From arjanv@redhat.com Wed Sep 1 00:03:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 00:03:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8173TkB000493 for ; Wed, 1 Sep 2004 00:03:29 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i81738S0014472; Wed, 1 Sep 2004 03:03:13 -0400 Received: from [172.31.3.35] (arjanv.cipe.redhat.com [10.0.2.48]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i81732322346; Wed, 1 Sep 2004 03:03:02 -0400 Subject: Re: [Announce] Update on ipw2100, ipw2200, and support for Intel PRO/Wireless 2915ABG From: Arjan van de Ven Reply-To: arjanv@redhat.com To: James Ketrenos Cc: Linux kernel mailing list , Netdev In-Reply-To: <4134E8EA.9080605@linux.intel.com> References: <4134E8EA.9080605@linux.intel.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-X7szBpNK5mljMglKnPP8" Organization: Red Hat UK Message-Id: <1094022177.2801.1.camel@laptop.fenrus.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Sep 2004 09:02:57 +0200 X-archive-position: 8295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arjanv@redhat.com Precedence: bulk X-list: netdev --=-X7szBpNK5mljMglKnPP8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-08-31 at 23:08, James Ketrenos wrote: > It's been a while since I've updated lkml and netdev on the progress of > the ipw projects. Given the recent announcement by Intel for the > introduction of Intel PRO/Wireless 2915 ABG Network Connection miniPCI > adapter, I thought now was a good time... you guys seem to be doing a really great job on these drivers; thanks! --=-X7szBpNK5mljMglKnPP8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBNXQgxULwo51rQBIRAvHCAJwOJrJP6DLAJuGhAuK9d1qoOUQJZgCghNlA Msq9xpw2hH+gug8KYZg9s0c= =kpDZ -----END PGP SIGNATURE----- --=-X7szBpNK5mljMglKnPP8-- From ricklind@us.ibm.com Wed Sep 1 01:33:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 01:33:59 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i818XlqM005862 for ; Wed, 1 Sep 2004 01:33:53 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i818XOKK349602; Wed, 1 Sep 2004 04:33:24 -0400 Received: from owlet.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i818YXrm160062; Wed, 1 Sep 2004 04:34:34 -0400 Received: from owlet.beaverton.ibm.com (rick@localhost) by owlet.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id i818XPZ04210; Wed, 1 Sep 2004 01:33:26 -0700 Message-Id: <200409010833.i818XPZ04210@owlet.beaverton.ibm.com> To: Nivedita Singhvi cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Fw: Re: 2.6.9-rc1-mm2 In-reply-to: Your message of "Tue, 31 Aug 2004 17:49:10 PDT." <41351C86.7000704@us.ibm.com> Date: Wed, 01 Sep 2004 01:33:25 -0700 From: Rick Lindsley X-archive-position: 8296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ricklind@us.ibm.com Precedence: bulk X-list: netdev Thanks for pointing out the specific config options. Granted a more recent config is warranted .. the one I'm using is 2.6.0-based. But considering I ran make oldconfig on this and chose the defaults in each and every case, should I end up with a config that doesn't compile? Is there still a config issue here, especially considering that both rc1 and rc1-mm1 compiled fine using this method? Or is make oldconfig only going to help for a version or two back? Rick From akpm@osdl.org Wed Sep 1 01:43:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 01:43:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i818hpT5006334 for ; Wed, 1 Sep 2004 01:43:51 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i818h7114811; Wed, 1 Sep 2004 01:43:07 -0700 Date: Wed, 1 Sep 2004 01:41:18 -0700 From: Andrew Morton To: Rick Lindsley Cc: niv@us.ibm.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Fw: Re: 2.6.9-rc1-mm2 Message-Id: <20040901014118.45204bcb.akpm@osdl.org> In-Reply-To: <200409010833.i818XPZ04210@owlet.beaverton.ibm.com> References: <41351C86.7000704@us.ibm.com> <200409010833.i818XPZ04210@owlet.beaverton.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Rick Lindsley wrote: > > But considering I ran make oldconfig on this and chose > the defaults in each and every case, should I end up with a config that > doesn't compile? No, you shouldn't. This indicates a Kconfig bug. From yoshfuji@linux-ipv6.org Wed Sep 1 02:01:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 02:01:56 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8191pPF007324 for ; Wed, 1 Sep 2004 02:01:51 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B532333CE6; Wed, 1 Sep 2004 18:02:37 +0900 (JST) Date: Wed, 01 Sep 2004 18:02:36 +0900 (JST) Message-Id: <20040901.180236.102852119.yoshfuji@linux-ipv6.org> To: thomasz@hostmaster.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1 oops From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1094028647.16908.42.camel@hostmaster.org> References: <1093945177.16908.14.camel@hostmaster.org> <1094028647.16908.42.camel@hostmaster.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <1094028647.16908.42.camel@hostmaster.org> (at Wed, 01 Sep 2004 10:50:47 +0200), Thomas Zehetbauer says: > I have now created a bug report for this issue: > http://bugzilla.kernel.org/show_bug.cgi?id=3323 (Plase use netdev...) I think this is already fixed in current bk tree. --yoshfuji From zhikui.chen@rus.uni-stuttgart.de Wed Sep 1 03:23:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 03:24:07 -0700 (PDT) Received: from uni-stuttgart.de (mbox.rus.uni-stuttgart.de [129.69.1.9]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81ANuWY011252 for ; Wed, 1 Sep 2004 03:23:57 -0700 Received: from [129.69.30.152] (HELO rus.uni-stuttgart.de) by uni-stuttgart.de (CommuniGate Pro SMTP 4.0.3) with ESMTP id 8883643; Wed, 01 Sep 2004 12:23:47 +0200 Message-ID: <4135A32A.4030901@rus.uni-stuttgart.de> Date: Wed, 01 Sep 2004 12:23:38 +0200 From: Zhikui Chen User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: dccp@ietf.org, netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: HELP for dccp implementation. References: <412CC269.8080907@rus.uni-stuttgart.de> <1093454747.1034.85.camel@jzny.localdomain> In-Reply-To: <1093454747.1034.85.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zhikui.chen@rus.uni-stuttgart.de Precedence: bulk X-list: netdev Hi, all If I assign a value such as 0x ee9fbc00 to sk in dccp_rcv (before lookup calling), and comment lookkup calling, I get a error report from bh_lock_sock(sk) calling inside dccp_rcv, which error report is spin_is_locked on uninitialized spinlock ee9fbc00, and spin_lock (:ee9fbc00) already locked by /73. Do you know its reason? Thanks, Best regards, Zhikui i there, >Could you please work with >Arnaldo Carvalho de Melo since he is >already working on this - this way we could have a coherent >implementation. >He is quiet knowledgeable on the internals of Linux and you could bring >in the protocol expertise. > >cheers, >jamal > >On Wed, 2004-08-25 at 12:46, Zhikui Chen wrote: > > >>Hi, dear all >> >>I could not assign __sk_head(head) value to sk in lookup_listen. >> >>I have writen the partial code for receive the request packet at server >>accodring to kernel TCP stuff, which is almost closed to TCP stuff. >> >>Anyone can tell me the reason or any hints? Thanks in advance. >> >>The details is following: >> >>The server for receiveing request packet firstly has following steps: >>1. Initialize dccp sock, >>2. dccp bind >>3. get_port >>3. hash >>4. accpet and waiting packet >>5. calling dccp_rcv to get packet ( I have checked dccp_rcv got the >>request packet). >>6. to get sk value by call dccp_lookup >>7 .... >> >>My problem is still in geting sk value, The follwing is my printing out: >> >>Aug 25 09:28:38 localhost kernel: DCCP: Hash tables configured >>(established 262144 bind 65536) >> >>dccp_init_sock: >>dccp_sock_init_common: >>allocated cctp successfully >>allocated pkt vectors successfully >>dccp_bind. >>New dccp_get_port start.65536 >>New dccp_get_port start.else:start >>db not found. >>bind hash add:sk:ee9fbc00,node:0,snum:7000 >>New dccp_get_port start.OK. sk:ee9fbc00,node:0 >>New dccp_get_port start.65536 >>New dccp_get_port start.else:start >>hlist_empty(&db->owners) not empty. >>New dccp_get_port start.OK. sk:ee9fbc00,node:ee5a0444 >>__dccp_v4_hash, list:c04eb670,num:7000,c0558780 >>__dccp_v4_hash, list:c04eb670,sk:ee9fbc00 >>dccp_accept start.7000,sk->sk_family=2,sk->sk_state=1,sk:ee9fbc00 >>dccp_accept 1 ..flags=2 >>dccp_accept 2 .. >>dccp_accept 3 ..timeo=2147483647,sk:ee9fbc00 >>wait_for_incoming_connection: >>dccp wait for connect start!sk:ee9fbc00 >>dccp wait for connect start!..sk:ee9fbc00 >>dccp_rcv start.ee9d3580 >>dccp_rcv: sk->sk_state=0, type=0,dh->dport=22555 >>dccp_v4_lookup >>__dccp_v4_lookup. >>dccp_v4_lookup_connection. >>hash 13291 >>dccp_v4_lookup_connection. head:f7619f58,node:eeaf5834,sk:ee9d3580 >>dccp_v4_lookup_connection. head:f7619f58,node:,sk:0 >>dccp_bhash_size: 65536,ntohs(dport):7000 >>first of head is not empty >>dccp_v4_lookup_listen: head: c04eb670,c0558780,__sk_head(head):ee9fbc00 >>dccp_v4_lookup_listen:sk: 0 >>dccp_rcv: unable to find socket() >> >>At print out, dccp_bind did not call get_port and inet_sk(sk) is >>assigned a port number which is 7000 from application. >> >>For printing __sk_head(head):ee9fbc00, I let sk = NULL in the >>dccp_v4_lookup_listen. >>HASH_TABLE = 32 or 128 I have the same result. >>And the source code is enclosed. >> >>Best regards, >> >>Zhikui >> >>------------------------------------------------------------------------ >> >>struct dccp_hashinfo __cacheline_aligned dccp_hashinfo = { >> .__dccp_lhash_lock = RW_LOCK_UNLOCKED, >> .__dccp_lhash_users = ATOMIC_INIT(0), >> .__dccp_lhash_wait >> = __WAIT_QUEUE_HEAD_INITIALIZER(dccp_hashinfo.__dccp_lhash_wait), >> .__dccp_portalloc_lock = SPIN_LOCK_UNLOCKED >>}; >> >> >> >> >>struct sockaddr_dccp { >> struct sockaddr_in in; >> __u32 service; >>}; >> >>static __inline__ int dccp_hashfn(__u32 laddr, __u16 lport, >> __u32 faddr, __u16 fport) >>{ >> int h = (laddr ^ lport) ^ (faddr ^ fport); >> h ^= h >> 16; >> h ^= h >> 8; >> return h & (dccp_ehash_size - 1);; >>} >> >>static __inline__ int dccp_sk_hashfn(struct sock *sk) >>{ >> struct inet_opt *inet = inet_sk(sk); >> __u32 laddr = inet->rcv_saddr; >> __u16 lport = inet->num; >> __u32 faddr = inet->daddr; >> __u16 fport = inet->dport; >> >> return dccp_hashfn(laddr, lport, faddr, fport); >>} >> >>kmem_cache_t *dccp_bucket_cachep; >> >>struct dccp_bind_bucket *dccp_bucket_create(struct dccp_bind_hashbucket *head, >> unsigned short snum) >>{ >> struct dccp_bind_bucket *db = kmem_cache_alloc(dccp_bucket_cachep, >> SLAB_ATOMIC); >> if (db) { >> db->port = snum; >> db->fastreuse = 0; >> INIT_HLIST_HEAD(&db->owners); >> hlist_add_head(&db->node, &head->chain); >> } >> return db; >>} >> >>void dccp_bucket_destroy(struct dccp_bind_bucket *db) >>{ >> if (hlist_empty(&db->owners)) { >> __hlist_del(&db->node); >> kmem_cache_free(dccp_bucket_cachep, db); >> } >>} >> >>/******************************************************************************/ >> >>static int parse_uaddr(struct sockaddr *uaddr, int addr_len, struct sockaddr_in **iaddr, struct sockaddr_dccp **dccp_addr){ >> if(addr_len < sizeof(struct sockaddr_in)) return -1; >> if(addr_len >= sizeof(struct sockaddr_dccp)){ >> *dccp_addr = (struct sockaddr_dccp *)uaddr; >> *iaddr = &((*dccp_addr)->in); >> }else{ >> *dccp_addr = NULL; >> *iaddr = (struct sockaddr_in *)uaddr; >> } >> return 0; >>} >> >>/******************************************************************************/ >>/* refer to net/ipv4/af_inet.c:inet_bind() */ >>static int dccp_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len){ >> printk("dccp_bind.\n"); >> struct sockaddr_in *iaddr; >> struct sockaddr_dccp *dccp_addr; >> struct inet_opt *inet = inet_sk(sk); >> int addr_type; >> int err; >> unsigned short port; >> >> if(parse_uaddr(uaddr, addr_len, &iaddr, &dccp_addr)) return -EINVAL; >> >> addr_type = inet_addr_type(iaddr->sin_addr.s_addr); >> if( inet->freebind == 0 >> && iaddr->sin_addr.s_addr != INADDR_ANY && addr_type != RTN_LOCAL >> && addr_type != RTN_MULTICAST && addr_type != RTN_BROADCAST) >> return -EADDRNOTAVAIL; >> >> port = ntohs(iaddr->sin_port); >> if(port && port < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE)) >> return -EACCES; >> >> lock_sock(sk); >> >> if(sk->sk_state != DCCP_STATE_CLOSED) ERR(-EISCONN); >> >> if(inet->num) ERR(-EINVAL); >> >> inet->rcv_saddr = inet->saddr = iaddr->sin_addr.s_addr; >> if(addr_type == RTN_MULTICAST || addr_type == RTN_BROADCAST) >> inet->saddr = 0; >> >> if(dccp_addr) dccp_sk(sk)->service = dccp_addr->service; >> else dccp_sk(sk)->service = 0; >>/*Note if we comment sk_port->getport() function calling, we should assign a local listen port number for building a listen hash and adding hash to node.*/ >>/* >> if(sk->sk_prot->get_port(sk, port) != 0){ >> inet->saddr = inet->rcv_saddr = 0; >> ERR(-EADDRINUSE); >> } >>*/ >> if(inet->rcv_saddr) sk->sk_userlocks |= SOCK_BINDADDR_LOCK; >> if(port) sk->sk_userlocks |= SOCK_BINDPORT_LOCK; >> inet->num = port;/*added 24.08.04, Note if we comment sk_port->getport() function calling, we should assign a local listen port number for building a listen hash and adding hash to node.*/ >> inet->dport = inet->daddr = 0; >> sk_dst_reset(sk); >> err = 0; >>out: >> release_sock(sk); >> return err; >>} >> >>void dccp_bind_hash(struct sock *sk, struct dccp_bind_bucket *db, >> unsigned short snum) >>{ >> inet_sk(sk)->num = snum; >> sk_add_bind_node(sk, &db->owners); >> dccp_sk(sk)->bind_hash = db; >>} >> >>static inline int dccp_bind_conflict(struct sock *sk, struct dccp_bind_bucket *db) >>{ >> printk("dccp_bind_conflict is called.\n"); >> const u32 sk_rcv_saddr = dccp_v4_rcv_saddr(sk); >> struct sock *sk2; >> struct hlist_node *node; >> int reuse = sk->sk_reuse; >> >> sk_for_each_bound(sk2, node, &db->owners) { >> if (sk != sk2 && >> !dccp_v6_ipv6only(sk2) && >> (!sk->sk_bound_dev_if || >> !sk2->sk_bound_dev_if || >> sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) { >> if (!reuse || !sk2->sk_reuse || >> sk2->sk_state == DCCP_STATE_LISTEN) { >> const u32 sk2_rcv_saddr = dccp_v4_rcv_saddr(sk2); >> if (!sk2_rcv_saddr || !sk_rcv_saddr || >> sk2_rcv_saddr == sk_rcv_saddr) >> break; >> } >> } >> } >> return node != NULL; >>} >> >>/* Obtain a reference to a local port for the given sock, >> * if snum is zero it means select any available local port. >> */ >>static int dccp_get_port(struct sock *sk, unsigned short snum) >>{ >> printk("New dccp_get_port start.%d, inet_sk(sk)->num=%d\n",dccp_bhash_size,inet_sk(sk)->num); >> struct dccp_bind_hashbucket *head; >> >> struct hlist_node *node; >> struct dccp_bind_bucket *db; >> int ret; >> >> if(inet_sk(sk)->num !=snum) >> snum=inet_sk(sk)->num; >> local_bh_disable(); >> if (!snum) { >> int low = sysctl_local_port_range[0]; >> int high = sysctl_local_port_range[1]; >> int remaining = (high - low) + 1; >> int rover; >> >> spin_lock(&dccp_portalloc_lock); >> rover = dccp_port_rover; >> do { >> printk("New dccp_get_port start.rover:%d\n",rover); >> rover++; >> if (rover < low || rover > high) >> rover = low; >> head = &dccp_bhash[dccp_bhashfn(rover)]; >> spin_lock(&head->lock); >> db_for_each(db, node, &head->chain) >> if (db->port == rover) >> goto next; >> break; >> next: >> spin_unlock(&head->lock); >> } while (--remaining > 0); >> dccp_port_rover = rover; >> spin_unlock(&dccp_portalloc_lock); >> >> /* Exhausted local port range during search? */ >> ret = 1; >> if (remaining <= 0) >> goto fail; >> >> /* OK, here is the one we will use. HEAD is >> * non-NULL and we hold it's mutex. >> */ >> printk("New dccp_get_port start.if:OK\n"); >> snum = rover; >> } else { >> printk("New dccp_get_port start.else:start\n"); >> head = &dccp_bhash[dccp_bhashfn(snum)]; >> spin_lock(&head->lock); >> db_for_each(db, node, &head->chain) >> if (db->port == snum) >> goto db_found; >> } >> db = NULL; >> goto db_not_found; >>db_found: >> if (!hlist_empty(&db->owners)) { >> printk("hlist_empty(&db->owners) not empty.\n"); >> if (sk->sk_reuse > 1) >> goto success; >> if (db->fastreuse > 0 && >> sk->sk_reuse && sk->sk_state != DCCP_STATE_LISTEN) { >> goto success; >> } else { >> ret = 1; >> if (dccp_bind_conflict(sk, db)) >> goto fail_unlock; >> } >> } >>db_not_found: >> printk("db not found.\n"); >> ret = 1; >> if (!db && (db = dccp_bucket_create(head, snum)) == NULL) >> goto fail_unlock; >> if (hlist_empty(&db->owners)) { >> if (sk->sk_reuse && sk->sk_state != DCCP_STATE_LISTEN) >> db->fastreuse = 1; >> else >> db->fastreuse = 0; >> } else if (db->fastreuse && >> (!sk->sk_reuse || sk->sk_state == DCCP_STATE_LISTEN)) >> db->fastreuse = 0; >>success: >> if (!dccp_sk(sk)->bind_hash){ >> dccp_bind_hash(sk, db, snum); >> printk("bind hash add:sk:%x,node:%x,snum:%d\n",sk,node,snum); >> } >> BUG_TRAP(dccp_sk(sk)->bind_hash == db); >> ret = 0; >> >>fail_unlock: >> spin_unlock(&head->lock); >>fail: >> local_bh_enable(); >> printk("New dccp_get_port start.OK. sk:%x,node:%x\n",sk,node); >> return ret; >>} >>/*****************************************************************************/ >>static int wait_for_incoming_connection(struct sock *sk, long timeo) >>{ >> printk("wait_for_incoming_connection: \n"); >> DECLARE_WAITQUEUE(wait, current); >> int err; >> struct dccp_opt *tp = dccp_sk(sk); >> >> /* >> * True wake-one mechanism for incoming connections: only >> * one process gets woken up, not the 'whole herd'. >> * Since we do not 'race & poll' for established sockets >> * anymore, the common case will execute the loop only once. >> * >> * Subtle issue: "add_wait_queue_exclusive()" will be added >> * after any current non-exclusive waiters, and we know that >> * it will always _stay_ after any new non-exclusive waiters >> * because all non-exclusive waiters are added at the >> * beginning of the wait-queue. As such, it's ok to "drop" >> * our exclusiveness temporarily when we get woken up without >> * having to remove and re-insert us on the wait queue. >> */ >> add_wait_queue_exclusive(sk->sk_sleep, &wait); >> printk("dccp wait for connect start!sk:%x\n",sk); >> for (;;) { >> current->state = TASK_INTERRUPTIBLE; >> release_sock(sk); >> printk("dccp wait for connect start!..sk:%x\n",sk); >> if (tp->accept_queue == NULL){ >> timeo = schedule_timeout(timeo); >> } >> printk("dccp wait for connect start .1!sk_state=%d, sk_family=%d\n",sk->sk_state,sk->sk_family); >> lock_sock(sk); >> err = 0; >> if (tp->accept_queue){ >> break; >> } >> err = -EINVAL; >> printk("dccp wait for connect start .1!sk_state=%d, sk_family=%d\n",sk->sk_state,sk->sk_family); >> if (sk->sk_state != DCCP_STATE_LISTEN){ >> printk("dccp wait for connect start .01!sk_state=%d\n",sk->sk_state); >> break; >> } >> err = sock_intr_errno(timeo); >> printk("dccp wait for connect start .2!\n"); >> if (signal_pending(current)){ >> break; >> } >> err = -EAGAIN; >> if (!timeo) >> break; >> } >> printk("dccp wait for connect end!\n"); >> current->state = TASK_RUNNING; >> remove_wait_queue(sk->sk_sleep, &wait); >> printk("dccp wait for connect end ok err=%d\n",err); >> return err; >>} >> >>struct sock *dccp_accept(struct sock *sk, int flags, int *err){ >> struct dccp_opt *tp = dccp_sk(sk); >> int error; >> struct sock *newsk = NULL; >> >> lock_sock(sk); >> >> printk("dccp_accept start.%d,sk->sk_family=%d,sk->sk_state=%d,sk:%x\n",inet_sk(sk)->num,sk->sk_family,sk->sk_state,sk); >> /* this socket must be listening */ >> error = -EINVAL; >> printk("dccp_accept 1 ..flags=%d\n",flags); >> if(sk->sk_state != DCCP_STATE_LISTEN) >> goto out; >> printk("dccp_accept 2 ..\n"); >> >> /* Find already established connection */ >> if(!tp->accept_queue){ >> long timeo = sock_rcvtimeo(sk, flags & O_NONBLOCK); >> printk("dccp_accept 3 ..timeo=%d,sk:%x\n",timeo,sk); >> >> error = -EAGAIN; >> if(!timeo) >> goto out; >> >> error = wait_for_incoming_connection(sk, timeo); >>// error = wait_for_connection(sk, timeo); >> printk("dccp_accept 4 ..\n"); >> //sleep(1000); >> if(error) goto out; >> BUG_TRAP(tp->accept_queue); >> } >> printk("dccp_accept 5 ..\n"); >> newsk = tp->accept_queue; >> tp->accept_queue = sk_next(newsk);//newsk->sk_bind_next; >> if(tp->accept_queue == NULL) tp->accept_queue_tail = NULL; >> BUG_TRAP(sk->sk_ack_backlog); >> sk->sk_ack_backlog -- ; /* since we are removing one */ >> dccp_sk(newsk)->flag_hashandle = 1; >>#if 0 >> /* remove from accept queue, will be referenced by socket */ >> sock_put(newsk); /* removed from the queue */ >> sock_hold(newsk); >>#endif >> >> error = 0; >>out: >> printk("dccp_accept 6 ..err=%d\n",err); >> release_sock(sk); >> *err = error; >> return newsk; >>} >> >>void dccp_listen_wlock(void) >>{ >> write_lock(&dccp_lhash_lock); >> >> if (atomic_read(&dccp_lhash_users)) { >> DEFINE_WAIT(wait); >> >> for (;;) { >> prepare_to_wait_exclusive(&dccp_lhash_wait, >> &wait, TASK_UNINTERRUPTIBLE); >> if (!atomic_read(&dccp_lhash_users)) >> break; >> write_unlock_bh(&dccp_lhash_lock); >> schedule(); >> write_lock_bh(&dccp_lhash_lock); >> } >> >> finish_wait(&dccp_lhash_wait, &wait); >> } >>} >> >>static __inline__ void __dccp_v4_hash(struct sock *sk, const int listen_possible) >>{ >> struct hlist_head *list; >> rwlock_t *lock; >> >> BUG_TRAP(sk_unhashed(sk)); >> if (listen_possible && sk->sk_state == DCCP_STATE_LISTEN) { >> list = &dccp_listening_hash[dccp_sk_listen_hashfn(sk)]; >> >> printk("__dccp_v4_hash, list:%x,num:%d,%x\n",list,inet_sk(sk)->num,&dccp_hash[inet_sk(sk)->num & (DCCP_HTABLE_SIZE - 1)]); >> lock = &dccp_lhash_lock; >> dccp_listen_wlock(); >> } else { >> list = &dccp_ehash[(sk->sk_hashent = dccp_sk_hashfn(sk))].chain; >> lock = &dccp_ehash[sk->sk_hashent].lock; >> write_lock(lock); >> } >> __sk_add_node(sk, list); >> sock_prot_inc_use(sk->sk_prot); >> write_unlock(lock); >> if (listen_possible && sk->sk_state == DCCP_STATE_LISTEN) >> wake_up(&dccp_lhash_wait); >> printk("__dccp_v4_hash, list:%x,sk:%x\n",list,sk); >>} >> >>static void dccp_v4_hash(struct sock *sk) >>{ >> if (sk->sk_state != DCCP_STATE_CLOSED) { >> local_bh_disable(); >> __dccp_v4_hash(sk, 1); >> local_bh_enable(); >> } >>} >> >>void dccp_unhash(struct sock *sk) >>{ >> rwlock_t *lock; >> >> if (sk_unhashed(sk)) >> goto ende; >> >> if (sk->sk_state == DCCP_STATE_LISTEN) { >> local_bh_disable(); >> dccp_listen_wlock(); >> lock = &dccp_lhash_lock; >> } else { >> struct dccp_ehash_bucket *head = &dccp_ehash[sk->sk_hashent]; >> lock = &head->lock; >> write_lock_bh(&head->lock); >> } >> >> if (__sk_del_node_init(sk)) >> sock_prot_dec_use(sk->sk_prot); >> write_unlock_bh(lock); >> >> ende: >> if (sk->sk_state == DCCP_STATE_LISTEN) >> wake_up(&dccp_lhash_wait); >>} >> >>/*****************************************************************************/ >>static struct sock *__dccp_v4_lookup_listen(struct hlist_head *head, u32 daddr, >> unsigned short hnum, int dif) >>{ >> struct sock *result = NULL, *sk; >> struct hlist_node *node; >> int score, hiscore; >> >> printk("__dccp_v4_lookup_listen: sk:%x,node:%x,head:%x,sk_state:%d\n",sk,node,head,sk->sk_state); >> hiscore=-1; >> sk_for_each(sk, node, head) { >> struct inet_opt *inet = inet_sk(sk); >> >> if (inet->num == hnum && !ipv6_only_sock(sk)) { >> __u32 rcv_saddr = inet->rcv_saddr; >> >> score = (sk->sk_family == PF_INET ? 1 : 0); >> if (rcv_saddr) { >> if (rcv_saddr != daddr) >> continue; >> score+=2; >> } >> if (sk->sk_bound_dev_if) { >> if (sk->sk_bound_dev_if != dif) >> continue; >> score+=2; >> } >> if (score == 5) >> return sk; >> if (score > hiscore) { >> hiscore = score; >> result = sk; >> } >> } >> } >> printk("dccp_v4_lookup_listen:sk:%x,result:%x\n",sk,result); >> return result; >>} >> >>/* Optimize the common listener case. */ >>inline struct sock *dccp_v4_lookup_listen(u32 daddr, u16 hnum,int dif) >>{ >> struct sock *sk = NULL; >> struct hlist_head *head; >> >> read_lock(&dccp_lhash_lock); >> printk("dccp_bhash_size: %d,ntohs(dport):%d\n",dccp_bhash_size,hnum); >> head = &dccp_listening_hash[dccp_lhashfn(hnum)]; >> >> if(head->first) >> printk("first of head is not empty\n"); >> >> printk("dccp_v4_lookup_listen: head: %x,%x,__sk_head(head):%x\n",head,&dccp_hash[hnum & (DCCP_HTABLE_SIZE - 1)],__sk_head(head)); >> >> if (!hlist_empty(head)) { >> struct inet_opt *inet = inet_sk((sk = __sk_head(head))); >> printk("dccp_v4_lookup_listen:sk: %x\n",sk); >> >> if (inet->num == hnum && !sk->sk_node.next && >> (!inet->rcv_saddr || inet->rcv_saddr == daddr) && >> (sk->sk_family == PF_INET || !ipv6_only_sock(sk)) && >> !sk->sk_bound_dev_if) >> goto sherry_cache; >> sk = __dccp_v4_lookup_listen(head, daddr, hnum, dif); >> } >> else >> printk("hlist_empty(head) is empty.\n"); >> if (sk) { >>sherry_cache: >> sock_hold(sk); >> } >> printk("dccp_v4_lookup_listen:sk: %x\n",sk); >> read_unlock(&dccp_lhash_lock); >> return sk; >>} >> >> >>/*****************************************************************************/ >> >>static inline struct sock *dccp_v4_lookup_connection(u32 saddr, u16 sport, u32 daddr, u16 hnum, int dif){ >> printk("dccp_v4_lookup_connection.\n"); >> struct dccp_ehash_bucket *head; >> DCCP_V4_ADDR_COOKIE(acookie, saddr, daddr) >> __u32 ports = DCCP_COMBINED_PORTS(sport, hnum); >> struct sock *sk; >> struct hlist_node *node; >> int hash = dccp_hashfn(daddr, hnum, saddr, sport); >> printk("hash %d\n",hash); >> head = &dccp_ehash[hash]; >> printk("dccp_v4_lookup_connection. head:%x,node:%x,sk:%x\n",head,node,sk); >> read_lock(&head->lock); >> sk_for_each(sk, node, &head->chain) { >> if (DCCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) >> goto hit; >> } >> >> sk_for_each(sk, node, &(head + dccp_ehash_size)->chain) { >> if (DCCP_IPV4_DW_MATCH(sk, acookie, saddr, daddr, ports, dif)) >> goto hit; >> } >> sk = NULL; >>out: >> read_unlock(&head->lock); >> printk("dccp_v4_lookup_connection. head:%x,node:,sk:%x\n",head,sk); >> return sk; >>hit: >> sock_hold(sk); >> goto out; >>} >> >>/*****************************************************************************/ >> >>static inline struct sock *__dccp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport,int dif){ >> printk("__dccp_v4_lookup.\n"); >> >> struct sock *sk = dccp_v4_lookup_connection(saddr, sport, daddr, ntohs(dport), dif); >> return sk ? : dccp_v4_lookup_listen(daddr, ntohs(dport),dif); >>} >> >>inline struct sock *dccp_v4_lookup(u32 saddr, u16 sport, u32 daddr, >> u16 dport, int dif) >>{ >> printk("dccp_v4_lookup\n"); >> struct sock *sk; >> >> local_bh_disable(); >> sk = __dccp_v4_lookup(saddr, sport, daddr, dport, dif); >> local_bh_enable(); >> >> return sk; >>} >> >>Best regards, >> >>Zhikui >> >> >> >> >> > > > > From vatsa@in.ibm.com Wed Sep 1 04:34:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 04:35:01 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81BYlS7017442 for ; Wed, 1 Sep 2004 04:34:48 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i81BYOnt158880; Wed, 1 Sep 2004 07:34:24 -0400 Received: from snowy.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i81BZSGY128368; Wed, 1 Sep 2004 07:35:32 -0400 Received: by snowy.in.ibm.com (Postfix, from userid 502) id 981C424E32; Wed, 1 Sep 2004 17:06:41 +0530 (IST) Date: Wed, 1 Sep 2004 17:06:41 +0530 From: Srivatsa Vaddagiri To: Andi Kleen Cc: davem@redhat.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Dipankar , paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-ID: <20040901113641.GA3918@in.ibm.com> Reply-To: vatsa@in.ibm.com References: <20040831125941.GA5534@in.ibm.com> <20040831135419.GA17642@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040831135419.GA17642@wotan.suse.de> User-Agent: Mutt/1.4.1i X-archive-position: 8300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vatsa@in.ibm.com Precedence: bulk X-list: netdev On Tue, Aug 31, 2004 at 03:54:20PM +0200, Andi Kleen wrote: > I bet also when you just do rdtsc timing for the TCP receive > path the cycle numbers will be way down (excluding the copy). I got cycle numbers for the lookup routine (with CONFIG_PREEMPT turned off). They were taken on a 900MHz 8way Intel P3 SMP box. The results are as below: ------------------------------------------------------------------------------- | 2.6.8.1 | 2.6.8.1 + my patch ------------------------------------------------------------------------------- Average cycles | | spent in | | __tcp_v4_lookup_established | 2970.65 | 668.227 | (~3.3 micro-seconds) | (~0.74 microseconds) ------------------------------------------------------------------------------- This repesents improvement by a factor of 77.5%! > > And it should also fix the performance problems with > cat /proc/net/tcp on ppc64/ia64 for large hash tables because the rw locks > are gone. But spinlocks are in! Would that still improve the performance compared to rw locks? (See me earlier note where I have explained that lookup done for /proc/net/tcp is _not_ lock-free yet). > I haven't studied it in detail (yet), just two minor style > comments: [snip] > Can you rewrite that without goto? [snip] > And that too. I have avoided the goto's in the updated patch below. Thanks!! --- linux-2.6.8.1-vatsa/include/net/sock.h | 22 +++++++++-- linux-2.6.8.1-vatsa/include/net/tcp.h | 24 +++++++++--- linux-2.6.8.1-vatsa/net/core/sock.c | 11 +++++ linux-2.6.8.1-vatsa/net/ipv4/tcp.c | 2 - linux-2.6.8.1-vatsa/net/ipv4/tcp_diag.c | 11 +++-- linux-2.6.8.1-vatsa/net/ipv4/tcp_ipv4.c | 50 ++++++++++++++++----------- linux-2.6.8.1-vatsa/net/ipv4/tcp_minisocks.c | 47 ++++++++++++++++++++----- linux-2.6.8.1-vatsa/net/ipv6/tcp_ipv6.c | 22 +++++++---- 8 files changed, 135 insertions(+), 54 deletions(-) diff -puN include/net/sock.h~tcp_ehash include/net/sock.h --- linux-2.6.8.1/include/net/sock.h~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/include/net/sock.h 2004-09-01 10:09:43.000000000 +0530 @@ -50,6 +50,7 @@ #include #include +#include #include #include @@ -178,6 +179,7 @@ struct sock_common { * @sk_error_report - callback to indicate errors (e.g. %MSG_ERRQUEUE) * @sk_backlog_rcv - callback to process the backlog * @sk_destruct - called at sock freeing time, i.e. when all refcnt == 0 + * @sk_rcu - RCU callback structure */ struct sock { /* @@ -266,6 +268,7 @@ struct sock { int (*sk_backlog_rcv)(struct sock *sk, struct sk_buff *skb); void (*sk_destruct)(struct sock *sk); + struct rcu_head sk_rcu; }; /* @@ -350,7 +353,7 @@ static __inline__ int sk_del_node_init(s static __inline__ void __sk_add_node(struct sock *sk, struct hlist_head *list) { - hlist_add_head(&sk->sk_node, list); + hlist_add_head_rcu(&sk->sk_node, list); } static __inline__ void sk_add_node(struct sock *sk, struct hlist_head *list) @@ -371,7 +374,7 @@ static __inline__ void sk_add_bind_node( } #define sk_for_each(__sk, node, list) \ - hlist_for_each_entry(__sk, node, list, sk_node) + hlist_for_each_entry_rcu(__sk, node, list, sk_node) #define sk_for_each_from(__sk, node) \ if (__sk && ({ node = &(__sk)->sk_node; 1; })) \ hlist_for_each_entry_from(__sk, node, sk_node) @@ -703,6 +706,7 @@ extern void FASTCALL(release_sock(struct extern struct sock * sk_alloc(int family, int priority, int zero_it, kmem_cache_t *slab); extern void sk_free(struct sock *sk); +extern void sk_free_rcu(struct rcu_head *head); extern struct sk_buff *sock_wmalloc(struct sock *sk, unsigned long size, int force, @@ -888,8 +892,18 @@ static inline void sk_filter_charge(stru /* Ungrab socket and destroy it, if it was the last reference. */ static inline void sock_put(struct sock *sk) { - if (atomic_dec_and_test(&sk->sk_refcnt)) - sk_free(sk); + while (atomic_dec_and_test(&sk->sk_refcnt)) { + /* Restore ref count and schedule callback. + * If we don't restore ref count, then the callback can be + * scheduled by more than one CPU. + */ + atomic_inc(&sk->sk_refcnt); + + if (atomic_read(&sk->sk_refcnt) == 1) { + call_rcu(&sk->sk_rcu, sk_free_rcu); + break; + } + } } /* Detach socket from process context. diff -puN include/net/tcp.h~tcp_ehash include/net/tcp.h --- linux-2.6.8.1/include/net/tcp.h~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/include/net/tcp.h 2004-09-01 10:13:40.000000000 +0530 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -44,7 +45,7 @@ * for the rest. I'll experiment with dynamic table growth later. */ struct tcp_ehash_bucket { - rwlock_t lock; + spinlock_t lock; struct hlist_head chain; } __attribute__((__aligned__(8))); @@ -222,12 +223,13 @@ struct tcp_tw_bucket { struct in6_addr tw_v6_rcv_saddr; int tw_v6_ipv6only; #endif + struct rcu_head tw_rcu; }; static __inline__ void tw_add_node(struct tcp_tw_bucket *tw, struct hlist_head *list) { - hlist_add_head(&tw->tw_node, list); + hlist_add_head_rcu(&tw->tw_node, list); } static __inline__ void tw_add_bind_node(struct tcp_tw_bucket *tw, @@ -305,14 +307,22 @@ static inline int tcp_v6_ipv6only(const #endif extern kmem_cache_t *tcp_timewait_cachep; +extern void tcp_tw_free(struct rcu_head *head); static inline void tcp_tw_put(struct tcp_tw_bucket *tw) { - if (atomic_dec_and_test(&tw->tw_refcnt)) { -#ifdef INET_REFCNT_DEBUG - printk(KERN_DEBUG "tw_bucket %p released\n", tw); -#endif - kmem_cache_free(tcp_timewait_cachep, tw); + while (atomic_dec_and_test(&tw->tw_refcnt)) { + /* Restore ref count and schedule callback. + * If we don't restore ref count, then the callback can be + * scheduled by more than one CPU. + */ + + atomic_inc(&tw->tw_refcnt); + + if (atomic_read(&tw->tw_refcnt) == 1) { + call_rcu(&tw->tw_rcu, tcp_tw_free); + break; + } } } diff -puN net/core/sock.c~tcp_ehash net/core/sock.c --- linux-2.6.8.1/net/core/sock.c~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/net/core/sock.c 2004-08-26 16:53:14.000000000 +0530 @@ -657,6 +657,16 @@ void sk_free(struct sock *sk) module_put(owner); } +/* RCU callback to free a socket */ + +void sk_free_rcu(struct rcu_head *head) +{ + struct sock *sk = container_of(head, struct sock, sk_rcu); + + if (atomic_dec_and_test(&sk->sk_refcnt)) + sk_free(sk); +} + void __init sk_init(void) { sk_cachep = kmem_cache_create("sock", sizeof(struct sock), 0, @@ -1347,6 +1357,7 @@ EXPORT_SYMBOL(__lock_sock); EXPORT_SYMBOL(__release_sock); EXPORT_SYMBOL(sk_alloc); EXPORT_SYMBOL(sk_free); +EXPORT_SYMBOL(sk_free_rcu); EXPORT_SYMBOL(sk_send_sigurg); EXPORT_SYMBOL(sock_alloc_send_pskb); EXPORT_SYMBOL(sock_alloc_send_skb); diff -puN net/ipv4/tcp_ipv4.c~tcp_ehash net/ipv4/tcp_ipv4.c --- linux-2.6.8.1/net/ipv4/tcp_ipv4.c~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/net/ipv4/tcp_ipv4.c 2004-08-25 18:07:27.000000000 +0530 @@ -351,7 +351,8 @@ void tcp_listen_wlock(void) static __inline__ void __tcp_v4_hash(struct sock *sk, const int listen_possible) { struct hlist_head *list; - rwlock_t *lock; + rwlock_t *lock = NULL; + spinlock_t *slock = NULL; BUG_TRAP(sk_unhashed(sk)); if (listen_possible && sk->sk_state == TCP_LISTEN) { @@ -360,14 +361,16 @@ static __inline__ void __tcp_v4_hash(str tcp_listen_wlock(); } else { list = &tcp_ehash[(sk->sk_hashent = tcp_sk_hashfn(sk))].chain; - lock = &tcp_ehash[sk->sk_hashent].lock; - write_lock(lock); + slock = &tcp_ehash[sk->sk_hashent].lock; + spin_lock(slock); } __sk_add_node(sk, list); sock_prot_inc_use(sk->sk_prot); - write_unlock(lock); - if (listen_possible && sk->sk_state == TCP_LISTEN) + if (listen_possible && sk->sk_state == TCP_LISTEN) { + write_unlock(lock); wake_up(&tcp_lhash_wait); + } else + spin_unlock(slock); } static void tcp_v4_hash(struct sock *sk) @@ -381,7 +384,8 @@ static void tcp_v4_hash(struct sock *sk) void tcp_unhash(struct sock *sk) { - rwlock_t *lock; + rwlock_t *lock = NULL; + spinlock_t *slock = NULL; if (sk_unhashed(sk)) goto ende; @@ -392,17 +396,20 @@ void tcp_unhash(struct sock *sk) lock = &tcp_lhash_lock; } else { struct tcp_ehash_bucket *head = &tcp_ehash[sk->sk_hashent]; - lock = &head->lock; - write_lock_bh(&head->lock); + slock = &head->lock; + spin_lock_bh(&head->lock); } if (__sk_del_node_init(sk)) sock_prot_dec_use(sk->sk_prot); - write_unlock_bh(lock); + if (sk->sk_state != TCP_LISTEN) + spin_unlock_bh(slock); + else { + write_unlock_bh(lock); ende: - if (sk->sk_state == TCP_LISTEN) wake_up(&tcp_lhash_wait); + } } /* Don't inline this cruft. Here are some nice properties to @@ -494,7 +501,7 @@ static inline struct sock *__tcp_v4_look */ int hash = tcp_hashfn(daddr, hnum, saddr, sport); head = &tcp_ehash[hash]; - read_lock(&head->lock); + rcu_read_lock(); sk_for_each(sk, node, &head->chain) { if (TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) goto hit; /* You sunk my battleship! */ @@ -507,7 +514,7 @@ static inline struct sock *__tcp_v4_look } sk = NULL; out: - read_unlock(&head->lock); + rcu_read_unlock(); return sk; hit: sock_hold(sk); @@ -559,7 +566,7 @@ static int __tcp_v4_check_established(st struct hlist_node *node; struct tcp_tw_bucket *tw; - write_lock(&head->lock); + spin_lock(&head->lock); /* Check TIME-WAIT sockets first. */ sk_for_each(sk2, node, &(head + tcp_ehash_size)->chain) { @@ -614,7 +621,7 @@ unique: BUG_TRAP(sk_unhashed(sk)); __sk_add_node(sk, &head->chain); sock_prot_inc_use(sk->sk_prot); - write_unlock(&head->lock); + spin_unlock(&head->lock); if (twp) { *twp = tw; @@ -630,7 +637,7 @@ unique: return 0; not_unique: - write_unlock(&head->lock); + spin_unlock(&head->lock); return -EADDRNOTAVAIL; } @@ -2228,7 +2235,10 @@ static void *established_get_first(struc struct hlist_node *node; struct tcp_tw_bucket *tw; - read_lock(&tcp_ehash[st->bucket].lock); + /* Take the spinlock. Otherwise a dancing socket + * (__tcp_tw_hashdance) may be reported twice! + */ + spin_lock(&tcp_ehash[st->bucket].lock); sk_for_each(sk, node, &tcp_ehash[st->bucket].chain) { if (sk->sk_family != st->family) { continue; @@ -2245,7 +2255,7 @@ static void *established_get_first(struc rc = tw; goto out; } - read_unlock(&tcp_ehash[st->bucket].lock); + spin_unlock(&tcp_ehash[st->bucket].lock); st->state = TCP_SEQ_STATE_ESTABLISHED; } out: @@ -2272,10 +2282,10 @@ get_tw: cur = tw; goto out; } - read_unlock(&tcp_ehash[st->bucket].lock); + spin_unlock(&tcp_ehash[st->bucket].lock); st->state = TCP_SEQ_STATE_ESTABLISHED; if (++st->bucket < tcp_ehash_size) { - read_lock(&tcp_ehash[st->bucket].lock); + spin_lock(&tcp_ehash[st->bucket].lock); sk = sk_head(&tcp_ehash[st->bucket].chain); } else { cur = NULL; @@ -2385,7 +2395,7 @@ static void tcp_seq_stop(struct seq_file case TCP_SEQ_STATE_TIME_WAIT: case TCP_SEQ_STATE_ESTABLISHED: if (v) - read_unlock(&tcp_ehash[st->bucket].lock); + spin_unlock(&tcp_ehash[st->bucket].lock); local_bh_enable(); break; } diff -puN net/ipv4/tcp.c~tcp_ehash net/ipv4/tcp.c --- linux-2.6.8.1/net/ipv4/tcp.c~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/net/ipv4/tcp.c 2004-08-25 18:07:27.000000000 +0530 @@ -2258,7 +2258,7 @@ void __init tcp_init(void) if (!tcp_ehash) panic("Failed to allocate TCP established hash table\n"); for (i = 0; i < (tcp_ehash_size << 1); i++) { - tcp_ehash[i].lock = RW_LOCK_UNLOCKED; + tcp_ehash[i].lock = SPIN_LOCK_UNLOCKED; INIT_HLIST_HEAD(&tcp_ehash[i].chain); } diff -puN net/ipv4/tcp_diag.c~tcp_ehash net/ipv4/tcp_diag.c --- linux-2.6.8.1/net/ipv4/tcp_diag.c~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/net/ipv4/tcp_diag.c 2004-08-25 18:07:27.000000000 +0530 @@ -522,7 +522,10 @@ skip_listen_ht: if (i > s_i) s_num = 0; - read_lock_bh(&head->lock); + /* Take the spinlock. Otherwise a dancing socket + * (__tcp_tw_hashdance) may be reported twice! + */ + spin_lock_bh(&head->lock); num = 0; sk_for_each(sk, node, &head->chain) { @@ -542,7 +545,7 @@ skip_listen_ht: if (tcpdiag_fill(skb, sk, r->tcpdiag_ext, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq) <= 0) { - read_unlock_bh(&head->lock); + spin_unlock_bh(&head->lock); goto done; } ++num; @@ -568,13 +571,13 @@ skip_listen_ht: if (tcpdiag_fill(skb, sk, r->tcpdiag_ext, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq) <= 0) { - read_unlock_bh(&head->lock); + spin_unlock_bh(&head->lock); goto done; } ++num; } } - read_unlock_bh(&head->lock); + spin_unlock_bh(&head->lock); } done: diff -puN net/ipv4/tcp_minisocks.c~tcp_ehash net/ipv4/tcp_minisocks.c --- linux-2.6.8.1/net/ipv4/tcp_minisocks.c~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/net/ipv4/tcp_minisocks.c 2004-08-26 16:58:08.000000000 +0530 @@ -64,14 +64,14 @@ static void tcp_timewait_kill(struct tcp /* Unlink from established hashes. */ ehead = &tcp_ehash[tw->tw_hashent]; - write_lock(&ehead->lock); + spin_lock(&ehead->lock); if (hlist_unhashed(&tw->tw_node)) { - write_unlock(&ehead->lock); + spin_unlock(&ehead->lock); return; } __hlist_del(&tw->tw_node); sk_node_init(&tw->tw_node); - write_unlock(&ehead->lock); + spin_unlock(&ehead->lock); /* Disassociate with bind bucket. */ bhead = &tcp_bhash[tcp_bhashfn(tw->tw_num)]; @@ -308,17 +308,28 @@ static void __tcp_tw_hashdance(struct so tw_add_bind_node(tw, &tw->tw_tb->owners); spin_unlock(&bhead->lock); - write_lock(&ehead->lock); + spin_lock(&ehead->lock); - /* Step 2: Remove SK from established hash. */ - if (__sk_del_node_init(sk)) - sock_prot_dec_use(sk->sk_prot); + /* + * We have to be carefull here since there could be racing + * (lock-free) lookups happening on other CPUs. If we remove SK first + * and then add TW, then there is a tiny window where this socket is + * in neither the established half nor in the TIMEWAIT half of the ehash + * table. Lookups occuring in that window can drop packets! + * Hence we first add TW and then remove SK, with a barrier in between. + */ - /* Step 3: Hash TW into TIMEWAIT half of established hash table. */ + /* Step 2: Hash TW into TIMEWAIT half of established hash table. */ tw_add_node(tw, &(ehead + tcp_ehash_size)->chain); atomic_inc(&tw->tw_refcnt); - write_unlock(&ehead->lock); + smp_wmb(); + + /* Step 3: Remove SK from established hash. */ + if (__sk_del_node_init(sk)) + sock_prot_dec_use(sk->sk_prot); + + spin_unlock(&ehead->lock); } /* @@ -1069,11 +1080,29 @@ int tcp_child_process(struct sock *paren return ret; } +/* RCU callback to free a timewait bucket */ + +void tcp_tw_free(struct rcu_head *head) +{ + struct tcp_tw_bucket *tw = + container_of(head, struct tcp_tw_bucket, tw_rcu); + + if (atomic_dec_and_test(&tw->tw_refcnt)) { +#ifdef INET_REFCNT_DEBUG + printk(KERN_DEBUG "tw_bucket %p released\n", tw); +#endif + kmem_cache_free(tcp_timewait_cachep, tw); + } +} + + + EXPORT_SYMBOL(tcp_check_req); EXPORT_SYMBOL(tcp_child_process); EXPORT_SYMBOL(tcp_create_openreq_child); EXPORT_SYMBOL(tcp_timewait_state_process); EXPORT_SYMBOL(tcp_tw_deschedule); +EXPORT_SYMBOL(tcp_tw_free); #ifdef CONFIG_SYSCTL EXPORT_SYMBOL(sysctl_tcp_tw_recycle); diff -puN net/ipv6/tcp_ipv6.c~tcp_ehash net/ipv6/tcp_ipv6.c --- linux-2.6.8.1/net/ipv6/tcp_ipv6.c~tcp_ehash 2004-08-25 18:06:42.000000000 +0530 +++ linux-2.6.8.1-vatsa/net/ipv6/tcp_ipv6.c 2004-08-25 18:07:27.000000000 +0530 @@ -210,7 +210,8 @@ fail: static __inline__ void __tcp_v6_hash(struct sock *sk) { struct hlist_head *list; - rwlock_t *lock; + rwlock_t *lock = NULL; + spinlock_t *slock = NULL; BUG_TRAP(sk_unhashed(sk)); @@ -221,13 +222,16 @@ static __inline__ void __tcp_v6_hash(str } else { sk->sk_hashent = tcp_v6_sk_hashfn(sk); list = &tcp_ehash[sk->sk_hashent].chain; - lock = &tcp_ehash[sk->sk_hashent].lock; - write_lock(lock); + slock = &tcp_ehash[sk->sk_hashent].lock; + spin_lock(slock); } __sk_add_node(sk, list); sock_prot_inc_use(sk->sk_prot); - write_unlock(lock); + if (sk->sk_state == TCP_LISTEN) + write_unlock(lock); + else + spin_unlock(slock); } @@ -307,7 +311,7 @@ static inline struct sock *__tcp_v6_look */ hash = tcp_v6_hashfn(daddr, hnum, saddr, sport); head = &tcp_ehash[hash]; - read_lock(&head->lock); + rcu_read_lock(); sk_for_each(sk, node, &head->chain) { /* For IPV6 do the cheaper port and family tests first. */ if(TCP_IPV6_MATCH(sk, saddr, daddr, ports, dif)) @@ -326,12 +330,12 @@ static inline struct sock *__tcp_v6_look goto hit; } } - read_unlock(&head->lock); + rcu_read_unlock(); return NULL; hit: sock_hold(sk); - read_unlock(&head->lock); + rcu_read_unlock(); return sk; } @@ -452,7 +456,7 @@ static int tcp_v6_check_established(stru struct hlist_node *node; struct tcp_tw_bucket *tw; - write_lock_bh(&head->lock); + spin_lock_bh(&head->lock); /* Check TIME-WAIT sockets first. */ sk_for_each(sk2, node, &(head + tcp_ehash_size)->chain) { @@ -491,7 +495,7 @@ unique: __sk_add_node(sk, &head->chain); sk->sk_hashent = hash; sock_prot_inc_use(sk->sk_prot); - write_unlock_bh(&head->lock); + spin_unlock_bh(&head->lock); if (tw) { /* Silly. Should hash-dance instead... */ _ -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 From DanE@aiinet.com Wed Sep 1 07:13:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 07:13:42 -0700 (PDT) Received: from aiexchange.ai.aiinet.com (ai181-26.aiinet.com [205.245.181.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81EDZc4021183 for ; Wed, 1 Sep 2004 07:13:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4902D.D3F1B09D" Subject: RE: [Bridge] BCP status Date: Wed, 1 Sep 2004 10:13:17 -0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Bridge] BCP status Thread-Index: AcSQBeEZdLXyu5JNTQGZbEJfr4S2kAAIN/oA From: "Eble, Dan" To: "Petter Larsen" Cc: , X-archive-position: 8301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: DanE@aiinet.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------_=_NextPart_001_01C4902D.D3F1B09D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Petter Larsen [mailto:petter.larsen@morecom.no]=20 > Subject: RE: [Bridge] BCP status >=20 > Ok. The patches that you sent to the mailing list in March,=20 > are they the latest from your side? You mentioned that you had some=20 > plug-ins for HDLC ppp-layer drivers. =20 >=20 > Are you working on this now, or are you finished?=20 Nothing is ever finished; however, I have not worked on it for months. Kernel BCP patch: http://marc.theaimsgroup.com/?l=3Dlinux-ppp&m=3D107814944215772&w=3D2 No changes since then, AFAICT. PPP daemon BCP patch: http://marc.theaimsgroup.com/?l=3Dlinux-ppp&m=3D107772784930462&w=3D2 No changes since then, AFAICT. PPP daemon "wanppp" plugin: http://marc.theaimsgroup.com/?l=3Dlinux-ppp&m=3D105526128502635&w=3D2 It looks current except for a correction of spelling (s/compliled/compiled/) and the addition of prototypes for wanppp_cleanup() and wanppp_close(). Kernel generic HDLC to generic PPP layer: http://marc.theaimsgroup.com/?l=3Dlinux-net&m=3D105525978800615&w=3D2 This has changed slightly. I have attached our latest drivers/net/wan/hdlc_ppp.c. --=20 Dan Eble _____ . Software Engineer | _ |/| Applied Innovation Inc. | |_| | | http://www.aiinet.com/ |__/|_|_| ------_=_NextPart_001_01C4902D.D3F1B09D Content-Type: application/octet-stream; name="hdlc_ppp.c" Content-Transfer-Encoding: base64 Content-Description: hdlc_ppp.c Content-Disposition: attachment; filename="hdlc_ppp.c" LyoKICogR2VuZXJpYyBIRExDIHN1cHBvcnQgcm91dGluZXMgZm9yIExpbnV4CiAqIFBvaW50LXRv LXBvaW50IHByb3RvY29sIHN1cHBvcnQKICoKICogQ29weXJpZ2h0IChDKSAxOTk5IC0gMjAwMyBL cnp5c3p0b2YgSGFsYXNhIDxraGNAcG0ud2F3LnBsPgogKgogKiBUaGlzIHByb2dyYW0gaXMgZnJl ZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSBpdAogKiB1 bmRlciB0aGUgdGVybXMgb2YgdmVyc2lvbiAyIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj ZW5zZQogKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbi4KICov CgojaW5jbHVkZSA8bGludXgvY29uZmlnLmg+CiNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KI2lu Y2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgojaW5jbHVkZSA8bGludXgvc2xhYi5oPgojaW5jbHVkZSA8 bGludXgvcG9sbC5oPgojaW5jbHVkZSA8bGludXgvZXJybm8uaD4KI2luY2x1ZGUgPGxpbnV4L2lm X2FycC5oPgojaW5jbHVkZSA8bGludXgvaW5pdC5oPgojaW5jbHVkZSA8bGludXgvc2tidWZmLmg+ CiNpbmNsdWRlIDxsaW51eC9wa3Rfc2NoZWQuaD4KI2luY2x1ZGUgPGxpbnV4L2luZXRkZXZpY2Uu aD4KI2luY2x1ZGUgPGxpbnV4L2xhcGIuaD4KI2luY2x1ZGUgPGxpbnV4L3J0bmV0bGluay5oPgoj aW5jbHVkZSA8bGludXgvaGRsYy5oPgojaW5jbHVkZSA8bGludXgvcHBwX2RlZnMuaD4KI2luY2x1 ZGUgPGxpbnV4L2lmX3BwcC5oPgojaW5jbHVkZSA8bGludXgvcHBwX2NoYW5uZWwuaD4KCi8qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKgogKiBDb25zdGFudHMgYW5kIFN0cnVjdHVyZXMKICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KiovCgovKiBUaGUgUFBQIGhlYWRlciBpbmNsdWRlcyB0aGUgSERMQyBhZGRyZXNzICYgY29udHJv bCBieXRlcywKICogc28gZG8gbm90IGNvdW50IHRoZW0gaW4gTVRVIGFkanVzdG1lbnRzLgogKi8K I2RlZmluZSBQUFBfT1ZFUkhFQUQJKFBQUF9IRFJMRU4gLSAyKQoKLyoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq CiAqIFByb3RvdHlwZXMKICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCgpzdGF0aWMgaW50IGhkbGNfcHBwX3Jl Z2lzdGVyKGhkbGNfZGV2aWNlICpoZGxjKTsKc3RhdGljIHZvaWQgaGRsY19wcHBfdW5yZWdpc3Rl cihoZGxjX2RldmljZSAqaGRsYyk7CnN0YXRpYyB2b2lkIGhkbGNfcHBwX25ldGlmX3J4KHN0cnVj dCBza19idWZmICpza2IpOwpzdGF0aWMgaW50IGhkbGNfZ2VucHBwX3N0YXJ0X3htaXQoc3RydWN0 IHBwcF9jaGFubmVsICosIHN0cnVjdCBza19idWZmICopOwpzdGF0aWMgaW50IGhkbGNfZ2VucHBw X2lvY3RsKHN0cnVjdCBwcHBfY2hhbm5lbCosIHVuc2lnbmVkIGludCwgdW5zaWduZWQgbG9uZyk7 CgovKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioKICogVmFyaWFibGVzCiAqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwoKc3Rh dGljIHN0cnVjdCBwcHBfY2hhbm5lbF9vcHMgaGRsY19nZW5wcHBfb3BzID0KewoJLnN0YXJ0X3ht aXQgPQloZGxjX2dlbnBwcF9zdGFydF94bWl0LAoJLmlvY3RsID0JaGRsY19nZW5wcHBfaW9jdGwK fTsKCi8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKgogKiBJbmxpbmUgRnVuY3Rpb25zCiAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqLwoKLyoqIEdldCB0aGUgUFBQIGNoYW5uZWwgb3duZWQgYnkgYW4gSERMQyBkZXZpY2UuICov CnN0YXRpYyBfX2lubGluZV9fIHN0cnVjdCBwcHBfY2hhbm5lbCogaGRsY190b19jaGFuKGhkbGNf ZGV2aWNlICpoZGxjKQp7CglyZXR1cm4gKHN0cnVjdCBwcHBfY2hhbm5lbCopJmhkbGMtPnN0YXRl LnBwcC5jaGFuOwp9CgovKiogR2V0IGFuIEhETEMgZGV2aWNlIGZyb20gaXRzIFBQUCBjaGFubmVs LiAqLwpzdGF0aWMgX19pbmxpbmVfXyBoZGxjX2RldmljZSogY2hhbl90b19oZGxjKHN0cnVjdCBw cHBfY2hhbm5lbCAqY2hhbikKewoJcmV0dXJuIChoZGxjX2RldmljZSopY2hhbi0+cHJpdmF0ZTsK fQoKLyoqIENoZWNrIFVQLCBSVU5OSU5HLCBhbmQgY2FycmllciBhbGwgYXQgb25jZS4gKi8Kc3Rh dGljIF9faW5saW5lX18gaW50IG5ldGlmX2dvb2RfdG9fZ28oc3RydWN0IG5ldF9kZXZpY2UgKmRl dikKewoJcmV0dXJuIChkZXYtPmZsYWdzICYgSUZGX1VQKSAmJgoJCW5ldGlmX3J1bm5pbmcoZGV2 KSAmJgoJCW5ldGlmX2NhcnJpZXJfb2soZGV2KTsKfQoKLyoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCiAqIEZ1 bmN0aW9ucwogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKi8KCi8qKgogKiBJbml0aWFsaXplIGFuZCByZWdpc3Rl ciBhIFBQUCBjaGFubmVsIHdpdGggdGhlIGdlbmVyaWMgUFBQIGxheWVyLgogKgogKiBoZGxjX3Bw cF9yZWdpc3RlcigpIGlzIGNhbGxlZCBmcm9tIHByb2Nlc3MgY29udGV4dCB3aGlsZSB0aGUKICog aW50ZXJmYWNlIGlzIGRvd24uCiAqLwpzdGF0aWMgaW50IGhkbGNfcHBwX3JlZ2lzdGVyKGhkbGNf ZGV2aWNlICpoZGxjKQp7CglzdHJ1Y3QgbmV0X2RldmljZSAqY29uc3QgZGV2ID0gaGRsY190b19k ZXYoaGRsYyk7CglzdHJ1Y3QgcHBwX2NoYW5uZWwgKmNvbnN0IGNoYW4gPSBoZGxjX3RvX2NoYW4o aGRsYyk7CglpbnQgb2xkX210dSwgbmV3X210dTsKCWludCBlcnI7CgoJLyoKCSAqIFNhdmUgdGhl IG9sZCBNVFUgYW5kIHVzZSBvbmUgbW9yZSBhZGVxdWF0ZSBmb3IgUFBQLgoJICovCglvbGRfbXR1 ID0gZGV2LT5tdHU7CgoJLyogVHJ5IGFuIE1UVSBmb3IgYnJpZGdpbmcgRXRoZXJuZXQgZnJhbWVz LiAqLwoJbmV3X210dSA9IFBQUF9PVkVSSEVBRCArQkNQXzgwMl8zX0hEUkxFTiArIEVUSF9GUkFN RV9MRU4gKyBFVEhfRkNTX0xFTjsKCWlmIChkZXYtPm10dSA8IG5ld19tdHUpCgkJZGV2LT5jaGFu Z2VfbXR1KGRldiwgbmV3X210dSk7CgoJLyogSWYgdGhhdCBNVFUgZGlkbid0IHdvcmssIHRyeSBp dCB3aXRob3V0IHJvb20gZm9yIHRoZSBFdGhlcm5ldCBGQ1MsCgkgKiB3aGljaCBpcyBvcHRpb25h bCBmb3IgQkNQIGVuY2Fwc3VsYXRpb24uICovCgluZXdfbXR1IC09IEVUSF9GQ1NfTEVOOwoJaWYg KGRldi0+bXR1IDwgbmV3X210dSkKCQlkZXYtPmNoYW5nZV9tdHUoZGV2LCBuZXdfbXR1KTsKCgkv KiBJZiAqdGhhdCogZGlkbid0IHdvcmssIHRyeSB0aGUgZGVmYXVsdCBQUFAgTVRVLiAqLwoJbmV3 X210dSA9IFBQUF9PVkVSSEVBRCArIFBQUF9NVFU7CglpZiAoZGV2LT5tdHUgPCBuZXdfbXR1KQoJ CWRldi0+Y2hhbmdlX210dShkZXYsIG5ld19tdHUpOwoKCS8qIE1UVSBzaG91bGQgbm90IGJlIGNo YW5nZWQgd2hpbGUgUFBQIG1vZGUgaXMgaW4gZWZmZWN0LiAqLwoJaGRsYy0+bXR1X2xvY2tlZCA9 IDE7CgoJLyogcmVzZXQgdGhlIFBQUCBzdGF0ZSAqLwoJbWVtc2V0KCZoZGxjLT5zdGF0ZS5wcHAs IDAsIHNpemVvZihoZGxjLT5zdGF0ZS5wcHApKTsKCWNoYW4tPnByaXZhdGUgPSBoZGxjOwoJY2hh bi0+b3BzID0gJmhkbGNfZ2VucHBwX29wczsKCgkvKiBUaGUgY2hhbm5lbCBNVFUgaXMgdGhlIHVu ZGVybHlpbmcgSERMQyBNVFUgcmVkdWNlZCBieSB0aGUKCSAqIG92ZXJoZWFkIFBQUCByZXF1aXJl cy4KCSAqLwoJY2hhbi0+bXR1ID0gZGV2LT5tdHUgLSBQUFBfT1ZFUkhFQUQ7CgoJLyogY2hhbi0+ aGRybGVuIGlzIHRoZSBoZWFkcm9vbSB0aGUgZ2VuZXJpYyBQUFAgbGF5ZXIgd2lsbAoJICogcmVz ZXJ2ZSBvbiBidWZmZXJzIGl0IHNlbmRzIHRvIHRoaXMgZHJpdmVyLiAgV2UgbmVlZCBlbm91Z2gK CSAqIGZvciB0aGUgSERMQyBhZGRyZXNzIGFuZCBjb250cm9sIGJ5dGVzLiAqLwoJY2hhbi0+aGRy bGVuID0gMjsKCiAJLyogVGhlIHBwcF9jaGFubmVsIG9iamVjdCBtdXN0IGV4aXN0IGZyb20gdGhl IHRpbWUgdGhhdAoJICogcHBwX3JlZ2lzdGVyX2NoYW5uZWwoKSBpcyBjYWxsZWQgdW50aWwgYWZ0 ZXIgdGhlIGNhbGwgdG8KCSAqIHBwcF91bnJlZ2lzdGVyX2NoYW5uZWwoKSByZXR1cm5zLgoJICov CgllcnIgPSBwcHBfcmVnaXN0ZXJfY2hhbm5lbChjaGFuKTsKCWlmICghZXJyKQoJewoJCWhkbGMt Pm9wZW4gPSBOVUxMOwoJCWhkbGMtPnN0b3AgPSBOVUxMOwoJCWhkbGMtPnByb3RvX2RldGFjaCA9 IGhkbGNfcHBwX3VucmVnaXN0ZXI7CgkJaGRsYy0+bmV0aWZfcnggPSBoZGxjX3BwcF9uZXRpZl9y eDsKCQloZGxjLT50eXBlX3RyYW5zID0gTlVMTDsJLyogZm9yY2UgdXNlIG9mIG5ldGlmX3J4KCkg Ki8KCQloZGxjLT5wcm90byA9IElGX1BST1RPX1BQUDsKCgkJZGV2LT5oYXJkX3N0YXJ0X3htaXQg PSBoZGxjLT54bWl0OwoJCWRldi0+aGFyZF9oZWFkZXIgPSBOVUxMOwoJCWRldi0+dHlwZSA9IEFS UEhSRF9QUFA7CgkJZGV2LT5oYXJkX2hlYWRlcl9sZW4gPSAyOwoJCWRldi0+YWRkcl9sZW4gPSAx OwoJCWRldi0+YnJvYWRjYXN0WzBdID0gUFBQX0FMTFNUQVRJT05TOwoJCWRldi0+ZGV2X2FkZHJb MF0gPSAwOwkJLyogbm90IGltcG9ydGFudCBmb3IgUFBQICovCgoJCWhkbGMtPnN0YXRlLnBwcC5z ZXR0aW5ncy5jaGFubmVsID0KCQkJcHBwX2NoYW5uZWxfaW5kZXgoaGRsY190b19jaGFuKGhkbGMp KTsKCgkJZ290byBTdWNjZXNzOwoJfQoKCS8qIHJlc3RvcmUgb2xkIE1UVSAqLwoJaGRsYy0+bXR1 X2xvY2tlZCA9IDA7CglpZiAoZGV2LT5tdHUgIT0gb2xkX210dSkKCQlkZXYtPmNoYW5nZV9tdHUo ZGV2LCBvbGRfbXR1KTsKCiBTdWNjZXNzOgoJcmV0dXJuIGVycjsKfQoKCgovKioKICogQ2xvc2Ug dGhlIGNoYW5uZWwgdG8gdGhlIGdlbmVyaWMgUFBQIGxheWVyLgogKgogKiBoZGxjX3BwcF91bnJl Z2lzdGVyKCkgaXMgY2FsbGVkIGZyb20gcHJvY2VzcyBjb250ZXh0IHdoaWxlIHRoZQogKiBpbnRl cmZhY2UgaXMgZG93bi4KICovCnN0YXRpYyB2b2lkIGhkbGNfcHBwX3VucmVnaXN0ZXIoaGRsY19k ZXZpY2UgKmhkbGMpCnsKCXN0cnVjdCBwcHBfY2hhbm5lbCAqY29uc3QgY2hhbiA9IGhkbGNfdG9f Y2hhbihoZGxjKTsKCXN0cnVjdCBuZXRfZGV2aWNlICpjb25zdCBkZXYgPSBoZGxjX3RvX2Rldiho ZGxjKTsKCgkvKiBObyB0aHJlYWQgbWF5IGJlIGluIGEgY2FsbCB0byBhbnkgb2YgcHBwX2lucHV0 KCksCgkgKiBwcHBfaW5wdXRfZXJyb3IoKSwgcHBwX291dHB1dF93YWtldXAoKSwgcHBwX2NoYW5u ZWxfaW5kZXgoKQoJICogb3IgcHBwX3VuaXRfbnVtYmVyKCkgZm9yIGEgY2hhbm5lbCBhdCB0aGUg dGltZSB0aGF0CgkgKiBwcHBfdW5yZWdpc3Rlcl9jaGFubmVsKCkgaXMgY2FsbGVkIGZvciB0aGF0 IGNoYW5uZWwuCgkgKi8KCS8qIEJ5IHRoZSB0aW1lIGEgY2FsbCB0byBwcHBfdW5yZWdpc3Rlcl9j aGFubmVsKCkgcmV0dXJucywgbm8KCSAqIHRocmVhZCB3aWxsIGJlIGV4ZWN1dGluZyBpbiBhIGNh bGwgZnJvbSB0aGUgZ2VuZXJpYyBsYXllcgoJICogdG8gdGhhdCBjaGFubmVsJ3Mgc3RhcnRfeG1p dCgpIG9yIGlvY3RsKCkgZnVuY3Rpb24sIGFuZCB0aGUKCSAqIGdlbmVyaWMgbGF5ZXIgd2lsbCBu b3QgY2FsbCBlaXRoZXIgb2YgdGhvc2UgZnVuY3Rpb25zCgkgKiBzdWJzZXF1ZW50bHkuCgkgKi8K CXBwcF91bnJlZ2lzdGVyX2NoYW5uZWwoY2hhbik7CgoJaGRsYy0+bXR1X2xvY2tlZCA9IDA7Cglo ZGxjLT5zdGF0ZS5wcHAuc2V0dGluZ3MuY2hhbm5lbCA9IC0xOwoJZGV2LT5oYXJkX2hlYWRlcl9s ZW4gPSAxNjsKfQoKCgovKioKICogUmVjZWl2ZSBhIGJ1ZmZlciBmcm9tIHRoZSBoYXJkd2FyZSwg c3RyaXAgdGhlIFBQUCBoZWFkZXIsIGFuZCBwYXNzCiAqIHRoZSByZXN0IHRvIHRoZSBnZW5lcmlj IFBQUCBsYXllci4KICovCnN0YXRpYyB2b2lkIGhkbGNfcHBwX25ldGlmX3J4KHN0cnVjdCBza19i dWZmICpza2IpCnsKCXN0cnVjdCBwcHBfY2hhbm5lbCAqY29uc3QgY2hhbiA9IGhkbGNfdG9fY2hh bihkZXZfdG9faGRsYyhza2ItPmRldikpOwoJdW5zaWduZWQgY2hhciAqcDsKCgkvKiBzdHJpcCBh ZGRyZXNzL2NvbnRyb2wgZmllbGQgaWYgcHJlc2VudCAqLwoJcCA9IHNrYi0+ZGF0YTsKCWlmIChw WzBdID09IFBQUF9BTExTVEFUSU9OUyAmJiBwWzFdID09IFBQUF9VSSkgewoJCS8qIGNob3Agb2Zm IGFkZHJlc3MvY29udHJvbCAqLwoJCWlmIChza2ItPmxlbiA8IDMpCgkJCWdvdG8gZXJyOwoJCXAg PSBza2JfcHVsbChza2IsIDIpOwoJfQoKCS8qIGRlY29tcHJlc3MgcHJvdG9jb2wgZmllbGQgaWYg Y29tcHJlc3NlZCAqLwoJaWYgKHBbMF0gJiAxKSB7CgkJLyogcHJvdG9jb2wgaXMgY29tcHJlc3Nl ZCAqLwoJCXNrYl9wdXNoKHNrYiwgMSlbMF0gPSAwOwoJfSBlbHNlIGlmIChza2ItPmxlbiA8IDIp CgkJZ290byBlcnI7CgoJLyogcGFzcyB0byBnZW5lcmljIGxheWVyICovCglwcHBfaW5wdXQoY2hh biwgc2tiKTsKCXJldHVybjsKCiBlcnI6CglrZnJlZV9za2Ioc2tiKTsKCXBwcF9pbnB1dF9lcnJv cihjaGFuLCAwKTsKfQoKCgovKioKICogU2VuZCBhIHBhY2tldCAob3IgbXVsdGlsaW5rIGZyYWdt ZW50KSBvbiB0aGlzIGNoYW5uZWwuCiAqIFJldHVybnMgMSBpZiBpdCB3YXMgYWNjZXB0ZWQsIDAg dG8gcXVldWUgaXQgZm9yIGxhdGVyLgogKgogKiBUaGUgZ2VuZXJpYyBsYXllciB3aWxsIG5vdCBj YWxsIHRoZSBzdGFydF94bWl0KCkgZnVuY3Rpb24gZm9yIGEKICogY2hhbm5lbCB3aGlsZSBhbnkg dGhyZWFkIGlzIGFscmVhZHkgZXhlY3V0aW5nIGluIHRoYXQgZnVuY3Rpb24gZm9yCiAqIHRoYXQg Y2hhbm5lbC4KICoKICogVGhlIGdlbmVyaWMgbGF5ZXIgbWF5IGNhbGwgdGhlIGNoYW5uZWwgc3Rh cnRfeG1pdCgpIGZ1bmN0aW9uIGF0CiAqIHNvZnRpcnEvQkggbGV2ZWwgYnV0IHdpbGwgbm90IGNh bGwgaXQgYXQgaW50ZXJydXB0IGxldmVsLiAgVGh1cyB0aGUKICogc3RhcnRfeG1pdCgpIGZ1bmN0 aW9uIG1heSBub3QgYmxvY2suCiAqLwpzdGF0aWMgaW50IGhkbGNfZ2VucHBwX3N0YXJ0X3htaXQo c3RydWN0IHBwcF9jaGFubmVsICpjaGFuLAoJCQkJICBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQp7Cglo ZGxjX2RldmljZSAqY29uc3QgaGRsYyA9IGNoYW5fdG9faGRsYyhjaGFuKTsKCXN0cnVjdCBuZXRf ZGV2aWNlICpjb25zdCBkZXYgPSBoZGxjX3RvX2RldihoZGxjKTsKCWludCBwcm90bzsKCXVuc2ln bmVkIGNoYXIgKmRhdGE7CglpbnQgaXNsY3A7CgoJaWYgKCFuZXRpZl9nb29kX3RvX2dvKGRldikp IHsKCQkvKiogQHRvZG8gSW5zdGVhZCwgcmV0dXJuIDAgdG8gbWFrZSBnZW5lcmljIGxheWVyCgkJ ICogcXVldWUgdGhlIHBhY2tldC4gIFRoYXQgd2lsbCByZXF1aXJlIGNhbGxpbmcKCQkgKiBwcHBf b3V0cHV0X3dha2V1cCgpIGF0IGFuIGFwcHJvcHJpYXRlIHRpbWUuICovCgkJa2ZyZWVfc2tiKHNr Yik7CgkJKytoZGxjLT5zdGF0cy50eF9kcm9wcGVkOwoJCXJldHVybiAxOwoJfQoKCWRhdGEgID0g c2tiLT5kYXRhOwoJcHJvdG8gPSAoZGF0YVswXSA8PCA4KSArIGRhdGFbMV07CgoJLyogTENQIHBh Y2tldHMgd2l0aCBjb2RlcyBiZXR3ZWVuIDEgKGNvbmZpZ3VyZS1yZXF1ZXN0KQoJICogYW5kIDcg KGNvZGUtcmVqZWN0KSBtdXN0IGJlIHNlbnQgYXMgdGhvdWdoIG5vIG9wdGlvbnMKCSAqIGhhdmUg YmVlbiBuZWdvdGlhdGVkLgoJICovCglpc2xjcCA9IHByb3RvID09IFBQUF9MQ1AgJiYgMSA8PSBk YXRhWzJdICYmIGRhdGFbMl0gPD0gNzsKCgkvKiBjb21wcmVzcyBwcm90b2NvbCBmaWVsZCBpZiBv cHRpb24gZW5hYmxlZCAqLwoJaWYgKGRhdGFbMF0gPT0gMCAmJiAoaGRsYy0+c3RhdGUucHBwLmZs YWdzICYgU0NfQ09NUF9QUk9UKSAmJiAhaXNsY3ApCgkJc2tiX3B1bGwoc2tiLDEpOwoKCS8qIHBy ZXBlbmQgYWRkcmVzcy9jb250cm9sIGZpZWxkcyBpZiBuZWNlc3NhcnkgKi8KCWlmICgoaGRsYy0+ c3RhdGUucHBwLmZsYWdzICYgU0NfQ09NUF9BQykgPT0gMCB8fCBpc2xjcCkgewoJCWlmIChza2Jf aGVhZHJvb20oc2tiKSA8IDIpIHsKCQkJc3RydWN0IHNrX2J1ZmYgKm5wa3QgPSBkZXZfYWxsb2Nf c2tiKHNrYi0+bGVuICsgMik7CgkJCWlmIChucGt0ID09IE5VTEwpIHsKCQkJCWtmcmVlX3NrYihz a2IpOwoJCQkJKytoZGxjLT5zdGF0cy50eF9kcm9wcGVkOwoJCQkJcmV0dXJuIDE7CgkJCX0KCQkJ c2tiX3Jlc2VydmUobnBrdCwyKTsKCQkJbWVtY3B5KHNrYl9wdXQobnBrdCxza2ItPmxlbiksIHNr Yi0+ZGF0YSwgc2tiLT5sZW4pOwoJCQlrZnJlZV9za2Ioc2tiKTsKCQkJc2tiID0gbnBrdDsKCQl9 CgkJc2tiX3B1c2goc2tiLDIpOwoJCXNrYi0+ZGF0YVswXSA9IFBQUF9BTExTVEFUSU9OUzsKCQlz a2ItPmRhdGFbMV0gPSBQUFBfVUk7Cgl9CgoJc2tiLT5kZXYgPSBkZXY7Cglza2ItPm5oLnJhdyA9 IHNrYi0+ZGF0YTsKCglkZXZfcXVldWVfeG1pdChza2IpOwoJcmV0dXJuIDE7Cn0KCgoKLyoqCiAq IEhhbmRsZSBhbiBpb2N0bCBjYWxsIHRoYXQgaGFzIGNvbWUgaW4gdmlhIC9kZXYvcHBwLgogKgog KiBUaGUgZ2VuZXJpYyBsYXllciB3aWxsIG9ubHkgY2FsbCB0aGUgY2hhbm5lbCBpb2N0bCgpIGZ1 bmN0aW9uIGluCiAqIHByb2Nlc3MgY29udGV4dC4KICoKICogVGhlIGdlbmVyaWMgbGF5ZXIgd2ls bCBub3QgY2FsbCB0aGUgaW9jdGwoKSBmdW5jdGlvbiBmb3IgYSBjaGFubmVsCiAqIHdoaWxlIGFu eSB0aHJlYWQgaXMgYWxyZWFkeSBleGVjdXRpbmcgaW4gdGhhdCBmdW5jdGlvbiBmb3IgdGhhdAog KiBjaGFubmVsLgogKi8Kc3RhdGljIGludCBoZGxjX2dlbnBwcF9pb2N0bChzdHJ1Y3QgcHBwX2No YW5uZWwgKmNoYW4sCgkJCSAgICAgdW5zaWduZWQgaW50IGNtZCwgdW5zaWduZWQgbG9uZyBhcmcp CnsKCWhkbGNfZGV2aWNlICpjb25zdCBoZGxjID0gY2hhbl90b19oZGxjKGNoYW4pOwoJc3RydWN0 IG5ldF9kZXZpY2UgKmNvbnN0IGRldiA9IGhkbGNfdG9fZGV2KGhkbGMpOwoJaW50IHZhbDsKCWlu dCBlcnI7CgoJZXJyID0gLUVGQVVMVDsKCXN3aXRjaCAoY21kKSB7CgljYXNlIFBQUElPQ0dNUlU6 CgkJaWYgKHB1dF91c2VyKGRldi0+bXR1IC0gUFBQX09WRVJIRUFELCAoaW50ICopIGFyZykpCgkJ CWJyZWFrOwoJCWVyciA9IDA7CgkJYnJlYWs7CgoJY2FzZSBQUFBJT0NTTVJVOgoJCWlmIChnZXRf dXNlcih2YWwsIChpbnQgKikgYXJnKSkKCQkJYnJlYWs7CgoJCWlmICh2YWwgPiBkZXYtPm10dSAt IFBQUF9PVkVSSEVBRCkKCQkJZXJyID0gLUVJTlZBTDsKCQllbHNlCgkJCWVyciA9IDA7CgkJYnJl YWs7CgoJY2FzZSBQUFBJT0NTRkxBR1M6CgkJaWYgKGdldF91c2VyKHZhbCwgKGludCAqKSBhcmcp KQoJCQlicmVhazsKCQl2YWwgJj0gU0NfTUFTSzsJLyoga2VlcCB0aGUgYml0cyB0aGF0IGFyZSBh bGxvd2VkIHRvIGJlIHNldCAqLwoJCWhkbGMtPnN0YXRlLnBwcC5mbGFncyAmPSB+U0NfTUFTSzsK CQloZGxjLT5zdGF0ZS5wcHAuZmxhZ3MgfD0gdmFsOwoJCWVyciA9IDA7CgkJYnJlYWs7CgoJZGVm YXVsdDoKCQllcnIgPSAtRU5PVFRZOwoJfQoJcmV0dXJuIGVycjsKfQoKCgppbnQgaGRsY19wcHBf aW9jdGwoaGRsY19kZXZpY2UgKmhkbGMsIHN0cnVjdCBpZnJlcSAqaWZyKQp7CglzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2ID0gaGRsY190b19kZXYoaGRsYyk7CglpbnQgZXJyOwoKCXN3aXRjaCAoaWZy LT5pZnJfc2V0dGluZ3MudHlwZSkgewoJY2FzZSBJRl9HRVRfUFJPVE86CgkJaWZyLT5pZnJfc2V0 dGluZ3MudHlwZSA9IElGX1BST1RPX1BQUDsKCQlpZiAoaWZyLT5pZnJfc2V0dGluZ3Muc2l6ZSA8 IHNpemVvZihwcHBfcHJvdG8pKSB7CgkJCWlmci0+aWZyX3NldHRpbmdzLnNpemUgPSBzaXplb2Yo cHBwX3Byb3RvKTsKCQkJcmV0dXJuIC1FTk9CVUZTOwoJCX0KCQlpZiAoY29weV90b191c2VyKGlm ci0+aWZyX3NldHRpbmdzLmlmc19pZnN1LnBwcCwKCQkJCSAmaGRsYy0+c3RhdGUucHBwLnNldHRp bmdzLCBzaXplb2YocHBwX3Byb3RvKSkpCgkJCXJldHVybiAtRUZBVUxUOwoJCXJldHVybiAwOwoK CWNhc2UgSUZfUFJPVE9fUFBQOgoJCWlmKCFjYXBhYmxlKENBUF9ORVRfQURNSU4pKQoJCQlyZXR1 cm4gLUVQRVJNOwoKCQlpZihkZXYtPmZsYWdzICYgSUZGX1VQKQoJCQlyZXR1cm4gLUVCVVNZOwoK CQkvKiBubyBzZXR0YWJsZSBwYXJhbWV0ZXJzICovCgoJCWVyciA9IGhkbGMtPmF0dGFjaChoZGxj LCBFTkNPRElOR19OUlosUEFSSVRZX0NSQzE2X1BSMV9DQ0lUVCk7CgkJaWYgKCFlcnIpIHsKCQkJ aGRsY19wcm90b19kZXRhY2goaGRsYyk7CgkJCWVyciA9IGhkbGNfcHBwX3JlZ2lzdGVyKGhkbGMp OwoJCX0KCgkJcmV0dXJuIGVycjsKCX0KCglyZXR1cm4gLUVJTlZBTDsKfQo= ------_=_NextPart_001_01C4902D.D3F1B09D-- From davem@davemloft.net Wed Sep 1 13:37:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 13:38:01 -0700 (PDT) Received: from smtp109.mail.sc5.yahoo.com (smtp109.mail.sc5.yahoo.com [66.163.170.7]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i81Kbs8b005999 for ; Wed, 1 Sep 2004 13:37:54 -0700 Received: from unknown (HELO cheetah.davemloft.net) (davem?330@63.197.226.105 with login) by smtp109.mail.sc5.yahoo.com with SMTP; 1 Sep 2004 20:37:46 -0000 Date: Wed, 1 Sep 2004 13:37:09 -0700 From: "David S. Miller" To: Zhikui Chen Cc: hadi@cyberus.ca, dccp@ietf.org, netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: HELP for dccp implementation. Message-Id: <20040901133709.3637d63d.davem@davemloft.net> In-Reply-To: <4135A32A.4030901@rus.uni-stuttgart.de> References: <412CC269.8080907@rus.uni-stuttgart.de> <1093454747.1034.85.camel@jzny.localdomain> <4135A32A.4030901@rus.uni-stuttgart.de> Organization: DaveM Loft Enterprises X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 594 Lines: 14 On Wed, 01 Sep 2004 12:23:38 +0200 Zhikui Chen wrote: > If I assign a value such as 0x ee9fbc00 to sk in dccp_rcv (before lookup > calling), and comment lookkup calling, I get a error report from > bh_lock_sock(sk) calling inside dccp_rcv, which error report is > spin_is_locked on uninitialized spinlock ee9fbc00, and spin_lock > (:ee9fbc00) already locked by /73. > > Do you know its reason? Thanks, Zhikui, are you working together with Arnaldo using his code base, like we suggested to you? Or are you working still on your own code? From janitor@sternwelten.at Wed Sep 1 13:49:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 13:49:30 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81KnOW9006538 for ; Wed, 1 Sep 2004 13:49:25 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 087725C065; Wed, 1 Sep 2004 22:49:14 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19512-07; Wed, 1 Sep 2004 22:49:13 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id A22D75C008; Wed, 1 Sep 2004 22:49:13 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2c2d-00077g-Sz; Wed, 01 Sep 2004 22:49:15 +0200 Subject: [patch 1/1] remove old ifdefs dmascc To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 22:49:15 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 832 Lines: 28 Patches to remove some old ifdefs. remove most of the #include kill compat cruft like #define ahd_pci_set_dma_mask pci_set_dma_mask Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/hamradio/dmascc.c | 1 - 1 files changed, 1 deletion(-) diff -puN drivers/net/hamradio/dmascc.c~remove-old-ifdefs-dmascc drivers/net/hamradio/dmascc.c --- linux-2.6.9-rc1-bk7/drivers/net/hamradio/dmascc.c~remove-old-ifdefs-dmascc 2004-08-31 17:42:11.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/hamradio/dmascc.c 2004-08-31 17:42:11.000000000 +0200 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #include _ From janitor@sternwelten.at Wed Sep 1 14:03:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:13 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L372Z007121 for ; Wed, 1 Sep 2004 14:03:08 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id D225B5C065; Wed, 1 Sep 2004 23:02:57 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-06; Wed, 1 Sep 2004 23:02:57 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 3B3025C008; Wed, 1 Sep 2004 23:02:57 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cFv-0007nx-Fp; Wed, 01 Sep 2004 23:02:59 +0200 Subject: [patch 05/16] net/e100: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:02:59 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 2783 Lines: 93 I would appreciate any comments from the janitor@sternweltens list. This is one (of many) cases where I made a decision about replacing set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(some_time); with msleep(jiffies_to_msecs(some_time)); msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch. Thanks, Nish Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/e100.c | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-) diff -puN drivers/net/e100.c~msleep-drivers_net_e100 drivers/net/e100.c --- linux-2.6.9-rc1-bk7/drivers/net/e100.c~msleep-drivers_net_e100 2004-09-01 19:35:28.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/e100.c 2004-09-01 19:35:28.000000000 +0200 @@ -623,8 +623,7 @@ static int e100_self_test(struct nic *ni writel(selftest | dma_addr, &nic->csr->port); e100_write_flush(nic); /* Wait 10 msec for self-test to complete */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 100 + 1); + msleep(10); /* Interrupts are enabled after self-test */ e100_disable_irq(nic); @@ -672,8 +671,7 @@ static void e100_eeprom_write(struct nic e100_write_flush(nic); udelay(4); } /* Wait 10 msec for cmd to complete */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 100 + 1); + msleep(10); /* Chip deselect */ writeb(0, &nic->csr->eeprom_ctrl_lo); @@ -1758,8 +1756,7 @@ static int e100_loopback_test(struct nic memset(skb->data, 0xFF, ETH_DATA_LEN); e100_xmit_frame(skb, nic->netdev); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 100 + 1); + msleep(10); if(memcmp(nic->rx_to_clean->skb->data + sizeof(struct rfd), skb->data, ETH_DATA_LEN)) @@ -1845,8 +1842,7 @@ static void e100_get_regs(struct net_dev mdio_read(netdev, nic->mii.phy_id, i); memset(nic->mem->dump_buf, 0, sizeof(nic->mem->dump_buf)); e100_exec_cb(nic, NULL, e100_dump); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 100 + 1); + msleep(10); memcpy(&buff[2 + E100_PHY_REGS], nic->mem->dump_buf, sizeof(nic->mem->dump_buf)); } @@ -2020,8 +2016,7 @@ static int e100_phys_id(struct net_devic if(!data || data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ)) data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ); mod_timer(&nic->blink_timer, jiffies); - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(data * HZ); + msleep(data * 1000); del_timer_sync(&nic->blink_timer); mdio_write(netdev, nic->mii.phy_id, MII_LED_CONTROL, 0); _ From janitor@sternwelten.at Wed Sep 1 14:02:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:02:52 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L2j0l007089 for ; Wed, 1 Sep 2004 14:02:46 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id B08D95C065; Wed, 1 Sep 2004 23:02:35 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-04; Wed, 1 Sep 2004 23:02:35 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 3C3265C008; Wed, 1 Sep 2004 23:02:35 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cFZ-0007l7-Gh; Wed, 01 Sep 2004 23:02:37 +0200 Subject: [patch 01/16] __FUNCTION__ string concatenation To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:02:37 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1608 Lines: 43 I've replaced the __FUNCTION__ string concatenation with the %s placeholder and a printf parameter in drivers/net/wireless/prism65/islpci_mgt.h, as suggested in the TODO list. I don't have the hardware to do a run-time check. It should not pose any problems though. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/07/04 22:08:37+02:00 drizzd@aon.at # __FUNCTION__ string concatenation is deprecated # # drivers/net/wireless/prism54/islpci_mgt.h # 2004/07/03 17:18:20+02:00 drizzd@aon.at +1 -1 # __FUNCTION__ string concatenation is deprecated # Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/wireless/prism54/islpci_mgt.h | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/wireless/prism54/islpci_mgt.h~printk-net_wireless_prism54_islpci_mgt.h drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.6.9-rc1-bk7/drivers/net/wireless/prism54/islpci_mgt.h~printk-net_wireless_prism54_islpci_mgt.h 2004-09-01 19:34:23.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/wireless/prism54/islpci_mgt.h 2004-09-01 19:34:23.000000000 +0200 @@ -31,7 +31,7 @@ #define K_DEBUG(f, m, args...) do { if(f & m) printk(KERN_DEBUG args); } while(0) #define DEBUG(f, args...) K_DEBUG(f, pc_debug, args) -#define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> " __FUNCTION__ "()\n", devname) +#define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> %s()\n", devname, __FUNCTION__) extern int pc_debug; #define init_wds 0 /* help compiler optimize away dead code */ _ From janitor@sternwelten.at Wed Sep 1 14:02:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:02:57 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L2pwo007095 for ; Wed, 1 Sep 2004 14:02:51 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 2E21D5C066; Wed, 1 Sep 2004 23:02:41 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-04; Wed, 1 Sep 2004 23:02:40 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id AEE925C008; Wed, 1 Sep 2004 23:02:40 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cFf-0007lp-03; Wed, 01 Sep 2004 23:02:43 +0200 Subject: [patch 02/16] net/3c505: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:02:42 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1440 Lines: 51 I would appreciate any comments from the janitor@sternweltens list. Thanks, Nish Description: Uses msleep() instead of schedule_timeout() so the task is guaranteed to delay the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/3c505.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff -puN drivers/net/3c505.c~msleep-drivers_net_3c505 drivers/net/3c505.c --- linux-2.6.9-rc1-bk7/drivers/net/3c505.c~msleep-drivers_net_3c505 2004-09-01 19:35:25.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/3c505.c 2004-09-01 19:35:25.000000000 +0200 @@ -1327,8 +1327,7 @@ static int __init elp_sense(struct net_d if (orig_HSR & DIR) { /* If HCR.DIR is up, we pull it down. HSR.DIR should follow. */ outb(0, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (inb_status(addr) & DIR) { if (elp_debug > 0) printk(notfound_msg, 2); @@ -1337,8 +1336,7 @@ static int __init elp_sense(struct net_d } else { /* If HCR.DIR is down, we pull it up. HSR.DIR should follow. */ outb(DIR, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (!(inb_status(addr) & DIR)) { if (elp_debug > 0) printk(notfound_msg, 3); _ From janitor@sternwelten.at Wed Sep 1 14:02:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:01 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L2ukq007103 for ; Wed, 1 Sep 2004 14:02:57 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id ABB7B5C066; Wed, 1 Sep 2004 23:02:46 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-05; Wed, 1 Sep 2004 23:02:46 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 3FC3C5C008; Wed, 1 Sep 2004 23:02:46 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cFk-0007mX-Fq; Wed, 01 Sep 2004 23:02:48 +0200 Subject: [patch 03/16] net/appletalk: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:02:48 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1299 Lines: 51 I would appreciate any comments from the janitor@sternweltens list. Thanks, Nish Description: Uses msleep() instead of schedule_timeout() so the task is guaranteed to delay the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/appletalk/ltpc.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff -puN drivers/net/appletalk/ltpc.c~msleep-drivers_net_appletalk_ltpc drivers/net/appletalk/ltpc.c --- linux-2.6.9-rc1-bk7/drivers/net/appletalk/ltpc.c~msleep-drivers_net_appletalk_ltpc 2004-09-01 19:35:26.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/appletalk/ltpc.c 2004-09-01 19:35:26.000000000 +0200 @@ -1109,8 +1109,7 @@ struct net_device * __init ltpc_probe(vo inb_p(io+1); inb_p(io+3); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(2*HZ/100); + msleep(20); inb_p(io+0); inb_p(io+2); @@ -1120,8 +1119,7 @@ struct net_device * __init ltpc_probe(vo inb_p(io+5); /* enable dma */ inb_p(io+6); /* tri-state interrupt line */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ); + msleep(1000); /* now, figure out which dma channel we're using, unless it's already been specified */ _ From janitor@sternwelten.at Wed Sep 1 14:03:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:07 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L32RC007113 for ; Wed, 1 Sep 2004 14:03:02 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 376FC5C066; Wed, 1 Sep 2004 23:02:52 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-05; Wed, 1 Sep 2004 23:02:51 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id BDA2B5C008; Wed, 1 Sep 2004 23:02:51 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cFp-0007nF-Vx; Wed, 01 Sep 2004 23:02:54 +0200 Subject: [patch 04/16] net/cs89x0: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:02:53 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1375 Lines: 52 I would appreciate any comments from the janitor@sternweltens list. This is one (of many) cases where I made a decision about replacing set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(some_time); with msleep(jiffies_to_msecs(some_time)); msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch. Thanks, Nish Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/cs89x0.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/cs89x0.c~msleep-drivers_net_cs89x0 drivers/net/cs89x0.c --- linux-2.6.9-rc1-bk7/drivers/net/cs89x0.c~msleep-drivers_net_cs89x0 2004-09-01 19:35:27.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/cs89x0.c 2004-09-01 19:35:27.000000000 +0200 @@ -891,8 +891,7 @@ void __init reset_chip(struct net_devic writereg(dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | POWER_ON_RESET); /* wait 30 ms */ - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(30*HZ/1000); + msleep(30); if (lp->chip_type != CS8900) { /* Hardware problem requires PNP registers to be reconfigured after a reset */ _ From janitor@sternwelten.at Wed Sep 1 14:03:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:18 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3DOU007127 for ; Wed, 1 Sep 2004 14:03:13 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 2D9985C067; Wed, 1 Sep 2004 23:03:03 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-06; Wed, 1 Sep 2004 23:03:02 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id AA7EE5C008; Wed, 1 Sep 2004 23:03:02 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cG0-0007of-Vj; Wed, 01 Sep 2004 23:03:05 +0200 Subject: [patch 06/16] net/e1000_osdep: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:04 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1764 Lines: 59 On Tue, Jul 27, 2004 at 04:00:52AM +0100, Matthew Wilcox wrote: > On Mon, Jul 26, 2004 at 05:00:01PM -0700, Nishanth Aravamudan wrote: > > I would appreciate any comments from the janitor@sternweltens list. > > > > > > > > Description: Replace schedule_timeout() with msleep() to guarantee the > > task delays for the desired time. > > } else { \ > > - set_current_state(TASK_UNINTERRUPTIBLE); \ > > - schedule_timeout((x * HZ)/1000 + 2); \ > > + msleep(x); \ > > } } while(0) > > Looks much better than the previous code. It's actually possible to do > better, though. Simply change to: > > #define msec_delay(x) msleep(x) > > If msleep() ends up scheduling, the bad attempt to sleep will be caught > by schedule(). There's no need to do the check in the driver. Thanks for the tip and here is this change: Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/e1000/e1000_osdep.h | 8 +------- 1 files changed, 1 insertion(+), 7 deletions(-) diff -puN drivers/net/e1000/e1000_osdep.h~msleep-drivers_net_e1000_osdep drivers/net/e1000/e1000_osdep.h --- linux-2.6.9-rc1-bk7/drivers/net/e1000/e1000_osdep.h~msleep-drivers_net_e1000_osdep 2004-09-01 19:35:28.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/e1000/e1000_osdep.h 2004-09-01 19:35:28.000000000 +0200 @@ -42,13 +42,7 @@ #include #ifndef msec_delay -#define msec_delay(x) do { if(in_interrupt()) { \ - /* Don't mdelay in interrupt context! */ \ - BUG(); \ - } else { \ - set_current_state(TASK_UNINTERRUPTIBLE); \ - schedule_timeout((x * HZ)/1000 + 2); \ - } } while(0) +#define msec_delay(x) msleep(x) #endif #define PCI_COMMAND_REGISTER PCI_COMMAND _ From janitor@sternwelten.at Wed Sep 1 14:03:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:23 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3Ivw007137 for ; Wed, 1 Sep 2004 14:03:19 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 9FFA55C068; Wed, 1 Sep 2004 23:03:08 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-07; Wed, 1 Sep 2004 23:03:08 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 3C4ED5C008; Wed, 1 Sep 2004 23:03:08 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cG6-0007pN-FM; Wed, 01 Sep 2004 23:03:10 +0200 Subject: [patch 07/16] net/ewrk3: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:10 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 938 Lines: 37 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/ewrk3.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/ewrk3.c~msleep-drivers_net_ewrk3 drivers/net/ewrk3.c --- linux-2.6.9-rc1-bk7/drivers/net/ewrk3.c~msleep-drivers_net_ewrk3 2004-09-01 19:35:29.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/ewrk3.c 2004-09-01 19:35:29.000000000 +0200 @@ -1681,8 +1681,7 @@ static int ewrk3_ethtool_ioctl(struct ne /* Wait a little while */ spin_unlock_irqrestore(&lp->hw_lock, flags); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ>>2); + msleep(250); spin_lock_irqsave(&lp->hw_lock, flags); /* Exit if we got a signal */ _ From janitor@sternwelten.at Wed Sep 1 14:03:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:29 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3ObA007145 for ; Wed, 1 Sep 2004 14:03:24 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 67CE25C066; Wed, 1 Sep 2004 23:03:14 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-07; Wed, 1 Sep 2004 23:03:14 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id B790E5C008; Wed, 1 Sep 2004 23:03:13 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGB-0007q6-VQ; Wed, 01 Sep 2004 23:03:16 +0200 Subject: [patch 08/16] net/gt96100eth: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:15 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 3299 Lines: 109 I would appreciate any comments from the janitor@sternweltens list. This is one (of many) cases where I made a decision about replacing set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(some_time); with msleep(jiffies_to_msecs(some_time)); msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch. Thanks, Nish PS. In this patch, the last delay is a bit confusing. It, in code, delayed for 1 msec, but the comment said 20 msecs, does anyone know which it should be? Description: Replace gt96100_delay() with msleep() to guarantee the task delays for the desired time. Remove the definition of gt96100_delay(). Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/gt96100eth.c | 19 ++++--------------- 1 files changed, 4 insertions(+), 15 deletions(-) diff -puN drivers/net/gt96100eth.c~msleep-drivers_net_gt96100eth drivers/net/gt96100eth.c --- linux-2.6.9-rc1-bk7/drivers/net/gt96100eth.c~msleep-drivers_net_gt96100eth 2004-09-01 19:35:29.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/gt96100eth.c 2004-09-01 19:35:29.000000000 +0200 @@ -59,7 +59,6 @@ // prototypes static void* dmaalloc(size_t size, dma_addr_t *dma_handle); static void dmafree(size_t size, void *vaddr); -static void gt96100_delay(int msec); static int gt96100_add_hash_entry(struct net_device *dev, unsigned char* addr); static void read_mib_counters(struct gt96100_private *gp); @@ -183,16 +182,6 @@ static void dmafree(size_t size, void *v free_pages((unsigned long)vaddr, get_order(size)); } -static void gt96100_delay(int ms) -{ - if (in_interrupt()) - return; - else { - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(ms*HZ/1000); - } -} - static int parse_mac_addr(struct net_device *dev, char* macstr) { @@ -238,7 +227,7 @@ read_MII(int phy_addr, u32 reg) // wait for last operation to complete while (GT96100_READ(GT96100_ETH_SMI_REG) & smirBusy) { // snooze for 1 msec and check again - gt96100_delay(1); + msleep(1); if (--timedout == 0) { printk(KERN_ERR "%s: busy timeout!!\n", __FUNCTION__); @@ -252,7 +241,7 @@ read_MII(int phy_addr, u32 reg) // wait for read to complete while (!((smir = GT96100_READ(GT96100_ETH_SMI_REG)) & smirReadValid)) { // snooze for 1 msec and check again - gt96100_delay(1); + msleep(1); if (--timedout == 0) { printk(KERN_ERR "%s: timeout!!\n", __FUNCTION__); @@ -304,7 +293,7 @@ write_MII(int phy_addr, u32 reg, u16 dat // wait for last operation to complete while (GT96100_READ(GT96100_ETH_SMI_REG) & smirBusy) { // snooze for 1 msec and check again - gt96100_delay(1); + msleep(1); if (--timedout == 0) { printk(KERN_ERR "%s: busy timeout!!\n", __FUNCTION__); @@ -528,7 +517,7 @@ abort(struct net_device *dev, u32 abort_ // wait for abort to complete while (GT96100ETH_READ(gp, GT96100_ETH_SDMA_COMM) & abort_bits) { // snooze for 20 msec and check again - gt96100_delay(1); + msleep(20); // was gt96100_delay(1) -> should it be 20 or 1? if (--timedout == 0) { err("%s: timeout!!\n", __FUNCTION__); _ From janitor@sternwelten.at Wed Sep 1 14:03:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:35 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3UFA007155 for ; Wed, 1 Sep 2004 14:03:30 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 16B385C065; Wed, 1 Sep 2004 23:03:20 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-08; Wed, 1 Sep 2004 23:03:19 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 407E75C008; Wed, 1 Sep 2004 23:03:19 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGH-0007qo-Fw; Wed, 01 Sep 2004 23:03:21 +0200 Subject: [patch 09/16] ixgb/ixgb_osdep: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:21 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1197 Lines: 44 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Redefine msec_delay(x) to directly call msleep(x). Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/ixgb/ixgb_osdep.h | 8 +------- 1 files changed, 1 insertion(+), 7 deletions(-) diff -puN drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_osdep drivers/net/ixgb/ixgb_osdep.h --- linux-2.6.9-rc1-bk7/drivers/net/ixgb/ixgb_osdep.h~msleep-drivers_net_ixgb_osdep 2004-09-01 19:35:34.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/ixgb/ixgb_osdep.h 2004-09-01 19:35:34.000000000 +0200 @@ -41,13 +41,7 @@ #include #ifndef msec_delay -#define msec_delay(x) do { if(in_interrupt()) { \ - /* Don't mdelay in interrupt context! */ \ - BUG(); \ - } else { \ - set_current_state(TASK_UNINTERRUPTIBLE); \ - schedule_timeout((x * HZ)/1000 + 2); \ - } } while(0) +#define msec_delay(x) msleep(x) #endif #define PCI_COMMAND_REGISTER PCI_COMMAND _ From janitor@sternwelten.at Wed Sep 1 14:03:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:39 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3Z0C007170 for ; Wed, 1 Sep 2004 14:03:35 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 209A35C065; Wed, 1 Sep 2004 23:03:25 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-08; Wed, 1 Sep 2004 23:03:24 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id A468B5C008; Wed, 1 Sep 2004 23:03:24 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGN-0007rW-0B; Wed, 01 Sep 2004 23:03:27 +0200 Subject: [patch 10/16] net/mac89x0: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:26 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1387 Lines: 53 I would appreciate any comments from the janitor@sternweltens list. This is one (of many) cases where I made a decision about replacing set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(some_time); with msleep(jiffies_to_msecs(some_time)); msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch. Thanks, Nish Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/mac89x0.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/mac89x0.c~msleep-drivers_net_max89x0 drivers/net/mac89x0.c --- linux-2.6.9-rc1-bk7/drivers/net/mac89x0.c~msleep-drivers_net_max89x0 2004-09-01 19:35:34.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/mac89x0.c 2004-09-01 19:35:34.000000000 +0200 @@ -308,8 +308,7 @@ void __init reset_chip(struct net_device writereg(dev, PP_SelfCTL, readreg(dev, PP_SelfCTL) | POWER_ON_RESET); /* wait 30 ms */ - current->state = TASK_INTERRUPTIBLE; - schedule_timeout(30*HZ/1000); + msleep(30); /* Wait until the chip is reset */ reset_start_time = jiffies; _ From janitor@sternwelten.at Wed Sep 1 14:03:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:46 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3ej7007189 for ; Wed, 1 Sep 2004 14:03:41 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 8A3A25C065; Wed, 1 Sep 2004 23:03:30 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-09; Wed, 1 Sep 2004 23:03:30 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 2119F5C008; Wed, 1 Sep 2004 23:03:30 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGS-0007sE-Ej; Wed, 01 Sep 2004 23:03:32 +0200 Subject: [patch 11/16] net/ni65: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:32 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1021 Lines: 38 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/ni65.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/ni65.c~msleep-drivers_net_ni65 drivers/net/ni65.c --- linux-2.6.9-rc1-bk7/drivers/net/ni65.c~msleep-drivers_net_ni65 2004-09-01 19:35:35.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/ni65.c 2004-09-01 19:35:35.000000000 +0200 @@ -526,8 +526,7 @@ static int __init ni65_probe1(struct net ni65_init_lance(p,dev->dev_addr,0,0); irq_mask = probe_irq_on(); writereg(CSR0_INIT|CSR0_INEA,CSR0); /* trigger interrupt */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ/50); + msleep(20); dev->irq = probe_irq_off(irq_mask); if(!dev->irq) { _ From janitor@sternwelten.at Wed Sep 1 14:03:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:03:52 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3kMm007301 for ; Wed, 1 Sep 2004 14:03:46 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 0C0875C065; Wed, 1 Sep 2004 23:03:36 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-09; Wed, 1 Sep 2004 23:03:35 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 96E9C5C008; Wed, 1 Sep 2004 23:03:35 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGX-0007sw-WC; Wed, 01 Sep 2004 23:03:38 +0200 Subject: [patch 12/16] net/ns83820: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:37 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1220 Lines: 45 On Tue, Jul 27, 2004 at 02:34:08PM -0400, Benjamin LaHaise wrote: > The commit message doesn't seem correspond to the actual patch. What > are you trying to "fix"? Thanks for catching this - it was another typo. Please find the corrected patch below. -Nish Description: Uses msleep() instead of schedule_timeout() to guarantee the task delays the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/ns83820.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/ns83820.c~msleep-drivers_net_ns83820 drivers/net/ns83820.c --- linux-2.6.9-rc1-bk7/drivers/net/ns83820.c~msleep-drivers_net_ns83820 2004-09-01 19:35:35.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/ns83820.c 2004-09-01 19:35:35.000000000 +0200 @@ -1960,8 +1960,7 @@ static int __devinit ns83820_init_one(st if (reset_phy) { printk(KERN_INFO "%s: resetting phy\n", ndev->name); writel(dev->CFG_cache | CFG_PHY_RST, dev->base + CFG); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout((HZ+99)/100); + msleep(10); writel(dev->CFG_cache, dev->base + CFG); } _ From janitor@sternwelten.at Wed Sep 1 14:03:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:04:00 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3qlf007420 for ; Wed, 1 Sep 2004 14:03:52 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id ED3A75C065; Wed, 1 Sep 2004 23:03:41 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19160-10; Wed, 1 Sep 2004 23:03:41 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 1A0BB5C008; Wed, 1 Sep 2004 23:03:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGd-0007te-EC; Wed, 01 Sep 2004 23:03:43 +0200 Subject: [patch 13/16] net/s2io.c: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:43 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 4651 Lines: 176 I would appreciate any comments from the janitor@sternweltens list. Description: Use msleep() instead of schedule_timeout() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/s2io.c | 45 +++++++++-------------------- 1 files changed, 15 insertions(+), 30 deletions(-) diff -puN drivers/net/s2io.c~msleep-drivers_net_s2io drivers/net/s2io.c --- linux-2.6.9-rc1-bk7/drivers/net/s2io.c~msleep-drivers_net_s2io 2004-09-01 19:35:36.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/s2io.c 2004-09-01 19:35:36.000000000 +0200 @@ -555,8 +555,7 @@ static int initNic(struct s2io_nic *nic) val64 = 0; writeq(val64, &bar0->sw_reset); val64 = readq(&bar0->sw_reset); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 2); + msleep(500); /* Enable Receiving broadcasts */ val64 = readq(&bar0->mac_cfg); @@ -803,8 +802,7 @@ static int initNic(struct s2io_nic *nic) dev->name); return -1; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); time++; } @@ -838,8 +836,7 @@ static int initNic(struct s2io_nic *nic) return -1; } time++; - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); } /* Initializing proper values as Pause threshold into all @@ -1182,8 +1179,7 @@ static int startNic(struct s2io_nic *nic writeq(val64, &bar0->mc_rldram_mrs); val64 = readq(&bar0->mc_rldram_mrs); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); /* Delay by around 100 ms. */ + msleep(100); /* Enabling ECC Protection. */ val64 = readq(&bar0->adapter_control); @@ -1891,8 +1887,7 @@ int waitForCmdComplete(nic_t * sp) ret = SUCCESS; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); if (cnt++ > 10) break; } @@ -1931,15 +1926,13 @@ void s2io_reset(nic_t * sp) * As of now I'am just giving a 250ms delay and hoping that the * PCI write to sw_reset register is done by this time. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 4); + msleep(250); /* Restore the PCI state saved during initializarion. */ pci_restore_state(sp->pdev, sp->config_space); s2io_init_pci(sp); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 4); + msleep(250); /* SXE-002: Configure link and activity LED to turn it off */ subid = sp->pdev->subsystem_device; @@ -2157,8 +2150,7 @@ int s2io_close(struct net_device *dev) /* If the device tasklet is running, wait till its done before killing it */ while (atomic_read(&(sp->tasklet_status))) { - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); + msleep(100); } tasklet_kill(&sp->task); @@ -2169,8 +2161,7 @@ int s2io_close(struct net_device *dev) break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); cnt++; if (cnt == 10) { DBG_PRINT(ERR_DBG, @@ -2943,8 +2934,7 @@ static u32 readEeprom(nic_t * sp, int of data = I2C_CONTROL_GET_DATA(val64); break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); exit_cnt++; } @@ -2983,8 +2973,7 @@ static int writeEeprom(nic_t * sp, int o ret = 0; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 20); + msleep(50); exit_cnt++; } @@ -3256,8 +3245,7 @@ static int s2io_bistTest(nic_t * sp, uin ret = 0; break; } - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); + msleep(100); cnt++; } @@ -3356,8 +3344,7 @@ static int s2io_rldramTest(nic_t * sp, u val64 = readq(&bar0->mc_rldram_test_ctrl); if (val64 & MC_RLDRAM_TEST_DONE) break; - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 5); + msleep(200); } if (cnt == 5) @@ -3373,8 +3360,7 @@ static int s2io_rldramTest(nic_t * sp, u val64 = readq(&bar0->mc_rldram_test_ctrl); if (val64 & MC_RLDRAM_TEST_DONE) break; - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 2); + msleep(500); } if (cnt == 5) @@ -3711,8 +3697,7 @@ static void s2io_set_link(unsigned long /* Allow a small delay for the NICs self initiated * cleanup to complete. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ / 10); + msleep(100); val64 = readq(&bar0->adapter_status); if (verify_xena_quiescence(val64, nic->device_enabled_once)) { _ From janitor@sternwelten.at Wed Sep 1 14:03:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:04:06 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L3vCR007517 for ; Wed, 1 Sep 2004 14:03:58 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 122495C066; Wed, 1 Sep 2004 23:03:47 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26133-10; Wed, 1 Sep 2004 23:03:46 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 930D85C008; Wed, 1 Sep 2004 23:03:46 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGi-0007uM-UH; Wed, 01 Sep 2004 23:03:49 +0200 Subject: [patch 14/16] net/ibmtr: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:48 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1505 Lines: 50 On Tue, Jul 27, 2004 at 01:43:32PM -0700, Nishanth Aravamudan wrote: > I would appreciate any comments from the janitor@sternweltens list. > > > > Description: Use msleep() instead of schedule_timeout() to guarantee > the task delays for the desired time. > > Signed-off-by: Nishanth Aravamudan The previous patch introduced extraneous whitespace, sorry. Thanks, Domen. Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/tokenring/ibmtr.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/tokenring/ibmtr.c~msleep-drivers_net_tokenring_ibmtr drivers/net/tokenring/ibmtr.c --- linux-2.6.9-rc1-bk7/drivers/net/tokenring/ibmtr.c~msleep-drivers_net_tokenring_ibmtr 2004-09-01 19:35:37.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/tokenring/ibmtr.c 2004-09-01 19:35:37.000000000 +0200 @@ -108,6 +108,7 @@ in the event that chatty debug messages #define IBMTR_DEBUG_MESSAGES 0 #include +#include #ifdef PCMCIA /* required for ibmtr_cs.c to build */ #undef MODULE /* yes, really */ @@ -858,8 +859,7 @@ static int tok_init_card(struct net_devi writeb(~INT_ENABLE, ti->mmio + ACA_OFFSET + ACA_RESET + ISRP_EVEN); outb(0, PIOaddr + ADAPTRESET); - current->state=TASK_UNINTERRUPTIBLE; - schedule_timeout(TR_RST_TIME); /* wait 50ms */ + msleep(jiffies_to_msecs(TR_RST_TIME)); outb(0, PIOaddr + ADAPTRESETREL); #ifdef ENABLE_PAGING _ From janitor@sternwelten.at Wed Sep 1 14:04:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:04:12 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L42Bn007682 for ; Wed, 1 Sep 2004 14:04:03 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id A9D0C5C067; Wed, 1 Sep 2004 23:03:52 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01102-01; Wed, 1 Sep 2004 23:03:52 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 262A35C008; Wed, 1 Sep 2004 23:03:52 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGo-0007v4-E1; Wed, 01 Sep 2004 23:03:54 +0200 Subject: [patch 15/16] tulip/de2104x: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:54 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 997 Lines: 38 I would appreciate any comments from the janitor@sternweltens list. Description: Use msleep() instead of schedule_timeout() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/tulip/de2104x.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/tulip/de2104x.c~msleep-drivers_net_tulip_de2104x drivers/net/tulip/de2104x.c --- linux-2.6.9-rc1-bk7/drivers/net/tulip/de2104x.c~msleep-drivers_net_tulip_de2104x 2004-09-01 19:35:38.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/tulip/de2104x.c 2004-09-01 19:35:38.000000000 +0200 @@ -1208,8 +1208,7 @@ static void de_adapter_wake (struct de_p pci_write_config_dword(de->pdev, PCIPM, pmctl); /* de4x5.c delays, so we do too */ - current->state = TASK_UNINTERRUPTIBLE; - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); } } _ From janitor@sternwelten.at Wed Sep 1 14:04:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:04:17 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L48SU007823 for ; Wed, 1 Sep 2004 14:04:09 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 85B5F5C008; Wed, 1 Sep 2004 23:03:58 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01102-02; Wed, 1 Sep 2004 23:03:58 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id A00B65C068; Wed, 1 Sep 2004 23:03:57 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cGt-0007vm-Tz; Wed, 01 Sep 2004 23:04:00 +0200 Subject: [patch 16/16] parport/ieee1284_ops: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:03:59 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1477 Lines: 53 I would appreciate any comments from the janitor@sternweltens list. This is one (of many) cases where I made a decision about replacing set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(some_time); with msleep(jiffies_to_msecs(some_time)); msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch. Thanks, Nish Description: Uses msleep() instead of schedule_timeout() to guarantee the task delays the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/parport/ieee1284_ops.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/parport/ieee1284_ops.c~msleep-drivers_parport_ieee1284_ops drivers/parport/ieee1284_ops.c --- linux-2.6.9-rc1-bk7/drivers/parport/ieee1284_ops.c~msleep-drivers_parport_ieee1284_ops 2004-09-01 19:35:41.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/parport/ieee1284_ops.c 2004-09-01 19:35:41.000000000 +0200 @@ -542,8 +542,7 @@ size_t parport_ieee1284_ecp_read_data (s /* Yield the port for a while. */ if (count && dev->port->irq != PARPORT_IRQ_NONE) { parport_release (dev); - __set_current_state (TASK_INTERRUPTIBLE); - schedule_timeout ((HZ + 24) / 25); + msleep(40); parport_claim_or_block (dev); } else _ From janitor@sternwelten.at Wed Sep 1 14:05:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:05:42 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L5Vfm009733 for ; Wed, 1 Sep 2004 14:05:32 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id D4AB75C065; Wed, 1 Sep 2004 23:05:21 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01102-06; Wed, 1 Sep 2004 23:05:21 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 6BB3A5C008; Wed, 1 Sep 2004 23:05:21 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIF-0007yy-Lb; Wed, 01 Sep 2004 23:05:23 +0200 Subject: [patch 1/8] irda/act200l-sir: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:23 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1050 Lines: 38 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/irda/act200l-sir.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/irda/act200l-sir.c~msleep-drivers_net_irda_act200l-sir drivers/net/irda/act200l-sir.c --- linux-2.6.9-rc1-bk7/drivers/net/irda/act200l-sir.c~msleep-drivers_net_irda_act200l-sir 2004-09-01 19:35:31.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/irda/act200l-sir.c 2004-09-01 19:35:31.000000000 +0200 @@ -177,8 +177,7 @@ static int act200l_change_speed(struct s /* Write control bytes */ sirdev_raw_write(dev, control, 3); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(5)); + msleep(5); /* Go back to normal mode */ sirdev_set_dtr_rts(dev, TRUE, TRUE); _ From janitor@sternwelten.at Wed Sep 1 14:05:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:05:44 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L5cWq009866 for ; Wed, 1 Sep 2004 14:05:38 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id AA92C5C066; Wed, 1 Sep 2004 23:05:27 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04663-06; Wed, 1 Sep 2004 23:05:27 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id E40355C008; Wed, 1 Sep 2004 23:05:26 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIL-0007zg-5D; Wed, 01 Sep 2004 23:05:29 +0200 Subject: [patch 2/8] irda/irtty-sir: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:28 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1258 Lines: 49 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/irda/irtty-sir.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff -puN drivers/net/irda/irtty-sir.c~msleep-drivers_net_irda_irtty-sir drivers/net/irda/irtty-sir.c --- linux-2.6.9-rc1-bk7/drivers/net/irda/irtty-sir.c~msleep-drivers_net_irda_irtty-sir 2004-09-01 19:35:31.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/irda/irtty-sir.c 2004-09-01 19:35:31.000000000 +0200 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -96,10 +97,8 @@ static void irtty_wait_until_sent(struct tty->driver->wait_until_sent(tty, msecs_to_jiffies(100)); unlock_kernel(); } - else { - set_task_state(current, TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(USBSERIAL_TX_DONE_DELAY)); - } + else + msleep(USBSERIAL_TX_DONE_DELAY); } /* _ From janitor@sternwelten.at Wed Sep 1 14:05:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:05:56 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L5mv8010060 for ; Wed, 1 Sep 2004 14:05:48 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 5E4395C068; Wed, 1 Sep 2004 23:05:38 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04663-07; Wed, 1 Sep 2004 23:05:38 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id E49035C008; Wed, 1 Sep 2004 23:05:37 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIW-000816-6g; Wed, 01 Sep 2004 23:05:40 +0200 Subject: [patch 4/8] irda/sir_dev: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:39 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1317 Lines: 46 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/irda/sir_dev.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/irda/sir_dev.c~msleep-drivers_net_irda_sir_dev drivers/net/irda/sir_dev.c --- linux-2.6.9-rc1-bk7/drivers/net/irda/sir_dev.c~msleep-drivers_net_irda_sir_dev 2004-09-01 19:35:32.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/irda/sir_dev.c 2004-09-01 19:35:32.000000000 +0200 @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -73,8 +74,7 @@ int sirdev_raw_write(struct sir_dev *dev spin_lock_irqsave(&dev->tx_lock, flags); /* serialize with other tx operations */ while (dev->tx_buff.len > 0) { /* wait until tx idle */ spin_unlock_irqrestore(&dev->tx_lock, flags); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); spin_lock_irqsave(&dev->tx_lock, flags); } _ From janitor@sternwelten.at Wed Sep 1 14:05:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:05:53 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L5gFg009961 for ; Wed, 1 Sep 2004 14:05:43 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id DE3005C067; Wed, 1 Sep 2004 23:05:32 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01102-07; Wed, 1 Sep 2004 23:05:32 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 5E9A05C008; Wed, 1 Sep 2004 23:05:32 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIQ-00080O-LF; Wed, 01 Sep 2004 23:05:34 +0200 Subject: [patch 3/8] irda/ma600-sir: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:34 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1945 Lines: 64 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/irda/ma600-sir.c | 12 ++++-------- 1 files changed, 4 insertions(+), 8 deletions(-) diff -puN drivers/net/irda/ma600-sir.c~msleep-drivers_net_irda_ma600-sir drivers/net/irda/ma600-sir.c --- linux-2.6.9-rc1-bk7/drivers/net/irda/ma600-sir.c~msleep-drivers_net_irda_ma600-sir 2004-09-01 19:35:32.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/irda/ma600-sir.c 2004-09-01 19:35:32.000000000 +0200 @@ -191,8 +191,7 @@ static int ma600_change_speed(struct sir sirdev_raw_write(dev, &byte, sizeof(byte)); /* Wait at least 10ms: fake wait_until_sent - 10 bits at 9600 baud*/ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(15)); /* old ma600 uses 15ms */ + msleep(15); /* old ma600 uses 15ms */ #if 1 /* read-back of the control byte. ma600 is the first dongle driver @@ -215,8 +214,7 @@ static int ma600_change_speed(struct sir sirdev_set_dtr_rts(dev, TRUE, TRUE); /* Wait at least 10ms */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); /* dongle is now switched to the new speed */ dev->speed = speed; @@ -245,13 +243,11 @@ int ma600_reset(struct sir_dev *dev) /* Reset the dongle : set DTR low for 10 ms */ sirdev_set_dtr_rts(dev, FALSE, TRUE); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); /* Go back to normal mode */ sirdev_set_dtr_rts(dev, TRUE, TRUE); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(10)); + msleep(10); dev->speed = 9600; /* That's the dongle-default */ _ From janitor@sternwelten.at Wed Sep 1 14:05:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:06:03 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L5spH010172 for ; Wed, 1 Sep 2004 14:05:54 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id CC3AB5C06A; Wed, 1 Sep 2004 23:05:43 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01102-08; Wed, 1 Sep 2004 23:05:43 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 63B025C069; Wed, 1 Sep 2004 23:05:43 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIb-00081o-MO; Wed, 01 Sep 2004 23:05:45 +0200 Subject: [patch 5/8] irda/tekram-sir: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:45 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1039 Lines: 38 I would appreciate any comments from the janitor@sternweltens list. Description: Replace schedule_timeout() with msleep() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/irda/tekram-sir.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/irda/tekram-sir.c~msleep-drivers_net_irda_tekram-sir drivers/net/irda/tekram-sir.c --- linux-2.6.9-rc1-bk7/drivers/net/irda/tekram-sir.c~msleep-drivers_net_irda_tekram-sir 2004-09-01 19:35:32.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/irda/tekram-sir.c 2004-09-01 19:35:32.000000000 +0200 @@ -210,8 +210,7 @@ static int tekram_reset(struct sir_dev * sirdev_set_dtr_rts(dev, FALSE, TRUE); /* Should sleep 1 ms */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(msecs_to_jiffies(1)); + msleep(1); /* Set DTR, Set RTS */ sirdev_set_dtr_rts(dev, TRUE, TRUE); _ From janitor@sternwelten.at Wed Sep 1 14:06:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:06:08 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L5xwp010292 for ; Wed, 1 Sep 2004 14:06:00 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 7876A5C06B; Wed, 1 Sep 2004 23:05:49 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04663-09; Wed, 1 Sep 2004 23:05:49 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id DF0FE5C008; Wed, 1 Sep 2004 23:05:48 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIh-00082W-6F; Wed, 01 Sep 2004 23:05:51 +0200 Subject: [patch 6/8] wireless/airo: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:50 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 2419 Lines: 82 I would appreciate any comments from the janitor@sternweltens list. Description: Use msleep() instead of schedule_timeout() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/wireless/airo.c | 18 ++++++------------ 1 files changed, 6 insertions(+), 12 deletions(-) diff -puN drivers/net/wireless/airo.c~msleep-drivers_net_wireless_airo drivers/net/wireless/airo.c --- linux-2.6.9-rc1-bk7/drivers/net/wireless/airo.c~msleep-drivers_net_wireless_airo 2004-09-01 19:35:39.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/wireless/airo.c 2004-09-01 19:35:39.000000000 +0200 @@ -2670,11 +2670,9 @@ int reset_card( struct net_device *dev , return -1; waitbusy (ai); OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); waitbusy (ai); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/5); + msleep(200); if (lock) up(&ai->sem); return 0; @@ -7436,8 +7434,7 @@ int cmdreset(struct airo_info *ai) { OUT4500(ai,COMMAND,CMD_SOFTRESET); - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* WAS 600 12/7/00 */ + msleep(1000); /* WAS 600 12/7/00 */ if(!waitbusy (ai)){ printk(KERN_INFO "Waitbusy hang AFTER RESET\n"); @@ -7464,8 +7461,7 @@ int setflashmode (struct airo_info *ai) OUT4500(ai, SWS3, FLASH_COMMAND); OUT4500(ai, COMMAND,0); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ/2); /* 500ms delay */ + msleep(500); if(!waitbusy(ai)) { clear_bit (FLAG_FLASHING, &ai->flags); @@ -7575,8 +7571,7 @@ int flashputbuf(struct airo_info *ai){ int flashrestart(struct airo_info *ai,struct net_device *dev){ int i,status; - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + msleep(1000); /* Added 12/7/00 */ clear_bit (FLAG_FLASHING, &ai->flags); if (test_bit(FLAG_MPI, &ai->flags)) { status = mpi_init_descriptors(ai); @@ -7591,8 +7586,7 @@ int flashrestart(struct airo_info *ai,st ( ai, 2312, i >= MAX_FIDS / 2 ); } - set_current_state (TASK_UNINTERRUPTIBLE); - schedule_timeout (HZ); /* Added 12/7/00 */ + msleep(1000); /* Added 12/7/00 */ return status; } #endif /* CISCO_EXT */ _ From janitor@sternwelten.at Wed Sep 1 14:06:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:06:14 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L65at010414 for ; Wed, 1 Sep 2004 14:06:05 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id EE3955C069; Wed, 1 Sep 2004 23:05:54 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04663-10; Wed, 1 Sep 2004 23:05:54 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 6B25F5C008; Wed, 1 Sep 2004 23:05:54 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIm-00083E-M9; Wed, 01 Sep 2004 23:05:56 +0200 Subject: [patch 7/8] wireless/airport: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:05:56 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 2171 Lines: 72 I would appreciate any comments from the janitor@sternweltens list. Description: Use msleep() instead of schedule_timeout() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/wireless/airport.c | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-) diff -puN drivers/net/wireless/airport.c~msleep-drivers_net_wireless_airport drivers/net/wireless/airport.c --- linux-2.6.9-rc1-bk7/drivers/net/wireless/airport.c~msleep-drivers_net_wireless_airport 2004-09-01 19:35:41.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/wireless/airport.c 2004-09-01 19:35:41.000000000 +0200 @@ -94,8 +94,7 @@ airport_resume(struct macio_dev *mdev) printk(KERN_DEBUG "%s: Airport waking up\n", dev->name); pmac_call_feature(PMAC_FTR_AIRPORT_ENABLE, macio_get_of_node(mdev), 0, 1); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ/5); + msleep(200); enable_irq(dev->irq); @@ -147,8 +146,7 @@ airport_detach(struct macio_dev *mdev) macio_release_resource(mdev, 0); pmac_call_feature(PMAC_FTR_AIRPORT_ENABLE, macio_get_of_node(mdev), 0, 0); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ); + msleep(1000); macio_set_drvdata(mdev, NULL); free_netdev(dev); @@ -174,11 +172,9 @@ static int airport_hard_reset(struct ori disable_irq(dev->irq); pmac_call_feature(PMAC_FTR_AIRPORT_ENABLE, macio_get_of_node(card->mdev), 0, 0); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ); + msleep(1000); pmac_call_feature(PMAC_FTR_AIRPORT_ENABLE, macio_get_of_node(card->mdev), 0, 1); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ); + msleep(1000); enable_irq(dev->irq); schedule_timeout(HZ); @@ -240,8 +236,7 @@ airport_attach(struct macio_dev *mdev, c /* Power up card */ pmac_call_feature(PMAC_FTR_AIRPORT_ENABLE, macio_get_of_node(mdev), 0, 1); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(HZ); + msleep(1000); /* Reset it before we get the interrupt */ hermes_init(hw); _ From janitor@sternwelten.at Wed Sep 1 14:06:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:06:20 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L6Alo010538 for ; Wed, 1 Sep 2004 14:06:11 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 968A55C06C; Wed, 1 Sep 2004 23:06:00 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15352-01; Wed, 1 Sep 2004 23:06:00 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 16C7C5C008; Wed, 1 Sep 2004 23:06:00 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by sputnik with esmtp (Exim 4.34) id 1C2cIs-00083w-5t; Wed, 01 Sep 2004 23:06:02 +0200 Subject: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, jt@hpl.hp.com, janitor@sternwelten.at From: janitor@sternwelten.at Date: Wed, 01 Sep 2004 23:06:01 +0200 Message-ID: X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1055 Lines: 38 I would appreciate any comments from the janitor@sternweltens list. Description: Use msleep() instead of schedule_timeout() to guarantee the task delays for the desired time. Signed-off-by: Nishanth Aravamudan Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-max/drivers/net/wireless/prism54/islpci_dev.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/wireless/prism54/islpci_dev.c~msleep-drivers_net_wireless_prism54_islpci_dev drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.9-rc1-bk7/drivers/net/wireless/prism54/islpci_dev.c~msleep-drivers_net_wireless_prism54_islpci_dev 2004-09-01 19:35:41.000000000 +0200 +++ linux-2.6.9-rc1-bk7-max/drivers/net/wireless/prism54/islpci_dev.c 2004-09-01 19:35:41.000000000 +0200 @@ -436,8 +436,7 @@ prism54_bring_down(islpci_private *priv) wmb(); /* wait a while for the device to reset */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(50*HZ/1000); + msleep(50); return 0; } _ From jt@bougret.hpl.hp.com Wed Sep 1 14:09:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:09:44 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81L9c39014539 for ; Wed, 1 Sep 2004 14:09:39 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 5A0224000A2; Wed, 1 Sep 2004 14:09:30 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA12874; Wed, 1 Sep 2004 14:12:01 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1C2cMD-000363-00; Wed, 01 Sep 2004 14:09:29 -0700 Date: Wed, 1 Sep 2004 14:09:29 -0700 To: janitor@sternwelten.at Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [patch 1/8] irda/act200l-sir: replace schedule_timeout() with msleep() Message-ID: <20040901210929.GA11442@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 8330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 309 Lines: 14 On Wed, Sep 01, 2004 at 11:05:23PM +0200, janitor@sternwelten.at wrote: > > > > > > > I would appreciate any comments from the janitor@sternweltens list. I already commented that I don't like the confusing msleep() API and I prefer the more explicit schedule_timeout(). But that's only me... Jean From max@stro.at Wed Sep 1 14:40:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:40:17 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81LeCas015306 for ; Wed, 1 Sep 2004 14:40:13 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 59E035C065; Wed, 1 Sep 2004 23:40:02 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26747-03; Wed, 1 Sep 2004 23:40:01 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id C027F5C008; Wed, 1 Sep 2004 23:40:01 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C2cpn-0000e6-Sl; Wed, 01 Sep 2004 23:40:03 +0200 Date: Wed, 1 Sep 2004 23:40:03 +0200 From: maximilian attems To: jt@hpl.hp.com Cc: netdev@oss.sgi.com, jgarzik@pobox.com, kj Subject: Re: [patch 1/8] irda/act200l-sir: replace schedule_timeout() with msleep() Message-ID: <20040901214003.GC7467@stro.at> Mail-Followup-To: jt@hpl.hp.com, netdev@oss.sgi.com, jgarzik@pobox.com, kj References: <20040901210929.GA11442@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901210929.GA11442@bougret.hpl.hp.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 666 Lines: 22 On Wed, 01 Sep 2004, Jean Tourrilhes wrote: > On Wed, Sep 01, 2004 at 11:05:23PM +0200, janitor@sternwelten.at wrote: > > I would appreciate any comments from the janitor@sternweltens list. uups mangled some text there sorry for this silly email. > > I already commented that I don't like the confusing msleep() > API and I prefer the more explicit schedule_timeout(). > But that's only me... > > Jean hmm we have still archs were HZ < 100. i find msleep use msecs units a lot more readable than schedule_timeout((HZ + 99) / 100); the schedule_timeout(HZ/100) gets safely converted with msleep. -- maks kernel janitor http://janitor.kernelnewbies.org/ From jt@bougret.hpl.hp.com Wed Sep 1 14:48:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 14:48:30 -0700 (PDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81LmOaM015754 for ; Wed, 1 Sep 2004 14:48:24 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 7FE3B1C0851D; Wed, 1 Sep 2004 14:48:16 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA13748; Wed, 1 Sep 2004 14:50:47 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1C2cxj-0003Oy-00; Wed, 01 Sep 2004 14:48:15 -0700 Date: Wed, 1 Sep 2004 14:48:15 -0700 To: netdev@oss.sgi.com, jgarzik@pobox.com, kj Subject: Re: [patch 1/8] irda/act200l-sir: replace schedule_timeout() with msleep() Message-ID: <20040901214815.GA13071@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040901210929.GA11442@bougret.hpl.hp.com> <20040901214003.GC7467@stro.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901214003.GC7467@stro.at> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 8332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 926 Lines: 27 On Wed, Sep 01, 2004 at 11:40:03PM +0200, maximilian attems wrote: > On Wed, 01 Sep 2004, Jean Tourrilhes wrote: > > > On Wed, Sep 01, 2004 at 11:05:23PM +0200, janitor@sternwelten.at wrote: > > > I would appreciate any comments from the janitor@sternweltens list. > uups mangled some text there sorry for this silly email. > > > > I already commented that I don't like the confusing msleep() > > API and I prefer the more explicit schedule_timeout(). > > But that's only me... > > > > Jean > > hmm we have still archs were HZ < 100. > i find msleep use msecs units a lot more readable than > schedule_timeout((HZ + 99) / 100); > > the schedule_timeout(HZ/100) gets safely converted with msleep. I don't have complain about converting the (HZ + 99) / 100 expressions to something saner. My beef is the fact that msleep hide the fact that a schedule might happen. This is important in the IrDA code. > maks Jean From nacc@us.ibm.com Wed Sep 1 15:07:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 15:08:03 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81M7oDP016384 for ; Wed, 1 Sep 2004 15:07:57 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i81M3UsB481516; Wed, 1 Sep 2004 18:03:30 -0400 Received: from arkanoid.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i81M3ShU204832; Wed, 1 Sep 2004 16:03:29 -0600 Received: from arkanoid.beaverton.ibm.com (arkanoid [127.0.0.1]) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) with ESMTP id i81M3R6a004197; Wed, 1 Sep 2004 22:03:27 GMT Received: (from aravamud@localhost) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) id i81M3RWP004194; Wed, 1 Sep 2004 22:03:27 GMT X-Authentication-Warning: arkanoid.beaverton.ibm.com: aravamud set sender to nacc@us.ibm.com using -f Date: Wed, 1 Sep 2004 22:03:26 +0000 From: Nishanth Aravamudan To: jt@hpl.hp.com Cc: netdev@oss.sgi.com, jgarzik@pobox.com, kj Subject: Re: [Kernel-janitors] Re: [patch 1/8] irda/act200l-sir: replace schedule_timeout() with msleep() Message-ID: <20040901220326.GB2516@us.ibm.com> References: <20040901210929.GA11442@bougret.hpl.hp.com> <20040901214003.GC7467@stro.at> <20040901214815.GA13071@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901214815.GA13071@bougret.hpl.hp.com> X-Operating-System: Linux 2.6.73 (i686) User-Agent: Mutt/1.5.6+20040803i X-archive-position: 8333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1508 Lines: 34 On Wed, Sep 01, 2004 at 02:48:15PM -0700, Jean Tourrilhes wrote: > On Wed, Sep 01, 2004 at 11:40:03PM +0200, maximilian attems wrote: > > On Wed, 01 Sep 2004, Jean Tourrilhes wrote: > > > > > On Wed, Sep 01, 2004 at 11:05:23PM +0200, janitor@sternwelten.at wrote: > > > > I would appreciate any comments from the janitor@sternweltens list. > > uups mangled some text there sorry for this silly email. > > > > > > I already commented that I don't like the confusing msleep() > > > API and I prefer the more explicit schedule_timeout(). > > > But that's only me... > > > > > > Jean > > > > hmm we have still archs were HZ < 100. > > i find msleep use msecs units a lot more readable than > > schedule_timeout((HZ + 99) / 100); > > > > the schedule_timeout(HZ/100) gets safely converted with msleep. > > I don't have complain about converting the (HZ + 99) / 100 > expressions to something saner. My beef is the fact that msleep hide > the fact that a schedule might happen. This is important in the IrDA > code. It *is* important for developers to realize that invoking msleep() may involve giving up the CPU (ie. eventually calling schedule()); however, I think my previous point, that the name itself (the "sleep" part, I mean) is a fair and clear indication of this behavior, is valid. In those cases where a busy-wait is desired, then mdelay() should be used, as indicated by "delay". I think with this in mind & with a quick glance at the source, if need be, the naming is quite safe. -Nish From max@stro.at Wed Sep 1 15:58:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 15:59:06 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i81Mwsp0017551 for ; Wed, 1 Sep 2004 15:58:55 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id DFA3E5C008; Thu, 2 Sep 2004 00:58:43 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01686-10; Thu, 2 Sep 2004 00:58:43 +0200 (CEST) Received: from sputnik (M830P021.adsl.highway.telekom.at [62.47.135.181]) by baikonur.stro.at (Postfix) with ESMTP id 3AAC15C065; Thu, 2 Sep 2004 00:58:43 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C2e3u-0001e1-TX; Thu, 02 Sep 2004 00:58:43 +0200 Date: Thu, 2 Sep 2004 00:58:42 +0200 From: maximilian attems To: jt@hpl.hp.com Cc: netdev@oss.sgi.com, jgarzik@pobox.com, kj Subject: Re: [Kernel-janitors] Re: [patch 1/8] irda/act200l-sir: replace schedule_timeout() with msleep() Message-ID: <20040901225841.GF7467@stro.at> Mail-Followup-To: jt@hpl.hp.com, netdev@oss.sgi.com, jgarzik@pobox.com, kj References: <20040901210929.GA11442@bougret.hpl.hp.com> <20040901214003.GC7467@stro.at> <20040901214815.GA13071@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901214815.GA13071@bougret.hpl.hp.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 737 Lines: 26 On Wed, 01 Sep 2004, Jean Tourrilhes wrote: > On Wed, Sep 01, 2004 at 11:40:03PM +0200, maximilian attems wrote: > > On Wed, 01 Sep 2004, Jean Tourrilhes wrote: .. > > > > hmm we have still archs were HZ < 100. > > i find msleep use msecs units a lot more readable than > > schedule_timeout((HZ + 99) / 100); > > > > the schedule_timeout(HZ/100) gets safely converted with msleep. > > I don't have complain about converting the (HZ + 99) / 100 > expressions to something saner. My beef is the fact that msleep hide > the fact that a schedule might happen. This is important in the IrDA > code. sorry my woding was confusing: (HZ + 99) / 100 is correct! as msleep(10) -- maks kernel janitor http://janitor.kernelnewbies.org/ From acme@conectiva.com.br Wed Sep 1 19:46:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 19:46:31 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i822kOCt024942 for ; Wed, 1 Sep 2004 19:46:25 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id 5FC4147429; Wed, 1 Sep 2004 23:46:14 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id B313F4796E for ; Wed, 1 Sep 2004 23:46:13 -0300 (BRT) Received: (qmail 31263 invoked by uid 0); 2 Sep 2004 03:43:59 -0000 Received: from mapi8.distro.conectiva (HELO oops.kerneljanitors.org) (10.0.16.10) by burns.conectiva with SMTP; 2 Sep 2004 03:43:59 -0000 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id CA0F21464C; Wed, 1 Sep 2004 23:48:05 -0300 (BRT) Date: Wed, 1 Sep 2004 23:48:05 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: Zhikui Chen , hadi@cyberus.ca, dccp@ietf.org, netdev@oss.sgi.com Subject: Re: HELP for dccp implementation. Message-ID: <20040902024805.GA23844@conectiva.com.br> References: <412CC269.8080907@rus.uni-stuttgart.de> <1093454747.1034.85.camel@jzny.localdomain> <4135A32A.4030901@rus.uni-stuttgart.de> <20040901133709.3637d63d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901133709.3637d63d.davem@davemloft.net> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.5.1i X-Bogosity: No, tests=bogofilter, spamicity=0.051111, version=0.16.3 X-archive-position: 8335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 882 Lines: 23 Em Wed, Sep 01, 2004 at 01:37:09PM -0700, David S. Miller escreveu: > On Wed, 01 Sep 2004 12:23:38 +0200 > Zhikui Chen wrote: > > > If I assign a value such as 0x ee9fbc00 to sk in dccp_rcv (before lookup > > calling), and comment lookkup calling, I get a error report from > > bh_lock_sock(sk) calling inside dccp_rcv, which error report is > > spin_is_locked on uninitialized spinlock ee9fbc00, and spin_lock > > (:ee9fbc00) already locked by /73. > > > > Do you know its reason? Thanks, > > Zhikui, are you working together with Arnaldo using his > code base, like we suggested to you? Or are you working > still on your own code? Dave, I've been quite busy lately with some other projects and haven't been able to colaborate with Zhikui, I hope to change this situation soon. Regards, - Arnaldo From davem@davemloft.net Wed Sep 1 22:22:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 22:22:29 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i825MM5j031276 for ; Wed, 1 Sep 2004 22:22:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C2k2A-0005yV-00; Wed, 01 Sep 2004 22:21:18 -0700 Date: Wed, 1 Sep 2004 22:21:18 -0700 From: "David S. Miller" To: Herbert Xu Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-Id: <20040901222118.0ce4bcc6.davem@davemloft.net> In-Reply-To: <20040831104139.GA2124@gondor.apana.org.au> References: <20040814005411.GA18350@gondor.apana.org.au> <20040814012513.GA721@gondor.apana.org.au> <20040814013030.GA2042@gondor.apana.org.au> <20040814050848.GA11874@gondor.apana.org.au> <20040814062703.GA4806@gondor.apana.org.au> <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2207 Lines: 81 On Tue, 31 Aug 2004 20:41:39 +1000 Herbert Xu wrote: > > I think we can clear this by putting neigh_parms_release() into an > > RCU handler. It can't be in in_dev_rcu_put. > > Yes that should go a long way in resolving this problem. So here's the first step. No rcu_read_lock()'s are needed since the tbl->lock needs to be held as a write when traversing these things anyways for other reasons. Can you work on the next bit you mentioned, making sure the corresponding idev is still alive when we add a neighbour with its neigh_parms to the hash table? Thanks. ===== include/net/neighbour.h 1.8 vs edited ===== --- 1.8/include/net/neighbour.h 2004-08-16 14:10:51 -07:00 +++ edited/include/net/neighbour.h 2004-09-01 21:57:37 -07:00 @@ -46,6 +46,7 @@ #include #include #include +#include #include #include @@ -65,6 +66,8 @@ void *priv; void *sysctl_table; + + struct rcu_head rcu_head; int base_reachable_time; int retrans_time; ===== net/core/neighbour.c 1.28 vs edited ===== --- 1.28/net/core/neighbour.c 2004-04-29 16:26:35 -07:00 +++ edited/net/core/neighbour.c 2004-09-01 22:00:59 -07:00 @@ -1120,6 +1120,7 @@ if (p) { memcpy(p, &tbl->parms, sizeof(*p)); p->tbl = tbl; + INIT_RCU_HEAD(&p->rcu_head); p->reachable_time = neigh_rand_reach_time(p->base_reachable_time); if (dev && dev->neigh_setup && dev->neigh_setup(dev, p)) { @@ -1135,6 +1136,14 @@ return p; } +static void neigh_rcu_free_parms(struct rcu_head *head) +{ + struct neigh_parms *parms = + container_of(head, struct neigh_parms, rcu_head); + + kfree(parms); +} + void neigh_parms_release(struct neigh_table *tbl, struct neigh_parms *parms) { struct neigh_parms **p; @@ -1146,7 +1155,7 @@ if (*p == parms) { *p = parms->next; write_unlock_bh(&tbl->lock); - kfree(parms); + call_rcu(&parms->rcu_head, neigh_rcu_free_parms); return; } } @@ -1159,6 +1168,7 @@ { unsigned long now = jiffies; + INIT_RCU_HEAD(&tbl->parms.rcu_head); tbl->parms.reachable_time = neigh_rand_reach_time(tbl->parms.base_reachable_time); From davem@redhat.com Wed Sep 1 22:27:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 22:27:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i825RWEM031668 for ; Wed, 1 Sep 2004 22:27:32 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i825RES0025351; Thu, 2 Sep 2004 01:27:19 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i825R9313941; Thu, 2 Sep 2004 01:27:09 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i825R1hU011844; Thu, 2 Sep 2004 01:27:01 -0400 Date: Wed, 1 Sep 2004 22:26:24 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Fix CONFIG_COMPAT with !CONFIG_NET Message-Id: <20040901222624.31205ef5.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 394 Lines: 12 On Tue, 31 Aug 2004 12:06:30 +0200 Andi Kleen wrote: > Fix compilation with CONFIG_COMPAT set and CONFIG_NET disabled. I like this patch, but... > -static int ret_einval(unsigned int fd, unsigned int cmd, unsigned long arg) > +static __attribute__((used)) int > +ret_einval(unsigned int fd, unsigned int cmd, unsigned long arg) Ahem... use something in linux/compiler.h ok? :) From davem@redhat.com Wed Sep 1 22:34:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 22:34:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i825Y85k032101 for ; Wed, 1 Sep 2004 22:34:09 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i825XqS0026489; Thu, 2 Sep 2004 01:33:52 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i825Xl314921; Thu, 2 Sep 2004 01:33:47 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i825XdiV013008; Thu, 2 Sep 2004 01:33:39 -0400 Date: Wed, 1 Sep 2004 22:33:01 -0700 From: "David S. Miller" To: Andi Kleen Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [PATCH] Extend lock less TX to real devices Message-Id: <20040901223301.1a8d97a8.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1126 Lines: 32 On Tue, 31 Aug 2004 14:38:20 +0200 Andi Kleen wrote: > This patch extends the recently added NETIF_F_LLTX to real devices. Well, it does a lot of other things too. > I added support for trylocking instead of spinning like sch_generic > does - for that the driver has to return -1, then the packet is requeued. > The check for a local device deadlock is lost for this case, > but that doesn't seem to be a big loss (I've never seen this printk > ever get triggered) It is triggerable if you misconfigure your system. I'm totally against this change, because previously at least the user would find out in their logs. With your change the system explodes looping with no explanation why. > The patch looks bigger than it really is because i moved some code > around and converted the macros into inlines. .. > I also did an additional micro optimization: And for this reason you need to split this patch up. I would recommend: patch 1) Change macros into inlines patch 2) local_bh_disable() preemption count optimization patch 3) support for F_LLTX on real devices patch 4) locking changes Thanks Andi. From davem@redhat.com Wed Sep 1 22:42:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 22:42:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i825gCc2032568 for ; Wed, 1 Sep 2004 22:42:12 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i825fsS0028432; Thu, 2 Sep 2004 01:41:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i825fs316499; Thu, 2 Sep 2004 01:41:54 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i825fjLG015242; Thu, 2 Sep 2004 01:41:46 -0400 Date: Wed, 1 Sep 2004 22:41:08 -0700 From: "David S. Miller" To: vatsa@in.ibm.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com, paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-Id: <20040901224108.3b2d692d.davem@redhat.com> In-Reply-To: <20040831125941.GA5534@in.ibm.com> References: <20040831125941.GA5534@in.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 3453 Lines: 71 On Tue, 31 Aug 2004 18:29:41 +0530 Srivatsa Vaddagiri wrote: > Some notes on the patch: > > - Although readprofile shows improvement in tick count for > __tcp_v4_lookup_established, I haven't come across any benchmarks that is > benefited noticeably by the lock-free lookup. I have tried httperf, netperf > and simple file transfer tests so far. > > This could possibly be because the hash table size on the machines I was > testing was high (tcp_ehash_size = 128K), leading to low contention rate on > the hash bucket locks. Also because of the fact that lookup could happen in > parallel to socket input packet processing. > > I would be interested to know if anyone has seen high-rate of lock contention > for hash bucket lock. Such workloads would benefit from the lock-free lookup. The reason you don't see any improvement is that the ehash table is pretty write heavy. I'm not totally against your patch, I just don't think that the TCP established hash table qualifies as "read heavy" as per what RCU is truly effective for. > - I presume that one of the reasons for keeping the hash table so big is to > keep lock contention low (& to reduce the size of hash chains). If the lookup > is made lock-free, then could the size of the hash table be reduced (without > adversely impacting performance)? It's large so that the hash itself is effective, not for locking reasons. > - Biggest problem I had converting over to RCU was the refcount race between > sock_put and sock_hold. sock_put might see the refcount go to zero and decide > to free the object, while on some other CPU, sock_get's are pending against > the same object. The patch handles the race by deciding to free the object > only from the RCU callback. That's exactly what I was concerned about when I saw that you had attempted this change. It is incredibly important for state changes and updates to be seen as atomic by the packet input processing engine. It would be illegal for a cpu running TCP input to see a socket in two tables at the same time (for example, in the main established area and in the second half for TIME_WAIT buckets). If the visibility of the socket is wrong, sockets could be erroneously be reset during the transition from established to TIME_WAIT state. Beware! > - Socket table lookups that happens thr', say /proc/net/tcp or tcpdiag_dump, is > not lock-free yet. This is because of movement of socket performed in > __tcp_tw_hashdance, between established half to time-wait half. > There is a window during this movement, when the same socket is present > on both time-wait half as well as established half. I felt that it is not > good to have /proc/net/tcp report two instances of the same socket. Hence > I resorted to have /proc/net/tcp and tcpdiag_dump doing the lookup using > a spinlock. /proc/net/tcp should simply not be used by people, we have the netlink interface to get socket listings which actually scales. Leaving /proc/net/tcp readable on servers with real users is a DoS waiting to happen. > Note that __tcp_v4_lookup_established should not be affected by the above > movement because I found it scans the established half first and _then_ the > time wait half. So even if the same socket is present in both established half > and time wait half, __tcp_v4_lookup_established will lookup only one of them > (& not both). I hope this is true. From davem@davemloft.net Wed Sep 1 22:44:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 22:44:06 -0700 (PDT) Received: from smtp110.mail.sc5.yahoo.com (smtp110.mail.sc5.yahoo.com [66.163.170.8]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i825hxhA000393 for ; Wed, 1 Sep 2004 22:44:00 -0700 Received: from unknown (HELO cheetah.davemloft.net) (davem?330@63.197.226.105 with login) by smtp110.mail.sc5.yahoo.com with SMTP; 2 Sep 2004 05:43:51 -0000 Date: Wed, 1 Sep 2004 22:43:06 -0700 From: "David S. Miller" To: Andi Kleen Cc: vatsa@in.ibm.com, davem@redhat.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com, paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-Id: <20040901224306.7dd80458.davem@davemloft.net> In-Reply-To: <20040831135419.GA17642@wotan.suse.de> References: <20040831125941.GA5534@in.ibm.com> <20040831135419.GA17642@wotan.suse.de> Organization: DaveM Loft Enterprises X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 760 Lines: 19 On Tue, 31 Aug 2004 15:54:20 +0200 Andi Kleen wrote: > And it should also fix the performance problems with > cat /proc/net/tcp on ppc64/ia64 for large hash tables because the rw locks > are gone. Time to convert netstat et al. over the netlink too. > > - I presume that one of the reasons for keeping the hash table so big is to > > keep lock contention low (& to reduce the size of hash chains). If the lookup > > is made lock-free, then could the size of the hash table be reduced (without > > adversely impacting performance)? > > Definitely worth trying IMHO. The current hash tables are far > too big. I would do that as followon patches though. The hashes are big to make the hash effective, not to help the locking contention. From davem@davemloft.net Wed Sep 1 22:46:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Sep 2004 22:46:44 -0700 (PDT) Received: from smtp108.mail.sc5.yahoo.com (smtp108.mail.sc5.yahoo.com [66.163.170.6]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i825kdsQ000774 for ; Wed, 1 Sep 2004 22:46:39 -0700 Received: from unknown (HELO cheetah.davemloft.net) (davem?330@63.197.226.105 with login) by smtp108.mail.sc5.yahoo.com with SMTP; 2 Sep 2004 05:46:31 -0000 Date: Wed, 1 Sep 2004 22:45:46 -0700 From: "David S. Miller" To: vatsa@in.ibm.com Cc: ak@suse.de, davem@redhat.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com, paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-Id: <20040901224546.03765c8d.davem@davemloft.net> In-Reply-To: <20040901113641.GA3918@in.ibm.com> References: <20040831125941.GA5534@in.ibm.com> <20040831135419.GA17642@wotan.suse.de> <20040901113641.GA3918@in.ibm.com> Organization: DaveM Loft Enterprises X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1484 Lines: 34 On Wed, 1 Sep 2004 17:06:41 +0530 Srivatsa Vaddagiri wrote: > On Tue, Aug 31, 2004 at 03:54:20PM +0200, Andi Kleen wrote: > > I bet also when you just do rdtsc timing for the TCP receive > > path the cycle numbers will be way down (excluding the copy). > > I got cycle numbers for the lookup routine (with CONFIG_PREEMPT turned off). > They were taken on a 900MHz 8way Intel P3 SMP box. The results are as below: > > > ------------------------------------------------------------------------------- > | 2.6.8.1 | 2.6.8.1 + my patch > ------------------------------------------------------------------------------- > Average cycles | | > spent in | | > __tcp_v4_lookup_established | 2970.65 | 668.227 > | (~3.3 micro-seconds) | (~0.74 microseconds) > ------------------------------------------------------------------------------- > > This repesents improvement by a factor of 77.5%! And yet none of your benchmarks show noticable improvements, which means that this micro-measurement is totally unimportant in the grand scheme of things as far as we know. I'm not adding in a patch that merely provides some micro-measurement improvement that someone can do a shamans dance over. :) If we're going to add this new level of complexity to the TCP code we need to see some real usage performance improvement, not just something that shows up when we put a microscope on a single function. From margitsw@t-online.de Thu Sep 2 00:02:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 00:02:45 -0700 (PDT) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8272W1O002697 for ; Thu, 2 Sep 2004 00:02:33 -0700 Received: from fwd00.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1C2lbz-0003TC-04; Thu, 02 Sep 2004 09:02:23 +0200 Received: from roglap.local (ZZMK7oZb8e9+xkugoAKd-ri8Nbyr6YNpR3taY7+k50x-7OKsWGqCcl@[217.224.24.102]) by fwd00.sul.t-online.com with esmtp id 1C2lbn-2FEFIe0; Thu, 2 Sep 2004 09:02:11 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: netdev@oss.sgi.com Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Date: Thu, 2 Sep 2004 08:50:38 +0200 User-Agent: KMail/1.5.4 Cc: janitor@sternwelten.at MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409020850.38177.margitsw@t-online.de> X-ID: ZZMK7oZb8e9+xkugoAKd-ri8Nbyr6YNpR3taY7+k50x-7OKsWGqCcl X-TOI-MSGID: 750c7a0a-8598-42e0-be04-32caec994a4a X-archive-position: 8342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 306 Lines: 10 I agree with Jean and add the following : You are assuming HZ = 1000. In 2.4, HZ = 100 (And in 2.6, HZ is not necessarily = 1000). The prism54 code base is identical between 2.4/2.6 and is maintained as such in the project. Therefore, I look forward to your implementation of msleep() in 2.4 ;-) Margit From max@stro.at Thu Sep 2 01:24:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 01:24:49 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i828OhMH008902 for ; Thu, 2 Sep 2004 01:24:44 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 569FE5C065; Thu, 2 Sep 2004 10:24:33 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11776-07; Thu, 2 Sep 2004 10:24:32 +0200 (CEST) Received: from sputnik (M965P030.adsl.highway.telekom.at [62.47.152.158]) by baikonur.stro.at (Postfix) with ESMTP id B5D775C008; Thu, 2 Sep 2004 10:24:32 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C2mtV-00012b-A6; Thu, 02 Sep 2004 10:24:33 +0200 Date: Thu, 2 Sep 2004 10:24:33 +0200 From: maximilian attems To: Margit Schubert-While Cc: netdev@oss.sgi.com, kj Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040902082432.GA1876@stro.at> Mail-Followup-To: Margit Schubert-While , netdev@oss.sgi.com, kj References: <200409020850.38177.margitsw@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409020850.38177.margitsw@t-online.de> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 724 Lines: 24 On Thu, 02 Sep 2004, Margit Schubert-While wrote: > I agree with Jean and add the following : > You are assuming HZ = 1000. > In 2.4, HZ = 100 (And in 2.6, HZ is not necessarily = 1000). shure, but this is an argument for msleep as it uses msecs as unit, which don't depend on your arch. (well physics says different for arch/relativistic :) > The prism54 code base is identical between 2.4/2.6 and is > maintained as such in the project. > Therefore, I look forward to your implementation of msleep() > in 2.4 ;-) 2.4 is closed for such stuff, you'll know that better than me, it shouldn't hinder 2.6 in it's progression. one day you will need to branch. -- maks kernel janitor http://janitor.kernelnewbies.org/ From margitsw@t-online.de Thu Sep 2 02:47:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 02:48:04 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i829lwLE013269 for ; Thu, 2 Sep 2004 02:47:59 -0700 Received: from fwd09.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1C2oC6-0000xj-01; Thu, 02 Sep 2004 11:47:50 +0200 Received: from roglap.local (SUHUzvZ-8eXCHB3xcEwbuSp0Mp4mYoutEzX8sHfg8jiJjYa1rVMWw+@[217.255.115.148]) by fwd09.sul.t-online.com with esmtp id 1C2oBr-0hwnce0; Thu, 2 Sep 2004 11:47:35 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: netdev@oss.sgi.com Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Date: Thu, 2 Sep 2004 11:35:57 +0200 User-Agent: KMail/1.5.4 Cc: janitor@sternwelten.at MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021135.57632.margitsw@t-online.de> X-ID: SUHUzvZ-8eXCHB3xcEwbuSp0Mp4mYoutEzX8sHfg8jiJjYa1rVMWw+ X-TOI-MSGID: 5ef338f1-34c6-4bd0-8378-af70bc838370 X-archive-position: 8344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 237 Lines: 8 On Thu, 02 Sep 2004, Maximilian scribeth: > it shouldn't hinder 2.6 in it's progression. I consider this a regression. As schedule_timeout is used elesewhere in the prism54 code, we are using a consistent and documented method. Margit From max@stro.at Thu Sep 2 03:03:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 03:03:38 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82A3WFo014123 for ; Thu, 2 Sep 2004 03:03:32 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id E87C65C065; Thu, 2 Sep 2004 12:03:21 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09880-07; Thu, 2 Sep 2004 12:03:21 +0200 (CEST) Received: from sputnik (M965P030.adsl.highway.telekom.at [62.47.152.158]) by baikonur.stro.at (Postfix) with ESMTP id 71EDB5C008; Thu, 2 Sep 2004 12:03:21 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C2oR8-0001sT-5r; Thu, 02 Sep 2004 12:03:22 +0200 Date: Thu, 2 Sep 2004 12:03:22 +0200 From: maximilian attems To: Margit Schubert-While Cc: netdev@oss.sgi.com, kj Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040902100322.GD1876@stro.at> Mail-Followup-To: Margit Schubert-While , netdev@oss.sgi.com, kj References: <200409021135.57632.margitsw@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409021135.57632.margitsw@t-online.de> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 460 Lines: 16 On Thu, 02 Sep 2004, Margit Schubert-While wrote: > On Thu, 02 Sep 2004, Maximilian scribeth: > > it shouldn't hinder 2.6 in it's progression. > I consider this a regression. > As schedule_timeout is used elesewhere in the prism54 code, > we are using a consistent and documented method. you didn't answer to the unit argument in favour of msleep. shure msleep is also consistent and documented. -- maks kernel janitor http://janitor.kernelnewbies.org/ From margitsw@t-online.de Thu Sep 2 03:33:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 03:33:44 -0700 (PDT) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82AXcn7016072 for ; Thu, 2 Sep 2004 03:33:38 -0700 Received: from fwd01.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1C2ouH-0003kY-05; Thu, 02 Sep 2004 12:33:29 +0200 Received: from roglap.local (Tnz5qYZF8e9457pYQieTTeEIqQdc7lGj+UHe6PaeG+V07c5IS8Ns4h@[217.224.28.77]) by fwd01.sul.t-online.com with esmtp id 1C2ouE-1a48OG0; Thu, 2 Sep 2004 12:33:26 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: netdev@oss.sgi.com Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Date: Thu, 2 Sep 2004 12:21:42 +0200 User-Agent: KMail/1.5.4 Cc: janitor@sternwelten.at MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021221.42287.margitsw@t-online.de> X-ID: Tnz5qYZF8e9457pYQieTTeEIqQdc7lGj+UHe6PaeG+V07c5IS8Ns4h X-TOI-MSGID: 68c3e6c7-4a05-4969-9a8a-cb9a86876b9b X-archive-position: 8346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev On Thu, 02 Sep 2004, Maximilian scribeth: > you didn't answer to the unit argument in favour of msleep. Don't need to, here's msleep - void msleep(unsigned int msecs) { unsigned long timeout = msecs_to_jiffies(msecs); while (timeout) { set_current_state(TASK_UNINTERRUPTIBLE); timeout = schedule_timeout(timeout); } } In other words, with the subtle exception of the while loop, it reconstitutes the original code. (Although m_to_j doesn't even exactly do that) (And note because of the while loop, this may not be what the author intended) > shure msleep is also consistent and documented. grep -r Documentation = Nix Margit From margitsw@t-online.de Thu Sep 2 04:14:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 04:14:23 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82BEEAT021128 for ; Thu, 2 Sep 2004 04:14:15 -0700 Received: from fwd08.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1C2pXZ-0001mb-05; Thu, 02 Sep 2004 13:14:05 +0200 Received: from roglap.local (ZYwoviZSreF-pdqRDHwkJ74gIjgQ8CI3ZTOcIys3IeGfg8e2b7Hmcy@[80.128.222.2]) by fwd08.sul.t-online.com with esmtp id 1C2pXR-0VU6C00; Thu, 2 Sep 2004 13:13:57 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: netdev@oss.sgi.com Subject: Re: [patch 01/16] __FUNCTION__ string concatenation Date: Thu, 2 Sep 2004 13:02:22 +0200 User-Agent: KMail/1.5.4 Cc: janitor@sternwelten.at MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021302.22823.margitsw@t-online.de> X-ID: ZYwoviZSreF-pdqRDHwkJ74gIjgQ8CI3ZTOcIys3IeGfg8e2b7Hmcy X-TOI-MSGID: 9470ae78-2f8a-4cc5-a808-7cfeabfe9e97 X-archive-position: 8347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev On Thu, 02 Sep 2004, Maximilian scribeth: > drivers/net/wireless/prism65/islpci_mgt.h, as suggested Woo, we got another project ? (prism65) > I don't have the hardware to do a run-time check. > It should not pose any problems though. Oh, I think we can safely say that, especially as TRACE is nowhere referenced ;-) (And therefore the patch is unnecessary) Margit From herbert@gondor.apana.org.au Thu Sep 2 06:06:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 06:06:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82D6WjR004015 for ; Thu, 2 Sep 2004 06:06:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C2rI2-0002ob-00; Thu, 02 Sep 2004 23:06:10 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C2rHx-0008TX-00; Thu, 02 Sep 2004 23:06:05 +1000 Date: Thu, 2 Sep 2004 23:06:05 +1000 To: "David S. Miller" Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-ID: <20040902130605.GA32570@gondor.apana.org.au> References: <20040814013030.GA2042@gondor.apana.org.au> <20040814050848.GA11874@gondor.apana.org.au> <20040814062703.GA4806@gondor.apana.org.au> <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> <20040901222118.0ce4bcc6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901222118.0ce4bcc6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Wed, Sep 01, 2004 at 10:21:18PM -0700, David S. Miller wrote: > > So here's the first step. No rcu_read_lock()'s are needed > since the tbl->lock needs to be held as a write when > traversing these things anyways for other reasons. Thanks. > Can you work on the next bit you mentioned, making > sure the corresponding idev is still alive when we add > a neighbour with its neigh_parms to the hash table? Sure. Actually I prefer to do it by ref counting neigh_parms directly. I'll send you a patch soon. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From khc@pm.waw.pl Thu Sep 2 07:06:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 07:06:55 -0700 (PDT) Received: from inx.pm.waw.pl (IDENT:1YwU6gXiFp5E39BXnhw2yBkLOvILUoL1@inx.pm.waw.pl [195.116.170.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82E6gHA015644 for ; Thu, 2 Sep 2004 07:06:43 -0700 Received: from defiant.pm.waw.pl (pk124.warszawa.cvx.ppp.tpnet.pl [213.76.106.124]) by inx.pm.waw.pl (Postfix) with ESMTP id 9EA61E0E2; Thu, 2 Sep 2004 16:05:08 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 40E49302D6; Thu, 2 Sep 2004 14:27:57 +0200 (CEST) To: Jeff Garzik Cc: Subject: [PATCH][REPOST] 21143 Tulip problems with 10BaseT References: From: Krzysztof Halasa Date: Thu, 02 Sep 2004 14:27:57 +0200 In-Reply-To: (Krzysztof Halasa's message of "Fri, 28 May 2004 14:21:57 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Hi, Looking at my kernel tree I noticed this patch has not been applied. I'm currently unable to test it, but it was required in the past and I don't think the situation has changed. Please apply. Thanks. --- linux-2.6/drivers/net/tulip/21142.c 19 Mar 2004 15:01:15 -0000 +++ linux-2.6/drivers/net/tulip/21142.c 2 Sep 2004 12:26:31 -0000 @@ -149,11 +149,13 @@ else if (negotiated & 0x0080) dev->if_port = 3; else if (negotiated & 0x0040) dev->if_port = 4; else if (negotiated & 0x0020) dev->if_port = 0; - else { + else if ((csr12 & 2) == 0 && (tp->sym_advertise & 0x0180)) + dev->if_port = 3; + else if ((csr12 & 4) == 0 && (tp->sym_advertise & 0x0060)) + dev->if_port = 0; + else tp->nwayset = 0; - if ((csr12 & 2) == 0 && (tp->sym_advertise & 0x0180)) - dev->if_port = 3; - } + tp->full_duplex = (tulip_media_cap[dev->if_port] & MediaAlwaysFD) ? 1:0; if (tulip_debug > 1) { My original mail: From: Krzysztof Halasa Subject: [PATCH] 21143 Tulip problems with 10BaseT To: Jeff Garzik Cc: Date: Fri, 28 May 2004 14:21:57 +0200 Current 2.4 and 2.6 kernels have problems with Tulip 21143 on 10BaseT link (with not-NWay-capable 10 Mbps peer) - tulip_debug shows: Linux Tulip driver version 1.1.13 (May 11, 2002) tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth2: Digital DS21143 Tulip rev 48 at 0xe400, 00:C0:CA:13:48:10, IRQ 9. eth2: Restarting 21143 autonegotiation, csr14=0003ffff. eth2: tulip_up(), irq==9. eth2: Restarting 21143 autonegotiation, csr14=0003ffff. eth2: Done tulip_up(), CSR0 ffa08000, CSR5 f0760000 CSR6 b2422202. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0668010 new csr5=0xf0660000. eth2: 21143 link status interrupt 000050ca, CSR5 f0668010, fffbffff. ^^^^^^^^ = got NLP but no FLP (no NWay) eth2: Autonegotiation failed, using 10baseT, link beat status 50ca. ... while we know the peer is using NLP and therefore is 10BaseT-HD capable. eth2: 21143 non-MII 10baseT transceiver control 08af/00a5. eth2: Setting CSR15 to 08af0008/00a50008. eth2: Using media type 10baseT, CSR12 is c6. eth2: Setting CSR6 82420000/b2422002 CSR12 000010c6. eth2: exiting interrupt, csr5=0xf0660000. eth2: 21143 negotiation status 000010c6, 10baseT. eth2: 21143 negotiation failed, status 000010c6. eth2: Testing new 21143 media 100baseTx. eth2: interrupt csr5=0xf0008102 new csr5=0xf0000000. eth2: The transmitter stopped. CSR5 is f0008102, CSR6 b2420000, new CSR6 83860000. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: 21143 negotiation status 000000c6, 100baseTx. eth2: No 21143 100baseTx link beat, 000000c6, trying NWay. eth2: Restarting 21143 autonegotiation, csr14=0003ffff. eth2: interrupt csr5=0xf0008102 new csr5=0xf0000000. eth2: The transmitter stopped. CSR5 is f0008102, CSR6 b2420200, new CSR6 82420200. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0668010 new csr5=0xf0660000. eth2: 21143 link status interrupt 000050ca, CSR5 f0668010, fffbffff. eth2: Autonegotiation failed, using 10baseT, link beat status 50ca. After the attached patch is applied: eth2: Restarting 21143 autonegotiation, csr14=0003ffff. eth2: tulip_up(), irq==9. eth2: Restarting 21143 autonegotiation, csr14=0003ffff. eth2: Done tulip_up(), CSR0 ffa08000, CSR5 f0360000 CSR6 b2422202. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth2: exiting interrupt, csr5=0xf0660000. eth2: interrupt csr5=0xf0668010 new csr5=0xf0660000. eth2: 21143 link status interrupt 000050ca, CSR5 f0668010, fffbffff. ^^^^^^^^ The same here - 0x50CA = got NLP, negotiation ok (seems like NLP only sets this bit as well), no 100 Mbps link status (whatever that means). eth2: Switching to 10baseT based on link negotiation 01e0 & 0000 = 0000. Correct, we haven't received FLP so no "capability bits" are present. eth2: 21143 non-MII 10baseT transceiver control 08af/00a5. eth2: Setting CSR15 to 08af0008/00a50008. eth2: Using media type 10baseT, CSR12 is c6. eth2: Setting CSR6 82420000/b2422002 CSR12 000010c6. eth2: exiting interrupt, csr5=0xf0660000. eth2: 21143 negotiation status 000010c6, 10baseT. ^^^^ Not sure about it (no 10 nor 100 Mbps link pulse?). But the chip does it this way. Possibly the bit should be cleared before read? eth2: Using NWay-set 10baseT media, csr12 000010c6. eth2: interrupt csr5=0xf0668010 new csr5=0xf0660000. eth2: 21143 link status interrupt 000050ca, CSR5 f0668010, fff8ffff. eth2: 21143 10baseT link beat good. eth2: exiting interrupt, csr5=0xf0660000. eth2: 21143 negotiation status 000050ca, 10baseT. eth2: Using NWay-set 10baseT media, csr12 000050ca. eth2: 21143 negotiation status 000050ca, 10baseT. eth2: Using NWay-set 10baseT media, csr12 000050ca. The chip on this card (Micronet SP2500K - Taiwan I think) is DEC 21143-PC: 00:08.0 Class 0200: 1011:0019 (rev 30) Subsystem: 1113:1207 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- ; Thu, 2 Sep 2004 08:28:21 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 3C4615C065; Thu, 2 Sep 2004 17:28:08 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06176-05; Thu, 2 Sep 2004 17:28:07 +0200 (CEST) Received: from sputnik (M802P011.adsl.highway.telekom.at [62.47.132.43]) by baikonur.stro.at (Postfix) with ESMTP id C08005C008; Thu, 2 Sep 2004 17:28:07 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C2tVQ-00016b-71; Thu, 02 Sep 2004 17:28:08 +0200 Date: Thu, 2 Sep 2004 17:28:08 +0200 From: maximilian attems To: Margit Schubert-While Cc: netdev@oss.sgi.com Subject: Re: [patch 01/16] __FUNCTION__ string concatenation Message-ID: <20040902152807.GA1894@stro.at> Mail-Followup-To: Margit Schubert-While , netdev@oss.sgi.com References: <200409021302.22823.margitsw@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409021302.22823.margitsw@t-online.de> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev On Thu, 02 Sep 2004, Margit Schubert-While wrote: > On Thu, 02 Sep 2004, Maximilian scribeth: > > I don't have the hardware to do a run-time check. > > It should not pose any problems though. > > Oh, I think we can safely say that, especially as TRACE > is nowhere referenced ;-) > (And therefore the patch is unnecessary) yup nice hint it was used: drivers/net/wireless/prism54/islpci_hotplug.c: /* TRACE(DRV_NAME); */ will resent patch that removes both. -- maks From andre.correa@pobox.com Thu Sep 2 08:40:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 08:40:46 -0700 (PDT) Received: from sasl.smtp.pobox.com (puzzle.sasl.smtp.pobox.com [207.8.226.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82FedSp023470 for ; Thu, 2 Sep 2004 08:40:39 -0700 Received: from localhost.localdomain (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id 9373F138F05; Thu, 2 Sep 2004 11:38:24 -0400 (EDT) Received: from pobox.com (unknown [200.150.240.34]) by puzzle.pobox.com (Postfix) with ESMTP id D8FDE138EF7; Thu, 2 Sep 2004 11:38:21 -0400 (EDT) Message-ID: <41373ED5.5070606@pobox.com> Date: Thu, 02 Sep 2004 12:40:05 -0300 From: Andre Correa User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, andre.correa@pobox.com Subject: Bad: scheduling while atomic! in 2.6.8.1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre.correa@pobox.com Precedence: bulk X-list: netdev Hi, I set up a Linux box as a firewall with 4 NICs (3C905) on a Dell with 2.6.8.1 and iptables 1.2.11. 3 NICs have several IP addresses and the 4th has 4 VLANs associated. This box is plugged on Cisco switches. Everything was fine, firewalling OK, until I plugged the 4th NIC. When traffic start to flow the box logs a _LOT_ of errors on syslog: Sep 1 03:58:48 fw01 kernel: bad: scheduling while atomic! Sep 1 03:58:48 fw01 kernel: [] schedule+0x3c/0x428 Sep 1 03:58:48 fw01 kernel: [] sys_socketcall+0x150/0x1f4 Sep 1 03:58:48 fw01 kernel: [] work_resched+0x5/0x16 Sep 1 03:58:48 fw01 kernel: bad: scheduling while atomic! Sep 1 03:58:48 fw01 kernel: [] schedule+0x3c/0x428 Sep 1 03:58:48 fw01 kernel: [] __kfree_skb+0xd3/0xd8 Sep 1 03:58:48 fw01 kernel: [] schedule_timeout+0x14/0xb0 Sep 1 03:58:48 fw01 kernel: [] unix_wait_for_peer+0xac/0xc8 Sep 1 03:58:48 fw01 kernel: [] autoremove_wake_function+0x0/0x40 Sep 1 03:58:48 fw01 kernel: [] autoremove_wake_function+0x0/0x40 Sep 1 03:58:48 fw01 kernel: [] unix_dgram_sendmsg+0x39b/0x4b0 Sep 1 03:58:48 fw01 kernel: [] sock_aio_write+0x101/0x10c Sep 1 03:58:48 fw01 kernel: [] do_sync_write+0x7a/0xac Sep 1 03:58:48 fw01 kernel: [] kfree_skbmem+0x17/0x1c Sep 1 03:58:48 fw01 kernel: [] __kfree_skb+0xd3/0xd8 Sep 1 03:58:48 fw01 kernel: [] vfs_write+0xb5/0xd4 Sep 1 03:58:48 fw01 kernel: [] sys_write+0x40/0x6c Sep 1 03:58:48 fw01 kernel: [] syscall_call+0x7/0xb Sep 1 03:58:48 fw01 kernel: bad: scheduling while atomic! Sep 1 03:58:48 fw01 kernel: [] schedule+0x3c/0x428 Sep 1 03:58:49 fw01 kernel: [] sys_socketcall+0x150/0x1f4 Sep 1 03:58:49 fw01 kernel: [] work_resched+0x5/0x16 Sep 1 03:58:49 fw01 kernel: bad: scheduling while atomic! Sep 1 03:58:49 fw01 kernel: [] schedule+0x3c/0x428 Sep 1 03:58:49 fw01 kernel: [] __kfree_skb+0xd3/0xd8 Sep 1 03:58:49 fw01 kernel: [] schedule_timeout+0x14/0xb0 Sep 1 03:58:49 fw01 kernel: [] unix_wait_for_peer+0xac/0xc8 Sep 1 03:58:49 fw01 kernel: [] autoremove_wake_function+0x0/0x40 Sep 1 03:58:49 fw01 kernel: [] autoremove_wake_function+0x0/0x40 Sep 1 03:58:49 fw01 kernel: [] unix_dgram_sendmsg+0x39b/0x4b0 Sep 1 03:58:49 fw01 kernel: [] sock_aio_write+0x101/0x10c Sep 1 03:58:49 fw01 kernel: [] do_sync_write+0x7a/0xac Sep 1 03:58:49 fw01 kernel: [] kfree_skbmem+0x17/0x1c Sep 1 03:58:49 fw01 kernel: [] __kfree_skb+0xd3/0xd8 Sep 1 03:58:49 fw01 kernel: [] vfs_write+0xb5/0xd4 Sep 1 03:58:49 fw01 kernel: [] sys_write+0x40/0x6c Sep 1 03:58:49 fw01 kernel: [] syscall_call+0x7/0xb I got more then 110Mb of it in ~2 hours of tests. Shutting down interface doesn't stop it, just a reboot takes the machine back to its normal state, if cable is unplugged. I've tested NIC, cable, PCI slot, switch port, switch and even changed the box itself, but nothing helped. When I take VLAN down, on Cisco switch, no errors are logged. If I go back to 2.6.7 + VLAN, no errors too, all OK. It seens to be related to VLAN on 2.6.8.1 only. Searching kernel source I found that it comes from kernel/sched.c, but it doesn't tells me much. /* * Test if we are atomic. Since do_exit() needs to call into * schedule() atomically, we ignore that path for now. * Otherwise, whine if we are scheduling when we should not be. */ if (likely(!(current->state & (TASK_DEAD | TASK_ZOMBIE)))) { if (unlikely(in_atomic())) { printk(KERN_ERR "bad: scheduling while atomic!\n"); dump_stack(); } } Does anybody can help on it?! Does it look like a bug or what? Any help is appreciated. tks Andre From vatsa@in.ibm.com Thu Sep 2 08:46:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 08:46:45 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82FkcoB023856 for ; Thu, 2 Sep 2004 08:46:38 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i82FkNnt734040; Thu, 2 Sep 2004 11:46:23 -0400 Received: from snowy.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with SMTP id i82FlQND083086; Thu, 2 Sep 2004 11:47:30 -0400 Received: by snowy.in.ibm.com (Postfix, from userid 502) id 7AA9B24E33; Thu, 2 Sep 2004 21:18:37 +0530 (IST) Date: Thu, 2 Sep 2004 21:18:37 +0530 From: Srivatsa Vaddagiri To: davem@redhat.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com, paulmck@us.ibm.com Subject: Fw: Re: [RFC] Use RCU for tcp_ehash lookup Message-ID: <20040902154837.GA5435@in.ibm.com> Reply-To: vatsa@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 8352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vatsa@in.ibm.com Precedence: bulk X-list: netdev Resending. Looks like my earlier mail didn't make it. ----- Forwarded message from Srivatsa Vaddagiri ----- Date: Thu, 2 Sep 2004 19:34:44 +0530 From: Srivatsa Vaddagiri To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com, paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Reply-To: vatsa@in.ibm.com On Wed, Sep 01, 2004 at 10:41:08PM -0700, David S. Miller wrote: > The reason you don't see any improvement is that the ehash table is > pretty write heavy. In my simple one-file-transfer-test-at-a-time, it should have been read-mostly. Probably the fact lookups are not serialized wrt input pakcet processing may have shadowed the benefits of lock-free lookup. However perhaps if I have multiple file transfer sessions in progress (one per cpu maybe), then the benefit of reduced time spent in looking up a socket, could be passed on to threads doing network input. > I'm not totally against your patch, I just don't think that the TCP established > hash table qualifies as "read heavy" as per what RCU is truly effective for. IMHO the benefits of lock-free will be seen only in such scenarios, i.e where read_lock ended up having to spin-wait on a update to finish. In the lock-free case, there is no such wait. > That's exactly what I was concerned about when I saw that you had attempted > this change. It is incredibly important for state changes and updates to > be seen as atomic by the packet input processing engine. It would be illegal > for a cpu running TCP input to see a socket in two tables at the same time > (for example, in the main established area and in the second half for TIME_WAIT > buckets). > > If the visibility of the socket is wrong, sockets could be erroneously > be reset during the transition from established to TIME_WAIT state. > Beware! This is precisely the reason why I changed the order of movement in __tcp_tw_hashdance. Earlier, it was removing the socket from the established half and _then_ adding it to time-wait half. This would have lead to a window where the socket is neither in established-half not in the time-wait half. A packet arriving in this window (& doing lock-free lookup) would have been dropped. Hence I reversed the order of movement to add in time-wait first before removing from established half. > > Note that __tcp_v4_lookup_established should not be affected by the above > > movement because I found it scans the established half first and _then_ the > > time wait half. So even if the same socket is present in both established half > > and time wait half, __tcp_v4_lookup_established will lookup only one of them > > (& not both). > > I hope this is true. AFAICS it is true! If __tcp_v4_lookup_established finds it in the established half, it does no further lookup in the time-wait half. -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 ----- End forwarded message ----- -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 From nacc@us.ibm.com Thu Sep 2 09:10:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 09:10:24 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82GAD75024762 for ; Thu, 2 Sep 2004 09:10:19 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i82G9p06025910; Thu, 2 Sep 2004 12:09:51 -0400 Received: from arkanoid.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i82G9oZC037834; Thu, 2 Sep 2004 10:09:50 -0600 Received: from arkanoid.beaverton.ibm.com (arkanoid [127.0.0.1]) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) with ESMTP id i82G9n0t002058; Thu, 2 Sep 2004 16:09:49 GMT Received: (from aravamud@localhost) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) id i82G9nU6002055; Thu, 2 Sep 2004 16:09:49 GMT X-Authentication-Warning: arkanoid.beaverton.ibm.com: aravamud set sender to nacc@us.ibm.com using -f Date: Thu, 2 Sep 2004 16:09:49 +0000 From: Nishanth Aravamudan To: Margit Schubert-While , netdev@oss.sgi.com, kj Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040902160948.GA1944@us.ibm.com> References: <200409020850.38177.margitsw@t-online.de> <20040902082432.GA1876@stro.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040902082432.GA1876@stro.at> X-Operating-System: Linux 2.6.73 (i686) User-Agent: Mutt/1.5.6+20040803i X-archive-position: 8353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev On Thu, Sep 02, 2004 at 10:24:33AM +0200, maximilian attems wrote: > On Thu, 02 Sep 2004, Margit Schubert-While wrote: > > > I agree with Jean and add the following : > > You are assuming HZ = 1000. > > In 2.4, HZ = 100 (And in 2.6, HZ is not necessarily = 1000). As the original author of the patches, I feel I should interject . . . Why/Where do you see an assumption about the value of HZ? The conversion of the parameter to schedule_timeout() from jiffies to msecs is the only place I can see where that might appear to be the case. But, upon closer examination, there is no such assumption: 1000 = the number of milliseconds in a second. HZ = the number of jiffies in a second (regardless of architecture) In the original code for prism54/islpci_dev.c: set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(50*HZ/1000); Thus, to convert (50*HZ/1000) from jiffies to msecs, multiply by 1000 and divide by HZ, or: 50*HZ/1000 jiffies * 1000/HZ msecs/jiffie = 50 msecs. And thus, in the patched code, the above becomes: msleep(50); Does that clear things up? -Nish From nacc@us.ibm.com Thu Sep 2 09:23:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 09:23:37 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82GNOG1025237 for ; Thu, 2 Sep 2004 09:23:31 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i82GN3gM506480; Thu, 2 Sep 2004 12:23:04 -0400 Received: from arkanoid.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i82GN2l9402682; Thu, 2 Sep 2004 10:23:03 -0600 Received: from arkanoid.beaverton.ibm.com (arkanoid [127.0.0.1]) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) with ESMTP id i82GN2Ww002105; Thu, 2 Sep 2004 16:23:02 GMT Received: (from aravamud@localhost) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) id i82GN1Bd002102; Thu, 2 Sep 2004 16:23:01 GMT X-Authentication-Warning: arkanoid.beaverton.ibm.com: aravamud set sender to nacc@us.ibm.com using -f Date: Thu, 2 Sep 2004 16:23:01 +0000 From: Nishanth Aravamudan To: Margit Schubert-While , netdev@oss.sgi.com, kj Subject: Re: [Kernel-janitors] Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040902162301.GB1944@us.ibm.com> References: <200409021135.57632.margitsw@t-online.de> <20040902100322.GD1876@stro.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040902100322.GD1876@stro.at> X-Operating-System: Linux 2.6.73 (i686) User-Agent: Mutt/1.5.6+20040803i X-archive-position: 8354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev On Thu, Sep 02, 2004 at 12:03:22PM +0200, maximilian attems wrote: > On Thu, 02 Sep 2004, Margit Schubert-While wrote: > > > On Thu, 02 Sep 2004, Maximilian scribeth: > > > it shouldn't hinder 2.6 in it's progression. > > I consider this a regression. > > As schedule_timeout is used elesewhere in the prism54 code, > > we are using a consistent and documented method. A grep of drivers/net/wireless/prism54 for schedule_timeout showed three occurrences (in 2.6.9-rc1-bk7): islpci_dev.c: schedule_timeout(50*HZ/1000); islpci_dev.c: remaining = schedule_timeout(HZ); islpci_mgt.c: timeleft = schedule_timeout(wait_cycle_jiffies); The first is removed by my patch. The second & third are potentially bugs as there is no set_current_state() preceding the call to schedule_timeout(). As per the source: /** * schedule_timeout - sleep until timeout * @timeout: timeout value in jiffies * * Make the current task sleep until @timeout jiffies have * elapsed. The routine will return immediately unless * the current task state has been set (see set_current_state()). Therefore, in the current code, the schedule_timeout() call does not have the desired effect (the same information is available in kernel-hacking.ps). Both of these calls should probably be fixed, but I'm not sure if you wish to sleep in TASK_INTERUPTIBLE or TASK_UNINTERRUPTIBLE. Keep in mind that msleep_interruptible() is also (hopefully) being pushed to the kernel soon. As to consistency or documentation . . . I have no evidence to suggest that msleep() is inconsistent. And I don't think there is any need for more documentation than the source in this case: /** * msleep - sleep safely even with waitqueue interruptions * @msecs: Time in milliseconds to sleep for */ Hope this helps clear things up. -Nish From paulmck@us.ibm.com Thu Sep 2 09:36:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 09:36:13 -0700 (PDT) Received: from linux.local (bi01p1.co.us.ibm.com [32.97.110.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82Ga0j7025740 for ; Thu, 2 Sep 2004 09:36:06 -0700 Received: by linux.local (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 4A40E148B98; Thu, 2 Sep 2004 09:31:50 -0700 (PDT) Date: Thu, 2 Sep 2004 09:31:50 -0700 From: "Paul E. McKenney" To: "David S. Miller" Cc: vatsa@in.ibm.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-ID: <20040902163149.GB1258@us.ibm.com> Reply-To: paulmck@us.ibm.com References: <20040831125941.GA5534@in.ibm.com> <20040901224108.3b2d692d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901224108.3b2d692d.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 8355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulmck@us.ibm.com Precedence: bulk X-list: netdev On Wed, Sep 01, 2004 at 10:41:08PM -0700, David S. Miller wrote: > On Tue, 31 Aug 2004 18:29:41 +0530 > Srivatsa Vaddagiri wrote: > > - Biggest problem I had converting over to RCU was the refcount race between > > sock_put and sock_hold. sock_put might see the refcount go to zero and decide > > to free the object, while on some other CPU, sock_get's are pending against > > the same object. The patch handles the race by deciding to free the object > > only from the RCU callback. > > That's exactly what I was concerned about when I saw that you had attempted > this change. It is incredibly important for state changes and updates to > be seen as atomic by the packet input processing engine. It would be illegal > for a cpu running TCP input to see a socket in two tables at the same time > (for example, in the main established area and in the second half for TIME_WAIT > buckets). > > If the visibility of the socket is wrong, sockets could be erroneously > be reset during the transition from established to TIME_WAIT state. > Beware! If the usages is too write-intensive, then RCU will certainly be less likely to work well. But there is nothing quite like actually trying it to see how it works. ;-) That aside, it -is- possible to make such state changes appear atomic, even when moving elements from one list to another. One way of doing this is to atomically replace the element with a "tombstone" element. Normal pointer writes suffice. The "tombstone" is set up so that searches for the outgoing element will stall (e.g., spin or sleep, depending on the environment). The element is moved to its destination list. At this point, searches for the element in the old list will still stall, while searches for the element in the new list will succeed. The tombstone is now marked so that CPUs stall on it now resume, but indicating failure to find the element in the old list. Of course, this approach makes writes more expensive than they otherwise would be, so, again, RCU is best for read-intensive uses. ;-) The fact that this data structure is not very read-intensive is due to the fact that short-lived TCP connections are quite common, right? Or am I missing the finer points of this data structure's workings? Thanx, Paul From margitsw@t-online.de Thu Sep 2 10:42:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 10:42:14 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82Hg9YQ027077 for ; Thu, 2 Sep 2004 10:42:09 -0700 Received: from fwd03.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1C2vay-0002NZ-00; Thu, 02 Sep 2004 19:42:00 +0200 Received: from roglap.local (rShJCvZ1oekYZs039dSpPc+qIpI7GJcpa8ZytgJ7WvedNZzrj1mEZV@[217.255.125.194]) by fwd03.sul.t-online.com with esmtp id 1C2var-0j45wm0; Thu, 2 Sep 2004 19:41:53 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: netdev@oss.sgi.com Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Date: Thu, 2 Sep 2004 19:30:18 +0200 User-Agent: KMail/1.5.4 Cc: janitor@sternwelten.at MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021930.18414.margitsw@t-online.de> X-ID: rShJCvZ1oekYZs039dSpPc+qIpI7GJcpa8ZytgJ7WvedNZzrj1mEZV X-TOI-MSGID: e1e2d3ca-1c83-40a9-a21f-7e2330d4634a X-archive-position: 8356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev On Thu, 02 Sep 2004, Nishanth scribeth: > A grep of drivers/net/wireless/prism54 for schedule_timeout showed three > occurrences (in 2.6.9-rc1-bk7): > islpci_dev.c: schedule_timeout(50*HZ/1000); > islpci_dev.c: remaining = schedule_timeout(HZ); > islpci_mgt.c: timeleft = schedule_timeout(wait_cycle_jiffies); > The first is removed by my patch. > The second & third are potentially bugs as there is no > set_current_state() preceding the call to schedule_timeout(). As per the > source: Nope, look a few lines above: DEFINE_WAIT() and prepare_to_wait(). Margit From margitsw@t-online.de Thu Sep 2 11:04:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 11:04:21 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82I4ANW027860 for ; Thu, 2 Sep 2004 11:04:11 -0700 Received: from fwd03.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1C2vwF-0006Qv-02; Thu, 02 Sep 2004 20:03:59 +0200 Received: from roglap.local (VgPdmiZvoeP7taiB8A7bbXy2sknkngKrtbSxwLtFFwgu92JIs-MOkm@[217.255.125.194]) by fwd03.sul.t-online.com with esmtp id 1C2vwE-024Pq40; Thu, 2 Sep 2004 20:03:58 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: netdev@oss.sgi.com Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Date: Thu, 2 Sep 2004 19:52:18 +0200 User-Agent: KMail/1.5.4 Cc: janitor@sternwelten.at, nacc@us.ibm.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021952.18280.margitsw@t-online.de> X-ID: VgPdmiZvoeP7taiB8A7bbXy2sknkngKrtbSxwLtFFwgu92JIs-MOkm X-TOI-MSGID: 9117e798-6f49-4eaf-b79c-44d2921846f0 X-archive-position: 8357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev On Thu, 02 Sep 2004, Nishanth scribeth: > Keep in mind that msleep_interruptible() is also > (hopefully) being pushed to the kernel soon I think you need this for your current patch set ;-) eg. In e100, where you replace an interruptible timeout: > @@ -2020,8 +2016,7 @@ I don't think that's correct. Margit From nacc@us.ibm.com Thu Sep 2 11:27:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 11:27:49 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82IRbEr028661 for ; Thu, 2 Sep 2004 11:27:43 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i82IRMDD385518; Thu, 2 Sep 2004 14:27:22 -0400 Received: from arkanoid.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i82IRLl9300046; Thu, 2 Sep 2004 12:27:21 -0600 Received: from arkanoid.beaverton.ibm.com (arkanoid [127.0.0.1]) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) with ESMTP id i82IRKjg002786; Thu, 2 Sep 2004 18:27:20 GMT Received: (from aravamud@localhost) by arkanoid.beaverton.ibm.com (8.13.1/8.13.1/Debian-6) id i82IRJaf002783; Thu, 2 Sep 2004 18:27:19 GMT X-Authentication-Warning: arkanoid.beaverton.ibm.com: aravamud set sender to nacc@us.ibm.com using -f Date: Thu, 2 Sep 2004 18:27:19 +0000 From: Nishanth Aravamudan To: Margit Schubert-While Cc: netdev@oss.sgi.com, janitor@sternwelten.at Subject: Re: [patch 8/8] prism54/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040902182719.GD1944@us.ibm.com> References: <200409021952.18280.margitsw@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409021952.18280.margitsw@t-online.de> X-Operating-System: Linux 2.6.73 (i686) User-Agent: Mutt/1.5.6+20040803i X-archive-position: 8358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev On Thu, Sep 02, 2004 at 07:52:18PM +0200, Margit Schubert-While wrote: > On Thu, 02 Sep 2004, Nishanth scribeth: > > Keep in mind that msleep_interruptible() is also > > (hopefully) being pushed to the kernel soon > > I think you need this for your current patch set ;-) > eg. In e100, where you replace an interruptible timeout: > > @@ -2020,8 +2016,7 @@ > > I don't think that's correct. The reasoning for me behind changing some of the TASK_INTERRUPTIBLE'd schedule_timeout()s to msleep()s was that LDD somewhat incorrectly advised device driver authors to use an INTERRUPTIBLE timeout for longer delays, when, in fact, they should probably use an UNINTERRUPTIBLE one. Only if signals are explicitly expected to occur is INTERRUPTIBLE necessary (in general). [By long delays, I mean those measurable in msecs] I am not an expert on the E100, so perhaps this was an error on my part. But this is also why I have a header on my patch submission regarding exactly this issue. If someone could verify (none of the maintainers I sent the original patch to did not reply with any problems for this patch) that there is or is not an issue, I'd appreciate it. -Nish From kaber@trash.net Thu Sep 2 11:36:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 11:36:58 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82IapdD029088 for ; Thu, 2 Sep 2004 11:36:52 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1C2wWi-0004h7-00; Thu, 02 Sep 2004 20:41:40 +0200 Message-ID: <4137681D.3000902@trash.net> Date: Thu, 02 Sep 2004 20:36:13 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: yoshfuji@linux-ipv6.org, Herbert Xu , netdev@oss.sgi.com Subject: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Content-Type: multipart/mixed; boundary="------------050003050700070306040006" X-archive-position: 8359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------050003050700070306040006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yoshifuji's recent fragment patch prevents unnecessary fragmentation when the data can be kept in a single packet, but only for the first packet. When fragmenting, all fragments are still truncated to multiples of 8 and we might end up creating an unnecessary fragment. This dump shows the problem (MTU 1499): 172.16.1.123.32771 > 172.16.195.3.4135: udp 2937 (frag 7066:1472@0+) 172.16.1.123 > 172.16.195.3: udp (frag 7066:1472@1472+) 172.16.1.123 > 172.16.195.3: udp (frag 7066:1@2944) This patch always builds mtu sized fragments and truncates the previous fragment to a multiple of 8 bytes when allocating a new one. With the patch the dump looks like this: 172.16.1.123.32772 > 172.16.195.3.4135: udp 2937 (frag 49641:1472@0+) 172.16.1.123 > 172.16.195.3: udp (frag 49641:1473@1472) Regards Patrick --------------050003050700070306040006 Content-Type: text/x-patch; name="frag.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="frag.diff" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/02 17:35:32+02:00 kaber@coreworks.de # [IPV4/IPV6]: Fix suboptimal fragment sizing for last fragment # # Signed-off-by: Patrick McHardy # # net/ipv6/ip6_output.c # 2004/09/02 17:35:14+02:00 kaber@coreworks.de +13 -22 # [IPV4/IPV6]: Fix suboptimal fragment sizing for last fragment # # net/ipv4/ip_output.c # 2004/09/02 17:35:14+02:00 kaber@coreworks.de +20 -49 # [IPV4/IPV6]: Fix suboptimal fragment sizing for last fragment # diff -Nru a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c --- a/net/ipv4/ip_output.c 2004-09-02 17:39:01 +02:00 +++ b/net/ipv4/ip_output.c 2004-09-02 17:39:01 +02:00 @@ -735,10 +735,10 @@ int hh_len; int exthdrlen; int mtu; - int copy = 0; + int copy; int err; int offset = 0; - unsigned int maxfraglen, fragheaderlen, fraggap = 0; + unsigned int maxfraglen, fragheaderlen; int csummode = CHECKSUM_NONE; if (flags&MSG_PROBE) @@ -781,6 +781,7 @@ hh_len = LL_RESERVED_SPACE(rt->u.dst.dev); fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0); + maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen; if (inet->cork.length + length > 0xFFFF - fragheaderlen) { ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->dport, mtu-exthdrlen); @@ -788,26 +789,11 @@ } /* - * Let's try using as much space as possible to avoid generating - * additional unnecessary small fragment of length - * (mtu-fragheaderlen)%8 if mtu-fragheaderlen is not 0 modulo 8. - * -- yoshfuji - */ - if (fragheaderlen + inet->cork.length + length <= mtu) - maxfraglen = mtu; - else - maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen; - - if (fragheaderlen + inet->cork.length <= mtu && - fragheaderlen + inet->cork.length + length > mtu) - fraggap = 1; - - /* * transhdrlen > 0 means that this is the first fragment and we wish * it won't be fragmented in the future. */ if (transhdrlen && - length + fragheaderlen <= maxfraglen && + length + fragheaderlen <= mtu && rt->u.dst.dev->features&(NETIF_F_IP_CSUM|NETIF_F_NO_CSUM|NETIF_F_HW_CSUM) && !exthdrlen) csummode = CHECKSUM_HW; @@ -821,34 +807,33 @@ * adding appropriate IP header. */ - if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) { - fraggap = 0; + if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) goto alloc_new_skb; - } while (length > 0) { - if ((copy = maxfraglen - skb->len) <= 0) { + if ((copy = mtu - skb->len) <= 0) { char *data; unsigned int datalen; unsigned int fraglen; + unsigned int fraggap; unsigned int alloclen; struct sk_buff *skb_prev; - BUG_TRAP(fraggap || copy == 0); + BUG_TRAP(copy == 0); alloc_new_skb: skb_prev = skb; + fraggap = 0; + if (skb_prev) + fraggap = mtu - maxfraglen; - if (fraggap) - fraggap = -copy; - - datalen = maxfraglen - fragheaderlen; + datalen = mtu - fragheaderlen; if (datalen > length + fraggap) datalen = length + fraggap; fraglen = datalen + fragheaderlen; if ((flags & MSG_MORE) && !(rt->u.dst.dev->features&NETIF_F_SG)) - alloclen = maxfraglen; + alloclen = mtu; else alloclen = datalen + fragheaderlen; @@ -913,7 +898,6 @@ length -= datalen - fraggap; transhdrlen = 0; exthdrlen = 0; - fraggap = 0; csummode = CHECKSUM_NONE; /* @@ -1006,7 +990,7 @@ int mtu; int len; int err; - unsigned int maxfraglen, fragheaderlen, fraggap = 0; + unsigned int maxfraglen, fragheaderlen, fraggap; if (inet->hdrincl) return -EPERM; @@ -1028,27 +1012,13 @@ mtu = inet->cork.fragsize; fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0); + maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen; if (inet->cork.length + size > 0xFFFF - fragheaderlen) { ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->dport, mtu); return -EMSGSIZE; } - /* - * Let's try using as much space as possible to avoid generating - * additional unnecessary small fragment of length - * (mtu-fragheaderlen)%8 if mtu-fragheaderlen is not 0 modulo 8. - * -- yoshfuji - */ - if (fragheaderlen + inet->cork.length + size <= mtu) - maxfraglen = mtu; - else - maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen; - - if (fragheaderlen + inet->cork.length <= mtu && - fragheaderlen + inet->cork.length + size > mtu) - fraggap = 1; - if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) return -EINVAL; @@ -1056,17 +1026,18 @@ while (size > 0) { int i; - if ((len = maxfraglen - skb->len) <= 0) { + if ((len = mtu - skb->len) <= 0) { struct sk_buff *skb_prev; char *data; struct iphdr *iph; int alloclen; - BUG_TRAP(fraggap || len == 0); + BUG_TRAP(len == 0); skb_prev = skb; - if (fraggap) - fraggap = -len; + fraggap = 0; + if (skb_prev) + fraggap = mtu - maxfraglen; alloclen = fragheaderlen + hh_len + fraggap + 15; skb = sock_wmalloc(sk, alloclen, 1, sk->sk_allocation); diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c 2004-09-02 17:39:01 +02:00 +++ b/net/ipv6/ip6_output.c 2004-09-02 17:39:01 +02:00 @@ -814,11 +814,11 @@ struct inet_opt *inet = inet_sk(sk); struct ipv6_pinfo *np = inet6_sk(sk); struct sk_buff *skb; - unsigned int maxfraglen, fragheaderlen, fraggap = 0; + unsigned int maxfraglen, fragheaderlen; int exthdrlen; int hh_len; int mtu; - int copy = 0; + int copy; int err; int offset = 0; int csummode = CHECKSUM_NONE; @@ -867,6 +867,7 @@ hh_len = LL_RESERVED_SPACE(rt->u.dst.dev); fragheaderlen = sizeof(struct ipv6hdr) + (opt ? opt->opt_nflen : 0); + maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - sizeof(struct frag_hdr); if (mtu <= sizeof(struct ipv6hdr) + IPV6_MAXPLEN) { if (inet->cork.length + length > sizeof(struct ipv6hdr) + IPV6_MAXPLEN - fragheaderlen) { @@ -883,46 +884,37 @@ * * Note that we may need to "move" the data from the tail of * of the buffer to the new fragment when we split - * the message at the first time. + * the message. * * FIXME: It may be fragmented into multiple chunks * at once if non-fragmentable extension headers * are too large. * --yoshfuji */ - if (fragheaderlen + inet->cork.length + length <= mtu) - maxfraglen = mtu; - else - maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - - sizeof(struct frag_hdr); - - if (fragheaderlen + inet->cork.length <= mtu && - fragheaderlen + inet->cork.length + length > mtu) - fraggap = 1; inet->cork.length += length; - if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) { - fraggap = 0; + if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) goto alloc_new_skb; - } while (length > 0) { - if ((copy = maxfraglen - skb->len) <= 0) { + if ((copy = mtu - skb->len) <= 0) { char *data; unsigned int datalen; unsigned int fraglen; + unsigned int fraggap; unsigned int alloclen; struct sk_buff *skb_prev; - BUG_TRAP(fraggap || copy == 0); + BUG_TRAP(copy == 0); alloc_new_skb: skb_prev = skb; /* There's no room in the current skb */ - if (fraggap) - fraggap = -copy; + fraggap = 0; + if (skb_prev) + fraggap = mtu - maxfraglen; - datalen = maxfraglen - fragheaderlen; + datalen = mtu - fragheaderlen; if (datalen > length + fraggap) datalen = length + fraggap; @@ -930,7 +922,7 @@ fraglen = datalen + fragheaderlen; if ((flags & MSG_MORE) && !(rt->u.dst.dev->features&NETIF_F_SG)) - alloclen = maxfraglen; + alloclen = mtu; else alloclen = datalen + fragheaderlen; @@ -1005,7 +997,6 @@ length -= datalen - fraggap; transhdrlen = 0; exthdrlen = 0; - fraggap = 0; csummode = CHECKSUM_NONE; /* --------------050003050700070306040006-- From yoshfuji@linux-ipv6.org Thu Sep 2 12:47:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 12:47:44 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82Jlbg2001233 for ; Thu, 2 Sep 2004 12:47:38 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1976B33CE6; Fri, 3 Sep 2004 04:48:25 +0900 (JST) Date: Fri, 03 Sep 2004 04:48:23 +0900 (JST) Message-Id: <20040903.044823.82214059.yoshfuji@linux-ipv6.org> To: kaber@trash.net Cc: davem@redhat.com, herbert@debian.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4137681D.3000902@trash.net> References: <4137681D.3000902@trash.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <4137681D.3000902@trash.net> (at Thu, 02 Sep 2004 20:36:13 +0200), Patrick McHardy says: > Yoshifuji's recent fragment patch prevents unnecessary fragmentation > when the data can be kept in a single packet, but only for the first > packet. When fragmenting, all fragments are still truncated to > multiples of 8 and we might end up creating an unnecessary fragment. > > This dump shows the problem (MTU 1499): > > 172.16.1.123.32771 > 172.16.195.3.4135: udp 2937 (frag 7066:1472@0+) > 172.16.1.123 > 172.16.195.3: udp (frag 7066:1472@1472+) > 172.16.1.123 > 172.16.195.3: udp (frag 7066:1@2944) > > This patch always builds mtu sized fragments and truncates the previous > fragment to a multiple of 8 bytes when allocating a new one. With the > patch the dump looks like this: > > > 172.16.1.123.32772 > 172.16.195.3.4135: udp 2937 (frag 49641:1472@0+) > 172.16.1.123 > 172.16.195.3: udp (frag 49641:1473@1472) Let me clarify. Are you sending payload of 2945 bytes (= udp payload of 2937 bytes)? Good point. I'll check this patch today. (Let me sleep for now...) Anyway, please update the comment instead of removing completely. Thanks. --yoshfuji From vkondra@mail.ru Thu Sep 2 13:25:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 13:26:37 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82KPolW003606 for ; Thu, 2 Sep 2004 13:25:51 -0700 Received: from [212.179.200.204] (port=14794 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C2y91-00093I-00; Fri, 03 Sep 2004 00:25:21 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Thu, 2 Sep 2004 23:24:35 +0300 User-Agent: KMail/1.7 Cc: Jeff Garzik , Denis Vlasenko , Jean Tourrilhes , Jouni Malinen , acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4134C1A7.50600@pobox.com> In-Reply-To: <4134C1A7.50600@pobox.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3883509.4mOIAh7QTs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409022324.43117.vkondra@mail.ru> X-Spam: Probable Spam X-archive-position: 8361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev --nextPart3883509.4mOIAh7QTs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Jeff, On Tuesday 31 August 2004 21:21, Jeff Garzik wrote: JG> Denis Vlasenko wrote: JG> > I think 'senior' network guys are in position to decide upon which JG> > of currently available 802.11 stacks we should continue to work. JG> > (Atheros has one, said to be derived from BSD, is there any others?) JG> JG> JG> Already have. Start with the code in wireless-2.6 -- HostAP -- and use JG> DaveM's 802.11 stack template as a model for actually integrating 802.11 JG> very tightly with the rest of the net stack. JG> JG> http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-= p8 0211.tar.bz2=20 Is this stack the main one that is going to be used? I.e. if I am working o= n=20 driver for next generation .11 card - should I try to use it, request/submi= tt=20 missing features etc.? Or should I use wireless extensions? --nextPart3883509.4mOIAh7QTs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBN4GKqxdj7mhC6o0RAsfgAJ9Nz7PdFdRc+2ywEfCEYcS+qutHsQCcCOKM JlRXzBD/qeiPNnWtwViO/VQ= =HvC8 -----END PGP SIGNATURE----- --nextPart3883509.4mOIAh7QTs-- From jgarzik@pobox.com Thu Sep 2 13:34:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 13:35:04 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82KYH72003984 for ; Thu, 2 Sep 2004 13:34:18 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C2yHC-0004JW-Dp; Thu, 02 Sep 2004 21:33:46 +0100 Message-ID: <4137839B.4000303@pobox.com> Date: Thu, 02 Sep 2004 16:33:31 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: netdev@oss.sgi.com, Denis Vlasenko , Jean Tourrilhes , Jouni Malinen , acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org, "David S. Miller" Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4134C1A7.50600@pobox.com> <200409022324.43117.vkondra@mail.ru> In-Reply-To: <200409022324.43117.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Vladimir Kondratiev wrote: > Jeff, > > On Tuesday 31 August 2004 21:21, Jeff Garzik wrote: > JG> Denis Vlasenko wrote: > JG> > I think 'senior' network guys are in position to decide upon which > JG> > of currently available 802.11 stacks we should continue to work. > JG> > (Atheros has one, said to be derived from BSD, is there any others?) > JG> > JG> > JG> Already have. Start with the code in wireless-2.6 -- HostAP -- and use > JG> DaveM's 802.11 stack template as a model for actually integrating 802.11 > JG> very tightly with the rest of the net stack. > JG> > JG> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8 > 0211.tar.bz2 > > Is this stack the main one that is going to be used? I.e. if I am working on > driver for next generation .11 card - should I try to use it, request/submitt > missing features etc.? Or should I use wireless extensions? DaveM's code is a template for how a wireless stack would look when properly and fully integrated into the net core. Although JeanT and I disagree about this, I am less interested in backwards compatibility than I am about making wireless a "first class citizen" in the kernel. As I have proven with kcompat (http://sf.net/projects/gkernel/) you can be backwards compatible while still evolving the current kernel driver API to meet current design needs. Jeff From ak@suse.de Thu Sep 2 14:20:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 14:20:55 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82LKauk004895 for ; Thu, 2 Sep 2004 14:20:37 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 85706B6C4D8; Thu, 2 Sep 2004 23:19:50 +0200 (CEST) Date: Thu, 2 Sep 2004 23:19:50 +0200 From: Andi Kleen To: Srivatsa Vaddagiri Cc: Andi Kleen , davem@redhat.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Dipankar , paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-ID: <20040902211950.GH16175@wotan.suse.de> References: <20040831125941.GA5534@in.ibm.com> <20040831135419.GA17642@wotan.suse.de> <20040901113641.GA3918@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901113641.GA3918@in.ibm.com> X-archive-position: 8363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Wed, Sep 01, 2004 at 05:06:41PM +0530, Srivatsa Vaddagiri wrote: > | 2.6.8.1 | 2.6.8.1 + my patch > ------------------------------------------------------------------------------- > Average cycles | | > spent in | | > __tcp_v4_lookup_established | 2970.65 | 668.227 > | (~3.3 micro-seconds) | (~0.74 microseconds) > ------------------------------------------------------------------------------- > > This repesents improvement by a factor of 77.5%! Nice. > > > > > > And it should also fix the performance problems with > > cat /proc/net/tcp on ppc64/ia64 for large hash tables because the rw locks > > are gone. > > But spinlocks are in! Would that still improve the performance compared to rw > locks? (See me earlier note where I have explained that lookup done for > /proc/net/tcp is _not_ lock-free yet). Yes, spinlocks are much faster than rwlocks. -Andi From davem@redhat.com Thu Sep 2 14:45:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 14:45:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82Ljpn3005512 for ; Thu, 2 Sep 2004 14:45:52 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i82LjZS0001754; Thu, 2 Sep 2004 17:45:40 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i82LjZ315553; Thu, 2 Sep 2004 17:45:35 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i82LjRBl012123; Thu, 2 Sep 2004 17:45:27 -0400 Date: Thu, 2 Sep 2004 14:44:36 -0700 From: "David S. Miller" To: Patrick McHardy Cc: yoshfuji@linux-ipv6.org, herbert@debian.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-Id: <20040902144436.2c8c1337.davem@redhat.com> In-Reply-To: <4137681D.3000902@trash.net> References: <4137681D.3000902@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 02 Sep 2004 20:36:13 +0200 Patrick McHardy wrote: > This patch always builds mtu sized fragments and truncates the previous > fragment to a multiple of 8 bytes when allocating a new one. With the > patch the dump looks like this: Looks great Patrick, applied. I see only one remaining possible improvement. If the fraggap area is paged data, we probably should try use page frags in the new SKB if this split occurs in ip_append_page(). From herbert@gondor.apana.org.au Thu Sep 2 15:04:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 15:04:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82M4HDs006026 for ; Thu, 2 Sep 2004 15:04:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C2zgK-0007pN-00; Fri, 03 Sep 2004 08:03:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C2zgG-0000vj-00; Fri, 03 Sep 2004 08:03:44 +1000 Date: Fri, 3 Sep 2004 08:03:44 +1000 To: "David S. Miller" Cc: Patrick McHardy , yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-ID: <20040902220343.GA3250@gondor.apana.org.au> References: <4137681D.3000902@trash.net> <20040902144436.2c8c1337.davem@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <20040902144436.2c8c1337.davem@redhat.com> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 02, 2004 at 02:44:36PM -0700, David S. Miller wrote: > > I see only one remaining possible improvement. If the fraggap > area is paged data, we probably should try use page frags > in the new SKB if this split occurs in ip_append_page(). Yes. That could also tie into another optimisation. But it's an ugly one :) The sk->csum values are added up at the end of the processing so when we move bytes to and fro the total csum value stays the same even if the fragment csum values change. Therefore we can get rid of the csum adjustments except for the parity bit in the getfrag call. Is this an acceptable optimisation to you guys? Another thing we can do is to not always fill up the frags in the middle and then move bytes off them. As it is if you do a send that spans multiple packets each fragment will be filled up to the full and then chopped off when the next one is started. And to finish it off, here is a really trivial patch to shave off 27 bytes from the source code :) It does nothing else, well unless your compiler decides to compile csum_block_sub out-of-line. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/ip_output.c 1.65 vs edited ===== --- 1.65/net/ipv4/ip_output.c 2004-09-02 15:07:28 +10:00 +++ edited/net/ipv4/ip_output.c 2004-09-03 07:53:54 +10:00 @@ -896,8 +896,8 @@ skb->csum = skb_copy_and_csum_bits( skb_prev, maxfraglen, data + transhdrlen, fraggap, 0); - skb_prev->csum = csum_block_sub( - skb_prev->csum, skb->csum, 0); + skb_prev->csum = csum_sub(skb_prev->csum, + skb->csum); data += fraggap; skb_trim(skb_prev, maxfraglen); } @@ -1094,8 +1094,8 @@ skb->csum = skb_copy_and_csum_bits( skb_prev, maxfraglen, data, fraggap, 0); - skb_prev->csum = csum_block_sub( - skb_prev->csum, skb->csum, 0); + skb_prev->csum = csum_sub(skb_prev->csum, + skb->csum); skb_trim(skb_prev, maxfraglen); } ===== net/ipv6/ip6_output.c 1.70 vs edited ===== --- 1.70/net/ipv6/ip6_output.c 2004-09-02 15:07:29 +10:00 +++ edited/net/ipv6/ip6_output.c 2004-09-03 07:54:41 +10:00 @@ -985,8 +985,8 @@ skb->csum = skb_copy_and_csum_bits( skb_prev, maxfraglen, data + transhdrlen, fraggap, 0); - skb_prev->csum = csum_block_sub( - skb_prev->csum, skb->csum, 0); + skb_prev->csum = csum_sub(skb_prev->csum, + skb->csum); data += fraggap; skb_trim(skb_prev, maxfraglen); } --fdj2RfSjLxBAspz7-- From keizerflipje@home.nl Thu Sep 2 15:05:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 15:06:03 -0700 (PDT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82M5tmo006283 for ; Thu, 2 Sep 2004 15:05:56 -0700 Received: from [213.51.128.135] (port=55609 helo=smtp4.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1C2ziE-0008C4-D0; Fri, 03 Sep 2004 00:05:46 +0200 Received: from cp232498-a.gelen1.lb.home.nl ([217.120.68.81]:51665 helo=[10.0.0.200]) by smtp4.home.nl with esmtp (Exim 4.30) id 1C2ziB-0002zZ-Ev; Fri, 03 Sep 2004 00:05:43 +0200 Message-ID: <41379937.5060301@home.nl> Date: Fri, 03 Sep 2004 00:05:43 +0200 From: Pascal de Bruijn User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: r8169 1.6LK lockup References: <4137418D.2040706@home.nl> <20040902174437.GA12068@electric-eye.fr.zoreil.com> In-Reply-To: <20040902174437.GA12068@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 8366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: keizerflipje@home.nl Precedence: bulk X-list: netdev Right, I've patched my kernel, and now everything works like a breeze... I enabled all features: ethtool -K eth0 rx on tx on sg on tso on Then I uploaded 10GB and downloaded about 2GB (in an alternating style). No more lockups... Good work! Thanks, Pascal de Bruijn Francois Romieu wrote: >Pascal de Bruijn : >[francois messed the r8169 update] > >How does the system perform if you apply the patches below as well: >http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc1-mm1/r8169-130.patch >http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc1-mm1/r8169-140.patch > >Please Cc: netdev@oss.sgi.com > >-- >Ueimor > > > From davem@redhat.com Thu Sep 2 15:10:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 15:10:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82M9x4x006811 for ; Thu, 2 Sep 2004 15:10:00 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i82M9US0007366; Thu, 2 Sep 2004 18:09:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i82M9T321944; Thu, 2 Sep 2004 18:09:29 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i82M9Ljj022112; Thu, 2 Sep 2004 18:09:21 -0400 Date: Thu, 2 Sep 2004 15:08:30 -0700 From: "David S. Miller" To: Herbert Xu Cc: kaber@trash.net, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-Id: <20040902150830.6585cfc5.davem@redhat.com> In-Reply-To: <20040902220343.GA3250@gondor.apana.org.au> References: <4137681D.3000902@trash.net> <20040902144436.2c8c1337.davem@redhat.com> <20040902220343.GA3250@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 3 Sep 2004 08:03:44 +1000 Herbert Xu wrote: > That could also tie into another optimisation. But it's > an ugly one :) The sk->csum values are added up at the end of > the processing so when we move bytes to and fro the total csum > value stays the same even if the fragment csum values change. > > Therefore we can get rid of the csum adjustments except for the > parity bit in the getfrag call. > > Is this an acceptable optimisation to you guys? I have no problems with this. > Another thing we can do is to not always fill up the frags in the middle > and then move bytes off them. As it is if you do a send that spans > multiple packets each fragment will be filled up to the full and then > chopped off when the next one is started. Please elaborate. > And to finish it off, here is a really trivial patch to shave off 27 > bytes from the source code :) It does nothing else, well unless your > compiler decides to compile csum_block_sub out-of-line. Applied :-) From romieu@fr.zoreil.com Thu Sep 2 16:06:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 16:06:27 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i82N6KBe007957 for ; Thu, 2 Sep 2004 16:06:21 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i82N2fvr016876; Fri, 3 Sep 2004 01:02:41 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i82N2eqD016875; Fri, 3 Sep 2004 01:02:40 +0200 Date: Fri, 3 Sep 2004 01:02:40 +0200 From: Francois Romieu To: Pascal de Bruijn Cc: netdev@oss.sgi.com Subject: Re: r8169 1.6LK lockup Message-ID: <20040902230240.GA16747@electric-eye.fr.zoreil.com> References: <4137418D.2040706@home.nl> <20040902174437.GA12068@electric-eye.fr.zoreil.com> <41379937.5060301@home.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41379937.5060301@home.nl> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Pascal de Bruijn : [fully featured patched r8169 driver] > > Then I uploaded 10GB and downloaded about 2GB (in an alternating style). > > No more lockups... > > Good work! It appears to be better but still not rock solid. Grrr... -- Ueimor From yoshfuji@linux-ipv6.org Thu Sep 2 18:40:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 18:40:10 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i831e3Wr014315 for ; Thu, 2 Sep 2004 18:40:03 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4CB4633CE6; Fri, 3 Sep 2004 10:40:51 +0900 (JST) Date: Fri, 03 Sep 2004 10:40:50 +0900 (JST) Message-Id: <20040903.104050.29603454.yoshfuji@linux-ipv6.org> To: davem@redhat.com, herbert@gondor.apana.org.au Cc: kaber@trash.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040902220343.GA3250@gondor.apana.org.au> References: <4137681D.3000902@trash.net> <20040902144436.2c8c1337.davem@redhat.com> <20040902220343.GA3250@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040902220343.GA3250@gondor.apana.org.au> (at Fri, 3 Sep 2004 08:03:44 +1000), Herbert Xu says: > Another thing we can do is to not always fill up the frags in the middle > and then move bytes off them. As it is if you do a send that spans > multiple packets each fragment will be filled up to the full and then > chopped off when the next one is started. I think I had similar impression when I saw the Patrick's patch. Here's the optimization: if we know the remaining data exceeds the mtu, we do not need to fill up full of it. skb_prev: mtu +----------+--+-+ | | | | +----------+--+-+ ^ ^ skb_prev->len | maxfraglen appending data: +--------+ | | +--------+ ---------> length In this case, we know we need more fragment(s). So, let's fill up to maxfraglen (instead of mtu) to avoid needless copy in the next loop. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/ip_output.c 1.67 vs edited ===== --- 1.67/net/ipv4/ip_output.c 2004-09-03 06:50:20 +09:00 +++ edited/net/ipv4/ip_output.c 2004-09-03 10:15:53 +09:00 @@ -811,26 +811,33 @@ goto alloc_new_skb; while (length > 0) { - if ((copy = mtu - skb->len) <= 0) { + /* Check if the remaining data fits into current packet. */ + copy = mtu - skb->len; + if (copy < length) + copy = maxfraglen - skb->len; + if (copy <= 0) { char *data; unsigned int datalen; unsigned int fraglen; unsigned int fraggap; unsigned int alloclen; struct sk_buff *skb_prev; - BUG_TRAP(copy == 0); - alloc_new_skb: skb_prev = skb; - fraggap = 0; if (skb_prev) - fraggap = mtu - maxfraglen; - - datalen = mtu - fragheaderlen; - if (datalen > length + fraggap) - datalen = length + fraggap; + fraggap = skb_prev->len - maxfraglen; + else + fraggap = 0; + /* + * If remaining data exceeds the mtu, + * we know we need more fragment(s). + */ + datalen = length + fraggap; + if (datalen > mtu - fragheaderlen) + datalen = maxfraglen - fragheaderlen; fraglen = datalen + fragheaderlen; + if ((flags & MSG_MORE) && !(rt->u.dst.dev->features&NETIF_F_SG)) alloclen = mtu; @@ -1026,18 +1033,22 @@ while (size > 0) { int i; - if ((len = mtu - skb->len) <= 0) { + + /* Check if the remaining data fits into current packet. */ + len = mtu - skb->len; + if (len > size) + len = maxfraglen - skb->len; + if (len <= 0) { struct sk_buff *skb_prev; char *data; struct iphdr *iph; int alloclen; - BUG_TRAP(len == 0); - skb_prev = skb; - fraggap = 0; if (skb_prev) - fraggap = mtu - maxfraglen; + fraggap = skb_prev->len - maxfraglen; + else + fraggap = 0; alloclen = fragheaderlen + hh_len + fraggap + 15; skb = sock_wmalloc(sk, alloclen, 1, sk->sk_allocation); ===== net/ipv6/ip6_output.c 1.72 vs edited ===== --- 1.72/net/ipv6/ip6_output.c 2004-09-03 06:50:20 +09:00 +++ edited/net/ipv6/ip6_output.c 2004-09-03 10:24:57 +09:00 @@ -898,26 +898,34 @@ goto alloc_new_skb; while (length > 0) { - if ((copy = mtu - skb->len) <= 0) { + /* Check if the remaining data fits into current packet. */ + copy = mtu - skb->len; + if (copy < length) + copy = maxfraglen - skb->len; + + if (copy <= 0) { char *data; unsigned int datalen; unsigned int fraglen; unsigned int fraggap; unsigned int alloclen; struct sk_buff *skb_prev; - BUG_TRAP(copy == 0); alloc_new_skb: skb_prev = skb; /* There's no room in the current skb */ - fraggap = 0; if (skb_prev) - fraggap = mtu - maxfraglen; - - datalen = mtu - fragheaderlen; + fraggap = skb_prev->len - maxfraglen; + else + fraggap = 0; - if (datalen > length + fraggap) - datalen = length + fraggap; + /* + * If remaining data exceeds the mtu, + * we know we need more fragment(s). + */ + datalen = length + fraggap; + if (datalen > mtu - fragheaderlen) + datalen = maxfraglen - fragheaderlen; fraglen = datalen + fragheaderlen; if ((flags & MSG_MORE) && -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From vatsa@in.ibm.com Thu Sep 2 21:04:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 21:05:05 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8344qbw020552 for ; Thu, 2 Sep 2004 21:04:53 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i8344dCR013368; Fri, 3 Sep 2004 00:04:39 -0400 Received: from snowy.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8345mND146320; Fri, 3 Sep 2004 00:05:51 -0400 Received: by snowy.in.ibm.com (Postfix, from userid 502) id ED4CD24E32; Thu, 2 Sep 2004 19:34:44 +0530 (IST) Date: Thu, 2 Sep 2004 19:34:44 +0530 From: Srivatsa Vaddagiri To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, dipankar@in.ibm.com, paulmck@us.ibm.com Subject: Re: [RFC] Use RCU for tcp_ehash lookup Message-ID: <20040902140444.GA4808@in.ibm.com> Reply-To: vatsa@in.ibm.com References: <20040831125941.GA5534@in.ibm.com> <20040901224108.3b2d692d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901224108.3b2d692d.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 8370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vatsa@in.ibm.com Precedence: bulk X-list: netdev On Wed, Sep 01, 2004 at 10:41:08PM -0700, David S. Miller wrote: > The reason you don't see any improvement is that the ehash table is > pretty write heavy. In my simple one-file-transfer-test-at-a-time, it should have been read-mostly. Probably the fact lookups are not serialized wrt input pakcet processing may have shadowed the benefits of lock-free lookup. However perhaps if I have multiple file transfer sessions in progress (one per cpu maybe), then the benefit of reduced time spent in looking up a socket, could be passed on to threads doing network input. > I'm not totally against your patch, I just don't think that the TCP established > hash table qualifies as "read heavy" as per what RCU is truly effective for. IMHO the benefits of lock-free will be seen only in such scenarios, i.e where read_lock ended up having to spin-wait on a update to finish. In the lock-free case, there is no such wait. > That's exactly what I was concerned about when I saw that you had attempted > this change. It is incredibly important for state changes and updates to > be seen as atomic by the packet input processing engine. It would be illegal > for a cpu running TCP input to see a socket in two tables at the same time > (for example, in the main established area and in the second half for TIME_WAIT > buckets). > > If the visibility of the socket is wrong, sockets could be erroneously > be reset during the transition from established to TIME_WAIT state. > Beware! This is precisely the reason why I changed the order of movement in __tcp_tw_hashdance. Earlier, it was removing the socket from the established half and _then_ adding it to time-wait half. This would have lead to a window where the socket is neither in established-half not in the time-wait half. A packet arriving in this window (& doing lock-free lookup) would have been dropped. Hence I reversed the order of movement to add in time-wait first before removing from established half. > > Note that __tcp_v4_lookup_established should not be affected by the above > > movement because I found it scans the established half first and _then_ the > > time wait half. So even if the same socket is present in both established half > > and time wait half, __tcp_v4_lookup_established will lookup only one of them > > (& not both). > > I hope this is true. AFAICS it is true! If __tcp_v4_lookup_established finds it in the established half, it does no further lookup in the time-wait half. -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 From max@stro.at Thu Sep 2 23:47:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Sep 2004 23:47:08 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i836l1Yp024411 for ; Thu, 2 Sep 2004 23:47:02 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 271885C065; Fri, 3 Sep 2004 08:46:51 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28481-06; Fri, 3 Sep 2004 08:46:50 +0200 (CEST) Received: from sputnik (M914P027.adsl.highway.telekom.at [62.47.146.59]) by baikonur.stro.at (Postfix) with ESMTP id 8A0AA5C008; Fri, 3 Sep 2004 08:46:50 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C37qV-0001Hl-Le; Fri, 03 Sep 2004 08:46:51 +0200 Date: Fri, 3 Sep 2004 08:46:51 +0200 From: maximilian attems To: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [patch] prism54 remove unused macro Message-ID: <20040903064651.GB1856@stro.at> Mail-Followup-To: netdev@oss.sgi.com, jgarzik@pobox.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev the TRACE macro was noticed because of it's string concatenation. this patch removes it as it's unused. Signed-off-by: Maximilian Attems --- linux-2.6.9-rc1-bk7-orig/drivers/net/wireless/prism54/islpci_mgt.h 2004-08-14 12:54:51.000000000 +0200 +++ linux-2.6.9-rc1-bk7/drivers/net/wireless/prism54/islpci_mgt.h 2004-09-03 08:35:30.000000000 +0200 @@ -31,8 +31,6 @@ #define K_DEBUG(f, m, args...) do { if(f & m) printk(KERN_DEBUG args); } while(0) #define DEBUG(f, args...) K_DEBUG(f, pc_debug, args) -#define TRACE(devname) K_DEBUG(SHOW_TRACING, VERBOSE, "%s: -> " __FUNCTION__ "()\n", devname) - extern int pc_debug; #define init_wds 0 /* help compiler optimize away dead code */ --- linux-2.6.9-rc1-bk7-orig/drivers/net/wireless/prism54/islpci_hotplug.c 2004-08-14 12:55:32.000000000 +0200 +++ linux-2.6.9-rc1-bk7/drivers/net/wireless/prism54/islpci_hotplug.c 2004-09-03 08:35:45.000000000 +0200 @@ -107,8 +107,6 @@ prism54_probe(struct pci_dev *pdev, cons islpci_private *priv; int rvalue; - /* TRACE(DRV_NAME); */ - /* Enable the pci device */ if (pci_enable_device(pdev)) { From laforge@netfilter.org Fri Sep 3 00:02:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 00:03:00 -0700 (PDT) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8372q8R025104 for ; Fri, 3 Sep 2004 00:02:52 -0700 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1C385p-0001iI-J5; Fri, 03 Sep 2004 09:02:42 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C385i-0000R6-LU; Fri, 03 Sep 2004 09:02:34 +0200 Date: Fri, 3 Sep 2004 09:02:34 +0200 From: Harald Welte To: David Miller Cc: Netfilter Development Mailinglist , netdev@oss.sgi.com Subject: [PATCH 2.6] 2/2: Fix NAT helper locking Message-ID: <20040903070234.GQ26263@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , David Miller , Netfilter Development Mailinglist , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CRjAHycgiaTQGSqU" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --CRjAHycgiaTQGSqU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! This is the second of a two part patch. This part fixes the locking in NAT helpers. Please apply, Thanks. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/08/08 01:40:28+02:00 kaber@coreworks.de=20 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers # =20 # There is a possible deadlock condition with conntrack/nat-helpers: # =20 # CPU1: # conntrack-helper:help: lock(private_lock) # ip_conntrack_expect_related: write_lock(ip_conntrack_lock) # =20 # CPU2: # nat-core:do_bindings: read_lock(ip_conntrack_lock) # nat-helper:help: lock(private_lock) # =20 # The lock in the nat-helper is unneccessary because the expectation # is never changed and is protected by ip_conntrack_lock. # =20 # Signed-off-by: Patrick McHardy # Signed-off-by: Harald Welte #=20 # net/ipv4/netfilter/ip_nat_irc.c # 2004/08/08 01:40:10+02:00 kaber@coreworks.de +1 -17 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # net/ipv4/netfilter/ip_nat_ftp.c # 2004/08/08 01:40:10+02:00 kaber@coreworks.de +1 -19 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # net/ipv4/netfilter/ip_conntrack_irc.c # 2004/08/08 01:40:10+02:00 kaber@coreworks.de +3 -4 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # net/ipv4/netfilter/ip_conntrack_ftp.c # 2004/08/08 01:40:10+02:00 kaber@coreworks.de +1 -2 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # include/linux/netfilter_ipv4/ip_conntrack_irc.h # 2004/08/08 01:40:10+02:00 kaber@coreworks.de +0 -5 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # include/linux/netfilter_ipv4/ip_conntrack_ftp.h # 2004/08/08 01:40:10+02:00 kaber@coreworks.de +0 -5 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 diff -Nru a/include/linux/netfilter_ipv4/ip_conntrack_ftp.h b/include/linux= /netfilter_ipv4/ip_conntrack_ftp.h --- a/include/linux/netfilter_ipv4/ip_conntrack_ftp.h 2004-08-08 01:41:23 += 02:00 +++ b/include/linux/netfilter_ipv4/ip_conntrack_ftp.h 2004-08-08 01:41:23 += 02:00 @@ -4,11 +4,6 @@ =20 #ifdef __KERNEL__ =20 -#include - -/* Protects ftp part of conntracks */ -DECLARE_LOCK_EXTERN(ip_ftp_lock); - #define FTP_PORT 21 =20 #endif /* __KERNEL__ */ diff -Nru a/include/linux/netfilter_ipv4/ip_conntrack_irc.h b/include/linux= /netfilter_ipv4/ip_conntrack_irc.h --- a/include/linux/netfilter_ipv4/ip_conntrack_irc.h 2004-08-08 01:41:23 += 02:00 +++ b/include/linux/netfilter_ipv4/ip_conntrack_irc.h 2004-08-08 01:41:23 += 02:00 @@ -33,12 +33,7 @@ =20 #ifdef __KERNEL__ =20 -#include - #define IRC_PORT 6667 - -/* Protects irc part of conntracks */ -DECLARE_LOCK_EXTERN(ip_irc_lock); =20 #endif /* __KERNEL__ */ =20 diff -Nru a/net/ipv4/netfilter/ip_conntrack_ftp.c b/net/ipv4/netfilter/ip_c= onntrack_ftp.c --- a/net/ipv4/netfilter/ip_conntrack_ftp.c 2004-08-08 01:41:23 +02:00 +++ b/net/ipv4/netfilter/ip_conntrack_ftp.c 2004-08-08 01:41:23 +02:00 @@ -27,7 +27,7 @@ /* This is slow, but it's simple. --RR */ static char ftp_buffer[65536]; =20 -DECLARE_LOCK(ip_ftp_lock); +static DECLARE_LOCK(ip_ftp_lock); struct module *ip_conntrack_ftp =3D THIS_MODULE; =20 #define MAX_PORTS 8 @@ -455,7 +455,6 @@ } =20 PROVIDES_CONNTRACK(ftp); -EXPORT_SYMBOL(ip_ftp_lock); =20 module_init(init); module_exit(fini); diff -Nru a/net/ipv4/netfilter/ip_conntrack_irc.c b/net/ipv4/netfilter/ip_c= onntrack_irc.c --- a/net/ipv4/netfilter/ip_conntrack_irc.c 2004-08-08 01:41:23 +02:00 +++ b/net/ipv4/netfilter/ip_conntrack_irc.c 2004-08-08 01:41:23 +02:00 @@ -40,6 +40,7 @@ static unsigned int dcc_timeout =3D 300; /* This is slow, but it's simple. --RR */ static char irc_buffer[65536]; +static DECLARE_LOCK(irc_buffer_lock); =20 MODULE_AUTHOR("Harald Welte "); MODULE_DESCRIPTION("IRC (DCC) connection tracking helper"); @@ -54,7 +55,6 @@ static char *dccprotos[] =3D { "SEND ", "CHAT ", "MOVE ", "TSEND ", "SCHAT= " }; #define MINMATCHLEN 5 =20 -DECLARE_LOCK(ip_irc_lock); struct module *ip_conntrack_irc =3D THIS_MODULE; =20 #if 0 @@ -134,7 +134,7 @@ if (dataoff >=3D skb->len) return NF_ACCEPT; =20 - LOCK_BH(&ip_irc_lock); + LOCK_BH(&irc_buffer_lock); skb_copy_bits(skb, dataoff, irc_buffer, skb->len - dataoff); =20 data =3D irc_buffer; @@ -227,7 +227,7 @@ } /* while data < ... */ =20 out: - UNLOCK_BH(&ip_irc_lock); + UNLOCK_BH(&irc_buffer_lock); return NF_ACCEPT; } =20 @@ -302,7 +302,6 @@ } =20 PROVIDES_CONNTRACK(irc); -EXPORT_SYMBOL(ip_irc_lock); =20 module_init(init); module_exit(fini); diff -Nru a/net/ipv4/netfilter/ip_nat_ftp.c b/net/ipv4/netfilter/ip_nat_ftp= =2Ec --- a/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 01:41:23 +02:00 +++ b/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 01:41:23 +02:00 @@ -35,8 +35,6 @@ =20 MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_PORTS) "i"); =20 -DECLARE_LOCK_EXTERN(ip_ftp_lock); - /* FIXME: Time out? --RR */ =20 static unsigned int @@ -59,8 +57,6 @@ DEBUGP("nat_expected: We have a connection!\n"); exp_ftp_info =3D &ct->master->help.exp_ftp_info; =20 - LOCK_BH(&ip_ftp_lock); - if (exp_ftp_info->ftptype =3D=3D IP_CT_FTP_PORT || exp_ftp_info->ftptype =3D=3D IP_CT_FTP_EPRT) { /* PORT command: make connection go to the client. */ @@ -75,7 +71,6 @@ DEBUGP("nat_expected: PASV cmd. %u.%u.%u.%u->%u.%u.%u.%u\n", NIPQUAD(newsrcip), NIPQUAD(newdstip)); } - UNLOCK_BH(&ip_ftp_lock); =20 if (HOOK2MANIP(hooknum) =3D=3D IP_NAT_MANIP_SRC) newip =3D newsrcip; @@ -111,8 +106,6 @@ { char buffer[sizeof("nnn,nnn,nnn,nnn,nnn,nnn")]; =20 - MUST_BE_LOCKED(&ip_ftp_lock); - sprintf(buffer, "%u,%u,%u,%u,%u,%u", NIPQUAD(newip), port>>8, port&0xFF); =20 @@ -134,8 +127,6 @@ { char buffer[sizeof("|1|255.255.255.255|65535|")]; =20 - MUST_BE_LOCKED(&ip_ftp_lock); - sprintf(buffer, "|1|%u.%u.%u.%u|%u|", NIPQUAD(newip), port); =20 DEBUGP("calling ip_nat_mangle_tcp_packet\n"); @@ -156,8 +147,6 @@ { char buffer[sizeof("|||65535|")]; =20 - MUST_BE_LOCKED(&ip_ftp_lock); - sprintf(buffer, "|||%u|", port); =20 DEBUGP("calling ip_nat_mangle_tcp_packet\n"); @@ -189,7 +178,6 @@ u_int16_t port; struct ip_conntrack_tuple newtuple; =20 - MUST_BE_LOCKED(&ip_ftp_lock); DEBUGP("FTP_NAT: seq %u + %u in %u\n", expect->seq, exp_ftp_info->len, ntohl(tcph->seq)); @@ -268,15 +256,12 @@ } =20 datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; - LOCK_BH(&ip_ftp_lock); /* If it's in the right range... */ if (between(exp->seq + exp_ftp_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!ftp_data_fixup(exp_ftp_info, ct, pskb, ctinfo, exp)) { - UNLOCK_BH(&ip_ftp_lock); + if (!ftp_data_fixup(exp_ftp_info, ct, pskb, ctinfo, exp)) return NF_DROP; - } } else { /* Half a match? This means a partial retransmisison. It's a cracker being funky. */ @@ -286,11 +271,8 @@ ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } - UNLOCK_BH(&ip_ftp_lock); return NF_DROP; } - UNLOCK_BH(&ip_ftp_lock); - return NF_ACCEPT; } =20 diff -Nru a/net/ipv4/netfilter/ip_nat_irc.c b/net/ipv4/netfilter/ip_nat_irc= =2Ec --- a/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 01:41:23 +02:00 +++ b/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 01:41:23 +02:00 @@ -44,9 +44,6 @@ MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_PORTS) "i"); MODULE_PARM_DESC(ports, "port numbers of IRC servers"); =20 -/* protects irc part of conntracks */ -DECLARE_LOCK_EXTERN(ip_irc_lock); - /* FIXME: Time out? --RR */ =20 static unsigned int @@ -102,8 +99,6 @@ /* "4294967296 65635 " */ char buffer[18]; =20 - MUST_BE_LOCKED(&ip_irc_lock); - DEBUGP("IRC_NAT: info (seq %u + %u) in %u\n", expect->seq, exp_irc_info->len, ntohl(tcph->seq)); @@ -111,11 +106,6 @@ newip =3D ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip; =20 /* Alter conntrack's expectations. */ - - /* We can read expect here without conntrack lock, since it's - only set in ip_conntrack_irc, with ip_irc_lock held - writable */ - t =3D expect->tuple; t.dst.ip =3D newip; for (port =3D exp_irc_info->port; port !=3D 0; port++) { @@ -185,15 +175,12 @@ DEBUGP("got beyond not touching\n"); =20 datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; - LOCK_BH(&ip_irc_lock); /* Check whether the whole IP/address pattern is carried in the payload */ if (between(exp->seq + exp_irc_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!irc_data_fixup(exp_irc_info, ct, pskb, ctinfo, exp)) { - UNLOCK_BH(&ip_irc_lock); + if (!irc_data_fixup(exp_irc_info, ct, pskb, ctinfo, exp)) return NF_DROP; - } } else {=20 /* Half a match? This means a partial retransmisison. It's a cracker being funky. */ @@ -204,11 +191,8 @@ ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } - UNLOCK_BH(&ip_irc_lock); return NF_DROP; } - UNLOCK_BH(&ip_irc_lock); - return NF_ACCEPT; } =20 --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --CRjAHycgiaTQGSqU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOBcKXaXGVTD0i/8RAt9bAJ9mgosYQaErcJ6v/8dofPmfdB+HPwCcC+hu q/G+Xbg03/ej1aGUj2zhWSE= =+hPN -----END PGP SIGNATURE----- --CRjAHycgiaTQGSqU-- From laforge@netfilter.org Fri Sep 3 00:04:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 00:04:21 -0700 (PDT) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8374ElJ025288 for ; Fri, 3 Sep 2004 00:04:14 -0700 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1C387A-0001kd-FJ; Fri, 03 Sep 2004 09:04:05 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C3873-0000RP-M4; Fri, 03 Sep 2004 09:03:57 +0200 Date: Fri, 3 Sep 2004 09:03:57 +0200 From: Harald Welte To: David Miller Cc: Netfilter Development Mailinglist , netdev@oss.sgi.com Subject: [PATCH 2.4] 1/2: Rename NAT helper structures Message-ID: <20040903070357.GR26263@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , David Miller , Netfilter Development Mailinglist , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bxF9Dep5HzwGj9mC" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --bxF9Dep5HzwGj9mC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! This is the first of a two part patch. Part one fixes confusing naming of some NAT helper data structures (ct_ are part of ip_conntrack, exp_ are part of ip_conntrack_expect). This patch is required to make the second apply, which fixes NAT helper locking. Please apply, thanks. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/08/08 12:26:16+02:00 kaber@coreworks.de=20 # [NETFILTER]: Fix confusing naming in NAT-helpers # =20 # Signed-off-by: Patrick McHardy # Signed-off-by: Harald Welte #=20 # net/ipv4/netfilter/ip_nat_irc.c # 2004/08/08 12:26:12+02:00 kaber@coreworks.de +9 -9 # [NETFILTER]: Fix confusing naming in NAT-helpers #=20 # net/ipv4/netfilter/ip_nat_ftp.c # 2004/08/08 12:26:12+02:00 kaber@coreworks.de +12 -12 # [NETFILTER]: Fix confusing naming in NAT-helpers #=20 diff -Nru a/net/ipv4/netfilter/ip_nat_ftp.c b/net/ipv4/netfilter/ip_nat_ftp= =2Ec --- a/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 12:49:36 +02:00 +++ b/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 12:49:36 +02:00 @@ -166,7 +166,7 @@ [IP_CT_FTP_EPSV] mangle_epsv_packet }; =20 -static int ftp_data_fixup(const struct ip_ct_ftp_expect *ct_ftp_info, +static int ftp_data_fixup(const struct ip_ct_ftp_expect *exp_ftp_info, struct ip_conntrack *ct, struct sk_buff **pskb, enum ip_conntrack_info ctinfo, @@ -180,13 +180,13 @@ =20 MUST_BE_LOCKED(&ip_ftp_lock); DEBUGP("FTP_NAT: seq %u + %u in %u\n", - expect->seq, ct_ftp_info->len, + expect->seq, exp_ftp_info->len, ntohl(tcph->seq)); =20 /* Change address inside packet to match way we're mapping this connection. */ - if (ct_ftp_info->ftptype =3D=3D IP_CT_FTP_PASV - || ct_ftp_info->ftptype =3D=3D IP_CT_FTP_EPSV) { + if (exp_ftp_info->ftptype =3D=3D IP_CT_FTP_PASV + || exp_ftp_info->ftptype =3D=3D IP_CT_FTP_EPSV) { /* PASV/EPSV response: must be where client thinks server is */ newip =3D ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.ip; @@ -208,7 +208,7 @@ newtuple.src.u.tcp.port =3D expect->tuple.src.u.tcp.port; =20 /* Try to get same port: if not, try to change it. */ - for (port =3D ct_ftp_info->port; port !=3D 0; port++) { + for (port =3D exp_ftp_info->port; port !=3D 0; port++) { newtuple.dst.u.tcp.port =3D htons(port); =20 if (ip_conntrack_change_expect(expect, &newtuple) =3D=3D 0) @@ -217,9 +217,9 @@ if (port =3D=3D 0) return 0; =20 - if (!mangle[ct_ftp_info->ftptype](pskb, newip, port, + if (!mangle[exp_ftp_info->ftptype](pskb, newip, port, expect->seq - ntohl(tcph->seq), - ct_ftp_info->len, ct, ctinfo)) + exp_ftp_info->len, ct, ctinfo)) return 0; =20 return 1; @@ -236,12 +236,12 @@ struct tcphdr *tcph =3D (void *)iph + iph->ihl*4; unsigned int datalen; int dir; - struct ip_ct_ftp_expect *ct_ftp_info; + struct ip_ct_ftp_expect *exp_ftp_info; =20 if (!exp) DEBUGP("ip_nat_ftp: no exp!!"); =20 - ct_ftp_info =3D &exp->help.exp_ftp_info; + exp_ftp_info =3D &exp->help.exp_ftp_info; =20 /* Only mangle things once: original direction in POST_ROUTING and reply direction on PRE_ROUTING. */ @@ -259,10 +259,10 @@ datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; LOCK_BH(&ip_ftp_lock); /* If it's in the right range... */ - if (between(exp->seq + ct_ftp_info->len, + if (between(exp->seq + exp_ftp_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!ftp_data_fixup(ct_ftp_info, ct, pskb, ctinfo, exp)) { + if (!ftp_data_fixup(exp_ftp_info, ct, pskb, ctinfo, exp)) { UNLOCK_BH(&ip_ftp_lock); return NF_DROP; } @@ -271,7 +271,7 @@ It's a cracker being funky. */ if (net_ratelimit()) { printk("FTP_NAT: partial packet %u/%u in %u/%u\n", - exp->seq, ct_ftp_info->len, + exp->seq, exp_ftp_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } diff -Nru a/net/ipv4/netfilter/ip_nat_irc.c b/net/ipv4/netfilter/ip_nat_irc= =2Ec --- a/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 12:49:36 +02:00 +++ b/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 12:49:36 +02:00 @@ -89,7 +89,7 @@ return ip_nat_setup_info(ct, &mr, hooknum); } =20 -static int irc_data_fixup(const struct ip_ct_irc_expect *ct_irc_info, +static int irc_data_fixup(const struct ip_ct_irc_expect *exp_irc_info, struct ip_conntrack *ct, struct sk_buff **pskb, enum ip_conntrack_info ctinfo, @@ -107,7 +107,7 @@ MUST_BE_LOCKED(&ip_irc_lock); =20 DEBUGP("IRC_NAT: info (seq %u + %u) in %u\n", - expect->seq, ct_irc_info->len, + expect->seq, exp_irc_info->len, ntohl(tcph->seq)); =20 newip =3D ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip; @@ -120,7 +120,7 @@ =20 t =3D expect->tuple; t.dst.ip =3D newip; - for (port =3D ct_irc_info->port; port !=3D 0; port++) { + for (port =3D exp_irc_info->port; port !=3D 0; port++) { t.dst.u.tcp.port =3D htons(port); if (ip_conntrack_change_expect(expect, &t) =3D=3D 0) { DEBUGP("using port %d", port); @@ -150,7 +150,7 @@ =20 return ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,=20 expect->seq - ntohl(tcph->seq), - ct_irc_info->len, buffer,=20 + exp_irc_info->len, buffer,=20 strlen(buffer)); } =20 @@ -165,12 +165,12 @@ struct tcphdr *tcph =3D (void *) iph + iph->ihl * 4; unsigned int datalen; int dir; - struct ip_ct_irc_expect *ct_irc_info; + struct ip_ct_irc_expect *exp_irc_info; =20 if (!exp) DEBUGP("ip_nat_irc: no exp!!"); =09 - ct_irc_info =3D &exp->help.exp_irc_info; + exp_irc_info =3D &exp->help.exp_irc_info; =20 /* Only mangle things once: original direction in POST_ROUTING and reply direction on PRE_ROUTING. */ @@ -189,10 +189,10 @@ datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; LOCK_BH(&ip_irc_lock); /* Check wether the whole IP/address pattern is carried in the payload */ - if (between(exp->seq + ct_irc_info->len, + if (between(exp->seq + exp_irc_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!irc_data_fixup(ct_irc_info, ct, pskb, ctinfo, exp)) { + if (!irc_data_fixup(exp_irc_info, ct, pskb, ctinfo, exp)) { UNLOCK_BH(&ip_irc_lock); return NF_DROP; } @@ -202,7 +202,7 @@ if (net_ratelimit()) { printk ("IRC_NAT: partial packet %u/%u in %u/%u\n", - exp->seq, ct_irc_info->len, + exp->seq, exp_irc_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --bxF9Dep5HzwGj9mC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOBddXaXGVTD0i/8RAjD2AJ0d2eu3tiW8CgGBQmfLfMQ6fMsXjQCff2qV iiENgsMIUj+DlK6U5GumqEc= =F4Nx -----END PGP SIGNATURE----- --bxF9Dep5HzwGj9mC-- From laforge@netfilter.org Fri Sep 3 00:05:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 00:05:21 -0700 (PDT) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8375BQr025559 for ; Fri, 3 Sep 2004 00:05:12 -0700 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1C3885-0001kx-Km; Fri, 03 Sep 2004 09:05:02 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C387z-0000Rd-1u; Fri, 03 Sep 2004 09:04:55 +0200 Date: Fri, 3 Sep 2004 09:04:55 +0200 From: Harald Welte To: David Miller Cc: Netfilter Development Mailinglist , netdev@oss.sgi.com Subject: [PATCH 2.4] 2/2: Fix NAT helper locking Message-ID: <20040903070455.GS26263@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , David Miller , Netfilter Development Mailinglist , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qgEfXXHyyarqcYJd" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --qgEfXXHyyarqcYJd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! This is the second of a two part patch. This part fixes the locking in NAT helpers. Please apply, Thanks. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/08/08 12:49:20+02:00 kaber@coreworks.de=20 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers # =20 # There is a possible deadlock condition with conntrack/nat-helpers: # =20 # CPU1: # conntrack-helper:help: lock(private_lock) # ip_conntrack_expect_related: write_lock(ip_conntrack_lock) # =20 # CPU2: # nat-core:do_bindings: read_lock(ip_conntrack_lock) # nat-helper:help: lock(private_lock) # =20 # The lock in the nat-helper is unneccessary because the expectation # is never changed and is protected by ip_conntrack_lock. # =20 # Signed-off-by: Patrick McHardy # Signed-off-by: Harald Welte #=20 # net/ipv4/netfilter/ip_nat_irc.c # 2004/08/08 12:49:15+02:00 kaber@coreworks.de +1 -17 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # net/ipv4/netfilter/ip_nat_ftp.c # 2004/08/08 12:49:15+02:00 kaber@coreworks.de +1 -19 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # net/ipv4/netfilter/ip_conntrack_irc.c # 2004/08/08 12:49:15+02:00 kaber@coreworks.de +0 -8 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # net/ipv4/netfilter/ip_conntrack_ftp.c # 2004/08/08 12:49:15+02:00 kaber@coreworks.de +3 -6 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # include/linux/netfilter_ipv4/ip_conntrack_irc.h # 2004/08/08 12:49:15+02:00 kaber@coreworks.de +0 -5 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 # include/linux/netfilter_ipv4/ip_conntrack_ftp.h # 2004/08/08 12:49:15+02:00 kaber@coreworks.de +0 -5 # [NETFILTER]: Fix deadlock condition in conntrack/nat-helpers #=20 diff -Nru a/include/linux/netfilter_ipv4/ip_conntrack_ftp.h b/include/linux= /netfilter_ipv4/ip_conntrack_ftp.h --- a/include/linux/netfilter_ipv4/ip_conntrack_ftp.h 2004-08-08 12:49:45 += 02:00 +++ b/include/linux/netfilter_ipv4/ip_conntrack_ftp.h 2004-08-08 12:49:45 += 02:00 @@ -4,11 +4,6 @@ =20 #ifdef __KERNEL__ =20 -#include - -/* Protects ftp part of conntracks */ -DECLARE_LOCK_EXTERN(ip_ftp_lock); - #define FTP_PORT 21 =20 #endif /* __KERNEL__ */ diff -Nru a/include/linux/netfilter_ipv4/ip_conntrack_irc.h b/include/linux= /netfilter_ipv4/ip_conntrack_irc.h --- a/include/linux/netfilter_ipv4/ip_conntrack_irc.h 2004-08-08 12:49:45 += 02:00 +++ b/include/linux/netfilter_ipv4/ip_conntrack_irc.h 2004-08-08 12:49:45 += 02:00 @@ -33,17 +33,12 @@ =20 #ifdef __KERNEL__ =20 -#include - #define IRC_PORT 6667 =20 struct dccproto { char* match; int matchlen; }; - -/* Protects irc part of conntracks */ -DECLARE_LOCK_EXTERN(ip_irc_lock); =20 #endif /* __KERNEL__ */ =20 diff -Nru a/net/ipv4/netfilter/ip_conntrack_ftp.c b/net/ipv4/netfilter/ip_c= onntrack_ftp.c --- a/net/ipv4/netfilter/ip_conntrack_ftp.c 2004-08-08 12:49:45 +02:00 +++ b/net/ipv4/netfilter/ip_conntrack_ftp.c 2004-08-08 12:49:45 +02:00 @@ -11,7 +11,7 @@ #include #include =20 -DECLARE_LOCK(ip_ftp_lock); +static DECLARE_LOCK(ip_ftp_lock); struct module *ip_conntrack_ftp =3D THIS_MODULE; =20 #define MAX_PORTS 8 @@ -338,7 +338,6 @@ memset(&expect, 0, sizeof(expect)); =20 /* Update the ftp info */ - LOCK_BH(&ip_ftp_lock); if (htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3= ]) =3D=3D ct->tuplehash[dir].tuple.src.ip) { exp->seq =3D ntohl(tcph->seq) + matchoff; @@ -358,7 +357,8 @@ for reporting this potential problem (DMZ machines opening holes to internal networks, or the packet filter itself). */ - if (!loose) goto out; + if (!loose) + return NF_ACCEPT; } =20 exp->tuple =3D ((struct ip_conntrack_tuple) @@ -376,9 +376,6 @@ =20 /* Ignore failure; should only happen with NAT */ ip_conntrack_expect_related(ct, &expect); - out: - UNLOCK_BH(&ip_ftp_lock); - return NF_ACCEPT; } =20 diff -Nru a/net/ipv4/netfilter/ip_conntrack_irc.c b/net/ipv4/netfilter/ip_c= onntrack_irc.c --- a/net/ipv4/netfilter/ip_conntrack_irc.c 2004-08-08 12:49:45 +02:00 +++ b/net/ipv4/netfilter/ip_conntrack_irc.c 2004-08-08 12:49:45 +02:00 @@ -29,7 +29,6 @@ #include #include =20 -#include #include #include =20 @@ -61,7 +60,6 @@ }; #define MINMATCHLEN 5 =20 -DECLARE_LOCK(ip_irc_lock); struct module *ip_conntrack_irc =3D THIS_MODULE; =20 #if 0 @@ -208,8 +206,6 @@ =09 memset(&expect, 0, sizeof(expect)); =20 - LOCK_BH(&ip_irc_lock); - /* save position of address in dcc string, * neccessary for NAT */ DEBUGP("tcph->seq =3D %u\n", tcph->seq); @@ -236,8 +232,6 @@ ntohs(exp->tuple.dst.u.tcp.port)); =20 ip_conntrack_expect_related(ct, &expect); - UNLOCK_BH(&ip_irc_lock); - return NF_ACCEPT; } /* for .. NUM_DCCPROTO */ } /* while data < ... */ @@ -314,8 +308,6 @@ ip_conntrack_helper_unregister(&irc_helpers[i]); } } - -EXPORT_SYMBOL(ip_irc_lock); =20 module_init(init); module_exit(fini); diff -Nru a/net/ipv4/netfilter/ip_nat_ftp.c b/net/ipv4/netfilter/ip_nat_ftp= =2Ec --- a/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 12:49:45 +02:00 +++ b/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 12:49:45 +02:00 @@ -24,8 +24,6 @@ MODULE_PARM(ports, "1-" __MODULE_STRING(MAX_PORTS) "i"); #endif =20 -DECLARE_LOCK_EXTERN(ip_ftp_lock); - /* FIXME: Time out? --RR */ =20 static unsigned int @@ -48,8 +46,6 @@ DEBUGP("nat_expected: We have a connection!\n"); exp_ftp_info =3D &ct->master->help.exp_ftp_info; =20 - LOCK_BH(&ip_ftp_lock); - if (exp_ftp_info->ftptype =3D=3D IP_CT_FTP_PORT || exp_ftp_info->ftptype =3D=3D IP_CT_FTP_EPRT) { /* PORT command: make connection go to the client. */ @@ -64,7 +60,6 @@ DEBUGP("nat_expected: PASV cmd. %u.%u.%u.%u->%u.%u.%u.%u\n", NIPQUAD(newsrcip), NIPQUAD(newdstip)); } - UNLOCK_BH(&ip_ftp_lock); =20 if (HOOK2MANIP(hooknum) =3D=3D IP_NAT_MANIP_SRC) newip =3D newsrcip; @@ -100,8 +95,6 @@ { char buffer[sizeof("nnn,nnn,nnn,nnn,nnn,nnn")]; =20 - MUST_BE_LOCKED(&ip_ftp_lock); - sprintf(buffer, "%u,%u,%u,%u,%u,%u", NIPQUAD(newip), port>>8, port&0xFF); =20 @@ -123,8 +116,6 @@ { char buffer[sizeof("|1|255.255.255.255|65535|")]; =20 - MUST_BE_LOCKED(&ip_ftp_lock); - sprintf(buffer, "|1|%u.%u.%u.%u|%u|", NIPQUAD(newip), port); =20 DEBUGP("calling ip_nat_mangle_tcp_packet\n"); @@ -145,8 +136,6 @@ { char buffer[sizeof("|||65535|")]; =20 - MUST_BE_LOCKED(&ip_ftp_lock); - sprintf(buffer, "|||%u|", port); =20 DEBUGP("calling ip_nat_mangle_tcp_packet\n"); @@ -178,7 +167,6 @@ u_int16_t port; struct ip_conntrack_tuple newtuple; =20 - MUST_BE_LOCKED(&ip_ftp_lock); DEBUGP("FTP_NAT: seq %u + %u in %u\n", expect->seq, exp_ftp_info->len, ntohl(tcph->seq)); @@ -257,15 +245,12 @@ } =20 datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; - LOCK_BH(&ip_ftp_lock); /* If it's in the right range... */ if (between(exp->seq + exp_ftp_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!ftp_data_fixup(exp_ftp_info, ct, pskb, ctinfo, exp)) { - UNLOCK_BH(&ip_ftp_lock); + if (!ftp_data_fixup(exp_ftp_info, ct, pskb, ctinfo, exp)) return NF_DROP; - } } else { /* Half a match? This means a partial retransmisison. It's a cracker being funky. */ @@ -275,11 +260,8 @@ ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } - UNLOCK_BH(&ip_ftp_lock); return NF_DROP; } - UNLOCK_BH(&ip_ftp_lock); - return NF_ACCEPT; } =20 diff -Nru a/net/ipv4/netfilter/ip_nat_irc.c b/net/ipv4/netfilter/ip_nat_irc= =2Ec --- a/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 12:49:45 +02:00 +++ b/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 12:49:45 +02:00 @@ -46,9 +46,6 @@ MODULE_PARM_DESC(ports, "port numbers of IRC servers"); #endif =20 -/* protects irc part of conntracks */ -DECLARE_LOCK_EXTERN(ip_irc_lock); - /* FIXME: Time out? --RR */ =20 static unsigned int @@ -104,8 +101,6 @@ /* "4294967296 65635 " */ char buffer[18]; =20 - MUST_BE_LOCKED(&ip_irc_lock); - DEBUGP("IRC_NAT: info (seq %u + %u) in %u\n", expect->seq, exp_irc_info->len, ntohl(tcph->seq)); @@ -113,11 +108,6 @@ newip =3D ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip; =20 /* Alter conntrack's expectations. */ - - /* We can read expect here without conntrack lock, since it's - only set in ip_conntrack_irc, with ip_irc_lock held - writable */ - t =3D expect->tuple; t.dst.ip =3D newip; for (port =3D exp_irc_info->port; port !=3D 0; port++) { @@ -187,15 +177,12 @@ DEBUGP("got beyond not touching\n"); =20 datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; - LOCK_BH(&ip_irc_lock); /* Check wether the whole IP/address pattern is carried in the payload */ if (between(exp->seq + exp_irc_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!irc_data_fixup(exp_irc_info, ct, pskb, ctinfo, exp)) { - UNLOCK_BH(&ip_irc_lock); + if (!irc_data_fixup(exp_irc_info, ct, pskb, ctinfo, exp)) return NF_DROP; - } } else {=20 /* Half a match? This means a partial retransmisison. It's a cracker being funky. */ @@ -206,11 +193,8 @@ ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } - UNLOCK_BH(&ip_irc_lock); return NF_DROP; } - UNLOCK_BH(&ip_irc_lock); - return NF_ACCEPT; } =20 --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --qgEfXXHyyarqcYJd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOBeXXaXGVTD0i/8RAjEuAJ41bNu5bI3O7R6UJQskFf5wGN5G9QCfbGDk Joq5HfUvLv0Fokn9mwXPG50= =aVT1 -----END PGP SIGNATURE----- --qgEfXXHyyarqcYJd-- From laforge@netfilter.org Fri Sep 3 00:06:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 00:06:13 -0700 (PDT) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83762W2025812 for ; Fri, 3 Sep 2004 00:06:02 -0700 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1C388u-0001lP-Oc; Fri, 03 Sep 2004 09:05:53 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C388p-0000Rs-Jh; Fri, 03 Sep 2004 09:05:47 +0200 Date: Fri, 3 Sep 2004 09:05:47 +0200 From: Harald Welte To: Netfilter Development Mailinglist Cc: netdev@oss.sgi.com Subject: [PATCH 2.6] 1/2: Rename NAT helper structures Message-ID: <20040903070547.GT26263@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Netfilter Development Mailinglist , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ca23f2aBZR6YDKM9" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --Ca23f2aBZR6YDKM9 Content-Type: multipart/mixed; boundary="ngiTnHdmUEG79yp6" Content-Disposition: inline --ngiTnHdmUEG79yp6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I forgot to Cc' the lists with this part of the patchset, here is the forwarded message: --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --ngiTnHdmUEG79yp6 Content-Type: message/rfc822 Content-Disposition: inline Date: Fri, 3 Sep 2004 09:00:17 +0200 From: Harald Welte To: David Miller Subject: [PATCH 2.6] 1/2: Rename NAT helper structures Message-ID: <20040903070017.GP26263@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6eUvXotnMb6+obQB" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i --6eUvXotnMb6+obQB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! This is the first of a two part patch. Part one fixes confusing naming of some NAT helper data structures (ct_ are part of ip_conntrack, exp_ are part of ip_conntrack_expect). This patch is required to make the second apply, which fixes NAT helper locking. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/08/07 23:30:12+02:00 kaber@coreworks.de=20 # [NETFILTER]: Fix confusing naming in NAT-helpers # # Signed-off-by: Patrick McHardy # Signed-off-by: Harald Welte #=20 # net/ipv4/netfilter/ip_nat_irc.c # 2004/08/07 23:29:48+02:00 kaber@coreworks.de +9 -9 # [NETFILTER]: Fix confusing naming in NAT-helpers #=20 # net/ipv4/netfilter/ip_nat_ftp.c # 2004/08/07 23:29:48+02:00 kaber@coreworks.de +12 -12 # [NETFILTER]: Fix confusing naming in NAT-helpers #=20 diff -Nru a/net/ipv4/netfilter/ip_nat_ftp.c b/net/ipv4/netfilter/ip_nat_ftp= =2Ec --- a/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 01:41:06 +02:00 +++ b/net/ipv4/netfilter/ip_nat_ftp.c 2004-08-08 01:41:06 +02:00 @@ -177,7 +177,7 @@ [IP_CT_FTP_EPSV] =3D mangle_epsv_packet }; =20 -static int ftp_data_fixup(const struct ip_ct_ftp_expect *ct_ftp_info, +static int ftp_data_fixup(const struct ip_ct_ftp_expect *exp_ftp_info, struct ip_conntrack *ct, struct sk_buff **pskb, enum ip_conntrack_info ctinfo, @@ -191,13 +191,13 @@ =20 MUST_BE_LOCKED(&ip_ftp_lock); DEBUGP("FTP_NAT: seq %u + %u in %u\n", - expect->seq, ct_ftp_info->len, + expect->seq, exp_ftp_info->len, ntohl(tcph->seq)); =20 /* Change address inside packet to match way we're mapping this connection. */ - if (ct_ftp_info->ftptype =3D=3D IP_CT_FTP_PASV - || ct_ftp_info->ftptype =3D=3D IP_CT_FTP_EPSV) { + if (exp_ftp_info->ftptype =3D=3D IP_CT_FTP_PASV + || exp_ftp_info->ftptype =3D=3D IP_CT_FTP_EPSV) { /* PASV/EPSV response: must be where client thinks server is */ newip =3D ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.ip; @@ -219,7 +219,7 @@ newtuple.src.u.tcp.port =3D expect->tuple.src.u.tcp.port; =20 /* Try to get same port: if not, try to change it. */ - for (port =3D ct_ftp_info->port; port !=3D 0; port++) { + for (port =3D exp_ftp_info->port; port !=3D 0; port++) { newtuple.dst.u.tcp.port =3D htons(port); =20 if (ip_conntrack_change_expect(expect, &newtuple) =3D=3D 0) @@ -228,9 +228,9 @@ if (port =3D=3D 0) return 0; =20 - if (!mangle[ct_ftp_info->ftptype](pskb, newip, port, + if (!mangle[exp_ftp_info->ftptype](pskb, newip, port, expect->seq - ntohl(tcph->seq), - ct_ftp_info->len, ct, ctinfo)) + exp_ftp_info->len, ct, ctinfo)) return 0; =20 return 1; @@ -247,12 +247,12 @@ struct tcphdr *tcph =3D (void *)iph + iph->ihl*4; unsigned int datalen; int dir; - struct ip_ct_ftp_expect *ct_ftp_info; + struct ip_ct_ftp_expect *exp_ftp_info; =20 if (!exp) DEBUGP("ip_nat_ftp: no exp!!"); =20 - ct_ftp_info =3D &exp->help.exp_ftp_info; + exp_ftp_info =3D &exp->help.exp_ftp_info; =20 /* Only mangle things once: original direction in POST_ROUTING and reply direction on PRE_ROUTING. */ @@ -270,10 +270,10 @@ datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; LOCK_BH(&ip_ftp_lock); /* If it's in the right range... */ - if (between(exp->seq + ct_ftp_info->len, + if (between(exp->seq + exp_ftp_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!ftp_data_fixup(ct_ftp_info, ct, pskb, ctinfo, exp)) { + if (!ftp_data_fixup(exp_ftp_info, ct, pskb, ctinfo, exp)) { UNLOCK_BH(&ip_ftp_lock); return NF_DROP; } @@ -282,7 +282,7 @@ It's a cracker being funky. */ if (net_ratelimit()) { printk("FTP_NAT: partial packet %u/%u in %u/%u\n", - exp->seq, ct_ftp_info->len, + exp->seq, exp_ftp_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } diff -Nru a/net/ipv4/netfilter/ip_nat_irc.c b/net/ipv4/netfilter/ip_nat_irc= =2Ec --- a/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 01:41:06 +02:00 +++ b/net/ipv4/netfilter/ip_nat_irc.c 2004-08-08 01:41:06 +02:00 @@ -87,7 +87,7 @@ return ip_nat_setup_info(ct, &mr, hooknum); } =20 -static int irc_data_fixup(const struct ip_ct_irc_expect *ct_irc_info, +static int irc_data_fixup(const struct ip_ct_irc_expect *exp_irc_info, struct ip_conntrack *ct, struct sk_buff **pskb, enum ip_conntrack_info ctinfo, @@ -105,7 +105,7 @@ MUST_BE_LOCKED(&ip_irc_lock); =20 DEBUGP("IRC_NAT: info (seq %u + %u) in %u\n", - expect->seq, ct_irc_info->len, + expect->seq, exp_irc_info->len, ntohl(tcph->seq)); =20 newip =3D ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.ip; @@ -118,7 +118,7 @@ =20 t =3D expect->tuple; t.dst.ip =3D newip; - for (port =3D ct_irc_info->port; port !=3D 0; port++) { + for (port =3D exp_irc_info->port; port !=3D 0; port++) { t.dst.u.tcp.port =3D htons(port); if (ip_conntrack_change_expect(expect, &t) =3D=3D 0) { DEBUGP("using port %d", port); @@ -148,7 +148,7 @@ =20 return ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,=20 expect->seq - ntohl(tcph->seq), - ct_irc_info->len, buffer,=20 + exp_irc_info->len, buffer,=20 strlen(buffer)); } =20 @@ -163,12 +163,12 @@ struct tcphdr *tcph =3D (void *) iph + iph->ihl * 4; unsigned int datalen; int dir; - struct ip_ct_irc_expect *ct_irc_info; + struct ip_ct_irc_expect *exp_irc_info; =20 if (!exp) DEBUGP("ip_nat_irc: no exp!!"); =09 - ct_irc_info =3D &exp->help.exp_irc_info; + exp_irc_info =3D &exp->help.exp_irc_info; =20 /* Only mangle things once: original direction in POST_ROUTING and reply direction on PRE_ROUTING. */ @@ -187,10 +187,10 @@ datalen =3D (*pskb)->len - iph->ihl * 4 - tcph->doff * 4; LOCK_BH(&ip_irc_lock); /* Check whether the whole IP/address pattern is carried in the payload */ - if (between(exp->seq + ct_irc_info->len, + if (between(exp->seq + exp_irc_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen)) { - if (!irc_data_fixup(ct_irc_info, ct, pskb, ctinfo, exp)) { + if (!irc_data_fixup(exp_irc_info, ct, pskb, ctinfo, exp)) { UNLOCK_BH(&ip_irc_lock); return NF_DROP; } @@ -200,7 +200,7 @@ if (net_ratelimit()) { printk ("IRC_NAT: partial packet %u/%u in %u/%u\n", - exp->seq, ct_irc_info->len, + exp->seq, exp_irc_info->len, ntohl(tcph->seq), ntohl(tcph->seq) + datalen); } --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --6eUvXotnMb6+obQB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOBaBXaXGVTD0i/8RAotRAJ90N4o+BXwF6PAX/6OQANliZbjCggCgquzv tIf1zDcRfMVMkcFaTJTcVpI= =zNZp -----END PGP SIGNATURE----- --6eUvXotnMb6+obQB-- --ngiTnHdmUEG79yp6-- --Ca23f2aBZR6YDKM9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOBfLXaXGVTD0i/8RAvWeAJ9cvcIu6ttmq5c5FpcZDQywBqlc8QCeJn44 c0xfFnKWBmgfVAoQS8qkUrM= =VeXZ -----END PGP SIGNATURE----- --Ca23f2aBZR6YDKM9-- From davem@davemloft.net Fri Sep 3 00:26:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 00:26:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i837QCP7030073 for ; Fri, 3 Sep 2004 00:26:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C38RJ-0008SX-00; Fri, 03 Sep 2004 00:24:53 -0700 Date: Fri, 3 Sep 2004 00:24:53 -0700 From: "David S. Miller" To: Harald Welte Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] 2/2: Fix NAT helper locking Message-Id: <20040903002453.77beee16.davem@davemloft.net> In-Reply-To: <20040903070234.GQ26263@sunbeam.de.gnumonks.org> References: <20040903070234.GQ26263@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 3 Sep 2004 09:02:34 +0200 Harald Welte wrote: > This is the second of a two part patch. > > This part fixes the locking in NAT helpers. > > Please apply, Thanks. Applied both patches, but the first had serious offsets and the second had to be applied by hand due to rejects against the current 2.6.x sources. Ummm... wow what ancient tree did you patch against Harald? The tree you patched against didn't even have the skb_header_pointer() changes in it, that's caveman era :-) That's what caused the rejects. Anyways, I merged it all in cleanly. Thanks. From davem@davemloft.net Fri Sep 3 00:28:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 00:28:37 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i837SUaF030315 for ; Fri, 3 Sep 2004 00:28:30 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C38TY-0008TQ-00; Fri, 03 Sep 2004 00:27:12 -0700 Date: Fri, 3 Sep 2004 00:27:12 -0700 From: "David S. Miller" To: Harald Welte Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.4] 2/2: Fix NAT helper locking Message-Id: <20040903002712.4fdf8194.davem@davemloft.net> In-Reply-To: <20040903070455.GS26263@sunbeam.de.gnumonks.org> References: <20040903070455.GS26263@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 3 Sep 2004 09:04:55 +0200 Harald Welte wrote: > This is the second of a two part patch. > > This part fixes the locking in NAT helpers. These 2.4.x variants of the NAT locking fixes are applied as well. Thanks. From herbert@gondor.apana.org.au Fri Sep 3 06:37:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 06:37:13 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83Db1Yk015955 for ; Fri, 3 Sep 2004 06:37:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C3EEu-0005sv-00; Fri, 03 Sep 2004 23:36:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C3EEp-000630-00; Fri, 03 Sep 2004 23:36:23 +1000 Date: Fri, 3 Sep 2004 23:36:23 +1000 To: "David S. Miller" Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-ID: <20040903133623.GA23179@gondor.apana.org.au> References: <20040814050848.GA11874@gondor.apana.org.au> <20040814062703.GA4806@gondor.apana.org.au> <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> <20040901222118.0ce4bcc6.davem@davemloft.net> <20040902130605.GA32570@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20040902130605.GA32570@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 02, 2004 at 11:06:05PM +1000, herbert wrote: > > > Can you work on the next bit you mentioned, making > > sure the corresponding idev is still alive when we add > > a neighbour with its neigh_parms to the hash table? > > Sure. Actually I prefer to do it by ref counting neigh_parms directly. > I'll send you a patch soon. Here is the patch. I've added a refcnt on neigh_parms as well as a dead flag. The latter is checked under the tbl_lock before adding a neigh entry to the hash table. The non-trivial bit of the patch is the first chunk of net/core/neighbour.c. I removed that line because not doing so would mean that I have to drop the reference to the parms right there. That would've lead to race conditions since many places dereference neigh->parms without holding locks. It's also unnecessary to reset n->parms since we're no longer in a hurry to see it go due to the new ref counting. You'll also notice that I've put all dereferences of dev->*_ptr under the rcu_read_lock(). Without this we may get a neigh_parms that's already been released. Incidentally a lot of these places were racy even before the RCU change. For example, in the IPv6 case neigh->parms may be set to a value that's just been released. Finally in order to make sure that all stale entries are purged as quickly as possible I've added neigh_ifdown/arp_ifdown calls after every neigh_parms_release call. In many cases we now have multiple calls to neigh_ifdown in the shutdown path. I didn't remove the earlier calls because there may be hidden dependencies for them to be there. Once the respective maintainers have looked at them we can probably remove most of them. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/s390/net/qeth_main.c 1.13 vs edited ===== --- 1.13/drivers/s390/net/qeth_main.c 2004-08-27 17:02:36 +10:00 +++ edited/drivers/s390/net/qeth_main.c 2004-09-03 23:16:30 +10:00 @@ -6710,19 +6710,28 @@ qeth_arp_constructor(struct neighbour *neigh) { struct net_device *dev = neigh->dev; - struct in_device *in_dev = in_dev_get(dev); + struct in_device *in_dev; + struct neigh_parms *parms; - if (in_dev == NULL) - return -EINVAL; if (!qeth_verify_dev(dev)) { - in_dev_put(in_dev); return qeth_old_arp_constructor(neigh); } + rcu_read_lock(); + in_dev = __in_dev_get(dev); + if (in_dev == NULL) { + rcu_read_unlock(); + return -EINVAL; + } + + parms = in_dev->arp_parms; + if (parms) { + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); + } + rcu_read_unlock(); + neigh->type = inet_addr_type(*(u32 *) neigh->primary_key); - if (in_dev->arp_parms) - neigh->parms = in_dev->arp_parms; - in_dev_put(in_dev); neigh->nud_state = NUD_NOARP; neigh->ops = arp_direct_ops; neigh->output = neigh->ops->queue_xmit; ===== include/net/neighbour.h 1.9 vs edited ===== --- 1.9/include/net/neighbour.h 2004-09-02 15:03:13 +10:00 +++ edited/include/net/neighbour.h 2004-09-03 23:15:51 +10:00 @@ -67,6 +67,8 @@ void *sysctl_table; + int dead; + atomic_t refcnt; struct rcu_head rcu_head; int base_reachable_time; @@ -199,6 +201,7 @@ extern struct neigh_parms *neigh_parms_alloc(struct net_device *dev, struct neigh_table *tbl); extern void neigh_parms_release(struct neigh_table *tbl, struct neigh_parms *parms); +extern void neigh_parms_destroy(struct neigh_parms *parms); extern unsigned long neigh_rand_reach_time(unsigned long base); extern void pneigh_enqueue(struct neigh_table *tbl, struct neigh_parms *p, @@ -219,6 +222,23 @@ char *p_name, proc_handler *proc_handler); extern void neigh_sysctl_unregister(struct neigh_parms *p); + +static inline void __neigh_parms_put(struct neigh_parms *parms) +{ + atomic_dec(&parms->refcnt); +} + +static inline void neigh_parms_put(struct neigh_parms *parms) +{ + if (atomic_dec_and_test(&parms->refcnt)) + neigh_parms_destroy(parms); +} + +static inline struct neigh_parms *neigh_parms_clone(struct neigh_parms *parms) +{ + atomic_inc(&parms->refcnt); + return parms; +} /* * Neighbour references ===== net/atm/clip.c 1.36 vs edited ===== --- 1.36/net/atm/clip.c 2004-08-16 12:05:46 +10:00 +++ edited/net/atm/clip.c 2004-09-03 23:16:55 +10:00 @@ -26,6 +26,7 @@ #include #include #include +#include #include /* for struct rtable and routing */ #include /* icmp_send */ #include /* for HZ */ @@ -311,13 +312,27 @@ { struct atmarp_entry *entry = NEIGH2ENTRY(neigh); struct net_device *dev = neigh->dev; - struct in_device *in_dev = dev->ip_ptr; + struct in_device *in_dev; + struct neigh_parms *parms; DPRINTK("clip_constructor (neigh %p, entry %p)\n",neigh,entry); - if (!in_dev) return -EINVAL; neigh->type = inet_addr_type(entry->ip); if (neigh->type != RTN_UNICAST) return -EINVAL; - if (in_dev->arp_parms) neigh->parms = in_dev->arp_parms; + + rcu_read_lock(); + in_dev = __in_dev_get(dev); + if (!in_dev) { + rcu_read_unlock(); + return -EINVAL; + } + + parms = in_dev->arp_parms; + if (parms) { + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); + } + rcu_read_unlock(); + neigh->ops = &clip_neigh_ops; neigh->output = neigh->nud_state & NUD_VALID ? neigh->ops->connected_output : neigh->ops->output; ===== net/core/neighbour.c 1.29 vs edited ===== --- 1.29/net/core/neighbour.c 2004-09-02 15:03:13 +10:00 +++ edited/net/core/neighbour.c 2004-09-03 23:17:17 +10:00 @@ -227,7 +227,6 @@ we must kill timers etc. and move it to safe state. */ - n->parms = &tbl->parms; skb_queue_purge(&n->arp_queue); n->output = neigh_blackhole; if (n->nud_state & NUD_VALID) @@ -273,7 +272,7 @@ n->updated = n->used = now; n->nud_state = NUD_NONE; n->output = neigh_blackhole; - n->parms = &tbl->parms; + n->parms = neigh_parms_clone(&tbl->parms); init_timer(&n->timer); n->timer.function = neigh_timer_handler; n->timer.data = (unsigned long)n; @@ -340,12 +339,16 @@ hash_val = tbl->hash(pkey, dev); write_lock_bh(&tbl->lock); + if (n->parms->dead) { + rc = ERR_PTR(-EINVAL); + goto out_tbl_unlock; + } + for (n1 = tbl->hash_buckets[hash_val]; n1; n1 = n1->next) { if (dev == n1->dev && !memcmp(n1->primary_key, pkey, key_len)) { neigh_hold(n1); - write_unlock_bh(&tbl->lock); rc = n1; - goto out_neigh_release; + goto out_tbl_unlock; } } @@ -358,6 +361,8 @@ rc = n; out: return rc; +out_tbl_unlock: + write_unlock_bh(&tbl->lock); out_neigh_release: neigh_release(n); goto out; @@ -494,6 +499,7 @@ skb_queue_purge(&neigh->arp_queue); dev_put(neigh->dev); + neigh_parms_put(neigh->parms); NEIGH_PRINTK2("neigh %p is destroyed.\n", neigh); @@ -1120,6 +1126,7 @@ if (p) { memcpy(p, &tbl->parms, sizeof(*p)); p->tbl = tbl; + atomic_set(&p->refcnt, 1); INIT_RCU_HEAD(&p->rcu_head); p->reachable_time = neigh_rand_reach_time(p->base_reachable_time); @@ -1141,7 +1148,7 @@ struct neigh_parms *parms = container_of(head, struct neigh_parms, rcu_head); - kfree(parms); + neigh_parms_put(parms); } void neigh_parms_release(struct neigh_table *tbl, struct neigh_parms *parms) @@ -1154,6 +1161,7 @@ for (p = &tbl->parms.next; *p; p = &(*p)->next) { if (*p == parms) { *p = parms->next; + parms->dead = 1; write_unlock_bh(&tbl->lock); call_rcu(&parms->rcu_head, neigh_rcu_free_parms); return; @@ -1163,11 +1171,17 @@ NEIGH_PRINTK1("neigh_parms_release: not found\n"); } +void neigh_parms_destroy(struct neigh_parms *parms) +{ + kfree(parms); +} + void neigh_table_init(struct neigh_table *tbl) { unsigned long now = jiffies; + atomic_set(&tbl->parms.refcnt, 1); INIT_RCU_HEAD(&tbl->parms.rcu_head); tbl->parms.reachable_time = neigh_rand_reach_time(tbl->parms.base_reachable_time); ===== net/decnet/dn_dev.c 1.24 vs edited ===== --- 1.24/net/decnet/dn_dev.c 2004-08-19 07:36:05 +10:00 +++ edited/net/decnet/dn_dev.c 2004-09-03 22:19:04 +10:00 @@ -1215,6 +1215,7 @@ dev->dn_ptr = NULL; neigh_parms_release(&dn_neigh_table, dn_db->neigh_parms); + neigh_ifdown(&dn_neigh_table, dev); if (dn_db->router) neigh_release(dn_db->router); ===== net/decnet/dn_neigh.c 1.10 vs edited ===== --- 1.10/net/decnet/dn_neigh.c 2004-01-26 16:13:52 +11:00 +++ edited/net/decnet/dn_neigh.c 2004-09-03 23:17:26 +10:00 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -134,13 +135,22 @@ { struct net_device *dev = neigh->dev; struct dn_neigh *dn = (struct dn_neigh *)neigh; - struct dn_dev *dn_db = (struct dn_dev *)dev->dn_ptr; + struct dn_dev *dn_db; + struct neigh_parms *parms; - if (dn_db == NULL) + rcu_read_lock(); + dn_db = dev->dn_ptr; + if (dn_db == NULL) { + rcu_read_unlock(); return -EINVAL; + } - if (dn_db->neigh_parms) - neigh->parms = dn_db->neigh_parms; + parms = dn_db->neigh_parms; + if (parms) { + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); + } + rcu_read_unlock(); if (dn_db->use_long) neigh->ops = &dn_long_ops; ===== net/ipv4/arp.c 1.43 vs edited ===== --- 1.43/net/ipv4/arp.c 2004-09-02 11:12:37 +10:00 +++ edited/net/ipv4/arp.c 2004-09-03 23:17:42 +10:00 @@ -96,6 +96,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -237,16 +238,24 @@ { u32 addr = *(u32*)neigh->primary_key; struct net_device *dev = neigh->dev; - struct in_device *in_dev = in_dev_get(dev); - - if (in_dev == NULL) - return -EINVAL; + struct in_device *in_dev; + struct neigh_parms *parms; neigh->type = inet_addr_type(addr); - if (in_dev->arp_parms) - neigh->parms = in_dev->arp_parms; - in_dev_put(in_dev); + rcu_read_lock(); + in_dev = __in_dev_get(dev); + if (in_dev == NULL) { + rcu_read_unlock(); + return -EINVAL; + } + + parms = in_dev->arp_parms; + if (parms) { + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); + } + rcu_read_unlock(); if (dev->hard_header == NULL) { neigh->nud_state = NUD_NOARP; ===== net/ipv4/devinet.c 1.36 vs edited ===== --- 1.36/net/ipv4/devinet.c 2004-08-16 16:11:59 +10:00 +++ edited/net/ipv4/devinet.c 2004-09-03 22:19:04 +10:00 @@ -184,6 +184,7 @@ static void inetdev_destroy(struct in_device *in_dev) { struct in_ifaddr *ifa; + struct net_device *dev; ASSERT_RTNL(); @@ -200,12 +201,15 @@ devinet_sysctl_unregister(&in_dev->cnf); #endif - in_dev->dev->ip_ptr = NULL; + dev = in_dev->dev; + dev->ip_ptr = NULL; #ifdef CONFIG_SYSCTL neigh_sysctl_unregister(in_dev->arp_parms); #endif neigh_parms_release(&arp_tbl, in_dev->arp_parms); + arp_ifdown(dev); + call_rcu(&in_dev->rcu_head, in_dev_rcu_put); } ===== net/ipv6/addrconf.c 1.106 vs edited ===== --- 1.106/net/ipv6/addrconf.c 2004-08-17 12:25:06 +10:00 +++ edited/net/ipv6/addrconf.c 2004-09-03 23:04:03 +10:00 @@ -2072,6 +2072,7 @@ neigh_sysctl_unregister(idev->nd_parms); #endif neigh_parms_release(&nd_tbl, idev->nd_parms); + neigh_ifdown(&nd_tbl, dev); in6_dev_put(idev); } return 0; ===== net/ipv6/ndisc.c 1.87 vs edited ===== --- 1.87/net/ipv6/ndisc.c 2004-08-08 16:43:41 +10:00 +++ edited/net/ipv6/ndisc.c 2004-09-03 23:17:56 +10:00 @@ -58,6 +58,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -284,14 +285,23 @@ { struct in6_addr *addr = (struct in6_addr*)&neigh->primary_key; struct net_device *dev = neigh->dev; - struct inet6_dev *in6_dev = in6_dev_get(dev); + struct inet6_dev *in6_dev; + struct neigh_parms *parms; int is_multicast = ipv6_addr_is_multicast(addr); - if (in6_dev == NULL) + rcu_read_lock(); + in6_dev = in6_dev_get(dev); + if (in6_dev == NULL) { + rcu_read_unlock(); return -EINVAL; + } - if (in6_dev->nd_parms) - neigh->parms = in6_dev->nd_parms; + parms = in6_dev->nd_parms; + if (parms) { + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); + } + rcu_read_unlock(); neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST; if (dev->hard_header == NULL) { --huq684BweRXVnRxX-- From stigge@antcom.de Fri Sep 3 07:07:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 07:07:30 -0700 (PDT) Received: from stigge.org (pD9E7EEC6.dip.t-dialin.net [217.231.238.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83E7NSE017083 for ; Fri, 3 Sep 2004 07:07:25 -0700 Received: (qmail 20881 invoked from network); 3 Sep 2004 14:07:07 -0000 Received: from unknown (HELO atari.stigge.org) (192.168.1.99) by sbo.stigge.org with SMTP; 3 Sep 2004 14:07:07 -0000 Received: from localhost (localhost [127.0.0.1]) by atari.stigge.org (Postfix) with ESMTP id D788910034F50; Fri, 3 Sep 2004 16:07:06 +0200 (CEST) Subject: Re: Debian #240812 - tg3 problems with NFS From: Roland Stigge To: "David S. Miller" Cc: Christoph Hellwig , netdev@oss.sgi.com, 240812@bugs.debian.org In-Reply-To: <20040819102941.70c94182.davem@redhat.com> References: <20040819161933.GA27114@lst.de> <20040819170619.GA28226@lst.de> <20040819102941.70c94182.davem@redhat.com> Content-Type: text/plain Organization: Antcom Message-Id: <1094220426.4139.5.camel@atari.stigge.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 16:07:06 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 8379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: stigge@antcom.de Precedence: bulk X-list: netdev On Thu, 2004-08-19 at 19:29, David S. Miller wrote: > Maybe it's checksum offload related. Try: > > ethtool -K $(DEVICE_NAME) rx off tx off sg off tso off > > Does that make the problem go away? No. From kaber@trash.net Fri Sep 3 08:54:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 08:54:17 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83FsAOE024381 for ; Fri, 3 Sep 2004 08:54:11 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1C3GSf-0007b8-00; Fri, 03 Sep 2004 17:58:49 +0200 Message-ID: <41389371.2030009@trash.net> Date: Fri, 03 Sep 2004 17:53:21 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Harald Welte , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] 2/2: Fix NAT helper locking References: <20040903070234.GQ26263@sunbeam.de.gnumonks.org> <20040903002453.77beee16.davem@davemloft.net> In-Reply-To: <20040903002453.77beee16.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev David S. Miller wrote: >Applied both patches, but the first had serious offsets >and the second had to be applied by hand due to rejects >against the current 2.6.x sources. > >Ummm... wow what ancient tree did you patch against >Harald? The tree you patched against didn't even have the >skb_header_pointer() changes in it, that's caveman >era :-) That's what caused the rejects. > > My fault, I put the patches into patch-o-matic about two or three weeks ago and didn't expect they wouldn't apply anymore so quickly :) > >Anyways, I merged it all in cleanly. > Thanks. Patrick From shemminger@osdl.org Fri Sep 3 09:01:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 09:01:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83G1Npv024802 for ; Fri, 3 Sep 2004 09:01:24 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i83G0r120723; Fri, 3 Sep 2004 09:00:53 -0700 Date: Fri, 3 Sep 2004 09:00:53 -0700 From: Stephen Hemminger To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-Id: <20040903090053.22c67bb9@dell_ss3.pdx.osdl.net> In-Reply-To: <20040903133623.GA23179@gondor.apana.org.au> References: <20040814050848.GA11874@gondor.apana.org.au> <20040814062703.GA4806@gondor.apana.org.au> <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> <20040901222118.0ce4bcc6.davem@davemloft.net> <20040902130605.GA32570@gondor.apana.org.au> <20040903133623.GA23179@gondor.apana.org.au> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 3 Sep 2004 23:36:23 +1000 Herbert Xu wrote: > On Thu, Sep 02, 2004 at 11:06:05PM +1000, herbert wrote: > > > > > Can you work on the next bit you mentioned, making > > > sure the corresponding idev is still alive when we add > > > a neighbour with its neigh_parms to the hash table? > > > > Sure. Actually I prefer to do it by ref counting neigh_parms directly. > > I'll send you a patch soon. > > Here is the patch. > > I've added a refcnt on neigh_parms as well as a dead flag. The latter > is checked under the tbl_lock before adding a neigh entry to the hash > table. > > The non-trivial bit of the patch is the first chunk of net/core/neighbour.c. > I removed that line because not doing so would mean that I have to drop > the reference to the parms right there. That would've lead to race > conditions since many places dereference neigh->parms without holding > locks. It's also unnecessary to reset n->parms since we're no longer > in a hurry to see it go due to the new ref counting. > > You'll also notice that I've put all dereferences of dev->*_ptr under > the rcu_read_lock(). Without this we may get a neigh_parms that's > already been released. I haven't looked at the exact code in detail, but don't you need use rcu_dereference() as well to make sure and get the smp_read_barrier_depends on Alpha. From davem@davemloft.net Fri Sep 3 09:19:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 09:20:00 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83GJsow025997 for ; Fri, 3 Sep 2004 09:19:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C3GlW-0001oW-00; Fri, 03 Sep 2004 09:18:18 -0700 Date: Fri, 3 Sep 2004 09:18:17 -0700 From: "David S. Miller" To: Herbert Xu Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-Id: <20040903091817.7b97d090.davem@davemloft.net> In-Reply-To: <20040903133623.GA23179@gondor.apana.org.au> References: <20040814050848.GA11874@gondor.apana.org.au> <20040814062703.GA4806@gondor.apana.org.au> <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> <20040901222118.0ce4bcc6.davem@davemloft.net> <20040902130605.GA32570@gondor.apana.org.au> <20040903133623.GA23179@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 3 Sep 2004 23:36:23 +1000 Herbert Xu wrote: > Here is the patch. Looks great. Yes, I see how the existing cases were racey pre-RCU, it is similar to the sysctl stuff and that area was truly horrible before Stephen and myself redid how generic device destruction works. Patch applied, thanks Herbert. From jeffpc@optonline.net Fri Sep 3 10:07:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 10:07:18 -0700 (PDT) Received: from mta8.srv.hcvlny.cv.net (mta8.srv.hcvlny.cv.net [167.206.5.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83H7BYf027180 for ; Fri, 3 Sep 2004 10:07:11 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta8.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H001KI67Q2C@mta8.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 13:07:02 -0400 (EDT) Date: Fri, 03 Sep 2004 13:06:55 -0400 From: josef Jeff Sipek Subject: [PATCH/RFC 2.6] NET: 64-bit network statistics To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Message-id: <200409031307.01240.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 X-archive-position: 8384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've created a patch that monitors changes to the network statistics variables and keeps internal 64-bit counter. I decided to split it into two parts (patches are to follow in next emails): 1) generic variable monitoring system (watch64) The watch64 system allows the programmer to specify the approximate interval at which he wants his variables checked. If he tries to specify shorter interval than the minimum a default value of HZ/10 is used. To minimize locking, RCU and seqlock are used. On 64-bit systems, all is optimized away. 2) network statistics specific patch (64network) Upon registration of a network device, all the statistics variables are registered with watch64. Additionally, a new proc file is created /proc/net/dev64 displays the 64-bit values as supposed to /proc/net/dev which is left to display the original 32-bit variables for backward compatibility. The sysfs interface (/sys/class/net//statistics/*) displays the 64-bit values only. On 64-bit systems, all is optimized away through watch64. Josef "Jeff" Sipek. - -- *NOTE: This message is ROT-13 encrypted twice for extra protection* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOKSzwFP0+seVj/4RAkz7AJ0Ut21nPMkHGKv1dXK17yoA5hQ1+ACglpMq IHh+tYW3innmwjlA7EU2x78= =LnHg -----END PGP SIGNATURE----- From Rezwanul_Kabir@Dell.com Fri Sep 3 10:06:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 10:06:22 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83H6H0F027153 for ; Fri, 3 Sep 2004 10:06:18 -0700 Received: from ausx2kcpc115.aus.amer.dell.com (10.166.84.69) by ausc60pc101.us.dell.com with ESMTP; 03 Sep 2004 12:06:05 -0500 X-Ironport-AV: i="3.84,129,1091422800"; d="scan'208"; a="84464312:sNHT20663774" X-MimeOLE: Produced By Microsoft Exchange V6.0.6527.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: ioctl() to get MAC address from EEPROM Date: Fri, 3 Sep 2004 12:06:02 -0500 Message-ID: <06226F23984D7A49A694576CF06603F908BBCC@ausx2kmpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ioctl() to get MAC address from EEPROM Thread-Index: AcSR2EpqqtgahXMFRfmmyUt8DI/YOw== From: To: X-OriginalArrivalTime: 03 Sep 2004 17:06:03.0956 (UTC) FILETIME=[4B8AAF40:01C491D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i83H6H0F027153 X-archive-position: 8383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Rezwanul_Kabir@Dell.com Precedence: bulk X-list: netdev Hi There seems to be no standard way to retrieve the MAC address of a NIC stored in the EEPROM ( ETHTOOL_GEEPROM ioctl may be used to do such thing but there's a need for a more direct standard interface).This is sometimes necessary when the MAC address in EEPROM may differ from the one associated with the software interface (i.e. dev_addr in struct net_device).For example, in some modes of channel bonding , the MAC address of the active NIC is duplicated on the rest of the members of the specific bond/team. How to fetch the "permanent" MAC address in this case? Any plan to include such commands in ethtool ioctls? Is there a better way to do this? Any suggestions would be appreciated.. Thanks.. --rez From jeffpc@optonline.net Fri Sep 3 10:19:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 10:19:40 -0700 (PDT) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.5.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83HJYt9028073 for ; Fri, 3 Sep 2004 10:19:35 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta4.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H00DMR6SDS8@mta4.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 13:19:25 -0400 (EDT) Date: Fri, 03 Sep 2004 13:19:24 -0400 From: "Josef 'Jeff' Sipek" Subject: [PATCH 2.6] watch64: generic variable monitoring system In-reply-to: <200409031307.01240.jeffpc@optonline.net> To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Message-id: <200409031319.24863.jeffpc@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> X-archive-position: 8385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev The watch64 system allows the programmer to specify the approximate interval at which he wants his variables checked. If he tries to specify shorter interval than the minimum a default value of HZ/10 is used. To minimize locking, RCU and seqlock are used. On 64-bit systems, all is optimized away. The following patch can be also pulled from http://jeffpc.bkbits.net/watch64-2.6 Josef "Jeff" Sipek. Signed-off-by: Josef "Jeff" Sipek diff -Nru a/Documentation/00-INDEX b/Documentation/00-INDEX --- a/Documentation/00-INDEX 2004-09-03 12:21:17 -04:00 +++ b/Documentation/00-INDEX 2004-09-03 12:21:17 -04:00 @@ -250,6 +250,8 @@ - directory with info regarding video/TV/radio cards and linux. vm/ - directory with info on the Linux vm code. +watch64.txt + - watch64 API description watchdog/ - how to auto-reboot Linux if it has "fallen and can't get up". ;-) x86_64/ diff -Nru a/Documentation/watch64.txt b/Documentation/watch64.txt --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/watch64.txt 2004-09-03 12:21:17 -04:00 @@ -0,0 +1,35 @@ +int watch64_register(unsigned long* ptr, unsigned int interval); + + - Registers *ptr to be monitored every interval jiffies. + - If interval==0, WATCH64_INTERVAL will be used (HZ/10 by default) + +int watch64_unregister(unsigned long* ptr, struct watch64* st); + + - Unregister *ptr + - st is optional pointer to the struct containing the registration + information + - if st==NULL, it will be looked up automatically + +struct watch64* watch64_find(unsigned long* ptr); + + - Return struct with registration information of *ptr + +int watch64_disable(unsigned long* ptr, struct watch64* st); + + - Disable *ptr from being monitored, without removing it from the list + - st is optional (see watch64_unregister for more information) + +int watch64_enable(unsigned long* ptr, struct watch64* st); + + - Enable *ptr from being monitored (opposite of watch64_disable) + - st is optional (see watch64_unregister for more information) + +int watch64_toggle(unsigned long* ptr, struct watch64* st); + + - Toggle the enable/disable status + - st is optional (see watch64_unregister for more information) + +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st); + + - Return the whole 64-bit counter + - st is optional (see watch64_unregister for more information) diff -Nru a/include/linux/watch64.h b/include/linux/watch64.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/include/linux/watch64.h 2004-09-03 12:21:17 -04:00 @@ -0,0 +1,63 @@ +/* + * inclue/linux/watch64.h + * + * Copyright (C) 2003 Josef "Jeff" Sipek + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#ifndef _LINUX_64WATCH_H +#define _LINUX_64WATCH_H + +#include +#include +#include +#include +#include + +#define WATCH64_INTERVAL (HZ/10) +#define WATCH64_MINIMUM (HZ/20) +#define WATCH64_MAGIC 0x573634 + +#if (BITS_PER_LONG == 64) + +struct watch64 { +}; + +#else + +struct watch64 { + struct list_head list; + unsigned long *ptr; + unsigned long oldval; + u_int64_t total; + unsigned int interval; + int active; + seqlock_t lock; + struct rcu_head rcuhead; +}; + +#endif /* (BITS_PER_LONG == 64) */ + +/* + * Prototypes + */ + +void watch64_init(void); +void watch64_run(unsigned long var); +int watch64_register(unsigned long* ptr, unsigned int interval); +int watch64_unregister(unsigned long* ptr, struct watch64* st); +void watch64_rcufree(struct rcu_head* p); +struct watch64* watch64_find(unsigned long* ptr); +inline struct watch64* __watch64_find(unsigned long* ptr); +int watch64_disable(unsigned long* ptr, struct watch64* st); +inline int __watch64_disable(unsigned long* ptr, struct watch64* st); +int watch64_enable(unsigned long* ptr, struct watch64* st); +inline int __watch64_enable(unsigned long* ptr, struct watch64* st); +int watch64_toggle(unsigned long* ptr, struct watch64* st); +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st); + +#endif /* _LINUX_WATCH64_H */ diff -Nru a/kernel/Makefile b/kernel/Makefile --- a/kernel/Makefile 2004-09-03 12:21:17 -04:00 +++ b/kernel/Makefile 2004-09-03 12:21:17 -04:00 @@ -7,7 +7,7 @@ sysctl.o capability.o ptrace.o timer.o user.o \ signal.o sys.o kmod.o workqueue.o pid.o \ rcupdate.o intermodule.o extable.o params.o posix-timers.o \ - kthread.o + kthread.o watch64.o obj-$(CONFIG_FUTEX) += futex.o obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o diff -Nru a/kernel/watch64.c b/kernel/watch64.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/kernel/watch64.c 2004-09-03 12:21:17 -04:00 @@ -0,0 +1,392 @@ +/* + * kernel/watch64.c + * + * Copyright (C) 2003 Josef "Jeff" Sipek + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * Watch64 global variables + */ + +spinlock_t watch64_biglock = SPIN_LOCK_UNLOCKED; +LIST_HEAD(watch64_head); +struct timer_list watch64_timer; +int watch64_setup; + +#if (BITS_PER_LONG == 64) + +void watch64_init(void) +{ +} + +void watch64_run(unsigned long var) +{ +} + +int watch64_register(unsigned long* ptr, unsigned int interval) +{ + return 0; +} + +int watch64_unregister(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +void watch64_rcufree(void* p) +{ +} + +struct watch64* watch64_find(unsigned long* ptr) +{ + return NULL; +} + +struct watch64* __watch64_find(unsigned long* ptr) +{ + return NULL; +} + +int watch64_disable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int __watch64_disable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int watch64_enable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int __watch64_enable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int watch64_toggle(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st) +{ + return (u_int64_t) *ptr; +} + +#else + +/* + * Initiate watch64 system + */ + +void watch64_init(void) +{ + spin_lock(&watch64_biglock); + + if (watch64_setup==WATCH64_MAGIC) { + spin_unlock(&watch64_biglock); + return; + } + + printk(KERN_WARNING "watch64: 2003/08/22 Josef 'Jeff' Sipek \n"); + printk(KERN_WARNING "watch64: Enabling Watch64 extensions..."); + + init_timer(&watch64_timer); + watch64_timer.function = watch64_run; + watch64_timer.data = (unsigned long) NULL; + watch64_timer.expires = jiffies + WATCH64_MINIMUM; + add_timer(&watch64_timer); + + printk("done.\n"); + + watch64_setup = WATCH64_MAGIC; + + spin_unlock(&watch64_biglock); +} + +/* + * Go through the list of registered variables and check them for changes + */ + +void watch64_run(unsigned long var) +{ + struct list_head* entry; + struct watch64* watch_struct; + unsigned long tmp; + + rcu_read_lock(); + list_for_each_rcu(entry, &watch64_head) { + watch_struct = list_entry(entry, struct watch64, list); + if (*watch_struct->ptr != watch_struct->oldval) { + tmp = *watch_struct->ptr; + if (tmp > watch_struct->oldval) { + write_seqlock(&watch_struct->lock); + watch_struct->total += tmp - watch_struct->oldval; + write_sequnlock(&watch_struct->lock); + } else if (tmp < watch_struct->oldval) { + write_seqlock(&watch_struct->lock); + watch_struct->total += ((u_int64_t) 1<oldval + tmp; + write_sequnlock(&watch_struct->lock); + } + watch_struct->oldval = tmp; + } + } + rcu_read_unlock(); + + mod_timer(&watch64_timer, jiffies + WATCH64_MINIMUM); +} + +/* + * Register a new variable with watch64 + */ + +int watch64_register(unsigned long* ptr, unsigned int interval) +{ + struct watch64* temp; + + temp = (struct watch64*) kmalloc(sizeof(struct watch64),GFP_ATOMIC); + + if (!temp) + return -ENOMEM; + + if (watch64_setup!=WATCH64_MAGIC) + watch64_init(); + + temp->ptr = ptr; + temp->oldval = 0; + temp->total = 0; + if (interval==0) + temp->interval = WATCH64_INTERVAL; + else if (intervalinterval = WATCH64_MINIMUM; + printk("watch64: attempted to add new watch with interval below %d jiffies",WATCH64_MINIMUM); + } else + temp->interval = interval; + + temp->active = 0; + + seqlock_init(&temp->lock); + + list_add_rcu(&temp->list, &watch64_head); + + return 0; +} + +/* + * Unregister a variable with watch64 + */ + +int watch64_unregister(unsigned long* ptr, struct watch64* st) +{ + rcu_read_lock(); + if (!st) + st = __watch64_find(ptr); + + if (!st) + return -EINVAL; + + __watch64_disable(ptr, st); + list_del_rcu(&st->list); + + call_rcu(&st->rcuhead, watch64_rcufree); + rcu_read_unlock(); + + return 0; +} + +/* + * Free memory via RCU + */ + +void watch64_rcufree(struct rcu_head* p) +{ + kfree(container_of(p, struct watch64, rcuhead)); +} + +/* + * Find watch64 structure with RCU lock + */ + +struct watch64* watch64_find(unsigned long* ptr) +{ + struct watch64* tmp; + + rcu_read_lock(); + tmp = __watch64_find(ptr); + rcu_read_unlock(); + + return tmp; +} + +/* + * Find watch64 structure without RCU lock + */ + +inline struct watch64* __watch64_find(unsigned long* ptr) +{ + struct list_head* tmp; + struct watch64* watch64_struct; + + list_for_each_rcu(tmp, &watch64_head) { + watch64_struct = list_entry(tmp, struct watch64, list); + if (watch64_struct->ptr==ptr) + return watch64_struct; + } + + return NULL; +} + +/* + * Disable a variable watch with RCU lock + */ + +int watch64_disable(unsigned long* ptr, struct watch64* st) +{ + int tmp; + + rcu_read_lock(); + tmp = __watch64_disable(ptr,st); + rcu_read_unlock(); + + return tmp; +} + +/* + * Disable a variable watch without RCU lock + */ + +inline int __watch64_disable(unsigned long* ptr, struct watch64* st) +{ + if (!st) + st = watch64_find(ptr); + + if (!st) + return -EINVAL; + + st->active = 0; + + return 0; +} + +/* + * Enable a variable watch with RCU lock + */ + +int watch64_enable(unsigned long* ptr, struct watch64* st) +{ + int tmp; + + rcu_read_lock(); + tmp = __watch64_enable(ptr,st); + rcu_read_unlock(); + + return tmp; +} + +/* + * Enable a variable watch without RCU lock + */ + +inline int __watch64_enable(unsigned long* ptr, struct watch64* st) +{ + if (!st) + st = __watch64_find(ptr); + + if (!st) + return -EINVAL; + + st->oldval = *ptr; + write_seqlock(&st->lock); + st->total = (u_int64_t) st->oldval; + write_sequnlock(&st->lock); + st->active = 1; + + return 0; +} + +/* + * Toggle a variable watch + */ + +int watch64_toggle(unsigned long* ptr, struct watch64* st) +{ + rcu_read_lock(); + if (!st) + st = __watch64_find(ptr); + + if (!st) { + rcu_read_unlock(); + return -EINVAL; + } + + if (st->active) + __watch64_disable(ptr,st); + else + __watch64_enable(ptr,st); + rcu_read_unlock(); + + return 0; +} + +/* + * Return the total 64-bit value + */ + +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st) +{ + unsigned int seq; + u_int64_t total; + + rcu_read_lock(); + if (!st) + st = __watch64_find(ptr); + + if (!st) { + rcu_read_unlock(); + return *ptr; + } + + do { + seq = read_seqbegin(&st->lock); + total = st->total; + } while (read_seqretry(&st->lock, seq)); + rcu_read_unlock(); + + return total; +} + +#endif /* (BITS_PER_LONG == 64) */ + +/* + * Export all the necessary symbols + */ + +EXPORT_SYMBOL(watch64_register); +EXPORT_SYMBOL(watch64_unregister); +EXPORT_SYMBOL(watch64_find); +EXPORT_SYMBOL(watch64_disable); +EXPORT_SYMBOL(watch64_enable); +EXPORT_SYMBOL(watch64_toggle); +EXPORT_SYMBOL(watch64_getval); From jeffpc@optonline.net Fri Sep 3 10:22:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 10:22:49 -0700 (PDT) Received: from mta10.srv.hcvlny.cv.net (mta10.srv.hcvlny.cv.net [167.206.5.85]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83HMdXi028435 for ; Fri, 3 Sep 2004 10:22:40 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta10.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H00IO36XIC9@mta10.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 13:22:30 -0400 (EDT) Date: Fri, 03 Sep 2004 13:22:29 -0400 From: "Josef 'Jeff' Sipek" Subject: [PATCH 2.6] 64network: 64-bit network statistics In-reply-to: <200409031307.01240.jeffpc@optonline.net> To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Message-id: <200409031322.29981.jeffpc@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> X-archive-position: 8386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev Upon registration of a network device, all the statistics variables are registered with watch64. Additionally, a new proc file is created /proc/net/dev64 displays the 64-bit values as supposed to /proc/net/dev which is left to display the original 32-bit variables for backward compatibility. The sysfs interface (/sys/class/net//statistics/*) displays the 64-bit values only. On 64-bit systems, all is optimized away through watch64. Requires: watch64 The following patch can be also pulled from http://jeffpc.bkbits.net/64network-2.6 (includes watch64) Josef "Jeff" Sipek Signed-off-by: Josef "Jeff" Sipek diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2004-09-03 12:22:08 -04:00 +++ b/include/linux/netdevice.h 2004-09-03 12:22:08 -04:00 @@ -14,6 +14,7 @@ * Alan Cox, * Bjorn Ekwall. * Pekka Riikonen + * Josef "Jeff" Sipek * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -945,6 +946,10 @@ #ifdef CONFIG_SYSCTL extern char *net_sysctl_strdup(const char *s); #endif + +/* Register/unregister all the members of struct net_device_stats with watch64 */ +inline void net_register_stats64(struct net_device_stats* stats); +inline void net_unregister_stats64(struct net_device_stats* stats); #endif /* __KERNEL__ */ diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-09-03 12:22:08 -04:00 +++ b/net/core/dev.c 2004-09-03 12:22:08 -04:00 @@ -18,6 +18,7 @@ * Alexey Kuznetsov * Adam Sulmicki * Pekka Riikonen + * Josef "Jeff" Sipek * * Changes: * D.J. Barrow : Fixed bug where dev->refcnt gets set @@ -70,6 +71,7 @@ * indefinitely on dev->refcnt * J Hadi Salim : - Backlog queue sampling * - netif_rx() feedback + * Josef "Jeff" Sipek : Added watch64 calls for network statistics */ #include @@ -108,6 +110,7 @@ #include #include #include +#include #ifdef CONFIG_NET_RADIO #include /* Note : will define WIRELESS_EXT */ #include @@ -2110,6 +2113,49 @@ seq_printf(seq, "%6s: No statistics available.\n", dev->name); } +static void dev_seq_printf_stats64(struct seq_file *seq, struct net_device *dev) +{ + if (dev->get_stats) { + struct net_device_stats *stats = dev->get_stats(dev); + + seq_printf(seq, "%6s:%8llu %7llu %4llu %4llu %4llu %5llu %10llu %9llu " + "%8llu %7llu %4llu %4llu %4llu %5llu %7llu %10llu\n", + dev->name, watch64_getval(&stats->rx_bytes,NULL), + watch64_getval(&stats->rx_packets,NULL), + watch64_getval(&stats->rx_errors,NULL), + watch64_getval(&stats->rx_dropped,NULL) + + watch64_getval(&stats->rx_missed_errors,NULL), + watch64_getval(&stats->rx_fifo_errors,NULL), + watch64_getval(&stats->rx_length_errors,NULL) + + watch64_getval(&stats->rx_over_errors,NULL) + + watch64_getval(&stats->rx_crc_errors,NULL) + + watch64_getval(&stats->rx_frame_errors,NULL), + watch64_getval(&stats->rx_compressed,NULL), + watch64_getval(&stats->multicast,NULL), + watch64_getval(&stats->tx_bytes,NULL), + watch64_getval(&stats->tx_packets,NULL), + watch64_getval(&stats->tx_errors,NULL), + watch64_getval(&stats->tx_dropped,NULL), + watch64_getval(&stats->tx_fifo_errors,NULL), + watch64_getval(&stats->collisions,NULL), + watch64_getval(&stats->tx_carrier_errors,NULL) + + watch64_getval(&stats->tx_aborted_errors,NULL) + + watch64_getval(&stats->tx_window_errors,NULL) + + watch64_getval(&stats->tx_heartbeat_errors,NULL), + watch64_getval(&stats->tx_compressed,NULL)); + } else + seq_printf(seq, "%6s: No statistics available.\n", dev->name); +} + +static void dev_seq_show_header(struct seq_file *seq) +{ + seq_puts(seq, "Inter-| Receive " + " | Transmit\n" + " face |bytes packets errs drop fifo frame " + "compressed multicast|bytes packets errs " + "drop fifo colls carrier compressed\n"); +} + /* * Called from the PROCfs module. This now uses the new arbitrary sized * /proc/net interface to create /proc/net/dev @@ -2117,16 +2163,21 @@ static int dev_seq_show(struct seq_file *seq, void *v) { if (v == SEQ_START_TOKEN) - seq_puts(seq, "Inter-| Receive " - " | Transmit\n" - " face |bytes packets errs drop fifo frame " - "compressed multicast|bytes packets errs " - "drop fifo colls carrier compressed\n"); + dev_seq_show_header(seq); else dev_seq_printf_stats(seq, v); return 0; } +static int dev_seq_show64(struct seq_file *seq, void *v) +{ + if (v == SEQ_START_TOKEN) + dev_seq_show_header(seq); + else + dev_seq_printf_stats64(seq, v); + return 0; +} + static struct netif_rx_stats *softnet_get_online(loff_t *pos) { struct netif_rx_stats *rc = NULL; @@ -2179,11 +2230,23 @@ .show = dev_seq_show, }; +static struct seq_operations dev_seq_ops64 = { + .start = dev_seq_start, + .next = dev_seq_next, + .stop = dev_seq_stop, + .show = dev_seq_show64, +}; + static int dev_seq_open(struct inode *inode, struct file *file) { return seq_open(file, &dev_seq_ops); } +static int dev_seq_open64(struct inode *inode, struct file *file) +{ + return seq_open(file, &dev_seq_ops64); +} + static struct file_operations dev_seq_fops = { .owner = THIS_MODULE, .open = dev_seq_open, @@ -2192,6 +2255,14 @@ .release = seq_release, }; +static struct file_operations dev_seq_fops64 = { + .owner = THIS_MODULE, + .open = dev_seq_open64, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + static struct seq_operations softnet_seq_ops = { .start = softnet_seq_start, .next = softnet_seq_next, @@ -2224,8 +2295,10 @@ if (!proc_net_fops_create("dev", S_IRUGO, &dev_seq_fops)) goto out; - if (!proc_net_fops_create("softnet_stat", S_IRUGO, &softnet_seq_fops)) + if (!proc_net_fops_create("dev64", S_IRUGO, &dev_seq_fops64)) goto out_dev; + if (!proc_net_fops_create("softnet_stat", S_IRUGO, &softnet_seq_fops)) + goto out_dev64; if (wireless_proc_init()) goto out_softnet; rc = 0; @@ -2233,6 +2306,8 @@ return rc; out_softnet: proc_net_remove("softnet_stat"); +out_dev64: + proc_net_remove("dev64"); out_dev: proc_net_remove("dev"); goto out; @@ -2910,6 +2985,9 @@ * device is present. */ + if (dev->get_stats) + net_register_stats64(dev->get_stats(dev)); + set_bit(__LINK_STATE_PRESENT, &dev->state); dev->next = NULL; @@ -2922,7 +3000,7 @@ dev_hold(dev); dev->reg_state = NETREG_REGISTERING; write_unlock_bh(&dev_base_lock); - + /* Notify protocols, that a new device appeared. */ notifier_call_chain(&netdev_chain, NETDEV_REGISTER, dev); @@ -3145,6 +3223,9 @@ /* If device is running, close it first. */ if (dev->flags & IFF_UP) dev_close(dev); + + if (dev->get_stats) + net_unregister_stats64(dev->get_stats(dev)); /* And unlink it from device chain. */ for (dp = &dev_base; (d = *dp) != NULL; dp = &d->next) { @@ -3246,6 +3327,98 @@ } #endif /* CONFIG_HOTPLUG_CPU */ +/* + * Register all the members of the net_device_stats structure + * + */ + +inline void net_register_stats64(struct net_device_stats* stats) +{ + if (!stats) + return; + + watch64_register(&stats->tx_packets,0); + watch64_enable (&stats->tx_packets,NULL); + watch64_register(&stats->rx_packets,0); + watch64_enable (&stats->rx_packets,NULL); + watch64_register(&stats->tx_bytes,0); + watch64_enable (&stats->tx_bytes,NULL); + watch64_register(&stats->rx_bytes,0); + watch64_enable (&stats->rx_bytes,NULL); + watch64_register(&stats->tx_errors,0); + watch64_enable (&stats->tx_errors,NULL); + watch64_register(&stats->rx_errors,0); + watch64_enable (&stats->rx_errors,NULL); + watch64_register(&stats->tx_dropped,0); + watch64_enable (&stats->tx_dropped,NULL); + watch64_register(&stats->rx_dropped,0); + watch64_enable (&stats->rx_dropped,NULL); + watch64_register(&stats->multicast,0); + watch64_enable (&stats->multicast,NULL); + watch64_register(&stats->collisions,0); + watch64_enable (&stats->collisions,NULL); + watch64_register(&stats->rx_length_errors,0); + watch64_enable (&stats->rx_length_errors,NULL); + watch64_register(&stats->rx_over_errors,0); + watch64_enable (&stats->rx_over_errors,NULL); + watch64_register(&stats->rx_crc_errors,0); + watch64_enable (&stats->rx_crc_errors,NULL); + watch64_register(&stats->rx_frame_errors,0); + watch64_enable (&stats->rx_frame_errors,NULL); + watch64_register(&stats->rx_fifo_errors,0); + watch64_enable (&stats->rx_fifo_errors,NULL); + watch64_register(&stats->rx_missed_errors,0); + watch64_enable (&stats->rx_missed_errors,NULL); + watch64_register(&stats->tx_aborted_errors,0); + watch64_enable (&stats->tx_aborted_errors,NULL); + watch64_register(&stats->tx_carrier_errors,0); + watch64_enable (&stats->tx_carrier_errors,NULL); + watch64_register(&stats->tx_fifo_errors,0); + watch64_enable (&stats->tx_fifo_errors,NULL); + watch64_register(&stats->tx_heartbeat_errors,0); + watch64_enable (&stats->tx_heartbeat_errors,NULL); + watch64_register(&stats->tx_window_errors,0); + watch64_enable (&stats->tx_window_errors,NULL); + watch64_register(&stats->rx_compressed,0); + watch64_enable (&stats->rx_compressed,NULL); + watch64_register(&stats->tx_compressed,0); + watch64_enable (&stats->tx_compressed,NULL); +} + +/* + * Unregister all the members of the net_device_stats structure + * + */ + +inline void net_unregister_stats64(struct net_device_stats* stats) +{ + if (!stats) + return; + + watch64_unregister(&stats->tx_packets,0); + watch64_unregister(&stats->rx_packets,0); + watch64_unregister(&stats->tx_bytes,0); + watch64_unregister(&stats->rx_bytes,0); + watch64_unregister(&stats->tx_errors,0); + watch64_unregister(&stats->rx_errors,0); + watch64_unregister(&stats->tx_dropped,0); + watch64_unregister(&stats->rx_dropped,0); + watch64_unregister(&stats->multicast,0); + watch64_unregister(&stats->collisions,0); + watch64_unregister(&stats->rx_length_errors,0); + watch64_unregister(&stats->rx_over_errors,0); + watch64_unregister(&stats->rx_crc_errors,0); + watch64_unregister(&stats->rx_frame_errors,0); + watch64_unregister(&stats->rx_fifo_errors,0); + watch64_unregister(&stats->rx_missed_errors,0); + watch64_unregister(&stats->tx_aborted_errors,0); + watch64_unregister(&stats->tx_carrier_errors,0); + watch64_unregister(&stats->tx_fifo_errors,0); + watch64_unregister(&stats->tx_heartbeat_errors,0); + watch64_unregister(&stats->tx_window_errors,0); + watch64_unregister(&stats->rx_compressed,0); + watch64_unregister(&stats->tx_compressed,0); +} /* * Initialize the DEV module. At boot time this walks the device list and diff -Nru a/net/core/net-sysfs.c b/net/core/net-sysfs.c --- a/net/core/net-sysfs.c 2004-09-03 12:22:08 -04:00 +++ b/net/core/net-sysfs.c 2004-09-03 12:22:08 -04:00 @@ -16,6 +16,7 @@ #include #include #include +#include #define to_class_dev(obj) container_of(obj,struct class_device,kobj) #define to_net_dev(class) container_of(class, struct net_device, class_dev) @@ -23,6 +24,7 @@ static const char fmt_hex[] = "%#x\n"; static const char fmt_dec[] = "%d\n"; static const char fmt_ulong[] = "%lu\n"; +static const char fmt_ullong[] = "%llu\n"; static inline int dev_isalive(const struct net_device *dev) { @@ -204,8 +206,8 @@ read_lock(&dev_base_lock); if (dev_isalive(dev) && dev->get_stats && (stats = (*dev->get_stats)(dev))) - ret = sprintf(buf, fmt_ulong, - *(unsigned long *)(((u8 *) stats) + offset)); + ret = sprintf(buf, fmt_ullong, + watch64_getval((unsigned long *)(((u8 *) stats) + offset),NULL)); read_unlock(&dev_base_lock); return ret; From jeffpc@optonline.net Fri Sep 3 10:25:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 10:25:31 -0700 (PDT) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83HPPCq028777 for ; Fri, 3 Sep 2004 10:25:26 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H00FI771066@mta6.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 13:24:37 -0400 (EDT) Date: Fri, 03 Sep 2004 13:24:28 -0400 From: Jeff Sipek Subject: Re: [PATCH/RFC 2.6] NET: 64-bit network statistics In-reply-to: <200409031307.01240.jeffpc@optonline.net> To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Message-id: <200409031324.36252.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> X-archive-position: 8387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 03 September 2004 13:06, josef Jeff Sipek wrote: > I've created a patch that monitors changes to the network statistics > variables and keeps internal 64-bit counter. I decided to split it into two > parts (patches are to follow in next emails): > 1) generic variable monitoring system (watch64) > 2) network statistics specific patch (64network) Btw, both of these patches apply cleanly against 2.6.9-rc1-bk10. Jeff. - -- bad pun of the week: the formula 1 control computer suffered from a race condition -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOKjQwFP0+seVj/4RApg/AKDEFSTVOMSvVh9zVU65o/P6ZcfBxgCffeId QddOVsR+uHdkV2D4/U8QVO4= =jQIT -----END PGP SIGNATURE----- From vkondra@mail.ru Fri Sep 3 11:04:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 11:05:32 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83I4k8w029921 for ; Fri, 3 Sep 2004 11:04:47 -0700 Received: from [212.179.200.204] (port=25901 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1C3IQ2-000Jtq-00; Fri, 03 Sep 2004 22:04:16 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Fri, 3 Sep 2004 20:37:54 +0300 User-Agent: KMail/1.7 Cc: Jeff Garzik , Denis Vlasenko , Jean Tourrilhes , Jouni Malinen , acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org, "David S. Miller" References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409022324.43117.vkondra@mail.ru> <4137839B.4000303@pobox.com> In-Reply-To: <4137839B.4000303@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409032039.28201.vkondra@mail.ru> X-Spam: Probable Spam X-archive-position: 8388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Is anyone working on this stack? I asked Dave, he is hot working on it. Or is this code dead? On Thursday 02 September 2004 23:33, Jeff Garzik wrote: JG> Vladimir Kondratiev wrote: JG> > Jeff, JG> > JG> > On Tuesday 31 August 2004 21:21, Jeff Garzik wrote: JG> > JG> Denis Vlasenko wrote: JG> > JG> > I think 'senior' network guys are in position to decide upon which JG> > JG> > of currently available 802.11 stacks we should continue to work. JG> > JG> > (Atheros has one, said to be derived from BSD, is there any others?) JG> > JG> JG> > JG> JG> > JG> Already have. Start with the code in wireless-2.6 -- HostAP -- and use JG> > JG> DaveM's 802.11 stack template as a model for actually integrating 802.11 JG> > JG> very tightly with the rest of the net stack. JG> > JG> JG> > JG> JG> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8 JG> > 0211.tar.bz2 JG> > JG> > Is this stack the main one that is going to be used? I.e. if I am working on JG> > driver for next generation .11 card - should I try to use it, request/submitt JG> > missing features etc.? Or should I use wireless extensions? JG> JG> DaveM's code is a template for how a wireless stack would look when JG> properly and fully integrated into the net core. JG> JG> Although JeanT and I disagree about this, I am less interested in JG> backwards compatibility than I am about making wireless a "first class JG> citizen" in the kernel. As I have proven with kcompat JG> (http://sf.net/projects/gkernel/) you can be backwards compatible while JG> still evolving the current kernel driver API to meet current design needs. JG> JG> Jeff JG> JG> JG> JG> From yoshfuji@linux-ipv6.org Fri Sep 3 12:06:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 12:06:48 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83J6fWW001538 for ; Fri, 3 Sep 2004 12:06:41 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D6C2533CE6; Sat, 4 Sep 2004 04:07:29 +0900 (JST) Date: Sat, 04 Sep 2004 04:07:27 +0900 (JST) Message-Id: <20040904.040727.72671952.yoshfuji@linux-ipv6.org> To: jeffpc@optonline.net Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200409031319.24863.jeffpc@optonline.net> References: <200409031307.01240.jeffpc@optonline.net> <200409031319.24863.jeffpc@optonline.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <200409031319.24863.jeffpc@optonline.net> (at Fri, 03 Sep 2004 13:19:24 -0400), "Josef 'Jeff' Sipek" says: > The watch64 system allows the programmer to specify the approximate interval > at which he wants his variables checked. If he tries to specify shorter > interval than the minimum a default value of HZ/10 is used. To minimize > locking, RCU and seqlock are used. On 64-bit systems, all is optimized away. I agree with the basic principle; it is very similar to mine. However, it is too complicated isn't it? I would do per-"table" registration (instead of per-variable one); watch64_getval() seems very ugly to me... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jeffpc@optonline.net Fri Sep 3 13:24:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 13:24:40 -0700 (PDT) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83KOWIQ006212 for ; Fri, 3 Sep 2004 13:24:34 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H00EK9FCNLU@mta6.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 16:24:23 -0400 (EDT) Date: Fri, 03 Sep 2004 16:24:15 -0400 From: Jeff Sipek Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system In-reply-to: <20040904.040727.72671952.yoshfuji@linux-ipv6.org> To: YOSHIFUJI Hideaki / =?utf-8?q?=E5=90=89=E8=97=A4=E8=8B=B1=E6=98=8E?= Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Message-id: <200409031624.22665.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=utf-8 Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> <200409031319.24863.jeffpc@optonline.net> <20040904.040727.72671952.yoshfuji@linux-ipv6.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i83KOWIQ006212 X-archive-position: 8390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 03 September 2004 15:07, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > I agree with the basic principle; it is very similar to mine. Yes, I saw a patch on lkml a while a go (possibly yours?) that used a workqueue (IIRC.) > However, it is too complicated isn't it? I considered the option of removing the capability of the programmer asking for a certain interval, and instead having all the variables checked every WATCH64_INTERVAL. > I would do per-"table" registration (instead of per-variable one); I considered that option, but then decided to make the watch64 system generic enough so that it could be used from anywhere in the kernel. Is my idea of having a kernel-wide subsystem like this too heavy-weight? > watch64_getval() seems very ugly to me... How so? Is it the multiplicity of "if (!st)"? Jeff. - -- bad pun of the week: the formula 1 control computer suffered from a race condition -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBONLzwFP0+seVj/4RAvYsAKCdVy9EzivcGtwa9CDiuvy/nwWuJwCglQ4L iIf4QXC7PA+YwQs3905sRv0= =NkA4 -----END PGP SIGNATURE----- From jgarzik@pobox.com Fri Sep 3 13:30:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 13:31:07 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83KUMva006625 for ; Fri, 3 Sep 2004 13:30:23 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C3Kgy-0002Ry-Ss; Fri, 03 Sep 2004 21:29:53 +0100 Message-ID: <4138D431.8040206@pobox.com> Date: Fri, 03 Sep 2004 16:29:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: netdev@oss.sgi.com, Denis Vlasenko , Jean Tourrilhes , Jouni Malinen , acx100-devel@lists.sourceforge.net, prism54-devel@prism54.org, "David S. Miller" Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409022324.43117.vkondra@mail.ru> <4137839B.4000303@pobox.com> <200409032039.28201.vkondra@mail.ru> In-Reply-To: <200409032039.28201.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Vladimir Kondratiev wrote: > Is anyone working on this stack? I asked Dave, he is hot working on it. > Or is this code dead? Nobody is actively working on that stack AFAIK. Jeff From jeffpc@optonline.net Fri Sep 3 13:40:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 13:41:01 -0700 (PDT) Received: from mta8.srv.hcvlny.cv.net (mta8.srv.hcvlny.cv.net [167.206.5.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83KetC2007208 for ; Fri, 3 Sep 2004 13:40:55 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta8.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H00DA2G3JO9@mta8.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 16:40:32 -0400 (EDT) Date: Fri, 03 Sep 2004 16:40:30 -0400 From: "Josef 'Jeff' Sipek" Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system In-reply-to: <200409031618.47521.jeffpc@optonline.net> To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Message-id: <200409031640.30731.jeffpc@optonline.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> <20040903121657.355a6a8b@dell_ss3.pdx.osdl.net> <200409031618.47521.jeffpc@optonline.net> X-archive-position: 8392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev The following fixes watch64 patch previously submitted to follow CodingStyle guidelines. BK repo is up to date as well Jeff. Signed-off-by: Josef "Jeff" Sipek --- 1.7/kernel/watch64.c 2004-07-14 16:41:26 -04:00 +++ edited/watch64.c 2004-09-03 16:12:39 -04:00 @@ -110,7 +110,8 @@ return; } - printk(KERN_WARNING "watch64: 2003/08/22 Josef 'Jeff' Sipek \n"); + printk(KERN_WARNING "watch64: 2003/08/22 Josef 'Jeff' Sipek " + "\n"); printk(KERN_WARNING "watch64: Enabling Watch64 extensions..."); init_timer(&watch64_timer); @@ -139,19 +140,21 @@ rcu_read_lock(); list_for_each_rcu(entry, &watch64_head) { watch_struct = list_entry(entry, struct watch64, list); - if (*watch_struct->ptr != watch_struct->oldval) { - tmp = *watch_struct->ptr; - if (tmp > watch_struct->oldval) { - write_seqlock(&watch_struct->lock); - watch_struct->total += tmp - watch_struct->oldval; - write_sequnlock(&watch_struct->lock); - } else if (tmp < watch_struct->oldval) { - write_seqlock(&watch_struct->lock); - watch_struct->total += ((u_int64_t) 1<oldval + tmp; - write_sequnlock(&watch_struct->lock); - } - watch_struct->oldval = tmp; + if (*watch_struct->ptr == watch_struct->oldval) + continue; + + tmp = *watch_struct->ptr; + if (tmp > watch_struct->oldval) { + write_seqlock(&watch_struct->lock); + watch_struct->total += tmp - watch_struct->oldval; + write_sequnlock(&watch_struct->lock); + } else if (tmp < watch_struct->oldval) { + write_seqlock(&watch_struct->lock); + watch_struct->total += ((u_int64_t) 1<oldval + tmp; + write_sequnlock(&watch_struct->lock); } + watch_struct->oldval = tmp; } rcu_read_unlock(); @@ -181,7 +184,8 @@ temp->interval = WATCH64_INTERVAL; else if (intervalinterval = WATCH64_MINIMUM; - printk("watch64: attempted to add new watch with interval below %d jiffies",WATCH64_MINIMUM); + printk("watch64: attempted to add new watch with " + "interval below %d jiffies",WATCH64_MINIMUM); } else temp->interval = interval; From davej@redhat.com Fri Sep 3 13:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 13:53:19 -0700 (PDT) Received: from delerium.codemonkey.org.uk (delerium.kernelslacker.org [81.187.208.145]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83KrBOr008042 for ; Fri, 3 Sep 2004 13:53:14 -0700 Received: from delerium.codemonkey.org.uk (localhost.localdomain [127.0.0.1]) by delerium.codemonkey.org.uk (8.13.1/8.13.1) with ESMTP id i83Kq6OV021868; Fri, 3 Sep 2004 21:52:06 +0100 Received: (from davej@localhost) by delerium.codemonkey.org.uk (8.13.1/8.13.1/Submit) id i83Kq6lu021867; Fri, 3 Sep 2004 21:52:06 +0100 X-Authentication-Warning: delerium.codemonkey.org.uk: davej set sender to davej@redhat.com using -f Date: Fri, 3 Sep 2004 21:52:06 +0100 From: Dave Jones To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Too late check in af_packet.c Message-ID: <20040903205206.GT26419@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 8393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davej@redhat.com Precedence: bulk X-list: netdev Using the automated source checker at coverity.com, they picked up on some code in packet_release() where a NULL check was done after dereferencing. Patch below. Signed-off-by: Dave Jones Dave --- linux-2.6.8/net/packet/af_packet.c~ 2004-09-03 21:48:14.653433072 +0100 +++ linux-2.6.8/net/packet/af_packet.c 2004-09-03 21:49:23.652943552 +0100 @@ -785,11 +785,13 @@ static int packet_release(struct socket *sock) { struct sock *sk = sock->sk; - struct packet_opt *po = pkt_sk(sk); + struct packet_opt *po; if (!sk) return 0; + po = pkt_sk(sk); + write_lock_bh(&packet_sklist_lock); sk_del_node_init(sk); write_unlock_bh(&packet_sklist_lock); From jeffpc@optonline.net Fri Sep 3 14:45:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 14:45:14 -0700 (PDT) Received: from mta9.srv.hcvlny.cv.net (mta9.srv.hcvlny.cv.net [167.206.5.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83Lj62F009118 for ; Fri, 3 Sep 2004 14:45:07 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta9.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3H00JKEJ29E3@mta9.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Fri, 03 Sep 2004 17:44:34 -0400 (EDT) Date: Fri, 03 Sep 2004 17:44:24 -0400 From: "Josef 'Jeff' Sipek" Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system In-reply-to: <20040903121657.355a6a8b@dell_ss3.pdx.osdl.net> To: Stephen Hemminger Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Message-id: <200409031744.32970.jeffpc@optonline.net> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Gu5A8t3yfXnZW0k3kEIBKg)" Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> <200409031319.24863.jeffpc@optonline.net> <20040903121657.355a6a8b@dell_ss3.pdx.osdl.net> X-archive-position: 8394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev --Boundary_(ID_Gu5A8t3yfXnZW0k3kEIBKg) Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 03 September 2004 15:16, Stephen Hemminger wrote: > - Code doesn't match the kernel style (read Documentation/CodingStyle) Sorry about the white space, KMail apparently likes to butcher the text. These are the same patches with the little cleanup update. Jeff. - -- Reality is merely an illusion, albeit a very persistent one. - Albert Einstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD4DBQFBOOW+wFP0+seVj/4RAgSiAJj54qcqdEx66lbMW9ik0XviupTNAKC82an1 R0pGX0pTBZ78NWrZpxJm+w== =EesC -----END PGP SIGNATURE----- --Boundary_(ID_Gu5A8t3yfXnZW0k3kEIBKg) Content-type: text/x-diff; charset=iso-8859-1; name=watch64-patch Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=watch64-patch diff -Nru a/Documentation/00-INDEX b/Documentation/00-INDEX --- a/Documentation/00-INDEX 2004-09-03 17:41:06 -04:00 +++ b/Documentation/00-INDEX 2004-09-03 17:41:06 -04:00 @@ -250,6 +250,8 @@ - directory with info regarding video/TV/radio cards and linux. vm/ - directory with info on the Linux vm code. +watch64.txt + - watch64 API description watchdog/ - how to auto-reboot Linux if it has "fallen and can't get up". ;-) x86_64/ diff -Nru a/Documentation/watch64.txt b/Documentation/watch64.txt --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/watch64.txt 2004-09-03 17:41:06 -04:00 @@ -0,0 +1,35 @@ +int watch64_register(unsigned long* ptr, unsigned int interval); + + - Registers *ptr to be monitored every interval jiffies. + - If interval==0, WATCH64_INTERVAL will be used (HZ/10 by default) + +int watch64_unregister(unsigned long* ptr, struct watch64* st); + + - Unregister *ptr + - st is optional pointer to the struct containing the registration + information + - if st==NULL, it will be looked up automatically + +struct watch64* watch64_find(unsigned long* ptr); + + - Return struct with registration information of *ptr + +int watch64_disable(unsigned long* ptr, struct watch64* st); + + - Disable *ptr from being monitored, without removing it from the list + - st is optional (see watch64_unregister for more information) + +int watch64_enable(unsigned long* ptr, struct watch64* st); + + - Enable *ptr from being monitored (opposite of watch64_disable) + - st is optional (see watch64_unregister for more information) + +int watch64_toggle(unsigned long* ptr, struct watch64* st); + + - Toggle the enable/disable status + - st is optional (see watch64_unregister for more information) + +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st); + + - Return the whole 64-bit counter + - st is optional (see watch64_unregister for more information) diff -Nru a/include/linux/watch64.h b/include/linux/watch64.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/include/linux/watch64.h 2004-09-03 17:41:06 -04:00 @@ -0,0 +1,63 @@ +/* + * inclue/linux/watch64.h + * + * Copyright (C) 2003 Josef "Jeff" Sipek + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#ifndef _LINUX_64WATCH_H +#define _LINUX_64WATCH_H + +#include +#include +#include +#include +#include + +#define WATCH64_INTERVAL (HZ/10) +#define WATCH64_MINIMUM (HZ/20) +#define WATCH64_MAGIC 0x573634 + +#if (BITS_PER_LONG == 64) + +struct watch64 { +}; + +#else + +struct watch64 { + struct list_head list; + unsigned long *ptr; + unsigned long oldval; + u_int64_t total; + unsigned int interval; + int active; + seqlock_t lock; + struct rcu_head rcuhead; +}; + +#endif /* (BITS_PER_LONG == 64) */ + +/* + * Prototypes + */ + +void watch64_init(void); +void watch64_run(unsigned long var); +int watch64_register(unsigned long* ptr, unsigned int interval); +int watch64_unregister(unsigned long* ptr, struct watch64* st); +void watch64_rcufree(struct rcu_head* p); +struct watch64* watch64_find(unsigned long* ptr); +inline struct watch64* __watch64_find(unsigned long* ptr); +int watch64_disable(unsigned long* ptr, struct watch64* st); +inline int __watch64_disable(unsigned long* ptr, struct watch64* st); +int watch64_enable(unsigned long* ptr, struct watch64* st); +inline int __watch64_enable(unsigned long* ptr, struct watch64* st); +int watch64_toggle(unsigned long* ptr, struct watch64* st); +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st); + +#endif /* _LINUX_WATCH64_H */ diff -Nru a/kernel/Makefile b/kernel/Makefile --- a/kernel/Makefile 2004-09-03 17:41:06 -04:00 +++ b/kernel/Makefile 2004-09-03 17:41:06 -04:00 @@ -7,7 +7,7 @@ sysctl.o capability.o ptrace.o timer.o user.o \ signal.o sys.o kmod.o workqueue.o pid.o \ rcupdate.o intermodule.o extable.o params.o posix-timers.o \ - kthread.o + kthread.o watch64.o obj-$(CONFIG_FUTEX) += futex.o obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o diff -Nru a/kernel/watch64.c b/kernel/watch64.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/kernel/watch64.c 2004-09-03 17:41:06 -04:00 @@ -0,0 +1,396 @@ +/* + * kernel/watch64.c + * + * Copyright (C) 2003 Josef "Jeff" Sipek + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * Watch64 global variables + */ + +spinlock_t watch64_biglock = SPIN_LOCK_UNLOCKED; +LIST_HEAD(watch64_head); +struct timer_list watch64_timer; +int watch64_setup; + +#if (BITS_PER_LONG == 64) + +void watch64_init(void) +{ +} + +void watch64_run(unsigned long var) +{ +} + +int watch64_register(unsigned long* ptr, unsigned int interval) +{ + return 0; +} + +int watch64_unregister(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +void watch64_rcufree(void* p) +{ +} + +struct watch64* watch64_find(unsigned long* ptr) +{ + return NULL; +} + +struct watch64* __watch64_find(unsigned long* ptr) +{ + return NULL; +} + +int watch64_disable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int __watch64_disable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int watch64_enable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int __watch64_enable(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +int watch64_toggle(unsigned long* ptr, struct watch64* st) +{ + return 0; +} + +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st) +{ + return (u_int64_t) *ptr; +} + +#else + +/* + * Initiate watch64 system + */ + +void watch64_init(void) +{ + spin_lock(&watch64_biglock); + + if (watch64_setup==WATCH64_MAGIC) { + spin_unlock(&watch64_biglock); + return; + } + + printk(KERN_WARNING "watch64: 2003/08/22 Josef 'Jeff' Sipek " + "\n"); + printk(KERN_WARNING "watch64: Enabling Watch64 extensions..."); + + init_timer(&watch64_timer); + watch64_timer.function = watch64_run; + watch64_timer.data = (unsigned long) NULL; + watch64_timer.expires = jiffies + WATCH64_MINIMUM; + add_timer(&watch64_timer); + + printk("done.\n"); + + watch64_setup = WATCH64_MAGIC; + + spin_unlock(&watch64_biglock); +} + +/* + * Go through the list of registered variables and check them for changes + */ + +void watch64_run(unsigned long var) +{ + struct list_head* entry; + struct watch64* watch_struct; + unsigned long tmp; + + rcu_read_lock(); + list_for_each_rcu(entry, &watch64_head) { + watch_struct = list_entry(entry, struct watch64, list); + if (*watch_struct->ptr == watch_struct->oldval) + continue; + + tmp = *watch_struct->ptr; + if (tmp > watch_struct->oldval) { + write_seqlock(&watch_struct->lock); + watch_struct->total += tmp - watch_struct->oldval; + write_sequnlock(&watch_struct->lock); + } else if (tmp < watch_struct->oldval) { + write_seqlock(&watch_struct->lock); + watch_struct->total += ((u_int64_t) 1<oldval + tmp; + write_sequnlock(&watch_struct->lock); + } + watch_struct->oldval = tmp; + } + rcu_read_unlock(); + + mod_timer(&watch64_timer, jiffies + WATCH64_MINIMUM); +} + +/* + * Register a new variable with watch64 + */ + +int watch64_register(unsigned long* ptr, unsigned int interval) +{ + struct watch64* temp; + + temp = (struct watch64*) kmalloc(sizeof(struct watch64),GFP_ATOMIC); + + if (!temp) + return -ENOMEM; + + if (watch64_setup!=WATCH64_MAGIC) + watch64_init(); + + temp->ptr = ptr; + temp->oldval = 0; + temp->total = 0; + if (interval==0) + temp->interval = WATCH64_INTERVAL; + else if (intervalinterval = WATCH64_MINIMUM; + printk("watch64: attempted to add new watch with " + "interval below %d jiffies",WATCH64_MINIMUM); + } else + temp->interval = interval; + + temp->active = 0; + + seqlock_init(&temp->lock); + + list_add_rcu(&temp->list, &watch64_head); + + return 0; +} + +/* + * Unregister a variable with watch64 + */ + +int watch64_unregister(unsigned long* ptr, struct watch64* st) +{ + rcu_read_lock(); + if (!st) + st = __watch64_find(ptr); + + if (!st) + return -EINVAL; + + __watch64_disable(ptr, st); + list_del_rcu(&st->list); + + call_rcu(&st->rcuhead, watch64_rcufree); + rcu_read_unlock(); + + return 0; +} + +/* + * Free memory via RCU + */ + +void watch64_rcufree(struct rcu_head* p) +{ + kfree(container_of(p, struct watch64, rcuhead)); +} + +/* + * Find watch64 structure with RCU lock + */ + +struct watch64* watch64_find(unsigned long* ptr) +{ + struct watch64* tmp; + + rcu_read_lock(); + tmp = __watch64_find(ptr); + rcu_read_unlock(); + + return tmp; +} + +/* + * Find watch64 structure without RCU lock + */ + +inline struct watch64* __watch64_find(unsigned long* ptr) +{ + struct list_head* tmp; + struct watch64* watch64_struct; + + list_for_each_rcu(tmp, &watch64_head) { + watch64_struct = list_entry(tmp, struct watch64, list); + if (watch64_struct->ptr==ptr) + return watch64_struct; + } + + return NULL; +} + +/* + * Disable a variable watch with RCU lock + */ + +int watch64_disable(unsigned long* ptr, struct watch64* st) +{ + int tmp; + + rcu_read_lock(); + tmp = __watch64_disable(ptr,st); + rcu_read_unlock(); + + return tmp; +} + +/* + * Disable a variable watch without RCU lock + */ + +inline int __watch64_disable(unsigned long* ptr, struct watch64* st) +{ + if (!st) + st = watch64_find(ptr); + + if (!st) + return -EINVAL; + + st->active = 0; + + return 0; +} + +/* + * Enable a variable watch with RCU lock + */ + +int watch64_enable(unsigned long* ptr, struct watch64* st) +{ + int tmp; + + rcu_read_lock(); + tmp = __watch64_enable(ptr,st); + rcu_read_unlock(); + + return tmp; +} + +/* + * Enable a variable watch without RCU lock + */ + +inline int __watch64_enable(unsigned long* ptr, struct watch64* st) +{ + if (!st) + st = __watch64_find(ptr); + + if (!st) + return -EINVAL; + + st->oldval = *ptr; + write_seqlock(&st->lock); + st->total = (u_int64_t) st->oldval; + write_sequnlock(&st->lock); + st->active = 1; + + return 0; +} + +/* + * Toggle a variable watch + */ + +int watch64_toggle(unsigned long* ptr, struct watch64* st) +{ + rcu_read_lock(); + if (!st) + st = __watch64_find(ptr); + + if (!st) { + rcu_read_unlock(); + return -EINVAL; + } + + if (st->active) + __watch64_disable(ptr,st); + else + __watch64_enable(ptr,st); + rcu_read_unlock(); + + return 0; +} + +/* + * Return the total 64-bit value + */ + +inline u_int64_t watch64_getval(unsigned long* ptr, struct watch64* st) +{ + unsigned int seq; + u_int64_t total; + + rcu_read_lock(); + if (!st) + st = __watch64_find(ptr); + + if (!st) { + rcu_read_unlock(); + return *ptr; + } + + do { + seq = read_seqbegin(&st->lock); + total = st->total; + } while (read_seqretry(&st->lock, seq)); + rcu_read_unlock(); + + return total; +} + +#endif /* (BITS_PER_LONG == 64) */ + +/* + * Export all the necessary symbols + */ + +EXPORT_SYMBOL(watch64_register); +EXPORT_SYMBOL(watch64_unregister); +EXPORT_SYMBOL(watch64_find); +EXPORT_SYMBOL(watch64_disable); +EXPORT_SYMBOL(watch64_enable); +EXPORT_SYMBOL(watch64_toggle); +EXPORT_SYMBOL(watch64_getval); --Boundary_(ID_Gu5A8t3yfXnZW0k3kEIBKg) Content-type: text/x-diff; charset=iso-8859-1; name=64network-patch Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=64network-patch diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h 2004-09-03 12:22:08 -04:00 +++ b/include/linux/netdevice.h 2004-09-03 12:22:08 -04:00 @@ -14,6 +14,7 @@ * Alan Cox, * Bjorn Ekwall. * Pekka Riikonen + * Josef "Jeff" Sipek * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License @@ -945,6 +946,10 @@ #ifdef CONFIG_SYSCTL extern char *net_sysctl_strdup(const char *s); #endif + +/* * Register/unregister all the members of struct net_device_stats with watch64 */ +inline void net_register_stats64(struct net_device_stats* stats); +inline void net_unregister_stats64(struct net_device_stats* stats); #endif /* __KERNEL__ */ diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c 2004-09-03 12:22:08 -04:00 +++ b/net/core/dev.c 2004-09-03 12:22:08 -04:00 @@ -18,6 +18,7 @@ * Alexey Kuznetsov * Adam Sulmicki * Pekka Riikonen + * Josef "Jeff" Sipek * * Changes: * D.J. Barrow : Fixed bug where dev->refcnt gets set @@ -70,6 +71,7 @@ * indefinitely on dev->refcnt * J Hadi Salim : - Backlog queue sampling * - netif_rx() feedback + * Josef "Jeff" Sipek : Added watch64 calls for network statistics */ #include @@ -108,6 +110,7 @@ #include #include #include +#include #ifdef CONFIG_NET_RADIO #include /* Note : will define WIRELESS_EXT */ #include @@ -2110,6 +2113,49 @@ seq_printf(seq, "%6s: No statistics available.\n", dev->name); } +static void dev_seq_printf_stats64(struct seq_file *seq, struct net_device *dev) +{ + if (dev->get_stats) { + struct net_device_stats *stats = dev->get_stats(dev); + + seq_printf(seq, "%6s:%8llu %7llu %4llu %4llu %4llu %5llu %10llu %9llu " + "%8llu %7llu %4llu %4llu %4llu %5llu %7llu %10llu\n", + dev->name, watch64_getval(&stats->rx_bytes,NULL), + watch64_getval(&stats->rx_packets,NULL), + watch64_getval(&stats->rx_errors,NULL), + watch64_getval(&stats->rx_dropped,NULL) + + watch64_getval(&stats->rx_missed_errors,NULL), + watch64_getval(&stats->rx_fifo_errors,NULL), + watch64_getval(&stats->rx_length_errors,NULL) + + watch64_getval(&stats->rx_over_errors,NULL) + + watch64_getval(&stats->rx_crc_errors,NULL) + + watch64_getval(&stats->rx_frame_errors,NULL), + watch64_getval(&stats->rx_compressed,NULL), + watch64_getval(&stats->multicast,NULL), + watch64_getval(&stats->tx_bytes,NULL), + watch64_getval(&stats->tx_packets,NULL), + watch64_getval(&stats->tx_errors,NULL), + watch64_getval(&stats->tx_dropped,NULL), + watch64_getval(&stats->tx_fifo_errors,NULL), + watch64_getval(&stats->collisions,NULL), + watch64_getval(&stats->tx_carrier_errors,NULL) + + watch64_getval(&stats->tx_aborted_errors,NULL) + + watch64_getval(&stats->tx_window_errors,NULL) + + watch64_getval(&stats->tx_heartbeat_errors,NULL), + watch64_getval(&stats->tx_compressed,NULL)); + } else + seq_printf(seq, "%6s: No statistics available.\n", dev->name); +} + +static void dev_seq_show_header(struct seq_file *seq) +{ + seq_puts(seq, "Inter-| Receive " + " | Transmit\n" + " face |bytes packets errs drop fifo frame " + "compressed multicast|bytes packets errs " + "drop fifo colls carrier compressed\n"); +} + /* * Called from the PROCfs module. This now uses the new arbitrary sized * /proc/net interface to create /proc/net/dev @@ -2117,16 +2163,21 @@ static int dev_seq_show(struct seq_file *seq, void *v) { if (v == SEQ_START_TOKEN) - seq_puts(seq, "Inter-| Receive " - " | Transmit\n" - " face |bytes packets errs drop fifo frame " - "compressed multicast|bytes packets errs " - "drop fifo colls carrier compressed\n"); + dev_seq_show_header(seq); else dev_seq_printf_stats(seq, v); return 0; } +static int dev_seq_show64(struct seq_file *seq, void *v) +{ + if (v == SEQ_START_TOKEN) + dev_seq_show_header(seq); + else + dev_seq_printf_stats64(seq, v); + return 0; +} + static struct netif_rx_stats *softnet_get_online(loff_t *pos) { struct netif_rx_stats *rc = NULL; @@ -2179,11 +2230,23 @@ .show = dev_seq_show, }; +static struct seq_operations dev_seq_ops64 = { + .start = dev_seq_start, + .next = dev_seq_next, + .stop = dev_seq_stop, + .show = dev_seq_show64, +}; + static int dev_seq_open(struct inode *inode, struct file *file) { return seq_open(file, &dev_seq_ops); } +static int dev_seq_open64(struct inode *inode, struct file *file) +{ + return seq_open(file, &dev_seq_ops64); +} + static struct file_operations dev_seq_fops = { .owner = THIS_MODULE, .open = dev_seq_open, @@ -2192,6 +2255,14 @@ .release = seq_release, }; +static struct file_operations dev_seq_fops64 = { + .owner = THIS_MODULE, + .open = dev_seq_open64, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + static struct seq_operations softnet_seq_ops = { .start = softnet_seq_start, .next = softnet_seq_next, @@ -2224,8 +2295,10 @@ if (!proc_net_fops_create("dev", S_IRUGO, &dev_seq_fops)) goto out; - if (!proc_net_fops_create("softnet_stat", S_IRUGO, &softnet_seq_fops)) + if (!proc_net_fops_create("dev64", S_IRUGO, &dev_seq_fops64)) goto out_dev; + if (!proc_net_fops_create("softnet_stat", S_IRUGO, &softnet_seq_fops)) + goto out_dev64; if (wireless_proc_init()) goto out_softnet; rc = 0; @@ -2233,6 +2306,8 @@ return rc; out_softnet: proc_net_remove("softnet_stat"); +out_dev64: + proc_net_remove("dev64"); out_dev: proc_net_remove("dev"); goto out; @@ -2910,6 +2985,9 @@ * device is present. */ + if (dev->get_stats) + net_register_stats64(dev->get_stats(dev)); + set_bit(__LINK_STATE_PRESENT, &dev->state); dev->next = NULL; @@ -2922,7 +3000,7 @@ dev_hold(dev); dev->reg_state = NETREG_REGISTERING; write_unlock_bh(&dev_base_lock); - + /* Notify protocols, that a new device appeared. */ notifier_call_chain(&netdev_chain, NETDEV_REGISTER, dev); @@ -3145,6 +3223,9 @@ /* If device is running, close it first. */ if (dev->flags & IFF_UP) dev_close(dev); + + if (dev->get_stats) + net_unregister_stats64(dev->get_stats(dev)); /* And unlink it from device chain. */ for (dp = &dev_base; (d = *dp) != NULL; dp = &d->next) { @@ -3246,6 +3327,98 @@ } #endif /* CONFIG_HOTPLUG_CPU */ +/* + * Register all the members of the net_device_stats structure + * + */ + +inline void net_register_stats64(struct net_device_stats* stats) +{ + if (!stats) + return; + + watch64_register(&stats->tx_packets,0); + watch64_enable (&stats->tx_packets,NULL); + watch64_register(&stats->rx_packets,0); + watch64_enable (&stats->rx_packets,NULL); + watch64_register(&stats->tx_bytes,0); + watch64_enable (&stats->tx_bytes,NULL); + watch64_register(&stats->rx_bytes,0); + watch64_enable (&stats->rx_bytes,NULL); + watch64_register(&stats->tx_errors,0); + watch64_enable (&stats->tx_errors,NULL); + watch64_register(&stats->rx_errors,0); + watch64_enable (&stats->rx_errors,NULL); + watch64_register(&stats->tx_dropped,0); + watch64_enable (&stats->tx_dropped,NULL); + watch64_register(&stats->rx_dropped,0); + watch64_enable (&stats->rx_dropped,NULL); + watch64_register(&stats->multicast,0); + watch64_enable (&stats->multicast,NULL); + watch64_register(&stats->collisions,0); + watch64_enable (&stats->collisions,NULL); + watch64_register(&stats->rx_length_errors,0); + watch64_enable (&stats->rx_length_errors,NULL); + watch64_register(&stats->rx_over_errors,0); + watch64_enable (&stats->rx_over_errors,NULL); + watch64_register(&stats->rx_crc_errors,0); + watch64_enable (&stats->rx_crc_errors,NULL); + watch64_register(&stats->rx_frame_errors,0); + watch64_enable (&stats->rx_frame_errors,NULL); + watch64_register(&stats->rx_fifo_errors,0); + watch64_enable (&stats->rx_fifo_errors,NULL); + watch64_register(&stats->rx_missed_errors,0); + watch64_enable (&stats->rx_missed_errors,NULL); + watch64_register(&stats->tx_aborted_errors,0); + watch64_enable (&stats->tx_aborted_errors,NULL); + watch64_register(&stats->tx_carrier_errors,0); + watch64_enable (&stats->tx_carrier_errors,NULL); + watch64_register(&stats->tx_fifo_errors,0); + watch64_enable (&stats->tx_fifo_errors,NULL); + watch64_register(&stats->tx_heartbeat_errors,0); + watch64_enable (&stats->tx_heartbeat_errors,NULL); + watch64_register(&stats->tx_window_errors,0); + watch64_enable (&stats->tx_window_errors,NULL); + watch64_register(&stats->rx_compressed,0); + watch64_enable (&stats->rx_compressed,NULL); + watch64_register(&stats->tx_compressed,0); + watch64_enable (&stats->tx_compressed,NULL); +} + +/* + * Unregister all the members of the net_device_stats structure + * + */ + +inline void net_unregister_stats64(struct net_device_stats* stats) +{ + if (!stats) + return; + + watch64_unregister(&stats->tx_packets,0); + watch64_unregister(&stats->rx_packets,0); + watch64_unregister(&stats->tx_bytes,0); + watch64_unregister(&stats->rx_bytes,0); + watch64_unregister(&stats->tx_errors,0); + watch64_unregister(&stats->rx_errors,0); + watch64_unregister(&stats->tx_dropped,0); + watch64_unregister(&stats->rx_dropped,0); + watch64_unregister(&stats->multicast,0); + watch64_unregister(&stats->collisions,0); + watch64_unregister(&stats->rx_length_errors,0); + watch64_unregister(&stats->rx_over_errors,0); + watch64_unregister(&stats->rx_crc_errors,0); + watch64_unregister(&stats->rx_frame_errors,0); + watch64_unregister(&stats->rx_fifo_errors,0); + watch64_unregister(&stats->rx_missed_errors,0); + watch64_unregister(&stats->tx_aborted_errors,0); + watch64_unregister(&stats->tx_carrier_errors,0); + watch64_unregister(&stats->tx_fifo_errors,0); + watch64_unregister(&stats->tx_heartbeat_errors,0); + watch64_unregister(&stats->tx_window_errors,0); + watch64_unregister(&stats->rx_compressed,0); + watch64_unregister(&stats->tx_compressed,0); +} /* * Initialize the DEV module. At boot time this walks the device list and diff -Nru a/net/core/net-sysfs.c b/net/core/net-sysfs.c --- a/net/core/net-sysfs.c 2004-09-03 12:22:08 -04:00 +++ b/net/core/net-sysfs.c 2004-09-03 12:22:08 -04:00 @@ -16,6 +16,7 @@ #include #include #include +#include #define to_class_dev(obj) container_of(obj,struct class_device,kobj) #define to_net_dev(class) container_of(class, struct net_device, class_dev) @@ -23,6 +24,7 @@ static const char fmt_hex[] = "%#x\n"; static const char fmt_dec[] = "%d\n"; static const char fmt_ulong[] = "%lu\n"; +static const char fmt_ullong[] = "%llu\n"; static inline int dev_isalive(const struct net_device *dev) { @@ -204,8 +206,8 @@ read_lock(&dev_base_lock); if (dev_isalive(dev) && dev->get_stats && (stats = (*dev->get_stats)(dev))) - ret = sprintf(buf, fmt_ulong, - *(unsigned long *)(((u8 *) stats) + offset)); + ret = sprintf(buf, fmt_ullong, + watch64_getval((unsigned long *)(((u8 *) stats) + offset),NULL)); read_unlock(&dev_base_lock); return ret; --Boundary_(ID_Gu5A8t3yfXnZW0k3kEIBKg)-- From afleming@freescale.com Fri Sep 3 15:18:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 15:18:44 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83MIdDg009752 for ; Fri, 3 Sep 2004 15:18:39 -0700 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i83MJYF7003825 for ; Fri, 3 Sep 2004 15:19:34 -0700 (MST) Received: from [10.82.17.240] ([10.82.17.240]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i83KHo3r026899 for ; Fri, 3 Sep 2004 15:18:16 -0500 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <29D06014-FDF7-11D8-942E-000393C30512@freescale.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: netdev@oss.sgi.com From: Andy Fleming Subject: Using schedule_work for interrupt handling Date: Fri, 3 Sep 2004 17:18:20 -0500 X-Mailer: Apple Mail (2.618) X-archive-position: 8395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev So I've done another bk pull (just a few minutes ago), and my driver is still broken. If this isn't the place to ask, please direct me to the appropriate list -- I'm getting desperate! So what I'm doing in my driver is handling the PHY link change interrupt by disabling and clearing the interrupt I recieve, then calling schedule_work() to invoke my actual handler outside of interrupt time. That function calls the various PHY configuration functions, configures the controller state appropriately, and then enables interrupts before returning. The entire interrupt function is: static irqreturn_t phy_interrupt(int irq, void *dev_id, struct pt_regs *regs) { struct net_device *dev = (struct net_device *) dev_id; struct gfar_private *priv = netdev_priv(dev); /* Clear the interrupt */ mii_clear_phy_interrupt(priv->mii_info); /* Disable PHY interrupts */ mii_configure_phy_interrupt(priv->mii_info, MII_INTERRUPT_DISABLED); /* Schedule the phy change */ schedule_work(&priv->tq); return IRQ_HANDLED; } In the gfar_startup() function (called from gfar_open()), I initialize the work queue: INIT_WORK(&priv->tq, gfar_phy_change, dev); And later, I request the irq: if (priv->einfo->flags & GFAR_HAS_PHY_INTR) { if (request_irq(priv->einfo->interruptPHY, phy_interrupt, SA_SHIRQ, "phy_interrupt", mii_info->dev) < 0) { printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n", mii_info->dev->name, priv->einfo->interruptPHY); } else { mii_configure_phy_interrupt(priv->mii_info, MII_INTERRUPT_ENABLED); return; } } (If the requesting the interrupt fails, it uses a timer, instead) Is this right? Am I missing a crucial step? I ask because this no longer works. The driver never successfully invokes gfar_phy_change(), and therefore never brings up the interface. I have tried MANY, MANY things to get this working for the last 2+ weeks, and nothing has succeeded. I can detail what I have done so far, if people think it will help, but for now I'm just seeing if anyone notices a flaw in my code (code which, I might add, works in 2.6.8.1). Is this just what I get for not using a "stable" kernel? If that's the case, then should I be submitting a bug to someone, so they know there may be a problem...somewhere? Thanks for any help, Andy Fleming PowerPC Software Enablement Freescale Semiconductor, Inc. From herbert@gondor.apana.org.au Fri Sep 3 16:50:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 16:50:14 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i83No40i014551 for ; Fri, 3 Sep 2004 16:50:05 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C3NoP-0002T3-00; Sat, 04 Sep 2004 09:49:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C3NoM-0001am-00; Sat, 04 Sep 2004 09:49:42 +1000 Date: Sat, 4 Sep 2004 09:49:41 +1000 To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-ID: <20040903234941.GA26247@gondor.apana.org.au> References: <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> <20040901222118.0ce4bcc6.davem@davemloft.net> <20040902130605.GA32570@gondor.apana.org.au> <20040903133623.GA23179@gondor.apana.org.au> <20040903090053.22c67bb9@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20040903090053.22c67bb9@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 03, 2004 at 09:00:53AM -0700, Stephen Hemminger wrote: > > > You'll also notice that I've put all dereferences of dev->*_ptr under > > the rcu_read_lock(). Without this we may get a neigh_parms that's > > already been released. > > I haven't looked at the exact code in detail, but don't you need > use rcu_dereference() as well to make sure and get the smp_read_barrier_depends > on Alpha. Not really because we're not depending on *dev->neigh_parms to be set to NULLon shutdown. In fact *dev->neigh_parms never gets set to NULL at all. If it did we'd have trouble cleaning up dead entries from the hash table. So there is no data-dependent read here whose order must be preserved when *dev is destroyed. But hang on a second, I had forgotten about the creation path. Indeed that is buggy without a barrier for every path except IPv6. Without the barrier, we may be reading NULL pointers from parms which may result in stale neigh entries lingering around. Or worse we may read complete garbage that was there before the memset on *dev was done. Fortunately the last bit probably can only be triggered if you're stepping through gdb :) So here is a patch to make sure that there is a barrier between the reading of dev->*_ptr and *dev->neigh_parms. With these barriers in place, it's clear that *dev->neigh_parms can no longer be NULL since once the parms are allocated, that pointer is never reset to NULL again. Therefore I've also removed the parms check in these paths. They were bogus to begin with since if they ever triggered then we'll have dead neigh entries stuck in the hash table. Unfortunately I couldn't arrange for this to happen with DECnet due to the dn_db->parms.up() call that's sandwiched between the assignment of dev->dn_ptr and dn_db->neigh_parms. So I've kept the parms check there but it will now fail instead of continuing. I've also added an smp_wmb() there so that at least we won't be reading garbage from dn_db->neigh_parms. DECnet is also buggy since there is no locking at all in the destruction path. It either needs locking or RCU like IPv4. Signed-off-by: Herbert Xu Thanks a lot, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== drivers/s390/net/qeth_main.c 1.14 vs edited ===== --- 1.14/drivers/s390/net/qeth_main.c 2004-09-04 08:22:06 +10:00 +++ edited/drivers/s390/net/qeth_main.c 2004-09-04 09:17:17 +10:00 @@ -6718,17 +6718,15 @@ } rcu_read_lock(); - in_dev = __in_dev_get(dev); + in_dev = rcu_dereference(__in_dev_get(dev)); if (in_dev == NULL) { rcu_read_unlock(); return -EINVAL; } parms = in_dev->arp_parms; - if (parms) { - __neigh_parms_put(neigh->parms); - neigh->parms = neigh_parms_clone(parms); - } + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); rcu_read_unlock(); neigh->type = inet_addr_type(*(u32 *) neigh->primary_key); ===== net/atm/clip.c 1.37 vs edited ===== --- 1.37/net/atm/clip.c 2004-09-04 08:22:07 +10:00 +++ edited/net/atm/clip.c 2004-09-04 09:18:22 +10:00 @@ -320,17 +320,15 @@ if (neigh->type != RTN_UNICAST) return -EINVAL; rcu_read_lock(); - in_dev = __in_dev_get(dev); + in_dev = rcu_dereference(__in_dev_get(dev)); if (!in_dev) { rcu_read_unlock(); return -EINVAL; } parms = in_dev->arp_parms; - if (parms) { - __neigh_parms_put(neigh->parms); - neigh->parms = neigh_parms_clone(parms); - } + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); rcu_read_unlock(); neigh->ops = &clip_neigh_ops; ===== net/decnet/dn_dev.c 1.25 vs edited ===== --- 1.25/net/decnet/dn_dev.c 2004-09-04 08:22:07 +10:00 +++ edited/net/decnet/dn_dev.c 2004-09-04 09:36:51 +10:00 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include @@ -1108,6 +1109,7 @@ memset(dn_db, 0, sizeof(struct dn_dev)); memcpy(&dn_db->parms, p, sizeof(struct dn_dev_parms)); + smp_wmb(); dev->dn_ptr = dn_db; dn_db->dev = dev; init_timer(&dn_db->timer); ===== net/decnet/dn_neigh.c 1.11 vs edited ===== --- 1.11/net/decnet/dn_neigh.c 2004-09-04 08:22:07 +10:00 +++ edited/net/decnet/dn_neigh.c 2004-09-04 09:33:12 +10:00 @@ -139,17 +139,20 @@ struct neigh_parms *parms; rcu_read_lock(); - dn_db = dev->dn_ptr; + dn_db = rcu_dereference(dev->dn_ptr); if (dn_db == NULL) { rcu_read_unlock(); return -EINVAL; } parms = dn_db->neigh_parms; - if (parms) { - __neigh_parms_put(neigh->parms); - neigh->parms = neigh_parms_clone(parms); + if (!parms) { + rcu_read_unlock(); + return -EINVAL; } + + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); rcu_read_unlock(); if (dn_db->use_long) ===== net/ipv4/arp.c 1.45 vs edited ===== --- 1.45/net/ipv4/arp.c 2004-09-04 08:22:07 +10:00 +++ edited/net/ipv4/arp.c 2004-09-04 09:17:46 +10:00 @@ -244,17 +244,15 @@ neigh->type = inet_addr_type(addr); rcu_read_lock(); - in_dev = __in_dev_get(dev); + in_dev = rcu_dereference(__in_dev_get(dev)); if (in_dev == NULL) { rcu_read_unlock(); return -EINVAL; } parms = in_dev->arp_parms; - if (parms) { - __neigh_parms_put(neigh->parms); - neigh->parms = neigh_parms_clone(parms); - } + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); rcu_read_unlock(); if (dev->hard_header == NULL) { ===== net/ipv6/ndisc.c 1.88 vs edited ===== --- 1.88/net/ipv6/ndisc.c 2004-09-04 08:22:07 +10:00 +++ edited/net/ipv6/ndisc.c 2004-09-04 09:28:12 +10:00 @@ -297,10 +297,8 @@ } parms = in6_dev->nd_parms; - if (parms) { - __neigh_parms_put(neigh->parms); - neigh->parms = neigh_parms_clone(parms); - } + __neigh_parms_put(neigh->parms); + neigh->parms = neigh_parms_clone(parms); rcu_read_unlock(); neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST; --DocE+STaALJfprDB-- From jgarzik@infradead.org Fri Sep 3 19:56:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Sep 2004 19:56:57 -0700 (PDT) Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i842upX2017313 for ; Fri, 3 Sep 2004 19:56:52 -0700 Received: from jgarzik by canuck.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1C3QjI-00074m-PP; Fri, 03 Sep 2004 22:56:40 -0400 Date: Fri, 3 Sep 2004 22:56:40 -0400 From: Jeff Garzik To: akpm@osdl.org, torvalds@osdl.org Cc: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x net driver fixes Message-ID: <20040904025640.GA27001@canuck.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 8397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/net/3c527.c | 13 ++---- drivers/net/8139cp.c | 2 - drivers/net/forcedeth.c | 78 +++++++++++++++++++++++++++-------------- drivers/net/r8169.c | 2 - drivers/net/wireless/airo.c | 1 drivers/net/wireless/wavelan.c | 11 +++-- 6 files changed, 66 insertions(+), 41 deletions(-) through these ChangeSets: (04/09/03 1.2021) [PATCH] fix media detection for nForce 2 nics attached is a patch that polls the media setting for non GigE nForce nics: Without polling, media changes are not autodetected. This is fatal, because the nic initialization is asynchroneous, thus "modprobe;ifup" resulted in a dead network connection. The attached patch fixes that problem. It's a repost of a patch I sent around three weeks ago: you objected that I rely on the nic irq instead of a software timer. I've documented why this is ok. (04/09/03 1.2020) [PATCH] airo build fix drivers/net/wireless/airo.c: In function `issuecommand': drivers/net/wireless/airo.c:3812: warning: implicit declaration of function `kernel_locked' *** Warning: "kernel_locked" [drivers/net/wireless/airo.ko] undefined! Signed-off-by: Andrew Morton (04/09/03 1.2019) [PATCH] wavelan uninitalised var. This seems a little odd, printing out the value of a variable we haven't read yet. Signed-off-by: Dave Jones (04/09/03 1.2018) [PATCH] 3c527 possible oops. If the alloc_skb() fails, we dereference it in the skb_reserve() call. Move the skb_reserve() call to after the NULL check. Also clean up some CodingStyle violations whilst in the vicinity. Signed-off-by: Dave Jones (04/08/31 1.1860.2.1) [netdrvr 8139cp,r8169] fix dma_addr_t sizeof test diff -Nru a/drivers/net/3c527.c b/drivers/net/3c527.c --- a/drivers/net/3c527.c 2004-09-03 22:20:03 -04:00 +++ b/drivers/net/3c527.c 2004-09-03 22:20:03 -04:00 @@ -751,18 +751,15 @@ rx_base=lp->rx_chain; - for(i=0; irx_ring[i].skb=alloc_skb(1532, GFP_KERNEL); - skb_reserve(lp->rx_ring[i].skb, 18); - - if(lp->rx_ring[i].skb==NULL) - { - for(;i>=0;i--) + if (lp->rx_ring[i].skb==NULL) { + for (;i>=0;i--) kfree_skb(lp->rx_ring[i].skb); return -ENOBUFS; } - + skb_reserve(lp->rx_ring[i].skb, 18); + p=isa_bus_to_virt(lp->base+rx_base); p->control=0; diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c 2004-09-03 22:20:03 -04:00 +++ b/drivers/net/8139cp.c 2004-09-03 22:20:03 -04:00 @@ -1698,7 +1698,7 @@ } /* Configure DMA attributes. */ - if ((sizeof(dma_addr_t) > 32) && + if ((sizeof(dma_addr_t) > 4) && !pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL) && !pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) { pci_using_dac = 1; diff -Nru a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c --- a/drivers/net/forcedeth.c 2004-09-03 22:20:03 -04:00 +++ b/drivers/net/forcedeth.c 2004-09-03 22:20:03 -04:00 @@ -75,6 +75,7 @@ * added CK804/MCP04 device IDs, code fixes * for registers, link status and other minor fixes. * 0.28: 21 Jun 2004: Big cleanup, making driver mostly endian safe + * 0.29: 31 Aug 2004: Add backup timer for link change notification. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -86,7 +87,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.28" +#define FORCEDETH_VERSION "0.29" #define DRV_NAME "forcedeth" #include @@ -120,10 +121,11 @@ * Hardware access: */ -#define DEV_NEED_LASTPACKET1 0x0001 -#define DEV_IRQMASK_1 0x0002 -#define DEV_IRQMASK_2 0x0004 -#define DEV_NEED_TIMERIRQ 0x0008 +#define DEV_NEED_LASTPACKET1 0x0001 /* set LASTPACKET1 in tx flags */ +#define DEV_IRQMASK_1 0x0002 /* use NVREG_IRQMASK_WANTED_1 for irq mask */ +#define DEV_IRQMASK_2 0x0004 /* use NVREG_IRQMASK_WANTED_2 for irq mask */ +#define DEV_NEED_TIMERIRQ 0x0008 /* set the timer irq flag in the irq mask */ +#define DEV_NEED_LINKTIMER 0x0010 /* poll link settings. Relies on the timer irq */ enum { NvRegIrqStatus = 0x000, @@ -367,6 +369,7 @@ #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) +#define LINK_TIMEOUT (3*HZ) #define DESC_VER_1 0x0 #define DESC_VER_2 0x02100 @@ -446,6 +449,11 @@ struct timer_list oom_kick; struct timer_list nic_poll; + /* media detection workaround. + * Locking: Within irq hander or disable_irq+spin_lock(&np->lock); + */ + int need_linktimer; + unsigned long link_timeout; /* * tx specific fields. */ @@ -1384,6 +1392,25 @@ return retval; } +static void nv_linkchange(struct net_device *dev) +{ + if (nv_update_linkspeed(dev)) { + if (netif_carrier_ok(dev)) { + nv_stop_rx(dev); + } else { + netif_carrier_on(dev); + printk(KERN_INFO "%s: link up.\n", dev->name); + } + nv_start_rx(dev); + } else { + if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + printk(KERN_INFO "%s: link down.\n", dev->name); + nv_stop_rx(dev); + } + } +} + static void nv_link_irq(struct net_device *dev) { u8 *base = get_hwbase(dev); @@ -1391,25 +1418,10 @@ miistat = readl(base + NvRegMIIStatus); writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - dprintk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); + dprintk(KERN_INFO "%s: link change irq, status 0x%x.\n", dev->name, miistat); - if (miistat & (NVREG_MIISTAT_LINKCHANGE)) { - if (nv_update_linkspeed(dev)) { - if (netif_carrier_ok(dev)) { - nv_stop_rx(dev); - } else { - netif_carrier_on(dev); - printk(KERN_INFO "%s: link up.\n", dev->name); - } - nv_start_rx(dev); - } else { - if (netif_carrier_ok(dev)) { - netif_carrier_off(dev); - printk(KERN_INFO "%s: link down.\n", dev->name); - nv_stop_rx(dev); - } - } - } + if (miistat & (NVREG_MIISTAT_LINKCHANGE)) + nv_linkchange(dev); dprintk(KERN_DEBUG "%s: link change notification done.\n", dev->name); } @@ -1452,6 +1464,12 @@ nv_link_irq(dev); spin_unlock(&np->lock); } + if (np->need_linktimer && time_after(jiffies, np->link_timeout)) { + spin_lock(&np->lock); + nv_linkchange(dev); + spin_unlock(&np->lock); + np->link_timeout = jiffies + LINK_TIMEOUT; + } if (events & (NVREG_IRQ_TX_ERR)) { dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n", dev->name, events); @@ -1816,6 +1834,14 @@ np->irqmask = NVREG_IRQMASK_WANTED_2; if (id->driver_data & DEV_NEED_TIMERIRQ) np->irqmask |= NVREG_IRQ_TIMER; + if (id->driver_data & DEV_NEED_LINKTIMER) { + dprintk(KERN_INFO "%s: link timer on.\n", pci_name(pci_dev)); + np->need_linktimer = 1; + np->link_timeout = jiffies + LINK_TIMEOUT; + } else { + dprintk(KERN_INFO "%s: link timer off.\n", pci_name(pci_dev)); + np->need_linktimer = 0; + } /* find a suitable phy */ for (i = 1; i < 32; i++) { @@ -1909,21 +1935,21 @@ .device = PCI_DEVICE_ID_NVIDIA_NVENET_1, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ, + .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER, }, { /* nForce2 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, .device = PCI_DEVICE_ID_NVIDIA_NVENET_2, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER, }, { /* nForce3 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, .device = PCI_DEVICE_ID_NVIDIA_NVENET_3, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER, }, { /* nForce3 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2004-09-03 22:20:03 -04:00 +++ b/drivers/net/r8169.c 2004-09-03 22:20:03 -04:00 @@ -983,7 +983,7 @@ tp->cp_cmd = PCIMulRW | RxChkSum; - if ((sizeof(dma_addr_t) > 32) && + if ((sizeof(dma_addr_t) > 4) && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) tp->cp_cmd |= PCIDAC; else { diff -Nru a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c --- a/drivers/net/wireless/airo.c 2004-09-03 22:20:03 -04:00 +++ b/drivers/net/wireless/airo.c 2004-09-03 22:20:03 -04:00 @@ -25,6 +25,7 @@ #include #include #include +#include #include #include diff -Nru a/drivers/net/wireless/wavelan.c b/drivers/net/wireless/wavelan.c --- a/drivers/net/wireless/wavelan.c 2004-09-03 22:20:03 -04:00 +++ b/drivers/net/wireless/wavelan.c 2004-09-03 22:20:03 -04:00 @@ -3822,17 +3822,18 @@ if ((hasr & HASR_MMC_INTR) && (lp->hacr & HACR_MMC_INT_ENABLE)) { u8 dce_status; -#ifdef DEBUG_INTERRUPT_ERROR - printk(KERN_INFO - "%s: wavelan_interrupt(): unexpected mmc interrupt: status 0x%04x.\n", - dev->name, dce_status); -#endif /* * Interrupt from the modem management controller. * This will clear it -- ignored for now. */ mmc_read(ioaddr, mmroff(0, mmr_dce_status), &dce_status, sizeof(dce_status)); + +#ifdef DEBUG_INTERRUPT_ERROR + printk(KERN_INFO + "%s: wavelan_interrupt(): unexpected mmc interrupt: status 0x%04x.\n", + dev->name, dce_status); +#endif } /* Check if not controller interrupt */ From hadi@cyberus.ca Sat Sep 4 06:20:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 06:20:36 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84DKVQn007432 for ; Sat, 4 Sep 2004 06:20:31 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090406215222:29254 ; Sat, 4 Sep 2004 06:21:52 -0700 Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system From: jamal Reply-To: hadi@cyberus.ca To: "Josef 'Jeff' Sipek" Cc: Stephen Hemminger , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <200409031744.32970.jeffpc@optonline.net> References: <200409031307.01240.jeffpc@optonline.net> <200409031319.24863.jeffpc@optonline.net> <20040903121657.355a6a8b@dell_ss3.pdx.osdl.net> <200409031744.32970.jeffpc@optonline.net> Organization: jamalopolis Message-Id: <1094303999.1633.116.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Sep 2004 09:19:59 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/04/2004 06:21:52 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/04/2004 06:21:55 AM, Serialize complete at 09/04/2004 06:21:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev I have a feeling this was discussed somewhere(other than netdev) and i missed it. Why isnt this watch64 being done in user space? cheers, jamal On Fri, 2004-09-03 at 17:44, Josef 'Jeff' Sipek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 03 September 2004 15:16, Stephen Hemminger wrote: > > - Code doesn't match the kernel style (read Documentation/CodingStyle) > > Sorry about the white space, KMail apparently likes to butcher the text. These > are the same patches with the little cleanup update. > > Jeff. > > - -- > Reality is merely an illusion, albeit a very persistent one. > - Albert Einstein > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iD4DBQFBOOW+wFP0+seVj/4RAgSiAJj54qcqdEx66lbMW9ik0XviupTNAKC82an1 > R0pGX0pTBZ78NWrZpxJm+w== > =EesC > -----END PGP SIGNATURE----- From ak@muc.de Sat Sep 4 06:28:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 06:28:24 -0700 (PDT) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i84DSJ1o007817 for ; Sat, 4 Sep 2004 06:28:19 -0700 Received: (qmail 42471 invoked by uid 3709); 4 Sep 2004 13:28:09 -0000 Date: 4 Sep 2004 15:28:09 +0200 Date: Sat, 4 Sep 2004 15:28:09 +0200 From: Andi Kleen To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [PATCH] Extend lock less TX to real devices Message-ID: <20040904132809.GB33964@muc.de> References: <20040901223301.1a8d97a8.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901223301.1a8d97a8.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 8399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev On Wed, Sep 01, 2004 at 10:33:01PM -0700, David S. Miller wrote: > On Tue, 31 Aug 2004 14:38:20 +0200 > Andi Kleen wrote: > > > This patch extends the recently added NETIF_F_LLTX to real devices. > > Well, it does a lot of other things too. Not really, it all works to the same goal. > > > I added support for trylocking instead of spinning like sch_generic > > does - for that the driver has to return -1, then the packet is requeued. > > The check for a local device deadlock is lost for this case, > > but that doesn't seem to be a big loss (I've never seen this printk > > ever get triggered) > > It is triggerable if you misconfigure your system. Really? The only reason I can see for it is a buggy driver. > I'm totally against this change, because previously at There is no change, except for drivers that set LLTX and these get different semantics anyways because they have to handle this on their own. In case the driver has bugs I guess it would be better to add the printk directly below the try_lock in the LLTX driver. > least the user would find out in their logs. With your > change the system explodes looping with no explanation why. Hmm, I guess if you're really worried about this class of driver bugs being common adding some real error handling for it (like bailing out and disabling the device) would be the far better option. > > > The patch looks bigger than it really is because i moved some code > > around and converted the macros into inlines. > .. > > I also did an additional micro optimization: > > And for this reason you need to split this patch up. > I would recommend: > > patch 1) Change macros into inlines > patch 2) local_bh_disable() preemption count optimization > patch 3) support for F_LLTX on real devices > patch 4) locking changes At least (3) and (4) are the same thing. I can drop the inlines, it was only for making the code clearer and less ugly but is not essential for the optimizations. -Andi From ak@suse.de Sat Sep 4 06:54:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 06:55:00 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84Dsrud008610 for ; Sat, 4 Sep 2004 06:54:54 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C6BCEB7E597; Sat, 4 Sep 2004 15:54:39 +0200 (CEST) Date: Sat, 4 Sep 2004 15:54:39 +0200 From: Andi Kleen To: davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] Do less atomic count changes in dev_queue_xmit Message-ID: <20040904135439.GA23934@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Do a single local_bh_disable and a single local_bh_enable instead of changing the atomic count all the time in dev_queue_xmit. Should mostly benefit preemptible kernels, but others see some small improvements too. diff -u linux-2.6.8/net/core/dev.c-o linux-2.6.8/net/core/dev.c --- linux-2.6.8/net/core/dev.c-o 2004-09-04 13:10:47.000000000 +0000 +++ linux-2.6.8/net/core/dev.c 2004-09-04 13:47:16.765722813 +0000 @@ -1249,14 +1249,14 @@ return 0; } -#define HARD_TX_LOCK_BH(dev, cpu) { \ +#define HARD_TX_LOCK(dev, cpu) { \ if ((dev->features & NETIF_F_LLTX) == 0) { \ spin_lock_bh(&dev->xmit_lock); \ dev->xmit_lock_owner = cpu; \ } \ } -#define HARD_TX_UNLOCK_BH(dev) { \ +#define HARD_TX_UNLOCK(dev) { \ if ((dev->features & NETIF_F_LLTX) == 0) { \ dev->xmit_lock_owner = -1; \ spin_unlock_bh(&dev->xmit_lock); \ @@ -1313,7 +1313,12 @@ if (skb_checksum_help(&skb, 0)) goto out_kfree_skb; - rcu_read_lock(); + + /* Disable soft irqs for various locks below. Also + * stops preemption for RCU. + */ + local_bh_disable(); + /* Updates of qdisc are serialized by queue_lock. * The struct Qdisc which is pointed to by qdisc is now a * rcu structure - it may be accessed without acquiring @@ -1332,18 +1337,16 @@ #endif if (q->enqueue) { /* Grab device queue */ - spin_lock_bh(&dev->queue_lock); + spin_lock(&dev->queue_lock); rc = q->enqueue(skb, q); qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); - rcu_read_unlock(); + spin_unlock(&dev->queue_lock); rc = rc == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : rc; goto out; } - rcu_read_unlock(); /* The device has no queue. Common case for software devices: loopback, all the sorts of tunnels... @@ -1358,12 +1361,11 @@ Either shot noqueue qdisc, it is even simpler 8) */ if (dev->flags & IFF_UP) { - int cpu = get_cpu(); + int cpu = smp_processor_id(); /* ok because BHs are off */ if (dev->xmit_lock_owner != cpu) { - HARD_TX_LOCK_BH(dev, cpu); - put_cpu(); + HARD_TX_LOCK(dev, cpu); if (!netif_queue_stopped(dev)) { if (netdev_nit) @@ -1371,17 +1373,16 @@ rc = 0; if (!dev->hard_start_xmit(skb, dev)) { - HARD_TX_UNLOCK_BH(dev); + HARD_TX_UNLOCK(dev); goto out; } } - HARD_TX_UNLOCK_BH(dev); + HARD_TX_UNLOCK(dev); if (net_ratelimit()) printk(KERN_CRIT "Virtual device %s asks to " "queue packet!\n", dev->name); goto out_enetdown; } else { - put_cpu(); /* Recursion is detected! It is possible, * unfortunately */ if (net_ratelimit()) @@ -1394,6 +1395,7 @@ out_kfree_skb: kfree_skb(skb); out: + local_bh_enable(); return rc; } From hadi@cyberus.ca Sat Sep 4 07:12:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 07:12:25 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84ECK2R009182 for ; Sat, 4 Sep 2004 07:12:20 -0700 Received: from localhost ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090407134204:29279 ; Sat, 4 Sep 2004 07:13:42 -0700 Subject: Re: [PATCH] Extend lock less TX to real devices From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: "David S. Miller" , Alexey , netdev@oss.sgi.com, akepner@sgi.com In-Reply-To: <20040904132809.GB33964@muc.de> References: <20040901223301.1a8d97a8.davem@redhat.com> <20040904132809.GB33964@muc.de> Organization: jamalopolis Message-Id: <1094307106.1634.147.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Sep 2004 10:11:46 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/04/2004 07:13:42 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/04/2004 07:13:44 AM, Serialize complete at 09/04/2004 07:13:44 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-09-04 at 09:28, Andi Kleen wrote: > On Wed, Sep 01, 2004 at 10:33:01PM -0700, David S. Miller wrote: > > On Tue, 31 Aug 2004 14:38:20 +0200 > > Andi Kleen wrote: > > > > > This patch extends the recently added NETIF_F_LLTX to real devices. > > > > Well, it does a lot of other things too. > > Not really, it all works to the same goal. Must be my sleep depravation - what is LLTX again? > > least the user would find out in their logs. With your > > change the system explodes looping with no explanation why. > > Hmm, I guess if you're really worried about this class > of driver bugs ble eing common adding some real error handling > for it (like bailing out and disabling the device) would > be the far better option. Actually that message is pretty useful. I have seen at least a handful of badly written drivers do that. Was also very useful for me when i was doing the tc extensions. I was able to catch a few bugs - so not just driver related. > > patch 1) Change macros into inlines > > patch 2) local_bh_disable() preemption count optimization > > patch 3) support for F_LLTX on real devices > > patch 4) locking changes > > At least (3) and (4) are the same thing. I can drop the > inlines, it was only for making the code clearer and less ugly > but is not essential for the optimizations. do you guys mind if i test these patches/patch out first before final inclusion? Next weekend i will have the chance. cheers, jamal From ak@suse.de Sat Sep 4 07:27:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 07:27:13 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84ER76U009692 for ; Sat, 4 Sep 2004 07:27:07 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0D877B7DB65; Sat, 4 Sep 2004 16:24:14 +0200 (CEST) Date: Sat, 4 Sep 2004 16:24:04 +0200 From: Andi Kleen To: jamal Cc: Andi Kleen , "David S. Miller" , Alexey , netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [PATCH] Extend lock less TX to real devices Message-ID: <20040904142404.GA6850@wotan.suse.de> References: <20040901223301.1a8d97a8.davem@redhat.com> <20040904132809.GB33964@muc.de> <1094307106.1634.147.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094307106.1634.147.camel@jzny.localdomain> X-archive-position: 8402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Sat, Sep 04, 2004 at 10:11:46AM -0400, jamal wrote: > On Sat, 2004-09-04 at 09:28, Andi Kleen wrote: > > On Wed, Sep 01, 2004 at 10:33:01PM -0700, David S. Miller wrote: > > > On Tue, 31 Aug 2004 14:38:20 +0200 > > > Andi Kleen wrote: > > > > > > > This patch extends the recently added NETIF_F_LLTX to real devices. > > > > > > Well, it does a lot of other things too. > > > > Not really, it all works to the same goal. > > Must be my sleep depravation - what is LLTX again? NETIF_F_LLTX - a new flag that tells the stack the the driver doesn't want an xmit lock. > > > > > least the user would find out in their logs. With your > > > change the system explodes looping with no explanation why. > > > > Hmm, I guess if you're really worried about this class > > of driver bugs ble eing common adding some real error handling > > for it (like bailing out and disabling the device) would > > be the far better option. > > Actually that message is pretty useful. > I have seen at least a handful of badly written drivers do that. They will still print that, no problem. > > > > patch 1) Change macros into inlines > > > patch 2) local_bh_disable() preemption count optimization > > > patch 3) support for F_LLTX on real devices > > > patch 4) locking changes > > > > At least (3) and (4) are the same thing. I can drop the > > inlines, it was only for making the code clearer and less ugly > > but is not essential for the optimizations. > > do you guys mind if i test these patches/patch out first before final > inclusion? Next weekend i will have the chance. You can do that, but they won't do much unless your driver sets NETIF_F_LLTX. -Andi From herbert@gondor.apana.org.au Sat Sep 4 12:40:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 12:40:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84Jeeam022183 for ; Sat, 4 Sep 2004 12:40:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C3gNk-0000EX-00; Sun, 05 Sep 2004 05:39:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C3gNb-0006DO-00; Sun, 05 Sep 2004 05:39:19 +1000 From: Herbert Xu To: ak@muc.de (Andi Kleen) Subject: Re: [PATCH] Extend lock less TX to real devices Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, akepner@sgi.com Organization: Core In-Reply-To: <20040904132809.GB33964@muc.de> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sun, 05 Sep 2004 05:39:19 +1000 X-archive-position: 8403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Andi Kleen wrote: > >> > I added support for trylocking instead of spinning like sch_generic >> > does - for that the driver has to return -1, then the packet is requeued. >> > The check for a local device deadlock is lost for this case, >> > but that doesn't seem to be a big loss (I've never seen this printk >> > ever get triggered) >> >> It is triggerable if you misconfigure your system. > > Really? The only reason I can see for it is a buggy driver. Is this the dead loop message? If so it can happen with tunnels. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From han@mijncomputer.nl Sat Sep 4 13:21:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 13:21:26 -0700 (PDT) Received: from boetes.org (cc15467-a.groni1.gr.home.nl [217.120.147.78]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i84KLH2b023278 for ; Sat, 4 Sep 2004 13:21:18 -0700 Received: (qmail 1941 invoked by uid 1000); 4 Sep 2004 20:21:29 -0000 Date: Sat, 4 Sep 2004 22:21:07 +0200 From: Han Boetes To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [Fwd: rtl8169 driver from realtek] Message-ID: <20040904202129.GJ2387@boetes.org> References: <4139ED5B.2030002@pobox.com> <20040904182404.GB16875@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040904182404.GB16875@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6i X-archive-position: 8404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: han@mijncomputer.nl Precedence: bulk X-list: netdev Francois Romieu wrote: > Hello M. Boetes, Bonjour :) > Jeff was kind enough to forward your message to me. Very kind indeed. > Can you provide: > - the kernel/compiler version (vendor/hand built/modular kernel); One thing: this is with the driver from realtek. After this run I'll send you another reply with the normal kernel driver. So you are about to get a very similar mail from me. Linux marsupilami 2.6.9-rc1 #3 Thu Sep 2 21:39:26 CEST 2004 i686 unknown unknown GNU/Linux, a hand build static kernel, only one module ( nvidia driver ) Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs Configured with: ../gcc-3.3.3/configure --prefix=/usr --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls Thread model: posix gcc version 3.3.3 (CRUX) > - the complete dmesg after boot once the r8169 is ifconfig'ed up Linux version 2.6.9-rc1 (han@bereboot) (gcc version 3.3.3 (CRUX)) #3 Thu Sep 2 21:39:26 CEST 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000002fff0000 (usable) BIOS-e820: 000000002fff0000 - 000000002fff8000 (ACPI data) BIOS-e820: 000000002fff8000 - 0000000030000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 767MB LOWMEM available. On node 0 totalpages: 196592 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 192496 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. Built 1 zonelists Kernel command line: BOOT_IMAGE=269rc1 ro root=305 acpi=off hdc=ide-cd hdd=ide-cd ide_setup: hdc=ide-cd ide_setup: hdd=ide-cd Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 1467.420 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 774920k/786368k available (2321k kernel code, 10696k reserved, 710k data, 396k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 2891.77 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 1700+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Edge set to Level Trigger. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040715 ACPI: Interpreter disabled. usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router default [1106/3147] at 0000:00:11.0 PCI: IRQ 0 for device 0000:00:11.1 doesn't match PIRQ mask - try pci=usepirqmask PCI: Hardcoded IRQ 14 for device 0000:00:11.1 get_random_bytes called before random driver initialization vesafb: framebuffer at 0xd0000000, mapped to 0xf0807000, size 3072k vesafb: mode is 1024x768x16, linelength=2048, pages=1 vesafb: protected mode interface info at c000:e4d0 vesafb: scrolling: redraw vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 fb0: VESA VGA frame buffer device Machine check exception polling timer started. apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: driver version: No APM present Console: switching to colour frame buffer device 128x48 Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT266/KY266x/KT333 chipset agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 128M @ 0xe0000000 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) 8139too Fast Ethernet driver 0.9.27 eth0: RealTek RTL8139 at 0xf0b88f00, 00:e0:4c:67:52:80, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139B' Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky eth1: Identified chip type is 'RTL8169s/8110s'. eth1: RTL8169s/8110s Gigabit Ethernet driver 2.2 at 0xe400, 00:08:a1:3c:34:7a, IRQ 12 eth1: Auto-negotiation Enabled. eth1: 1000Mbps Full-duplex operation. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 PCI: Hardcoded IRQ 14 for device 0000:00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8233a (rev 00) IDE UDMA133 controller on pci0000:00:11.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio hda: ST340823A, ATA DISK drive hdb: BDV 108A DVDROM, ATAPI CD/DVD-ROM drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: LITE-ON LTR-40125S, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 78165360 sectors (40020 MB) w/512KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > hdb: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 hdc: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) ide-floppy driver 0.99.newide USB Universal Host Controller Interface driver v2.2 uhci_hcd 0000:00:11.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:11.2: irq 5, io base 0000d800 uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected uhci_hcd 0000:00:11.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:11.3: irq 5, io base 0000dc00 uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 Advanced Linux Sound Architecture Driver Version 1.0.4 (Mon May 17 14:31:44 2004 UTC). AC'97 0 analog subsections not ready ALSA device list: #0: Sound Blaster Live! (rev.7) at 0xe000, irq 10 NET: Registered protocol family 2 IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 usb 1-1: new low speed USB device using address 2 UDF-fs: No VRS found HID Mouse 0xc024 forced to 2 ms polling VFS: Mounted root (jfs filesystem) readonly. Freeing unused kernel memory: 396k freed input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:11.2-1 Adding 257000k swap on /dev/hda6. Priority:-1 extents:1 > - the content of the /proc/interrupts file once the r8169 is ifconfig'ed up CPU0 0: 365527 XT-PIC timer 1: 1830 XT-PIC i8042 2: 0 XT-PIC cascade 5: 2310 XT-PIC uhci_hcd, uhci_hcd 8: 1 XT-PIC rtc 10: 0 XT-PIC EMU10K1 12: 2819 XT-PIC eth1 14: 3207 XT-PIC ide0 15: 20 XT-PIC ide1 NMI: 0 ERR: 0 > - a short description of the "does not work" I'm terribly sorry I didn't provide it. This is the description of what goes wrong with the realtek-driver: One single transfer goes ok as far as I can tell. But once I start doing multiple things, all over nfs, like listening to an mp3 and sending over files the connection gets the hickups. > - the brand of the 8169 cards (if any) This is a real GIGABIT ETHERNET CARD from 19 Euro at my favourite provider. :-) > If you have some version of the Realtek's driver prior to the 2.2 version > which are not available on their site any more, I'll welcome these. No I don't have any other drivers from them. > > Please let me know which driver you think is the best. > > None :o) > -> in tree driver does not work for you > -> From a quick look, Realtek's driver does not include a single barrier > instruction and the failure paths in rtl8169_open() are broken. I would > not be surprized that some fixes are missing which are available in the > kernel tree. No NAPI nor ethtool. Jumbo frames support and other > goodies are there though. Okay, I'll have to isolate the differences. > If you can stay with us until an in kernel, modified, r8169 driver works > with your setup, it should be possible to get the best of both worlds. Ok, now lets try the normal kernel driver with a clear head. # Han -- (I hate large) \||/ A man is already halfway in love with any (sigs) Oo. | @___oo woman who listens to him. -- Brendan Francis /\ /\ / (__,,,,| ) /^\) ^\/ _) ) /^\/ _) ) _ / / _) /\ )/\/ || | )_) < > |(,,) )__) || / \)___)\ | \____( )___) )___ \______(_______;;; __;;; From uucp@ganesha.gnumonks.org Sat Sep 4 13:38:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 13:38:18 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84KcB77023776 for ; Sat, 4 Sep 2004 13:38:12 -0700 Received: from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.30) id 1C3hIL-0001yt-6q for netdev@oss.sgi.com; Sat, 04 Sep 2004 22:37:57 +0200 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1C3gmk-0004cM-00; Sat, 04 Sep 2004 22:05:18 +0200 Date: Sat, 4 Sep 2004 22:05:18 +0200 From: Harald Welte To: "David S. Miller" Cc: Harald Welte , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] 2/2: Fix NAT helper locking Message-ID: <20040904200518.GC11414@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , "David S. Miller" , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com References: <20040903070234.GQ26263@sunbeam.de.gnumonks.org> <20040903002453.77beee16.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="adJ1OR3c6QgCpb/j" Content-Disposition: inline In-Reply-To: <20040903002453.77beee16.davem@davemloft.net> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.8-rc2-nfp0722-tcpwin X-Date: Today is Pungenday, the 23rd day of Chaos in the YOLD 3070 User-Agent: Mutt/1.5.6+20040722i X-archive-position: 8405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --adJ1OR3c6QgCpb/j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2004 at 12:24:53AM -0700, David S. Miller wrote: =20 > Ummm... wow what ancient tree did you patch against > Harald? The tree you patched against didn't even have the > skb_header_pointer() changes in it, that's caveman > era :-) That's what caused the rejects. I tried to apply the patch against 2.6.9-rc1 before sending it to you. It had offsets, but applied cleanly > Thanks. --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --adJ1OR3c6QgCpb/j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBOh/+XaXGVTD0i/8RAgXLAJ4tcjBuw7+0CoQGe1FK9Dc1/2LB+ACbBtxK 8sWfs0Pl9hdUDYNq+oDE+KA= =k3Xl -----END PGP SIGNATURE----- --adJ1OR3c6QgCpb/j-- From han@mijncomputer.nl Sat Sep 4 14:18:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 14:18:57 -0700 (PDT) Received: from boetes.org (cc15467-a.groni1.gr.home.nl [217.120.147.78]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i84LIoPT024864 for ; Sat, 4 Sep 2004 14:18:51 -0700 Received: (qmail 21712 invoked by uid 1000); 4 Sep 2004 21:19:02 -0000 Date: Sat, 4 Sep 2004 23:18:40 +0159 From: Han Boetes To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [Fwd: rtl8169 driver from realtek] Message-ID: <20040904211902.GK2387@boetes.org> References: <4139ED5B.2030002@pobox.com> <20040904182404.GB16875@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040904182404.GB16875@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.5.6i X-archive-position: 8406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: han@mijncomputer.nl Precedence: bulk X-list: netdev Here we go again. This is with the normal kernel-driver. It works fine. Obviously I did something else wrong and drew the wrong conclusion. Excuse me for that. Heavy stress-tests work fine with this driver! Francois Romieu wrote: > - the complete dmesg after boot once the r8169 is ifconfig'ed up Linux version 2.6.9-rc1 (han@marsupilami) (gcc version 3.3.3 (CRUX)) #1 Sat Sep 4 22:43:12 CEST 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000002fff0000 (usable) BIOS-e820: 000000002fff0000 - 000000002fff8000 (ACPI data) BIOS-e820: 000000002fff8000 - 0000000030000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 767MB LOWMEM available. On node 0 totalpages: 196592 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 192496 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. Built 1 zonelists Kernel command line: BOOT_IMAGE=269rc1 ro root=305 acpi=off hdc=ide-cd hdd=ide-cd ide_setup: hdc=ide-cd ide_setup: hdd=ide-cd Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 1467.420 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 774912k/786368k available (2324k kernel code, 10704k reserved, 714k data, 396k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 2891.77 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 1700+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Edge set to Level Trigger. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040715 ACPI: Interpreter disabled. usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router default [1106/3147] at 0000:00:11.0 PCI: IRQ 0 for device 0000:00:11.1 doesn't match PIRQ mask - try pci=usepirqmask PCI: Hardcoded IRQ 14 for device 0000:00:11.1 get_random_bytes called before random driver initialization vesafb: framebuffer at 0xd0000000, mapped to 0xf0807000, size 3072k vesafb: mode is 1024x768x16, linelength=2048, pages=1 vesafb: protected mode interface info at c000:e4d0 vesafb: scrolling: redraw vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 fb0: VESA VGA frame buffer device Machine check exception polling timer started. apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: driver version: No APM present Console: switching to colour frame buffer device 128x48 Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT266/KY266x/KT333 chipset agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 128M @ 0xe0000000 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) 8139too Fast Ethernet driver 0.9.27 eth0: RealTek RTL8139 at 0xf0b88f00, 00:e0:4c:67:52:80, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139B' Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky r8169 Gigabit Ethernet driver 1.2 loaded eth1: Identified chip type is 'RTL8169s/8110s'. eth1: RTL8169 at 0xf0b8ae00, 00:08:a1:3c:34:7a, IRQ 12 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 PCI: Hardcoded IRQ 14 for device 0000:00:11.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8233a (rev 00) IDE UDMA133 controller on pci0000:00:11.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio hda: ST340823A, ATA DISK drive hdb: BDV 108A DVDROM, ATAPI CD/DVD-ROM drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: LITE-ON LTR-40125S, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 78165360 sectors (40020 MB) w/512KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > hdb: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 hdc: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) ide-floppy driver 0.99.newide USB Universal Host Controller Interface driver v2.2 uhci_hcd 0000:00:11.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:11.2: irq 5, io base 0000d800 uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected uhci_hcd 0000:00:11.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:11.3: irq 5, io base 0000dc00 uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 Advanced Linux Sound Architecture Driver Version 1.0.4 (Mon May 17 14:31:44 2004 UTC). ALSA device list: #0: Sound Blaster Live! (rev.7) at 0xe000, irq 10 NET: Registered protocol family 2 IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 usb 1-1: new low speed USB device using address 2 UDF-fs: No VRS found VFS: Mounted root (jfs filesystem) readonly. Freeing unused kernel memory: 396k freed HID Mouse 0xc024 forced to 2 ms polling input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:11.2-1 Adding 257000k swap on /dev/hda6. Priority:-1 extents:1 > - the content of the /proc/interrupts file once the r8169 is ifconfig'ed up CPU0 0: 1012596 XT-PIC timer 1: 2271 XT-PIC i8042 2: 0 XT-PIC cascade 5: 35354 XT-PIC uhci_hcd, uhci_hcd 8: 1 XT-PIC rtc 10: 8922 XT-PIC EMU10K1 11: 68450 XT-PIC nvidia 12: 203034 XT-PIC eth1 14: 7347 XT-PIC ide0 15: 20 XT-PIC ide1 NMI: 0 ERR: 0 > If you can stay with us until an in kernel, modified, r8169 driver > works with your setup, it should be possible to get the best of both > worlds. Please let me know if you want to test new patches based on stuff you found in the realtek driver. # Han -- A random bookmark: http://crypto.yashy.com/nmap.php From romieu@fr.zoreil.com Sat Sep 4 14:46:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 14:46:39 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84LkWso025634 for ; Sat, 4 Sep 2004 14:46:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i84LiLvr019952; Sat, 4 Sep 2004 23:44:21 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i84LiLBQ019951; Sat, 4 Sep 2004 23:44:21 +0200 Date: Sat, 4 Sep 2004 23:44:21 +0200 From: Francois Romieu To: Han Boetes Cc: netdev@oss.sgi.com Subject: Re: [Fwd: rtl8169 driver from realtek] Message-ID: <20040904214243.GA19728@electric-eye.fr.zoreil.com> References: <4139ED5B.2030002@pobox.com> <20040904182404.GB16875@electric-eye.fr.zoreil.com> <20040904211902.GK2387@boetes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040904211902.GK2387@boetes.org> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Han Boetes : > > Here we go again. This is with the normal kernel-driver. It works > fine. Obviously I did something else wrong and drew the wrong > conclusion. Excuse me for that. Success reports are welcome too :o) -- Ueimor From alex@towebs.com Sat Sep 4 15:34:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 15:34:17 -0700 (PDT) Received: from gate-one.toservers.com (customer.iplannetworks.net [200.69.210.29] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i84MY9wS026615; Sat, 4 Sep 2004 15:34:10 -0700 Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 0F1695F9EB; Sat, 4 Sep 2004 22:32:13 +0000 (UTC) Received: from [10.10.1.38] (alexis [10.10.1.38]) by gate-one.toservers.com (Postfix) with ESMTP id 804305F9C7; Sat, 4 Sep 2004 22:32:12 +0000 (UTC) Message-ID: <413A1566.6050807@towebs.com> Date: Sat, 04 Sep 2004 19:20:06 +0000 From: Alex User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040819 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, majordomo@oss.sgi.com Subject: Host AP driver for Intersil Prism2/2.5/3 X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@towebs.com Precedence: bulk X-list: netdev This driver is not build-in in linux kernel. http://www.inlab.csp.it/tools/wireless/hostqs/ From listmoved@calle.in-berlin.de Sat Sep 4 19:15:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 19:15:52 -0700 (PDT) Received: from gnu.in-berlin.de (gnu.in-berlin.de [192.109.42.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i852FjMV001172 for ; Sat, 4 Sep 2004 19:15:46 -0700 X-Envelope-From: listmoved@calle.in-berlin.de X-Envelope-To: Received: from calle.in-berlin.de (calle.in-berlin.de [217.197.81.210]) by gnu.in-berlin.de (8.12.11/8.12.11/Debian-4) with ESMTP id i852FZlx011951 for ; Sun, 5 Sep 2004 04:15:35 +0200 Received: by calle.in-berlin.de (Smail3.2.0.115) id ; Sun, 5 Sep 2004 04:15:35 +0200 (CEST) Message-Id: Date: Sun, 5 Sep 2004 04:15:35 +0200 (CEST) To: netdev@oss.sgi.com From: calle@calle.in-berlin.de Subject: Re: Server Error (majordomo@calle.in-berlin.de) Precedence: bulk X-Scanned-By: MIMEDefang 2.43 X-archive-position: 8409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: calle@calle.in-berlin.de Precedence: bulk X-list: netdev Hallo. Die Mailingliste linux-avmb1@calle.in-berlin.de ist umgezogen, da sie durch Spams verseucht wurde. Siehe https://mlists.in-berlin.de/mailman/listinfo/linux-avmb1 The mailing list linux-avmb1@calle.in-berlin.de was been moved, we got too many spams. Visit https://mlists.in-berlin.de/mailman/listinfo/linux-avmb1 calle From mcgrof@studorgs.rutgers.edu Sat Sep 4 23:46:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 23:46:12 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i856k7J6008868 for ; Sat, 4 Sep 2004 23:46:07 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 505F6F99C1; Sun, 5 Sep 2004 02:45:58 -0400 (EDT) Date: Sun, 5 Sep 2004 02:45:58 -0400 To: Jeff Garzik Cc: prism54-devel@prism54.org, Netdev Subject: [PATCH 0/4] prism54: remove some module_params, WE17 and initial WPA work Message-ID: <20040905064558.GT31207@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , prism54-devel@prism54.org, Netdev Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 8410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Note: I'm resending these as Jeff's HD died ] Jeff, = =20 = =20 The following patches go ontop of Margit's recent patches which have not = =20 yet been integrated by you. These patches add remove some unncessary = =20 module_params, adds WE17 support and adds our initial WPA work -- = =20 striving to get prism54 wpa_supplicant to work with prism54. = =20 = =20 Please note that these patches are for *both* 2.6 and 2.4. = =20 = =20 Thanks, = =20 = =20 Luis=20 --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBOrYmat1JN+IKUl4RAprmAKCoB+ioyNxT3fGzKg+e5EWPCorzKwCeJC9C DHiJKtT7d+2+wU7JFuR9Jok= =yZXR -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- From mcgrof@studorgs.rutgers.edu Sat Sep 4 23:49:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 04 Sep 2004 23:49:48 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i856nhms009204 for ; Sat, 4 Sep 2004 23:49:43 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 73114F99C1; Sun, 5 Sep 2004 02:49:34 -0400 (EDT) Date: Sun, 5 Sep 2004 02:49:34 -0400 To: Jeff Garzik , prism54-devel@prism54.org, Netdev Subject: Re: [PATCH 0/4] prism54: remove some module_params, WE17 and initial WPA work Message-ID: <20040905064934.GV31207@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , prism54-devel@prism54.org, Netdev References: <20040905064558.GT31207@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040905064558.GT31207@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 8411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev nevermind, I'm going to coordinate with Margit so we send her and my patches together to make life easier for you. Luis On Sun, Sep 05, 2004 at 02:45:58AM -0400, Luis R. Rodriguez wrote: > > [ Note: I'm resending these as Jeff's HD died ] > > Jeff, > > The following patches go ontop of Margit's recent patches which have not > yet been integrated by you. These patches add remove some unncessary > module_params, adds WE17 support and adds our initial WPA work -- > striving to get prism54 wpa_supplicant to work with prism54. > > Please note that these patches are for *both* 2.6 and 2.4. > > Thanks, > > Luis > > -- > GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From margitsw@t-online.de Sun Sep 5 02:28:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 02:28:11 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i859S24b015399 for ; Sun, 5 Sep 2004 02:28:03 -0700 Received: from fwd05.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1C3tJ4-0004LB-02; Sun, 05 Sep 2004 11:27:30 +0200 Received: from roglap.local (ZwnRR8Z68eRo4AfVV-pfOw7R64FAxblgxc62jXHZyNUEFIjgZRTbZS@[217.224.19.205]) by fwd05.sul.t-online.com with esmtp id 1C3tIw-0qpJXE0; Sun, 5 Sep 2004 11:27:22 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH Linux-2.4.28-pre2] prism54 Update to 2.6 status Date: Sun, 5 Sep 2004 11:15:49 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org, marcelo.tosatti@cyclades.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_FltOBefVy+CGV5h" Message-Id: <200409051115.50083.margitsw@t-online.de> X-ID: ZwnRR8Z68eRo4AfVV-pfOw7R64FAxblgxc62jXHZyNUEFIjgZRTbZS X-TOI-MSGID: e065345e-8edf-45e4-9b72-74b221704805 X-archive-position: 8412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_FltOBefVy+CGV5h Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While * This rollup patch brings 2.4 into line with current * 2.6 status. * The code base is then IDENTICAL for both 2.4 and 2.6 with * the exception of an extra compatibility header for 2.4. * There is no point in doing a split out for this patch * as all changes have already been individually posted * against 2.6 and passed through Jeff. * As of now, we can post one patch for both kernels. * I have included Marcelo in the CC so that he is informed. * Jeff, after this patch, the upcoming resend of patches * apply equally to 2.4 and 2.6 unless explicitly stated. Margit --Boundary-00=_FltOBefVy+CGV5h Content-Type: text/x-diff; charset="us-ascii"; name="01_rollup.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="01_rollup.patch" diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/isl_38xx.c linux-2.4.28-pre2msw/drivers/net/wireless/prism54/isl_38xx.c --- linux-2.4.28-pre2/drivers/net/wireless/prism54/isl_38xx.c 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/isl_38xx.c 2004-09-05 10:36:25.000000000 +0200 @@ -18,8 +18,6 @@ * */ -#define __KERNEL_SYSCALLS__ - #include #include #include diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/isl_ioctl.c linux-2.4.28-pre2msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.4.28-pre2/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:36:25.000000000 +0200 @@ -436,7 +436,7 @@ { struct iw_range *range = (struct iw_range *) extra; islpci_private *priv = netdev_priv(ndev); - char *data; + u8 *data; int i, m, rvalue; struct obj_frequencies *freq; union oid_res_t r; @@ -513,8 +513,7 @@ i = 0; while ((i < IW_MAX_BITRATES) && (*data != 0)) { /* the result must be in bps. The card gives us 500Kbps */ - range->bitrate[i] = (__s32) (*data >> 1); - range->bitrate[i] *= 1000000; + range->bitrate[i] = *data * 500000; i++; data++; } @@ -820,9 +819,11 @@ return mgt_set_request(priv, DOT11_OID_PROFILES, 0, &profile); } - if ((ret = - mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r))) + ret = mgt_get_request(priv, DOT11_OID_SUPPORTEDRATES, 0, NULL, &r); + if (ret) { + kfree(r.ptr); return ret; + } rate = (u32) (vwrq->value / 500000); data = r.ptr; @@ -840,6 +841,7 @@ } if (!data[i]) { + kfree(r.ptr); return -EINVAL; } @@ -888,8 +890,11 @@ vwrq->value = r.u * 500000; /* request the device for the enabled rates */ - if ((rvalue = mgt_get_request(priv, DOT11_OID_RATES, 0, NULL, &r))) + rvalue = mgt_get_request(priv, DOT11_OID_RATES, 0, NULL, &r); + if (rvalue) { + kfree(r.ptr); return rvalue; + } data = r.ptr; vwrq->fixed = (data[0] != 0) && (data[1] == 0); kfree(r.ptr); @@ -1942,7 +1947,7 @@ { islpci_private *priv = netdev_priv(ndev); struct islpci_mgmtframe *response = NULL; - int ret = -EIO, response_op = PIMFOR_OP_ERROR; + int ret = -EIO; printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); data->length = 0; @@ -1952,9 +1957,7 @@ islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, priv->priv_oid, extra, 256, &response); - response_op = response->header->operation; printk("%s: ret: %i\n", ndev->name, ret); - printk("%s: response_op: %i\n", ndev->name, response_op); if (ret || !response || response->header->operation == PIMFOR_OP_ERROR) { if (response) { @@ -1991,16 +1994,20 @@ priv->priv_oid, extra, data->length, &response); printk("%s: ret: %i\n", ndev->name, ret); + if (ret || !response + || response->header->operation == PIMFOR_OP_ERROR) { + if (response) { + islpci_mgt_release(response); + } + printk("%s: EIO\n", ndev->name); + ret = -EIO; + } if (!ret) { response_op = response->header->operation; printk("%s: response_op: %i\n", ndev->name, response_op); islpci_mgt_release(response); } - if (ret || response_op == PIMFOR_OP_ERROR) { - printk("%s: EIO\n", ndev->name); - ret = -EIO; - } } return (ret ? ret : -EINPROGRESS); diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/islpci_dev.c linux-2.4.28-pre2msw/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.4.28-pre2/drivers/net/wireless/prism54/islpci_dev.c 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/islpci_dev.c 2004-09-05 10:36:25.000000000 +0200 @@ -39,6 +39,7 @@ #include "oid_mgt.h" #define ISL3877_IMAGE_FILE "isl3877" +#define ISL3886_IMAGE_FILE "isl3886" #define ISL3890_IMAGE_FILE "isl3890" static int prism54_bring_down(islpci_private *); @@ -82,7 +83,7 @@ mdelay(50); { - const struct firmware *fw_entry = 0; + const struct firmware *fw_entry = NULL; long fw_len; const u32 *fw_ptr; @@ -185,6 +186,9 @@ void *device = priv->device_base; int powerstate = ISL38XX_PSM_POWERSAVE_STATE; + /* lock the interrupt handler */ + spin_lock(&priv->slock); + /* received an interrupt request on a shared IRQ line * first check whether the device is in sleep mode */ reg = readl(device + ISL38XX_CTRL_STAT_REG); @@ -194,14 +198,10 @@ #if VERBOSE > SHOW_ERROR_MESSAGES DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); #endif + spin_unlock(&priv->slock); return IRQ_NONE; } - if (islpci_get_state(priv) != PRV_STATE_SLEEP) - powerstate = ISL38XX_PSM_ACTIVE_STATE; - - /* lock the interrupt handler */ - spin_lock(&priv->slock); /* check whether there is any source of interrupt on the device */ reg = readl(device + ISL38XX_INT_IDENT_REG); @@ -212,6 +212,9 @@ reg &= ISL38XX_INT_SOURCES; if (reg != 0) { + if (islpci_get_state(priv) != PRV_STATE_SLEEP) + powerstate = ISL38XX_PSM_ACTIVE_STATE; + /* reset the request bits in the Identification register */ isl38xx_w32_flush(device, reg, ISL38XX_INT_ACK_REG); @@ -339,6 +342,12 @@ isl38xx_handle_wakeup(priv->control_block, &powerstate, priv->device_base); } + } else { +#if VERBOSE > SHOW_ERROR_MESSAGES + DEBUG(SHOW_TRACING, "Assuming someone else called the IRQ\n"); +#endif + spin_unlock(&priv->slock); + return IRQ_NONE; } /* sleep -> ready */ @@ -716,7 +725,7 @@ if (priv->device_base) iounmap(priv->device_base); - priv->device_base = 0; + priv->device_base = NULL; /* free consistent DMA area... */ if (priv->driver_mem_address) @@ -725,10 +734,10 @@ priv->device_host_address); /* clear some dangling pointers */ - priv->driver_mem_address = 0; + priv->driver_mem_address = NULL; priv->device_host_address = 0; priv->device_psm_buffer = 0; - priv->control_block = 0; + priv->control_block = NULL; /* clean up mgmt rx buffers */ for (counter = 0; counter < ISL38XX_CB_MGMT_QSIZE; counter++) { @@ -754,7 +763,7 @@ if (priv->data_low_rx[counter]) dev_kfree_skb(priv->data_low_rx[counter]); - priv->data_low_rx[counter] = 0; + priv->data_low_rx[counter] = NULL; } /* Free the acces control list and the WPA list */ @@ -856,14 +865,14 @@ /* select the firmware file depending on the device id */ switch (pdev->device) { - case PCIDEVICE_ISL3890: - case PCIDEVICE_3COM6001: - strcpy(priv->firmware, ISL3890_IMAGE_FILE); - break; - case PCIDEVICE_ISL3877: + case 0x3877: strcpy(priv->firmware, ISL3877_IMAGE_FILE); break; + case 0x3886: + strcpy(priv->firmware, ISL3886_IMAGE_FILE); + break; + default: strcpy(priv->firmware, ISL3890_IMAGE_FILE); break; @@ -880,9 +889,9 @@ do_islpci_free_memory: islpci_free_memory(priv); do_free_netdev: - pci_set_drvdata(pdev, 0); + pci_set_drvdata(pdev, NULL); free_netdev(ndev); - priv = 0; + priv = NULL; return NULL; } diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/islpci_hotplug.c linux-2.4.28-pre2msw/drivers/net/wireless/prism54/islpci_hotplug.c --- linux-2.4.28-pre2/drivers/net/wireless/prism54/islpci_hotplug.c 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/islpci_hotplug.c 2004-09-05 10:36:25.000000000 +0200 @@ -44,102 +44,30 @@ * If you have an update for this please contact prism54-devel@prism54.org * The latest list can be found at http://prism54.org/supported_cards.php */ static const struct pci_device_id prism54_id_tbl[] = { - /* 3COM 3CRWE154G72 Wireless LAN adapter */ - { - PCIVENDOR_3COM, PCIDEVICE_3COM6001, - PCIVENDOR_3COM, PCIDEVICE_3COM6001, - 0, 0, 0 - }, - - /* D-Link Air Plus Xtreme G A1 - DWL-g650 A1 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_DLINK, 0x3202UL, - 0, 0, 0 - }, - - /* I-O Data WN-G54/CB - WN-G54/CB */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_IODATA, 0xd019UL, - 0, 0, 0 - }, - - /* Netgear WG511 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_NETGEAR, 0x4800UL, - 0, 0, 0 - }, - - /* Tekram Technology clones, Allnet, Netcomm, Zyxel */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_TTL, 0x1605UL, - 0, 0, 0 - }, - - /* SMC2802W */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0x2802UL, - 0, 0, 0 - }, - - /* SMC2835W */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0x2835UL, - 0, 0, 0 - }, - - /* Corega CG-WLCB54GT */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_ATI, 0xc104UL, - 0, 0, 0 - }, - - /* I4 Z-Com XG-600 */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0014UL, - 0, 0, 0 - }, - - /* I4 Z-Com XG-900 and clones Macer, Ovislink, Planex, Peabird, */ - /* Sitecom, Xterasys */ - { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_I4, 0x0020UL, - 0, 0, 0 - }, - - /* SMC 2802W V2 */ + /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_ACCTON, 0xee03UL, + 0x1260, 0x3890, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, - /* SMC 2835W V2 */ + /* 3COM 3CRWE154G72 Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, - PCIVENDOR_SMC, 0xa835UL, + 0x10b7, 0x6001, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, /* Intersil PRISM Indigo Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3877, + 0x1260, 0x3877, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, - /* Intersil PRISM Duette/Prism GT Wireless LAN adapter */ - /* Default */ + /* Intersil PRISM Javelin/Xbow Wireless LAN adapter */ { - PCIVENDOR_INTERSIL, PCIDEVICE_ISL3890, + 0x1260, 0x3886, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, @@ -166,85 +94,6 @@ /* .enable_wake ; we don't support this yet */ }; -static void -prism54_get_card_model(struct net_device *ndev) -{ - islpci_private *priv; - char *modelp; - int notwork = 0; - - priv = netdev_priv(ndev); - switch (priv->pdev->subsystem_device) { - case PCIDEVICE_ISL3877: - modelp = "PRISM Indigo"; - break; - case PCIDEVICE_ISL3886: - modelp = "PRISM Javelin / Xbow"; - break; - case PCIDEVICE_3COM6001: - modelp = "3COM 3CRWE154G72"; - break; - case 0x3202UL: - modelp = "D-Link DWL-g650 A1"; - break; - case 0xd019UL: - modelp = "WN-G54/CB"; - break; - case 0x4800UL: - modelp = "Netgear WG511"; - break; - case 0x2802UL: - modelp = "SMC2802W"; - break; - case 0xee03UL: - modelp = "SMC2802W V2"; - notwork = 1; - break; - case 0x2835UL: - modelp = "SMC2835W"; - break; - case 0xa835UL: - modelp = "SMC2835W V2"; - notwork = 1; - break; - case 0xc104UL: - modelp = "CG-WLCB54GT"; - break; - case 0x1605UL: - modelp = "Tekram Technology clone"; - break; - /* Let's leave this one out for now since it seems bogus/wrong - * Even if the manufacturer did use 0x0000UL it may not be correct - * by their part, therefore deserving no name ;) */ - /* case 0x0000UL: - * modelp = "SparkLAN WL-850F"; - * break;*/ - - /* We have two reported for the one below :( */ - case 0x0014UL: - modelp = "I4 Z-Com XG-600 and clones"; - break; - case 0x0020UL: - modelp = "I4 Z-Com XG-900 and clones"; - break; -/* Default it */ -/* - case PCIDEVICE_ISL3890: - modelp = "PRISM Duette/GT"; - break; -*/ - default: - modelp = "PRISM Duette/GT"; - } - printk(KERN_DEBUG "%s: %s driver detected card model: %s\n", - ndev->name, DRV_NAME, modelp); - if ( notwork ) { - printk(KERN_DEBUG "%s: %s Warning - This may not work\n", - ndev->name, DRV_NAME); - } - return; -} - /****************************************************************************** Module initialization functions ******************************************************************************/ @@ -354,17 +203,14 @@ /* firmware upload is triggered in islpci_open */ - /* Pretty card model discovery output */ - prism54_get_card_model(ndev); - return 0; do_unregister_netdev: unregister_netdev(ndev); islpci_free_memory(priv); - pci_set_drvdata(pdev, 0); + pci_set_drvdata(pdev, NULL); free_netdev(ndev); - priv = 0; + priv = NULL; do_pci_release_regions: pci_release_regions(pdev); do_pci_disable_device: @@ -380,7 +226,7 @@ prism54_remove(struct pci_dev *pdev) { struct net_device *ndev = pci_get_drvdata(pdev); - islpci_private *priv = ndev ? netdev_priv(ndev) : 0; + islpci_private *priv = ndev ? netdev_priv(ndev) : NULL; BUG_ON(!priv); if (!__in_cleanup_module) { @@ -408,9 +254,9 @@ /* free the PCI memory and unmap the remapped page */ islpci_free_memory(priv); - pci_set_drvdata(pdev, 0); + pci_set_drvdata(pdev, NULL); free_netdev(ndev); - priv = 0; + priv = NULL; pci_release_regions(pdev); @@ -421,7 +267,7 @@ prism54_suspend(struct pci_dev *pdev, u32 state) { struct net_device *ndev = pci_get_drvdata(pdev); - islpci_private *priv = ndev ? netdev_priv(ndev) : 0; + islpci_private *priv = ndev ? netdev_priv(ndev) : NULL; BUG_ON(!priv); printk(KERN_NOTICE "%s: got suspend request (state %d)\n", @@ -446,7 +292,7 @@ prism54_resume(struct pci_dev *pdev) { struct net_device *ndev = pci_get_drvdata(pdev); - islpci_private *priv = ndev ? netdev_priv(ndev) : 0; + islpci_private *priv = ndev ? netdev_priv(ndev) : NULL; BUG_ON(!priv); printk(KERN_NOTICE "%s: got resume request\n", ndev->name); diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/islpci_mgt.h linux-2.4.28-pre2msw/drivers/net/wireless/prism54/islpci_mgt.h --- linux-2.4.28-pre2/drivers/net/wireless/prism54/islpci_mgt.h 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/islpci_mgt.h 2004-09-05 10:36:25.000000000 +0200 @@ -38,21 +38,6 @@ /* General driver definitions */ -#define PCIVENDOR_INTERSIL 0x1260UL -#define PCIVENDOR_3COM 0x10b7UL -#define PCIVENDOR_DLINK 0x1186UL -#define PCIVENDOR_I4 0x17cfUL -#define PCIVENDOR_IODATA 0x10fcUL -#define PCIVENDOR_NETGEAR 0x1385UL -#define PCIVENDOR_SMC 0x10b8UL -#define PCIVENDOR_ACCTON 0x1113UL -#define PCIVENDOR_ATI 0x1259UL -#define PCIVENDOR_TTL 0x16a5UL - -#define PCIDEVICE_ISL3877 0x3877UL -#define PCIDEVICE_ISL3886 0x3886UL -#define PCIDEVICE_ISL3890 0x3890UL -#define PCIDEVICE_3COM6001 0x6001UL #define PCIDEVICE_LATENCY_TIMER_MIN 0x40 #define PCIDEVICE_LATENCY_TIMER_VAL 0x50 diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/oid_mgt.c linux-2.4.28-pre2msw/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.4.28-pre2/drivers/net/wireless/prism54/oid_mgt.c 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/oid_mgt.c 2004-09-05 10:36:25.000000000 +0200 @@ -219,7 +219,7 @@ OID_UNKNOWN(OID_INL_MEMORY, 0xFF020002), OID_U32_C(OID_INL_MODE, 0xFF020003), OID_UNKNOWN(OID_INL_COMPONENT_NR, 0xFF020004), - OID_UNKNOWN(OID_INL_VERSION, 0xFF020005), + OID_STRUCT(OID_INL_VERSION, 0xFF020005, u8[8], OID_TYPE_RAW), OID_UNKNOWN(OID_INL_INTERFACE_ID, 0xFF020006), OID_UNKNOWN(OID_INL_COMPONENT_ID, 0xFF020007), OID_U32_C(OID_INL_CONFIG, 0xFF020008), @@ -481,6 +481,8 @@ BUG_ON(OID_NUM_LAST <= n); BUG_ON(extra > isl_oid[n].range); + res->ptr = NULL; + if (!priv->mib) /* memory has been freed */ return -1; @@ -613,7 +615,9 @@ DOT11_OID_DEFKEYID, DOT11_OID_DOT1XENABLE, OID_INL_DOT11D_CONFORMANCE, + /* Do not initialize this - fw < 1.0.4.3 rejects it OID_INL_OUTPUTPOWER, + */ }; /* update the MAC addr. */ diff -Naur linux-2.4.28-pre2/drivers/net/wireless/prism54/prismcompat24.h linux-2.4.28-pre2msw/drivers/net/wireless/prism54/prismcompat24.h --- linux-2.4.28-pre2/drivers/net/wireless/prism54/prismcompat24.h 2004-09-05 10:08:56.000000000 +0200 +++ linux-2.4.28-pre2msw/drivers/net/wireless/prism54/prismcompat24.h 2004-09-05 10:36:55.000000000 +0200 @@ -52,7 +52,7 @@ #define schedule_work schedule_task #if !defined(HAVE_NETDEV_PRIV) -#define netdev_priv(x) x->priv +#define netdev_priv(x) (x)->priv #endif #if !defined(CONFIG_FW_LOADER) && !defined(CONFIG_FW_LOADER_MODULE) --Boundary-00=_FltOBefVy+CGV5h-- From zdzichu@irc.pl Sun Sep 5 02:53:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 02:53:35 -0700 (PDT) Received: from mother.localdomain (serwer.tvgawex.pl [212.122.214.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i859rS3Y017784 for ; Sun, 5 Sep 2004 02:53:29 -0700 Received: (qmail 22454 invoked by uid 1000); 5 Sep 2004 09:46:36 -0000 Date: Sun, 5 Sep 2004 11:46:36 +0200 From: Tomasz Torcz To: netdev@oss.sgi.com Subject: Improvements in FreeBSD 5.3 networking Message-ID: <20040905094636.GA10086@irc.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 8413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdzichu@irc.pl Precedence: bulk X-list: netdev Hi, reading Slashdot I'm sutmbled upon presentation of FreeBSD new features: http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf It look pretty interesting (e.g. tcphostcache), especially they claim that FreeBSD on 2.8 GHz Xeon can route 1Mpps. Original slashodt story: http://bsd.slashdot.org/article.pl?sid=04/09/04/133253 -- Tomasz Torcz Morality must always be based on practicality. zdzichu@irc.-nie.spam-.pl -- Baron Vladimir Harkonnen From margitsw@t-online.de Sun Sep 5 03:10:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:10:51 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85AAjtP018366 for ; Sun, 5 Sep 2004 03:10:46 -0700 Received: from fwd08.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1C3tyk-0006cQ-02; Sun, 05 Sep 2004 12:10:34 +0200 Received: from roglap.local (Z4iPzrZSQeHK3nA2mEOEbmeO6F6DnZim6TtDvGVX5o0j2ba6zholQg@[217.224.19.205]) by fwd08.sul.t-online.com with esmtp id 1C3tyj-14ymbA0; Sun, 5 Sep 2004 12:10:33 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 0/6 linux-2.6.9-rc1/linux-2.4.28-pre2] prism54 patches resend Date: Sun, 5 Sep 2004 11:58:59 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409051158.59976.margitsw@t-online.de> X-ID: Z4iPzrZSQeHK3nA2mEOEbmeO6F6DnZim6TtDvGVX5o0j2ba6zholQg X-TOI-MSGID: 34695457-a5df-400d-82d6-203e26ddb276 X-archive-position: 8414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev 2004-09-05 Margit Schubert-While * Resend of patches as follows : * 01_frequency.patch * Fix frequency reporting * 02_codeclean.patch * Code clean up * 03_remove_modparms.patch * Remove unneeded module params * 04_handle_we17.patch * Handle WE17 extensions * 05_start_wpa.patch * Initial WPA work * 06_fix_freqparse.patch * Fix frequency parsing * After the 2.4.28 rollup patch, this applies to both 2.4 and 2.6. Margit From margitsw@t-online.de Sun Sep 5 03:13:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:13:33 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85ADSbw018679 for ; Sun, 5 Sep 2004 03:13:28 -0700 Received: from fwd02.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1C3u1N-0004eY-01; Sun, 05 Sep 2004 12:13:17 +0200 Received: from roglap.local (X7k0eqZVYeTQjcbUPUkjpDJPzedXj3J5n---3hj2aCXrzcBpZJ32Ud@[217.224.19.205]) by fwd02.sul.t-online.com with esmtp id 1C3u1M-06zvAu0; Sun, 5 Sep 2004 12:13:16 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 1/6 linux-2.6.9-rc1/2.4.28-pre2] prism54 Bug - Fix frequency reporting Date: Sun, 5 Sep 2004 12:01:43 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_HQuOB3p1Mjavrdt" Message-Id: <200409051201.43676.margitsw@t-online.de> X-ID: X7k0eqZVYeTQjcbUPUkjpDJPzedXj3J5n---3hj2aCXrzcBpZJ32Ud X-TOI-MSGID: f59740aa-d3e4-4063-bbd2-b706c8994501 X-archive-position: 8415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_HQuOB3p1Mjavrdt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While * prism54_get_freq is incorrectly returning channel * and not frequency. Wireless tools detect this, but * other programs do not, leading to insane reported * values. (As Jean documents, drivers should really be * reporting the frequency). * An example is wavemon. Margit --Boundary-00=_HQuOB3p1Mjavrdt Content-Type: text/x-diff; charset="us-ascii"; name="01_frequency.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="01_frequency.patch" diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c 2004-08-14 07:36:44.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:16:55.000000000 +0200 @@ -334,9 +334,10 @@ int rvalue; rvalue = mgt_get_request(priv, DOT11_OID_CHANNEL, 0, NULL, &r); - + fwrq->i = r.u; + rvalue |= mgt_get_request(priv, DOT11_OID_FREQUENCY, 0, NULL, &r); fwrq->m = r.u; - fwrq->e = 0; + fwrq->e = 3; return rvalue; } --Boundary-00=_HQuOB3p1Mjavrdt-- From margitsw@t-online.de Sun Sep 5 03:18:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:18:45 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85AIcU8019061 for ; Sun, 5 Sep 2004 03:18:39 -0700 Received: from fwd09.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1C3u5z-0007H1-01; Sun, 05 Sep 2004 12:18:03 +0200 Received: from roglap.local (SgCav+Z68eNk54ssHAOzKTfoEV+ZEXjIvRR12CKIOzYzKeloIs5Fw3@[217.224.19.205]) by fwd09.sul.t-online.com with esmtp id 1C3u5m-1hKpY80; Sun, 5 Sep 2004 12:17:50 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 2/6 linux-2.6.9-rc1/2.4.28-pre2] prism54 Code cleanup Date: Sun, 5 Sep 2004 12:06:17 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ZUuOBkgLRqNii/g" Message-Id: <200409051206.17586.margitsw@t-online.de> X-ID: SgCav+Z68eNk54ssHAOzKTfoEV+ZEXjIvRR12CKIOzYzKeloIs5Fw3 X-TOI-MSGID: f7b73a37-c6b4-47fe-86e0-40bcffd21008 X-archive-position: 8416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_ZUuOBkgLRqNii/g Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While (Patches submitted by Denis Vlasenko) There are neither functionality changes nor bug fixes. * 2004-08-14 Denis Vlasenko * Move assignment out of if() * Remove trailing space from printk * Eliminate not needed local 'u32 reg' * Add a comment about undoc bits * Add #define VEC_SIZE, use it as appropriate * Add some printks to reset error code path (our * current area of trouble) * Make printk text less confusing * Some not needed NULL assignments removed * mgt_commit_list(): tell which oid has failed Margit --Boundary-00=_ZUuOBkgLRqNii/g Content-Type: text/x-diff; charset="us-ascii"; name="02_codeclean.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="02_codeclean.patch" diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_38xx.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_38xx.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_38xx.c 2004-08-14 07:36:58.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_38xx.c 2004-09-05 10:41:07.000000000 +0200 @@ -133,8 +133,8 @@ readl(device_base + ISL38XX_CTRL_STAT_REG)); udelay(ISL38XX_WRITEIO_DELAY); - if (reg = readl(device_base + ISL38XX_INT_IDENT_REG), - reg == 0xabadface) { + reg = readl(device_base + ISL38XX_INT_IDENT_REG); + if (reg == 0xabadface) { #if VERBOSE > SHOW_ERROR_MESSAGES do_gettimeofday(¤t_time); DEBUG(SHOW_TRACING, @@ -192,10 +192,8 @@ void isl38xx_interface_reset(void *device_base, dma_addr_t host_address) { - u32 reg; - #if VERBOSE > SHOW_ERROR_MESSAGES - DEBUG(SHOW_FUNCTION_CALLS, "isl38xx_interface_reset \n"); + DEBUG(SHOW_FUNCTION_CALLS, "isl38xx_interface_reset\n"); #endif /* load the address of the control block in the device */ @@ -203,8 +201,7 @@ udelay(ISL38XX_WRITEIO_DELAY); /* set the reset bit in the Device Interrupt Register */ - isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_RESET, - ISL38XX_DEV_INT_REG); + isl38xx_w32_flush(device_base, ISL38XX_DEV_INT_RESET, ISL38XX_DEV_INT_REG); udelay(ISL38XX_WRITEIO_DELAY); /* enable the interrupt for detecting initialization */ @@ -212,9 +209,7 @@ /* Note: Do not enable other interrupts here. We want the * device to have come up first 100% before allowing any other * interrupts. */ - reg = ISL38XX_INT_IDENT_INIT; - - isl38xx_w32_flush(device_base, reg, ISL38XX_INT_EN_REG); + isl38xx_w32_flush(device_base, ISL38XX_INT_IDENT_INIT, ISL38XX_INT_EN_REG); udelay(ISL38XX_WRITEIO_DELAY); /* allow complete full reset */ } diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_38xx.h linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_38xx.h --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_38xx.h 2004-08-14 07:38:11.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_38xx.h 2004-09-05 10:41:07.000000000 +0200 @@ -95,6 +95,10 @@ #define ISL38XX_INT_SOURCES 0x001E /* Control/Status register bits */ +/* Looks like there are other meaningful bits + 0x20004400 seen in normal operation, + 0x200044db at 'timeout waiting for mgmt response' +*/ #define ISL38XX_CTRL_STAT_SLEEPMODE 0x00000200 #define ISL38XX_CTRL_STAT_CLKRUN 0x00800000 #define ISL38XX_CTRL_STAT_RESET 0x10000000 diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:39:09.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:41:07.000000000 +0200 @@ -1947,7 +1947,7 @@ struct iw_point *data, char *extra) { islpci_private *priv = netdev_priv(ndev); - struct islpci_mgmtframe *response = NULL; + struct islpci_mgmtframe *response; int ret = -EIO; printk("%s: get_oid 0x%08X\n", ndev->name, priv->priv_oid); @@ -1983,7 +1983,7 @@ struct iw_point *data, char *extra) { islpci_private *priv = netdev_priv(ndev); - struct islpci_mgmtframe *response = NULL; + struct islpci_mgmtframe *response; int ret = 0, response_op = PIMFOR_OP_ERROR; printk("%s: set_oid 0x%08X\tlen: %d\n", ndev->name, priv->priv_oid, diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_dev.c 2004-08-14 07:36:11.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_dev.c 2004-09-05 10:41:07.000000000 +0200 @@ -375,8 +375,6 @@ u32 rc; islpci_private *priv = netdev_priv(ndev); - printk(KERN_DEBUG "%s: islpci_open()\n", ndev->name); - /* reset data structures, upload firmware and reset device */ rc = islpci_reset(priv,1); if (rc) { @@ -462,8 +460,7 @@ return rc; } - printk(KERN_DEBUG - "%s: firmware uploaded done, now triggering reset...\n", + printk(KERN_DEBUG "%s: firmware upload complete\n", priv->ndev->name); islpci_set_state(priv, PRV_STATE_POSTBOOT); @@ -499,15 +496,16 @@ /* If we're here it's because our IRQ hasn't yet gone through. * Retry a bit more... */ - printk(KERN_ERR "%s: device soft reset timed out\n", - priv->ndev->name); - + printk(KERN_ERR "%s: reset problem: no 'reset complete' IRQ seen\n", + priv->ndev->name); } finish_wait(&priv->reset_done, &wait); - if(result) + if (result) { + printk(KERN_ERR "%s: islpci_reset_if: failure\n", priv->ndev->name); return result; + } islpci_set_state(priv, PRV_STATE_INIT); @@ -524,6 +522,7 @@ islpci_set_state(priv, PRV_STATE_READY); + printk(KERN_DEBUG "%s: interface reset complete\n", priv->ndev->name); return 0; } @@ -584,18 +583,18 @@ /* now that the data structures are cleaned up, upload * firmware and reset interface */ rc = islpci_upload_fw(priv); - if (rc) + if (rc) { + printk(KERN_ERR "%s: islpci_reset: failure\n", + priv->ndev->name); return rc; + } } /* finally reset interface */ rc = islpci_reset_if(priv); - if (!rc) /* If successful */ - return rc; - - printk(KERN_DEBUG "prism54: Your card/socket may be faulty, or IRQ line too busy :(\n"); + if (rc) + printk(KERN_ERR "prism54: Your card/socket may be faulty, or IRQ line too busy :(\n"); return rc; - } struct net_device_stats * @@ -604,7 +603,7 @@ islpci_private *priv = netdev_priv(ndev); #if VERBOSE > SHOW_ERROR_MESSAGES - DEBUG(SHOW_FUNCTION_CALLS, "islpci_statistics \n"); + DEBUG(SHOW_FUNCTION_CALLS, "islpci_statistics\n"); #endif return &priv->statistics; diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_eth.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_eth.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_eth.c 2004-08-14 07:36:14.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_eth.c 2004-09-05 10:41:07.000000000 +0200 @@ -508,11 +508,12 @@ /* increment the transmit error counter */ statistics->tx_errors++; + printk(KERN_WARNING "%s: tx_timeout", ndev->name); if (!priv->reset_task_pending) { priv->reset_task_pending = 1; + printk(", scheduling a reset"); netif_stop_queue(ndev); schedule_work(&priv->reset_task); } - - return; + printk("\n"); } diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/oid_mgt.c 2004-08-14 07:38:04.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/oid_mgt.c 2004-09-05 10:41:07.000000000 +0200 @@ -555,15 +555,18 @@ u32 oid = t->oid; BUG_ON(data == NULL); while (j <= t->range) { - response = NULL; - ret |= islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, + int r = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, oid, data, t->size, &response); if (response) { - ret |= (response->header->operation == - PIMFOR_OP_ERROR); + r |= (response->header->operation == PIMFOR_OP_ERROR); islpci_mgt_release(response); } + if (r) + printk(KERN_ERR "%s: mgt_commit_list: failure. " + "oid=%08x err=%d\n", + priv->ndev->name, oid, r); + ret |= r; j++; oid++; data += t->size; @@ -624,7 +627,7 @@ static int mgt_update_addr(islpci_private *priv) { - struct islpci_mgmtframe *res = NULL; + struct islpci_mgmtframe *res; int ret; ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_GET, @@ -638,9 +641,13 @@ if (res) islpci_mgt_release(res); + if (ret) + printk(KERN_ERR "%s: mgt_update_addr: failure\n", priv->ndev->name); return ret; } +#define VEC_SIZE(a) (sizeof(a)/sizeof(a[0])) + void mgt_commit(islpci_private *priv) { @@ -650,14 +657,10 @@ if (islpci_get_state(priv) < PRV_STATE_INIT) return; - rvalue = mgt_commit_list(priv, commit_part1, - sizeof (commit_part1) / - sizeof (commit_part1[0])); + rvalue = mgt_commit_list(priv, commit_part1, VEC_SIZE(commit_part1)); if (priv->iw_mode != IW_MODE_MONITOR) - rvalue |= mgt_commit_list(priv, commit_part2, - sizeof (commit_part2) / - sizeof (commit_part2[0])); + rvalue |= mgt_commit_list(priv, commit_part2, VEC_SIZE(commit_part2)); u = OID_INL_MODE; rvalue |= mgt_commit_list(priv, &u, 1); @@ -666,8 +669,7 @@ if (rvalue) { /* some request have failed. The device might be in an incoherent state. We should reset it ! */ - printk(KERN_DEBUG "%s: mgt_commit has failed. Restart the " - "device \n", priv->ndev->name); + printk(KERN_DEBUG "%s: mgt_commit: failure\n", priv->ndev->name); } } --Boundary-00=_ZUuOBkgLRqNii/g-- From margitsw@t-online.de Sun Sep 5 03:24:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:24:40 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85AOZqP019418 for ; Sun, 5 Sep 2004 03:24:35 -0700 Received: from fwd07.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1C3uBo-0005EG-03; Sun, 05 Sep 2004 12:24:04 +0200 Received: from roglap.local (Z62NCBZ-YeBMptqq76hoeXXDLHfTPmTnsbnxFciOMtFTK14FljJtgW@[217.224.19.205]) by fwd07.sul.t-online.com with esmtp id 1C3uBl-06ZWTo0; Sun, 5 Sep 2004 12:24:01 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 3/6 linux-2.6.9-rc1/2.4.28-pre2] prism54 remove module params Date: Sun, 5 Sep 2004 12:12:28 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_MauOBTDXmybLGKK" Message-Id: <200409051212.28081.margitsw@t-online.de> X-ID: Z62NCBZ-YeBMptqq76hoeXXDLHfTPmTnsbnxFciOMtFTK14FljJtgW X-TOI-MSGID: 59e3e93a-549b-41cb-8710-5cb397a8c1b4 X-archive-position: 8417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_MauOBTDXmybLGKK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While 2004-08-18 Luis R. Rodriguez * Remove unneeded module params. Margit --Boundary-00=_MauOBTDXmybLGKK Content-Type: text/x-diff; charset="us-ascii"; name="03_remove_modparms.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="03_remove_modparms.patch" diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:44:54.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:45:27.000000000 +0200 @@ -36,38 +36,6 @@ #include /* New driver API */ -static int init_mode = CARD_DEFAULT_IW_MODE; -static int init_channel = CARD_DEFAULT_CHANNEL; -static int init_wep = CARD_DEFAULT_WEP; -static int init_filter = CARD_DEFAULT_FILTER; -static int init_authen = CARD_DEFAULT_AUTHEN; -static int init_dot1x = CARD_DEFAULT_DOT1X; -static int init_conformance = CARD_DEFAULT_CONFORMANCE; -static int init_mlme = CARD_DEFAULT_MLME_MODE; - -module_param(init_mode, int, 0); -MODULE_PARM_DESC(init_mode, - "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor"); - -module_param(init_channel, int, 0); -MODULE_PARM_DESC(init_channel, - "Check `iwpriv ethx channel` for available channels"); - -module_param(init_wep, int, 0); -module_param(init_filter, int, 0); - -module_param(init_authen, int, 0); -MODULE_PARM_DESC(init_authen, - "Authentication method. Can be of seven types:\n0 0x0000: None\n1 0x0001: DOT11_AUTH_OS (Default)\n2 0x0002: DOT11_AUTH_SK\n3 0x0003: DOT11_AUTH_BOTH"); - -module_param(init_dot1x, int, 0); -MODULE_PARM_DESC(init_dot1x, - "\n0: None/not set (Default)\n1: DOT11_DOT1X_AUTHENABLED\n2: DOT11_DOT1X_KEYTXENABLED"); - -module_param(init_mlme, int, 0); -MODULE_PARM_DESC(init_mlme, - "Sets the MAC layer management entity (MLME) mode of operation,\n0: DOT11_MLME_AUTO (Default)\n1: DOT11_MLME_INTERMEDIATE\n2: DOT11_MLME_EXTENDED"); - /** * prism54_mib_mode_helper - MIB change mode helper function * @mib: the &struct islpci_mib object to modify @@ -141,36 +109,34 @@ void prism54_mib_init(islpci_private *priv) { - u32 t; + u32 channel, authen, wep, filter, dot1x, mlme, conformance, power, mode; struct obj_buffer psm_buffer = { .size = PSM_BUFFER_SIZE, .addr = priv->device_psm_buffer }; - mgt_set(priv, DOT11_OID_CHANNEL, &init_channel); - mgt_set(priv, DOT11_OID_AUTHENABLE, &init_authen); - mgt_set(priv, DOT11_OID_PRIVACYINVOKED, &init_wep); - + channel = CARD_DEFAULT_CHANNEL; + authen = CARD_DEFAULT_AUTHEN; + wep = CARD_DEFAULT_WEP; + filter = CARD_DEFAULT_FILTER; /* (0) Do not filter un-encrypted data */ + dot1x = CARD_DEFAULT_DOT1X; + mlme = CARD_DEFAULT_MLME_MODE; + conformance = CARD_DEFAULT_CONFORMANCE; + power = 127; + mode = CARD_DEFAULT_IW_MODE; + + mgt_set(priv, DOT11_OID_CHANNEL, &channel); + mgt_set(priv, DOT11_OID_AUTHENABLE, &authen); + mgt_set(priv, DOT11_OID_PRIVACYINVOKED, &wep); mgt_set(priv, DOT11_OID_PSMBUFFER, &psm_buffer); - mgt_set(priv, DOT11_OID_EXUNENCRYPTED, &init_filter); - mgt_set(priv, DOT11_OID_DOT1XENABLE, &init_dot1x); - mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &init_mlme); - mgt_set(priv, OID_INL_DOT11D_CONFORMANCE, &init_conformance); - - t = 127; - mgt_set(priv, OID_INL_OUTPUTPOWER, &t); - - /* Important: we are setting a default wireless mode and we are - * forcing a valid one, so prism54_mib_mode_helper should just set - * mib values depending on what the wireless mode given is. No need - * for it save old values */ - if (init_mode > IW_MODE_MONITOR || init_mode < IW_MODE_AUTO) { - printk(KERN_DEBUG "%s(): You passed a non-valid init_mode. " - "Using default mode\n", __FUNCTION__); - init_mode = CARD_DEFAULT_IW_MODE; - } + mgt_set(priv, DOT11_OID_EXUNENCRYPTED, &filter); + mgt_set(priv, DOT11_OID_DOT1XENABLE, &dot1x); + mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &mlme); + mgt_set(priv, OID_INL_DOT11D_CONFORMANCE, &conformance); + mgt_set(priv, OID_INL_OUTPUTPOWER, &power); + /* This sets all of the mode-dependent values */ - prism54_mib_mode_helper(priv, init_mode); + prism54_mib_mode_helper(priv, mode); } /* this will be executed outside of atomic context thanks to --Boundary-00=_MauOBTDXmybLGKK-- From margitsw@t-online.de Sun Sep 5 03:30:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:30:43 -0700 (PDT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85AUaQm019825 for ; Sun, 5 Sep 2004 03:30:37 -0700 Received: from fwd01.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1C3uHd-0008De-04; Sun, 05 Sep 2004 12:30:05 +0200 Received: from roglap.local (E1vS+gZpQeR2fTuStRecyuTIyhPusaGaaSBQO-DNq18oh8FczBkEY5@[217.224.19.205]) by fwd01.sul.t-online.com with esmtp id 1C3uHa-1GyKqO0; Sun, 5 Sep 2004 12:30:02 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 4/6 linux-2.6.9-rc1/2.4.28-pre2] prism54 add WE17 support Date: Sun, 5 Sep 2004 12:18:28 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_0fuOBMb4BojZJud" Message-Id: <200409051218.28597.margitsw@t-online.de> X-ID: E1vS+gZpQeR2fTuStRecyuTIyhPusaGaaSBQO-DNq18oh8FczBkEY5 X-TOI-MSGID: 59bffabe-404c-443e-933d-c999c4290065 X-archive-position: 8418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_0fuOBMb4BojZJud Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While 2004-08-18 Luis R. Rodriguez * Add support for WE17 from Jean Tourrilhes Margit --Boundary-00=_0fuOBMb4BojZJud Content-Type: text/x-diff; charset="us-ascii"; name="04_handle_we17.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="04_handle_we17.patch" diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:46:50.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:47:13.000000000 +0200 @@ -451,6 +451,15 @@ /* txpower is supported in dBm's */ range->txpower_capa = IW_TXPOW_DBM; +#if WIRELESS_EXT > 16 + /* Event capability (kernel + driver) */ + range->event_capa[0] = (IW_EVENT_CAPA_K_0 | + IW_EVENT_CAPA_MASK(SIOCGIWTHRSPY) | + IW_EVENT_CAPA_MASK(SIOCGIWAP)); + range->event_capa[1] = IW_EVENT_CAPA_K_1; + range->event_capa[4] = IW_EVENT_CAPA_MASK(IWEVCUSTOM); +#endif /* WIRELESS_EXT > 16 */ + if (islpci_get_state(priv) < PRV_STATE_INIT) return 0; @@ -656,19 +665,33 @@ rvalue = mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); noise = r.u; - /* Ask the device for a list of known bss. We can report at most - * IW_MAX_AP=64 to the range struct. But the device won't repport anything - * if you change the value of IWMAX_BSS=24. - */ + /* Ask the device for a list of known bss. + * The old API, using SIOCGIWAPLIST, had a hard limit of IW_MAX_AP=64. + * The new API, using SIOCGIWSCAN, is only limited by the buffer size. + * WE-14->WE-16, the buffer is limited to IW_SCAN_MAX_DATA bytes. + * Starting with WE-17, the buffer can be as big as needed. + * But the device won't repport anything if you change the value + * of IWMAX_BSS=24. */ + rvalue |= mgt_get_request(priv, DOT11_OID_BSSLIST, 0, NULL, &r); bsslist = r.ptr; /* ok now, scan the list and translate its info */ - for (i = 0; i < min(IW_MAX_AP, (int) bsslist->nr); i++) + for (i = 0; i < (int) bsslist->nr; i++) { current_ev = prism54_translate_bss(ndev, current_ev, - extra + IW_SCAN_MAX_DATA, + extra + dwrq->length, &(bsslist->bsslist[i]), noise); +#if WIRELESS_EXT > 16 + /* Check if there is space for one more entry */ + if((extra + dwrq->length - current_ev) <= IW_EV_ADDR_LEN) { + /* Ask user space to try again with a bigger buffer */ + rvalue = -E2BIG; + break; + } +#endif /* WIRELESS_EXT > 16 */ + } + kfree(bsslist); dwrq->length = (current_ev - extra); dwrq->flags = 0; /* todo */ @@ -2222,7 +2245,9 @@ .standard = (iw_handler *) prism54_handler, .private = (iw_handler *) prism54_private_handler, .private_args = (struct iw_priv_args *) prism54_private_args, +#if WIRELESS_EXT == 16 .spy_offset = offsetof(islpci_private, spy_data), +#endif /* WIRELESS_EXT == 16 */ }; /* For ioctls that don't work with the new API */ diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_dev.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_dev.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_dev.c 2004-09-05 10:44:54.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_dev.c 2004-09-05 10:47:13.000000000 +0200 @@ -829,6 +829,12 @@ priv->ndev->type = (priv->iw_mode == IW_MODE_MONITOR) ? priv->monitor_type : ARPHRD_ETHER; +#if WIRELESS_EXT > 16 + /* Add pointers to enable iwspy support. */ + priv->wireless_data.spy_data = &priv->spy_data; + ndev->wireless_data = &priv->wireless_data; +#endif /* WIRELESS_EXT > 16 */ + /* save the start and end address of the PCI memory area */ ndev->mem_start = (unsigned long) priv->device_base; ndev->mem_end = ndev->mem_start + ISL38XX_PCI_MEM_SIZE; diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_dev.h linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_dev.h --- linux-2.6.9rc1/drivers/net/wireless/prism54/islpci_dev.h 2004-08-14 07:36:56.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/islpci_dev.h 2004-09-05 10:47:13.000000000 +0200 @@ -100,6 +100,10 @@ struct iw_spy_data spy_data; /* iwspy support */ +#if WIRELESS_EXT > 16 + struct iw_public_data wireless_data; +#endif /* WIRELESS_EXT > 16 */ + int monitor_type; /* ARPHRD_IEEE80211 or ARPHRD_IEEE80211_PRISM */ struct islpci_acl acl; --Boundary-00=_0fuOBMb4BojZJud-- From margitsw@t-online.de Sun Sep 5 03:44:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:44:50 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85Aiggd020364 for ; Sun, 5 Sep 2004 03:44:43 -0700 Received: from fwd10.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1C3uVI-0001oZ-00; Sun, 05 Sep 2004 12:44:12 +0200 Received: from roglap.local (bLP3BgZAQelsixkqQpxiwtFJhKW4nqAz9RAU0Ur8S8O1yxjsTCOFEz@[217.224.19.205]) by fwd10.sul.t-online.com with esmtp id 1C3uV8-2JwpKy0; Sun, 5 Sep 2004 12:44:02 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 5/6 linux-2.6.9-rc1/2.4.28-pre2] prism54 initial WPA support Date: Sun, 5 Sep 2004 12:32:29 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_9suOBTiZpSr4nE3" Message-Id: <200409051232.29014.margitsw@t-online.de> X-ID: bLP3BgZAQelsixkqQpxiwtFJhKW4nqAz9RAU0Ur8S8O1yxjsTCOFEz X-TOI-MSGID: 025dfab6-3039-49f2-9ecc-bb89e97d05db X-archive-position: 8419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_9suOBTiZpSr4nE3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While 2004-08-18 Luis R. Rodriguez * Work based on initial patches from Jouni Malinen * Initial wpa_supplicant support work: * isl_ioctl.c (prism54_process_trap_helper): Start to use mlmeex, * start doing what's right for * DOT11_OID_AUTHENTICATEEX, * DOT11_OID_ASSOCIATEEX, * DOT11_OID_ASSOCIATEEX, and * DOT11_OID_REASSOCIATEEX * isl_ioctl.c: add temporary structure for wpa_supplicant requests, * isl_ioctl.c: add prism2_ioctl_set_encryption which can probably be removed later * isl_ioctl.c: add prism2_ioctl_set_generic_element (well tested) * isl_ioctl.c: add prism2_ioctl_mlme which should be unnecessary since * WE scan should be used by wpa_supplicant * isl_ioctl.c: add prism54_hostapd - this parses wpa_supplicant * requests and does the right job for each * isl_ioctl.c (prism54_set_wpa): changed to not use mgt_set/mgt_commit * as commit is unecessary. Added proper OID sets to enable/disable WPA. * This is called by wpa_supplicant at startup. This should eventually * be part of WE18. * isl_ioctl.c (prism54_ioctl): Links wpa_supplicant to prism54 * isl_ioctl.h: defined prism54_set_wpa to allow prism54_hostapd to use * isl_oid.h: add struct obj_attachment for OID OID_TYPE_ATTACH * oid_mgt.c: map OID DOT11_OID_ATTACHMENT to struct obj_attachment * oid_mgt.c (mgt_le_to_cpu, mgt_cpu_to_le): handle endianness for * obj_attachment * oid_mgt.c: add mgt_set_varlen, needed for mlmeex as it has a * variable size field. * oid_mgt.c: add mgt_unlatch_all, this can be used to force a commit * on OIDs: * MEDIUMLIMIT, BEACONPERIOD, DTIMPERIOD, ATIMWINDOW, * LISTENINTERVAL, FREQUENCY, EXTENDEDRATES * These OIDs are "latched". TODO: config mode handling. * oid_mgt.c (mgt_response_to_str): learn to parse OID_TYPE_ATTACH * oid_mgt.h: add mgt_set_varlen, and mgt_unlatch_all Margit --Boundary-00=_9suOBTiZpSr4nE3 Content-Type: text/x-diff; charset="us-ascii"; name="05_start_wpa.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="05_start_wpa.patch" diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:48:32.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:49:05.000000000 +0200 @@ -1735,11 +1735,13 @@ char *data) { struct obj_mlme *mlme = (struct obj_mlme *) data; - size_t len; - u8 *payload, *pos = (u8 *) (mlme + 1); - - len = pos[0] | (pos[1] << 8); /* little endian data length */ - payload = pos + 2; + struct obj_mlmeex *mlmeex = (struct obj_mlmeex *) data; + struct obj_mlmeex *confirm; + u8 wpa_ie[MAX_WPA_IE_LEN]; + int wpa_ie_len; + size_t len = 0; /* u16, better? */ + u8 *payload = 0, *pos = 0; + int ret; /* I think all trapable objects are listed here. * Some oids have a EX version. The difference is that they are emitted @@ -1749,9 +1751,14 @@ * suited. We use the more flexible custom event facility. */ + if (oid >= DOT11_OID_BEACON) { + len = mlmeex->size; + payload = pos = mlmeex->data; + } + /* I fear prism54_process_bss_data won't work with big endian data */ if ((oid == DOT11_OID_BEACON) || (oid == DOT11_OID_PROBE)) - prism54_process_bss_data(priv, oid, mlme->address, + prism54_process_bss_data(priv, oid, mlmeex->address, payload, len); mgt_le_to_cpu(isl_oid[oid].flags & OID_FLAG_TYPE, (void *) mlme); @@ -1811,21 +1818,134 @@ case DOT11_OID_AUTHENTICATEEX: handle_request(priv, mlme, oid); - send_formatted_event(priv, "Authenticate request", mlme, 1); + send_formatted_event(priv, "Authenticate request (ex)", mlme, 1); + + if (priv->iw_mode != IW_MODE_MASTER + && mlmeex->state != DOT11_STATE_AUTHING) + break; + + confirm = kmalloc(sizeof(struct obj_mlmeex) + 6, GFP_ATOMIC); + + if (!confirm) + break; + + memcpy(&confirm->address, mlmeex->address, ETH_ALEN); + printk(KERN_DEBUG "Authenticate from: address:\t%02x:%02x:%02x:%02x:%02x:%02x\n", + mlmeex->address[0], + mlmeex->address[1], + mlmeex->address[2], + mlmeex->address[3], + mlmeex->address[4], + mlmeex->address[5] + ); + confirm->id = -1; /* or mlmeex->id ? */ + confirm->state = 0; /* not used */ + confirm->code = 0; + confirm->size = 6; + confirm->data[0] = 0x00; + confirm->data[1] = 0x00; + confirm->data[2] = 0x02; + confirm->data[3] = 0x00; + confirm->data[4] = 0x00; + confirm->data[5] = 0x00; + + ret = mgt_set_varlen(priv, DOT11_OID_ASSOCIATEEX, confirm, 6); + + kfree(confirm); + if (ret) + return ret; break; case DOT11_OID_DISASSOCIATEEX: - send_formatted_event(priv, "Disassociate request", mlme, 0); + send_formatted_event(priv, "Disassociate request (ex)", mlme, 0); break; case DOT11_OID_ASSOCIATEEX: handle_request(priv, mlme, oid); - send_formatted_event(priv, "Associate request", mlme, 1); + send_formatted_event(priv, "Associate request (ex)", mlme, 1); + + if (priv->iw_mode != IW_MODE_MASTER + && mlmeex->state != DOT11_STATE_AUTHING) + break; + + confirm = kmalloc(sizeof(struct obj_mlmeex), GFP_ATOMIC); + + if (!confirm) + break; + + memcpy(&confirm->address, mlmeex->address, ETH_ALEN); + + confirm->id = ((struct obj_mlmeex *)mlme)->id; + confirm->state = 0; /* not used */ + confirm->code = 0; + + wpa_ie_len = prism54_wpa_ie_get(priv, mlmeex->address, wpa_ie); + + if (!wpa_ie_len) { + printk(KERN_DEBUG "No WPA IE found from " + "address:\t%02x:%02x:%02x:%02x:%02x:%02x\n", + mlmeex->address[0], + mlmeex->address[1], + mlmeex->address[2], + mlmeex->address[3], + mlmeex->address[4], + mlmeex->address[5] + ); + kfree(confirm); + break; + } + + confirm->size = wpa_ie_len; + memcpy(&confirm->data, wpa_ie, wpa_ie_len); + + mgt_set_varlen(priv, oid, confirm, wpa_ie_len); + + kfree(confirm); + break; case DOT11_OID_REASSOCIATEEX: handle_request(priv, mlme, oid); - send_formatted_event(priv, "Reassociate request", mlme, 1); + send_formatted_event(priv, "Reassociate request (ex)", mlme, 1); + + if (priv->iw_mode != IW_MODE_MASTER + && mlmeex->state != DOT11_STATE_ASSOCING) + break; + + confirm = kmalloc(sizeof(struct obj_mlmeex), GFP_ATOMIC); + + if (!confirm) + break; + + memcpy(&confirm->address, mlmeex->address, ETH_ALEN); + + confirm->id = mlmeex->id; + confirm->state = 0; /* not used */ + confirm->code = 0; + + wpa_ie_len = prism54_wpa_ie_get(priv, mlmeex->address, wpa_ie); + + if (!wpa_ie_len) { + printk(KERN_DEBUG "No WPA IE found from " + "address:\t%02x:%02x:%02x:%02x:%02x:%02x\n", + mlmeex->address[0], + mlmeex->address[1], + mlmeex->address[2], + mlmeex->address[3], + mlmeex->address[4], + mlmeex->address[5] + ); + kfree(confirm); + break; + } + + confirm->size = wpa_ie_len; + memcpy(&confirm->data, wpa_ie, wpa_ie_len); + + mgt_set_varlen(priv, oid, confirm, wpa_ie_len); + + kfree(confirm); + break; default: @@ -1868,23 +1988,367 @@ return ret; } +/* Note: currently, use hostapd ioctl from the Host AP driver for WPA + * support. This is to be replaced with Linux wireless extensions once they + * get WPA support. */ + +/* Note II: please leave all this together as it will be easier to remove later, + * once wireless extensions add WPA support -mcgrof */ + +/* PRISM54_HOSTAPD ioctl() cmd: */ +enum { + PRISM2_SET_ENCRYPTION = 6, + PRISM2_HOSTAPD_SET_GENERIC_ELEMENT = 12, + PRISM2_HOSTAPD_MLME = 13, + PRISM2_HOSTAPD_SCAN_REQ = 14, +}; + +#define PRISM54_SET_WPA SIOCIWFIRSTPRIV+12 +#define PRISM54_HOSTAPD SIOCIWFIRSTPRIV+25 +#define PRISM54_DROP_UNENCRYPTED SIOCIWFIRSTPRIV+26 + +#define PRISM2_HOSTAPD_MAX_BUF_SIZE 1024 +#define PRISM2_HOSTAPD_GENERIC_ELEMENT_HDR_LEN \ +((int) (&((struct prism2_hostapd_param *) 0)->u.generic_elem.data)) + +/* Maximum length for algorithm names (-1 for nul termination) + * used in ioctl() */ +#define HOSTAP_CRYPT_ALG_NAME_LEN 16 + +struct prism2_hostapd_param { + u32 cmd; + u8 sta_addr[ETH_ALEN]; + union { + struct { + u8 alg[HOSTAP_CRYPT_ALG_NAME_LEN]; + u32 flags; + u32 err; + u8 idx; + u8 seq[8]; /* sequence counter (set: RX, get: TX) */ + u16 key_len; + u8 key[0]; + } crypt; + struct { + u8 len; + u8 data[0]; + } generic_elem; + struct { +#define MLME_STA_DEAUTH 0 +#define MLME_STA_DISASSOC 1 + u16 cmd; + u16 reason_code; + } mlme; + struct { + u8 ssid_len; + u8 ssid[32]; + } scan_req; + } u; +}; + + +static int +prism2_ioctl_set_encryption(struct net_device *dev, + struct prism2_hostapd_param *param, + int param_len) +{ + islpci_private *priv = netdev_priv(dev); + int rvalue = 0, force = 0; + int authen = DOT11_AUTH_OS, invoke = 0, exunencrypt = 0; + union oid_res_t r; + + /* with the new API, it's impossible to get a NULL pointer. + * New version of iwconfig set the IW_ENCODE_NOKEY flag + * when no key is given, but older versions don't. */ + + if (param->u.crypt.key_len > 0) { + /* we have a key to set */ + int index = param->u.crypt.idx; + int current_index; + struct obj_key key = { DOT11_PRIV_TKIP, 0, "" }; + + /* get the current key index */ + rvalue = mgt_get_request(priv, DOT11_OID_DEFKEYID, 0, NULL, &r); + current_index = r.u; + /* Verify that the key is not marked as invalid */ + if (!(param->u.crypt.flags & IW_ENCODE_NOKEY)) { + key.length = param->u.crypt.key_len > sizeof (param->u.crypt.key) ? + sizeof (param->u.crypt.key) : param->u.crypt.key_len; + memcpy(key.key, param->u.crypt.key, key.length); + if (key.length == 32) + /* we want WPA-PSK */ + key.type = DOT11_PRIV_TKIP; + if ((index < 0) || (index > 3)) + /* no index provided use the current one */ + index = current_index; + + /* now send the key to the card */ + rvalue |= + mgt_set_request(priv, DOT11_OID_DEFKEYX, index, + &key); + } + /* + * If a valid key is set, encryption should be enabled + * (user may turn it off later). + * This is also how "iwconfig ethX key on" works + */ + if ((index == current_index) && (key.length > 0)) + force = 1; + } else { + int index = (param->u.crypt.flags & IW_ENCODE_INDEX) - 1; + if ((index >= 0) && (index <= 3)) { + /* we want to set the key index */ + rvalue |= + mgt_set_request(priv, DOT11_OID_DEFKEYID, 0, + &index); + } else { + if (!param->u.crypt.flags & IW_ENCODE_MODE) { + /* we cannot do anything. Complain. */ + return -EINVAL; + } + } + } + /* now read the flags */ + if (param->u.crypt.flags & IW_ENCODE_DISABLED) { + /* Encoding disabled, + * authen = DOT11_AUTH_OS; + * invoke = 0; + * exunencrypt = 0; */ + } + if (param->u.crypt.flags & IW_ENCODE_OPEN) + /* Encode but accept non-encoded packets. No auth */ + invoke = 1; + if ((param->u.crypt.flags & IW_ENCODE_RESTRICTED) || force) { + /* Refuse non-encoded packets. Auth */ + authen = DOT11_AUTH_BOTH; + invoke = 1; + exunencrypt = 1; + } + /* do the change if requested */ + if ((param->u.crypt.flags & IW_ENCODE_MODE) || force) { + rvalue |= + mgt_set_request(priv, DOT11_OID_AUTHENABLE, 0, &authen); + rvalue |= + mgt_set_request(priv, DOT11_OID_PRIVACYINVOKED, 0, &invoke); + rvalue |= + mgt_set_request(priv, DOT11_OID_EXUNENCRYPTED, 0, + &exunencrypt); + } + return rvalue; +} + +static int +prism2_ioctl_set_generic_element(struct net_device *ndev, + struct prism2_hostapd_param *param, + int param_len) +{ + islpci_private *priv = netdev_priv(ndev); + int max_len, len, alen, ret=0; + struct obj_attachment *attach; + + len = param->u.generic_elem.len; + max_len = param_len - PRISM2_HOSTAPD_GENERIC_ELEMENT_HDR_LEN; + if (max_len < 0 || max_len < len) + return -EINVAL; + + alen = sizeof(*attach) + len; + attach = kmalloc(alen, GFP_KERNEL); + if (attach == NULL) + return -ENOMEM; + + memset(attach, 0, alen); +#define WLAN_FC_TYPE_MGMT 0 +#define WLAN_FC_STYPE_ASSOC_REQ 0 +#define WLAN_FC_STYPE_REASSOC_REQ 2 + + /* Note: endianness is covered by mgt_set_varlen */ + + attach->type = (WLAN_FC_TYPE_MGMT << 2) | + (WLAN_FC_STYPE_ASSOC_REQ << 4); + attach->id = -1; + attach->size = len; + memcpy(attach->data, param->u.generic_elem.data, len); + + ret = mgt_set_varlen(priv, DOT11_OID_ATTACHMENT, attach, len); + + if (ret == 0) { + attach->type = (WLAN_FC_TYPE_MGMT << 2) | + (WLAN_FC_STYPE_REASSOC_REQ << 4); + + ret = mgt_set_varlen(priv, DOT11_OID_ATTACHMENT, attach, len); + + if (ret == 0) + printk(KERN_DEBUG "%s: WPA IE Attachment was set\n", + ndev->name); + } + + kfree(attach); + return ret; + +} + +static int +prism2_ioctl_mlme(struct net_device *dev, struct prism2_hostapd_param *param) +{ + return -EOPNOTSUPP; +} + +static int +prism2_ioctl_scan_req(struct net_device *ndev, + struct prism2_hostapd_param *param) +{ + islpci_private *priv = netdev_priv(ndev); + int i, rvalue; + struct obj_bsslist *bsslist; + u32 noise = 0; + char *extra = ""; + char *current_ev = "foo"; + union oid_res_t r; + + if (islpci_get_state(priv) < PRV_STATE_INIT) { + /* device is not ready, fail gently */ + return 0; + } + + /* first get the noise value. We will use it to report the link quality */ + rvalue = mgt_get_request(priv, DOT11_OID_NOISEFLOOR, 0, NULL, &r); + noise = r.u; + + /* Ask the device for a list of known bss. We can report at most + * IW_MAX_AP=64 to the range struct. But the device won't repport anything + * if you change the value of IWMAX_BSS=24. + */ + rvalue |= mgt_get_request(priv, DOT11_OID_BSSLIST, 0, NULL, &r); + bsslist = r.ptr; + + /* ok now, scan the list and translate its info */ + for (i = 0; i < min(IW_MAX_AP, (int) bsslist->nr); i++) + current_ev = prism54_translate_bss(ndev, current_ev, + extra + IW_SCAN_MAX_DATA, + &(bsslist->bsslist[i]), + noise); + kfree(bsslist); + + return rvalue; +} + +static int +prism54_hostapd(struct net_device *ndev, struct iw_point *p) +{ + struct prism2_hostapd_param *param; + int ret = 0; + u32 uwrq; + + printk(KERN_DEBUG "prism54_hostapd - len=%d\n", p->length); + if (p->length < sizeof(struct prism2_hostapd_param) || + p->length > PRISM2_HOSTAPD_MAX_BUF_SIZE || !p->pointer) + return -EINVAL; + + param = (struct prism2_hostapd_param *) kmalloc(p->length, GFP_KERNEL); + if (param == NULL) + return -ENOMEM; + + if (copy_from_user(param, p->pointer, p->length)) { + kfree(param); + return -EFAULT; + } + + switch (param->cmd) { + case PRISM2_SET_ENCRYPTION: + printk(KERN_DEBUG "%s: Caught WPA supplicant set encryption request\n", + ndev->name); + ret = prism2_ioctl_set_encryption(ndev, param, p->length); + break; + case PRISM2_HOSTAPD_SET_GENERIC_ELEMENT: + printk(KERN_DEBUG "%s: Caught WPA supplicant set WPA IE request\n", + ndev->name); + ret = prism2_ioctl_set_generic_element(ndev, param, + p->length); + break; + case PRISM2_HOSTAPD_MLME: + printk(KERN_DEBUG "%s: Caught WPA supplicant MLME request\n", + ndev->name); + ret = prism2_ioctl_mlme(ndev, param); + break; + case PRISM2_HOSTAPD_SCAN_REQ: + printk(KERN_DEBUG "%s: Caught WPA supplicant scan request\n", + ndev->name); + ret = prism2_ioctl_scan_req(ndev, param); + break; + case PRISM54_SET_WPA: + printk(KERN_DEBUG "%s: Caught WPA supplicant wpa init request\n", + ndev->name); + uwrq = 1; + ret = prism54_set_wpa(ndev, NULL, &uwrq, NULL); + break; + case PRISM54_DROP_UNENCRYPTED: + printk(KERN_DEBUG "%s: Caught WPA drop unencrypted request\n", + ndev->name); +#if 0 + uwrq = 0x01; + mgt_set(priv, DOT11_OID_EXUNENCRYPTED, &uwrq); + down_write(&priv->mib_sem); + mgt_commit(priv); + up_write(&priv->mib_sem); +#endif + /* Not necessary, as set_wpa does it, should we just do it here though? */ + ret = 0; + break; + default: + printk(KERN_DEBUG "%s: Caught a WPA supplicant request that is not supported\n", + ndev->name); + ret = -EOPNOTSUPP; + break; + } + + if (ret == 0 && copy_to_user(p->pointer, param, p->length)) + ret = -EFAULT; + + kfree(param); + + return ret; +} + int prism54_set_wpa(struct net_device *ndev, struct iw_request_info *info, __u32 * uwrq, char *extra) { islpci_private *priv = netdev_priv(ndev); + u32 mlme, authen, dot1x, filter, wep; - down_write(&priv->mib_sem); + if (islpci_get_state(priv) < PRV_STATE_INIT) + return 0; + wep = 1; /* For privacy invoked */ + filter = 1; /* Filter out all unencrypted frames */ + dot1x = 0x01; /* To enable eap filter */ + mlme = DOT11_MLME_EXTENDED; + authen = DOT11_AUTH_OS; /* Only WEP uses _SK and _BOTH */ + + down_write(&priv->mib_sem); priv->wpa = *uwrq; - if (priv->wpa) { - u32 l = DOT11_MLME_EXTENDED; - mgt_set(priv, DOT11_OID_MLMEAUTOLEVEL, &l); + + switch (priv->wpa) { + default: + case 0: /* Clears/disables WPA and friends */ + wep = 0; + filter = 0; /* Do not filter un-encrypted data */ + dot1x = 0; + mlme = DOT11_MLME_AUTO; + printk("%s: Disabling WPA\n", ndev->name); + break; + case 2: + case 1: /* WPA */ + printk("%s: Enabling WPA\n", ndev->name); + break; } - /* restart the card with new level. Needed ? */ - mgt_commit(priv); up_write(&priv->mib_sem); + mgt_set_request(priv, DOT11_OID_AUTHENABLE, 0, &authen); + mgt_set_request(priv, DOT11_OID_PRIVACYINVOKED, 0, &wep); + mgt_set_request(priv, DOT11_OID_EXUNENCRYPTED, 0, &filter); + mgt_set_request(priv, DOT11_OID_DOT1XENABLE, 0, &dot1x); + mgt_set_request(priv, DOT11_OID_MLMEAUTOLEVEL, 0, &mlme); + return 0; } @@ -2250,11 +2714,19 @@ #endif /* WIRELESS_EXT == 16 */ }; -/* For ioctls that don't work with the new API */ +/* For wpa_supplicant */ int prism54_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) { - + struct iwreq *wrq = (struct iwreq *) rq; + int ret = -1; + switch (cmd) { + case PRISM54_HOSTAPD: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + ret = prism54_hostapd(ndev, &wrq->u.data); + return ret; + } return -EOPNOTSUPP; } diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.h linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.h --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.h 2004-08-14 07:36:58.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.h 2004-09-05 10:49:05.000000000 +0200 @@ -48,6 +48,8 @@ int prism54_set_mac_address(struct net_device *, void *); int prism54_ioctl(struct net_device *, struct ifreq *, int); +int prism54_set_wpa(struct net_device *, struct iw_request_info *, + __u32 *, char *); extern const struct iw_handler_def prism54_handler_def; diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_oid.h linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_oid.h --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_oid.h 2004-08-14 07:37:15.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_oid.h 2004-09-05 10:49:05.000000000 +0200 @@ -91,6 +91,14 @@ u16 mhz[0]; } __attribute__ ((packed)); +struct obj_attachment { + char type; + char reserved; + short id; + short size; + char data[0]; +} __attribute__((packed)); + /* * in case everything's ok, the inlined function below will be * optimized away by the compiler... @@ -472,6 +480,7 @@ #define OID_TYPE_MLMEEX 0x09 #define OID_TYPE_ADDR 0x0A #define OID_TYPE_RAW 0x0B +#define OID_TYPE_ATTACH 0x0C /* OID_TYPE_MLMEEX is special because of a variable size field when sending. * Not yet implemented (not used in driver anyway). diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/oid_mgt.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/oid_mgt.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/oid_mgt.c 2004-09-05 10:44:54.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/oid_mgt.c 2004-09-05 10:49:05.000000000 +0200 @@ -201,7 +201,8 @@ OID_U32(DOT11_OID_STATIMEOUT, 0x19000000), OID_U32_C(DOT11_OID_MLMEAUTOLEVEL, 0x19000001), OID_U32(DOT11_OID_BSSTIMEOUT, 0x19000002), - OID_UNKNOWN(DOT11_OID_ATTACHMENT, 0x19000003), + [DOT11_OID_ATTACHMENT] = {0x19000003, 0, + sizeof(struct obj_attachment), OID_TYPE_ATTACH}, OID_STRUCT_C(DOT11_OID_PSMBUFFER, 0x19000004, struct obj_buffer, OID_TYPE_BUFFER), @@ -329,6 +330,12 @@ mlme->size = le16_to_cpu(mlme->size); break; } + case OID_TYPE_ATTACH:{ + struct obj_attachment *attach = data; + attach->id = le16_to_cpu(attach->id); + attach->size = le16_to_cpu(attach->size);; + break; + } case OID_TYPE_SSID: case OID_TYPE_KEY: case OID_TYPE_ADDR: @@ -392,6 +399,12 @@ mlme->size = cpu_to_le16(mlme->size); break; } + case OID_TYPE_ATTACH:{ + struct obj_attachment *attach = data; + attach->id = cpu_to_le16(attach->id); + attach->size = cpu_to_le16(attach->size);; + break; + } case OID_TYPE_SSID: case OID_TYPE_KEY: case OID_TYPE_ADDR: @@ -465,6 +478,42 @@ return ret; } +/* None of these are cached */ +int +mgt_set_varlen(islpci_private *priv, enum oid_num_t n, void *data, int extra_len) +{ + int ret = 0; + struct islpci_mgmtframe *response; + int response_op = PIMFOR_OP_ERROR; + int dlen; + u32 oid; + + BUG_ON(OID_NUM_LAST <= n); + + dlen = isl_oid[n].size; + oid = isl_oid[n].oid; + + mgt_cpu_to_le(isl_oid[n].flags & OID_FLAG_TYPE, data); + + if (islpci_get_state(priv) >= PRV_STATE_READY) { + ret = islpci_mgt_transaction(priv->ndev, PIMFOR_OP_SET, oid, + data, dlen + extra_len, &response); + if (!ret) { + response_op = response->header->operation; + islpci_mgt_release(response); + } + if (ret || response_op == PIMFOR_OP_ERROR) + ret = -EIO; + } else + ret = -EIO; + + /* re-set given data to what it was */ + if (data) + mgt_le_to_cpu(isl_oid[n].flags & OID_FLAG_TYPE, data); + + return ret; +} + int mgt_get_request(islpci_private *priv, enum oid_num_t n, int extra, void *data, union oid_res_t *res) @@ -673,6 +722,40 @@ } } +/* The following OIDs need to be "unlatched": + * + * MEDIUMLIMIT,BEACONPERIOD,DTIMPERIOD,ATIMWINDOW,LISTENINTERVAL + * FREQUENCY,EXTENDEDRATES. + * + * The way to do this is to set ESSID. Note though that they may get + * unlatch before though by setting another OID. */ +void +mgt_unlatch_all(islpci_private *priv) +{ + u32 u; + int rvalue = 0; + + if (islpci_get_state(priv) < PRV_STATE_INIT) + return; + + u = DOT11_OID_SSID; + rvalue = mgt_commit_list(priv, &u, 1); + /* Necessary if in MANUAL RUN mode? */ +#if 0 + u = OID_INL_MODE; + rvalue |= mgt_commit_list(priv, &u, 1); + + u = DOT11_OID_MLMEAUTOLEVEL; + rvalue |= mgt_commit_list(priv, &u, 1); + + u = OID_INL_MODE; + rvalue |= mgt_commit_list(priv, &u, 1); +#endif + + if (rvalue) + printk(KERN_DEBUG "%s: Unlatching OIDs failed\n", priv->ndev->name); +} + /* This will tell you if you are allowed to answer a mlme(ex) request .*/ int @@ -773,6 +856,14 @@ mlme->state, mlme->code, mlme->size); } break; + case OID_TYPE_ATTACH:{ + struct obj_attachment *attach = r->ptr; + return snprintf(str, PRIV_STR_SIZE, + "id=%d\nsize=%d\n", + attach->id, + attach->size); + } + break; case OID_TYPE_SSID:{ struct obj_ssid *ssid = r->ptr; return snprintf(str, PRIV_STR_SIZE, diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/oid_mgt.h linux-2.6.9-rc1msw/drivers/net/wireless/prism54/oid_mgt.h --- linux-2.6.9rc1/drivers/net/wireless/prism54/oid_mgt.h 2004-08-14 07:38:07.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/oid_mgt.h 2004-09-05 10:49:05.000000000 +0200 @@ -36,6 +36,8 @@ void mgt_le_to_cpu(int, void *); int mgt_set_request(islpci_private *, enum oid_num_t, int, void *); +int mgt_set_varlen(islpci_private *, enum oid_num_t, void *, int); + int mgt_get_request(islpci_private *, enum oid_num_t, int, void *, union oid_res_t *); @@ -47,6 +49,7 @@ void mgt_get(islpci_private *, enum oid_num_t, void *); void mgt_commit(islpci_private *); +void mgt_unlatch_all(islpci_private *); int mgt_mlme_answer(islpci_private *); --Boundary-00=_9suOBTiZpSr4nE3-- From margitsw@t-online.de Sun Sep 5 03:50:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 03:50:22 -0700 (PDT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85AoGPm020739 for ; Sun, 5 Sep 2004 03:50:17 -0700 Received: from fwd02.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1C3uaZ-0006iB-00; Sun, 05 Sep 2004 12:49:39 +0200 Received: from roglap.local (X7k0e6Zage4T9+QRRYGXn7udS1tgLRjBj2jmqKiHeAFSkscfqCAQr7@[217.224.19.205]) by fwd02.sul.t-online.com with esmtp id 1C3uaP-1TlewS0; Sun, 5 Sep 2004 12:49:29 +0200 From: margitsw@t-online.de (Margit Schubert-While) To: jgarzik@pobox.com Subject: [PATCH 6/6 linux-2.6.9-rc1/2.4.28-pre2] prism54 fix wpa_supplicant frequency parsing Date: Sun, 5 Sep 2004 12:37:56 +0200 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_EyuOBgflA0PJwpo" Message-Id: <200409051237.56058.margitsw@t-online.de> X-ID: X7k0e6Zage4T9+QRRYGXn7udS1tgLRjBj2jmqKiHeAFSkscfqCAQr7 X-TOI-MSGID: 1062f646-4f41-46e4-a193-d554d8adf83a X-archive-position: 8420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev --Boundary-00=_EyuOBgflA0PJwpo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 2004-09-05 Margit Schubert-While 2004-08-22 Luis R. Rodriguez * This work fixes wpa_supplicant frequency parsing. iwlist eth0 * scan will now show channel and frequency. Margit --Boundary-00=_EyuOBgflA0PJwpo Content-Type: text/x-diff; charset="us-ascii"; name="06_fix_freqparse.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="06_fix_freqparse.patch" diff -Naur linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c --- linux-2.6.9rc1/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:49:37.000000000 +0200 +++ linux-2.6.9-rc1msw/drivers/net/wireless/prism54/isl_ioctl.c 2004-09-05 10:49:53.000000000 +0200 @@ -604,8 +604,8 @@ current_ev = iwe_stream_add_point(current_ev, end_buf, &iwe, NULL); /* Add frequency. (short) bss->channel is the frequency in MHz */ - iwe.u.freq.m = channel_of_freq(bss->channel); - iwe.u.freq.e = 0; + iwe.u.freq.m = bss->channel; + iwe.u.freq.e = 6; iwe.cmd = SIOCGIWFREQ; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); --Boundary-00=_EyuOBgflA0PJwpo-- From hadi@cyberus.ca Sun Sep 5 05:15:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 05:16:06 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85CFxRY031106 for ; Sun, 5 Sep 2004 05:15:59 -0700 Received: from localhost.tpn.ch ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090505172011:29825 ; Sun, 5 Sep 2004 05:17:20 -0700 Subject: Re: Improvements in FreeBSD 5.3 networking From: jamal Reply-To: hadi@cyberus.ca To: Tomasz Torcz Cc: netdev@oss.sgi.com, "David S. Miller" , Robert Olsson In-Reply-To: <20040905094636.GA10086@irc.pl> References: <20040905094636.GA10086@irc.pl> Organization: jamalopolis Message-Id: <1094386350.1340.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Sep 2004 08:15:25 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/05/2004 05:17:20 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/05/2004 05:17:22 AM, Serialize complete at 09/05/2004 05:17:22 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Guess didnt take too long for those BSDers to post on slashdot. It would be nice for someone to install freebsd and verify the claims on the routing aspect. Anyone in Ottawa with BSD expertise drop me a note - I have access to measurement equipment (and really dont wanna touch BSD if i can avoid it). cheers, jamal PS: We can certainly do better than that on Opterons. Robert reports a 1.3 Mpps rate on a dual opteron 1.6Ghz. Our numbers on Xeons are less than 1Mpps. But we can let an old OS like BSD beat us, can we now ? ;-> On Sun, 2004-09-05 at 05:46, Tomasz Torcz wrote: > Hi, > > reading Slashdot I'm sutmbled upon presentation of FreeBSD new > features: > http://people.freebsd.org/~andre/FreeBSD-5.3-Networking.pdf > > It look pretty interesting (e.g. tcphostcache), especially they claim > that FreeBSD on 2.8 GHz Xeon can route 1Mpps. > > Original slashodt story: > http://bsd.slashdot.org/article.pl?sid=04/09/04/133253 From manfred@colorfullife.com Sun Sep 5 06:10:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 06:11:03 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85DAoUC032224 for ; Sun, 5 Sep 2004 06:10:51 -0700 Received: from dbl.q-ag.de (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i85DAKuG016390; Sun, 5 Sep 2004 15:10:20 +0200 Received: from localhost (manfred@localhost) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i85DAJSp016386; Sun, 5 Sep 2004 15:10:20 +0200 X-Authentication-Warning: dbl.q-ag.de: manfred owned process doing -bs Date: Sun, 5 Sep 2004 15:10:19 +0200 (CEST) From: Manfred Spraul X-X-Sender: manfred@dbl.q-ag.de To: linux-kernel@vger.kernel.org cc: netdev@oss.sgi.com Subject: [PATCH] backport of forcedeth 0.29 to 2.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Hi, attached is as backport of the latest forcedeth driver to 2.4: It adds gigabit ethernet support and lots of bugfixes from the 2.6 driver. The most notable change is gigabit ethernet support and a complete rewrite of the PHY initialization and media detection code. Please test it: It works for me (nForce 250-Gb), but I don't have a non-GigE board to test the media detection. The actual backport was done by Jane Liu: - all occurrences of msleep changed to mdelay - invocations of synchronize_irq changed to take no parameters - SET_NETDEV_DEV calls removed - module_param call changed to MODULE_PARM -- Manfred // Kernel Version: // VERSION = 2 // PATCHLEVEL = 4 // SUBLEVEL = 28 // EXTRAVERSION = -pre2 --- 2.4/drivers/net/forcedeth.c 2004-04-14 15:05:30.000000000 +0200 +++ build-2.4/drivers/net/forcedeth.c 2004-09-05 14:34:44.019230793 +0200 @@ -10,8 +10,11 @@ * trademarks of NVIDIA Corporation in the United States and other * countries. * - * Copyright (C) 2003 Manfred Spraul + * Copyright (C) 2003,4 Manfred Spraul * Copyright (C) 2004 Andrew de Quincey (wol support) + * Copyright (C) 2004 Carl-Daniel Hailfinger (invalid MAC handling, insane + * IRQ rate fixes, bigendian fixes, cleanups, verification) + * Copyright (c) 2004 NVIDIA Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -60,15 +63,19 @@ * 0.19: 29 Nov 2003: Handle RxNoBuf, detect & handle invalid mac * addresses, really stop rx if already running * in nv_start_rx, clean up a bit. - * (C) Carl-Daniel Hailfinger * 0.20: 07 Dec 2003: alloc fixes * 0.21: 12 Jan 2004: additional alloc fix, nic polling fix. * 0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup - * on close. - * (C) Carl-Daniel Hailfinger, Manfred Spraul + * on close. * 0.23: 26 Jan 2004: various small cleanups * 0.24: 27 Feb 2004: make driver even less anonymous in backtraces * 0.25: 09 Mar 2004: wol support + * 0.26: 03 Jun 2004: netdriver specific annotation, sparse-related fixes + * 0.27: 19 Jun 2004: Gigabit support, new descriptor rings, + * added CK804/MCP04 device IDs, code fixes + * for registers, link status and other minor fixes. + * 0.28: 21 Jun 2004: Big cleanup, making driver mostly endian safe + * 0.29: 31 Aug 2004: Add backup timer for link change notification. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -80,7 +87,8 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.25" +#define FORCEDETH_VERSION "0.29" +#define DRV_NAME "forcedeth" #include #include @@ -113,16 +121,18 @@ * Hardware access: */ -#define DEV_NEED_LASTPACKET1 0x0001 -#define DEV_IRQMASK_1 0x0002 -#define DEV_IRQMASK_2 0x0004 -#define DEV_NEED_TIMERIRQ 0x0008 +#define DEV_NEED_LASTPACKET1 0x0001 /* set LASTPACKET1 in tx flags */ +#define DEV_IRQMASK_1 0x0002 /* use NVREG_IRQMASK_WANTED_1 for irq mask */ +#define DEV_IRQMASK_2 0x0004 /* use NVREG_IRQMASK_WANTED_2 for irq mask */ +#define DEV_NEED_TIMERIRQ 0x0008 /* set the timer irq flag in the irq mask */ +#define DEV_NEED_LINKTIMER 0x0010 /* poll link settings. Relies on the timer irq */ enum { NvRegIrqStatus = 0x000, #define NVREG_IRQSTAT_MIIEVENT 0x040 #define NVREG_IRQSTAT_MASK 0x1ff NvRegIrqMask = 0x004, +#define NVREG_IRQ_RX_ERROR 0x0001 #define NVREG_IRQ_RX 0x0002 #define NVREG_IRQ_RX_NOBUF 0x0004 #define NVREG_IRQ_TX_ERR 0x0008 @@ -132,7 +142,7 @@ enum { #define NVREG_IRQ_TX1 0x0100 #define NVREG_IRQMASK_WANTED_1 0x005f #define NVREG_IRQMASK_WANTED_2 0x0147 -#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) +#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) NvRegUnknownSetupReg6 = 0x008, #define NVREG_UNKSETUP6_VAL 3 @@ -159,7 +169,7 @@ enum { NvRegOffloadConfig = 0x90, #define NVREG_OFFLOAD_HOMEPHY 0x601 -#define NVREG_OFFLOAD_NORMAL 0x5ee +#define NVREG_OFFLOAD_NORMAL RX_NIC_BUFSIZE NvRegReceiverControl = 0x094, #define NVREG_RCVCTL_START 0x01 NvRegReceiverStatus = 0x98, @@ -168,6 +178,8 @@ enum { NvRegRandomSeed = 0x9c, #define NVREG_RNDSEED_MASK 0x00ff #define NVREG_RNDSEED_FORCE 0x7f00 +#define NVREG_RNDSEED_FORCE2 0x2d00 +#define NVREG_RNDSEED_FORCE3 0x7400 NvRegUnknownSetupReg1 = 0xA0, #define NVREG_UNKSETUP1_VAL 0x16070f @@ -181,6 +193,9 @@ enum { NvRegMulticastMaskA = 0xB8, NvRegMulticastMaskB = 0xBC, + NvRegPhyInterface = 0xC0, +#define PHY_RGMII 0x10000000 + NvRegTxRingPhysAddr = 0x100, NvRegRxRingPhysAddr = 0x104, NvRegRingSizes = 0x108, @@ -189,12 +204,12 @@ enum { NvRegUnknownTransmitterReg = 0x10c, NvRegLinkSpeed = 0x110, #define NVREG_LINKSPEED_FORCE 0x10000 -#define NVREG_LINKSPEED_10 10 +#define NVREG_LINKSPEED_10 1000 #define NVREG_LINKSPEED_100 100 -#define NVREG_LINKSPEED_1000 1000 +#define NVREG_LINKSPEED_1000 50 NvRegUnknownSetupReg5 = 0x130, #define NVREG_UNKSETUP5_BIT31 (1<<31) - NvRegUnknownSetupReg3 = 0x134, + NvRegUnknownSetupReg3 = 0x13c, #define NVREG_UNKSETUP3_VAL1 0x200010 NvRegTxRxControl = 0x144, #define NVREG_TXRXCTL_KICK 0x0001 @@ -213,15 +228,15 @@ enum { NvRegAdapterControl = 0x188, #define NVREG_ADAPTCTL_START 0x02 #define NVREG_ADAPTCTL_LINKUP 0x04 -#define NVREG_ADAPTCTL_PHYVALID 0x4000 +#define NVREG_ADAPTCTL_PHYVALID 0x40000 #define NVREG_ADAPTCTL_RUNNING 0x100000 #define NVREG_ADAPTCTL_PHYSHIFT 24 NvRegMIISpeed = 0x18c, #define NVREG_MIISPEED_BIT8 (1<<8) #define NVREG_MIIDELAY 5 NvRegMIIControl = 0x190, -#define NVREG_MIICTL_INUSE 0x10000 -#define NVREG_MIICTL_WRITE 0x08000 +#define NVREG_MIICTL_INUSE 0x08000 +#define NVREG_MIICTL_WRITE 0x00400 #define NVREG_MIICTL_ADDRSHIFT 5 NvRegMIIData = 0x194, NvRegWakeUpFlags = 0x200, @@ -253,34 +268,63 @@ enum { #define NVREG_POWERSTATE_D3 0x0003 }; +/* Big endian: should work, but is untested */ struct ring_desc { u32 PacketBuffer; - u16 Length; - u16 Flags; + u32 FlagLen; }; -#define NV_TX_LASTPACKET (1<<0) -#define NV_TX_RETRYERROR (1<<3) -#define NV_TX_LASTPACKET1 (1<<8) -#define NV_TX_DEFERRED (1<<10) -#define NV_TX_CARRIERLOST (1<<11) -#define NV_TX_LATECOLLISION (1<<12) -#define NV_TX_UNDERFLOW (1<<13) -#define NV_TX_ERROR (1<<14) -#define NV_TX_VALID (1<<15) - -#define NV_RX_DESCRIPTORVALID (1<<0) -#define NV_RX_MISSEDFRAME (1<<1) -#define NV_RX_SUBSTRACT1 (1<<3) -#define NV_RX_ERROR1 (1<<7) -#define NV_RX_ERROR2 (1<<8) -#define NV_RX_ERROR3 (1<<9) -#define NV_RX_ERROR4 (1<<10) -#define NV_RX_CRCERR (1<<11) -#define NV_RX_OVERFLOW (1<<12) -#define NV_RX_FRAMINGERR (1<<13) -#define NV_RX_ERROR (1<<14) -#define NV_RX_AVAIL (1<<15) +#define FLAG_MASK_V1 0xffff0000 +#define FLAG_MASK_V2 0xffffc000 +#define LEN_MASK_V1 (0xffffffff ^ FLAG_MASK_V1) +#define LEN_MASK_V2 (0xffffffff ^ FLAG_MASK_V2) + +#define NV_TX_LASTPACKET (1<<16) +#define NV_TX_RETRYERROR (1<<19) +#define NV_TX_LASTPACKET1 (1<<24) +#define NV_TX_DEFERRED (1<<26) +#define NV_TX_CARRIERLOST (1<<27) +#define NV_TX_LATECOLLISION (1<<28) +#define NV_TX_UNDERFLOW (1<<29) +#define NV_TX_ERROR (1<<30) +#define NV_TX_VALID (1<<31) + +#define NV_TX2_LASTPACKET (1<<29) +#define NV_TX2_RETRYERROR (1<<18) +#define NV_TX2_LASTPACKET1 (1<<23) +#define NV_TX2_DEFERRED (1<<25) +#define NV_TX2_CARRIERLOST (1<<26) +#define NV_TX2_LATECOLLISION (1<<27) +#define NV_TX2_UNDERFLOW (1<<28) +/* error and valid are the same for both */ +#define NV_TX2_ERROR (1<<30) +#define NV_TX2_VALID (1<<31) + +#define NV_RX_DESCRIPTORVALID (1<<16) +#define NV_RX_MISSEDFRAME (1<<17) +#define NV_RX_SUBSTRACT1 (1<<18) +#define NV_RX_ERROR1 (1<<23) +#define NV_RX_ERROR2 (1<<24) +#define NV_RX_ERROR3 (1<<25) +#define NV_RX_ERROR4 (1<<26) +#define NV_RX_CRCERR (1<<27) +#define NV_RX_OVERFLOW (1<<28) +#define NV_RX_FRAMINGERR (1<<29) +#define NV_RX_ERROR (1<<30) +#define NV_RX_AVAIL (1<<31) + +#define NV_RX2_DESCRIPTORVALID (1<<29) +#define NV_RX2_SUBSTRACT1 (1<<25) +#define NV_RX2_ERROR1 (1<<18) +#define NV_RX2_ERROR2 (1<<19) +#define NV_RX2_ERROR3 (1<<20) +#define NV_RX2_ERROR4 (1<<21) +#define NV_RX2_CRCERR (1<<22) +#define NV_RX2_OVERFLOW (1<<23) +#define NV_RX2_FRAMINGERR (1<<24) +/* error and avail are the same for both */ +#define NV_RX2_ERROR (1<<30) +#define NV_RX2_AVAIL (1<<31) /* Miscelaneous hardware related defines: */ #define NV_PCI_REGSZ 0x270 @@ -306,28 +350,67 @@ struct ring_desc { /* General driver defaults */ #define NV_WATCHDOG_TIMEO (5*HZ) -#define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ #define RX_RING 128 -#define TX_RING 16 -/* limited to 1 packet until we understand NV_TX_LASTPACKET */ -#define TX_LIMIT_STOP 10 -#define TX_LIMIT_START 5 +#define TX_RING 64 +/* + * If your nic mysteriously hangs then try to reduce the limits + * to 1/0: It might be required to set NV_TX_LASTPACKET in the + * last valid ring entry. But this would be impossible to + * implement - probably a disassembly error. + */ +#define TX_LIMIT_STOP 63 +#define TX_LIMIT_START 62 /* rx/tx mac addr + type + vlan + align + slack*/ -#define RX_NIC_BUFSIZE (DEFAULT_MTU + 64) +#define RX_NIC_BUFSIZE (ETH_DATA_LEN + 64) /* even more slack */ -#define RX_ALLOC_BUFSIZE (DEFAULT_MTU + 128) +#define RX_ALLOC_BUFSIZE (ETH_DATA_LEN + 128) #define OOM_REFILL (1+HZ/20) #define POLL_WAIT (1+HZ/100) +#define LINK_TIMEOUT (3*HZ) + +#define DESC_VER_1 0x0 +#define DESC_VER_2 0x02100 + +/* PHY defines */ +#define PHY_OUI_MARVELL 0x5043 +#define PHY_OUI_CICADA 0x03f1 +#define PHYID1_OUI_MASK 0x03ff +#define PHYID1_OUI_SHFT 6 +#define PHYID2_OUI_MASK 0xfc00 +#define PHYID2_OUI_SHFT 10 +#define PHY_INIT1 0x0f000 +#define PHY_INIT2 0x0e00 +#define PHY_INIT3 0x01000 +#define PHY_INIT4 0x0200 +#define PHY_INIT5 0x0004 +#define PHY_INIT6 0x02000 +#define PHY_GIGABIT 0x0100 + +#define PHY_TIMEOUT 0x1 +#define PHY_ERROR 0x2 + +#define PHY_100 0x1 +#define PHY_1000 0x2 +#define PHY_HALF 0x100 + +/* FIXME: MII defines that should be added to */ +#define MII_1000BT_CR 0x09 +#define MII_1000BT_SR 0x0a +#define ADVERTISE_1000FULL 0x0200 +#define ADVERTISE_1000HALF 0x0100 +#define LPA_1000FULL 0x0800 +#define LPA_1000HALF 0x0400 + /* * SMP locking: * All hardware access under dev->priv->lock, except the performance * critical parts: * - rx is (pseudo-) lockless: it relies on the single-threading provided - * by the arch code for interrupts. + * by the arch code for interrupts. * - tx setup is lockless: it relies on dev->xmit_lock. Actual submission * needs dev->priv->lock :-( * - set_multicast_list: preparation lockless, relies on dev->xmit_lock. @@ -345,12 +428,15 @@ struct fe_priv { int duplex; int phyaddr; int wolenabled; + unsigned int phy_oui; + u16 gigabit; /* General data: RO fields */ dma_addr_t ring_addr; struct pci_dev *pci_dev; u32 orig_mac[2]; u32 irqmask; + u32 desc_ver; /* rx specific fields. * Locking: Within irq hander or disable_irq+spin_lock(&np->lock); @@ -363,6 +449,11 @@ struct fe_priv { struct timer_list oom_kick; struct timer_list nic_poll; + /* media detection workaround. + * Locking: Within irq hander or disable_irq+spin_lock(&np->lock); + */ + int need_linktimer; + unsigned long link_timeout; /* * tx specific fields. */ @@ -370,7 +461,7 @@ struct fe_priv { unsigned int next_tx, nic_tx; struct sk_buff *tx_skbuff[TX_RING]; dma_addr_t tx_dma[TX_RING]; - u16 tx_flags; + u32 tx_flags; }; /* @@ -395,6 +486,12 @@ static inline void pci_push(u8 * base) readl(base); } +static inline u32 nv_descr_getlength(struct ring_desc *prd, u32 v) +{ + return le32_to_cpu(prd->FlagLen) + & ((v == DESC_VER_1) ? LEN_MASK_V1 : LEN_MASK_V2); +} + static int reg_delay(struct net_device *dev, int offset, u32 mask, u32 target, int delay, int delaymax, const char *msg) { @@ -421,24 +518,18 @@ static int reg_delay(struct net_device * static int mii_rw(struct net_device *dev, int addr, int miireg, int value) { u8 *base = get_hwbase(dev); - int was_running; u32 reg; int retval; writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - was_running = 0; - reg = readl(base + NvRegAdapterControl); - if (reg & NVREG_ADAPTCTL_RUNNING) { - was_running = 1; - writel(reg & ~NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); - } + reg = readl(base + NvRegMIIControl); if (reg & NVREG_MIICTL_INUSE) { writel(NVREG_MIICTL_INUSE, base + NvRegMIIControl); udelay(NV_MIIBUSY_DELAY); } - reg = NVREG_MIICTL_INUSE | (addr << NVREG_MIICTL_ADDRSHIFT) | miireg; + reg = (addr << NVREG_MIICTL_ADDRSHIFT) | miireg; if (value != MII_READ) { writel(value, base + NvRegMIIData); reg |= NVREG_MIICTL_WRITE; @@ -460,19 +551,117 @@ static int mii_rw(struct net_device *dev dev->name, miireg, addr); retval = -1; } else { - /* FIXME: why is that required? */ - udelay(50); retval = readl(base + NvRegMIIData); dprintk(KERN_DEBUG "%s: mii_rw read from reg %d at PHY %d: 0x%x.\n", dev->name, miireg, addr, retval); } - if (was_running) { - reg = readl(base + NvRegAdapterControl); - writel(reg | NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); - } + return retval; } +static int phy_reset(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u32 miicontrol; + unsigned int tries = 0; + + miicontrol = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + miicontrol |= BMCR_RESET; + if (mii_rw(dev, np->phyaddr, MII_BMCR, miicontrol)) { + return -1; + } + + /* wait for 500ms */ + mdelay(500); + + /* must wait till reset is deasserted */ + while (miicontrol & BMCR_RESET) { + mdelay(10); + miicontrol = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + /* FIXME: 100 tries seem excessive */ + if (tries++ > 100) + return -1; + } + return 0; +} + +static int phy_init(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + u32 phyinterface, phy_reserved, mii_status, mii_control, mii_control_1000,reg; + + /* set advertise register */ + reg = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ); + reg |= (ADVERTISE_10HALF|ADVERTISE_10FULL|ADVERTISE_100HALF|ADVERTISE_100FULL|0x800|0x400); + if (mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg)) { + printk(KERN_INFO "%s: phy write to advertise failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + + /* get phy interface type */ + phyinterface = readl(base + NvRegPhyInterface); + + /* see if gigabit phy */ + mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + if (mii_status & PHY_GIGABIT) { + np->gigabit = PHY_GIGABIT; + mii_control_1000 = mii_rw(dev, np->phyaddr, MII_1000BT_CR, MII_READ); + mii_control_1000 &= ~ADVERTISE_1000HALF; + if (phyinterface & PHY_RGMII) + mii_control_1000 |= ADVERTISE_1000FULL; + else + mii_control_1000 &= ~ADVERTISE_1000FULL; + + if (mii_rw(dev, np->phyaddr, MII_1000BT_CR, mii_control_1000)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + } + else + np->gigabit = 0; + + /* reset the phy */ + if (phy_reset(dev)) { + printk(KERN_INFO "%s: phy reset failed\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + + /* phy vendor specific configuration */ + if ((np->phy_oui == PHY_OUI_CICADA) && (phyinterface & PHY_RGMII) ) { + phy_reserved = mii_rw(dev, np->phyaddr, MII_RESV1, MII_READ); + phy_reserved &= ~(PHY_INIT1 | PHY_INIT2); + phy_reserved |= (PHY_INIT3 | PHY_INIT4); + if (mii_rw(dev, np->phyaddr, MII_RESV1, phy_reserved)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + phy_reserved = mii_rw(dev, np->phyaddr, MII_NCONFIG, MII_READ); + phy_reserved |= PHY_INIT5; + if (mii_rw(dev, np->phyaddr, MII_NCONFIG, phy_reserved)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + } + if (np->phy_oui == PHY_OUI_CICADA) { + phy_reserved = mii_rw(dev, np->phyaddr, MII_SREVISION, MII_READ); + phy_reserved |= PHY_INIT6; + if (mii_rw(dev, np->phyaddr, MII_SREVISION, phy_reserved)) { + printk(KERN_INFO "%s: phy init failed.\n", pci_name(np->pci_dev)); + return PHY_ERROR; + } + } + + /* restart auto negotiation */ + mii_control = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ); + mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE); + if (mii_rw(dev, np->phyaddr, MII_BMCR, mii_control)) { + return PHY_ERROR; + } + + return 0; +} + static void nv_start_rx(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); @@ -487,6 +676,8 @@ static void nv_start_rx(struct net_devic writel(np->linkspeed, base + NvRegLinkSpeed); pci_push(base); writel(NVREG_RCVCTL_START, base + NvRegReceiverControl); + dprintk(KERN_DEBUG "%s: nv_start_rx to duplex %d, speed 0x%08x.\n", + dev->name, np->duplex, np->linkspeed); pci_push(base); } @@ -497,8 +688,8 @@ static void nv_stop_rx(struct net_device dprintk(KERN_DEBUG "%s: nv_stop_rx\n", dev->name); writel(0, base + NvRegReceiverControl); reg_delay(dev, NvRegReceiverStatus, NVREG_RCVSTAT_BUSY, 0, - NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX, - KERN_INFO "nv_stop_rx: ReceiverStatus remained busy"); + NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX, + KERN_INFO "nv_stop_rx: ReceiverStatus remained busy"); udelay(NV_RXSTOP_DELAY2); writel(0, base + NvRegLinkSpeed); @@ -520,8 +711,8 @@ static void nv_stop_tx(struct net_device dprintk(KERN_DEBUG "%s: nv_stop_tx\n", dev->name); writel(0, base + NvRegTransmitterControl); reg_delay(dev, NvRegTransmitterStatus, NVREG_XMITSTAT_BUSY, 0, - NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX, - KERN_INFO "nv_stop_tx: TransmitterStatus remained busy"); + NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX, + KERN_INFO "nv_stop_tx: TransmitterStatus remained busy"); udelay(NV_TXSTOP_DELAY2); writel(0, base + NvRegUnknownTransmitterReg); @@ -529,13 +720,14 @@ static void nv_stop_tx(struct net_device static void nv_txrx_reset(struct net_device *dev) { + struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); dprintk(KERN_DEBUG "%s: nv_txrx_reset\n", dev->name); - writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET, base + NvRegTxRxControl); + writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET | np->desc_ver, base + NvRegTxRxControl); pci_push(base); udelay(NV_TXRX_RESET_DELAY); - writel(NVREG_TXRXCTL_BIT2, base + NvRegTxRxControl); + writel(NVREG_TXRXCTL_BIT2 | np->desc_ver, base + NvRegTxRxControl); pci_push(base); } @@ -556,7 +748,7 @@ static struct net_device_stats *nv_get_s return &np->stats; } -static int nv_ethtool_ioctl(struct net_device *dev, void *useraddr) +static int nv_ethtool_ioctl(struct net_device *dev, void __user *useraddr) { struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); @@ -634,7 +826,7 @@ static int nv_ioctl(struct net_device *d { switch(cmd) { case SIOCETHTOOL: - return nv_ethtool_ioctl(dev, (void *) rq->ifr_data); + return nv_ethtool_ioctl(dev, rq->ifr_data); default: return -EOPNOTSUPP; @@ -650,11 +842,12 @@ static int nv_alloc_rx(struct net_device { struct fe_priv *np = get_nvpriv(dev); unsigned int refill_rx = np->refill_rx; + int nr; while (np->cur_rx != refill_rx) { - int nr = refill_rx % RX_RING; struct sk_buff *skb; + nr = refill_rx % RX_RING; if (np->rx_skbuff[nr] == NULL) { skb = dev_alloc_skb(RX_ALLOC_BUFSIZE); @@ -669,10 +862,9 @@ static int nv_alloc_rx(struct net_device np->rx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len, PCI_DMA_FROMDEVICE); np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]); - np->rx_ring[nr].Length = cpu_to_le16(RX_NIC_BUFSIZE); wmb(); - np->rx_ring[nr].Flags = cpu_to_le16(NV_RX_AVAIL); - dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", + np->rx_ring[nr].FlagLen = cpu_to_le32(RX_NIC_BUFSIZE | NV_RX_AVAIL); + dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n", dev->name, refill_rx); refill_rx++; } @@ -703,15 +895,13 @@ static int nv_init_ring(struct net_devic int i; np->next_tx = np->nic_tx = 0; - for (i = 0; i < TX_RING; i++) { - np->tx_ring[i].Flags = 0; - } + for (i = 0; i < TX_RING; i++) + np->tx_ring[i].FlagLen = 0; np->cur_rx = RX_RING; np->refill_rx = 0; - for (i = 0; i < RX_RING; i++) { - np->rx_ring[i].Flags = 0; - } + for (i = 0; i < RX_RING; i++) + np->rx_ring[i].FlagLen = 0; return nv_alloc_rx(dev); } @@ -720,7 +910,7 @@ static void nv_drain_tx(struct net_devic struct fe_priv *np = get_nvpriv(dev); int i; for (i = 0; i < TX_RING; i++) { - np->tx_ring[i].Flags = 0; + np->tx_ring[i].FlagLen = 0; if (np->tx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->tx_dma[i], np->tx_skbuff[i]->len, @@ -737,7 +927,7 @@ static void nv_drain_rx(struct net_devic struct fe_priv *np = get_nvpriv(dev); int i; for (i = 0; i < RX_RING; i++) { - np->rx_ring[i].Flags = 0; + np->rx_ring[i].FlagLen = 0; wmb(); if (np->rx_skbuff[i]) { pci_unmap_single(np->pci_dev, np->rx_dma[i], @@ -769,11 +959,10 @@ static int nv_start_xmit(struct sk_buff PCI_DMA_TODEVICE); np->tx_ring[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); - np->tx_ring[nr].Length = cpu_to_le16(skb->len-1); spin_lock_irq(&np->lock); wmb(); - np->tx_ring[nr].Flags = np->tx_flags; + np->tx_ring[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags ); dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n", dev->name, np->next_tx); { @@ -792,7 +981,7 @@ static int nv_start_xmit(struct sk_buff if (np->next_tx - np->nic_tx >= TX_LIMIT_STOP) netif_stop_queue(dev); spin_unlock_irq(&np->lock); - writel(NVREG_TXRXCTL_KICK, get_hwbase(dev) + NvRegTxRxControl); + writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl); pci_push(get_hwbase(dev)); return 0; } @@ -805,27 +994,42 @@ static int nv_start_xmit(struct sk_buff static void nv_tx_done(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); + u32 Flags; + int i; - while (np->nic_tx < np->next_tx) { - struct ring_desc *prd; - int i = np->nic_tx % TX_RING; + while (np->nic_tx != np->next_tx) { + i = np->nic_tx % TX_RING; - prd = &np->tx_ring[i]; + Flags = le32_to_cpu(np->tx_ring[i].FlagLen); dprintk(KERN_DEBUG "%s: nv_tx_done: looking at packet %d, Flags 0x%x.\n", - dev->name, np->nic_tx, prd->Flags); - if (prd->Flags & cpu_to_le16(NV_TX_VALID)) + dev->name, np->nic_tx, Flags); + if (Flags & NV_TX_VALID) break; - if (prd->Flags & cpu_to_le16(NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| - NV_TX_UNDERFLOW|NV_TX_ERROR)) { - if (prd->Flags & cpu_to_le16(NV_TX_UNDERFLOW)) - np->stats.tx_fifo_errors++; - if (prd->Flags & cpu_to_le16(NV_TX_CARRIERLOST)) - np->stats.tx_carrier_errors++; - np->stats.tx_errors++; + if (np->desc_ver == DESC_VER_1) { + if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| + NV_TX_UNDERFLOW|NV_TX_ERROR)) { + if (Flags & NV_TX_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += np->tx_skbuff[i]->len; + } } else { - np->stats.tx_packets++; - np->stats.tx_bytes += np->tx_skbuff[i]->len; + if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION| + NV_TX2_UNDERFLOW|NV_TX2_ERROR)) { + if (Flags & NV_TX2_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX2_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += np->tx_skbuff[i]->len; + } } pci_unmap_single(np->pci_dev, np->tx_dma[i], np->tx_skbuff[i]->len, @@ -875,9 +1079,9 @@ static void nv_tx_timeout(struct net_dev static void nv_rx_process(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); + u32 Flags; for (;;) { - struct ring_desc *prd; struct sk_buff *skb; int len; int i; @@ -885,11 +1089,13 @@ static void nv_rx_process(struct net_dev break; /* we scanned the whole ring - do not continue */ i = np->cur_rx % RX_RING; - prd = &np->rx_ring[i]; + Flags = le32_to_cpu(np->rx_ring[i].FlagLen); + len = nv_descr_getlength(&np->rx_ring[i], np->desc_ver); + dprintk(KERN_DEBUG "%s: nv_rx_process: looking at packet %d, Flags 0x%x.\n", - dev->name, np->cur_rx, prd->Flags); + dev->name, np->cur_rx, Flags); - if (prd->Flags & cpu_to_le16(NV_RX_AVAIL)) + if (Flags & NV_RX_AVAIL) break; /* still owned by hardware, */ /* @@ -903,7 +1109,7 @@ static void nv_rx_process(struct net_dev { int j; - dprintk(KERN_DEBUG "Dumping packet (flags 0x%x).",prd->Flags); + dprintk(KERN_DEBUG "Dumping packet (flags 0x%x).",Flags); for (j=0; j<64; j++) { if ((j%16) == 0) dprintk("\n%03x:", j); @@ -912,41 +1118,69 @@ static void nv_rx_process(struct net_dev dprintk("\n"); } /* look at what we actually got: */ - if (!(prd->Flags & cpu_to_le16(NV_RX_DESCRIPTORVALID))) - goto next_pkt; - - - len = le16_to_cpu(prd->Length); + if (np->desc_ver == DESC_VER_1) { + if (!(Flags & NV_RX_DESCRIPTORVALID)) + goto next_pkt; - if (prd->Flags & cpu_to_le16(NV_RX_MISSEDFRAME)) { - np->stats.rx_missed_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_CRCERR)) { - np->stats.rx_crc_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_OVERFLOW)) { - np->stats.rx_over_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (prd->Flags & cpu_to_le16(NV_RX_ERROR)) { - /* framing errors are soft errors, the rest is fatal. */ - if (prd->Flags & cpu_to_le16(NV_RX_FRAMINGERR)) { - if (prd->Flags & cpu_to_le16(NV_RX_SUBSTRACT1)) { - len--; + if (Flags & NV_RX_MISSEDFRAME) { + np->stats.rx_missed_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & (NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_CRCERR) { + np->stats.rx_crc_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_OVERFLOW) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_ERROR) { + /* framing errors are soft errors, the rest is fatal. */ + if (Flags & NV_RX_FRAMINGERR) { + if (Flags & NV_RX_SUBSTRACT1) { + len--; + } + } else { + np->stats.rx_errors++; + goto next_pkt; } - } else { + } + } else { + if (!(Flags & NV_RX2_DESCRIPTORVALID)) + goto next_pkt; + + if (Flags & (NV_RX2_ERROR1|NV_RX2_ERROR2|NV_RX2_ERROR3|NV_RX2_ERROR4)) { + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX2_CRCERR) { + np->stats.rx_crc_errors++; np->stats.rx_errors++; goto next_pkt; } + if (Flags & NV_RX2_OVERFLOW) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX2_ERROR) { + /* framing errors are soft errors, the rest is fatal. */ + if (Flags & NV_RX2_FRAMINGERR) { + if (Flags & NV_RX2_SUBSTRACT1) { + len--; + } + } else { + np->stats.rx_errors++; + goto next_pkt; + } + } } /* got a valid packet - forward it to the network core */ skb = np->rx_skbuff[i]; @@ -971,7 +1205,7 @@ next_pkt: */ static int nv_change_mtu(struct net_device *dev, int new_mtu) { - if (new_mtu > DEFAULT_MTU) + if (new_mtu > ETH_DATA_LEN) return -EINVAL; dev->mtu = new_mtu; return 0; @@ -1035,6 +1269,8 @@ static void nv_set_multicast(struct net_ writel(mask[0], base + NvRegMulticastMaskA); writel(mask[1], base + NvRegMulticastMaskB); writel(pff, base + NvRegPacketFilterFlags); + dprintk(KERN_INFO "%s: reconfiguration for multicast lists.\n", + dev->name); nv_start_rx(dev); spin_unlock_irq(&np->lock); } @@ -1042,16 +1278,62 @@ static void nv_set_multicast(struct net_ static int nv_update_linkspeed(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); - int adv, lpa, newls, newdup; + u8 *base = get_hwbase(dev); + int adv, lpa; + int newls = np->linkspeed; + int newdup = np->duplex; + int mii_status; + int retval = 0; + u32 control_1000, status_1000, phyreg; + + /* BMSR_LSTATUS is latched, read it twice: + * we want the current value. + */ + mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + mii_status = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + + if (!(mii_status & BMSR_LSTATUS)) { + dprintk(KERN_DEBUG "%s: no link detected by phy - falling back to 10HD.\n", + dev->name); + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 0; + retval = 0; + goto set_speed; + } + + /* check auto negotiation is complete */ + if (!(mii_status & BMSR_ANEGCOMPLETE)) { + /* still in autonegotiation - configure nic for 10 MBit HD and wait. */ + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 0; + retval = 0; + dprintk(KERN_DEBUG "%s: autoneg not completed - falling back to 10HD.\n", dev->name); + goto set_speed; + } + + retval = 1; + if (np->gigabit == PHY_GIGABIT) { + control_1000 = mii_rw(dev, np->phyaddr, MII_1000BT_CR, MII_READ); + status_1000 = mii_rw(dev, np->phyaddr, MII_1000BT_SR, MII_READ); + + if ((control_1000 & ADVERTISE_1000FULL) && + (status_1000 & LPA_1000FULL)) { + dprintk(KERN_DEBUG "%s: nv_update_linkspeed: GBit ethernet detected.\n", + dev->name); + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_1000; + newdup = 1; + goto set_speed; + } + } adv = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ); lpa = mii_rw(dev, np->phyaddr, MII_LPA, MII_READ); dprintk(KERN_DEBUG "%s: nv_update_linkspeed: PHY advertises 0x%04x, lpa 0x%04x.\n", dev->name, adv, lpa); - /* FIXME: handle parallel detection properly, handle gigabit ethernet */ + /* FIXME: handle parallel detection properly */ lpa = lpa & adv; - if (lpa & LPA_100FULL) { + if (lpa & LPA_100FULL) { newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100; newdup = 1; } else if (lpa & LPA_100HALF) { @@ -1068,37 +1350,57 @@ static int nv_update_linkspeed(struct ne newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; newdup = 0; } - if (np->duplex != newdup || np->linkspeed != newls) { - np->duplex = newdup; - np->linkspeed = newls; - return 1; - } - return 0; -} -static void nv_link_irq(struct net_device *dev) -{ - struct fe_priv *np = get_nvpriv(dev); - u8 *base = get_hwbase(dev); - u32 miistat; - int miival; +set_speed: + if (np->duplex == newdup && np->linkspeed == newls) + return retval; + + dprintk(KERN_INFO "%s: changing link setting from %d/%d to %d/%d.\n", + dev->name, np->linkspeed, np->duplex, newls, newdup); + + np->duplex = newdup; + np->linkspeed = newls; + + if (np->gigabit == PHY_GIGABIT) { + phyreg = readl(base + NvRegRandomSeed); + phyreg &= ~(0x3FF00); + if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_10) + phyreg |= NVREG_RNDSEED_FORCE3; + else if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_100) + phyreg |= NVREG_RNDSEED_FORCE2; + else if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_1000) + phyreg |= NVREG_RNDSEED_FORCE; + writel(phyreg, base + NvRegRandomSeed); + } + + phyreg = readl(base + NvRegPhyInterface); + phyreg &= ~(PHY_HALF|PHY_100|PHY_1000); + if (np->duplex == 0) + phyreg |= PHY_HALF; + if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_100) + phyreg |= PHY_100; + else if ((np->linkspeed & 0xFFF) == NVREG_LINKSPEED_1000) + phyreg |= PHY_1000; + writel(phyreg, base + NvRegPhyInterface); - miistat = readl(base + NvRegMIIStatus); - writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); - printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), + base + NvRegMisc1); + pci_push(base); + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); - miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); - if (miival & BMSR_ANEGCOMPLETE) { - nv_update_linkspeed(dev); + return retval; +} +static void nv_linkchange(struct net_device *dev) +{ + if (nv_update_linkspeed(dev)) { if (netif_carrier_ok(dev)) { nv_stop_rx(dev); } else { netif_carrier_on(dev); printk(KERN_INFO "%s: link up.\n", dev->name); } - writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), - base + NvRegMisc1); nv_start_rx(dev); } else { if (netif_carrier_ok(dev)) { @@ -1106,11 +1408,23 @@ static void nv_link_irq(struct net_devic printk(KERN_INFO "%s: link down.\n", dev->name); nv_stop_rx(dev); } - writel(np->linkspeed, base + NvRegLinkSpeed); - pci_push(base); } } +static void nv_link_irq(struct net_device *dev) +{ + u8 *base = get_hwbase(dev); + u32 miistat; + + miistat = readl(base + NvRegMIIStatus); + writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); + dprintk(KERN_INFO "%s: link change irq, status 0x%x.\n", dev->name, miistat); + + if (miistat & (NVREG_MIISTAT_LINKCHANGE)) + nv_linkchange(dev); + dprintk(KERN_DEBUG "%s: link change notification done.\n", dev->name); +} + static irqreturn_t nv_nic_irq(int foo, void *data, struct pt_regs *regs) { struct net_device *dev = (struct net_device *) data; @@ -1135,7 +1449,7 @@ static irqreturn_t nv_nic_irq(int foo, v spin_unlock(&np->lock); } - if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { + if (events & (NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { nv_rx_process(dev); if (nv_alloc_rx(dev)) { spin_lock(&np->lock); @@ -1150,6 +1464,12 @@ static irqreturn_t nv_nic_irq(int foo, v nv_link_irq(dev); spin_unlock(&np->lock); } + if (np->need_linktimer && time_after(jiffies, np->link_timeout)) { + spin_lock(&np->lock); + nv_linkchange(dev); + spin_unlock(&np->lock); + np->link_timeout = jiffies + LINK_TIMEOUT; + } if (events & (NVREG_IRQ_TX_ERR)) { dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n", dev->name, events); @@ -1157,7 +1477,7 @@ static irqreturn_t nv_nic_irq(int foo, v if (events & (NVREG_IRQ_UNKNOWN)) { printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n", dev->name, events); - } + } if (i > max_interrupt_work) { spin_lock(&np->lock); /* disable interrupts on the nic */ @@ -1210,21 +1530,27 @@ static int nv_open(struct net_device *de writel(0, base + NvRegMulticastMaskA); writel(0, base + NvRegMulticastMaskB); writel(0, base + NvRegPacketFilterFlags); + + writel(0, base + NvRegTransmitterControl); + writel(0, base + NvRegReceiverControl); + writel(0, base + NvRegAdapterControl); + + /* 2) initialize descriptor rings */ + oom = nv_init_ring(dev); + writel(0, base + NvRegLinkSpeed); writel(0, base + NvRegUnknownTransmitterReg); nv_txrx_reset(dev); writel(0, base + NvRegUnknownSetupReg6); - /* 2) initialize descriptor rings */ np->in_shutdown = 0; - oom = nv_init_ring(dev); /* 3) set mac address */ { u32 mac[2]; - mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) + + mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) + (dev->dev_addr[2] << 16) + (dev->dev_addr[3] << 24); mac[1] = (dev->dev_addr[4] << 0) + (dev->dev_addr[5] << 8); @@ -1232,53 +1558,31 @@ static int nv_open(struct net_device *de writel(mac[1], base + NvRegMacAddrB); } - /* 4) continue setup */ + /* 4) give hw rings */ + writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr); + writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); + writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT), + base + NvRegRingSizes); + + /* 5) continue setup */ np->linkspeed = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; np->duplex = 0; + + writel(np->linkspeed, base + NvRegLinkSpeed); writel(NVREG_UNKSETUP3_VAL1, base + NvRegUnknownSetupReg3); - writel(0, base + NvRegTxRxControl); + writel(np->desc_ver, base + NvRegTxRxControl); pci_push(base); - writel(NVREG_TXRXCTL_BIT1, base + NvRegTxRxControl); + writel(NVREG_TXRXCTL_BIT1|np->desc_ver, base + NvRegTxRxControl); reg_delay(dev, NvRegUnknownSetupReg5, NVREG_UNKSETUP5_BIT31, NVREG_UNKSETUP5_BIT31, NV_SETUP5_DELAY, NV_SETUP5_DELAYMAX, KERN_INFO "open: SetupReg5, Bit 31 remained off\n"); - writel(0, base + NvRegUnknownSetupReg4); - - /* 5) Find a suitable PHY */ - writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed); - for (i = 1; i < 32; i++) { - int id1, id2; - - spin_lock_irq(&np->lock); - id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ); - spin_unlock_irq(&np->lock); - if (id1 < 0 || id1 == 0xffff) - continue; - spin_lock_irq(&np->lock); - id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ); - spin_unlock_irq(&np->lock); - if (id2 < 0 || id2 == 0xffff) - continue; - dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n", - dev->name, id1, id2, i); - np->phyaddr = i; - - spin_lock_irq(&np->lock); - nv_update_linkspeed(dev); - spin_unlock_irq(&np->lock); - break; - } - if (i == 32) { - printk(KERN_INFO "%s: open: failing due to lack of suitable PHY.\n", - dev->name); - ret = -EINVAL; - goto out_drain; - } + writel(0, base + NvRegUnknownSetupReg4); + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); + writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus); /* 6) continue setup */ - writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), - base + NvRegMisc1); + writel(NVREG_MISC1_FORCE | NVREG_MISC1_HD, base + NvRegMisc1); writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus); writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags); writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig); @@ -1290,17 +1594,12 @@ static int nv_open(struct net_device *de writel(NVREG_UNKSETUP2_VAL, base + NvRegUnknownSetupReg2); writel(NVREG_POLL_DEFAULT, base + NvRegPollingInterval); writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6); - writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID, + writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID|NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); + writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed); writel(NVREG_UNKSETUP4_VAL, base + NvRegUnknownSetupReg4); writel(NVREG_WAKEUPFLAGS_VAL, base + NvRegWakeUpFlags); - /* 7) start packet processing */ - writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr); - writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); - writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT), - base + NvRegRingSizes); - i = readl(base + NvRegPowerState); if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0) writel(NVREG_POWERSTATE_POWEREDUP|i, base + NvRegPowerState); @@ -1308,13 +1607,9 @@ static int nv_open(struct net_device *de pci_push(base); udelay(10); writel(readl(base + NvRegPowerState) | NVREG_POWERSTATE_VALID, base + NvRegPowerState); - writel(NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); - writel(0, base + NvRegIrqMask); pci_push(base); - writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); - pci_push(base); writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus); writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); pci_push(base); @@ -1323,6 +1618,7 @@ static int nv_open(struct net_device *de if (ret) goto out_drain; + /* ask for interrupts */ writel(np->irqmask, base + NvRegIrqMask); spin_lock_irq(&np->lock); @@ -1331,18 +1627,27 @@ static int nv_open(struct net_device *de writel(0, base + NvRegMulticastMaskA); writel(0, base + NvRegMulticastMaskB); writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags); + /* One manual link speed update: Interrupts are enabled, future link + * speed changes cause interrupts and are handled by nv_link_irq(). + */ + { + u32 miistat; + miistat = readl(base + NvRegMIIStatus); + writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); + dprintk(KERN_INFO "startup: got 0x%08x.\n", miistat); + } + ret = nv_update_linkspeed(dev); nv_start_rx(dev); nv_start_tx(dev); netif_start_queue(dev); - if (oom) - mod_timer(&np->oom_kick, jiffies + OOM_REFILL); - if (mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE) { + if (ret) { netif_carrier_on(dev); } else { printk("%s: no link during initialization.\n", dev->name); netif_carrier_off(dev); } - + if (oom) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); spin_unlock_irq(&np->lock); return 0; @@ -1406,7 +1711,6 @@ static int __devinit nv_probe(struct pci np->pci_dev = pci_dev; spin_lock_init(&np->lock); SET_MODULE_OWNER(dev); - SET_NETDEV_DEV(dev, &pci_dev->dev); init_timer(&np->oom_kick); np->oom_kick.data = (unsigned long) dev; @@ -1424,7 +1728,7 @@ static int __devinit nv_probe(struct pci pci_set_master(pci_dev); - err = pci_request_regions(pci_dev, dev->name); + err = pci_request_regions(pci_dev, DRV_NAME); if (err < 0) goto out_disable; @@ -1447,6 +1751,14 @@ static int __devinit nv_probe(struct pci goto out_relreg; } + /* handle different descriptor versions */ + if (pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_1 || + pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 || + pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3) + np->desc_ver = DESC_VER_1; + else + np->desc_ver = DESC_VER_2; + err = -ENOMEM; dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ); if (!dev->base_addr) @@ -1506,15 +1818,65 @@ static int __devinit nv_probe(struct pci writel(0, base + NvRegWakeUpFlags); np->wolenabled = 0; - np->tx_flags = cpu_to_le16(NV_TX_LASTPACKET|NV_TX_LASTPACKET1|NV_TX_VALID); - if (id->driver_data & DEV_NEED_LASTPACKET1) - np->tx_flags |= cpu_to_le16(NV_TX_LASTPACKET1); + if (np->desc_ver == DESC_VER_1) { + np->tx_flags = NV_TX_LASTPACKET|NV_TX_VALID; + if (id->driver_data & DEV_NEED_LASTPACKET1) + np->tx_flags |= NV_TX_LASTPACKET1; + } else { + np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID; + if (id->driver_data & DEV_NEED_LASTPACKET1) + np->tx_flags |= NV_TX2_LASTPACKET1; + } if (id->driver_data & DEV_IRQMASK_1) np->irqmask = NVREG_IRQMASK_WANTED_1; if (id->driver_data & DEV_IRQMASK_2) np->irqmask = NVREG_IRQMASK_WANTED_2; if (id->driver_data & DEV_NEED_TIMERIRQ) np->irqmask |= NVREG_IRQ_TIMER; + if (id->driver_data & DEV_NEED_LINKTIMER) { + dprintk(KERN_INFO "%s: link timer on.\n", pci_name(pci_dev)); + np->need_linktimer = 1; + np->link_timeout = jiffies + LINK_TIMEOUT; + } else { + dprintk(KERN_INFO "%s: link timer off.\n", pci_name(pci_dev)); + np->need_linktimer = 0; + } + + /* find a suitable phy */ + for (i = 1; i < 32; i++) { + int id1, id2; + + spin_lock_irq(&np->lock); + id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ); + spin_unlock_irq(&np->lock); + if (id1 < 0 || id1 == 0xffff) + continue; + spin_lock_irq(&np->lock); + id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ); + spin_unlock_irq(&np->lock); + if (id2 < 0 || id2 == 0xffff) + continue; + + id1 = (id1 & PHYID1_OUI_MASK) << PHYID1_OUI_SHFT; + id2 = (id2 & PHYID2_OUI_MASK) >> PHYID2_OUI_SHFT; + dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n", + pci_name(pci_dev), id1, id2, i); + np->phyaddr = i; + np->phy_oui = id1 | id2; + break; + } + if (i == 32) { + /* PHY in isolate mode? No phy attached and user wants to + * test loopback? Very odd, but can be correct. + */ + printk(KERN_INFO "%s: open: Could not find a valid PHY.\n", + pci_name(pci_dev)); + } + + if (i != 32) { + /* reset it */ + phy_init(dev); + } err = register_netdev(dev); if (err) { @@ -1569,21 +1931,77 @@ static void __devexit nv_remove(struct p static struct pci_device_id pci_tbl[] = { { /* nForce Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x1C3, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_1, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ, + .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER, }, { /* nForce2 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x0066, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_2, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_3, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_4, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, }, { /* nForce3 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, - .device = 0x00D6, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_5, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_6, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_7, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* CK804 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_8, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* CK804 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_9, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* MCP04 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_10, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* MCP04 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = PCI_DEVICE_ID_NVIDIA_NVENET_11, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, @@ -1612,7 +2030,7 @@ static void __exit exit_nic(void) MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM_DESC(max_interrupt_work, "forcedeth maximum events handled per interrupt"); - + MODULE_AUTHOR("Manfred Spraul "); MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver"); MODULE_LICENSE("GPL"); --- 2.4/include/linux/pci_ids.h 2004-09-05 12:19:08.000000000 +0200 +++ build-2.4/include/linux/pci_ids.h 2004-09-05 14:34:14.043803399 +0200 @@ -981,21 +981,31 @@ #define PCI_DEVICE_ID_NVIDIA_UVTNT2 0x002D #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_IDE 0x0035 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SATA 0x0036 +#define PCI_DEVICE_ID_NVIDIA_NVENET_10 0x0037 +#define PCI_DEVICE_ID_NVIDIA_NVENET_11 0x0038 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP04_SATA2 0x003e #define PCI_DEVICE_ID_NVIDIA_NFORCE_CK804_IDE 0x0053 #define PCI_DEVICE_ID_NVIDIA_NFORCE_CK804_SATA 0x0054 #define PCI_DEVICE_ID_NVIDIA_NFORCE_CK804_SATA2 0x0055 +#define PCI_DEVICE_ID_NVIDIA_NVENET_8 0x0056 +#define PCI_DEVICE_ID_NVIDIA_NVENET_9 0x0057 #define PCI_DEVICE_ID_NVIDIA_NFORCE2_IDE 0x0065 +#define PCI_DEVICE_ID_NVIDIA_NVENET_2 0x0066 #define PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO 0x006a #define PCI_DEVICE_ID_NVIDIA_NFORCE2S_IDE 0x0085 +#define PCI_DEVICE_ID_NVIDIA_NVENET_4 0x0086 +#define PCI_DEVICE_ID_NVIDIA_NVENET_5 0x008c #define PCI_DEVICE_ID_NVIDIA_NFORCE2S_SATA 0x008e #define PCI_DEVICE_ID_NVIDIA_ITNT2 0x00A0 #define PCI_DEVICE_ID_NVIDIA_NFORCE3 0x00d1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3_IDE 0x00d5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_3 0x00d5 #define PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO 0x00da +#define PCI_DEVICE_ID_NVIDIA_NVENET_7 0x00df #define PCI_DEVICE_ID_NVIDIA_NFORCE3S 0x00e1 #define PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA 0x00e3 #define PCI_DEVICE_ID_NVIDIA_NFORCE3S_IDE 0x00e5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_6 0x00e6 #define PCI_DEVICE_ID_NVIDIA_NFORCE3S_SATA2 0x00ee #define PCI_DEVICE_ID_NVIDIA_GEFORCE_SDR 0x0100 #define PCI_DEVICE_ID_NVIDIA_GEFORCE_DDR 0x0101 @@ -1012,6 +1022,7 @@ #define PCI_DEVICE_ID_NVIDIA_NFORCE 0x01a4 #define PCI_DEVICE_ID_NVIDIA_MCP1_AUDIO 0x01b1 #define PCI_DEVICE_ID_NVIDIA_NFORCE_IDE 0x01bc +#define PCI_DEVICE_ID_NVIDIA_NVENET_1 0x01c3 #define PCI_DEVICE_ID_NVIDIA_NFORCE2 0x01e0 #define PCI_DEVICE_ID_NVIDIA_GEFORCE3 0x0200 #define PCI_DEVICE_ID_NVIDIA_GEFORCE3_1 0x0201 From linux_lover2004@yahoo.com Sun Sep 5 06:41:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 06:41:15 -0700 (PDT) Received: from web52202.mail.yahoo.com (web52202.mail.yahoo.com [206.190.39.84]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i85DfA30000543 for ; Sun, 5 Sep 2004 06:41:10 -0700 Message-ID: <20040905134056.87431.qmail@web52202.mail.yahoo.com> Received: from [66.218.69.220] by web52202.mail.yahoo.com via HTTP; Sun, 05 Sep 2004 06:40:56 PDT Date: Sun, 5 Sep 2004 06:40:56 -0700 (PDT) From: linux lover Subject: Skbuff modification To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Hello, can it be possible to add a my own structure to skbuff structure, so that it will also be send with packet on network? Regards, linux lover __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From linux_lover2004@yahoo.com Sun Sep 5 06:40:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 06:40:21 -0700 (PDT) Received: from web52201.mail.yahoo.com (web52201.mail.yahoo.com [206.190.39.83]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i85DeGsu000449 for ; Sun, 5 Sep 2004 06:40:17 -0700 Message-ID: <20040905134002.41285.qmail@web52201.mail.yahoo.com> Received: from [66.218.69.220] by web52201.mail.yahoo.com via HTTP; Sun, 05 Sep 2004 06:40:02 PDT Date: Sun, 5 Sep 2004 06:40:02 -0700 (PDT) From: linux lover Subject: Skbuff modification To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Hello, can it be possible to add a my own structure to skbuff structure, so that it will also be send with packet on network? Regards, linux lover __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From khc@pm.waw.pl Sun Sep 5 07:21:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 07:21:12 -0700 (PDT) Received: from inx.pm.waw.pl (IDENT:m289MuBeM+kxjLD6Nb2shH9aHL4dI/6o@inx.pm.waw.pl [195.116.170.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85EL6nq001800 for ; Sun, 5 Sep 2004 07:21:06 -0700 Received: from defiant.pm.waw.pl (qr224.warszawa.cvx.ppp.tpnet.pl [217.99.27.224]) by inx.pm.waw.pl (Postfix) with ESMTP id 92540E0E1; Sun, 5 Sep 2004 16:19:27 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id E00E9302D5; Sun, 5 Sep 2004 16:19:59 +0200 (CEST) To: Jeff Garzik , marcelo.tosatti@cyclades.com, Subject: fix for integer overflow in hd6457[02] driver code From: Krzysztof Halasa Date: Sun, 05 Sep 2004 16:19:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Hi, The attached patch fixes an integer overflow in drivers for N2, C101, PCI200SYN WAN cards (brv * port->settings.clock_rate overflowed at requested clock rate of 8*1024*1024 bps, problem noted by Nagaraj Kanniah). Please apply to 2.4 and 2.6 kernel trees. Thanks. -- Krzysztof Halasa From khc@pm.waw.pl Sun Sep 5 07:27:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 07:27:41 -0700 (PDT) Received: from inx.pm.waw.pl (IDENT:D/MleOFHhP+CevyBUcJGYBBEOvD4vRJd@inx.pm.waw.pl [195.116.170.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85ERW1E002193 for ; Sun, 5 Sep 2004 07:27:35 -0700 Received: from defiant.pm.waw.pl (qr224.warszawa.cvx.ppp.tpnet.pl [217.99.27.224]) by inx.pm.waw.pl (Postfix) with ESMTP id A1337E0E1; Sun, 5 Sep 2004 16:25:54 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 71FD9302D5; Sun, 5 Sep 2004 16:26:26 +0200 (CEST) To: Jeff Garzik , marcelo.tosatti@cyclades.com, Subject: [PATCH] fix for integer overflow in hd6457[02] driver code From: Krzysztof Halasa Date: Sun, 05 Sep 2004 16:26:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 8426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev --=-=-= Hi, The attached patch fixes an integer overflow in drivers for N2, C101, PCI200SYN WAN cards (brv * port->settings.clock_rate overflowed at requested clock rate of 8*1024*1024 bps, problem noted by Nagaraj Kanniah). Please apply to 2.4 and 2.6 kernel trees. Thanks. [now the patch has made it here] -- Krzysztof Halasa --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=hd6457x-speed-fix.patch --- linux-2.6/drivers/net/wan/hd6457x.c 1 Jun 2004 03:47:44 -0000 +++ linux-2.6/drivers/net/wan/hd6457x.c 5 Sep 2004 13:59:22 -0000 @@ -463,8 +463,8 @@ brv >>= 1; /* brv = 2^9 = 512 max in specs */ /* Baud Rate = CLOCK_BASE / TMC / 2^BR */ - tmc = CLOCK_BASE / (brv * port->settings.clock_rate); - }while(br > 1 && tmc <= 128); + tmc = CLOCK_BASE / brv / port->settings.clock_rate; + }while (br > 1 && tmc <= 128); if (tmc < 1) { tmc = 1; @@ -473,7 +473,7 @@ } else if (tmc > 255) tmc = 256; /* tmc=0 means 256 - low baud rates */ - port->settings.clock_rate = CLOCK_BASE / (brv * tmc); + port->settings.clock_rate = CLOCK_BASE / brv / tmc; } else { br = 9; /* Minimum clock rate */ tmc = 256; /* 8bit = 0 */ --=-=-=-- From jeffpc@optonline.net Sun Sep 5 09:20:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 09:20:06 -0700 (PDT) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.5.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85GJwnP007097 for ; Sun, 5 Sep 2004 09:20:01 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta5.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3K00JJCTD1X1@mta5.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Sun, 05 Sep 2004 12:19:50 -0400 (EDT) Date: Sun, 05 Sep 2004 12:19:34 -0400 From: Jeff Sipek Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system In-reply-to: <1094303999.1633.116.camel@jzny.localdomain> To: hadi@cyberus.ca Cc: Stephen Hemminger , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Message-id: <200409051219.47590.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> <200409031744.32970.jeffpc@optonline.net> <1094303999.1633.116.camel@jzny.localdomain> X-archive-position: 8427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 04 September 2004 09:19, jamal wrote: > I have a feeling this was discussed somewhere(other than netdev) and i > missed it. Why isnt this watch64 being done in user space? There was a discussion about 64-bit network statistics about a year ago on lkml. watch64 is a generic so that anyone in the kernel can use it. Jeff. - -- Mankind invented the atomic bomb, but no mouse would ever construct a mousetrap. - Albert Einstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBOzybwFP0+seVj/4RArmhAKC3ddX4ZGoAMQKxGplXqqbER9BBMQCfencW wDt06dC8MifG9NU3xWx0ULo= =z9kC -----END PGP SIGNATURE----- From jgarzik@pobox.com Sun Sep 5 13:10:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 13:10:17 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85KACOX014018 for ; Sun, 5 Sep 2004 13:10:13 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C43Ks-0002Ph-It; Sun, 05 Sep 2004 21:10:02 +0100 Message-ID: <413B728D.7000902@pobox.com> Date: Sun, 05 Sep 2004 16:09:49 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: [PATCH 0/6 linux-2.6.9-rc1/linux-2.4.28-pre2] prism54 patches resend References: <200409051158.59976.margitsw@t-online.de> In-Reply-To: <200409051158.59976.margitsw@t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied 2.4 sync-up patch, and the series 1-6 to 2.4 and 2.6. only patch #1 went into net-drivers-2.[46] for immediate queueing, the rest went into netdev-2.[46] (and thus -mm) for further testing of new features. Jeff From herbert@gondor.apana.org.au Sun Sep 5 15:05:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 15:05:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85M5Jrk015961 for ; Sun, 5 Sep 2004 15:05:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C456w-0001KV-00; Mon, 06 Sep 2004 08:03:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C456r-0003Ri-00; Mon, 06 Sep 2004 08:03:41 +1000 Date: Mon, 6 Sep 2004 08:03:41 +1000 To: Andi Kleen Cc: davem@redhat.com, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [PATCH] Do less atomic count changes in dev_queue_xmit Message-ID: <20040905220341.GA13217@gondor.apana.org.au> References: <20040904135439.GA23934@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040904135439.GA23934@wotan.suse.de> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sat, Sep 04, 2004 at 01:54:39PM +0000, Andi Kleen wrote: > > diff -u linux-2.6.8/net/core/dev.c-o linux-2.6.8/net/core/dev.c > --- linux-2.6.8/net/core/dev.c-o 2004-09-04 13:10:47.000000000 +0000 > +++ linux-2.6.8/net/core/dev.c 2004-09-04 13:47:16.765722813 +0000 > @@ -1249,14 +1249,14 @@ > return 0; > } > > -#define HARD_TX_LOCK_BH(dev, cpu) { \ > +#define HARD_TX_LOCK(dev, cpu) { \ > if ((dev->features & NETIF_F_LLTX) == 0) { \ > spin_lock_bh(&dev->xmit_lock); \ You can remove the _bh here as well. > @@ -1358,12 +1361,11 @@ > Either shot noqueue qdisc, it is even simpler 8) > */ > if (dev->flags & IFF_UP) { > - int cpu = get_cpu(); > + int cpu = smp_processor_id(); /* ok because BHs are off */ Hmm this means that the loopback xmit function will now execute with BH/preempt turned off. Is this what we want? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dr@cluenet.de Sun Sep 5 16:02:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 16:02:34 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [195.20.121.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i85N2Shb016954 for ; Sun, 5 Sep 2004 16:02:29 -0700 Received: by mail1.cluenet.de (Postfix, from userid 500) id 4D946178A4; Mon, 6 Sep 2004 01:02:19 +0200 (CEST) Date: Mon, 6 Sep 2004 01:02:19 +0200 From: Daniel Roesen To: Paul Jakma Cc: lkml@einar-lueck.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head Message-ID: <20040905230219.GA24688@srv01.cluenet.de> Mail-Followup-To: Paul Jakma , lkml@einar-lueck.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200409011441.10154.elueck@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 8430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dr@cluenet.de Precedence: bulk X-list: netdev On Thu, Sep 02, 2004 at 05:22:01PM +0100, Paul Jakma wrote: > ip route add default via src Sitenote: unfortunately, "src <...>" doesn't work for IPv6 routes, at least in 2.4 -- can someone confirm this problem to still exist in current 2.6? Copying netdev for the record. Regards, Daniel From davem@davemloft.net Sun Sep 5 20:24:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 20:24:44 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i863ObW2030035 for ; Sun, 5 Sep 2004 20:24:38 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4A59-0006R0-00; Sun, 05 Sep 2004 20:22:15 -0700 Date: Sun, 5 Sep 2004 20:22:15 -0700 From: "David S. Miller" To: Daniel Roesen Cc: paul@clubi.ie, lkml@einar-lueck.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] net/ipv4 for Source VIPA support, kernel BK Head Message-Id: <20040905202215.5ed8bf5f.davem@davemloft.net> In-Reply-To: <20040905230219.GA24688@srv01.cluenet.de> References: <200409011441.10154.elueck@de.ibm.com> <20040905230219.GA24688@srv01.cluenet.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 6 Sep 2004 01:02:19 +0200 Daniel Roesen wrote: > On Thu, Sep 02, 2004 at 05:22:01PM +0100, Paul Jakma wrote: > > ip route add default via src > > Sitenote: unfortunately, "src <...>" doesn't work for IPv6 routes, at > least in 2.4 -- can someone confirm this problem to still exist in > current 2.6? That's right, no routing by source in ipv6 yet, the folks working with the USAGI guys on MIPV6 support will add the feature. From glen.turner@aarnet.edu.au Sun Sep 5 21:19:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 05 Sep 2004 21:19:49 -0700 (PDT) Received: from clix.aarnet.edu.au (clix.aarnet.edu.au [192.94.63.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i864JduA031291 for ; Sun, 5 Sep 2004 21:19:40 -0700 Received: from [202.158.193.5] (andromache.adelaide.aarnet.edu.au [202.158.193.5]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id i864JTCS018371 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 6 Sep 2004 14:19:29 +1000 Subject: DHCP and jumbo frames From: Glen Turner To: netdev@oss.sgi.com Content-Type: text/plain Organization: Australian Academic and Research Network Message-Id: <1094444369.22662.32.camel@andromache> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 06 Sep 2004 13:49:29 +0930 Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glen.turner@aarnet.edu.au Precedence: bulk X-list: netdev Hi folks, I'm trying to make DHCP work correctly for ethernet jumbo frame media and jumbo+standard MTU subnets on jumbo media. It's turning into a bit of a long slog (RFC amendments, etc), but jumbo frames will never seen widespread host deployment without it. It turns out that the DHCP client has to be able to select from a range of potential DHCP offers (all else equal it should select the offer with the largest MTU) and has to be able to reject an offer with an MTU the hardware cannot support. Setting the MTU often re-sets the ethernet controller (as far as I can tell from the e1000 source). So checking each DHCP offer by attempting to write the MTU to the hardware isn't going to work well. Especially if an ethernet controller reset causes the PHY to drop carrier, as spanning tree hold-downs could then cause the DHCP state machine to time out. Is there any way for the DHCP client to query every interface for the MTU size ranges that the interface supports? Advice is very appreciated, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From nakam@linux-ipv6.org Mon Sep 6 00:47:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 00:48:02 -0700 (PDT) Received: from mail206.noc.n-bone.net (mail2.noc.n-bone.net [138.243.50.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i867lvo4006504 for ; Mon, 6 Sep 2004 00:47:58 -0700 Received: from localhost (unknown [203.178.140.10]) by mail206.noc.n-bone.net (NBONE-MTA) with ESMTP id 49801A85; Mon, 6 Sep 2004 16:47:43 +0900 (JST) Date: Mon, 6 Sep 2004 16:47:42 +0900 From: Masahide Nakamura To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, nakam@linux-ipv6.org Subject: [PATCH] [iproute2] XFRM: support ICMP/ICMPv6's type and code Message-Id: <20040906164742.54795bf4@localhost> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev This patch supports ICMP/ICMPv6's type and code in IPsec selector. Kernel has supported this feature from 2.6.9-rc1. The ChangeSet is also available at: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/01 14:45:04+09:00 nakam@linux-ipv6.org # support ICMP and ICMPv6's type/code for IPsec. # # ip/xfrm_state.c # 2004/09/01 14:44:59+09:00 nakam@linux-ipv6.org +3 -1 # fix usage. # # ip/xfrm_policy.c # 2004/09/01 14:44:59+09:00 nakam@linux-ipv6.org +2 -1 # fix usage. # # ip/ipxfrm.c # 2004/09/01 14:44:59+09:00 nakam@linux-ipv6.org +75 -4 # ICMP and ICMPv6's type/code can be specified in selector. # fix to show sport/dport values when mask is specified. # diff -Nru a/ip/ipxfrm.c b/ip/ipxfrm.c --- a/ip/ipxfrm.c 2004-09-02 23:08:19 +09:00 +++ b/ip/ipxfrm.c 2004-09-02 23:08:19 +09:00 @@ -352,10 +352,25 @@ if (sel->proto) fprintf(fp, "proto %s ", strxf_proto(sel->proto)); - if (sel->sport) - fprintf(fp, "sport %u ", ntohs(sel->sport)); - if (sel->dport) - fprintf(fp, "dport %u ", ntohs(sel->dport)); + switch (sel->proto) { + case IPPROTO_TCP: + case IPPROTO_UDP: + case IPPROTO_SCTP: + default: /* XXX */ + if (sel->sport_mask) + fprintf(fp, "sport %u ", ntohs(sel->sport)); + if (sel->dport_mask) + fprintf(fp, "dport %u ", ntohs(sel->dport)); + break; + case IPPROTO_ICMP: + case IPPROTO_ICMPV6: + /* type/code is stored at sport/dport in selector */ + if (sel->sport_mask) + fprintf(fp, "type %u ", ntohs(sel->sport)); + if (sel->dport_mask) + fprintf(fp, "code %u ", ntohs(sel->dport)); + break; + } if (sel->ifindex > 0) { char buf[IF_NAMESIZE]; @@ -653,6 +668,10 @@ { int argc = *argcp; char **argv = *argvp; + char *sportp = NULL; + char *dportp = NULL; + char *typep = NULL; + char *codep = NULL; while (1) { if (strcmp(*argv, "proto") == 0) { @@ -677,6 +696,8 @@ filter.upspec_proto_mask = XFRM_FILTER_MASK_FULL; } else if (strcmp(*argv, "sport") == 0) { + sportp = *argv; + NEXT_ARG(); if (get_u16(&sel->sport, *argv, 0)) @@ -688,6 +709,8 @@ filter.upspec_sport_mask = XFRM_FILTER_MASK_FULL; } else if (strcmp(*argv, "dport") == 0) { + dportp = *argv; + NEXT_ARG(); if (get_u16(&sel->dport, *argv, 0)) @@ -698,6 +721,33 @@ filter.upspec_dport_mask = XFRM_FILTER_MASK_FULL; + } else if (strcmp(*argv, "type") == 0) { + typep = *argv; + + NEXT_ARG(); + + if (get_u16(&sel->sport, *argv, 0) || + (sel->sport & ~((__u16)0xff))) + invarg("\"type\" value is invalid", *argv); + sel->sport = htons(sel->sport); + sel->sport_mask = ~((__u16)0); + + filter.upspec_sport_mask = XFRM_FILTER_MASK_FULL; + + + } else if (strcmp(*argv, "code") == 0) { + codep = *argv; + + NEXT_ARG(); + + if (get_u16(&sel->dport, *argv, 0) || + (sel->dport & ~((__u16)0xff))) + invarg("\"code\" value is invalid", *argv); + sel->dport = htons(sel->dport); + sel->dport_mask = ~((__u16)0); + + filter.upspec_dport_mask = XFRM_FILTER_MASK_FULL; + } else { PREV_ARG(); /* back track */ break; @@ -709,6 +759,27 @@ } if (argc == *argcp) missarg("UPSPEC"); + if (sportp || dportp) { + switch (sel->proto) { + case IPPROTO_TCP: + case IPPROTO_UDP: + case IPPROTO_SCTP: + break; + default: + fprintf(stderr, "\"sport\" and \"dport\" are invalid with proto=%s\n", strxf_proto(sel->proto)); + exit(1); + } + } + if (typep || codep) { + switch (sel->proto) { + case IPPROTO_ICMP: + case IPPROTO_ICMPV6: + break; + default: + fprintf(stderr, "\"type\" and \"code\" are invalid with proto=%s\n", strxf_proto(sel->proto)); + exit(1); + } + } *argcp = argc; *argvp = argv; diff -Nru a/ip/xfrm_policy.c b/ip/xfrm_policy.c --- a/ip/xfrm_policy.c 2004-09-02 23:08:19 +09:00 +++ b/ip/xfrm_policy.c 2004-09-02 23:08:19 +09:00 @@ -62,7 +62,8 @@ fprintf(stderr, "SELECTOR := src ADDR[/PLEN] dst ADDR[/PLEN] [ UPSPEC ] [ dev DEV ]\n"); - fprintf(stderr, "UPSPEC := proto PROTO [ sport PORT ] [ dport PORT ]\n"); + fprintf(stderr, "UPSPEC := proto PROTO [ [ sport PORT ] [ dport PORT ] |\n"); + fprintf(stderr, " [ type NUMBER ] [ code NUMBER ] ]\n"); //fprintf(stderr, "DEV - device name(default=none)\n"); diff -Nru a/ip/xfrm_state.c b/ip/xfrm_state.c --- a/ip/xfrm_state.c 2004-09-02 23:08:19 +09:00 +++ b/ip/xfrm_state.c 2004-09-02 23:08:19 +09:00 @@ -91,7 +91,9 @@ fprintf(stderr, "SELECTOR := src ADDR[/PLEN] dst ADDR[/PLEN] [ upspec UPSPEC ] [ dev DEV ]\n"); - fprintf(stderr, "UPSPEC := proto PROTO [ sport PORT ] [ dport PORT ]\n"); + fprintf(stderr, "UPSPEC := proto PROTO [ [ sport PORT ] [ dport PORT ] |\n"); + fprintf(stderr, " [ type NUMBER ] [ code NUMBER ] ]\n"); + //fprintf(stderr, "DEV - device name(default=none)\n"); fprintf(stderr, "LIMIT-LIST := [ LIMIT-LIST ] | [ limit LIMIT ]\n"); -- Masahide NAKAMURA From nakam@linux-ipv6.org Mon Sep 6 00:47:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 00:47:23 -0700 (PDT) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i867lHgG006164 for ; Mon, 6 Sep 2004 00:47:17 -0700 Received: from localhost (unknown [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id DCA2B97C; Mon, 6 Sep 2004 16:47:03 +0900 (JST) Date: Mon, 6 Sep 2004 16:47:03 +0900 From: Masahide Nakamura To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, nakam@linux-ipv6.org Subject: [PATCH] [iproute2] XFRM: fixing protocol Message-Id: <20040906164703.3e674496@localhost> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Talking about "protocol" on IPsec/XFRM, there are two kinds of it, one is in selector and the other is in SA(state for transformation). This patch makes it is managed separately. The ChangeSets are also available at: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/02 19:11:13+09:00 nakam@linux-ipv6.org # fix error message. # # ip/xfrm_state.c # 2004/09/02 19:11:13+09:00 nakam@linux-ipv6.org +2 -2 # fix error message to use strxf_xfrmproto(). # # ChangeSet # 2004/09/02 13:35:13+09:00 nakam@linux-ipv6.org # distinguish xfrm protocol and selector protocol. # # ip/xfrm_state.c # 2004/09/02 13:35:10+09:00 nakam@linux-ipv6.org +4 -4 # fix usage. # # ip/xfrm_policy.c # 2004/09/02 13:35:10+09:00 nakam@linux-ipv6.org +4 -4 # fix usage. # # ip/xfrm.h # 2004/09/02 13:35:10+09:00 nakam@linux-ipv6.org +2 -0 # add interfaces of xfrmproto. # # ip/ipxfrm.c # 2004/09/02 13:35:10+09:00 nakam@linux-ipv6.org +45 -21 # add "xfrmproto" to distinguish xfrm protocol and selector protocol. # diff -Nru a/ip/ipxfrm.c b/ip/ipxfrm.c --- a/ip/ipxfrm.c 2004-09-02 23:03:08 +09:00 +++ b/ip/ipxfrm.c 2004-09-02 23:03:08 +09:00 @@ -57,6 +57,43 @@ int t_type; }; +static const struct typeent xfrmproto_types[]= { + { "esp", IPPROTO_ESP }, { "ah", IPPROTO_AH }, + { "comp", IPPROTO_COMP }, { NULL, -1 } +}; + +int xfrm_xfrmproto_getbyname(char *name) +{ + int i; + + for (i = 0; ; i++) { + const struct typeent *t = &xfrmproto_types[i]; + if (!t->t_name || t->t_type == -1) + break; + + if (strcmp(t->t_name, name) == 0) + return t->t_type; + } + + return -1; +} + +const char *strxf_xfrmproto(__u8 proto) +{ + int i; + + for (i = 0; ; i++) { + const struct typeent *t = &xfrmproto_types[i]; + if (!t->t_name || t->t_type == -1) + break; + + if (t->t_type == proto) + return t->t_name; + } + + return NULL; +} + static const struct typeent algo_types[]= { { "enc", XFRMA_ALG_CRYPT }, { "auth", XFRMA_ALG_AUTH }, { "comp", XFRMA_ALG_COMP }, { NULL, -1 } @@ -172,7 +209,7 @@ fprintf(fp, prefix); fprintf(fp, "\t"); - fprintf(fp, "proto %s ", strxf_proto(id->proto)); + fprintf(fp, "proto %s ", strxf_xfrmproto(id->proto)); spi = ntohl(id->spi); fprintf(fp, "spi 0x%08x", spi); @@ -522,7 +559,6 @@ char **argv = *argvp; inet_prefix dst; inet_prefix src; - __u8 proto = 0; memset(&dst, 0, sizeof(dst)); memset(&src, 0, sizeof(src)); @@ -555,27 +591,15 @@ filter.id_dst_mask = dst.bitlen; } else if (strcmp(*argv, "proto") == 0) { - struct protoent *pp; + int ret; NEXT_ARG(); - pp = getprotobyname(*argv); - if (pp) - proto = pp->p_proto; - else { - if (get_u8(&proto, *argv, 0)) - invarg("\"XFRM_PROTO\" is invalid", *argv); - } + ret = xfrm_xfrmproto_getbyname(*argv); + if (ret < 0) + invarg("\"XFRM_PROTO\" is invalid", *argv); - switch (proto) { - case IPPROTO_ESP: - case IPPROTO_AH: - case IPPROTO_COMP: - id->proto = proto; - break; - default: - invarg("\"XFRM_PROTO\" is unsuppored proto", *argv); - } + id->proto = (__u8)ret; filter.id_proto_mask = XFRM_FILTER_MASK_FULL; @@ -604,8 +628,8 @@ if (src.family && dst.family && (src.family != dst.family)) invarg("the same address family is required between \"SADDR\" and \"DADDR\"", *argv); - if (loose == 0 && proto == 0) - missarg("PROTO"); + if (loose == 0 && id->proto == 0) + missarg("XFRM_PROTO"); if (argc == *argcp) missarg("ID"); diff -Nru a/ip/xfrm.h b/ip/xfrm.h --- a/ip/xfrm.h 2004-09-02 23:03:08 +09:00 +++ b/ip/xfrm.h 2004-09-02 23:03:08 +09:00 @@ -78,7 +78,9 @@ int do_xfrm_state(int argc, char **argv); int do_xfrm_policy(int argc, char **argv); +int xfrm_xfrmproto_getbyname(char *name); int xfrm_algotype_getbyname(char *name); +const char *strxf_xfrmproto(__u8 proto); const char *strxf_algotype(int type); const char *strxf_flags(__u8 flags); const char *strxf_share(__u8 share); diff -Nru a/ip/xfrm_policy.c b/ip/xfrm_policy.c --- a/ip/xfrm_policy.c 2004-09-02 23:03:08 +09:00 +++ b/ip/xfrm_policy.c 2004-09-02 23:03:08 +09:00 @@ -78,11 +78,11 @@ fprintf(stderr, "TMPL := ID [ mode MODE ] [ reqid REQID ] [ level LEVEL ]\n"); fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]\n"); - //fprintf(stderr, "XFRM_PROTO := [ esp | ah | ipcomp ]\n"); + //fprintf(stderr, "XFRM_PROTO := [ esp | ah | comp ]\n"); fprintf(stderr, "XFRM_PROTO := [ "); - fprintf(stderr, "%s | ", strxf_proto(IPPROTO_ESP)); - fprintf(stderr, "%s | ", strxf_proto(IPPROTO_AH)); - fprintf(stderr, "%s", strxf_proto(IPPROTO_COMP)); + fprintf(stderr, "%s | ", strxf_xfrmproto(IPPROTO_ESP)); + fprintf(stderr, "%s | ", strxf_xfrmproto(IPPROTO_AH)); + fprintf(stderr, "%s", strxf_xfrmproto(IPPROTO_COMP)); fprintf(stderr, " ]\n"); fprintf(stderr, "MODE := [ transport | tunnel ](default=transport)\n"); diff -Nru a/ip/xfrm_state.c b/ip/xfrm_state.c --- a/ip/xfrm_state.c 2004-09-02 23:03:08 +09:00 +++ b/ip/xfrm_state.c 2004-09-02 23:03:08 +09:00 @@ -63,11 +63,11 @@ fprintf(stderr, " [ FLAG_LIST ]\n"); fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]\n"); - //fprintf(stderr, "XFRM_PROTO := [ esp | ah | ipcomp ]\n"); + //fprintf(stderr, "XFRM_PROTO := [ esp | ah | comp ]\n"); fprintf(stderr, "XFRM_PROTO := [ "); - fprintf(stderr, "%s | ", strxf_proto(IPPROTO_ESP)); - fprintf(stderr, "%s | ", strxf_proto(IPPROTO_AH)); - fprintf(stderr, "%s ", strxf_proto(IPPROTO_COMP)); + fprintf(stderr, "%s | ", strxf_xfrmproto(IPPROTO_ESP)); + fprintf(stderr, "%s | ", strxf_xfrmproto(IPPROTO_AH)); + fprintf(stderr, "%s ", strxf_xfrmproto(IPPROTO_COMP)); fprintf(stderr, "]\n"); //fprintf(stderr, "SPI - security parameter index(default=0)\n"); @@ -308,14 +308,14 @@ if (req.xsinfo.id.proto != IPPROTO_ESP && req.xsinfo.id.proto != IPPROTO_AH && req.xsinfo.id.proto != IPPROTO_COMP) { - fprintf(stderr, "\"ALGO\" is invalid with proto=%s\n", strxf_proto(req.xsinfo.id.proto)); + fprintf(stderr, "\"ALGO\" is invalid with proto=%s\n", strxf_xfrmproto(req.xsinfo.id.proto)); exit(1); } } else { if (req.xsinfo.id.proto == IPPROTO_ESP || req.xsinfo.id.proto == IPPROTO_AH || req.xsinfo.id.proto == IPPROTO_COMP) { - fprintf(stderr, "\"ALGO\" is required with proto=%s\n", strxf_proto(req.xsinfo.id.proto)); + fprintf(stderr, "\"ALGO\" is required with proto=%s\n", strxf_xfrmproto(req.xsinfo.id.proto)); exit (1); } } -- Masahide NAKAMURA From nakam@linux-ipv6.org Mon Sep 6 00:46:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 00:46:37 -0700 (PDT) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i867kUiP006012 for ; Mon, 6 Sep 2004 00:46:31 -0700 Received: from localhost (unknown [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id 3DA53F05; Mon, 6 Sep 2004 16:46:16 +0900 (JST) Date: Mon, 6 Sep 2004 16:46:15 +0900 From: Masahide Nakamura To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, yoshfuji@linux-ipv6.org, nakam@linux-ipv6.org Subject: [PATCH] [iproute2] XFRM: fixing IPsec algorithm key Message-Id: <20040906164615.6320ab5f@localhost> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Hello, This patch fixes `ip xfrm`'s algorithm key when using hexadecimal number from command line. Please apply it. The ChangeSet is also available at: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/02 17:35:23+09:00 nakam@linux-ipv6.org # fix specifying IPsec algorithm key. # # ip/xfrm_state.c # 2004/09/02 17:35:21+09:00 nakam@linux-ipv6.org +27 -26 # fix algorithm key when using hexadecimal number # (clean-up by Hideaki YOSHIFUJI ). # diff -Nru a/ip/xfrm_state.c b/ip/xfrm_state.c --- a/ip/xfrm_state.c 2004-09-02 23:04:14 +09:00 +++ b/ip/xfrm_state.c 2004-09-02 23:04:14 +09:00 @@ -114,34 +114,35 @@ strncpy(alg->alg_name, name, sizeof(alg->alg_name)); if (slen > 2 && strncmp(key, "0x", 2) == 0) { - /* - * XXX: fix me!! + /* split two chars "0x" from the top */ + char *p = key + 2; + int plen = slen - 2; + int i; + int j; + + /* Converting hexadecimal numbered string into real key; + * Convert each two chars into one char(value). If number + * of the length is odd, add zero on the top for rounding. */ - union { - __u64 x; - unsigned char p[8]; - } val; - - memset(&val, 0, sizeof(val)); - - if (get_u64(&val.x, key, 16)) - invarg("\"ALGOKEY\" is invalid", key); - - len = (slen - 2) / 2; - if (len > sizeof(val)) - invarg("\"ALGOKEY\" is invalid: too large", key); - - if (len > 0) { - int i; - - if (len > max) - invarg("\"ALGOKEY\" makes buffer overflow\n", key); - for (i = sizeof(val.p) - 1; i >= 0; i--) { - int j = sizeof(val.p) - 1 - i; - alg->alg_key[j] = val.p[i]; - } - } + /* calculate length of the converted values(real key) */ + len = (plen + 1) / 2; + if (len > max) + invarg("\"ALGOKEY\" makes buffer overflow\n", key); + + for (i = - (plen % 2), j = 0; j < len; i += 2, j++) { + char vbuf[3]; + char val; + + vbuf[0] = i >= 0 ? p[i] : '0'; + vbuf[1] = p[i + 1]; + vbuf[2] = '\0'; + + if (get_u8(&val, vbuf, 16)) + invarg("\"ALGOKEY\" is invalid", key); + + alg->alg_key[j] = val; + } } else { len = slen; if (len > 0) { -- Masahide NAKAMURA -- Masahide NAKAMURA From nakam@linux-ipv6.org Mon Sep 6 00:46:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 00:47:00 -0700 (PDT) Received: from mail406.noc.n-bone.net (mail4.noc.n-bone.net [138.243.50.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i867kt8h006034 for ; Mon, 6 Sep 2004 00:46:56 -0700 Received: from localhost (unknown [203.178.140.10]) by mail406.noc.n-bone.net (NBONE-MTA) with ESMTP id B67D75A7; Mon, 6 Sep 2004 16:46:41 +0900 (JST) Date: Mon, 6 Sep 2004 16:46:40 +0900 From: Masahide Nakamura To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, nakam@linux-ipv6.org Subject: [PATCH] [iproute2] XFRM: using flush message type Message-Id: <20040906164640.19710b12@localhost> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Kernel has flush message types for XFRM's policy/state so I've fixed to use it in which case no argument are specified after "flush" in the command line. Please apply a patch below. The ChangeSet is also available at: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/02 22:58:16+09:00 nakam@linux-ipv6.org # use flush message types. # # ip/xfrm_state.c # 2004/09/02 22:58:11+09:00 nakam@linux-ipv6.org +37 -3 # use XFRM_MSG_FLUSHSA message type in flushing without any other # arguments. # # ip/xfrm_policy.c # 2004/09/02 22:58:11+09:00 nakam@linux-ipv6.org +33 -2 # use XFRM_MSG_FLUSHPOLICY message type in flushing without any other # arguments. # # include/utils.h # 2004/09/02 22:58:10+09:00 nakam@linux-ipv6.org +3 -0 # add IPSEC_PROTO_ANY in kernel's include/linux/ipsec.h. # diff -Nru a/include/utils.h b/include/utils.h --- a/include/utils.h 2004-09-02 23:05:20 +09:00 +++ b/include/utils.h 2004-09-02 23:05:20 +09:00 @@ -25,6 +25,9 @@ #ifndef IPPROTO_COMP #define IPPROTO_COMP 108 #endif +#ifndef IPSEC_PROTO_ANY +#define IPSEC_PROTO_ANY 255 +#endif #define SPRINT_BSIZE 64 #define SPRINT_BUF(x) char x[SPRINT_BSIZE] diff -Nru a/ip/xfrm_policy.c b/ip/xfrm_policy.c --- a/ip/xfrm_policy.c 2004-09-02 23:05:20 +09:00 +++ b/ip/xfrm_policy.c 2004-09-02 23:05:20 +09:00 @@ -680,6 +680,33 @@ exit(0); } +static int xfrm_policy_flush_all(void) +{ + struct rtnl_handle rth; + struct { + struct nlmsghdr n; + } req; + + memset(&req, 0, sizeof(req)); + + req.n.nlmsg_len = NLMSG_LENGTH(0); /* nlmsg data is nothing */ + req.n.nlmsg_flags = NLM_F_REQUEST; + req.n.nlmsg_type = XFRM_MSG_FLUSHPOLICY; + + if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0) + exit(1); + + if (show_stats > 1) + fprintf(stderr, "Flush all\n"); + + if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0) + exit(2); + + rtnl_close(&rth); + + return 0; +} + int do_xfrm_policy(int argc, char **argv) { if (argc < 1) @@ -698,8 +725,12 @@ return xfrm_policy_list_or_flush(argc-1, argv+1, 0); if (matches(*argv, "get") == 0) return xfrm_policy_get(argc-1, argv+1); - if (matches(*argv, "flush") == 0) - return xfrm_policy_list_or_flush(argc-1, argv+1, 1); + if (matches(*argv, "flush") == 0) { + if (argc-1 < 1) + return xfrm_policy_flush_all(); + else + return xfrm_policy_list_or_flush(argc-1, argv+1, 1); + } if (matches(*argv, "help") == 0) usage(); fprintf(stderr, "Command \"%s\" is unknown, try \"ip xfrm policy help\".\n", *argv); diff -Nru a/ip/xfrm_state.c b/ip/xfrm_state.c --- a/ip/xfrm_state.c 2004-09-02 23:05:20 +09:00 +++ b/ip/xfrm_state.c 2004-09-02 23:05:20 +09:00 @@ -563,7 +563,8 @@ char *idp = NULL; struct rtnl_handle rth; - filter.use = 1; + if(argc > 0) + filter.use = 1; filter.xsinfo.family = preferred_family; while (argc > 0) { @@ -661,6 +662,35 @@ exit(0); } +static int xfrm_state_flush_all(void) +{ + struct rtnl_handle rth; + struct { + struct nlmsghdr n; + struct xfrm_usersa_flush xsf; + } req; + + memset(&req, 0, sizeof(req)); + + req.n.nlmsg_len = NLMSG_LENGTH(sizeof(req.xsf)); + req.n.nlmsg_flags = NLM_F_REQUEST; + req.n.nlmsg_type = XFRM_MSG_FLUSHSA; + req.xsf.proto = IPSEC_PROTO_ANY; + + if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0) + exit(1); + + if (show_stats > 1) + fprintf(stderr, "Flush all\n"); + + if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0) + exit(2); + + rtnl_close(&rth); + + return 0; +} + int do_xfrm_state(int argc, char **argv) { if (argc < 1) @@ -679,8 +709,12 @@ return xfrm_state_list_or_flush(argc-1, argv+1, 0); if (matches(*argv, "get") == 0) return xfrm_state_get_or_delete(argc-1, argv+1, 0); - if (matches(*argv, "flush") == 0) - return xfrm_state_list_or_flush(argc-1, argv+1, 1); + if (matches(*argv, "flush") == 0) { + if (argc-1 < 1) + return xfrm_state_flush_all(); + else + return xfrm_state_list_or_flush(argc-1, argv+1, 1); + } if (matches(*argv, "help") == 0) usage(); fprintf(stderr, "Command \"%s\" is unknown, try \"ip xfrm state help\".\n", *argv); -- Masahide NAKAMURA From hch@lst.de Mon Sep 6 03:10:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 03:10:49 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86AAO0E013305 for ; Mon, 6 Sep 2004 03:10:25 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i86AAE95017630 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 12:10:14 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i86AAEdd017628; Mon, 6 Sep 2004 12:10:14 +0200 Date: Mon, 6 Sep 2004 12:10:14 +0200 From: Christoph Hellwig To: netdev@oss.sgi.com, linux-scsi@vger.kernel.org Subject: [PATCH] remove iph5526 driver Message-ID: <20040906101014.GA17597@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 193095 Lines: 5941 This driver is for totally obsolete early fibrechannel hardware and doesn't compile anymore since early 2.5.x. In addition it'll require a major rewrite to fit into the current framework for fc drivers. --- 1.91/drivers/net/Kconfig 2004-09-03 11:08:21 +02:00 +++ edited/drivers/net/Kconfig 2004-09-06 11:56:04 +02:00 @@ -2618,15 +2618,6 @@ adaptor below. You also should have said Y to "SCSI support" and "SCSI generic support". -config IPHASE5526 - tristate "Interphase 5526 Tachyon chipset based adapter support" - depends on NET_FC && SCSI && PCI && BROKEN - help - Say Y here if you have a Fibre Channel adaptor of this kind. - - To compile this driver as a module, choose M here: the module - will be called iph5526. - config SHAPER tristate "Traffic Shaper (EXPERIMENTAL)" depends on NETDEVICES && EXPERIMENTAL ===== drivers/net/fc/Makefile 1.5 vs edited ===== --- 1.5/drivers/net/fc/Makefile 2002-12-14 13:38:56 +01:00 +++ edited/drivers/net/fc/Makefile 2004-09-06 11:54:26 +02:00 @@ -1,8 +0,0 @@ -# -# Makefile for linux/drivers/net/fc -# -# 9 Aug 2000, Christoph Hellwig -# Rewritten to use lists instead of if-statements. -# - -obj-$(CONFIG_IPHASE5526) += iph5526.o ===== drivers/net/fc/iph5526.c 1.35 vs edited ===== --- 1.35/drivers/net/fc/iph5526.c 2004-06-19 17:54:02 +02:00 +++ edited/drivers/net/fc/iph5526.c 2004-09-06 11:53:59 +02:00 @@ -1,4645 +0,0 @@ -/********************************************************************** - * iph5526.c: IP/SCSI driver for the Interphase 5526 PCI Fibre Channel - * Card. - * Copyright (C) 1999 Vineet M Abraham - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - *********************************************************************/ -/********************************************************************** -Log: -Vineet M Abraham -02.12.99 Support multiple cards. -03.15.99 Added Fabric support. -04.04.99 Added N_Port support. -04.15.99 Added SCSI support. -06.18.99 Added ABTS Protocol. -06.24.99 Fixed data corruption when multiple XFER_RDYs are received. -07.07.99 Can be loaded as part of the Kernel. Changed semaphores. Added - more checks before invalidating SEST entries. -07.08.99 Added Broadcast IP stuff and fixed an unicast timeout bug. -***********************************************************************/ -/* TODO: - R_T_TOV set to 15msec in Loop topology. Need to be 100 msec. - SMP testing. - Fix ADISC Tx before completing FLOGI. -*/ - -static const char *version = - "iph5526.c:v1.0 07.08.99 Vineet Abraham (vmabraham@hotmail.com)\n"; - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include /* had the declarations for init_fcdev among - others + includes if_fcdevice.h */ - -#include "../../scsi/scsi.h" -#include -#include "../../fc4/fcp.h" - -#include -#include - -/* driver specific header files */ -#include "tach.h" -#include "tach_structs.h" -#include "iph5526_ip.h" -#include "iph5526_scsi.h" -#include "iph5526_novram.c" - -#define RUN_AT(x) (jiffies + (x)) - -#define DEBUG_5526_0 0 -#define DEBUG_5526_1 0 -#define DEBUG_5526_2 0 - -#if DEBUG_5526_0 -#define DPRINTK(format, a...) {printk("%s: ", fi->name); \ - printk(format, ##a); \ - printk("\n");} -#define ENTER(x) {printk("%s: ", fi->name); \ - printk("iph5526.c : entering %s()\n", x);} -#define LEAVE(x) {printk("%s: ", fi->name); \ - printk("iph5526.c : leaving %s()\n",x);} - -#else -#define DPRINTK(format, a...) {} -#define ENTER(x) {} -#define LEAVE(x) {} -#endif - -#if DEBUG_5526_1 -#define DPRINTK1(format, a...) {printk("%s: ", fi->name); \ - printk(format, ##a); \ - printk("\n");} -#else -#define DPRINTK1(format, a...) {} -#endif - -#if DEBUG_5526_2 -#define DPRINTK2(format, a...) {printk("%s: ", fi->name); \ - printk(format, ##a); \ - printk("\n");} -#else -#define DPRINTK2(format, a...) {} -#endif - -#define T_MSG(format, a...) {printk("%s: ", fi->name); \ - printk(format, ##a);\ - printk("\n");} - -#define ALIGNED_SFS_ADDR(addr) ((((unsigned long)(addr) + (SFS_BUFFER_SIZE - 1)) & ~(SFS_BUFFER_SIZE - 1)) - (unsigned long)(addr)) -#define ALIGNED_ADDR(addr, len) ((((unsigned long)(addr) + (len - 1)) & ~(len - 1)) - (unsigned long)(addr)) - - -static struct pci_device_id iph5526_pci_tbl[] = { - { PCI_VENDOR_ID_INTERPHASE, PCI_DEVICE_ID_INTERPHASE_5526, PCI_ANY_ID, PCI_ANY_ID, }, - { PCI_VENDOR_ID_INTERPHASE, PCI_DEVICE_ID_INTERPHASE_55x6, PCI_ANY_ID, PCI_ANY_ID, }, - { } /* Terminating entry */ -}; -MODULE_DEVICE_TABLE(pci, iph5526_pci_tbl); - -MODULE_LICENSE("GPL"); - -#define MAX_FC_CARDS 2 -static struct fc_info *fc[MAX_FC_CARDS+1]; -static unsigned int pci_irq_line; -static struct { - unsigned short vendor_id; - unsigned short device_id; - char *name; -} -clone_list[] __initdata = { - {PCI_VENDOR_ID_INTERPHASE, PCI_DEVICE_ID_INTERPHASE_5526, "Interphase Fibre Channel HBA"}, - {PCI_VENDOR_ID_INTERPHASE, PCI_DEVICE_ID_INTERPHASE_55x6, "Interphase Fibre Channel HBA"}, - {0,} -}; - -static irqreturn_t tachyon_interrupt(int irq, void *dev_id, struct pt_regs *regs); -static void tachyon_interrupt_handler(int irq, void* dev_id, struct pt_regs* regs); - -static int initialize_register_pointers(struct fc_info *fi); -void clean_up_memory(struct fc_info *fi); - -static int tachyon_init(struct fc_info *fi); -static int build_queues(struct fc_info *fi); -static void build_tachyon_header(struct fc_info *fi, u_int my_id, u_int r_ctl, u_int d_id, u_int type, u_char seq_id, u_char df_ctl, u_short ox_id, u_short rx_id, char *data); -static int get_free_header(struct fc_info *fi); -static void build_EDB(struct fc_info *fi, char *data, u_short flags, u_short len); -static int get_free_EDB(struct fc_info *fi); -static void build_ODB(struct fc_info *fi, u_char seq_id, u_int d_id, u_int len, u_int cntl, u_short mtu, u_short ox_id, u_short rx_id, int NW_header, int int_required, u_int frame_class); -static void write_to_tachyon_registers(struct fc_info *fi); -static void reset_latch(struct fc_info *fi); -static void reset_tachyon(struct fc_info *fi, u_int value); -static void take_tachyon_offline(struct fc_info *fi); -static void read_novram(struct fc_info *fi); -static void reset_ichip(struct fc_info *fi); -static void update_OCQ_indx(struct fc_info *fi); -static void update_IMQ_indx(struct fc_info *fi, int count); -static void update_SFSBQ_indx(struct fc_info *fi); -static void update_MFSBQ_indx(struct fc_info *fi, int count); -static void update_tachyon_header_indx(struct fc_info *fi); -static void update_EDB_indx(struct fc_info *fi); -static void handle_FM_interrupt(struct fc_info *fi); -static void handle_MFS_interrupt(struct fc_info *fi); -static void handle_OOO_interrupt(struct fc_info *fi); -static void handle_SFS_interrupt(struct fc_info *fi); -static void handle_OCI_interrupt(struct fc_info *fi); -static void handle_SFS_BUF_WARN_interrupt(struct fc_info *fi); -static void handle_MFS_BUF_WARN_interrupt(struct fc_info *fi); -static void handle_IMQ_BUF_WARN_interrupt(struct fc_info *fi); -static void handle_Unknown_Frame_interrupt(struct fc_info *fi); -static void handle_Busied_Frame_interrupt(struct fc_info *fi); -static void handle_Bad_SCSI_Frame_interrupt(struct fc_info *fi); -static void handle_Inbound_SCSI_Status_interrupt(struct fc_info *fi); -static void handle_Inbound_SCSI_Command_interrupt(struct fc_info *fi); -static void completion_message_handler(struct fc_info *fi, u_int imq_int_type); -static void fill_login_frame(struct fc_info *fi, u_int logi); - -static int tx_exchange(struct fc_info *fi, char *data, u_int len, u_int r_ctl, u_int type, u_int d_id, u_int mtu, int int_required, u_short ox_id, u_int frame_class); -static int tx_sequence(struct fc_info *fi, char *data, u_int len, u_int mtu, u_int d_id, u_short ox_id, u_short rx_id, u_char seq_id, int NW_flag, int int_required, u_int frame_class); -static int validate_login(struct fc_info *fi, u_int *base_ptr); -static void add_to_address_cache(struct fc_info *fi, u_int *base_ptr); -static void remove_from_address_cache(struct fc_info *fi, u_int *data, u_int cmnd_code); -static int node_logged_in_prev(struct fc_info *fi, u_int *buff_addr); -static int sid_logged_in(struct fc_info *fi, u_int s_id); -static struct fc_node_info *look_up_cache(struct fc_info *fi, char *data); -static int display_cache(struct fc_info *fi); - -static void tx_logi(struct fc_info *fi, u_int logi, u_int d_id); -static void tx_logi_acc(struct fc_info *fi, u_int logi, u_int d_id, u_short received_ox_id); -static void tx_prli(struct fc_info *fi, u_int command_code, u_int d_id, u_short received_ox_id); -static void tx_logo(struct fc_info *fi, u_int d_id, u_short received_ox_id); -static void tx_adisc(struct fc_info *fi, u_int cmnd_code, u_int d_id, u_short received_ox_id); -static void tx_ls_rjt(struct fc_info *fi, u_int d_id, u_short received_ox_id, u_short reason_code, u_short expln_code); -static u_int plogi_ok(struct fc_info *fi, u_int *buff_addr, int size); -static void tx_acc(struct fc_info *fi, u_int d_id, u_short received_ox_id); -static void tx_name_server_req(struct fc_info *fi, u_int req); -static void rscn_handler(struct fc_info *fi, u_int node_id); -static void tx_scr(struct fc_info *fi); -static void scr_timer(unsigned long data); -static void explore_fabric(struct fc_info *fi, u_int *buff_addr); -static void perform_adisc(struct fc_info *fi); -static void local_port_discovery(struct fc_info *fi); -static void add_to_ox_id_list(struct fc_info *fi, u_int transaction_id, u_int cmnd_code); -static u_int remove_from_ox_id_list(struct fc_info *fi, u_short received_ox_id); -static void add_display_cache_timer(struct fc_info *fi); - -/* Timers... */ -static void nos_ols_timer(unsigned long data); -static void loop_timer(unsigned long data); -static void fabric_explore_timer(unsigned long data); -static void port_discovery_timer(unsigned long data); -static void display_cache_timer(unsigned long data); - -/* SCSI Stuff */ -static int add_to_sest(struct fc_info *fi, Scsi_Cmnd *Cmnd, struct fc_node_info *ni); -static struct fc_node_info *resolve_target(struct fc_info *fi, u_char target); -static void update_FCP_CMND_indx(struct fc_info *fi); -static int get_free_SDB(struct fc_info *fi); -static void update_SDB_indx(struct fc_info *fi); -static void mark_scsi_sid(struct fc_info *fi, u_int *buff_addr, u_char action); -static void invalidate_SEST_entry(struct fc_info *fi, u_short received_ox_id); -static int abort_exchange(struct fc_info *fi, u_short ox_id); -static void flush_tachyon_cache(struct fc_info *fi, u_short ox_id); -static int get_scsi_oxid(struct fc_info *fi); -static void update_scsi_oxid(struct fc_info *fi); - -static Scsi_Host_Template driver_template = IPH5526_SCSI_FC; - -static void iph5526_timeout(struct net_device *dev); - -static int iph5526_probe_pci(struct net_device *dev); - -int __init iph5526_probe(struct net_device *dev) -{ - if (iph5526_probe_pci(dev) == 0) - return 0; - return -ENODEV; -} - -static int __init iph5526_probe_pci(struct net_device *dev) -{ - struct fc_info *fi = dev->priv; - fi->dev = dev; - dev->base_addr = fi->base_addr; - dev->irq = fi->irq; - if (dev->priv == NULL) - dev->priv = fi; - fcdev_init(dev); - /* Assign ur MAC address. - */ - dev->dev_addr[0] = (fi->g.my_port_name_high & 0x0000FF00) >> 8; - dev->dev_addr[1] = fi->g.my_port_name_high; - dev->dev_addr[2] = (fi->g.my_port_name_low & 0xFF000000) >> 24; - dev->dev_addr[3] = (fi->g.my_port_name_low & 0x00FF0000) >> 16; - dev->dev_addr[4] = (fi->g.my_port_name_low & 0x0000FF00) >> 8; - dev->dev_addr[5] = fi->g.my_port_name_low; - display_cache(fi); - return 0; -} - -static int __init fcdev_init(struct net_device *dev) -{ - SET_MODULE_OWNER(dev); - dev->open = iph5526_open; - dev->stop = iph5526_close; - dev->hard_start_xmit = iph5526_send_packet; - dev->get_stats = iph5526_get_stats; - dev->set_multicast_list = NULL; - dev->change_mtu = iph5526_change_mtu; - dev->tx_timeout = iph5526_timeout; - dev->watchdog_timeo = 5*HZ; - return 0; -} - -/* initialize tachyon and take it OnLine */ -static int tachyon_init(struct fc_info *fi) -{ - ENTER("tachyon_init"); - if (build_queues(fi) == 0) { - T_MSG("build_queues() failed"); - return 0; - } - - /* Retrieve your port/node name. - */ - read_novram(fi); - - reset_ichip(fi); - - reset_tachyon(fi, SOFTWARE_RESET); - - LEAVE("tachyon_init"); - return 1; -} - -/* Build the 4 Qs - IMQ, OCQ, MFSBQ, SFSBQ */ -/* Lots of dma_pages needed as Tachyon DMAs almost everything into - * host memory. - */ -static int build_queues(struct fc_info *fi) -{ -int i,j; -u_char *addr; - ENTER("build_queues"); - /* Initializing Queue Variables. - */ - fi->q.ptr_host_ocq_cons_indx = NULL; - fi->q.ptr_host_hpcq_cons_indx = NULL; - fi->q.ptr_host_imq_prod_indx = NULL; - - fi->q.ptr_ocq_base = NULL; - fi->q.ocq_len = 0; - fi->q.ocq_end = 0; - fi->q.ocq_prod_indx = 0; - - fi->q.ptr_imq_base = NULL; - fi->q.imq_len = 0; - fi->q.imq_end = 0; - fi->q.imq_cons_indx = 0; - fi->q.imq_prod_indx = 0; - - fi->q.ptr_mfsbq_base = NULL; - fi->q.mfsbq_len = 0; - fi->q.mfsbq_end = 0; - fi->q.mfsbq_prod_indx = 0; - fi->q.mfsbq_cons_indx = 0; - fi->q.mfsbuff_len = 0; - fi->q.mfsbuff_end = 0; - fi->g.mfs_buffer_count = 0; - - fi->q.ptr_sfsbq_base = NULL; - fi->q.sfsbq_len = 0; - fi->q.sfsbq_end = 0; - fi->q.sfsbq_prod_indx = 0; - fi->q.sfsbq_cons_indx = 0; - fi->q.sfsbuff_len = 0; - fi->q.sfsbuff_end = 0; - - fi->q.sdb_indx = 0; - fi->q.fcp_cmnd_indx = 0; - - fi->q.ptr_edb_base = NULL; - fi->q.edb_buffer_indx = 0; - fi->q.ptr_tachyon_header_base = NULL; - fi->q.tachyon_header_indx = 0; - fi->node_info_list = NULL; - fi->ox_id_list = NULL; - fi->g.loop_up = FALSE; - fi->g.ptp_up = FALSE; - fi->g.link_up = FALSE; - fi->g.fabric_present = FALSE; - fi->g.n_port_try = FALSE; - fi->g.dont_init = FALSE; - fi->g.nport_timer_set = FALSE; - fi->g.lport_timer_set = FALSE; - fi->g.no_of_targets = 0; - fi->g.sem = 0; - fi->g.perform_adisc = FALSE; - fi->g.e_i = 0; - - /* build OCQ */ - if ( (fi->q.ptr_ocq_base = (u_int *)__get_free_pages(GFP_KERNEL, 0)) == 0) { - T_MSG("failed to get OCQ page"); - return 0; - } - /* set up the OCQ structures */ - for (i = 0; i < OCQ_LENGTH; i++) - fi->q.ptr_odb[i] = fi->q.ptr_ocq_base + NO_OF_ENTRIES*i; - - /* build IMQ */ - if ( (fi->q.ptr_imq_base = (u_int *)__get_free_pages(GFP_KERNEL, 0)) == 0) { - T_MSG("failed to get IMQ page"); - return 0; - } - for (i = 0; i < IMQ_LENGTH; i++) - fi->q.ptr_imqe[i] = fi->q.ptr_imq_base + NO_OF_ENTRIES*i; - - /* build MFSBQ */ - if ( (fi->q.ptr_mfsbq_base = (u_int *)__get_free_pages(GFP_KERNEL, 0)) == 0) { - T_MSG("failed to get MFSBQ page"); - return 0; - } - memset((char *)fi->q.ptr_mfsbq_base, 0, MFSBQ_LENGTH * 32); - /* Allocate one huge chunk of memory... helps while reassembling - * frames. - */ - if ( (addr = (u_char *)__get_free_pages(GFP_KERNEL, 5) ) == 0) { - T_MSG("failed to get MFSBQ page"); - return 0; - } - /* fill in addresses of empty buffers */ - for (i = 0; i < MFSBQ_LENGTH; i++) { - for (j = 0; j < NO_OF_ENTRIES; j++) { - *(fi->q.ptr_mfsbq_base + i*NO_OF_ENTRIES + j) = htonl(virt_to_bus(addr)); - addr += MFS_BUFFER_SIZE; - } - } - - /* The number of entries in each MFS buffer is 8. There are 8 - * MFS buffers. That leaves us with 4096-256 bytes. We use them - * as temporary space for ELS frames. This is done to make sure that - * the addresses are aligned. - */ - fi->g.els_buffer[0] = fi->q.ptr_mfsbq_base + MFSBQ_LENGTH*NO_OF_ENTRIES; - for (i = 1; i < MAX_PENDING_FRAMES; i++) - fi->g.els_buffer[i] = fi->g.els_buffer[i-1] + 64; - - /* build SFSBQ */ - if ( (fi->q.ptr_sfsbq_base = (u_int *)__get_free_pages(GFP_KERNEL, 0)) == 0) { - T_MSG("failed to get SFSBQ page"); - return 0; - } - memset((char *)fi->q.ptr_sfsbq_base, 0, SFSBQ_LENGTH * 32); - /* fill in addresses of empty buffers */ - for (i = 0; i < SFSBQ_LENGTH; i++) - for (j = 0; j < NO_OF_ENTRIES; j++){ - addr = kmalloc(SFS_BUFFER_SIZE*2, GFP_KERNEL); - if (addr == NULL){ - T_MSG("ptr_sfs_buffer : memory not allocated"); - return 0; - } - else { - int offset = ALIGNED_SFS_ADDR(addr); - memset((char *)addr, 0, SFS_BUFFER_SIZE); - fi->q.ptr_sfs_buffers[i*NO_OF_ENTRIES +j] = (u_int *)addr; - addr += offset; - *(fi->q.ptr_sfsbq_base + i*NO_OF_ENTRIES + j) = htonl(virt_to_bus(addr)); - } - } - - /* The number of entries in each SFS buffer is 8. There are 8 - * MFS buffers. That leaves us with 4096-256 bytes. We use them - * as temporary space for ARP frames. This is done inorder to - * support HW_Types of 0x1 and 0x6. - */ - fi->g.arp_buffer = (char *)fi->q.ptr_sfsbq_base + SFSBQ_LENGTH*NO_OF_ENTRIES*4; - - /* build EDB */ - if ((fi->q.ptr_edb_base = (u_int *)__get_free_pages(GFP_KERNEL, 5) ) == 0) { - T_MSG("failed to get EDB page"); - return 0; - } - for (i = 0; i < EDB_LEN; i++) - fi->q.ptr_edb[i] = fi->q.ptr_edb_base + 2*i; - - /* build SEST */ - - /* OX_IDs range from 0x0 - 0x4FFF. - */ - if ((fi->q.ptr_sest_base = (u_int *)__get_free_pages(GFP_KERNEL, 5)) == 0) { - T_MSG("failed to get SEST page"); - return 0; - } - for (i = 0; i < SEST_LENGTH; i++) - fi->q.ptr_sest[i] = fi->q.ptr_sest_base + NO_OF_ENTRIES*i; - - if ((fi->q.ptr_sdb_base = (u_int *)__get_free_pages(GFP_KERNEL, 5)) == 0) { - T_MSG("failed to get SDB page"); - return 0; - } - for (i = 0 ; i < NO_OF_SDB_ENTRIES; i++) - fi->q.ptr_sdb_slot[i] = fi->q.ptr_sdb_base + (SDB_SIZE/4)*i; - - if ((fi->q.ptr_fcp_cmnd_base = (u_int *)__get_free_pages(GFP_KERNEL, 0)) == 0) { - T_MSG("failed to get FCP_CMND page"); - return 0; - } - for (i = 0; i < NO_OF_FCP_CMNDS; i++) - fi->q.ptr_fcp_cmnd[i] = fi->q.ptr_fcp_cmnd_base + NO_OF_ENTRIES*i; - - /* Allocate space for Tachyon Header as well... - */ - if ((fi->q.ptr_tachyon_header_base = (u_int *)__get_free_pages(GFP_KERNEL, 0) ) == 0) { - T_MSG("failed to get tachyon_header page"); - return 0; - } - for (i = 0; i < NO_OF_TACH_HEADERS; i++) - fi->q.ptr_tachyon_header[i] = fi->q.ptr_tachyon_header_base + 16*i; - - /* Allocate memory for indices. - * Indices should be aligned on 32 byte boundaries. - */ - fi->q.host_ocq_cons_indx = kmalloc(2*32, GFP_KERNEL); - if (fi->q.host_ocq_cons_indx == NULL){ - T_MSG("fi->q.host_ocq_cons_indx : memory not allocated"); - return 0; - } - fi->q.ptr_host_ocq_cons_indx = fi->q.host_ocq_cons_indx; - if ((u_long)(fi->q.host_ocq_cons_indx) % 32) - fi->q.host_ocq_cons_indx++; - - fi->q.host_hpcq_cons_indx = kmalloc(2*32, GFP_KERNEL); - if (fi->q.host_hpcq_cons_indx == NULL){ - T_MSG("fi->q.host_hpcq_cons_indx : memory not allocated"); - return 0; - } - fi->q.ptr_host_hpcq_cons_indx= fi->q.host_hpcq_cons_indx; - if ((u_long)(fi->q.host_hpcq_cons_indx) % 32) - fi->q.host_hpcq_cons_indx++; - - fi->q.host_imq_prod_indx = kmalloc(2*32, GFP_KERNEL); - if (fi->q.host_imq_prod_indx == NULL){ - T_MSG("fi->q.host_imq_prod_indx : memory not allocated"); - return 0; - } - fi->q.ptr_host_imq_prod_indx = fi->q.host_imq_prod_indx; - if ((u_long)(fi->q.host_imq_prod_indx) % 32) - fi->q.host_imq_prod_indx++; - - LEAVE("build_queues"); - return 1; -} - - -static void write_to_tachyon_registers(struct fc_info *fi) -{ -u_int bus_addr, bus_indx_addr, i; - - ENTER("write_to_tachyon_registers"); - - /* Clear Queues each time Tachyon is reset */ - memset((char *)fi->q.ptr_ocq_base, 0, OCQ_LENGTH * 32); - memset((char *)fi->q.ptr_imq_base, 0, IMQ_LENGTH * 32); - memset((char *)fi->q.ptr_edb_base, 0, EDB_LEN * 8); - memset((char *)fi->q.ptr_sest_base, 0, SEST_LENGTH * 32); - memset((char *)fi->q.ptr_sdb_base, 0, NO_OF_SDB_ENTRIES * SDB_SIZE); - memset((char *)fi->q.ptr_tachyon_header_base, 0xFF, NO_OF_TACH_HEADERS * TACH_HEADER_SIZE); - for (i = 0; i < SEST_LENGTH; i++) - fi->q.free_scsi_oxid[i] = OXID_AVAILABLE; - for (i = 0; i < NO_OF_SDB_ENTRIES; i++) - fi->q.sdb_slot_status[i] = SDB_FREE; - - take_tachyon_offline(fi); - writel(readl(fi->t_r.ptr_tach_config_reg) | SCSI_ENABLE | WRITE_STREAM_SIZE | READ_STREAM_SIZE | PARITY_EVEN | OOO_REASSEMBLY_DISABLE, fi->t_r.ptr_tach_config_reg); - - /* Write OCQ registers */ - fi->q.ocq_prod_indx = 0; - *(fi->q.host_ocq_cons_indx) = 0; - - /* The Tachyon needs to be passed the "real" address */ - bus_addr = virt_to_bus(fi->q.ptr_ocq_base); - writel(bus_addr, fi->t_r.ptr_ocq_base_reg); - writel(OCQ_LENGTH - 1, fi->t_r. ptr_ocq_len_reg); - bus_indx_addr = virt_to_bus(fi->q.host_ocq_cons_indx); - writel(bus_indx_addr, fi->t_r.ptr_ocq_cons_indx_reg); - - /* Write IMQ registers */ - fi->q.imq_cons_indx = 0; - *(fi->q.host_imq_prod_indx) = 0; - bus_addr = virt_to_bus(fi->q.ptr_imq_base); - writel(bus_addr, fi->t_r.ptr_imq_base_reg); - writel(IMQ_LENGTH - 1, fi->t_r.ptr_imq_len_reg); - bus_indx_addr = virt_to_bus(fi->q.host_imq_prod_indx); - writel(bus_indx_addr, fi->t_r.ptr_imq_prod_indx_reg); - - /* Write MFSBQ registers */ - fi->q.mfsbq_prod_indx = MFSBQ_LENGTH - 1; - fi->q.mfsbuff_end = MFS_BUFFER_SIZE - 1; - fi->q.mfsbq_cons_indx = 0; - bus_addr = virt_to_bus(fi->q.ptr_mfsbq_base); - writel(bus_addr, fi->t_r.ptr_mfsbq_base_reg); - writel(MFSBQ_LENGTH - 1, fi->t_r.ptr_mfsbq_len_reg); - writel(fi->q.mfsbuff_end, fi->t_r.ptr_mfsbuff_len_reg); - /* Do this last as tachyon will prefetch the - * first entry as soon as we write to it. - */ - writel(fi->q.mfsbq_prod_indx, fi->t_r.ptr_mfsbq_prod_reg); - - /* Write SFSBQ registers */ - fi->q.sfsbq_prod_indx = SFSBQ_LENGTH - 1; - fi->q.sfsbuff_end = SFS_BUFFER_SIZE - 1; - fi->q.sfsbq_cons_indx = 0; - bus_addr = virt_to_bus(fi->q.ptr_sfsbq_base); - writel(bus_addr, fi->t_r.ptr_sfsbq_base_reg); - writel(SFSBQ_LENGTH - 1, fi->t_r.ptr_sfsbq_len_reg); - writel(fi->q.sfsbuff_end, fi->t_r.ptr_sfsbuff_len_reg); - /* Do this last as tachyon will prefetch the first - * entry as soon as we write to it. - */ - writel(fi->q.sfsbq_prod_indx, fi->t_r.ptr_sfsbq_prod_reg); - - /* Write SEST registers */ - bus_addr = virt_to_bus(fi->q.ptr_sest_base); - writel(bus_addr, fi->t_r.ptr_sest_base_reg); - writel(SEST_LENGTH - 1, fi->t_r.ptr_sest_len_reg); - /* the last 2 bits _should_ be 1 */ - writel(SEST_BUFFER_SIZE - 1, fi->t_r.ptr_scsibuff_len_reg); - - /* write AL_TIME & E_D_TOV into the registers */ - writel(TOV_VALUES, fi->t_r.ptr_fm_tov_reg); - /* Tell Tachyon to pick a Soft Assigned AL_PA */ - writel(LOOP_INIT_SOFT_ADDRESS, fi->t_r.ptr_fm_config_reg); - - /* Read the WWN from EEPROM . But, for now we assign it here. */ - writel(WORLD_WIDE_NAME_LOW, fi->t_r.ptr_fm_wwn_low_reg); - writel(WORLD_WIDE_NAME_HIGH, fi->t_r.ptr_fm_wwn_hi_reg); - - DPRINTK1("TACHYON initializing as L_Port...\n"); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - - LEAVE("write_to_tachyon_registers"); -} - - -static irqreturn_t tachyon_interrupt(int irq, void* dev_id, struct pt_regs* regs) -{ -struct Scsi_Host *host = dev_id; -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata *)host->hostdata; -struct fc_info *fi = hostdata->fi; -u_long flags; - spin_lock_irqsave(&fi->fc_lock, flags); - tachyon_interrupt_handler(irq, dev_id, regs); - spin_unlock_irqrestore(&fi->fc_lock, flags); - return IRQ_HANDLED; -} - -static void tachyon_interrupt_handler(int irq, void* dev_id, struct pt_regs* regs) -{ -struct Scsi_Host *host = dev_id; -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata *)host->hostdata; -struct fc_info *fi = hostdata->fi; -u_int *ptr_imq_entry; -u_int imq_int_type, current_IMQ_index = 0, prev_IMQ_index; -int index, no_of_entries = 0; - - DPRINTK("\n"); - ENTER("tachyon_interrupt"); - if (fi->q.host_imq_prod_indx != NULL) { - current_IMQ_index = ntohl(*(fi->q.host_imq_prod_indx)); - } - else { - /* _Should not_ happen */ - T_MSG("IMQ_indx NULL. DISABLING INTERRUPTS!!!\n"); - writel(0x0, fi->i_r.ptr_ichip_hw_control_reg); - } - - if (current_IMQ_index > fi->q.imq_cons_indx) - no_of_entries = current_IMQ_index - fi->q.imq_cons_indx; - else - if (current_IMQ_index < fi->q.imq_cons_indx) - no_of_entries = IMQ_LENGTH - (fi->q.imq_cons_indx - current_IMQ_index); - - if (no_of_entries == 0) { - u_int ichip_status; - ichip_status = readl(fi->i_r.ptr_ichip_hw_status_reg); - if (ichip_status & 0x20) { - /* Should _never_ happen. Might require a hard reset */ - T_MSG("Too bad... PCI Bus Error. Resetting (i)chip"); - reset_ichip(fi); - T_MSG("DISABLING INTERRUPTS!!!\n"); - writel(0x0, fi->i_r.ptr_ichip_hw_control_reg); - } - } - - prev_IMQ_index = current_IMQ_index; - for (index = 0; index < no_of_entries; index++) { - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - imq_int_type = ntohl(*ptr_imq_entry); - - completion_message_handler(fi, imq_int_type); - if ((fi->g.link_up == FALSE) && ((imq_int_type == MFS_BUF_WARN) || (imq_int_type == SFS_BUF_WARN) || (imq_int_type == IMQ_BUF_WARN))) - break; - update_IMQ_indx(fi, 1); - - /* Check for more entries */ - current_IMQ_index = ntohl(*(fi->q.host_imq_prod_indx)); - if (current_IMQ_index != prev_IMQ_index) { - no_of_entries++; - prev_IMQ_index = current_IMQ_index; - } - } /*end of for loop*/ - LEAVE("tachyon_interrupt"); - return; -} - - -static void handle_SFS_BUF_WARN_interrupt(struct fc_info *fi) -{ -int i; - ENTER("handle_SFS_BUF_WARN_interrupt"); - if (fi->g.link_up == FALSE) { - reset_tachyon(fi, SOFTWARE_RESET); - return; - } - /* Free up all but one entry in the Q. - */ - for (i = 0; i < ((SFSBQ_LENGTH - 1) * NO_OF_ENTRIES); i++) { - handle_SFS_interrupt(fi); - update_IMQ_indx(fi, 1); - } - LEAVE("handle_SFS_BUF_WARN_interrupt"); -} - -/* Untested_Code_Begin */ -static void handle_MFS_BUF_WARN_interrupt(struct fc_info *fi) -{ -int i; - ENTER("handle_MFS_BUF_WARN_interrupt"); - if (fi->g.link_up == FALSE) { - reset_tachyon(fi, SOFTWARE_RESET); - return; - } - /* FIXME: freeing up 8 entries. - */ - for (i = 0; i < NO_OF_ENTRIES; i++) { - handle_MFS_interrupt(fi); - update_IMQ_indx(fi, 1); - } - LEAVE("handle_MFS_BUF_WARN_interrupt"); -} -/*Untested_Code_End */ - -static void handle_IMQ_BUF_WARN_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry; -u_int imq_int_type, current_IMQ_index = 0, temp_imq_cons_indx; -int index, no_of_entries = 0; - - ENTER("handle_IMQ_BUF_WARN_interrupt"); - if (fi->g.link_up == FALSE) { - reset_tachyon(fi, SOFTWARE_RESET); - return; - } - current_IMQ_index = ntohl(*(fi->q.host_imq_prod_indx)); - - if (current_IMQ_index > fi->q.imq_cons_indx) - no_of_entries = current_IMQ_index - fi->q.imq_cons_indx; - else - if (current_IMQ_index < fi->q.imq_cons_indx) - no_of_entries = IMQ_LENGTH - (fi->q.imq_cons_indx - current_IMQ_index); - /* We don't want to look at the same IMQ entry again. - */ - temp_imq_cons_indx = fi->q.imq_cons_indx + 1; - if (no_of_entries != 0) - no_of_entries -= 1; - for (index = 0; index < no_of_entries; index++) { - ptr_imq_entry = fi->q.ptr_imqe[temp_imq_cons_indx]; - imq_int_type = ntohl(*ptr_imq_entry); - if (imq_int_type != IMQ_BUF_WARN) - completion_message_handler(fi, imq_int_type); - temp_imq_cons_indx++; - if (temp_imq_cons_indx == IMQ_LENGTH) - temp_imq_cons_indx = 0; - } /*end of for loop*/ - if (no_of_entries != 0) - update_IMQ_indx(fi, no_of_entries); - LEAVE("handle_IMQ_BUF_WARN_interrupt"); -} - -static void completion_message_handler(struct fc_info *fi, u_int imq_int_type) -{ - switch(imq_int_type) { - case OUTBOUND_COMPLETION: - DPRINTK("OUTBOUND_COMPLETION message received"); - break; - case OUTBOUND_COMPLETION_I: - DPRINTK("OUTBOUND_COMPLETION_I message received"); - handle_OCI_interrupt(fi); - break; - case OUT_HI_PRI_COMPLETION: - DPRINTK("OUT_HI_PRI_COMPLETION message received"); - break; - case OUT_HI_PRI_COMPLETION_I: - DPRINTK("OUT_HI_PRI_COMPLETION_I message received"); - break; - case INBOUND_MFS_COMPLETION: - DPRINTK("INBOUND_MFS_COMPLETION message received"); - handle_MFS_interrupt(fi); - break; - case INBOUND_OOO_COMPLETION: - DPRINTK("INBOUND_OOO_COMPLETION message received"); - handle_OOO_interrupt(fi); - break; - case INBOUND_SFS_COMPLETION: - DPRINTK("INBOUND_SFS_COMPLETION message received"); - handle_SFS_interrupt(fi); - break; - case INBOUND_UNKNOWN_FRAME_I: - DPRINTK("INBOUND_UNKNOWN_FRAME message received"); - handle_Unknown_Frame_interrupt(fi); - break; - case INBOUND_BUSIED_FRAME: - DPRINTK("INBOUND_BUSIED_FRAME message received"); - handle_Busied_Frame_interrupt(fi); - break; - case FRAME_MGR_INTERRUPT: - DPRINTK("FRAME_MGR_INTERRUPT message received"); - handle_FM_interrupt(fi); - break; - case READ_STATUS: - DPRINTK("READ_STATUS message received"); - break; - case SFS_BUF_WARN: - DPRINTK("SFS_BUF_WARN message received"); - handle_SFS_BUF_WARN_interrupt(fi); - break; - case MFS_BUF_WARN: - DPRINTK("MFS_BUF_WARN message received"); - handle_MFS_BUF_WARN_interrupt(fi); - break; - case IMQ_BUF_WARN: - DPRINTK("IMQ_BUF_WARN message received"); - handle_IMQ_BUF_WARN_interrupt(fi); - break; - case INBOUND_C1_TIMEOUT: - DPRINTK("INBOUND_C1_TIMEOUT message received"); - break; - case BAD_SCSI_FRAME: - DPRINTK("BAD_SCSI_FRAME message received"); - handle_Bad_SCSI_Frame_interrupt(fi); - break; - case INB_SCSI_STATUS_COMPLETION: - DPRINTK("INB_SCSI_STATUS_COMPL message received"); - handle_Inbound_SCSI_Status_interrupt(fi); - break; - case INBOUND_SCSI_COMMAND: - DPRINTK("INBOUND_SCSI_COMMAND message received"); - handle_Inbound_SCSI_Command_interrupt(fi); - break; - case INBOUND_SCSI_DATA_COMPLETION: - DPRINTK("INBOUND_SCSI_DATA message received"); - /* Only for targets */ - break; - default: - T_MSG("DEFAULT message received, type = %x", imq_int_type); - return; - } - reset_latch(fi); -} - -static void handle_OCI_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry; -u_long transaction_id = 0; -unsigned short status, seq_count, transmitted_ox_id; -struct Scsi_Host *host = fi->host; -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata *)host->hostdata; -Scsi_Cmnd *Cmnd; -u_int tag; - - ENTER("handle_OCI_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - transaction_id = ntohl(*(ptr_imq_entry + 1)); - status = ntohl(*(ptr_imq_entry + 2)) >> 16; - seq_count = ntohl(*(ptr_imq_entry + 3)); - DPRINTK("transaction_id= %x", (u_int)transaction_id); - tag = transaction_id & 0xFFFF0000; - transmitted_ox_id = transaction_id; - - /* The INT could be either due to TIME_OUT | BAD_ALPA. - * But we check only for TimeOuts. Bad AL_PA will - * caught by FM_interrupt handler. - */ - - if ((status == OCM_TIMEOUT_OR_BAD_ALPA) && (!fi->g.port_discovery) && (!fi->g.perform_adisc)){ - DPRINTK("Frame TimeOut on OX_ID = %x", (u_int)transaction_id); - - /* Is it a SCSI frame that is timing out ? Not a very good check... - */ - if ((transmitted_ox_id <= MAX_SCSI_OXID) && ((tag == FC_SCSI_BAD_TARGET) || (tag < 0x00FF0000))) { - /* If it is a Bad AL_PA, we report it as BAD_TARGET. - * Else, we allow the command to time-out. A Link - * re-initialization could be taking place. - */ - if (tag == FC_SCSI_BAD_TARGET) { - Cmnd = hostdata->cmnd_handler[transmitted_ox_id & MAX_SCSI_XID]; - hostdata->cmnd_handler[transmitted_ox_id & MAX_SCSI_XID] = NULL; - if (Cmnd != NULL) { - Cmnd->result = DID_BAD_TARGET << 16; - (*Cmnd->scsi_done) (Cmnd); - } - else - T_MSG("NULL Command out of handler!"); - } /* if Bad Target */ - else { - u_char missing_target = tag >> 16; - struct fc_node_info *q = fi->node_info_list; - /* A Node that we thought was logged in has gone - * away. We are the optimistic kind and we keep - * hoping that our dear little Target will come back - * to us. For now we log him out. - */ - DPRINTK2("Missing Target = %d", missing_target); - while (q != NULL) { - if (q->target_id == missing_target) { - T_MSG("Target %d Logged out", q->target_id); - q->login = LOGIN_ATTEMPTED; - if (fi->num_nodes > 0) - fi->num_nodes--; - tx_logi(fi, ELS_PLOGI, q->d_id); - break; - } - else - q = q->next; - } - } - } /* End of SCSI frame timing out. */ - else { - if (seq_count > 1) { - /* An IP frame was transmitted to a Bad AL_PA. Free up - * the skb used. - */ - dev_kfree_skb_irq((struct sk_buff *)(bus_to_virt(transaction_id))); - netif_wake_queue(fi->dev); - } - } /* End of IP frame timing out. */ - } /* End of frame timing out. */ - else { - /* Frame was transmitted successfully. Check if it was an ELS - * frame or an IP frame or a Bad_Target_Notification frame (in - * case of a ptp_link). Ugly! - */ - if ((status == 0) && (seq_count == 0)) { - u_int tag = transaction_id & 0xFFFF0000; - /* Continue with port discovery after an ELS is successfully - * transmitted. (status == 0). - */ - DPRINTK("tag = %x", tag); - switch(tag) { - case ELS_FLOGI: - /* Letz use the Name Server instead */ - fi->g.explore_fabric = TRUE; - fi->g.port_discovery = FALSE; - fi->g.alpa_list_index = MAX_NODES; - add_to_ox_id_list(fi, transaction_id, tag); - break; - case ELS_PLOGI: - if (fi->g.fabric_present && (fi->g.name_server == FALSE)) - add_to_ox_id_list(fi,transaction_id,ELS_NS_PLOGI); - else - add_to_ox_id_list(fi, transaction_id, tag); - break; - case FC_SCSI_BAD_TARGET: - Cmnd = hostdata->cmnd_handler[transmitted_ox_id & MAX_SCSI_XID]; - hostdata->cmnd_handler[transmitted_ox_id & MAX_SCSI_XID] = NULL; - if (Cmnd != NULL) { - Cmnd->result = DID_BAD_TARGET << 16; - (*Cmnd->scsi_done) (Cmnd); - } - else - T_MSG("NULL Command out of handler!"); - break; - default: - add_to_ox_id_list(fi, transaction_id, tag); - } - - if (fi->g.alpa_list_index >= MAX_NODES) { - if (fi->g.port_discovery == TRUE) { - fi->g.port_discovery = FALSE; - add_display_cache_timer(fi); - } - fi->g.alpa_list_index = MAX_NODES; - } - if (fi->g.port_discovery == TRUE) - local_port_discovery(fi); - } - else { - /* An IP frame has been successfully transmitted. - * Free the skb that was used for this IP frame. - */ - if ((status == 0) && (seq_count > 1)) { - dev_kfree_skb_irq((struct sk_buff *)(bus_to_virt(transaction_id))); - netif_wake_queue(fi->dev); - } - } - } - LEAVE("handle_OCI_interrupt"); -} - -/* Right now we discard OOO frames */ -static void handle_OOO_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry; -int queue_indx, offset, payload_size; -int no_of_buffers = 1; /* header is in a separate buffer */ - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - payload_size = ntohl(*(ptr_imq_entry + 2)) - TACHYON_HEADER_LEN; - /* Calculate total number of buffers */ - no_of_buffers += payload_size / MFS_BUFFER_SIZE; - if (payload_size % MFS_BUFFER_SIZE) - no_of_buffers++; - - /* provide Tachyon will another set of buffers */ - fi->g.mfs_buffer_count += no_of_buffers; - if (fi->g.mfs_buffer_count >= NO_OF_ENTRIES) { - int count = fi->g.mfs_buffer_count / NO_OF_ENTRIES; - fi->g.mfs_buffer_count -= NO_OF_ENTRIES * count; - update_MFSBQ_indx(fi, count); - } -} - -static void handle_MFS_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry, *buff_addr; -u_int type_of_frame, s_id; -int queue_indx, offset, payload_size, starting_indx, starting_offset; -u_short received_ox_id; -int no_of_buffers = 1; /* header is in a separate buffer */ -struct sk_buff *skb; -int wrap_around = FALSE, no_of_wrap_buffs = NO_OF_ENTRIES - 1; - ENTER("handle_MFS_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - DPRINTK("queue_indx = %d, offset = %d\n", queue_indx, offset); - payload_size = ntohl(*(ptr_imq_entry + 2)) - TACHYON_HEADER_LEN; - DPRINTK("payload_size = %d", payload_size); - /* Calculate total number of buffers */ - no_of_buffers += payload_size / MFS_BUFFER_SIZE; - if (payload_size % MFS_BUFFER_SIZE) - no_of_buffers++; - DPRINTK("no_of_buffers = %d", no_of_buffers); - - if ((no_of_buffers - 1) <= offset) { - starting_offset = offset - (no_of_buffers - 1); - starting_indx = queue_indx; - } - else { - int temp = no_of_buffers - (offset + 1); - int no_of_queues = temp / NO_OF_ENTRIES; - starting_offset = temp % NO_OF_ENTRIES; - if (starting_offset != 0) { - no_of_wrap_buffs = starting_offset - 1; //exclude header - starting_offset = NO_OF_ENTRIES - starting_offset; - no_of_queues++; - } - starting_indx = queue_indx - no_of_queues; - if (starting_indx < 0) { - no_of_wrap_buffs -= (starting_indx + 1) * NO_OF_ENTRIES; - starting_indx = MFSBQ_LENGTH + starting_indx; - wrap_around = TRUE; - } - } - - DPRINTK("starting_indx = %d, starting offset = %d no_of_wrap_buffs = %d\n", starting_indx, starting_offset, no_of_wrap_buffs); - /* Get Tachyon Header from first buffer */ - buff_addr = bus_to_virt(ntohl(*(fi->q.ptr_mfsbq_base + starting_indx*NO_OF_ENTRIES + starting_offset))); - - - /* extract Type of Frame */ - type_of_frame = (u_int)ntohl(*(buff_addr + 4)) & 0xFF000000; - s_id = (u_int)ntohl(*(buff_addr + 3)) & 0x00FFFFFF; - received_ox_id = ntohl(*(buff_addr + 6)) >> 16; - buff_addr += MFS_BUFFER_SIZE/4; - DPRINTK("type_of_frame = %x, s_id = %x, ox_id = %x", type_of_frame, s_id, received_ox_id); - - switch(type_of_frame) { - case TYPE_LLC_SNAP: - skb = dev_alloc_skb(payload_size); - if (skb == NULL) { - printk(KERN_NOTICE "%s: In handle_MFS_interrupt() Memory squeeze, dropping packet.\n", fi->name); - fi->fc_stats.rx_dropped++; - fi->g.mfs_buffer_count += no_of_buffers; - if (fi->g.mfs_buffer_count >= NO_OF_ENTRIES) { - int count = fi->g.mfs_buffer_count / NO_OF_ENTRIES; - fi->g.mfs_buffer_count -= NO_OF_ENTRIES * count; - update_MFSBQ_indx(fi, count); - } - return; - } - if (wrap_around) { - int wrap_size = no_of_wrap_buffs * MFS_BUFFER_SIZE; - int tail_size = payload_size - wrap_size; - DPRINTK("wrap_size = %d, tail_size = %d\n", wrap_size, tail_size); - if (no_of_wrap_buffs) - memcpy(skb_put(skb, wrap_size), buff_addr, wrap_size); - buff_addr = bus_to_virt(ntohl(*(fi->q.ptr_mfsbq_base))); - memcpy(skb_put(skb, tail_size), buff_addr, tail_size); - } - else - memcpy(skb_put(skb, payload_size), buff_addr, payload_size); - rx_net_mfs_packet(fi, skb); - break; - default: - T_MSG("Unknown Frame Type received. Type = %x", type_of_frame); - } - - /* provide Tachyon will another set of buffers */ - fi->g.mfs_buffer_count += no_of_buffers; - if (fi->g.mfs_buffer_count >= NO_OF_ENTRIES) { - int count = fi->g.mfs_buffer_count / NO_OF_ENTRIES; - fi->g.mfs_buffer_count -= NO_OF_ENTRIES * count; - update_MFSBQ_indx(fi, count); - } - LEAVE("handle_MFS_interrupt"); -} - -static void handle_Unknown_Frame_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry; -int queue_indx, offset; - ENTER("handle_Unknown_Frame_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - /* We discard the "unknown" frame */ - /* provide Tachyon will another set of buffers */ - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - LEAVE("handle_Unknown_Frame_interrupt"); -} - -static void handle_Busied_Frame_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry; -int queue_indx, offset; - ENTER("handle_Busied_Frame_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - /* We discard the "busied" frame */ - /* provide Tachyon will another set of buffers */ - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - LEAVE("handle_Busied_Frame_interrupt"); -} - -static void handle_Bad_SCSI_Frame_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry, *buff_addr, *tach_header, *ptr_edb; -u_int s_id, rctl, frame_class, burst_len, transfered_len, len = 0; -int queue_indx, offset, payload_size, i; -u_short ox_id, rx_id, x_id, mtu = 512; -u_char target_id = 0xFF; - - ENTER("handle_Bad_SCSI_Frame_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - payload_size = ntohl(*(ptr_imq_entry + 2)); - - buff_addr = bus_to_virt(ntohl(*(fi->q.ptr_sfsbq_base + queue_indx*NO_OF_ENTRIES + offset))); - - rctl = ntohl(*(buff_addr + 2)) & 0xFF000000; - s_id = ntohl(*(buff_addr + 3)) & 0x00FFFFFF; - ox_id = ntohl(*(buff_addr + 6)) >> 16; - rx_id = ntohl(*(buff_addr + 6)); - x_id = ox_id & MAX_SCSI_XID; - - /* Any frame that comes in with OX_ID that matches an OX_ID - * that has been allocated for SCSI, will be called a Bad - * SCSI frame if the Exchange is not valid any more. - * - * We will also get a Bad SCSI frame interrupt if we receive - * a XFER_RDY with offset != 0. Tachyon washes its hands off - * this Exchange. We have to take care of ourselves. Grrr... - */ - if (rctl == DATA_DESCRIPTOR) { - struct fc_node_info *q = fi->node_info_list; - while (q != NULL) { - if (q->d_id == s_id) { - target_id = q->target_id; - mtu = q->mtu; - break; - } - else - q = q->next; - } - frame_class = target_id; - transfered_len = ntohl(*(buff_addr + 8)); - burst_len = ntohl(*(buff_addr + 9)); - - build_ODB(fi, fi->g.seq_id, s_id, burst_len, 0, mtu, ox_id, rx_id, 0, 0, frame_class << 16); - /* Update the SEQ_ID and Relative Offset in the - * Tachyon Header Structure. - */ - tach_header = bus_to_virt(ntohl(*(fi->q.ptr_sest[x_id] + 5))); - *(tach_header + 5) = htonl(fi->g.seq_id << 24); - *(tach_header + 7) = htonl(transfered_len); - fi->g.odb.hdr_addr = *(fi->q.ptr_sest[x_id] + 5); - - /* Invalidate the EDBs used - */ - ptr_edb = bus_to_virt(ntohl(*(fi->q.ptr_sest[x_id] + 7))); - - for (i = 0; i < EDB_LEN; i++) - if (fi->q.ptr_edb[i] == ptr_edb) - break; - ptr_edb--; - - if (i < EDB_LEN) { - int j; - do { - ptr_edb += 2; - len += (htonl(*ptr_edb) & 0xFFFF); - j = i; - fi->q.free_edb_list[i++] = EDB_FREE; - if (i == EDB_LEN) { - i = 0; - ptr_edb = fi->q.ptr_edb_base - 1; - } - } while (len < transfered_len); - if (len > transfered_len) { - ptr_edb--; - fi->q.free_edb_list[j] = EDB_BUSY; - } - else - ptr_edb++; - } - else { - T_MSG("EDB not found while freeing"); - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - return; - } - - /* Update the EDB pointer in the ODB. - */ - fi->g.odb.edb_addr = htonl(virt_to_bus(ptr_edb)); - memcpy(fi->q.ptr_odb[fi->q.ocq_prod_indx], &(fi->g.odb), sizeof(ODB)); - /* Update the EDB pointer in the SEST entry. We might need - * this if get another XFER_RDY for the same Exchange. - */ - *(fi->q.ptr_sest[x_id] + 7) = htonl(virt_to_bus(ptr_edb)); - - update_OCQ_indx(fi); - if (fi->g.seq_id == MAX_SEQ_ID) - fi->g.seq_id = 0; - else - fi->g.seq_id++; - } - else - /* Could be a BA_ACC or a BA_RJT. - */ - if (rctl == RCTL_BASIC_ACC) { - u_int bls_type = remove_from_ox_id_list(fi, ox_id); - DPRINTK1("BA_ACC received from S_ID 0x%x with OX_ID = %x in response to %x", s_id, ox_id, bls_type); - if (bls_type == RCTL_BASIC_ABTS) { - u_int STE_bit; - /* Invalidate resources for that Exchange. - */ - STE_bit = ntohl(*fi->q.ptr_sest[x_id]); - if (STE_bit & SEST_V) { - *(fi->q.ptr_sest[x_id]) &= htonl(SEST_INV); - invalidate_SEST_entry(fi, ox_id); - } - } - } - else - if (rctl == RCTL_BASIC_RJT) { - u_int bls_type = remove_from_ox_id_list(fi, ox_id); - DPRINTK1("BA_RJT received from S_ID 0x%x with OX_ID = %x in response to %x", s_id, ox_id, bls_type); - if (bls_type == RCTL_BASIC_ABTS) { - u_int STE_bit; - /* Invalidate resources for that Exchange. - */ - STE_bit = ntohl(*fi->q.ptr_sest[x_id]); - if (STE_bit & SEST_V) { - *(fi->q.ptr_sest[x_id]) &= htonl(SEST_INV); - invalidate_SEST_entry(fi, ox_id); - } - } - } - else - DPRINTK1("Frame with R_CTL = %x received from S_ID 0x%x with OX_ID %x", rctl, s_id, ox_id); - - /* Else, discard the "Bad" SCSI frame. - */ - - /* provide Tachyon will another set of buffers - */ - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - LEAVE("handle_Bad_SCSI_Frame_interrupt"); -} - -static void handle_Inbound_SCSI_Status_interrupt(struct fc_info *fi) -{ -struct Scsi_Host *host = fi->host; -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata *)host->hostdata; -u_int *ptr_imq_entry, *buff_addr, *ptr_rsp_info, *ptr_sense_info = NULL; -int queue_indx, offset, payload_size; -u_short received_ox_id, x_id; -Scsi_Cmnd *Cmnd; -u_int fcp_status, fcp_rsp_info_len = 0, fcp_sense_info_len = 0, s_id; - ENTER("handle_SCSI_status_interrupt"); - - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - buff_addr = bus_to_virt(ntohl(*(fi->q.ptr_sfsbq_base + queue_indx*NO_OF_ENTRIES + offset))); - payload_size = ntohl(*(ptr_imq_entry + 2)); - received_ox_id = ntohl(*(buff_addr + 6)) >> 16; - - buff_addr = bus_to_virt(ntohl(*(fi->q.ptr_sfsbq_base + queue_indx*NO_OF_ENTRIES + offset))); - - fcp_status = ntohl(*(buff_addr + 10)); - ptr_rsp_info = buff_addr + 14; - if (fcp_status & FCP_STATUS_RSP_LEN) - fcp_rsp_info_len = ntohl(*(buff_addr + 13)); - - if (fcp_status & FCP_STATUS_SENSE_LEN) { - ptr_sense_info = ptr_rsp_info + fcp_rsp_info_len / 4; - fcp_sense_info_len = ntohl(*(buff_addr + 12)); - DPRINTK("sense_info = %x", (u_int)ntohl(*ptr_sense_info)); - } - DPRINTK("fcp_status = %x, fcp_rsp_len = %x", fcp_status, fcp_rsp_info_len); - x_id = received_ox_id & MAX_SCSI_XID; - Cmnd = hostdata->cmnd_handler[x_id]; - hostdata->cmnd_handler[x_id] = NULL; - if (Cmnd != NULL) { - memset(Cmnd->sense_buffer, 0, sizeof(Cmnd->sense_buffer)); - /* Check if there is a Sense field */ - if (fcp_status & FCP_STATUS_SENSE_LEN) { - int size = sizeof(Cmnd->sense_buffer); - if (fcp_sense_info_len < size) - size = fcp_sense_info_len; - memcpy(Cmnd->sense_buffer, (char *)ptr_sense_info, size); - } - Cmnd->result = fcp_status & FCP_STATUS_MASK; - (*Cmnd->scsi_done) (Cmnd); - } - else - T_MSG("NULL Command out of handler!"); - - invalidate_SEST_entry(fi, received_ox_id); - s_id = ntohl(*(buff_addr + 3)) & 0x00FFFFFF; - fi->q.free_scsi_oxid[x_id] = OXID_AVAILABLE; - - /* provide Tachyon will another set of buffers */ - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - LEAVE("handle_SCSI_status_interrupt"); -} - -static void invalidate_SEST_entry(struct fc_info *fi, u_short received_ox_id) -{ -u_short x_id = received_ox_id & MAX_SCSI_XID; - /* Invalidate SEST entry if it is an OutBound SEST Entry - */ - if (!(received_ox_id & SCSI_READ_BIT)) { - u_int *ptr_tach_header, *ptr_edb; - u_short temp_ox_id = NOT_SCSI_XID; - int i; - *(fi->q.ptr_sest[x_id]) &= htonl(SEST_INV); - - /* Invalidate the Tachyon Header structure - */ - ptr_tach_header = bus_to_virt(ntohl(*(fi->q.ptr_sest[x_id] + 5))); - for (i = 0; i < NO_OF_TACH_HEADERS; i++) - if(fi->q.ptr_tachyon_header[i] == ptr_tach_header) - break; - if (i < NO_OF_TACH_HEADERS) - memset(ptr_tach_header, 0xFF, 32); - else - T_MSG("Tachyon Header not found while freeing in invalidate_SEST_entry()"); - - /* Invalidate the EDB used - */ - ptr_edb = bus_to_virt(ntohl(*(fi->q.ptr_sest[x_id] + 7))); - for (i = 0; i < EDB_LEN; i++) - if (fi->q.ptr_edb[i] == ptr_edb) - break; - ptr_edb--; - if (i < EDB_LEN) { - do { - ptr_edb += 2; - fi->q.free_edb_list[i++] = EDB_FREE; - if (i == EDB_LEN) { - i = 0; - ptr_edb = fi->q.ptr_edb_base - 1; - } - } while ((htonl(*ptr_edb) & 0x80000000) != 0x80000000); - } - else - T_MSG("EDB not found while freeing in invalidate_SEST_entry()"); - - /* Search for its other header structure and destroy it! - */ - if ((ptr_tach_header + 16) < (fi->q.ptr_tachyon_header_base + (MY_PAGE_SIZE/4))) - ptr_tach_header += 16; - else - ptr_tach_header = fi->q.ptr_tachyon_header_base; - while (temp_ox_id != x_id) { - temp_ox_id = ntohl(*(ptr_tach_header + 6)) >> 16; - if (temp_ox_id == x_id) { - /* Paranoid checking... - */ - for (i = 0; i < NO_OF_TACH_HEADERS; i++) - if(fi->q.ptr_tachyon_header[i] == ptr_tach_header) - break; - if (i < NO_OF_TACH_HEADERS) - memset(ptr_tach_header, 0xFF, 32); - else - T_MSG("Tachyon Header not found while freeing in invalidate_SEST_entry()"); - break; - } - else { - if ((ptr_tach_header + 16) < (fi->q.ptr_tachyon_header_base + (MY_PAGE_SIZE/4))) - ptr_tach_header += 16; - else - ptr_tach_header = fi->q.ptr_tachyon_header_base; - } - } - } - else { - u_short sdb_table_indx; - /* An Inbound Command has completed or needs to be Aborted. - * Clear up the SDB buffers. - */ - sdb_table_indx = *(fi->q.ptr_sest[x_id] + 5); - fi->q.sdb_slot_status[sdb_table_indx] = SDB_FREE; - } -} - -static void handle_Inbound_SCSI_Command_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry; -int queue_indx, offset; - ENTER("handle_Inbound_SCSI_Command_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - /* We discard the SCSI frame as we shouldn't be receiving - * a SCSI Command in the first place - */ - /* provide Tachyon will another set of buffers */ - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - LEAVE("handle_Inbound_SCSI_Command_interrupt"); -} - -static void handle_SFS_interrupt(struct fc_info *fi) -{ -u_int *ptr_imq_entry, *buff_addr; -u_int class_of_frame, type_of_frame, s_id, els_type = 0, rctl; -int queue_indx, offset, payload_size, login_state; -u_short received_ox_id, fs_cmnd_code; - ENTER("handle_SFS_interrupt"); - ptr_imq_entry = fi->q.ptr_imqe[fi->q.imq_cons_indx]; - offset = ntohl(*(ptr_imq_entry + 1)) & 0x00000007; - queue_indx = ntohl(*(ptr_imq_entry + 1)) & 0xFFFF0000; - queue_indx = queue_indx >> 16; - DPRINTK("queue_indx = %d, offset = %d\n", queue_indx, offset); - payload_size = ntohl(*(ptr_imq_entry + 2)); - DPRINTK("payload_size = %d", payload_size); - - buff_addr = bus_to_virt(ntohl(*(fi->q.ptr_sfsbq_base + queue_indx*NO_OF_ENTRIES + offset))); - - /* extract Type of Frame */ - type_of_frame = ntohl(*(buff_addr + 4)) & 0xFF000000; - s_id = ntohl(*(buff_addr + 3)) & 0x00FFFFFF; - received_ox_id = ntohl(*(buff_addr + 6)) >> 16; - switch(type_of_frame) { - case TYPE_BLS: - rctl = ntohl(*(buff_addr + 2)) & 0xFF000000; - switch(rctl) { - case RCTL_BASIC_ABTS: - /* As an Initiator, we should never be receiving - * this. - */ - DPRINTK1("ABTS received from S_ID 0x%x with OX_ID = %x", s_id, received_ox_id); - break; - } - break; - case TYPE_ELS: - class_of_frame = ntohl(*(buff_addr + 8)); - login_state = sid_logged_in(fi, s_id); - switch(class_of_frame & 0xFF000000) { - case ELS_PLOGI: - if (s_id != fi->g.my_id) { - u_int ret_code; - DPRINTK1("PLOGI received from D_ID 0x%x with 0X_ID = %x", s_id, received_ox_id); - if ((ret_code = plogi_ok(fi, buff_addr, payload_size)) == 0){ - tx_logi_acc(fi, ELS_ACC, s_id, received_ox_id); - add_to_address_cache(fi, buff_addr); - } - else { - u_short cmnd_code = ret_code >> 16; - u_short expln_code = ret_code; - tx_ls_rjt(fi, s_id, received_ox_id, cmnd_code, expln_code); - } - } - break; - case ELS_ACC: - els_type = remove_from_ox_id_list(fi, received_ox_id); - DPRINTK1("ELS_ACC received from D_ID 0x%x in response to ELS %x", s_id, els_type); - switch(els_type) { - case ELS_PLOGI: - add_to_address_cache(fi, buff_addr); - tx_prli(fi, ELS_PRLI, s_id, OX_ID_FIRST_SEQUENCE); - break; - case ELS_FLOGI: - add_to_address_cache(fi, buff_addr); - fi->g.my_id = ntohl(*(buff_addr + 2)) & 0x00FFFFFF; - fi->g.fabric_present = TRUE; - fi->g.my_ddaa = fi->g.my_id & 0xFFFF00; - /* Login to the Name Server - */ - tx_logi(fi, ELS_PLOGI, DIRECTORY_SERVER); - break; - case ELS_NS_PLOGI: - fi->g.name_server = TRUE; - add_to_address_cache(fi, buff_addr); - tx_name_server_req(fi, FCS_RFC_4); - tx_scr(fi); - /* Some devices have a delay before - * registering with the Name Server - */ - udelay(500); - tx_name_server_req(fi, FCS_GP_ID4); - break; - case ELS_PRLI: - mark_scsi_sid(fi, buff_addr, ADD_ENTRY); - break; - case ELS_ADISC: - if (!(validate_login(fi, buff_addr))) - tx_logo(fi, s_id, OX_ID_FIRST_SEQUENCE); - break; - } - break; - case ELS_PDISC: - DPRINTK1("ELS_PDISC received from D_ID 0x%x", s_id); - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_ADISC: - DPRINTK1("ELS_ADISC received from D_ID 0x%x", s_id); - if (node_logged_in_prev(fi, buff_addr)) - tx_adisc(fi, ELS_ACC, s_id, received_ox_id); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_PRLI: - DPRINTK1("ELS_PRLI received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) { - tx_prli(fi, ELS_ACC, s_id, received_ox_id); - mark_scsi_sid(fi, buff_addr, ADD_ENTRY); - } - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_PRLO: - DPRINTK1("ELS_PRLO received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_OUT) || (login_state == NODE_NOT_PRESENT)) - tx_logo(fi, s_id, received_ox_id); - else - if (login_state == NODE_LOGGED_IN) - - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - if (login_state == NODE_PROCESS_LOGGED_IN) { - tx_prli(fi, ELS_ACC, s_id, received_ox_id); - mark_scsi_sid(fi, buff_addr, DELETE_ENTRY); - } - break; - case ELS_LS_RJT: - els_type = remove_from_ox_id_list(fi, received_ox_id); - DPRINTK1("ELS_LS_RJT received from D_ID 0x%x in response to %x", s_id, els_type); - /* We should be chking the reason code. - */ - switch (els_type) { - case ELS_ADISC: - tx_logi(fi, ELS_PLOGI, s_id); - break; - } - break; - case ELS_LOGO: - els_type = remove_from_ox_id_list(fi, received_ox_id); - DPRINTK1("ELS_LOGO received from D_ID 0x%x in response to %x", s_id, els_type); - remove_from_address_cache(fi, buff_addr, ELS_LOGO); - tx_acc(fi, s_id, received_ox_id); - if (els_type == ELS_ADISC) - tx_logi(fi, ELS_PLOGI, s_id); - break; - case ELS_RSCN: - DPRINTK1("ELS_RSCN received from D_ID 0x%x", s_id); - tx_acc(fi, s_id, received_ox_id); - remove_from_address_cache(fi, buff_addr, ELS_RSCN); - break; - case ELS_FARP_REQ: - /* We do not support FARP. - So, silently discard it */ - DPRINTK1("ELS_FARP_REQ received from D_ID 0x%x", s_id); - break; - case ELS_ABTX: - DPRINTK1("ELS_ABTX received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_FLOGI: - DPRINTK1("ELS_FLOGI received from D_ID 0x%x", s_id); - if (fi->g.ptp_up == TRUE) { - /* The node could have come up as an N_Port - * in a Loop! So,try initializing as an NL_port - */ - take_tachyon_offline(fi); - /* write AL_TIME & E_D_TOV into the registers */ - writel(TOV_VALUES, fi->t_r.ptr_fm_tov_reg); - writel(LOOP_INIT_SOFT_ADDRESS, fi->t_r.ptr_fm_config_reg); - DPRINTK1("FLOGI received, TACHYON initializing as L_Port...\n"); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - } - else { - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - } - break; - case ELS_ADVC: - DPRINTK1("ELS_ADVC received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_ECHO: - DPRINTK1("ELS_ECHO received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_ESTC: - DPRINTK1("ELS_ESTC received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_ESTS: - DPRINTK1("ELS_ESTS received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RCS: - DPRINTK1("ELS_RCS received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RES: - DPRINTK1("ELS_RES received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RLS: - DPRINTK1("ELS_RLS received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RRQ: - DPRINTK1("ELS_RRQ received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RSS: - DPRINTK1("ELS_RSS received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RTV: - DPRINTK1("ELS_RTV received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RSI: - DPRINTK1("ELS_RSI received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_TEST: - /* No reply sequence */ - DPRINTK1("ELS_TEST received from D_ID 0x%x", s_id); - break; - case ELS_RNC: - DPRINTK1("ELS_RNC received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_RVCS: - DPRINTK1("ELS_RVCS received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_TPLS: - DPRINTK1("ELS_TPLS received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_GAID: - DPRINTK1("ELS_GAID received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_FACT: - DPRINTK1("ELS_FACT received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_FAN: - /* Hmmm... You don't support FAN ??? */ - DPRINTK1("ELS_FAN received from D_ID 0x%x", s_id); - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - break; - case ELS_FDACT: - DPRINTK1("ELS_FDACT received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_NACT: - DPRINTK1("ELS_NACT received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_NDACT: - DPRINTK1("ELS_NDACT received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_QoSR: - DPRINTK1("ELS_QoSR received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - case ELS_FDISC: - DPRINTK1("ELS_FDISC received from D_ID 0x%x", s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - default: - DPRINTK1("ELS Frame %x received from D_ID 0x%x", class_of_frame, s_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) - tx_ls_rjt(fi, s_id, received_ox_id, CMND_NOT_SUPP, NO_EXPLN); - else - tx_logo(fi, s_id, received_ox_id); - break; - } - break; - case TYPE_FC_SERVICES: - fs_cmnd_code = (ntohl(*(buff_addr + 10)) & 0xFFFF0000) >>16; - switch(fs_cmnd_code) { - case FCS_ACC: - els_type = remove_from_ox_id_list(fi, received_ox_id); - DPRINTK1("FCS_ACC received from D_ID 0x%x in response to %x", s_id, els_type); - if (els_type == FCS_GP_ID4) - explore_fabric(fi, buff_addr); - break; - case FCS_REJECT: - DPRINTK1("FCS_REJECT received from D_ID 0x%x in response to %x", s_id, els_type); - break; - } - break; - case TYPE_LLC_SNAP: - rx_net_packet(fi, (u_char *)buff_addr, payload_size); - break; - default: - T_MSG("Frame Type %x received from %x", type_of_frame, s_id); - } - - /* provide Tachyon will another set of buffers */ - if (offset == (NO_OF_ENTRIES - 1)) - update_SFSBQ_indx(fi); - LEAVE("handle_SFS_interrupt"); -} - -static void handle_FM_interrupt(struct fc_info *fi) -{ -u_int fm_status; -u_int tachyon_status; - - ENTER("handle_FM_interrupt"); - fm_status = readl(fi->t_r.ptr_fm_status_reg); - tachyon_status = readl(fi->t_r.ptr_tach_status_reg); - DPRINTK("FM_status = %x, Tachyon_status = %x", fm_status, tachyon_status); - if (fm_status & LINK_DOWN) { - T_MSG("Fibre Channel Link DOWN"); - fm_status = readl(fi->t_r.ptr_fm_status_reg); - - del_timer(&fi->explore_timer); - del_timer(&fi->nport_timer); - del_timer(&fi->lport_timer); - del_timer(&fi->display_cache_timer); - fi->g.link_up = FALSE; - if (fi->g.ptp_up == TRUE) - fi->g.n_port_try = FALSE; - fi->g.ptp_up = FALSE; - fi->g.port_discovery = FALSE; - fi->g.explore_fabric = FALSE; - fi->g.perform_adisc = FALSE; - - /* Logout will all nodes */ - if (fi->node_info_list) { - struct fc_node_info *temp_list = fi->node_info_list; - while(temp_list) { - temp_list->login = LOGIN_ATTEMPTED; - temp_list = temp_list->next; - } - fi->num_nodes = 0; - } - - if ((fi->g.n_port_try == FALSE) && (fi->g.dont_init == FALSE)){ - take_tachyon_offline(fi); - /* write AL_TIME & E_D_TOV into the registers */ - writel(TOV_VALUES, fi->t_r.ptr_fm_tov_reg); - - if ((fi->g.fabric_present == TRUE) && (fi->g.loop_up == TRUE)) { - u_int al_pa = fi->g.my_id & 0xFF; - writel((al_pa << 24) | LOOP_INIT_FABRIC_ADDRESS | LOOP_INIT_PREVIOUS_ADDRESS, fi->t_r.ptr_fm_config_reg); - } - else - if (fi->g.loop_up == TRUE) { - u_int al_pa = fi->g.my_id & 0xFF; - writel((al_pa << 24) | LOOP_INIT_PREVIOUS_ADDRESS, fi->t_r.ptr_fm_config_reg); - } - else - writel(LOOP_INIT_SOFT_ADDRESS, fi->t_r.ptr_fm_config_reg); - fi->g.loop_up = FALSE; - DPRINTK1("In LDWN TACHYON initializing as L_Port...\n"); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - } - } - - if (fm_status & NON_PARTICIPATING) { - T_MSG("Did not acquire an AL_PA. I am not participating"); - } - else - if ((fm_status & LINK_UP) && ((fm_status & LINK_DOWN) == 0)) { - T_MSG("Fibre Channel Link UP"); - if ((fm_status & NON_PARTICIPATING) != TRUE) { - fi->g.link_up = TRUE; - if (tachyon_status & OSM_FROZEN) { - reset_tachyon(fi, ERROR_RELEASE); - reset_tachyon(fi, OCQ_RESET); - } - init_timer(&fi->explore_timer); - init_timer(&fi->nport_timer); - init_timer(&fi->lport_timer); - init_timer(&fi->display_cache_timer); - if ((fm_status & OLD_PORT) == 0) { - fi->g.loop_up = TRUE; - fi->g.ptp_up = FALSE; - fi->g.my_id = readl(fi->t_r.ptr_fm_config_reg) >> 24; - DPRINTK1("My AL_PA = %x", fi->g.my_id); - fi->g.port_discovery = TRUE; - fi->g.explore_fabric = FALSE; - } - else - if (((fm_status & 0xF0) == OLD_PORT) && ((fm_status & 0x0F) == PORT_STATE_ACTIVE)) { - fi->g.loop_up = FALSE; - fi->g.my_id = 0x0; - /* In a point-to-point configuration, we expect to be - * connected to an F_Port. This driver does not yet support - * a configuration where it is connected to another N_Port - * directly. - */ - fi->g.explore_fabric = TRUE; - fi->g.port_discovery = FALSE; - if (fi->g.n_port_try == FALSE) { - take_tachyon_offline(fi); - /* write R_T_TOV & E_D_TOV into the registers */ - writel(PTP_TOV_VALUES, fi->t_r.ptr_fm_tov_reg); - writel(BB_CREDIT | NPORT, fi->t_r.ptr_fm_config_reg); - fi->g.n_port_try = TRUE; - DPRINTK1("In LUP TACHYON initializing as N_Port...\n"); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - } - else { - fi->g.ptp_up = TRUE; - tx_logi(fi, ELS_FLOGI, F_PORT); - } - } - fi->g.my_ddaa = 0x0; - fi->g.fabric_present = FALSE; - /* We havn't sent out any Name Server Reqs */ - fi->g.name_server = FALSE; - fi->g.alpa_list_index = 0; - fi->g.ox_id = NOT_SCSI_XID; - fi->g.my_mtu = TACH_FRAME_SIZE; - - /* Implicitly LOGO with all logged-in nodes. - */ - if (fi->node_info_list) { - struct fc_node_info *temp_list = fi->node_info_list; - while(temp_list) { - temp_list->login = LOGIN_ATTEMPTED; - temp_list = temp_list->next; - } - fi->num_nodes = 0; - fi->g.perform_adisc = TRUE; - //fi->g.perform_adisc = FALSE; - fi->g.port_discovery = FALSE; - tx_logi(fi, ELS_FLOGI, F_PORT); - } - else { - /* If Link coming up for the _first_ time or no nodes - * were logged in before... - */ - fi->g.scsi_oxid = 0; - fi->g.seq_id = 0x00; - fi->g.perform_adisc = FALSE; - } - - /* reset OX_ID table */ - while (fi->ox_id_list) { - struct ox_id_els_map *temp = fi->ox_id_list; - fi->ox_id_list = fi->ox_id_list->next; - kfree(temp); - } - fi->ox_id_list = NULL; - } /* End of if partipating */ - } - - if (fm_status & ELASTIC_STORE_ERROR) { - /* Too much junk on the Link - */ - /* Trying to clear it up by Txing PLOGI to urself */ - if (fi->g.link_up == TRUE) - tx_logi(fi, ELS_PLOGI, fi->g.my_id); - } - - if (fm_status & LOOP_UP) { - if (tachyon_status & OSM_FROZEN) { - reset_tachyon(fi, ERROR_RELEASE); - reset_tachyon(fi, OCQ_RESET); - } - } - - if (fm_status & NOS_OLS_RECEIVED){ - if (fi->g.nport_timer_set == FALSE) { - DPRINTK("NOS/OLS Received"); - DPRINTK("FM_status = %x", fm_status); - fi->nport_timer.function = nos_ols_timer; - fi->nport_timer.data = (unsigned long)fi; - fi->nport_timer.expires = RUN_AT((3*HZ)/100); /* 30 msec */ - init_timer(&fi->nport_timer); - add_timer(&fi->nport_timer); - fi->g.nport_timer_set = TRUE; - } - } - - if (((fm_status & 0xF0) == OLD_PORT) && (((fm_status & 0x0F) == PORT_STATE_LF1) || ((fm_status & 0x0F) == PORT_STATE_LF2))) { - DPRINTK1("Link Fail-I in OLD-PORT."); - take_tachyon_offline(fi); - reset_tachyon(fi, SOFTWARE_RESET); - } - - if (fm_status & LOOP_STATE_TIMEOUT){ - if ((fm_status & 0xF0) == ARBITRATING) - DPRINTK1("ED_TOV timesout.In ARBITRATING state..."); - if ((fm_status & 0xF0) == ARB_WON) - DPRINTK1("ED_TOV timesout.In ARBITRATION WON state..."); - if ((fm_status & 0xF0) == OPEN) - DPRINTK1("ED_TOV timesout.In OPEN state..."); - if ((fm_status & 0xF0) == OPENED) - DPRINTK1("ED_TOV timesout.In OPENED state..."); - if ((fm_status & 0xF0) == TX_CLS) - DPRINTK1("ED_TOV timesout.In XMITTED CLOSE state..."); - if ((fm_status & 0xF0) == RX_CLS) - DPRINTK1("ED_TOV timesout.In RECEIVED CLOSE state..."); - if ((fm_status & 0xF0) == INITIALIZING) - DPRINTK1("ED_TOV timesout.In INITIALIZING state..."); - DPRINTK1("Initializing Loop..."); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - } - - if ((fm_status & BAD_ALPA) && (fi->g.loop_up == TRUE)) { - u_char bad_alpa = (readl(fi->t_r.ptr_fm_rx_al_pa_reg) & 0xFF00) >> 8; - if (tachyon_status & OSM_FROZEN) { - reset_tachyon(fi, ERROR_RELEASE); - reset_tachyon(fi, OCQ_RESET); - } - /* Fix for B34 */ - tx_logi(fi, ELS_PLOGI, fi->g.my_id); - - if (!fi->g.port_discovery && !fi->g.perform_adisc) { - if (bad_alpa != 0xFE) - DPRINTK("Bad AL_PA = %x", bad_alpa); - } - else { - if ((fi->g.perform_adisc == TRUE) && (bad_alpa == 0x00)) { - DPRINTK1("Performing ADISC..."); - fi->g.fabric_present = FALSE; - perform_adisc(fi); - } - } - } - - if (fm_status & LIPF_RECEIVED){ - DPRINTK("LIP(F8) Received"); - } - - if (fm_status & LINK_FAILURE) { - if (fm_status & LOSS_OF_SIGNAL) - DPRINTK1("Detected Loss of Signal."); - if (fm_status & OUT_OF_SYNC) - DPRINTK1("Detected Loss of Synchronization."); - } - - if (fm_status & TRANSMIT_PARITY_ERROR) { - /* Bad! Should not happen. Solution-> Hard Reset. - */ - T_MSG("Parity Error. Perform Hard Reset!"); - } - - if (fi->g.alpa_list_index >= MAX_NODES){ - if (fi->g.port_discovery == TRUE) { - fi->g.port_discovery = FALSE; - add_display_cache_timer(fi); - } - fi->g.alpa_list_index = MAX_NODES; - } - - if (fi->g.port_discovery == TRUE) - local_port_discovery(fi); - - LEAVE("handle_FM_interrupt"); - return; -} - -static void local_port_discovery(struct fc_info *fi) -{ - if (fi->g.loop_up == TRUE) { - /* If this is not here, some of the Bad AL_PAs are missed. - */ - udelay(20); - if ((fi->g.alpa_list_index == 0) && (fi->g.fabric_present == FALSE)){ - tx_logi(fi, ELS_FLOGI, F_PORT); - } - else { - int login_state = sid_logged_in(fi, fi->g.my_ddaa | alpa_list[fi->g.alpa_list_index]); - while ((fi->g.alpa_list_index == 0) || ((fi->g.alpa_list_index < MAX_NODES) && ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN) || (alpa_list[fi->g.alpa_list_index] == (fi->g.my_id & 0xFF))))) - fi->g.alpa_list_index++; - if (fi->g.alpa_list_index < MAX_NODES) - tx_logi(fi, ELS_PLOGI, alpa_list[fi->g.alpa_list_index]); - } - fi->g.alpa_list_index++; - if (fi->g.alpa_list_index >= MAX_NODES){ - if (fi->g.port_discovery == TRUE) { - fi->g.port_discovery = FALSE; - add_display_cache_timer(fi); - } - fi->g.alpa_list_index = MAX_NODES; - } - } -} - -static void nos_ols_timer(unsigned long data) -{ -struct fc_info *fi = (struct fc_info*)data; -u_int fm_status; - fm_status = readl(fi->t_r.ptr_fm_status_reg); - DPRINTK1("FM_status in timer= %x", fm_status); - fi->g.nport_timer_set = FALSE; - del_timer(&fi->nport_timer); - if ((fi->g.ptp_up == TRUE) || (fi->g.loop_up == TRUE)) - return; - if (((fm_status & 0xF0) == OLD_PORT) && (((fm_status & 0x0F) == PORT_STATE_ACTIVE) || ((fm_status & 0x0F) == PORT_STATE_OFFLINE))) { - DPRINTK1("In OLD-PORT after E_D_TOV."); - take_tachyon_offline(fi); - /* write R_T_TOV & E_D_TOV into the registers */ - writel(PTP_TOV_VALUES, fi->t_r.ptr_fm_tov_reg); - writel(BB_CREDIT | NPORT, fi->t_r.ptr_fm_config_reg); - fi->g.n_port_try = TRUE; - DPRINTK1("In timer, TACHYON initializing as N_Port...\n"); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - } - else - if ((fi->g.lport_timer_set == FALSE) && ((fm_status & 0xF0) == LOOP_FAIL)) { - DPRINTK1("Loop Fail after E_D_TOV."); - fi->lport_timer.function = loop_timer; - fi->lport_timer.data = (unsigned long)fi; - fi->lport_timer.expires = RUN_AT((8*HZ)/100); - init_timer(&fi->lport_timer); - add_timer(&fi->lport_timer); - fi->g.lport_timer_set = TRUE; - take_tachyon_offline(fi); - reset_tachyon(fi, SOFTWARE_RESET); - } - else - if (((fm_status & 0xF0) == OLD_PORT) && (((fm_status & 0x0F) == PORT_STATE_LF1) || ((fm_status & 0x0F) == PORT_STATE_LF2))) { - DPRINTK1("Link Fail-II in OLD-PORT."); - take_tachyon_offline(fi); - reset_tachyon(fi, SOFTWARE_RESET); - } -} - -static void loop_timer(unsigned long data) -{ -struct fc_info *fi = (struct fc_info*)data; - fi->g.lport_timer_set = FALSE; - del_timer(&fi->lport_timer); - if ((fi->g.ptp_up == TRUE) || (fi->g.loop_up == TRUE)) - return; -} - -static void add_display_cache_timer(struct fc_info *fi) -{ - fi->display_cache_timer.function = display_cache_timer; - fi->display_cache_timer.data = (unsigned long)fi; - fi->display_cache_timer.expires = RUN_AT(fi->num_nodes * HZ); - init_timer(&fi->display_cache_timer); - add_timer(&fi->display_cache_timer); -} - -static void display_cache_timer(unsigned long data) -{ -struct fc_info *fi = (struct fc_info*)data; - del_timer(&fi->display_cache_timer); - display_cache(fi); - return; -} - -static void reset_tachyon(struct fc_info *fi, u_int value) -{ -u_int tachyon_status, reset_done = OCQ_RESET_STATUS | SCSI_FREEZE_STATUS; -int not_done = 1, i = 0; - writel(value, fi->t_r.ptr_tach_control_reg); - if (value == OCQ_RESET) - fi->q.ocq_prod_indx = 0; - tachyon_status = readl(fi->t_r.ptr_tach_status_reg); - - /* Software resets are immediately done, whereas other aren't. It - about 30 clocks to do the reset */ - if (value != SOFTWARE_RESET) { - while(not_done) { - if (i++ > 100000) { - T_MSG("Reset was unsuccessful! Tachyon Status = %x", tachyon_status); - break; - } - tachyon_status = readl(fi->t_r.ptr_tach_status_reg); - if ((tachyon_status & reset_done) == 0) - not_done = 0; - } - } - else { - write_to_tachyon_registers(fi); - } -} - -static void take_tachyon_offline(struct fc_info *fi) -{ -u_int fm_status = readl(fi->t_r.ptr_fm_status_reg); - - /* The first two conditions will never be true. The Manual and - * the errata say this. But the current implementation is - * decently stable. - */ - //if ((fm_status & 0xF0) == LOOP_FAIL) { - if (fm_status == LOOP_FAIL) { - // workaround as in P. 89 - writel(HOST_CONTROL, fi->t_r.ptr_fm_control_reg); - if (fi->g.loop_up == TRUE) - writel(SOFTWARE_RESET, fi->t_r.ptr_tach_control_reg); - else { - writel(OFFLINE, fi->t_r.ptr_fm_control_reg); - writel(EXIT_HOST_CONTROL, fi->t_r.ptr_fm_control_reg); - } - } - else - //if ((fm_status & LOOP_UP) == LOOP_UP) { - if (fm_status == LOOP_UP) { - writel(SOFTWARE_RESET, fi->t_r.ptr_tach_control_reg); - } - else - writel(OFFLINE, fi->t_r.ptr_fm_control_reg); -} - - -static void read_novram(struct fc_info *fi) -{ -int off = 0; - fi->n_r.ptr_novram_hw_control_reg = fi->i_r.ptr_ichip_hw_control_reg; - fi->n_r.ptr_novram_hw_status_reg = fi->i_r.ptr_ichip_hw_status_reg; - iph5526_nr_do_init(fi); - if (fi->clone_id == PCI_VENDOR_ID_INTERPHASE) - off = 32; - - fi->g.my_node_name_high = (fi->n_r.data[off] << 16) | fi->n_r.data[off+1]; - fi->g.my_node_name_low = (fi->n_r.data[off+2] << 16) | fi->n_r.data[off+3]; - fi->g.my_port_name_high = (fi->n_r.data[off+4] << 16) | fi->n_r.data[off+5]; - fi->g.my_port_name_low = (fi->n_r.data[off+6] << 16) | fi->n_r.data[off+7]; - DPRINTK("node_name = %x %x", fi->g.my_node_name_high, fi->g.my_node_name_low); - DPRINTK("port_name = %x %x", fi->g.my_port_name_high, fi->g.my_port_name_low); -} - -static void reset_ichip(struct fc_info *fi) -{ - /* (i)chip reset */ - writel(ICHIP_HCR_RESET, fi->i_r.ptr_ichip_hw_control_reg); - /*wait for chip to get reset */ - mdelay(10); - /*de-assert reset */ - writel(ICHIP_HCR_DERESET, fi->i_r.ptr_ichip_hw_control_reg); - - /* enable INT lines on the (i)chip */ - writel(ICHIP_HCR_ENABLE_INTA , fi->i_r.ptr_ichip_hw_control_reg); - /* enable byte swap */ - writel(ICHIP_HAMR_BYTE_SWAP_ADDR_TR, fi->i_r.ptr_ichip_hw_addr_mask_reg); -} - -static void tx_logi(struct fc_info *fi, u_int logi, u_int d_id) -{ -int int_required = 1; -u_short ox_id = OX_ID_FIRST_SEQUENCE; -u_int r_ctl = RCTL_ELS_UCTL; -u_int type = TYPE_ELS | SEQUENCE_INITIATIVE | FIRST_SEQUENCE; -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_logi"); - /* We don't want interrupted for our own logi. - * It screws up the port discovery process. - */ - if (d_id == fi->g.my_id) - int_required = 0; - fill_login_frame(fi, logi); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.login, sizeof(LOGIN)); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),sizeof(LOGIN), r_ctl, type, d_id, my_mtu, int_required, ox_id, logi); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_logi"); - return; -} - -static void tx_logi_acc(struct fc_info *fi, u_int logi, u_int d_id, u_short received_ox_id) -{ -int int_required = 0; -u_int r_ctl = RCTL_ELS_SCTL; -u_int type = TYPE_ELS | EXCHANGE_RESPONDER | LAST_SEQUENCE; -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_logi_acc"); - fill_login_frame(fi, logi); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.login, sizeof(LOGIN)); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),sizeof(LOGIN), r_ctl, type, d_id, my_mtu, int_required, received_ox_id, logi); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_logi_acc"); - return; -} - -static void tx_prli(struct fc_info *fi, u_int command_code, u_int d_id, u_short received_ox_id) -{ -int int_required = 1; -u_int r_ctl = RCTL_ELS_UCTL; -u_int type = TYPE_ELS | SEQUENCE_INITIATIVE | FIRST_SEQUENCE; -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_prli"); - if (command_code == ELS_PRLI) - fi->g.prli.cmnd_code = htons((ELS_PRLI | PAGE_LEN) >> 16); - else { - fi->g.prli.cmnd_code = htons((ELS_ACC | PAGE_LEN) >> 16); - int_required = 0; - type = TYPE_ELS | EXCHANGE_RESPONDER | LAST_SEQUENCE; - r_ctl = RCTL_ELS_SCTL; - } - fi->g.prli.payload_length = htons(PRLI_LEN); - fi->g.prli.type_code = htons(FCP_TYPE_CODE); - fi->g.prli.est_image_pair = htons(IMAGE_PAIR); - fi->g.prli.responder_pa = 0; - fi->g.prli.originator_pa = 0; - fi->g.prli.service_params = htonl(INITIATOR_FUNC | READ_XFER_RDY_DISABLED); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.prli, sizeof(PRLI)); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]), sizeof(PRLI), r_ctl, type, d_id, my_mtu, int_required, received_ox_id, command_code); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_prli"); - return; -} - -static void tx_logo(struct fc_info *fi, u_int d_id, u_short received_ox_id) -{ -int int_required = 1; -u_int r_ctl = RCTL_ELS_UCTL; -u_int type = TYPE_ELS | EXCHANGE_RESPONDER | SEQUENCE_RESPONDER | FIRST_SEQUENCE | END_SEQUENCE | SEQUENCE_INITIATIVE; -int size = sizeof(LOGO); -char fc_id[3]; -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_logo"); - fi->g.logo.logo_cmnd = htonl(ELS_LOGO); - fi->g.logo.reserved = 0; - memcpy(fc_id, &(fi->g.my_id), 3); - fi->g.logo.n_port_id_0 = fc_id[0]; - fi->g.logo.n_port_id_1 = fc_id[1]; - fi->g.logo.n_port_id_2 = fc_id[2]; - fi->g.logo.port_name_up = htonl(N_PORT_NAME_HIGH); - fi->g.logo.port_name_low = htonl(N_PORT_NAME_LOW); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.logo, sizeof(LOGO)); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, received_ox_id, ELS_LOGO); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_logo"); -} - -static void tx_adisc(struct fc_info *fi, u_int cmnd_code, u_int d_id, u_short received_ox_id) -{ -int int_required = 0; -u_int r_ctl = RCTL_ELS_SCTL; -u_int type = TYPE_ELS | EXCHANGE_RESPONDER | SEQUENCE_RESPONDER | FIRST_SEQUENCE | END_SEQUENCE; -int size = sizeof(ADISC); -u_int my_mtu = fi->g.my_mtu; - fi->g.adisc.ls_cmnd_code = htonl(cmnd_code); - fi->g.adisc.hard_address = htonl(0); - fi->g.adisc.port_name_high = htonl(N_PORT_NAME_HIGH); - fi->g.adisc.port_name_low = htonl(N_PORT_NAME_LOW); - fi->g.adisc.node_name_high = htonl(NODE_NAME_HIGH); - fi->g.adisc.node_name_low = htonl(NODE_NAME_LOW); - fi->g.adisc.n_port_id = htonl(fi->g.my_id); - if (cmnd_code == ELS_ADISC) { - int_required = 1; - r_ctl = RCTL_ELS_UCTL; - type = TYPE_ELS | SEQUENCE_INITIATIVE | FIRST_SEQUENCE; - } - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.adisc, size); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, received_ox_id, cmnd_code); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; -} - -static void tx_ls_rjt(struct fc_info *fi, u_int d_id, u_short received_ox_id, u_short reason_code, u_short expln_code) -{ -int int_required = 0; -u_int r_ctl = RCTL_ELS_SCTL; -u_int type = TYPE_ELS | EXCHANGE_RESPONDER | LAST_SEQUENCE; -int size = sizeof(LS_RJT); -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_ls_rjt"); - fi->g.ls_rjt.cmnd_code = htonl(ELS_LS_RJT); - fi->g.ls_rjt.reason_code = htonl((reason_code << 16) | expln_code); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.ls_rjt, size); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, received_ox_id, ELS_LS_RJT); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_ls_rjt"); -} - -static void tx_abts(struct fc_info *fi, u_int d_id, u_short ox_id) -{ -int int_required = 1; -u_int r_ctl = RCTL_BASIC_ABTS; -u_int type = TYPE_BLS | SEQUENCE_INITIATIVE | FIRST_SEQUENCE; -int size = 0; -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_abts"); - fi->g.type_of_frame = FC_BLS; - tx_exchange(fi, NULL, size, r_ctl, type, d_id, my_mtu, int_required, ox_id, RCTL_BASIC_ABTS); - LEAVE("tx_abts"); -} - -static u_int plogi_ok(struct fc_info *fi, u_int *buff_addr, int size) -{ -int ret_code = 0; -u_short mtu = ntohl(*(buff_addr + 10)) & 0x00000FFF; -u_short class3 = ntohl(*(buff_addr + 25)) >> 16; -u_short class3_conc_seq = ntohl(*(buff_addr + 27)) >> 16; -u_short open_seq = ntohl(*(buff_addr + 28)) >> 16; - DPRINTK1("mtu = %x class3 = %x conc_seq = %x open_seq = %x", mtu, class3, class3_conc_seq, open_seq); - size -= TACHYON_HEADER_LEN; - if (!(class3 & 0x8000)) { - DPRINTK1("Received PLOGI with class3 = %x", class3); - ret_code = (LOGICAL_ERR << 16) | NO_EXPLN; - return ret_code; - } - if (mtu < 256) { - DPRINTK1("Received PLOGI with MTU set to %x", mtu); - ret_code = (LOGICAL_ERR << 16) | RECV_FIELD_SIZE; - return ret_code; - } - if (size != PLOGI_LEN) { - DPRINTK1("Received PLOGI of size %x", size); - ret_code = (LOGICAL_ERR << 16) | INV_PAYLOAD_LEN; - return ret_code; - } - if (class3_conc_seq == 0) { - DPRINTK1("Received PLOGI with conc_seq == 0"); - ret_code = (LOGICAL_ERR << 16) | CONC_SEQ; - return ret_code; - } - if (open_seq == 0) { - DPRINTK1("Received PLOGI with open_seq == 0"); - ret_code = (LOGICAL_ERR << 16) | NO_EXPLN; - return ret_code; - } - - /* Could potentially check for more fields, but might end up - not talking to most of the devices. ;-) */ - /* Things that could get checked are: - common_features = 0x8800 - total_concurrent_seq = at least 1 - */ - return ret_code; -} - -static void tx_acc(struct fc_info *fi, u_int d_id, u_short received_ox_id) -{ -int int_required = 0; -u_int r_ctl = RCTL_ELS_SCTL; -u_int type = TYPE_ELS | EXCHANGE_RESPONDER | LAST_SEQUENCE; -int size = sizeof(ACC); -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_acc"); - fi->g.acc.cmnd_code = htonl(ELS_ACC); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.acc, size); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, received_ox_id, ELS_ACC); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_acc"); -} - - -static void tx_name_server_req(struct fc_info *fi, u_int req) -{ -int int_required = 1, i, size = 0; -u_short ox_id = OX_ID_FIRST_SEQUENCE; -u_int type = TYPE_FC_SERVICES | SEQUENCE_INITIATIVE | FIRST_SEQUENCE; -u_int r_ctl = FC4_DEVICE_DATA | UNSOLICITED_CONTROL; -u_int my_mtu = fi->g.my_mtu, d_id = DIRECTORY_SERVER; -CT_HDR ct_hdr; - ENTER("tx_name_server_req"); - /* Fill up CT_Header */ - ct_hdr.rev_in_id = htonl(FC_CT_REV); - ct_hdr.fs_type = DIRECTORY_SERVER_APP; - ct_hdr.fs_subtype = NAME_SERVICE; - ct_hdr.options = 0; - ct_hdr.resv1 = 0; - ct_hdr.cmnd_resp_code = htons(req >> 16); - ct_hdr.max_res_size = 0; - ct_hdr.resv2 = 0; - ct_hdr.reason_code = 0; - ct_hdr.expln_code = 0; - ct_hdr.vendor_unique = 0; - - fi->g.type_of_frame = FC_ELS; - switch(req) { - case FCS_RFC_4: - memcpy(&(fi->g.rfc_4.ct_hdr), &ct_hdr, sizeof(CT_HDR)); - fi->g.rfc_4.s_id = htonl(fi->g.my_id); - for (i = 0; i < 32; i++) - fi->g.rfc_4.bit_map[i] = 0; - /* We support IP & SCSI */ - fi->g.rfc_4.bit_map[2] = 0x01; - fi->g.rfc_4.bit_map[3] = 0x20; - size = sizeof(RFC_4); - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.rfc_4, size); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, ox_id, req); - break; - case FCS_GP_ID4: - memcpy(&(fi->g.gp_id4.ct_hdr), &ct_hdr, sizeof(CT_HDR)); - fi->g.gp_id4.port_type = htonl(PORT_TYPE_NX_PORTS); - size = sizeof(GP_ID4); - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.gp_id4, size); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, ox_id, req); - break; - } - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_name_server_req"); -} - -static void tx_scr(struct fc_info *fi) -{ -int int_required = 1, size = sizeof(SCR); -u_short ox_id = OX_ID_FIRST_SEQUENCE; -u_int type = TYPE_ELS | SEQUENCE_INITIATIVE | FIRST_SEQUENCE; -u_int r_ctl = RCTL_ELS_UCTL; -u_int my_mtu = fi->g.my_mtu, d_id = FABRIC_CONTROLLER; - ENTER("tx_scr"); - fi->g.scr.cmnd_code = htonl(ELS_SCR); - fi->g.scr.reg_function = htonl(FULL_REGISTRATION); - fi->g.type_of_frame = FC_ELS; - memcpy(fi->g.els_buffer[fi->g.e_i], &fi->g.scr, size); - tx_exchange(fi, (char *)(fi->g.els_buffer[fi->g.e_i]),size, r_ctl, type, d_id, my_mtu, int_required, ox_id, ELS_SCR); - fi->g.e_i++; - if (fi->g.e_i == MAX_PENDING_FRAMES) - fi->g.e_i = 0; - LEAVE("tx_scr"); -} - -static void perform_adisc(struct fc_info *fi) -{ -int count = 0; - /* Will be set to TRUE when timer expires in a PLDA environment. - */ - fi->g.port_discovery = FALSE; - - if (fi->node_info_list) { - struct fc_node_info *temp_list = fi->node_info_list; - while(temp_list) { - /* Tx ADISC to all non-fabric based - * entities. - */ - if ((temp_list->d_id & 0xFF0000) != 0xFF0000) - tx_adisc(fi, ELS_ADISC, temp_list->d_id, OX_ID_FIRST_SEQUENCE); - temp_list = temp_list->next; - udelay(20); - count++; - } - } - /* Perform Port Discovery after timer expires. - * We are giving time for the ADISCed nodes to respond - * so that we don't have to perform PLOGI to those whose - * login are _still_ valid. - */ - fi->explore_timer.function = port_discovery_timer; - fi->explore_timer.data = (unsigned long)fi; - fi->explore_timer.expires = RUN_AT((count*3*HZ)/100); - init_timer(&fi->explore_timer); - add_timer(&fi->explore_timer); -} - -static void explore_fabric(struct fc_info *fi, u_int *buff_addr) -{ -u_int *addr = buff_addr + 12; /* index into payload */ -u_char control_code; -u_int d_id; -int count = 0; - ENTER("explore_fabric"); - DPRINTK1("entering explore_fabric"); - - /*fi->g.perform_adisc = TRUE; - fi->g.explore_fabric = TRUE; - perform_adisc(fi);*/ - - do { - d_id = ntohl(*addr) & 0x00FFFFFF; - if (d_id != fi->g.my_id) { - if (sid_logged_in(fi, d_id) == NODE_NOT_PRESENT) - tx_logi(fi, ELS_PLOGI, d_id); - else - if (sid_logged_in(fi, d_id) == NODE_LOGGED_OUT) - tx_adisc(fi, ELS_ADISC, d_id, OX_ID_FIRST_SEQUENCE); - count++; - } - control_code = (ntohl(*addr) & 0xFF000000) >> 24; - addr++; - DPRINTK1("cc = %x, d_id = %x", control_code, d_id); - } while (control_code != 0x80); - - fi->explore_timer.function = fabric_explore_timer; - fi->explore_timer.data = (unsigned long)fi; - /* We give 30 msec for each device to respond and then send out - * our SCSI enquiries. - */ - fi->explore_timer.expires = RUN_AT((count*3*HZ)/100); - init_timer(&fi->explore_timer); - add_timer(&fi->explore_timer); - - DPRINTK1("leaving explore_fabric"); - LEAVE("explore_fabric"); -} - -static void fabric_explore_timer(unsigned long data) -{ -struct fc_info *fi = (struct fc_info*)data; - del_timer(&fi->explore_timer); - - if ((fi->g.loop_up == TRUE) && (fi->g.ptp_up == FALSE)) { - /* Initiate Local Port Discovery on the Local Loop. - */ - fi->g.port_discovery = TRUE; - fi->g.alpa_list_index = 1; - local_port_discovery(fi); - } - fi->g.explore_fabric = FALSE; - return; -} - -static void port_discovery_timer(unsigned long data) -{ -struct fc_info *fi = (struct fc_info*)data; - del_timer(&fi->explore_timer); - - if ((fi->g.loop_up == TRUE) && (fi->g.explore_fabric != TRUE)) { - fi->g.port_discovery = TRUE; - fi->g.alpa_list_index = 1; - local_port_discovery(fi); - } - fi->g.perform_adisc = FALSE; - return; -} - -static void add_to_ox_id_list(struct fc_info *fi, u_int transaction_id, u_int cmnd_code) -{ -struct ox_id_els_map *p, *q = fi->ox_id_list, *r = NULL; -int size = sizeof(struct ox_id_els_map); - while (q != NULL) { - r = q; - q = q->next; - } - p = (struct ox_id_els_map *)kmalloc(size, GFP_ATOMIC); - if (p == NULL) { - T_MSG("kmalloc failed in add_to_ox_id_list()"); - return; - } - p->ox_id = transaction_id; - p->els = cmnd_code; - p->next = NULL; - if (fi->ox_id_list == NULL) - fi->ox_id_list = p; - else - r->next = p; - return; -} - -static u_int remove_from_ox_id_list(struct fc_info *fi, u_short received_ox_id) -{ -struct ox_id_els_map *p = fi->ox_id_list, *q = fi->ox_id_list; -u_int els_type; - while (q != NULL) { - if (q->ox_id == received_ox_id) { - - if (q == fi->ox_id_list) - fi->ox_id_list = fi->ox_id_list->next; - else - if (q->next == NULL) - p->next = NULL; - else - p->next = q->next; - - els_type = q->els; - kfree(q); - return els_type; - } - p = q; - q = q->next; - } - if (q == NULL) - DPRINTK2("Could not find ox_id %x in ox_id_els_map", received_ox_id); - return 0; -} - -static void build_tachyon_header(struct fc_info *fi, u_int my_id, u_int r_ctl, u_int d_id, u_int type, u_char seq_id, u_char df_ctl, u_short ox_id, u_short rx_id, char *data) -{ -u_char alpa = d_id & 0x0000FF; -u_int dest_ddaa = d_id &0xFFFF00; - - ENTER("build_tachyon_header"); - DPRINTK("d_id = %x, my_ddaa = %x", d_id, fi->g.my_ddaa); - /* Does it have to go to/thru a Fabric? */ - if ((dest_ddaa != 0) && ((d_id == F_PORT) || (fi->g.fabric_present && (dest_ddaa != fi->g.my_ddaa)))) - alpa = 0x00; - fi->g.tach_header.resv = 0x00000000; - fi->g.tach_header.sof_and_eof = SOFI3 | EOFN; - fi->g.tach_header.dest_alpa = alpa; - /* Set LCr properly to have enuff credit */ - if (alpa == REPLICATE) - fi->g.tach_header.lcr_and_time_stamp = htons(0xC00);/* LCr=3 */ - else - fi->g.tach_header.lcr_and_time_stamp = 0; - fi->g.tach_header.r_ctl_and_d_id = htonl(r_ctl | d_id); - fi->g.tach_header.vc_id_and_s_id = htonl(my_id); - fi->g.tach_header.type_and_f_cntl = htonl(type); - fi->g.tach_header.seq_id = seq_id; - fi->g.tach_header.df_cntl = df_ctl; - fi->g.tach_header.seq_cnt = 0; - fi->g.tach_header.ox_id = htons(ox_id); - fi->g.tach_header.rx_id = htons(rx_id); - fi->g.tach_header.ro = 0; - if (data) { - /* We use the Seq_Count to keep track of IP frames in the - * OCI_interrupt handler. Initial Seq_Count of IP frames is 1. - */ - if (fi->g.type_of_frame == FC_BROADCAST) - fi->g.tach_header.seq_cnt = htons(0x1); - else - fi->g.tach_header.seq_cnt = htons(0x2); - fi->g.tach_header.nw_header.d_naa = htons(0x1000); - fi->g.tach_header.nw_header.s_naa = htons(0x1000); - memcpy(&(fi->g.tach_header.nw_header.dest_high), data, 2); - memcpy(&(fi->g.tach_header.nw_header.dest_low), data + 2, 4); - memcpy(&(fi->g.tach_header.nw_header.source_high), data + 6, 2); - memcpy(&(fi->g.tach_header.nw_header.source_low), data + 8, 4); - } - LEAVE("build_tachyon_header"); -} - -static void build_EDB(struct fc_info *fi, char *data, u_short flags, u_short len) -{ - fi->g.edb.buf_addr = ntohl((u_int)virt_to_bus(data)); - fi->g.edb.ehf = ntohs(flags); - if (len % 4) - len += (4 - (len % 4)); - fi->g.edb.buf_len = ntohs(len); -} - -static void build_ODB(struct fc_info *fi, u_char seq_id, u_int d_id, u_int len, u_int cntl, u_short mtu, u_short ox_id, u_short rx_id, int NW_header, int int_required, u_int frame_class) -{ - fi->g.odb.seq_d_id = htonl(seq_id << 24 | d_id); - fi->g.odb.tot_len = len; - if (NW_header) - fi->g.odb.tot_len += NW_HEADER_LEN; - if (fi->g.odb.tot_len % 4) - fi->g.odb.tot_len += (4 - (fi->g.odb.tot_len % 4)); - fi->g.odb.tot_len = htonl(fi->g.odb.tot_len); - switch(int_required) { - case NO_COMP_AND_INT: - fi->g.odb.cntl = htons(ODB_CLASS_3 | ODB_EE_CREDIT | ODB_NO_INT | ODB_NO_COMP | cntl); - break; - case INT_AND_COMP_REQ: - fi->g.odb.cntl = htons(ODB_CLASS_3 | ODB_EE_CREDIT | cntl); - break; - case NO_INT_COMP_REQ: - fi->g.odb.cntl = htons(ODB_CLASS_3 | ODB_EE_CREDIT | ODB_NO_INT | cntl); - break; - } - fi->g.odb.rx_id = htons(rx_id); - fi->g.odb.cs_enable = 0; - fi->g.odb.cs_seed = htons(1); - - fi->g.odb.hdr_addr = htonl(virt_to_bus(fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx])); - fi->g.odb.frame_len = htons(mtu); - - if (NW_header) { - /* The pointer to the sk_buff is in here. Freed up when the - * OCI_interrupt is received. - */ - fi->g.odb.trans_id = htonl(frame_class); - fi->g.odb.hdr_len = TACHYON_HEADER_LEN + NW_HEADER_LEN; - } - else { - /* helps in tracking transmitted OX_IDs */ - fi->g.odb.trans_id = htonl((frame_class & 0xFFFF0000) | ox_id); - fi->g.odb.hdr_len = TACHYON_HEADER_LEN; - } - fi->g.odb.hdr_len = htons(fi->g.odb.hdr_len); - - fi->g.odb.edb_addr = htonl(virt_to_bus(fi->q.ptr_edb[fi->q.edb_buffer_indx])); -} - -static void fill_login_frame(struct fc_info *fi, u_int logi) -{ -int i; - fi->g.login.ls_cmnd_code= htonl(logi); - fi->g.login.fc_ph_version = htons(PH_VERSION); - if (fi->g.loop_up) - fi->g.login.buff_to_buff_credit = htons(LOOP_BB_CREDIT); - else - if (fi->g.ptp_up) - fi->g.login.buff_to_buff_credit = htons(PT2PT_BB_CREDIT); - if ((logi != ELS_FLOGI) || (logi == ELS_ACC)) - fi->g.login.common_features = htons(PLOGI_C_F); - else - if (logi == ELS_FLOGI) - fi->g.login.common_features = htons(FLOGI_C_F); - fi->g.login.recv_data_field_size = htons(TACH_FRAME_SIZE); - fi->g.login.n_port_total_conc_seq = htons(CONCURRENT_SEQUENCES); - fi->g.login.rel_off_by_info_cat = htons(RO_INFO_CATEGORY); - fi->g.login.ED_TOV = htonl(E_D_TOV); - fi->g.login.n_port_name_high = htonl(N_PORT_NAME_HIGH); - fi->g.login.n_port_name_low = htonl(N_PORT_NAME_LOW); - fi->g.login.node_name_high = htonl(NODE_NAME_HIGH); - fi->g.login.node_name_low = htonl(NODE_NAME_LOW); - - /* Fill Class 1 parameters */ - fi->g.login.c_of_s[0].service_options = htons(0); - fi->g.login.c_of_s[0].initiator_ctl = htons(0); - fi->g.login.c_of_s[0].recipient_ctl = htons(0); - fi->g.login.c_of_s[0].recv_data_field_size = htons(0); - fi->g.login.c_of_s[0].concurrent_sequences = htons(0); - fi->g.login.c_of_s[0].n_port_end_to_end_credit = htons(0); - fi->g.login.c_of_s[0].open_seq_per_exchange = htons(0); - fi->g.login.c_of_s[0].resv = htons(0); - - /* Fill Class 2 parameters */ - fi->g.login.c_of_s[1].service_options = htons(0); - fi->g.login.c_of_s[1].initiator_ctl = htons(0); - fi->g.login.c_of_s[1].recipient_ctl = htons(0); - fi->g.login.c_of_s[1].recv_data_field_size = htons(0); - fi->g.login.c_of_s[1].concurrent_sequences = htons(0); - fi->g.login.c_of_s[1].n_port_end_to_end_credit = htons(0); - fi->g.login.c_of_s[1].open_seq_per_exchange = htons(0); - fi->g.login.c_of_s[1].resv = htons(0); - - /* Fill Class 3 parameters */ - if (logi == ELS_FLOGI) - fi->g.login.c_of_s[2].service_options = htons(SERVICE_VALID | SEQUENCE_DELIVERY); - else - fi->g.login.c_of_s[2].service_options = htons(SERVICE_VALID); - fi->g.login.c_of_s[2].initiator_ctl = htons(0); - fi->g.login.c_of_s[2].recipient_ctl = htons(0); - fi->g.login.c_of_s[2].recv_data_field_size = htons(TACH_FRAME_SIZE); - fi->g.login.c_of_s[2].concurrent_sequences = htons(CLASS3_CONCURRENT_SEQUENCE); - fi->g.login.c_of_s[2].n_port_end_to_end_credit = htons(0); - fi->g.login.c_of_s[2].open_seq_per_exchange = htons(CLASS3_OPEN_SEQUENCE); - fi->g.login.c_of_s[2].resv = htons(0); - - for(i = 0; i < 4; i++) { - fi->g.login.resv[i] = 0; - fi->g.login.vendor_version_level[i] = 0; - } -} - - -/* clear the Interrupt Latch on the (i)chip, so that you can receive - * Interrupts from Tachyon in future - */ -static void reset_latch(struct fc_info *fi) -{ - writel(readl(fi->i_r.ptr_ichip_hw_status_reg) | ICHIP_HSR_INT_LATCH, fi->i_r.ptr_ichip_hw_status_reg); -} - -static void update_OCQ_indx(struct fc_info *fi) -{ - fi->q.ocq_prod_indx++; - if (fi->q.ocq_prod_indx == OCQ_LENGTH) - fi->q.ocq_prod_indx = 0; - writel(fi->q.ocq_prod_indx, fi->t_r.ptr_ocq_prod_indx_reg); -} - -static void update_IMQ_indx(struct fc_info *fi, int count) -{ - fi->q.imq_cons_indx += count; - if (fi->q.imq_cons_indx >= IMQ_LENGTH) - fi->q.imq_cons_indx -= IMQ_LENGTH; - writel(fi->q.imq_cons_indx, fi->t_r.ptr_imq_cons_indx_reg); -} - -static void update_SFSBQ_indx(struct fc_info *fi) -{ - fi->q.sfsbq_prod_indx++; - if (fi->q.sfsbq_prod_indx == SFSBQ_LENGTH) - fi->q.sfsbq_prod_indx = 0; - writel(fi->q.sfsbq_prod_indx, fi->t_r.ptr_sfsbq_prod_reg); -} - -static void update_MFSBQ_indx(struct fc_info *fi, int count) -{ - fi->q.mfsbq_prod_indx += count; - if (fi->q.mfsbq_prod_indx >= MFSBQ_LENGTH) - fi->q.mfsbq_prod_indx -= MFSBQ_LENGTH; - writel(fi->q.mfsbq_prod_indx, fi->t_r.ptr_mfsbq_prod_reg); -} - - -static void update_tachyon_header_indx(struct fc_info *fi) -{ - fi->q.tachyon_header_indx++; - if (fi->q.tachyon_header_indx == NO_OF_TACH_HEADERS) - fi->q.tachyon_header_indx = 0; -} - -static void update_EDB_indx(struct fc_info *fi) -{ - fi->q.edb_buffer_indx++; - if (fi->q.edb_buffer_indx == EDB_LEN) - fi->q.edb_buffer_indx = 0; -} - -static int iph5526_open(struct net_device *dev) -{ - netif_start_queue(dev); - return 0; -} - -static int iph5526_close(struct net_device *dev) -{ - netif_stop_queue(dev); - return 0; -} - -static void iph5526_timeout(struct net_device *dev) -{ - struct fc_info *fi = dev->priv; - printk(KERN_WARNING "%s: timed out on send.\n", dev->name); - fi->fc_stats.tx_dropped++; - dev->trans_start = jiffies; - netif_wake_queue(dev); -} - -static int iph5526_send_packet(struct sk_buff *skb, struct net_device *dev) -{ - struct fc_info *fi = dev->priv; - int status = 0; - short type = 0; - u_long flags; - struct fcllc *fcllc; - - ENTER("iph5526_send_packet"); - - netif_stop_queue(dev); - /* Strip off the pseudo header. - */ - skb->data = skb->data + 2*FC_ALEN; - skb->len = skb->len - 2*FC_ALEN; - fcllc = (struct fcllc *)skb->data; - type = ntohs(fcllc->ethertype); - - spin_lock_irqsave(&fi->fc_lock, flags); - switch(type) { - case ETH_P_IP: - status = tx_ip_packet(skb, skb->len, fi); - break; - case ETH_P_ARP: - status = tx_arp_packet(skb->data, skb->len, fi); - break; - default: - T_MSG("WARNING!!! Received Unknown Packet Type... Discarding..."); - fi->fc_stats.rx_dropped++; - break; - } - spin_unlock_irqrestore(&fi->fc_lock, flags); - - if (status) { - fi->fc_stats.tx_bytes += skb->len; - fi->fc_stats.tx_packets++; - } - else - fi->fc_stats.tx_dropped++; - dev->trans_start = jiffies; - /* We free up the IP buffers in the OCI_interrupt handler. - * status == 0 implies that the frame was not transmitted. So the - * skb is freed here. - */ - if ((type == ETH_P_ARP) || (status == 0)) - dev_kfree_skb(skb); - netif_wake_queue(dev); - LEAVE("iph5526_send_packet"); - return 0; -} - -static int iph5526_change_mtu(struct net_device *dev, int mtu) -{ - return 0; -} - -static int tx_ip_packet(struct sk_buff *skb, unsigned long len, struct fc_info *fi) -{ -u_int d_id; -int int_required = 1; -u_int r_ctl = FC4_DEVICE_DATA | UNSOLICITED_DATA; -u_int type = TYPE_LLC_SNAP; -u_short ox_id = OX_ID_FIRST_SEQUENCE; -u_int mtu; -struct fc_node_info *q; - - ENTER("tx_ip_packet"); - q = look_up_cache(fi, skb->data - 2*FC_ALEN); - if (q != NULL) { - d_id = q->d_id; - DPRINTK("Look-Up Cache Succeeded for d_id = %x", d_id); - mtu = q->mtu; - if (q->login == LOGIN_COMPLETED){ - fi->g.type_of_frame = FC_IP; - return tx_exchange(fi, skb->data, len, r_ctl, type, d_id, mtu, int_required, ox_id, virt_to_bus(skb)); - } - - if (q->d_id == BROADCAST) { - struct fc_node_info *p = fi->node_info_list; - int return_value = FALSE; - fi->g.type_of_frame = FC_BROADCAST; - /* Do unicast to local nodes. - */ - int_required = 0; - while(p != NULL) { - d_id = p->d_id; - if ((d_id & 0xFFFF00) == fi->g.my_ddaa) - return_value |= tx_exchange(fi, skb->data, len, r_ctl, type, d_id, fi->g.my_mtu, int_required, ox_id, TYPE_LLC_SNAP); - p = p->next; - } - kfree(q); - return return_value; - } - - if (q->login != LOGIN_COMPLETED) { - DPRINTK1("Node not logged in... Txing PLOGI to %x", d_id); - /* FIXME: we are dumping the frame here */ - tx_logi(fi, ELS_PLOGI, d_id); - } - } - DPRINTK2("Look-Up Cache Failed"); - LEAVE("tx_ip_packet"); - return 0; -} - -static int tx_arp_packet(char *data, unsigned long len, struct fc_info *fi) -{ -u_int opcode = data[ARP_OPCODE_0]; -u_int d_id; -int int_required = 0, return_value = FALSE; -u_int r_ctl = FC4_DEVICE_DATA | UNSOLICITED_DATA; -u_int type = TYPE_LLC_SNAP; -u_short ox_id = OX_ID_FIRST_SEQUENCE; -u_int my_mtu = fi->g.my_mtu; - ENTER("tx_arp_packet"); - - opcode = opcode << 8 | data[ARP_OPCODE_1]; - fi->g.type_of_frame = FC_IP; - - if (opcode == ARPOP_REQUEST) { - struct fc_node_info *q = fi->node_info_list; - d_id = BROADCAST; - return_value |= tx_exchange(fi, data, len, r_ctl, type, d_id, my_mtu, int_required, ox_id, TYPE_LLC_SNAP); - /* Some devices support HW_TYPE 0x01 */ - memcpy(fi->g.arp_buffer, data - 2*FC_ALEN, len + 2*FC_ALEN); - fi->g.arp_buffer[9 + 2*FC_ALEN] = 0x01; - return_value |= tx_exchange(fi, (char *)(fi->g.arp_buffer + 2*FC_ALEN), len, r_ctl, type, d_id, my_mtu, int_required, ox_id, TYPE_LLC_SNAP); - - /* Do unicast to local nodes. - */ - while(q != NULL) { - fi->g.type_of_frame = FC_BROADCAST; - d_id = q->d_id; - if ((d_id & 0xFFFF00) == fi->g.my_ddaa) { - return_value |= tx_exchange(fi, data, len, r_ctl, type, d_id, my_mtu, int_required, ox_id, TYPE_LLC_SNAP); - // Some devices support HW_TYPE 0x01 - memcpy(fi->g.arp_buffer, data - 2*FC_ALEN, len + 2*FC_ALEN); - fi->g.arp_buffer[9 + 2*FC_ALEN] = 0x01; - return_value |= tx_exchange(fi, (char *)(fi->g.arp_buffer + 2*FC_ALEN), len, r_ctl, type, d_id, my_mtu, int_required, ox_id, TYPE_LLC_SNAP); - } - q = q->next; - } - return return_value; - } - else - if (opcode == ARPOP_REPLY) { - struct fc_node_info *q; u_int mtu; - DPRINTK("We are sending out an ARP reply"); - q = look_up_cache(fi, data - 2*FC_ALEN); - if (q != NULL) { - d_id = q->d_id; - DPRINTK("Look-Up Cache Succeeded for d_id = %x", d_id); - mtu = q->mtu; - if (q->login == LOGIN_COMPLETED){ - tx_exchange(fi, data, len, r_ctl, type, d_id, mtu, int_required, ox_id, TYPE_LLC_SNAP); - /* Some devices support HW_TYPE 0x01 */ - memcpy(fi->g.arp_buffer, data - 2*FC_ALEN, len + 2*FC_ALEN); - fi->g.arp_buffer[9 + 2*FC_ALEN] = 0x01; - return tx_exchange(fi, (char *)(fi->g.arp_buffer + 2*FC_ALEN), len, r_ctl, type, d_id, my_mtu, int_required, ox_id, TYPE_LLC_SNAP); - } - else { - DPRINTK1("Node not logged in... Txing PLOGI to %x", d_id); - tx_logi(fi, ELS_PLOGI, d_id); /* FIXME: we are dumping the frame here */ - } - } - DPRINTK2("Look-Up Cache Failed"); - } - else { - T_MSG("Warning!!! Invalid Opcode in ARP Packet!"); - } - LEAVE("tx_arp_packet"); - return 0; -} - - -static void rx_net_packet(struct fc_info *fi, u_char *buff_addr, int payload_size) -{ -struct net_device *dev = fi->dev; -struct sk_buff *skb; -u_int skb_size = 0; -struct fch_hdr fch; - ENTER("rx_net_packet"); - skb_size = payload_size - TACHYON_HEADER_LEN; - DPRINTK("skb_size = %d", skb_size); - fi->fc_stats.rx_bytes += skb_size - 2; - skb = dev_alloc_skb(skb_size); - if (skb == NULL) { - printk(KERN_NOTICE "%s: In rx_net_packet() Memory squeeze, dropping packet.\n", dev->name); - fi->fc_stats.rx_dropped++; - return; - } - /* Skip over the Tachyon Frame Header. - */ - buff_addr += TACHYON_HEADER_LEN; - - memcpy(fch.daddr, buff_addr + 2, FC_ALEN); - memcpy(fch.saddr, buff_addr + 10, FC_ALEN); - buff_addr += 2; - memcpy(buff_addr, fch.daddr, FC_ALEN); - memcpy(buff_addr + 6, fch.saddr, FC_ALEN); - skb_reserve(skb, 2); - memcpy(skb_put(skb, skb_size - 2), buff_addr, skb_size - 2); - skb->dev = dev; - skb->protocol = fc_type_trans(skb, dev); - DPRINTK("protocol = %x", skb->protocol); - - /* Hmmm... to accept HW Type 0x01 as well... - */ - if (skb->protocol == ntohs(ETH_P_ARP)) - skb->data[1] = 0x06; - netif_rx(skb); - dev->last_rx = jiffies; - fi->fc_stats.rx_packets++; - LEAVE("rx_net_packet"); -} - - -static void rx_net_mfs_packet(struct fc_info *fi, struct sk_buff *skb) -{ -struct net_device *dev = fi->dev; -struct fch_hdr fch; - ENTER("rx_net_mfs_packet"); - /* Construct your Hard Header */ - memcpy(fch.daddr, skb->data + 2, FC_ALEN); - memcpy(fch.saddr, skb->data + 10, FC_ALEN); - skb_pull(skb, 2); - memcpy(skb->data, fch.daddr, FC_ALEN); - memcpy(skb->data + 6, fch.saddr, FC_ALEN); - skb->dev = dev; - skb->protocol = fc_type_trans(skb, dev); - DPRINTK("protocol = %x", skb->protocol); - netif_rx(skb); - dev->last_rx = jiffies; - LEAVE("rx_net_mfs_packet"); -} - -static int tx_exchange(struct fc_info *fi, char *data, u_int len, u_int r_ctl, u_int type, u_int d_id, u_int mtu, int int_required, u_short tx_ox_id, u_int frame_class) -{ -u_char df_ctl; -int NW_flag = 0, h_size, return_value; -u_short rx_id = RX_ID_FIRST_SEQUENCE; -u_int tachyon_status; -u_int my_id = fi->g.my_id; - ENTER("tx_exchange"); - - tachyon_status = readl(fi->t_r.ptr_tach_status_reg); - DPRINTK("Tachyon Status = %x len = %d MTU = %d", tachyon_status, len, mtu); - if (tachyon_status & OSM_FROZEN) { - reset_tachyon(fi, ERROR_RELEASE); - reset_tachyon(fi, OCQ_RESET); - DPRINTK("Tachyon Status = %x len = %d MTU = %d", tachyon_status, len, mtu); - } - if (tx_ox_id == OX_ID_FIRST_SEQUENCE) { - switch(fi->g.type_of_frame) { - case FC_SCSI_READ: - tx_ox_id = fi->g.scsi_oxid | SCSI_READ_BIT; - break; - case FC_SCSI_WRITE: - tx_ox_id = fi->g.scsi_oxid; - break; - default: - tx_ox_id = fi->g.ox_id; - break; - } - } - else { - switch(fi->g.type_of_frame) { - case FC_SCSI_READ: - rx_id = fi->g.scsi_oxid | SCSI_READ_BIT; - break; - case FC_SCSI_WRITE: - rx_id = fi->g.scsi_oxid; - break; - case FC_BLS: - rx_id = RX_ID_FIRST_SEQUENCE; - break; - default: - rx_id = fi->g.ox_id; - break; - } - } - - if (type == TYPE_LLC_SNAP) { - df_ctl = 0x20; - NW_flag = 1; - /* Multi Frame Sequence ? If yes, set RO bit */ - if (len > mtu) - type |= RELATIVE_OFF_PRESENT; - build_tachyon_header(fi, my_id, r_ctl, d_id, type, fi->g.seq_id, df_ctl, tx_ox_id, rx_id, data - 2*FC_ALEN); - } - else { - df_ctl = 0; - /* Multi Frame Sequence ? If yes, set RO bit */ - if (len > mtu) - type |= RELATIVE_OFF_PRESENT; - build_tachyon_header(fi, my_id, r_ctl, d_id, type, fi->g.seq_id, df_ctl, tx_ox_id, rx_id, NULL); - } - - /* Get free Tachyon Headers and EDBs */ - if (get_free_header(fi) || get_free_EDB(fi)) - return 0; - - if ((type & 0xFF000000) == TYPE_LLC_SNAP) { - h_size = TACHYON_HEADER_LEN + NW_HEADER_LEN; - memcpy(fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx], &(fi->g.tach_header), h_size); - } - else - memcpy(fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx], &(fi->g.tach_header), TACHYON_HEADER_LEN); - - return_value = tx_sequence(fi, data, len, mtu, d_id, tx_ox_id, rx_id, fi->g.seq_id, NW_flag, int_required, frame_class); - - switch(fi->g.type_of_frame) { - case FC_SCSI_READ: - case FC_SCSI_WRITE: - update_scsi_oxid(fi); - break; - case FC_BLS: - break; - default: - fi->g.ox_id++; - if (fi->g.ox_id == 0xFFFF) - fi->g.ox_id = NOT_SCSI_XID; - break; - } - - if (fi->g.seq_id == MAX_SEQ_ID) - fi->g.seq_id = 0; - else - fi->g.seq_id++; - LEAVE("tx_exchange"); - return return_value; -} - -static int tx_sequence(struct fc_info *fi, char *data, u_int len, u_int mtu, u_int d_id, u_short ox_id, u_short rx_id, u_char seq_id, int NW_flag, int int_required, u_int frame_class) -{ -u_int cntl = 0; -int return_value; - ENTER("tx_sequence"); - build_EDB(fi, data, EDB_END, len); - memcpy(fi->q.ptr_edb[fi->q.edb_buffer_indx], &(fi->g.edb), sizeof(EDB)); - build_ODB(fi, seq_id, d_id, len, cntl, mtu, ox_id, rx_id, NW_flag, int_required, frame_class); - memcpy(fi->q.ptr_odb[fi->q.ocq_prod_indx], &(fi->g.odb), sizeof(ODB)); - if (fi->g.link_up != TRUE) { - DPRINTK2("Fibre Channel Link not up. Dropping Exchange!"); - return_value = FALSE; - } - else { - /* To be on the safe side, a check should be included - * at this point to check if we are overrunning - * Tachyon. - */ - update_OCQ_indx(fi); - return_value = TRUE; - } - update_EDB_indx(fi); - update_tachyon_header_indx(fi); - LEAVE("tx_sequence"); - return return_value; -} - -static int get_free_header(struct fc_info *fi) -{ -u_short temp_ox_id; -u_int *tach_header, initial_indx = fi->q.tachyon_header_indx; - /* Check if the header is in use. - * We could have an outstanding command. - * We should find a free slot as we can queue a - * maximum of 32 SCSI commands only. - */ - tach_header = fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx]; - temp_ox_id = ntohl(*(tach_header + 6)) >> 16; - /* We care about the SCSI writes only. Those are the wicked ones - * that need an additional set of buffers. - */ - while(temp_ox_id <= MAX_SCSI_XID) { - update_tachyon_header_indx(fi); - if (fi->q.tachyon_header_indx == initial_indx) { - /* Should never happen. - */ - T_MSG("No free Tachyon headers available"); - reset_tachyon(fi, SOFTWARE_RESET); - return 1; - } - tach_header = fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx]; - temp_ox_id = ntohl(*(tach_header + 6)) >> 16; - } - return 0; -} - -static int get_free_EDB(struct fc_info *fi) -{ -unsigned int initial_indx = fi->q.edb_buffer_indx; - /* Check if the EDB is in use. - * We could have an outstanding SCSI Write command. - * We should find a free slot as we can queue a - * maximum of 32 SCSI commands only. - */ - while (fi->q.free_edb_list[fi->q.edb_buffer_indx] != EDB_FREE) { - update_EDB_indx(fi); - if (fi->q.edb_buffer_indx == initial_indx) { - T_MSG("No free EDB buffers avaliable") - reset_tachyon(fi, SOFTWARE_RESET); - return 1; - } - } - return 0; -} - -static int validate_login(struct fc_info *fi, u_int *base_ptr) -{ -struct fc_node_info *q = fi->node_info_list; -char n_port_name[PORT_NAME_LEN]; -char node_name[NODE_NAME_LEN]; -u_int s_id; - ENTER("validate_login"); - /*index to Port Name in the payload. We need the 8 byte Port Name */ - memcpy(n_port_name, base_ptr + 10, PORT_NAME_LEN); - memcpy(node_name, base_ptr + 12, NODE_NAME_LEN); - s_id = ntohl(*(base_ptr + 3)) & 0x00FFFFFF; - - /* check if Fibre Channel IDs have changed */ - while(q != NULL) { - if (memcmp(n_port_name, q->hw_addr, PORT_NAME_LEN) == 0) { - if ((s_id != q->d_id) || (memcmp(node_name, q->node_name, NODE_NAME_LEN) != 0)) { - DPRINTK1("Fibre Channel ID of Node has changed. Txing LOGO."); - return 0; - } - q->login = LOGIN_COMPLETED; -#if DEBUG_5526_2 - display_cache(fi); -#endif - return 1; - } - q = q->next; - } - DPRINTK1("Port Name does not match. Txing LOGO."); - LEAVE("validate_login"); - return 0; -} - -static void add_to_address_cache(struct fc_info *fi, u_int *base_ptr) -{ -int size = sizeof(struct fc_node_info); -struct fc_node_info *p, *q = fi->node_info_list, *r = NULL; -char n_port_name[PORT_NAME_LEN]; -u_int s_id; - ENTER("add_to_address_cache"); - /*index to Port Name in the payload. We need the 8 byte Port Name */ - memcpy(n_port_name, base_ptr + 13, PORT_NAME_LEN); - s_id = ntohl(*(base_ptr + 3)) & 0x00FFFFFF; - - /* check if info already exists */ - while(q != NULL) { - if (memcmp(n_port_name, q->hw_addr, PORT_NAME_LEN) == 0) { - if (s_id != q->d_id) { - memcpy(&(q->c_of_s[0]), base_ptr + 17, 3 * sizeof(CLASS_OF_SERVICE)); - q->mtu = ntohl(*(base_ptr + 10)) & 0x00000FFF; - q->d_id = s_id; - memcpy(q->node_name, base_ptr + 15, NODE_NAME_LEN); - } - q->login = LOGIN_COMPLETED; - q->scsi = FALSE; - fi->num_nodes++; -#if DEBUG_5526_2 - display_cache(fi); -#endif - return; - } - r = q; - q = q->next; - } - p = (struct fc_node_info *)kmalloc(size, GFP_ATOMIC); - if (p == NULL) { - T_MSG("kmalloc failed in add_to_address_cache()"); - return; - } - memcpy(&(p->c_of_s[0]), base_ptr + 17, 3 * sizeof(CLASS_OF_SERVICE)); - p->mtu = ntohl(*(base_ptr + 10)) & 0x00000FFF; - p->d_id = s_id; - memcpy(p->hw_addr, base_ptr + 13, PORT_NAME_LEN); - memcpy(p->node_name, base_ptr + 15, NODE_NAME_LEN); - p->login = LOGIN_COMPLETED; - p->scsi = FALSE; - p->target_id = 0xFF; - p->next = NULL; - if (fi->node_info_list == NULL) - fi->node_info_list = p; - else - r->next = p; - fi->num_nodes++; -#if DEBUG_5526_2 - display_cache(fi); -#endif - LEAVE("add_to_address_cache"); - return; -} - -static void remove_from_address_cache(struct fc_info *fi, u_int *base_ptr, u_int cmnd_code) -{ -struct fc_node_info *q = fi->node_info_list; -u_int s_id; - ENTER("remove_from_address_cache"); - s_id = ntohl(*(base_ptr + 3)) & 0x00FFFFFF; - switch(cmnd_code) { - case ELS_LOGO: - /* check if info exists */ - while (q != NULL) { - if (s_id == q->d_id) { - if (q->login == LOGIN_COMPLETED) - q->login = LOGIN_ATTEMPTED; - if (fi->num_nodes > 0) - fi->num_nodes--; -#if DEBUG_5526_2 - display_cache(fi); -#endif - return; - } - q = q->next; - } - DPRINTK1("ELS_LOGO received from node 0x%x which is not logged-in", s_id); - break; - case ELS_RSCN: - { - int payload_len = ntohl(*(base_ptr + 8)) & 0xFF; - int no_of_pages, i; - u_char address_format; - u_short received_ox_id = ntohl(*(base_ptr + 6)) >> 16; - u_int node_id, mask, *page_ptr = base_ptr + 9; - if ((payload_len < 4) || (payload_len > 256)) { - DPRINTK1("RSCN with invalid payload length received"); - tx_ls_rjt(fi, s_id, received_ox_id, LOGICAL_ERR, RECV_FIELD_SIZE); - return; - } - /* Page_size includes the Command Code */ - no_of_pages = (payload_len / 4) - 1; - for (i = 0; i < no_of_pages; i++) { - address_format = ntohl(*page_ptr) >> 24; - node_id = ntohl(*page_ptr) & 0x00FFFFFF; - switch(address_format) { - case PORT_ADDRESS_FORMAT: - rscn_handler(fi, node_id); - break; - case AREA_ADDRESS_FORMAT: - case DOMAIN_ADDRESS_FORMAT: - if (address_format == AREA_ADDRESS_FORMAT) - mask = 0xFFFF00; - else - mask = 0xFF0000; - while(q != NULL) { - if ((q->d_id & mask) == (node_id & mask)) - rscn_handler(fi, q->d_id); - q = q->next; - } - /* There might be some new nodes to be - * discovered. But, some of the earlier - * requests as a result of the RSCN might be - * in progress. We don't want to duplicate that - * effort. So letz call SCR after a lag. - */ - fi->explore_timer.function = scr_timer; - fi->explore_timer.data = (unsigned long)fi; - fi->explore_timer.expires = RUN_AT((no_of_pages*3*HZ)/100); - init_timer(&fi->explore_timer); - add_timer(&fi->explore_timer); - break; - default: - T_MSG("RSCN with invalid address format received"); - tx_ls_rjt(fi, s_id, received_ox_id, LOGICAL_ERR, NO_EXPLN); - } - page_ptr += 1; - } /* end of for loop */ - } /* end of case RSCN: */ - break; - } -#if DEBUG_5526_2 - display_cache(fi); -#endif - LEAVE("remove_from_address_cache"); -} - -static void rscn_handler(struct fc_info *fi, u_int node_id) -{ -struct fc_node_info *q = fi->node_info_list; -int login_state = sid_logged_in(fi, node_id); - if ((login_state == NODE_LOGGED_IN) || (login_state == NODE_PROCESS_LOGGED_IN)) { - while(q != NULL) { - if (q->d_id == node_id) { - q->login = LOGIN_ATTEMPTED; - if (fi->num_nodes > 0) - fi->num_nodes--; - break; - } - else - q = q->next; - } - } - else - if (login_state == NODE_LOGGED_OUT) - tx_adisc(fi, ELS_ADISC, node_id, OX_ID_FIRST_SEQUENCE); - else - if (login_state == NODE_LOGGED_OUT) - tx_logi(fi, ELS_PLOGI, node_id); -} - -static void scr_timer(unsigned long data) -{ -struct fc_info *fi = (struct fc_info *)data; - del_timer(&fi->explore_timer); - tx_name_server_req(fi, FCS_GP_ID4); -} - -static int sid_logged_in(struct fc_info *fi, u_int s_id) -{ -struct fc_node_info *temp = fi->node_info_list; - while(temp != NULL) - if ((temp->d_id == s_id) && (temp->login == LOGIN_COMPLETED)) { - if (temp->scsi != FALSE) - return NODE_PROCESS_LOGGED_IN; - else - return NODE_LOGGED_IN; - } - else - if ((temp->d_id == s_id) && (temp->login != LOGIN_COMPLETED)) - return NODE_LOGGED_OUT; - else - temp = temp->next; - return NODE_NOT_PRESENT; -} - -static void mark_scsi_sid(struct fc_info *fi, u_int *buff_addr, u_char action) -{ -struct fc_node_info *temp = fi->node_info_list; -u_int s_id; -u_int service_params; - s_id = ntohl(*(buff_addr + 3)) & 0x00FFFFFF; - service_params = ntohl(*(buff_addr + 12)) & 0x000000F0; - while(temp != NULL) - if ((temp->d_id == s_id) && (temp->login == LOGIN_COMPLETED)) { - if (action == DELETE_ENTRY) { - temp->scsi = FALSE; -#if DEBUG_5526_2 - display_cache(fi); -#endif - return; - } - /* Check if it is a SCSI Target */ - if (!(service_params & TARGET_FUNC)) { - temp->scsi = INITIATOR; -#if DEBUG_5526_2 - display_cache(fi); -#endif - return; - } - temp->scsi = TARGET; - /* This helps to maintain the target_id no matter what your - * Fibre Channel ID is. - */ - if (temp->target_id == 0xFF) { - if (fi->g.no_of_targets <= MAX_SCSI_TARGETS) - temp->target_id = fi->g.no_of_targets++; - else - T_MSG("MAX TARGETS reached!"); - } - else - DPRINTK1("Target_id %d already present", temp->target_id); -#if DEBUG_5526_2 - display_cache(fi); -#endif - return; - } - else - temp = temp->next; - return; -} - -static int node_logged_in_prev(struct fc_info *fi, u_int *buff_addr) -{ -struct fc_node_info *temp; -u_char *data = (u_char *)buff_addr; -u_int s_id; -char node_name[NODE_NAME_LEN]; - s_id = ntohl(*(buff_addr + 3)) & 0x00FFFFFF; - memcpy(node_name, buff_addr + 12, NODE_NAME_LEN); - /* point to port_name in the ADISC payload */ - data += 10 * 4; - /* point to last 6 bytes of port_name */ - data += 2; - temp = look_up_cache(fi, data); - if (temp != NULL) { - if ((temp->d_id == s_id) && (memcmp(node_name, temp->node_name, NODE_NAME_LEN) == 0)) { - temp->login = LOGIN_COMPLETED; -#if DEBUG_5526_2 - display_cache(fi); -#endif - return TRUE; - } - } - return FALSE; -} - -static struct fc_node_info *look_up_cache(struct fc_info *fi, char *data) -{ -struct fc_node_info *temp_list = fi->node_info_list, *q; -u_char n_port_name[FC_ALEN], temp_addr[FC_ALEN]; - ENTER("look_up_cache"); - memcpy(n_port_name, data, FC_ALEN); - while(temp_list) { - if (memcmp(n_port_name, &(temp_list->hw_addr[2]), FC_ALEN) == 0) - return temp_list; - else - temp_list = temp_list->next; - } - - /* Broadcast IP ? - */ - temp_addr[0] = temp_addr[1] = temp_addr[2] = 0xFF; - temp_addr[3] = temp_addr[4] = temp_addr[5] = 0xFF; - if (memcmp(n_port_name, temp_addr, FC_ALEN) == 0) { - q = (struct fc_node_info *)kmalloc(sizeof(struct fc_node_info), GFP_ATOMIC); - if (q == NULL) { - T_MSG("kmalloc failed in look_up_cache()"); - return NULL; - } - q->d_id = BROADCAST; - return q; - } - LEAVE("look_up_cache"); - return NULL; -} - -static int display_cache(struct fc_info *fi) -{ -struct fc_node_info *q = fi->node_info_list; -#if DEBUG_5526_2 -struct ox_id_els_map *temp_ox_id_list = fi->ox_id_list; -#endif -int count = 0, j; - printk("\nFibre Channel Node Information for %s\n", fi->name); - printk("My FC_ID = %x, My WWN = %x %x, ", fi->g.my_id, fi->g.my_node_name_high, fi->g.my_node_name_low); - if (fi->g.ptp_up == TRUE) - printk("Port_Type = N_Port\n"); - if (fi->g.loop_up == TRUE) - printk("Port_Type = L_Port\n"); - while(q != NULL) { - printk("WWN = "); - for (j = 0; j < PORT_NAME_LEN; j++) - printk("%x ", q->hw_addr[j]); - printk("FC_ID = %x, ", q->d_id); - printk("Login = "); - if (q->login == LOGIN_COMPLETED) - printk("ON "); - else - printk("OFF "); - if (q->scsi == TARGET) - printk("Target_ID = %d ", q->target_id); - printk("\n"); - q = q->next; - count++; - } - -#if DEBUG_5526_2 - printk("OX_ID -> ELS Map\n"); - while(temp_ox_id_list) { - printk("ox_id = %x, ELS = %x\n", temp_ox_id_list->ox_id, temp_ox_id_list->els); - temp_ox_id_list = temp_ox_id_list->next; - } -#endif - - return 0; -} - -static struct net_device_stats * iph5526_get_stats(struct net_device *dev) -{ -struct fc_info *fi = dev->priv; - return (struct net_device_stats *) &fi->fc_stats; -} - - -/* SCSI stuff starts here */ - -int iph5526_detect(Scsi_Host_Template *tmpt) -{ - struct Scsi_Host *host = NULL; - struct iph5526_hostdata *hostdata; - struct fc_info *fi = NULL; - int no_of_hosts = 0, i, j, count = 0; - u_int pci_maddr = 0; - struct pci_dev *pdev = NULL; - unsigned long timeout; - - tmpt->proc_name = "iph5526"; - - for (i = 0; i <= MAX_FC_CARDS; i++) - fc[i] = NULL; - - for (i = 0; clone_list[i].vendor_id != 0; i++) - while ((pdev = pci_find_device(clone_list[i].vendor_id, clone_list[i].device_id, pdev))) { - unsigned short pci_command; - if (pci_enable_device(pdev)) - continue; - if (count < MAX_FC_CARDS) { - fc[count] = kmalloc(sizeof(struct fc_info), GFP_ATOMIC); - if (fc[count] == NULL) { - printk("iph5526.c: Unable to register card # %d\n", count + 1); - return no_of_hosts; - } - memset(fc[count], 0, sizeof(struct fc_info)); - } - else { - printk("iph5526.c: Maximum Number of cards reached.\n"); - return no_of_hosts; - } - - fi = fc[count]; - sprintf(fi->name, "fc%d", count); - - host = scsi_register(tmpt, sizeof(struct iph5526_hostdata)); - if(host==NULL) { - kfree(fc[count]); - return no_of_hosts; - } - - hostdata = (struct iph5526_hostdata *)host->hostdata; - memset(hostdata, 0 , sizeof(struct iph5526_hostdata)); - for (j = 0; j < MAX_SCSI_TARGETS; j++) - hostdata->tag_ages[j] = jiffies; - hostdata->fi = fi; - fi->host = host; - //host->max_id = MAX_SCSI_TARGETS; - host->max_id = 5; - host->this_id = tmpt->this_id; - - pci_maddr = pci_resource_start(pdev, 0); - if (pci_resource_flags(pdev, 0) & IORESOURCE_IO) { - printk("iph5526.c : Cannot find proper PCI device base address.\n"); - scsi_unregister(host); - kfree(fc[count]); - fc[count] = NULL; - continue; - } - - DPRINTK("pci_maddr = %x", pci_maddr); - pci_read_config_word(pdev, PCI_COMMAND, &pci_command); - - pci_irq_line = pdev->irq; - printk("iph5526.c: PCI BIOS reports %s at i/o %#x, irq %d.\n", clone_list[i].name, pci_maddr, pci_irq_line); - fi->g.mem_base = ioremap(pci_maddr & PAGE_MASK, 1024); - - /* We use Memory Mapped IO. The initial space contains the - * PCI Configuration registers followed by the (i) chip - * registers followed by the Tachyon registers. - */ - /* Thatz where (i)chip maps Tachyon Address Space. - */ - fi->g.tachyon_base = (u_long)fi->g.mem_base + TACHYON_OFFSET + ( pci_maddr & ~PAGE_MASK ); - DPRINTK("fi->g.tachyon_base = %x", (u_int)fi->g.tachyon_base); - if (fi->g.mem_base == NULL) { - printk("iph5526.c : ioremap failed!!!\n"); - scsi_unregister(host); - kfree(fc[count]); - fc[count] = NULL; - continue; - } - DPRINTK("IRQ1 = %d\n", pci_irq_line); - printk(version); - fi->base_addr = (long) pdev; - - if (pci_irq_line) { - int irqval = 0; - /* Found it, get IRQ. - */ - irqval = request_irq(pci_irq_line, &tachyon_interrupt, pci_irq_line ? SA_SHIRQ : 0, fi->name, host); - if (irqval) { - printk("iph5526.c : Unable to get IRQ %d (irqval = %d).\n", pci_irq_line, irqval); - scsi_unregister(host); - kfree(fc[count]); - fc[count] = NULL; - continue; - } - host->irq = fi->irq = pci_irq_line; - pci_irq_line = 0; - fi->clone_id = clone_list[i].vendor_id; - } - - if (!initialize_register_pointers(fi) || !tachyon_init(fi)) { - printk("iph5526.c: TACHYON initialization failed for card # %d!!!\n", count + 1); - free_irq(host->irq, host); - scsi_unregister(host); - if (fi) - clean_up_memory(fi); - kfree(fc[count]); - fc[count] = NULL; - break; - } - DPRINTK1("Fibre Channel card initialized"); - /* Wait for the Link to come up and the login process - * to complete. - */ - for(timeout = jiffies + 10*HZ; time_before(jiffies, timeout) && ((fi->g.link_up == FALSE) || (fi->g.port_discovery == TRUE) || (fi->g.explore_fabric == TRUE) || (fi->g.perform_adisc == TRUE));) - { - cpu_relax(); - barrier(); - } - - count++; - no_of_hosts++; - } - DPRINTK1("no_of_hosts = %d",no_of_hosts); - - /* This is to make sure that the ACC to the PRLI comes in - * for the last ALPA. - */ - mdelay(1000); /* Ugly! Let the Gods forgive me */ - - DPRINTK1("leaving iph5526_detect\n"); - return no_of_hosts; -} - - -int iph5526_biosparam(struct scsi_device *sdev, struct block_device *n, - sector_t capacity, int ip[]) -{ -int size = capacity; - ip[0] = 64; - ip[1] = 32; - ip[2] = size >> 11; - if (ip[2] > 1024) { - ip[0] = 255; - ip[1] = 63; - ip[2] = size / (ip[0] * ip[1]); - } - return 0; -} - -int iph5526_queuecommand(Scsi_Cmnd *Cmnd, void (*done) (Scsi_Cmnd *)) -{ -int int_required = 0; -u_int r_ctl = FC4_DEVICE_DATA | UNSOLICITED_COMMAND; -u_int type = TYPE_FCP | SEQUENCE_INITIATIVE; -u_int frame_class = Cmnd->device->id; -u_short ox_id = OX_ID_FIRST_SEQUENCE; -struct Scsi_Host *host = Cmnd->device->host; -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata*)host->hostdata; -struct fc_info *fi = hostdata->fi; -struct fc_node_info *q; -u_long flags; - ENTER("iph5526_queuecommand"); - - spin_lock_irqsave(&fi->fc_lock, flags); - Cmnd->scsi_done = done; - - if (Cmnd->device->tagged_supported) { - switch(Cmnd->tag) { - case SIMPLE_QUEUE_TAG: - hostdata->cmnd.fcp_cntl = FCP_CNTL_QTYPE_SIMPLE; - break; - case HEAD_OF_QUEUE_TAG: - hostdata->cmnd.fcp_cntl = FCP_CNTL_QTYPE_HEAD_OF_Q; - break; - case ORDERED_QUEUE_TAG: - hostdata->cmnd.fcp_cntl = FCP_CNTL_QTYPE_ORDERED; - break; - default: - if ((jiffies - hostdata->tag_ages[Cmnd->device->id]) > (5 * HZ)) { - hostdata->cmnd.fcp_cntl = FCP_CNTL_QTYPE_ORDERED; - hostdata->tag_ages[Cmnd->device->id] = jiffies; - } - else - hostdata->cmnd.fcp_cntl = FCP_CNTL_QTYPE_SIMPLE; - break; - } - } - /*else - hostdata->cmnd.fcp_cntl = FCP_CNTL_QTYPE_UNTAGGED; - */ - - hostdata->cmnd.fcp_addr[3] = 0; - hostdata->cmnd.fcp_addr[2] = 0; - hostdata->cmnd.fcp_addr[1] = 0; - hostdata->cmnd.fcp_addr[0] = htons(Cmnd->device->lun); - - memcpy(&hostdata->cmnd.fcp_cdb, Cmnd->cmnd, Cmnd->cmd_len); - hostdata->cmnd.fcp_data_len = htonl(Cmnd->request_bufflen); - - /* Get an used OX_ID. We could have pending commands. - */ - if (get_scsi_oxid(fi)) { - spin_unlock_irqrestore(&fi->fc_lock, flags); - return 1; - } - fi->q.free_scsi_oxid[fi->g.scsi_oxid] = OXID_INUSE; - - /* Maintain a handler so that we can associate the done() function - * on completion of the SCSI command. - */ - hostdata->cmnd_handler[fi->g.scsi_oxid] = Cmnd; - - switch(Cmnd->cmnd[0]) { - case WRITE_6: - case WRITE_10: - case WRITE_12: - fi->g.type_of_frame = FC_SCSI_WRITE; - hostdata->cmnd.fcp_cntl = htonl(FCP_CNTL_WRITE | hostdata->cmnd.fcp_cntl); - break; - default: - fi->g.type_of_frame = FC_SCSI_READ; - hostdata->cmnd.fcp_cntl = htonl(FCP_CNTL_READ | hostdata->cmnd.fcp_cntl); - } - - memcpy(fi->q.ptr_fcp_cmnd[fi->q.fcp_cmnd_indx], &(hostdata->cmnd), sizeof(fcp_cmd)); - - q = resolve_target(fi, Cmnd->device->id); - - if (q == NULL) { - u_int bad_id = fi->g.my_ddaa | 0xFE; - /* We transmit to an non-existant AL_PA so that the "done" - * function can be called while receiving the interrupt - * due to a Timeout for a bad AL_PA. In a PTP configuration, - * the int_required field is set, since there is no notion - * of AL_PAs. This approach sucks, but works alright! - */ - if (fi->g.ptp_up == TRUE) - int_required = 1; - tx_exchange(fi, (char *)(&(hostdata->cmnd)), sizeof(fcp_cmd), r_ctl, type, bad_id, fi->g.my_mtu, int_required, ox_id, FC_SCSI_BAD_TARGET); - spin_unlock_irqrestore(&fi->fc_lock, flags); - DPRINTK1("Target ID %x not present", Cmnd->target); - return 0; - } - if (q->login == LOGIN_COMPLETED) { - if (add_to_sest(fi, Cmnd, q)) { - DPRINTK1("add_to_sest() failed."); - spin_unlock_irqrestore(&fi->fc_lock, flags); - return 0; - } - tx_exchange(fi, (char *)(fi->q.ptr_fcp_cmnd[fi->q.fcp_cmnd_indx]), sizeof(fcp_cmd), r_ctl, type, q->d_id, q->mtu, int_required, ox_id, frame_class << 16); - update_FCP_CMND_indx(fi); - } - spin_unlock_irqrestore(&fi->fc_lock, flags); - /* If q != NULL, then we have a SCSI Target. - * If q->login != LOGIN_COMPLETED, then that device could be - * offline temporarily. So we let the command to time-out. - */ - LEAVE("iph5526_queuecommand"); - return 0; -} - -int iph5526_abort(Scsi_Cmnd *Cmnd) -{ -struct Scsi_Host *host = Cmnd->device->host; -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata *)host->hostdata; -struct fc_info *fi = hostdata->fi; -struct fc_node_info *q; -u_int r_ctl = FC4_DEVICE_DATA | UNSOLICITED_COMMAND; -u_int type = TYPE_FCP | SEQUENCE_INITIATIVE; -u_short ox_id = OX_ID_FIRST_SEQUENCE; -int int_required = 1, i, abort_status = FALSE; -u_long flags; - - ENTER("iph5526_abort"); - - spin_lock_irqsave(&fi->fc_lock, flags); - - q = resolve_target(fi, Cmnd->device->id); - if (q == NULL) { - u_int bad_id = fi->g.my_ddaa | 0xFE; - /* This should not happen as we should always be able to - * resolve a target id. But, jus in case... - * We transmit to an non-existant AL_PA so that the done - * function can be called while receiving the interrupt - * for a bad AL_PA. - */ - DPRINTK1("Unresolved Target ID!"); - tx_exchange(fi, (char *)(&(hostdata->cmnd)), sizeof(fcp_cmd), r_ctl, type, bad_id, fi->g.my_mtu, int_required, ox_id, FC_SCSI_BAD_TARGET); - DPRINTK1("Target ID %x not present", Cmnd->target); - spin_unlock_irqrestore(&fi->fc_lock, flags); - return FAILED; - } - - /* If q != NULL, then we have a SCSI Target. If - * q->login != LOGIN_COMPLETED, then that device could - * be offline temporarily. So we let the command to time-out. - */ - - /* Get the OX_ID for the Command to be aborted. - */ - for (i = 0; i <= MAX_SCSI_XID; i++) { - if (hostdata->cmnd_handler[i] == Cmnd) { - hostdata->cmnd_handler[i] = NULL; - ox_id = i; - break; - } - } - if (i > MAX_SCSI_XID) { - T_MSG("Command could not be resolved to OX_ID"); - spin_unlock_irqrestore(&fi->fc_lock, flags); - return FAILED; - } - - switch(Cmnd->cmnd[0]) { - case WRITE_6: - case WRITE_10: - case WRITE_12: - break; - default: - ox_id |= SCSI_READ_BIT; - } - abort_status = abort_exchange(fi, ox_id); - - if ((q->login == LOGIN_COMPLETED) && (abort_status == TRUE)) { - /* Then, transmit an ABTS to the target. The rest - * is done when the BA_ACC is received for the ABTS. - */ - tx_abts(fi, q->d_id, ox_id); - } - else { - u_int STE_bit; - u_short x_id; - /* Invalidate resources for that Exchange. - */ - x_id = ox_id & MAX_SCSI_XID; - STE_bit = ntohl(*fi->q.ptr_sest[x_id]); - if (STE_bit & SEST_V) { - *(fi->q.ptr_sest[x_id]) &= htonl(SEST_INV); - invalidate_SEST_entry(fi, ox_id); - } - } - - LEAVE("iph5526_abort"); - spin_unlock_irqrestore(&fi->fc_lock, flags); - return SUCCESS; -} - -static int abort_exchange(struct fc_info *fi, u_short ox_id) -{ -u_short x_id; -volatile u_int flush_SEST, STE_bit; - x_id = ox_id & MAX_SCSI_XID; - DPRINTK1("Aborting Exchange %x", ox_id); - - STE_bit = ntohl(*fi->q.ptr_sest[x_id]); - /* Is the Exchange still active?. - */ - if (STE_bit & SEST_V) { - if (ox_id & SCSI_READ_BIT) { - /* If the Exchange to be aborted is Inbound, - * Flush the SEST Entry from Tachyon's Cache. - */ - *(fi->q.ptr_sest[x_id]) &= htonl(SEST_INV); - flush_tachyon_cache(fi, ox_id); - flush_SEST = readl(fi->t_r.ptr_tach_flush_oxid_reg); - while ((flush_SEST & 0x80000000) != 0) - flush_SEST = readl(fi->t_r.ptr_tach_flush_oxid_reg); - STE_bit = ntohl(*fi->q.ptr_sest[x_id]); - while ((STE_bit & 0x80000000) != 0) - STE_bit = ntohl(*fi->q.ptr_sest[x_id]); - flush_SEST = readl(fi->t_r.ptr_tach_flush_oxid_reg); - invalidate_SEST_entry(fi, ox_id); - } - else { - int i; - u_int *ptr_edb; - /* For In-Order Reassembly, the following is done: - * First, write zero as the buffer length in the EDB. - */ - ptr_edb = bus_to_virt(ntohl(*(fi->q.ptr_sest[x_id] + 7))); - for (i = 0; i < EDB_LEN; i++) - if (fi->q.ptr_edb[i] == ptr_edb) - break; - if (i < EDB_LEN) - *ptr_edb = *ptr_edb & 0x0000FFFF; - else - T_MSG("EDB not found while clearing in abort_exchange()"); - } - DPRINTK1("Exchange %x invalidated", ox_id); - return TRUE; - } - else { - DPRINTK1("SEST Entry for exchange %x not valid", ox_id); - return FALSE; - } -} - -static void flush_tachyon_cache(struct fc_info *fi, u_short ox_id) -{ -volatile u_int tachyon_status; - if (fi->g.loop_up == TRUE) { - writel(HOST_CONTROL, fi->t_r.ptr_fm_control_reg); - /* Make sure that the Inbound FIFO is empty. - */ - do { - tachyon_status = readl(fi->t_r.ptr_tach_status_reg); - udelay(200); - }while ((tachyon_status & RECEIVE_FIFO_EMPTY) == 0); - /* Ok. Go ahead and flushhhhhhhhh! - */ - writel(0x80000000 | ox_id, fi->t_r.ptr_tach_flush_oxid_reg); - writel(EXIT_HOST_CONTROL, fi->t_r.ptr_fm_control_reg); - return; - } - if (fi->g.ptp_up == TRUE) { - take_tachyon_offline(fi); - /* Make sure that the Inbound FIFO is empty. - */ - do { - tachyon_status = readl(fi->t_r.ptr_tach_status_reg); - udelay(200); - }while ((tachyon_status & RECEIVE_FIFO_EMPTY) == 0); - writel(0x80000000 | ox_id, fi->t_r.ptr_tach_flush_oxid_reg); - /* Write the Initialize command to the FM Control reg. - */ - fi->g.n_port_try = TRUE; - DPRINTK1("In abort_exchange, TACHYON initializing as N_Port...\n"); - writel(INITIALIZE, fi->t_r.ptr_fm_control_reg); - } -} - -static struct fc_node_info *resolve_target(struct fc_info *fi, u_char target) -{ -struct fc_node_info *temp = fi->node_info_list; - while(temp != NULL) - if (temp->target_id == target) { - if ((temp->scsi == TARGET) && (temp->login == LOGIN_COMPLETED)) - return temp; - else { - if (temp->login != LOGIN_COMPLETED) { - /* The Target is not currently logged in. - * It could be a Target on the Local Loop or - * on a Remote Loop connected through a switch. - * In either case, we will know whenever the Target - * comes On-Line again. We let the command to - * time-out so that it gets retried. - */ - T_MSG("Target %d not logged in.", temp->target_id); - tx_logi(fi, ELS_PLOGI, temp->d_id); - return temp; - } - else { - if (temp->scsi != TARGET) { - /* For some reason, we did not get a response to - * PRLI. Letz try it again... - */ - DPRINTK1("Node not PRLIied. Txing PRLI..."); - tx_prli(fi, ELS_PRLI, temp->d_id, OX_ID_FIRST_SEQUENCE); - } - } - return temp; - } - } - else - temp = temp->next; - return NULL; -} - -static int add_to_sest(struct fc_info *fi, Scsi_Cmnd *Cmnd, struct fc_node_info *ni) -{ -/* we have at least 1 buffer, the terminator */ -int no_of_sdb_buffers = 1, i; -int no_of_edb_buffers = 0; -u_int *req_buffer = (u_int *)Cmnd->request_buffer; -u_int *ptr_sdb = NULL; -struct scatterlist *sl1, *sl2 = NULL; -int no_of_sg = 0; - - switch(fi->g.type_of_frame) { - case FC_SCSI_READ: - fi->g.inb_sest_entry.flags_and_byte_offset = htonl(INB_SEST_VED); - fi->g.inb_sest_entry.byte_count = 0; - fi->g.inb_sest_entry.no_of_recvd_frames = 0; - fi->g.inb_sest_entry.no_of_expected_frames = 0; - fi->g.inb_sest_entry.last_fctl = 0; - - if (Cmnd->use_sg) { - no_of_sg = Cmnd->use_sg; - sl1 = sl2 = (struct scatterlist *)Cmnd->request_buffer; - for (i = 0; i < no_of_sg; i++) { - no_of_sdb_buffers += sl1->length / SEST_BUFFER_SIZE; - if (sl1->length % SEST_BUFFER_SIZE) - no_of_sdb_buffers++; - sl1++; - } - } - else { - no_of_sdb_buffers += Cmnd->request_bufflen / SEST_BUFFER_SIZE; - if (Cmnd->request_bufflen % SEST_BUFFER_SIZE) - no_of_sdb_buffers++; - } /* if !use_sg */ - - /* We are working with the premise that at the max we would - * get a scatter-gather buffer containing 63 buffers - * of size 1024 bytes each. Is it a _bad_ assumption? - */ - if (no_of_sdb_buffers > 512) { - T_MSG("Number of SDB buffers needed = %d", no_of_sdb_buffers); - T_MSG("Disable Scatter-Gather!!!"); - return 1; - } - - - /* Store it in the sdb_table so that we can retrieve that - * free up the memory when the Read Command completes. - */ - if (get_free_SDB(fi)) - return 1; - ptr_sdb = fi->q.ptr_sdb_slot[fi->q.sdb_indx]; - fi->q.sdb_slot_status[fi->q.sdb_indx] = SDB_BUSY; - fi->g.inb_sest_entry.sdb_address = htonl(virt_to_bus(ptr_sdb)); - - if (Cmnd->use_sg) { - int count = 0, j; - for(i = 0; i < no_of_sg; i++) { - char *addr_ptr = sl2->address; - count = sl2->length / SEST_BUFFER_SIZE; - if (sl2->length % SEST_BUFFER_SIZE) - count++; - for (j = 0; j < count; j++) { - *(ptr_sdb) = htonl(virt_to_bus(addr_ptr)); - addr_ptr += SEST_BUFFER_SIZE; - ptr_sdb++; - } - count = 0; - sl2++; - } - } - else { - for (i = 0; i < no_of_sdb_buffers - 1; i++) { - *(ptr_sdb) = htonl(virt_to_bus(req_buffer)); - req_buffer += SEST_BUFFER_SIZE/4; - ptr_sdb++; - } - } - *(ptr_sdb) = htonl(0x1); /* Terminator */ - - /* The scratch pad is used to hold the index into the SDB. - */ - fi->g.inb_sest_entry.scratch_pad = fi->q.sdb_indx; - fi->g.inb_sest_entry.expected_ro = 0; - fi->g.inb_sest_entry.buffer_index = 0; - fi->g.inb_sest_entry.buffer_offset = 0; - memcpy(fi->q.ptr_sest[fi->g.scsi_oxid], &fi->g.inb_sest_entry, sizeof(INB_SEST_ENTRY)); - break; - case FC_SCSI_WRITE: - fi->g.outb_sest_entry.flags_and_did = htonl(OUTB_SEST_VED | ni->d_id); - fi->g.outb_sest_entry.max_frame_len = htons(ni->mtu << 4); - fi->g.outb_sest_entry.cntl = htons(ODB_CLASS_3 | ODB_EE_CREDIT | ODB_NO_INT | ODB_NO_COMP); - fi->g.outb_sest_entry.total_seq_length = INV_SEQ_LEN; - fi->g.outb_sest_entry.link = htons(OUTB_SEST_LINK); - fi->g.outb_sest_entry.transaction_id = htonl(fi->g.scsi_oxid); - fi->g.outb_sest_entry.seq_id = fi->g.seq_id; - fi->g.outb_sest_entry.reserved = 0x0; - fi->g.outb_sest_entry.header_length = htons(TACHYON_HEADER_LEN); - - { - u_char df_ctl = 0; - u_short rx_id = RX_ID_FIRST_SEQUENCE; - u_int r_ctl = FC4_DEVICE_DATA | SOLICITED_DATA; - u_int type = TYPE_FCP | SEQUENCE_INITIATIVE; - /* Multi Frame Sequence ? If yes, set RO bit. - */ - if (Cmnd->request_bufflen > ni->mtu) - type |= RELATIVE_OFF_PRESENT; - build_tachyon_header(fi, fi->g.my_id, r_ctl, ni->d_id, type, fi->g.seq_id, df_ctl, fi->g.scsi_oxid, rx_id, NULL); - if (get_free_header(fi) || get_free_EDB(fi)) - return 1; - memcpy(fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx], &(fi->g.tach_header), TACHYON_HEADER_LEN); - fi->g.outb_sest_entry.header_address = htonl(virt_to_bus(fi->q.ptr_tachyon_header[fi->q.tachyon_header_indx])); - update_tachyon_header_indx(fi); - } - - if (Cmnd->use_sg) { - no_of_sg = Cmnd->use_sg; - sl1 = sl2 = (struct scatterlist *)Cmnd->request_buffer; - for (i = 0; i < no_of_sg; i++) { - no_of_edb_buffers += sl1->length / SEST_BUFFER_SIZE; - if (sl1->length % SEST_BUFFER_SIZE) - no_of_edb_buffers++; - sl1++; - } - } - else { - no_of_edb_buffers += Cmnd->request_bufflen / SEST_BUFFER_SIZE; - if (Cmnd->request_bufflen % SEST_BUFFER_SIZE) - no_of_edb_buffers++; - } /* if !use_sg */ - - - /* We need "no_of_edb_buffers" _contiguous_ EDBs - * that are FREE. Check for that first. - */ - for (i = 0; i < no_of_edb_buffers; i++) { - int j; - if ((fi->q.edb_buffer_indx + no_of_edb_buffers) >= EDB_LEN) - fi->q.edb_buffer_indx = 0; - if (fi->q.free_edb_list[fi->q.edb_buffer_indx + i] != EDB_FREE) { - for (j = 0; j < i; j++) - update_EDB_indx(fi); - if (get_free_EDB(fi)) - return 1; - i = 0; - } - } - - /* We got enuff FREE EDBs. - */ - if (Cmnd->use_sg) { - fi->g.outb_sest_entry.edb_address = htonl(virt_to_bus(fi->q.ptr_edb[fi->q.edb_buffer_indx])); - sl1 = (struct scatterlist *)Cmnd->request_buffer; - for(i = 0; i < no_of_sg; i++) { - int count = 0, j; - count = sl1->length / SEST_BUFFER_SIZE; - for (j = 0; j < count; j++) { - build_EDB(fi, (char *)sl1->address, 0, SEST_BUFFER_SIZE); - memcpy(fi->q.ptr_edb[fi->q.edb_buffer_indx], &(fi->g.edb), sizeof(EDB)); - /* Mark this EDB as being in use */ - fi->q.free_edb_list[fi->q.edb_buffer_indx] = EDB_BUSY; - /* We have already made sure that we have enuff - * free EDBs that are contiguous. So this is - * safe. - */ - update_EDB_indx(fi); - sl1->address += SEST_BUFFER_SIZE; - } - /* Just in case itz not a multiple of - * SEST_BUFFER_SIZE bytes. - */ - if (sl1->length % SEST_BUFFER_SIZE) { - build_EDB(fi, (char *)sl1->address, 0, sl1->length % SEST_BUFFER_SIZE); - memcpy(fi->q.ptr_edb[fi->q.edb_buffer_indx], &(fi->g.edb), sizeof(EDB)); - fi->q.free_edb_list[fi->q.edb_buffer_indx] = EDB_BUSY; - update_EDB_indx(fi); - } - sl1++; - } - /* The last EDB is special. It needs the "end bit" to - * be set. - */ - *(fi->q.ptr_edb[fi->q.edb_buffer_indx - 1] + 1) = *(fi->q.ptr_edb[fi->q.edb_buffer_indx - 1] + 1) | ntohs(EDB_END); - } - else { - int count = 0, j; - fi->g.outb_sest_entry.edb_address = htonl(virt_to_bus(fi->q.ptr_edb[fi->q.edb_buffer_indx])); - count = Cmnd->request_bufflen / SEST_BUFFER_SIZE; - for (j = 0; j < count; j++) { - build_EDB(fi, (char *)req_buffer, 0, SEST_BUFFER_SIZE); - memcpy(fi->q.ptr_edb[fi->q.edb_buffer_indx], &(fi->g.edb), sizeof(EDB)); - /* Mark this EDB as being in use */ - fi->q.free_edb_list[fi->q.edb_buffer_indx] = EDB_BUSY; - /* We have already made sure that we have enuff - * free EDBs that are contiguous. So this is - * safe. - */ - update_EDB_indx(fi); - req_buffer += SEST_BUFFER_SIZE; - } - /* Just in case itz not a multiple of - * SEST_BUFFER_SIZE bytes. - */ - if (Cmnd->request_bufflen % SEST_BUFFER_SIZE) { - build_EDB(fi, (char *)req_buffer, EDB_END, Cmnd->request_bufflen % SEST_BUFFER_SIZE); - memcpy(fi->q.ptr_edb[fi->q.edb_buffer_indx], &(fi->g.edb), sizeof(EDB)); - fi->q.free_edb_list[fi->q.edb_buffer_indx] = EDB_BUSY; - update_EDB_indx(fi); - } - else { - /* Mark the last EDB as the "end edb". - */ - *(fi->q.ptr_edb[fi->q.edb_buffer_indx - 1] + 1) = *(fi->q.ptr_edb[fi->q.edb_buffer_indx - 1] + 1) | htons(EDB_END); - } - } - - /* Finally we have something to send!. - */ - memcpy(fi->q.ptr_sest[fi->g.scsi_oxid], &fi->g.outb_sest_entry, sizeof(OUTB_SEST_ENTRY)); - break; - } - return 0; -} - -static void update_FCP_CMND_indx(struct fc_info *fi) -{ - fi->q.fcp_cmnd_indx++; - if (fi->q.fcp_cmnd_indx == NO_OF_FCP_CMNDS) - fi->q.fcp_cmnd_indx = 0; -} - -static int get_scsi_oxid(struct fc_info *fi) -{ -u_short initial_oxid = fi->g.scsi_oxid; - /* Check if the OX_ID is in use. - * We could have an outstanding SCSI command. - */ - while (fi->q.free_scsi_oxid[fi->g.scsi_oxid] != OXID_AVAILABLE) { - update_scsi_oxid(fi); - if (fi->g.scsi_oxid == initial_oxid) { - T_MSG("No free OX_IDs avaliable") - reset_tachyon(fi, SOFTWARE_RESET); - return 1; - } - } - return 0; -} - -static void update_scsi_oxid(struct fc_info *fi) -{ - fi->g.scsi_oxid++; - if (fi->g.scsi_oxid == (MAX_SCSI_XID + 1)) - fi->g.scsi_oxid = 0; -} - -static int get_free_SDB(struct fc_info *fi) -{ -unsigned int initial_indx = fi->q.sdb_indx; - /* Check if the SDB is in use. - * We could have an outstanding SCSI Read command. - * We should find a free slot as we can queue a - * maximum of 32 SCSI commands only. - */ - while (fi->q.sdb_slot_status[fi->q.sdb_indx] != SDB_FREE) { - update_SDB_indx(fi); - if (fi->q.sdb_indx == initial_indx) { - T_MSG("No free SDB buffers avaliable") - reset_tachyon(fi, SOFTWARE_RESET); - return 1; - } - } - return 0; -} - -static void update_SDB_indx(struct fc_info *fi) -{ - fi->q.sdb_indx++; - if (fi->q.sdb_indx == NO_OF_SDB_ENTRIES) - fi->q.sdb_indx = 0; -} - -int iph5526_release(struct Scsi_Host *host) -{ -struct iph5526_hostdata *hostdata = (struct iph5526_hostdata*)host->hostdata; -struct fc_info *fi = hostdata->fi; - free_irq(host->irq, host); - iounmap(fi->g.mem_base); - return 0; -} - -const char *iph5526_info(struct Scsi_Host *host) -{ -static char buf[80]; - sprintf(buf, "Interphase 5526 Fibre Channel PCI SCSI Adapter using IRQ %d\n", host->irq); - return buf; -} - -#define NAMELEN 8 /* # of chars for storing dev->name */ - -static struct net_device *dev_fc[MAX_FC_CARDS]; - -static int io; -static int irq; -static int bad; /* 0xbad = bad sig or no reset ack */ -static int scsi_registered; - - -static int __init iph5526_init(void) -{ - int i = 0; - - driver_template.module = THIS_MODULE; - scsi_register_host(&driver_template); - if (driver_template.present) - scsi_registered = TRUE; - else { - printk("iph5526: SCSI registeration failed!!!\n"); - scsi_registered = FALSE; - scsi_unregister_host(&driver_template); - } - - while(fc[i] != NULL) { - struct net_device *dev = alloc_fcdev(0); - int err; - - if (!dev) { - printk("iph5526.c: init_fcdev failed for card #%d\n", i+1); - break; - } - dev->priv = fc[i]; - iph5526_probe_pci(dev); - err = register_netdev(dev); - if (err < 0) { - free_netdev(dev); - printk("iph5526.c: init_fcdev failed for card #%d\n", i+1); - break; - } - dev_fc[i] = dev; - i++; - } - if (i == 0) - return -ENODEV; - - return 0; -} - -static void __exit iph5526_exit(void) -{ - int i = 0; - while(fc[i] != NULL) { - struct net_device *dev = fc[i]->dev; - void *priv = dev->priv; - fc[i]->g.dont_init = TRUE; - take_tachyon_offline(fc[i]); - unregister_netdev(dev); - clean_up_memory(fc[i]); - if (dev->priv) - kfree(priv); - free_netdev(dev); - dev = NULL; - i++; - } - if (scsi_registered == TRUE) - scsi_unregister_host(&driver_template); -} - -module_init(iph5526_init); -module_exit(iph5526_exit); - -void clean_up_memory(struct fc_info *fi) -{ -int i,j; - ENTER("clean_up_memory"); - if (fi->q.ptr_mfsbq_base) - free_pages((u_long)bus_to_virt(ntohl(*(fi->q.ptr_mfsbq_base))), 5); - DPRINTK("after kfree2"); - for (i = 0; i < SFSBQ_LENGTH; i++) - for (j = 0; j < NO_OF_ENTRIES; j++) - if (fi->q.ptr_sfs_buffers[i*NO_OF_ENTRIES + j]) - kfree(fi->q.ptr_sfs_buffers[i*NO_OF_ENTRIES + j]); - DPRINTK("after kfree1"); - if (fi->q.ptr_ocq_base) - free_page((u_long)fi->q.ptr_ocq_base); - if (fi->q.ptr_imq_base) - free_page((u_long)fi->q.ptr_imq_base); - if (fi->q.ptr_mfsbq_base) - free_page((u_long)fi->q.ptr_mfsbq_base); - if (fi->q.ptr_sfsbq_base) - free_page((u_long)fi->q.ptr_sfsbq_base); - if (fi->q.ptr_edb_base) - free_pages((u_long)fi->q.ptr_edb_base, 5); - if (fi->q.ptr_sest_base) - free_pages((u_long)fi->q.ptr_sest_base, 5); - if (fi->q.ptr_tachyon_header_base) - free_page((u_long)fi->q.ptr_tachyon_header_base); - if (fi->q.ptr_sdb_base) - free_pages((u_long)fi->q.ptr_sdb_base, 5); - if (fi->q.ptr_fcp_cmnd_base) - free_page((u_long)fi->q.ptr_fcp_cmnd_base); - DPRINTK("after free_pages"); - if (fi->q.ptr_host_ocq_cons_indx) - kfree(fi->q.ptr_host_ocq_cons_indx); - if (fi->q.ptr_host_hpcq_cons_indx) - kfree(fi->q.ptr_host_hpcq_cons_indx); - if (fi->q.ptr_host_imq_prod_indx) - kfree(fi->q.ptr_host_imq_prod_indx); - DPRINTK("after kfree3"); - while (fi->node_info_list) { - struct fc_node_info *temp_list = fi->node_info_list; - fi->node_info_list = fi->node_info_list->next; - kfree(temp_list); - } - while (fi->ox_id_list) { - struct ox_id_els_map *temp = fi->ox_id_list; - fi->ox_id_list = fi->ox_id_list->next; - kfree(temp); - } - LEAVE("clean_up_memory"); -} - -static int initialize_register_pointers(struct fc_info *fi) -{ -ENTER("initialize_register_pointers"); -if(fi->g.tachyon_base == 0) - return -ENOMEM; - -fi->i_r.ptr_ichip_hw_control_reg = ICHIP_HW_CONTROL_REG_OFF + fi->g.tachyon_base; -fi->i_r.ptr_ichip_hw_status_reg = ICHIP_HW_STATUS_REG_OFF + fi->g.tachyon_base; -fi->i_r.ptr_ichip_hw_addr_mask_reg = ICHIP_HW_ADDR_MASK_REG_OFF + fi->g.tachyon_base; -fi->t_r.ptr_ocq_base_reg = OCQ_BASE_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_ocq_len_reg = OCQ_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_ocq_prod_indx_reg = OCQ_PRODUCER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_ocq_cons_indx_reg = OCQ_CONSUMER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_imq_base_reg = IMQ_BASE_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_imq_len_reg = IMQ_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_imq_cons_indx_reg = IMQ_CONSUMER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_imq_prod_indx_reg = IMQ_PRODUCER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_mfsbq_base_reg = MFSBQ_BASE_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_mfsbq_len_reg = MFSBQ_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_mfsbq_prod_reg = MFSBQ_PRODUCER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_mfsbq_cons_reg = MFSBQ_CONSUMER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_mfsbuff_len_reg = MFS_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sfsbq_base_reg = SFSBQ_BASE_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sfsbq_len_reg = SFSBQ_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sfsbq_prod_reg = SFSBQ_PRODUCER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sfsbq_cons_reg = SFSBQ_CONSUMER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sfsbuff_len_reg = SFS_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sest_base_reg = SEST_BASE_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_sest_len_reg = SEST_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_scsibuff_len_reg = SCSI_LENGTH_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_tach_config_reg = TACHYON_CONFIG_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_tach_control_reg = TACHYON_CONTROL_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_tach_status_reg = TACHYON_STATUS_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_tach_flush_oxid_reg = TACHYON_FLUSH_SEST_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_config_reg = FMGR_CONFIG_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_control_reg = FMGR_CONTROL_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_status_reg = FMGR_STATUS_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_tov_reg = FMGR_TIMER_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_wwn_hi_reg = FMGR_WWN_HI_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_wwn_low_reg = FMGR_WWN_LO_REGISTER_OFFSET + fi->g.tachyon_base; -fi->t_r.ptr_fm_rx_al_pa_reg = FMGR_RCVD_ALPA_REGISTER_OFFSET + fi->g.tachyon_base; - -LEAVE("initialize_register_pointers"); -return 1; -} - - - -/* - * Local variables: - * compile-command: "gcc -DKERNEL -Wall -O6 -fomit-frame-pointer -I/usr/src/linux/net/tcp -c iph5526.c" - * version-control: t - * kept-new-versions: 5 - * End: - */ ===== drivers/net/fc/iph5526_ip.h 1.1 vs edited ===== --- 1.1/drivers/net/fc/iph5526_ip.h 2002-02-05 18:40:03 +01:00 +++ edited/drivers/net/fc/iph5526_ip.h 2004-09-06 11:54:04 +02:00 @@ -1,25 +0,0 @@ -#ifndef IPH5526_IP_H -#define IPH5526_IP_H - -#define LLC_SNAP_LEN 0x8 - -/* Offsets into the ARP frame */ -#define ARP_OPCODE_0 (0x6 + LLC_SNAP_LEN) -#define ARP_OPCODE_1 (0x7 + LLC_SNAP_LEN) - -int iph5526_probe(struct net_device *dev); -static int fcdev_init(struct net_device *dev); -static int iph5526_open(struct net_device *dev); -static int iph5526_close(struct net_device *dev); -static int iph5526_send_packet(struct sk_buff *skb, struct net_device *dev); -static struct net_device_stats * iph5526_get_stats(struct net_device *dev); -static int iph5526_change_mtu(struct net_device *dev, int mtu); - - -static void rx_net_packet(struct fc_info *fi, u_char *buff_addr, int payload_size); -static void rx_net_mfs_packet(struct fc_info *fi, struct sk_buff *skb); -unsigned short fc_type_trans(struct sk_buff *skb, struct net_device *dev); -static int tx_ip_packet(struct sk_buff *skb, unsigned long len, struct fc_info *fi); -static int tx_arp_packet(char *data, unsigned long len, struct fc_info *fi); -#endif - ===== drivers/net/fc/iph5526_novram.c 1.1 vs edited ===== --- 1.1/drivers/net/fc/iph5526_novram.c 2002-02-05 18:40:03 +01:00 +++ edited/drivers/net/fc/iph5526_novram.c 2004-09-06 11:54:09 +02:00 @@ -1,278 +0,0 @@ -/********************************************************************** - * Reading the NVRAM on the Interphase 5526 PCI Fibre Channel Card. - * All contents in this file : courtesy Interphase Corporation. - * Special thanks to Kevin Quick, kquick@iphase.com. - **********************************************************************/ - -#define FF_MAGIC 0x4646 -#define DB_MAGIC 0x4442 -#define DL_MAGIC 0x444d - - -#define CMD_LEN 9 - -/*********** - * - * Switches and defines for header files. - * - * The following defines are used to turn on and off - * various options in the header files. Primarily useful - * for debugging. - * - ***********/ - -static const unsigned short novram_default[4] = { - FF_MAGIC, - DB_MAGIC, - DL_MAGIC, - 0 }; - - -/* - * a list of the commands that can be sent to the NOVRAM - */ - -#define NR_EXTEND 0x100 -#define NR_WRITE 0x140 -#define NR_READ 0x180 -#define NR_ERASE 0x1c0 - -#define EWDS 0x00 -#define WRAL 0x10 -#define ERAL 0x20 -#define EWEN 0x30 - -/* - * Defines for the pins on the NOVRAM - */ - -#define BIT(x) (1 << (x)) - -#define NVDI_B 31 -#define NVDI BIT(NVDI_B) -#define NVDO BIT(9) -#define NVCE BIT(30) -#define NVSK BIT(29) -#define NV_MANUAL BIT(28) - -/*********** - * - * Include files. - * - ***********/ - -#define KeStallExecutionProcessor(x) {volatile int d, p;\ - for (d=0; dn_r.ptr_novram_hw_control_reg); \ - t &= (val); \ - writel(t, fi->n_r.ptr_novram_hw_control_reg); \ - } - -/*********************** - * - * This define ors the value and the current config register and puts - * the result in the config register - * - ***********************/ - -#define CFG_OR(val) { volatile int t; \ - t = readl(fi->n_r.ptr_novram_hw_control_reg); \ - t |= (val); \ - writel(t, fi->n_r.ptr_novram_hw_control_reg); \ - } - -/*********************** - * - * Send a command to the NOVRAM, the command is in cmd. - * - * clear CE and SK. Then assert CE. - * Clock each of the command bits out in the correct order with SK - * exit with CE still asserted - * - ***********************/ - -#define NVRAM_CMD(cmd) { int i; \ - int c = cmd; \ - CFG_AND(~(NVCE|NVSK)); \ - CFG_OR(NVCE); \ - for (i=0; in_r.ptr_novram_hw_status_reg) & NVDO) ? 1 : 0; \ - } - -/*********** - * - * Function Prototypes - * - ***********/ - -static int iph5526_nr_get(struct fc_info *fi, int addr); -static void iph5526_nr_do_init(struct fc_info *fi); -static void iph5526_nr_checksum(struct fc_info *fi); - - -/******************************************************************* - * - * Local routine: iph5526_nr_do_init - * Purpose: initialize novram server - * Description: - * - * iph5526_nr_do_init reads the novram into the temporary holding place. - * A checksum is done on the area and the Magic Cookies are checked. - * If any of them are bad, the NOVRAM is initialized with the - * default values and a warning message is displayed. - * - *******************************************************************/ - -static void iph5526_nr_do_init(struct fc_info *fi) -{ - int i; - unsigned short chksum = 0; - int bad = 0; - - for (i=0; in_r.data[i] = iph5526_nr_get(fi, i); - chksum += fi->n_r.data[i]; - } - - if (chksum) - bad = 1; - - if (fi->n_r.data[IPH5526_NOVRAM_SIZE - 4] != FF_MAGIC) - bad = 1; - if (fi->n_r.data[IPH5526_NOVRAM_SIZE - 3] != DB_MAGIC) - bad = 1; - if (fi->n_r.data[IPH5526_NOVRAM_SIZE - 2] != DL_MAGIC) - bad = 1; - - if (bad) { - for (i=0; in_r.data[i] = 0xffff; - } else { - fi->n_r.data[i] = novram_default[i - (IPH5526_NOVRAM_SIZE - 4)]; - } - } - iph5526_nr_checksum(fi); - } -} - - -/******************************************************************* - * - * Local routine: iph5526_nr_get - * Purpose: read a single word of NOVRAM - * Description: - * - * read the 16 bits that make up a word addr of the novram. - * The 16 bits of data that are read are returned as the return value - * - *******************************************************************/ - -static int iph5526_nr_get(struct fc_info *fi, int addr) -{ - int i; - int t; - int val = 0; - - CFG_OR(NV_MANUAL); - - /* - * read the first bit that was clocked with the falling edge of the - * the last command data clock - */ - - NVRAM_CMD(NR_READ + addr); - - /* - * Now read the rest of the bits, the next bit read is D1, then D2, - * and so on - */ - - val = 0; - for (i=0; i<16; i++) { - NVRAM_CLKIN(t); - val <<= 1; - val |= t; - } - NVRAM_CLR_CE; - - CFG_OR(NVDI); - CFG_AND(~NV_MANUAL); - - return(val); -} - - - - -/******************************************************************* - * - * Local routine: iph5526_nr_checksum - * Purpose: calculate novram checksum on fi->n_r.data - * Description: - * - * calculate a checksum for the novram on the image that is - * currently in fi->n_r.data - * - *******************************************************************/ - -static void iph5526_nr_checksum(struct fc_info *fi) -{ - int i; - unsigned short chksum = 0; - - for (i=0; i<(IPH5526_NOVRAM_SIZE - 1); i++) - chksum += fi->n_r.data[i]; - - fi->n_r.data[i] = -chksum; -} ===== drivers/net/fc/iph5526_scsi.h 1.4 vs edited ===== --- 1.4/drivers/net/fc/iph5526_scsi.h 2004-01-10 16:32:23 +01:00 +++ edited/drivers/net/fc/iph5526_scsi.h 2004-09-06 11:54:12 +02:00 @@ -1,31 +0,0 @@ -#ifndef IPH5526_SCSI_H -#define IPH5526_SCSI_H - -#define IPH5526_CAN_QUEUE 32 -#define IPH5526_SCSI_FC { \ - .name = "Interphase 5526 Fibre Channel SCSI Adapter", \ - .detect = iph5526_detect, \ - .release = iph5526_release, \ - .info = iph5526_info, \ - .queuecommand = iph5526_queuecommand, \ - .bios_param = iph5526_biosparam, \ - .can_queue = IPH5526_CAN_QUEUE, \ - .this_id = -1, \ - .sg_tablesize = 255, \ - .cmd_per_lun = 8, \ - .use_clustering = DISABLE_CLUSTERING, \ - .eh_abort_handler = iph5526_abort, \ - .eh_device_reset_handler = NULL, \ - .eh_bus_reset_handler = NULL, \ - .eh_host_reset_handler = NULL, \ -} - -int iph5526_detect(Scsi_Host_Template *tmpt); -int iph5526_queuecommand(Scsi_Cmnd *Cmnd, void (*done) (Scsi_Cmnd *)); -int iph5526_release(struct Scsi_Host *host); -int iph5526_abort(Scsi_Cmnd *Cmnd); -const char *iph5526_info(struct Scsi_Host *host); -int iph5526_biosparam(struct Scsi_Disk * disk, struct block_device *n, int ip[]); - -#endif - ===== drivers/net/fc/tach.h 1.2 vs edited ===== --- 1.2/drivers/net/fc/tach.h 2002-02-05 08:49:26 +01:00 +++ edited/drivers/net/fc/tach.h 2004-09-06 11:54:16 +02:00 @@ -1,475 +0,0 @@ -/********************************************************************** - * Defines for the Tachyon Fibre Channel Controller and the Interphase - * (i)chip TPI. - *********************************************************************/ - -#ifndef _TACH_H -#define _TACH_H - -#define MY_PAGE_SIZE 4096 -#define REPLICATE 0xFF -#define MAX_NODES 127 -#define BROADCAST 0xFFFFFF -#define BROADCAST_ADDR 0xFFFFFFFFFFFF -#define LOGIN_COMPLETED 2 -#define LOGIN_ATTEMPTED 1 -#define LOGIN_NOT_ATTEMPTED 0 -#define TRUE 1 -#define FALSE 0 - -#define TACHYON_LIMIT 0x01EF -#define TACHYON_OFFSET 0x200 - -/* Offsets to the (i) chip */ -#define ICHIP_HW_CONTROL_REG_OFF (0x080 - TACHYON_OFFSET) -#define ICHIP_HW_STATUS_REG_OFF (0x084 - TACHYON_OFFSET) -#define ICHIP_HW_ADDR_MASK_REG_OFF (0x090 - TACHYON_OFFSET) - -/* (i)chip Hardware Control Register defines */ -#define ICHIP_HCR_RESET 0x01 -#define ICHIP_HCR_DERESET 0x0 -#define ICHIP_HCR_ENABLE_INTA 0x0000003E -#define ICHIP_HCR_ENABLE_INTB 0x003E0000 -#define ICHIP_HCR_IWDATA_FIFO 0x800000 - -/* (i)chip Hardware Status Register defines */ -#define ICHIP_HSR_INT_LATCH 0x02 - -/* (i)chip Hardware Address Mask Register defines */ -#define ICHIP_HAMR_BYTE_SWAP_ADDR_TR 0x08 -#define ICHIP_HAMR_BYTE_SWAP_NO_ADDR_TR 0x04 - -/* NOVRAM defines */ -#define IPH5526_NOVRAM_SIZE 64 - - -/* Offsets for the registers that correspond to the - * Qs on the Tachyon (As defined in the Tachyon Manual). - */ - -/* Outbound Command Queue (OCQ). - */ -#define OCQ_BASE_REGISTER_OFFSET 0x000 -#define OCQ_LENGTH_REGISTER_OFFSET 0x004 -#define OCQ_PRODUCER_REGISTER_OFFSET 0x008 -#define OCQ_CONSUMER_REGISTER_OFFSET 0x00C - -/* Inbound Message Queue (IMQ). - */ -#define IMQ_BASE_REGISTER_OFFSET 0x080 -#define IMQ_LENGTH_REGISTER_OFFSET 0x084 -#define IMQ_CONSUMER_REGISTER_OFFSET 0x088 -#define IMQ_PRODUCER_REGISTER_OFFSET 0x08C - -/* Multiframe Sequence Buffer Queue (MFSBQ) - */ -#define MFSBQ_BASE_REGISTER_OFFSET 0x0C0 -#define MFSBQ_LENGTH_REGISTER_OFFSET 0x0C4 -#define MFSBQ_PRODUCER_REGISTER_OFFSET 0x0C8 -#define MFSBQ_CONSUMER_REGISTER_OFFSET 0x0CC -#define MFS_LENGTH_REGISTER_OFFSET 0x0D0 - -/* Single Frame Sequence Buffer Queue (SFSBQ) - */ -#define SFSBQ_BASE_REGISTER_OFFSET 0x100 -#define SFSBQ_LENGTH_REGISTER_OFFSET 0x104 -#define SFSBQ_PRODUCER_REGISTER_OFFSET 0x108 -#define SFSBQ_CONSUMER_REGISTER_OFFSET 0x10C -#define SFS_LENGTH_REGISTER_OFFSET 0x110 - -/* SCSI Exchange State Table (SEST) - */ -#define SEST_BASE_REGISTER_OFFSET 0x140 -#define SEST_LENGTH_REGISTER_OFFSET 0x144 -#define SCSI_LENGTH_REGISTER_OFFSET 0x148 - -/* Length of the various Qs - */ -#define NO_OF_ENTRIES 8 -#define OCQ_LENGTH (MY_PAGE_SIZE/32) -#define IMQ_LENGTH (MY_PAGE_SIZE/32) -#define MFSBQ_LENGTH 8 -#define SFSBQ_LENGTH 8 -#define SEST_LENGTH MY_PAGE_SIZE - -/* Size of the various buffers. - */ -#define TACH_FRAME_SIZE 2048 -#define MFS_BUFFER_SIZE TACH_FRAME_SIZE -#define SFS_BUFFER_SIZE (TACH_FRAME_SIZE + TACHYON_HEADER_LEN) -#define SEST_BUFFER_SIZE 512 -#define TACH_HEADER_SIZE 64 -#define NO_OF_TACH_HEADERS ((MY_PAGE_SIZE)/TACH_HEADER_SIZE) - -#define NO_OF_FCP_CMNDS (MY_PAGE_SIZE/32) -#define SDB_SIZE 2048 -#define NO_OF_SDB_ENTRIES ((32*MY_PAGE_SIZE)/SDB_SIZE) - - -/* Offsets to the other Tachyon registers. - * (As defined in the Tachyon manual) - */ -#define TACHYON_CONFIG_REGISTER_OFFSET 0x184 -#define TACHYON_CONTROL_REGISTER_OFFSET 0x188 -#define TACHYON_STATUS_REGISTER_OFFSET 0x18C -#define TACHYON_FLUSH_SEST_REGISTER_OFFSET 0x190 - -/* Defines for the Tachyon Configuration register. - */ -#define SCSI_ENABLE 0x40000000 -#define WRITE_STREAM_SIZE 0x800 /* size = 16 */ -#define READ_STREAM_SIZE 0x300 /* size = 64 */ -#define PARITY_EVEN 0x2 -#define OOO_REASSEMBLY_DISABLE 0x40 - -/* Defines for the Tachyon Control register. - */ -#define SOFTWARE_RESET 0x80000000 -#define OCQ_RESET 0x4 -#define ERROR_RELEASE 0x2 - -/* Defines for the Tachyon Status register. - */ -#define RECEIVE_FIFO_EMPTY 0x10 -#define OSM_FROZEN 0x1 -#define OCQ_RESET_STATUS 0x20 -#define SCSI_FREEZE_STATUS 0x40 - - -/* Offsets to the Frame Manager registers. - */ -#define FMGR_CONFIG_REGISTER_OFFSET 0x1C0 -#define FMGR_CONTROL_REGISTER_OFFSET 0x1C4 -#define FMGR_STATUS_REGISTER_OFFSET 0x1C8 -#define FMGR_TIMER_REGISTER_OFFSET 0x1CC -#define FMGR_WWN_HI_REGISTER_OFFSET 0x1E0 -#define FMGR_WWN_LO_REGISTER_OFFSET 0x1E4 -#define FMGR_RCVD_ALPA_REGISTER_OFFSET 0x1E8 - -/* Defines for the Frame Manager Configuration register. - */ -#define BB_CREDIT 0x10000 -#define NPORT 0x8000 -#define LOOP_INIT_FABRIC_ADDRESS 0x400 -#define LOOP_INIT_PREVIOUS_ADDRESS 0x200 -#define LOOP_INIT_SOFT_ADDRESS 0x80 - -/* Defines for the Frame Manager Control register. - */ -#define HOST_CONTROL 0x02 -#define EXIT_HOST_CONTROL 0x03 -#define OFFLINE 0x05 -#define INITIALIZE 0x06 -#define CLEAR_LF 0x07 - -/* Defines for the Frame Manager Status register. - */ -#define LOOP_UP 0x80000000 -#define TRANSMIT_PARITY_ERROR 0x40000000 -#define NON_PARTICIPATING 0x20000000 -#define OUT_OF_SYNC 0x02000000 -#define LOSS_OF_SIGNAL 0x01000000 -#define NOS_OLS_RECEIVED 0x00080000 -#define LOOP_STATE_TIMEOUT 0x00040000 -#define LIPF_RECEIVED 0x00020000 -#define BAD_ALPA 0x00010000 -#define LINK_FAILURE 0x00001000 -#define ELASTIC_STORE_ERROR 0x00000400 -#define LINK_UP 0x00000200 -#define LINK_DOWN 0x00000100 -#define ARBITRATING 0x00000010 -#define ARB_WON 0x00000020 -#define OPEN 0x00000030 -#define OPENED 0x00000040 -#define TX_CLS 0x00000050 -#define RX_CLS 0x00000060 -#define TRANSFER 0x00000070 -#define INITIALIZING 0x00000080 -#define LOOP_FAIL 0x000000D0 -#define OLD_PORT 0x000000F0 -#define PORT_STATE_ACTIVE 0x0000000F -#define PORT_STATE_OFFLINE 0x00000000 -#define PORT_STATE_LF1 0x00000009 -#define PORT_STATE_LF2 0x0000000A - -/* Completion Message Types - * (defined in P.177 of the Tachyon manual) - */ -#define OUTBOUND_COMPLETION 0x000 -#define OUTBOUND_COMPLETION_I 0x100 -#define OUT_HI_PRI_COMPLETION 0x001 -#define OUT_HI_PRI_COMPLETION_I 0x101 -#define INBOUND_MFS_COMPLETION 0x102 -#define INBOUND_OOO_COMPLETION 0x003 -#define INBOUND_SFS_COMPLETION 0x104 -#define INBOUND_C1_TIMEOUT 0x105 -#define INBOUND_UNKNOWN_FRAME_I 0x106 -#define INBOUND_BUSIED_FRAME 0x006 -#define SFS_BUF_WARN 0x107 -#define MFS_BUF_WARN 0x108 -#define IMQ_BUF_WARN 0x109 -#define FRAME_MGR_INTERRUPT 0x10A -#define READ_STATUS 0x10B -#define INBOUND_SCSI_DATA_COMPLETION 0x10C -#define INBOUND_SCSI_COMMAND 0x10D -#define BAD_SCSI_FRAME 0x10E -#define INB_SCSI_STATUS_COMPLETION 0x10F - -/* One of the things that we care about when we receive an - * Outbound Completion Message (OCM). - */ -#define OCM_TIMEOUT_OR_BAD_ALPA 0x0800 - -/* Defines for the Tachyon Header structure. - */ -#define SOFI3 0x70 -#define SOFN3 0xB0 -#define EOFN 0x5 - -/* R_CTL */ -#define FC4_DEVICE_DATA 0 -#define EXTENDED_LINK_DATA 0x20000000 -#define FC4_LINK_DATA 0x30000000 -#define BASIC_LINK_DATA 0x80000000 -#define LINK_CONTROL 0xC0000000 -#define SOLICITED_DATA 0x1000000 -#define UNSOLICITED_CONTROL 0x2000000 -#define SOLICITED_CONTROL 0x3000000 -#define UNSOLICITED_DATA 0x4000000 -#define DATA_DESCRIPTOR 0x5000000 -#define UNSOLICITED_COMMAND 0x6000000 - -#define RCTL_ELS_UCTL 0x22000000 -#define RCTL_ELS_SCTL 0x23000000 -#define RCTL_BASIC_ABTS 0x81000000 -#define RCTL_BASIC_ACC 0x84000000 -#define RCTL_BASIC_RJT 0x85000000 - -/* TYPE */ -#define TYPE_BLS 0x00000000 -#define TYPE_ELS 0x01000000 -#define TYPE_FC_SERVICES 0x20000000 -#define TYPE_LLC_SNAP 0x05000000 -#define TYPE_FCP 0x08000000 - -/* F_CTL */ -#define EXCHANGE_RESPONDER 0x800000 -#define SEQUENCE_RESPONDER 0x400000 -#define FIRST_SEQUENCE 0x200000 -#define LAST_SEQUENCE 0x100000 -#define SEQUENCE_INITIATIVE 0x10000 -#define RELATIVE_OFF_PRESENT 0x8 -#define END_SEQUENCE 0x80000 - -#define TACHYON_HEADER_LEN 32 -#define NW_HEADER_LEN 16 -/* Defines for the Outbound Descriptor Block (ODB). - */ -#define ODB_CLASS_3 0xC000 -#define ODB_NO_COMP 0x400 -#define ODB_NO_INT 0x200 -#define ODB_EE_CREDIT 0xF - -/* Defines for the Extended Descriptor Block (EDB). - */ -#define EDB_LEN ((32*MY_PAGE_SIZE)/8) -#define EDB_END 0x8000 -#define EDB_FREE 0 -#define EDB_BUSY 1 - -/* Command Codes */ -#define ELS_LS_RJT 0x01000000 -#define ELS_ACC 0x02000000 -#define ELS_PLOGI 0x03000000 -#define ELS_FLOGI 0x04000000 -#define ELS_LOGO 0x05000000 -#define ELS_TPRLO 0x24000000 -#define ELS_ADISC 0x52000000 -#define ELS_PDISC 0x50000000 -#define ELS_PRLI 0x20000000 -#define ELS_PRLO 0x21000000 -#define ELS_SCR 0x62000000 -#define ELS_RSCN 0x61000000 -#define ELS_FARP_REQ 0x54000000 -#define ELS_ABTX 0x06000000 -#define ELS_ADVC 0x0D000000 -#define ELS_ECHO 0x10000000 -#define ELS_ESTC 0x0C000000 -#define ELS_ESTS 0x0B000000 -#define ELS_RCS 0x07000000 -#define ELS_RES 0x08000000 -#define ELS_RLS 0x0F000000 -#define ELS_RRQ 0x12000000 -#define ELS_RSS 0x09000000 -#define ELS_RTV 0x0E000000 -#define ELS_RSI 0x0A000000 -#define ELS_TEST 0x11000000 -#define ELS_RNC 0x53000000 -#define ELS_RVCS 0x41000000 -#define ELS_TPLS 0x23000000 -#define ELS_GAID 0x30000000 -#define ELS_FACT 0x31000000 -#define ELS_FAN 0x60000000 -#define ELS_FDACT 0x32000000 -#define ELS_NACT 0x33000000 -#define ELS_NDACT 0x34000000 -#define ELS_QoSR 0x40000000 -#define ELS_FDISC 0x51000000 - -#define ELS_NS_PLOGI 0x03FFFFFC - -/* LS_RJT reason codes. - */ -#define INV_LS_CMND_CODE 0x0001 -#define LOGICAL_ERR 0x0003 -#define LOGICAL_BUSY 0x0005 -#define PROTOCOL_ERR 0x0007 -#define UNABLE_TO_PERFORM 0x0009 -#define CMND_NOT_SUPP 0x000B - -/* LS_RJT explanation codes. - */ -#define NO_EXPLN 0x0000 -#define RECV_FIELD_SIZE 0x0700 -#define CONC_SEQ 0x0900 -#define REQ_NOT_SUPPORTED 0x2C00 -#define INV_PAYLOAD_LEN 0x2D00 - -/* Payload Length defines. - */ -#define PLOGI_LEN 116 - -#define CONCURRENT_SEQUENCES 0x01 -#define RO_INFO_CATEGORY 0xFE -#define E_D_TOV 0x07D0 /* 2 Secs */ -#define AL_TIME 0x0010 /* ~15 msec */ -#define TOV_VALUES (AL_TIME << 16) | E_D_TOV -#define RT_TOV 0x64 /* 100 msec */ -#define PTP_TOV_VALUES (RT_TOV << 16) | E_D_TOV -#define SERVICE_VALID 0x8000 -#define SEQUENCE_DELIVERY 0x0800 -#define CLASS3_CONCURRENT_SEQUENCE 0x01 -#define CLASS3_OPEN_SEQUENCE 0x01 - -/* These are retrieved from the NOVRAM. - */ -#define WORLD_WIDE_NAME_LOW fi->g.my_port_name_low -#define WORLD_WIDE_NAME_HIGH fi->g.my_port_name_high -#define N_PORT_NAME_HIGH fi->g.my_port_name_high -#define N_PORT_NAME_LOW fi->g.my_port_name_low -#define NODE_NAME_HIGH fi->g.my_node_name_high -#define NODE_NAME_LOW fi->g.my_node_name_low - -#define PORT_NAME_LEN 8 -#define NODE_NAME_LEN 8 - - -#define PH_VERSION 0x0909 - -#define LOOP_BB_CREDIT 0x00 -#define PT2PT_BB_CREDIT 0x01 -#define FLOGI_C_F 0x0800 /* Alternate BB_Credit Mgmnt */ -#define PLOGI_C_F 0x8800 /* Continuously Increasing + Alternate BB_Credit Management */ - -/* Fabric defines */ -#define DIRECTORY_SERVER 0xFFFFFC -#define FABRIC_CONTROLLER 0xFFFFFD -#define F_PORT 0xFFFFFE - -#define FLOGI_DID 0xFFFE -#define NS_PLOGI_DID 0xFFFC - -/* Fibre Channel Services defines */ -#define FCS_RFC_4 0x02170000 -#define FCS_GP_ID4 0x01A10000 -#define FCS_ACC 0x8002 -#define FCS_REJECT 0x8001 - -/* CT Header defines */ -#define FC_CT_REV 0x01000000 -#define DIRECTORY_SERVER_APP 0xFC -#define NAME_SERVICE 0x02 - -/* Port Type defines */ -#define PORT_TYPE_IP 0x05000000 -#define PORT_TYPE_NX_PORTS 0x7F000000 - -/* SCR defines */ -#define FABRIC_DETECTED_REG 0x00000001 -#define N_PORT_DETECTED_REG 0x00000002 -#define FULL_REGISTRATION 0x00000003 -#define CLEAR_REGISTRATION 0x000000FF - -/* Command structure has only one byte to address targets - */ -#define MAX_SCSI_TARGETS 0xFF - -#define FC_SCSI_READ 0x80 -#define FC_SCSI_WRITE 0x81 -#define FC_ELS 0x01 -#define FC_BLS 0x00 -#define FC_IP 0x05 -#define FC_BROADCAST 0xFF - -/* SEST defines. - */ -#define SEST_V 0x80000000 /* V = 1 */ -#define INB_SEST_VED 0xA0000000 /* V = 1, D = 1 */ -#define SEST_INV 0x7FFFFFFF -#define OUTB_SEST_VED 0x80000000 /* V = 1 */ -#define INV_SEQ_LEN 0xFFFFFFFF -#define OUTB_SEST_LINK 0xFFFF - -/* PRLI defines. - */ -#define PAGE_LEN 0x100000 /* 3rd byte - 0x10 */ -#define PRLI_LEN 0x0014 /* 20 bytes */ -#define FCP_TYPE_CODE 0x0800 /* FCP-SCSI */ -#define IMAGE_PAIR 0x2000 /* establish image pair */ -#define INITIATOR_FUNC 0x00000020 -#define TARGET_FUNC 0x00000010 -#define READ_XFER_RDY_DISABLED 0x00000002 - -#define NODE_PROCESS_LOGGED_IN 0x3 -#define NODE_NOT_PRESENT 0x2 -#define NODE_LOGGED_IN 0x1 -#define NODE_LOGGED_OUT 0x0 - -/* Defines to determine what should be returned when a SCSI frame - * times out. - */ -#define FC_SCSI_BAD_TARGET 0xFFFE0000 - -/* RSCN Address formats */ -#define PORT_ADDRESS_FORMAT 0x00 -#define AREA_ADDRESS_FORMAT 0x01 -#define DOMAIN_ADDRESS_FORMAT 0x02 - -/* Defines used to determine whether a frame transmission should - * be indicated by an interrupt or not. - */ -#define NO_COMP_AND_INT 0 -#define INT_AND_COMP_REQ 1 -#define NO_INT_COMP_REQ 2 - -/* Other junk... - */ -#define SDB_FREE 0 -#define SDB_BUSY 1 -#define MAX_PENDING_FRAMES 15 -#define RX_ID_FIRST_SEQUENCE 0xFFFF -#define OX_ID_FIRST_SEQUENCE 0xFFFF -#define NOT_SCSI_XID 0x8000 -#define MAX_SCSI_XID 0x0FFF /* X_IDs are from 0-4095 */ -#define SCSI_READ_BIT 0x4000 -#define MAX_SCSI_OXID 0x4FFF -#define OXID_AVAILABLE 0 -#define OXID_INUSE 1 -#define MAX_SEQ_ID 0xFF - -#define INITIATOR 2 -#define TARGET 1 -#define DELETE_ENTRY 1 -#define ADD_ENTRY 2 - -#endif /* _TACH_H */ ===== drivers/net/fc/tach_structs.h 1.2 vs edited ===== --- 1.2/drivers/net/fc/tach_structs.h 2003-02-25 11:44:51 +01:00 +++ edited/drivers/net/fc/tach_structs.h 2004-09-06 11:54:19 +02:00 @@ -1,428 +0,0 @@ -/********************************************************************** - * iph5526.c: Structures for the Interphase 5526 PCI Fibre Channel - * IP/SCSI driver. - * Copyright (C) 1999 Vineet M Abraham - **********************************************************************/ - -#ifndef _TACH_STRUCT_H -#define _TACH_STRUCT_H - -typedef struct { - u_short cmnd_code; - u_short payload_length; - u_short type_code; - u_short est_image_pair; - u_int originator_pa; - u_int responder_pa; - u_int service_params; -} PRLI; - -typedef struct { - u_int flags_and_byte_offset; - u_int byte_count; - u_short no_of_recvd_frames; - u_short no_of_expected_frames; - u_int last_fctl; - u_int sdb_address; - u_int scratch_pad; - u_int expected_ro; - u_short buffer_index; - u_short buffer_offset; - } INB_SEST_ENTRY; - -typedef struct { - u_int flags_and_did; - u_short max_frame_len; - u_short cntl; - u_int total_seq_length; - u_short link; - u_short rx_id; - u_int transaction_id; - u_int header_address; - u_char seq_id; - u_char reserved; - u_short header_length; - u_int edb_address; - } OUTB_SEST_ENTRY; - -typedef struct { - u_short d_naa; - u_short dest_high; - u_int dest_low; - u_short s_naa; - u_short source_high; - u_int source_low; - } NW_HEADER; - -typedef struct { - u_int resv; - u_char sof_and_eof; - u_char dest_alpa; - u_short lcr_and_time_stamp; - u_int r_ctl_and_d_id; - u_int vc_id_and_s_id; - u_int type_and_f_cntl; - u_char seq_id; - u_char df_cntl; - u_short seq_cnt; - u_short ox_id; - u_short rx_id; - u_int ro; - NW_HEADER nw_header; - } TACHYON_HEADER; - -typedef struct { - u_short service_options; - u_short initiator_ctl; - u_short recipient_ctl; - u_short recv_data_field_size; - u_short concurrent_sequences; - u_short n_port_end_to_end_credit; - u_short open_seq_per_exchange; - u_short resv; - }CLASS_OF_SERVICE; - -typedef struct { - u_int logo_cmnd; - u_char reserved; - u_char n_port_id_2; - u_char n_port_id_1; - u_char n_port_id_0; - u_int port_name_up; - u_int port_name_low; - } LOGO; - -typedef struct { - u_int ls_cmnd_code; - u_int hard_address; - u_int port_name_high; - u_int port_name_low; - u_int node_name_high; - u_int node_name_low; - u_int n_port_id; - } ADISC; - -typedef struct { - u_int cmnd_code; - u_int reason_code; - } LS_RJT; - -typedef struct { - u_int cmnd_code; - } ACC; - -typedef struct { - u_int seq_d_id; - u_int tot_len; - u_short cntl; - u_short rx_id; - u_short cs_enable; - u_short cs_seed; - u_int trans_id; - u_int hdr_addr; - u_short frame_len; - u_short hdr_len; - u_int edb_addr; - }ODB; - -typedef struct { - u_int cmnd_code; - u_int reg_function; /* in the last byte */ - } SCR; - -typedef struct { - u_int rev_in_id; - u_char fs_type; - u_char fs_subtype; - u_char options; - u_char resv1; - u_short cmnd_resp_code; - u_short max_res_size; - u_char resv2; - u_char reason_code; - u_char expln_code; - u_char vendor_unique; - } CT_HDR; - -typedef struct { - CT_HDR ct_hdr; - u_int s_id; - u_char bit_map[32]; /* 32 byte bit map */ - } RFC_4; - -typedef struct { - u_int ls_cmnd_code; - u_short fc_ph_version; - u_short buff_to_buff_credit; - u_short common_features; - u_short recv_data_field_size; - u_short n_port_total_conc_seq; - u_short rel_off_by_info_cat; - u_int ED_TOV; - u_int n_port_name_high; - u_int n_port_name_low; - u_int node_name_high; - u_int node_name_low; - CLASS_OF_SERVICE c_of_s[3]; - u_int resv[4]; - u_int vendor_version_level[4]; - }LOGIN; - -typedef struct { - CT_HDR ct_hdr; - u_int port_type; /* in the first byte */ - } GP_ID4; - -typedef struct { - u_int buf_addr; - u_short ehf; - u_short buf_len; - }EDB; - -/* (i)chip Registers */ -struct i_chip_regs { - u_int ptr_ichip_hw_control_reg; - u_int ptr_ichip_hw_status_reg; - u_int ptr_ichip_hw_addr_mask_reg; -}; - -struct iph5526_novram { - u_int ptr_novram_hw_control_reg; - u_int ptr_novram_hw_status_reg; - u_short data[IPH5526_NOVRAM_SIZE]; -}; - -/* Tachyon Registers */ -struct tachyon_regs { - u_int ptr_ocq_base_reg; - u_int ptr_ocq_len_reg; - u_int ptr_ocq_prod_indx_reg; - u_int ptr_ocq_cons_indx_reg; - - u_int ptr_imq_base_reg; - u_int ptr_imq_len_reg; - u_int ptr_imq_cons_indx_reg; - u_int ptr_imq_prod_indx_reg; - - u_int ptr_mfsbq_base_reg; - u_int ptr_mfsbq_len_reg; - u_int ptr_mfsbq_prod_reg; - u_int ptr_mfsbq_cons_reg; - u_int ptr_mfsbuff_len_reg; - - u_int ptr_sfsbq_base_reg; - u_int ptr_sfsbq_len_reg; - u_int ptr_sfsbq_prod_reg; - u_int ptr_sfsbq_cons_reg; - u_int ptr_sfsbuff_len_reg; - - u_int ptr_sest_base_reg; - u_int ptr_sest_len_reg; - u_int ptr_scsibuff_len_reg; - - u_int ptr_tach_config_reg; - u_int ptr_tach_control_reg; - u_int ptr_tach_status_reg; - u_int ptr_tach_flush_oxid_reg; - - u_int ptr_fm_config_reg; - u_int ptr_fm_control_reg; - u_int ptr_fm_status_reg; - u_int ptr_fm_tov_reg; - u_int ptr_fm_wwn_hi_reg; - u_int ptr_fm_wwn_low_reg; - u_int ptr_fm_rx_al_pa_reg; -}; - -struct globals { - u_long tachyon_base; - u_int *mem_base; - u_short ox_id; /* OX_ID used for IP and ELS frames */ - u_short scsi_oxid; /* OX_ID for SEST entry */ - u_char seq_id; - u_int my_id; - u_int my_ddaa; /* my domain and area in a fabric */ - volatile u_char loop_up; - volatile u_char ptp_up; /* we have a point-to-point link */ - volatile u_char link_up; - volatile u_char n_port_try; - volatile u_char nport_timer_set; - volatile u_char lport_timer_set; - /* Hmmm... We don't want to Initialize while closing */ - u_char dont_init; - u_int my_node_name_high; - u_int my_node_name_low; - u_int my_port_name_high; - u_int my_port_name_low; - u_char fabric_present; - u_char explore_fabric; - u_char name_server; - u_int my_mtu; - u_int *els_buffer[MAX_PENDING_FRAMES]; /* temp space for ELS frames */ - char *arp_buffer; /* temp space for ARP frames */ - u_int mfs_buffer_count; /* keep track of MFS buffers used*/ - u_char scsi_registered; - /* variables for port discovery */ - volatile u_char port_discovery; - volatile u_char perform_adisc; - u_short alpa_list_index; - u_short type_of_frame; /* Could be IP/SCSI Read/SCSI Write*/ - u_char no_of_targets; /* used to assign target_ids */ - u_long sem; /* to synchronize between IP and SCSI */ - u_char e_i; - - /* the frames */ - TACHYON_HEADER tach_header; - LOGIN login; - PRLI prli; - LOGO logo; - ADISC adisc; - LS_RJT ls_rjt; - ODB odb; - INB_SEST_ENTRY inb_sest_entry; - OUTB_SEST_ENTRY outb_sest_entry; - ACC acc; - SCR scr; - EDB edb; - RFC_4 rfc_4; - GP_ID4 gp_id4; -}; - -struct queue_variables { - /* Indices maintained in host memory. - */ - u_int *host_ocq_cons_indx, *host_hpcq_cons_indx, *host_imq_prod_indx; - u_int *ptr_host_ocq_cons_indx, *ptr_host_hpcq_cons_indx, *ptr_host_imq_prod_indx; - - /* Variables for Outbound Command Queue (OCQ). - */ - u_int *ptr_ocq_base; - u_int ocq_len, ocq_end; - u_int ocq_prod_indx; - u_int *ptr_odb[OCQ_LENGTH]; - - /* Variables for Inbound Message Queue (IMQ). - */ - u_int *ptr_imq_base; - u_int imq_len, imq_end; - u_int imq_cons_indx; - u_int imq_prod_indx; - u_int *ptr_imqe[IMQ_LENGTH]; - - u_int *ptr_mfsbq_base; - u_int mfsbq_len, mfsbq_end; - u_int mfsbq_prod_indx; - u_int mfsbq_cons_indx; - u_int mfsbuff_len, mfsbuff_end; - - u_int *ptr_sfsbq_base; - u_int sfsbq_len, sfsbq_end; - u_int sfsbq_prod_indx; - u_int sfsbq_cons_indx; - u_int sfsbuff_len, sfsbuff_end; - u_int *ptr_sfs_buffers[SFSBQ_LENGTH * NO_OF_ENTRIES]; - - /* Tables for SCSI Transactions */ - u_int *ptr_sest_base; - u_int *ptr_sest[SEST_LENGTH]; - u_char free_scsi_oxid[SEST_LENGTH]; - u_int *ptr_sdb_base; - u_int *ptr_sdb_slot[NO_OF_SDB_ENTRIES]; - u_char sdb_slot_status[NO_OF_SDB_ENTRIES]; - u_int sdb_indx; - u_int *ptr_fcp_cmnd_base; - u_int *ptr_fcp_cmnd[NO_OF_FCP_CMNDS]; - u_int fcp_cmnd_indx; - - /* Table for data to be transmitted. - */ - u_int *ptr_edb_base; - u_int *ptr_edb[EDB_LEN]; - u_int edb_buffer_indx; - volatile u_char free_edb_list[EDB_LEN]; - - /* Table of Tachyon Headers. - */ - u_int *ptr_tachyon_header[NO_OF_TACH_HEADERS]; - u_int *ptr_tachyon_header_base; - u_int tachyon_header_indx; -}; - -/* Used to match incoming ACCs to ELS requests sent out */ -struct ox_id_els_map { - u_short ox_id; - u_int els; - struct ox_id_els_map *next; -}; - - -/* Carries info about individual nodes... stores the info got at login - * time. Also maintains mapping between MAC->FC addresses - */ -struct fc_node_info { - /* Itz the WWN (8 bytes), the last 6 bytes is the MAC address */ - u_char hw_addr[PORT_NAME_LEN]; - u_char node_name[NODE_NAME_LEN]; - u_int d_id; /*real FC address, 3 bytes */ - int mtu; - /* login = 1 if login attempted - * login = 2 if login completed - */ - int login; - u_char scsi; /* = 1 if device is a SCSI Target */ - u_char target_id; - CLASS_OF_SERVICE c_of_s[3]; - struct fc_node_info *next; -}; - -struct fc_info { - char name[8]; - u_long base_addr; - int irq; - struct net_device_stats fc_stats; - struct fc_node_info *node_info_list; - int num_nodes; - struct ox_id_els_map *ox_id_list; - struct i_chip_regs i_r; - struct tachyon_regs t_r; - struct queue_variables q; - struct globals g; - struct iph5526_novram n_r; - u_short clone_id; - struct timer_list nport_timer; - struct timer_list lport_timer; - struct timer_list explore_timer; - struct timer_list display_cache_timer; - struct net_device *dev; - struct Scsi_Host *host; - spinlock_t fc_lock; -}; - -struct iph5526_hostdata { - struct fc_info *fi; - fcp_cmd cmnd; - Scsi_Cmnd *cmnd_handler[SEST_LENGTH]; - u_int tag_ages[MAX_SCSI_TARGETS]; -}; - -/* List of valid AL_PAs */ -u_char alpa_list[127] = { - 0x00, 0x01, 0x02, 0x04, 0x08, 0x0F, 0x10, 0x17, - 0x18, 0x1B, 0x1D, 0x1E, 0x1F, 0x23, 0x25, 0x26, - 0x27, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x31, - 0x32, 0x33, 0x34, 0x35, 0x36, 0x39, 0x3A, 0x3C, - 0x43, 0x45, 0x46, 0x47, 0x49, 0x4A, 0x4B, 0x4C, - 0x4D, 0x4E, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, - 0x59, 0x5A, 0x5C, 0x63, 0x65, 0x66, 0x67, 0x69, - 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x71, 0x72, 0x73, - 0x74, 0x75, 0x76, 0x79, 0x7A, 0x7C, 0x80, 0x81, - 0x82, 0x84, 0x88, 0x8F, 0x90, 0x97, 0x98, 0x9B, - 0x9D, 0x9E, 0x9F, 0xA3, 0xA5, 0xA6, 0xA7, 0xA9, - 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xB1, 0xB2, 0xB3, - 0xB4, 0xB5, 0xB6, 0xB9, 0xBA, 0xBC, 0xC3, 0xC5, - 0xC6, 0xC7, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, - 0xD1, 0xD2, 0xD3, 0xD4, 0xD5, 0xD6, 0xD9, 0xDA, - 0xDC, 0xE0, 0xE1, 0xE2, 0xE4, 0xE8, 0xEF -}; - -#endif /* _TACH_STRUCT_H */ From jchapman@katalix.com Mon Sep 6 04:57:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 04:57:53 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86Bvdlv019007 for ; Mon, 6 Sep 2004 04:57:40 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1C4I65-0000bl-4V; Mon, 06 Sep 2004 06:55:45 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Mon, 6 Sep 2004 12:55:44 +0100 Message-ID: <1094471744.413c5040e7f06@www.katalix.com> Date: Mon, 6 Sep 2004 12:55:44 +0100 From: James Chapman To: netdev@oss.sgi.com Cc: Martijn van Oosterhout Subject: PPP-over-L2TP kernel support, patch for review MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 8439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 717 Lines: 19 Attached is a PPP-over-L2TP driver for review. The patch is against vanilla 2.6.8.1. It was originally developed for 2.4 and forward- ported to 2.6 so please look for typical 2.4-to-2.6 porting bugs. The original version of this driver was written by Martijn van Oosterhout, distributed as kl2tp-0.2 last year. Note that this code handles only the datapath of L2TP; a userland daemon runs the L2TP control protocol, setting up tunnels and sessions with its peers. OpenL2TP is a recently released L2TP client/server written specifically for Linux and includes this driver in its distribution, http://openl2tp.sourceforge.net. I'm working towards having this driver integrated into the kernel tree. Comments? /jc From jchapman@katalix.com Mon Sep 6 05:01:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 05:01:11 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86C15DS019359 for ; Mon, 6 Sep 2004 05:01:06 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1C4I9V-0000vB-02; Mon, 06 Sep 2004 06:59:17 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Mon, 6 Sep 2004 12:59:16 +0100 Message-ID: <1094471956.413c5114de2d7@www.katalix.com> Date: Mon, 6 Sep 2004 12:59:16 +0100 From: James Chapman To: netdev@oss.sgi.com Cc: Martijn van Oosterhout Subject: PPP-over-L2TP kernel support, patch for review MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ10944719560baa5174fac6e4ed97ac1aeaf3061f31" User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 8440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 97057 Lines: 1279 This message is in MIME format. ---MOQ10944719560baa5174fac6e4ed97ac1aeaf3061f31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Attached this time... sorry. Attached is a PPP-over-L2TP driver for review. The patch is against vanilla 2.6.8.1. It was originally developed for 2.4 and forward- ported to 2.6 so please look for typical 2.4-to-2.6 porting bugs. The original version of this driver was written by Martijn van Oosterhout, distributed as kl2tp-0.2 last year. Note that this code handles only the datapath of L2TP; a userland daemon runs the L2TP control protocol, setting up tunnels and sessions with its peers. OpenL2TP is a recently released L2TP client/server written specifically for Linux and includes this driver in its distribution, http://openl2tp.sourceforge.net. I'm working towards having this driver integrated into the kernel tree. Comments? /jc ---MOQ10944719560baa5174fac6e4ed97ac1aeaf3061f31 Content-Type: application/octet-stream; name="pppol2tp-linux-2.6.8.1.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pppol2tp-linux-2.6.8.1.patch" ZGlmZiAtTmF1ciBsaW51eC0yLjYuOC4xLm9yaWcvZHJpdmVycy9uZXQvS2NvbmZpZyBsaW51eC0y LjYuOC4xL2RyaXZlcnMvbmV0L0tjb25maWcKLS0tIGxpbnV4LTIuNi44LjEub3JpZy9kcml2ZXJz L25ldC9LY29uZmlnCTIwMDQtMDgtMTQgMTE6NTY6MDAuMDAwMDAwMDAwICswMTAwCisrKyBsaW51 eC0yLjYuOC4xL2RyaXZlcnMvbmV0L0tjb25maWcJMjAwNC0wOS0wNCAwMTowMjowMC4wMDAwMDAw MDAgKzAxMDAKQEAgLTI0ODEsNiArMjQ4MSwxOSBAQAogCSAgd2hpY2ggY2FuIGxlYWQgdG8gYmFk IHJlc3VsdHMgaWYgdGhlIEFUTSBwZWVyIGxvc2VzIHN0YXRlIGFuZAogCSAgY2hhbmdlcyBpdHMg ZW5jYXBzdWxhdGlvbiB1bmlsYXRlcmFsbHkuCiAKK2NvbmZpZyBQUFBPTDJUUAorCXRyaXN0YXRl ICJQUFAgb3ZlciBMMlRQIChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gRVhQRVJJTUVOVEFM ICYmIFBQUE9FCisJaGVscAorCSAgU3VwcG9ydCBmb3IgUFBQLW92ZXItTDJUUCBzb2NrZXQgZmFt aWx5LiBMMlRQIGlzIGEgcHJvdG9jb2wKKwkgIHVzZWQgYnkgSVNQcyBhbmQgZW50ZXJwcmlzZXMg dG8gdHVubmVsIFBQUCB0cmFmZmljIG92ZXIgVURQCisJICB0dW5uZWxzLiBMMlRQIGlzIHJlcGxh Y2luZyBQUFRQIGZvciBWUE4gdXNlcy4KKworCSAgVGhpcyBrZXJuZWwgY29tcG9uZW50IGhhbmRs ZXMgb25seSBMMlRQIGRhdGEgcGFja2V0czogYQorCSAgdXNlcmxhbmQgZGFlbW9uIGhhbmRsZXMg TDJUUCB0aGUgY29udHJvbCBwcm90b2NvbCAodHVubmVsCisJICBhbmQgc2Vzc2lvbiBzZXR1cCku IE9uZSBzdWNoIGRhZW1vbiBpcyBPcGVuTDJUUAorCSAgKGh0dHA6Ly9vcGVubDJ0cC5zb3VyY2Vm b3JnZS5uZXQvKS4KKwogY29uZmlnIFNMSVAKIAl0cmlzdGF0ZSAiU0xJUCAoc2VyaWFsIGxpbmUp IHN1cHBvcnQiCiAJZGVwZW5kcyBvbiBORVRERVZJQ0VTCmRpZmYgLU5hdXIgbGludXgtMi42Ljgu MS5vcmlnL2RyaXZlcnMvbmV0L01ha2VmaWxlIGxpbnV4LTIuNi44LjEvZHJpdmVycy9uZXQvTWFr ZWZpbGUKLS0tIGxpbnV4LTIuNi44LjEub3JpZy9kcml2ZXJzL25ldC9NYWtlZmlsZQkyMDA0LTA4 LTE0IDExOjU1OjA5LjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9kcml2ZXJzL25l dC9NYWtlZmlsZQkyMDA0LTA5LTAxIDE3OjU3OjA3LjAwMDAwMDAwMCArMDEwMApAQCAtMTAxLDYg KzEwMSw3IEBACiBvYmotJChDT05GSUdfUFBQX0RFRkxBVEUpICs9IHBwcF9kZWZsYXRlLm8KIG9i ai0kKENPTkZJR19QUFBfQlNEQ09NUCkgKz0gYnNkX2NvbXAubwogb2JqLSQoQ09ORklHX1BQUE9F KSArPSBwcHBveC5vIHBwcG9lLm8KK29iai0kKENPTkZJR19QUFBPTDJUUCkgKz0gcHBwb3gubyBw cHBvbDJ0cC5vCiAKIG9iai0kKENPTkZJR19TTElQKSArPSBzbGlwLm8KIGlmZXEgKCQoQ09ORklH X1NMSVBfQ09NUFJFU1NFRCkseSkKZGlmZiAtTmF1ciBsaW51eC0yLjYuOC4xLm9yaWcvZHJpdmVy cy9uZXQvcHBwb2wydHAuYyBsaW51eC0yLjYuOC4xL2RyaXZlcnMvbmV0L3BwcG9sMnRwLmMKLS0t IGxpbnV4LTIuNi44LjEub3JpZy9kcml2ZXJzL25ldC9wcHBvbDJ0cC5jCTE5NzAtMDEtMDEgMDE6 MDA6MDAuMDAwMDAwMDAwICswMTAwCisrKyBsaW51eC0yLjYuOC4xL2RyaXZlcnMvbmV0L3BwcG9s MnRwLmMJMjAwNC0wOS0wNCAwMTowMDoyMy4wMDAwMDAwMDAgKzAxMDAKQEAgLTAsMCArMSwyMzU5 IEBACisvKiogLSotIGxpbnV4LWMgLSotICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBMaW51eCBQUFAgb3ZlciBMMlRQIChQUFBv WC9QUFBvTDJUUCkgU29ja2V0cworICoKKyAqIFBQUG9YICAgIC0tLSBHZW5lcmljIFBQUCBlbmNh cHN1bGF0aW9uIHNvY2tldCBmYW1pbHkKKyAqIFBQUG9MMlRQIC0tLSBQUFAgb3ZlciBMMlRQIChS RkMgMjY2MSkKKyAqCisgKgorICogVmVyc2lvbjogICAgMC4zLjAKKyAqCisgKiAyNTEwMDMgOglD b3BpZWQgZnJvbSBwcHBvZS5jIHZlcnNpb24gMC42LjkuCisgKgorICogQXV0aG9yOglNYXJ0aWpu IHZhbiBPb3N0ZXJob3V0IDxrbGVwdG9nQHN2YW5hLm9yZz4KKyAqIENvbnRyaWJ1dG9yczoKKyAq CQlNaWNoYWwgT3N0cm93c2tpIDxtb3N0cm93c0BzcGVha2Vhc3kubmV0PgorICoJCUFybmFsZG8g Q2FydmFsaG8gZGUgTWVsbyA8YWNtZUB4Y29uZWN0aXZhLmNvbS5icj4KKyAqCQlEYXZpZCBTLiBN aWxsZXIgKGRhdmVtQHJlZGhhdC5jb20pCisgKgkJSmFtZXMgQ2hhcG1hbiAoamNoYXBtYW5Aa2F0 YWxpeC5jb20pCisgKgorICogTGljZW5zZToKKyAqCQlUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0 d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKgkJbW9kaWZ5IGl0IHVuZGVy IHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqCQlhcyBwdWJs aXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24KKyAq CQkyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u LgorICoKKyAqLworCisvKiBUaGlzIGRyaXZlciBoYW5kbGVzIG9ubHkgTDJUUCBkYXRhIGZyYW1l czsgY29udHJvbCBmcmFtZXMgYXJlIGhhbmRsZWQgYnkgYQorICogdXNlcnNwYWNlIGFwcGxpY2F0 aW9uLgorICoKKyAqIFRvIHNlbmQgZGF0YSBpbiBhbiBMMlRQIHNlc3Npb24sIHVzZXJzcGFjZSBv cGVucyBhIFBQUG9MMlRQIHNvY2tldCBhbmQKKyAqIGF0dGFjaGVzIGl0IHRvIGEgYm91bmQgVURQ IHNvY2tldCB3aXRoIGxvY2FsIHR1bm5lbF9pZCAvIHNlc3Npb25faWQgYW5kCisgKiBwZWVyIHR1 bm5lbF9pZCAvIHNlc3Npb25faWQgc2V0LiBEYXRhIGNhbiB0aGVuIGJlIHNlbnQgb3IgcmVjZWl2 ZWQgdXNpbmcKKyAqIHJlZ3VsYXIgc29ja2V0IHNlbmRtc2coKSAvIHJlY3Ztc2coKSBjYWxscy4g S2VybmVsIHBhcmFtZXRlcnMgb2YgdGhlIHNvY2tldAorICogY2FuIGJlIHJlYWQgb3IgbW9kaWZp ZWQgdXNpbmcgaW9jdGwoKSBvciBbZ3NdZXRzb2Nrb3B0KCkgY2FsbHMuCisgKgorICogV2hlbiBh IFBQUG9MMlRQIHNvY2tldCBpcyBjb25uZWN0ZWQgd2l0aCBsb2NhbCBhbmQgcGVlciBzZXNzaW9u X2lkIHZhbHVlcworICogemVybywgdGhlIHNvY2tldCBpcyB0cmVhdGVkIGFzIGEgc3BlY2lhbCB0 dW5uZWwgbWFuYWdlbWVudCBzb2NrZXQuCisgKgorICogSGVyZSdzIGV4YW1wbGUgdXNlcnNwYWNl IGNvZGUgdG8gY3JlYXRlIGEgc29ja2V0IGZvciBzZW5kaW5nL3JlY2VpdmluZyBkYXRhCisgKiBv dmVyIGFuIEwyVFAgc2Vzc2lvbjotCisgKgorICoJc3RydWN0IHNvY2thZGRyX3BwcG94IHNheDsK KyAqCWludCBmZDsKKyAqCWludCBzZXNzaW9uX2ZkOworICoJCisgKglmZCA9IHNvY2tldChBRl9Q UFBPWCwgU09DS19ER1JBTSwgUFhfUFJPVE9fT0wyVFApOworICoKKyAqCXNheC5zYV9mYW1pbHkg PSBBRl9QUFBPWDsKKyAqCXNheC5zYV9wcm90b2NvbCA9IFBYX1BST1RPX09MMlRQOworICoJc2F4 LnNhX2FkZHIucHBwb2wydHAuZmQgPSB0dW5uZWxfZmQ7IC8vIGJvdW5kIFVEUCBzb2NrZXQKKyAq CXNheC5zYV9hZGRyLnBwcG9sMnRwLmFkZHIuc2luX2FkZHIuc19hZGRyID0gYWRkci0+c2luX2Fk ZHIuc19hZGRyOworICoJc2F4LnNhX2FkZHIucHBwb2wydHAuYWRkci5zaW5fcG9ydCA9IGFkZHIt PnNpbl9wb3J0OworICoJc2F4LnNhX2FkZHIucHBwb2wydHAuYWRkci5zaW5fZmFtaWx5ID0gQUZf SU5FVDsKKyAqCXNheC5zYV9hZGRyLnBwcG9sMnRwLnNfdHVubmVsICA9IHR1bm5lbF9pZDsKKyAq CXNheC5zYV9hZGRyLnBwcG9sMnRwLnNfc2Vzc2lvbiA9IHNlc3Npb25faWQ7CisgKglzYXguc2Ff YWRkci5wcHBvbDJ0cC5kX3R1bm5lbCAgPSBwZWVyX3R1bm5lbF9pZDsKKyAqCXNheC5zYV9hZGRy LnBwcG9sMnRwLmRfc2Vzc2lvbiA9IHBlZXJfc2Vzc2lvbl9pZDsKKyAqICAKKyAqCXNlc3Npb25f ZmQgPSBjb25uZWN0KGZkLCAoc3RydWN0IHNvY2thZGRyICopJnNheCwgc2l6ZW9mKHNheCkpOwor ICoKKyAqLworCisjaW5jbHVkZSA8bGludXgvc3RyaW5nLmg+CisjaW5jbHVkZSA8bGludXgvbW9k dWxlLmg+CisjaW5jbHVkZSA8bGludXgvdmVyc2lvbi5oPgorCisjaW5jbHVkZSA8YXNtL3VhY2Nl c3MuaD4KKworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L3NjaGVk Lmg+CisjaW5jbHVkZSA8bGludXgvc2xhYi5oPgorI2luY2x1ZGUgPGxpbnV4L2Vycm5vLmg+CisK KyNpbmNsdWRlIDxsaW51eC9uZXRkZXZpY2UuaD4KKyNpbmNsdWRlIDxsaW51eC9uZXQuaD4KKyNp bmNsdWRlIDxsaW51eC9pbmV0ZGV2aWNlLmg+CisjaW5jbHVkZSA8bGludXgvc2tidWZmLmg+Cisj aW5jbHVkZSA8bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxpbnV4L3VkcC5oPgorI2luY2x1ZGUg PGxpbnV4L2lmX3BwcG94Lmg+CisjaW5jbHVkZSA8bmV0L3NvY2suaD4KKyNpbmNsdWRlIDxsaW51 eC9wcHBfY2hhbm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L3BwcF9kZWZzLmg+CisjaW5jbHVkZSA8 bGludXgvaWZfcHBwLmg+CisjaW5jbHVkZSA8bGludXgvZmlsZS5oPgorI2luY2x1ZGUgPGxpbnV4 L3Byb2NfZnMuaD4KKworI2luY2x1ZGUgPGFzbS9ieXRlb3JkZXIuaD4KKyNpbmNsdWRlIDxhc20v YXRvbWljLmg+CisKKyNkZWZpbmUgUFBQT0wyVFBfRFJWX1ZFUlNJT04JIlYwLjMiCisKKy8qIERl dmVsb3BlciBkZWJ1ZyBjb2RlLiAqLworI2lmIDAKKyNkZWZpbmUgREVCVUcJLyogRGVmaW5lIHRv IGNvbXBpbGUgaW4gdmVyeSB2ZXJib3NlIGRldmVsb3BlciBkZWJ1ZyAqLworI2VuZGlmCisKKy8q IFRpbWVvdXRzIGFyZSBzcGVjaWZpZWQgaW4gbWlsbGlzZWNvbmRzIHRvL2Zyb20gdXNlcnNwYWNl ICovCisjZGVmaW5lIEpJRkZJRVNfVE9fTVModCkgKCh0KSAqIDEwMDAgLyBIWikKKyNkZWZpbmUg TVNfVE9fSklGRklFUyhqKSAoKGogKiBIWikgLyAxMDAwKQorCisvKiBMMlRQIGhlYWRlciBjb25z dGFudHMgKi8KKyNkZWZpbmUgTDJUUF9IRFJGTEFHX1QJICAgMHg4MDAwCisjZGVmaW5lIEwyVFBf SERSRkxBR19MCSAgIDB4NDAwMAorI2RlZmluZSBMMlRQX0hEUkZMQUdfUwkgICAweDA4MDAKKyNk ZWZpbmUgTDJUUF9IRFJGTEFHX08JICAgMHgwMjAwCisjZGVmaW5lIEwyVFBfSERSRkxBR19QCSAg IDB4MDEwMAorCisjZGVmaW5lIEwyVFBfSERSX1ZFUl9NQVNLICAweDAwMEYKKyNkZWZpbmUgTDJU UF9IRFJfVkVSCSAgIDB4MDAwMgorCisvKiBTcGFjZSBmb3IgVURQLCBMMlRQIGFuZCBQUFAgaGVh ZGVycywgcGx1cyBzb21lIHNsYWNrICovCisjZGVmaW5lIFBQUE9MMlRQX0hFQURFUl9PVkVSSEVB RAk0MAorCisvKiBKdXN0IHNvbWUgcmFuZG9tIG51bWJlcnMgKi8KKyNkZWZpbmUgTDJUUF9UVU5O RUxfTUFHSUMgICAweDQyMTE0RERBCisjZGVmaW5lIEwyVFBfU0VTU0lPTl9NQUdJQyAgMHgwQzA0 RUI3RAorCisjZGVmaW5lIFBQUE9MMlRQX0hBU0hfQklUUyA0CisjZGVmaW5lIFBQUE9MMlRQX0hB U0hfU0laRSAoMTw8UFBQT0wyVFBfSEFTSF9CSVRTKQorCisvKiBEZWZhdWx0IHRyYWNlIGZsYWdz ICovCisjaWZkZWYgREVCVUcKKyNkZWZpbmUgUFBQT0wyVFBfREVGQVVMVF9ERUJVR19GTEFHUwkt MQorI2Vsc2UKKyNkZWZpbmUgUFBQT0wyVFBfREVGQVVMVF9ERUJVR19GTEFHUwkwCisjZW5kaWYK KworCisvKiBEZWJ1ZyBrZXJuZWwgbWVzc2FnZSBjb250cm9sLgorICogVmVyYm9zZSBkZWJ1ZyBt ZXNzYWdlcyAoTDJUUF9NU0dfREVCVUcgZmxhZykgYXJlIG9wdGlvbmFsbHkgY29tcGlsZWQgaW4u CisgKi8KKyNpZmRlZiBERUJVRworI2RlZmluZSBEUFJJTlRLKF9tYXNrLCBfZm10LCBhcmdzLi4u KQkJCQkJXAorCWRvIHsJCQkJCQkJCVwKKwkJaWYgKChfbWFzaykgJiBQUFBPTDJUUF9NU0dfREVC VUcpCQkJXAorCQkJcHJpbnRrKEtFUk5fREVCVUcgIlBQUE9MMlRQICVzOiAiIF9mbXQsCQlcCisJ CQkgICAgICAgX19GVU5DVElPTl9fLCAjI2FyZ3MpOwkJCVwKKwl9IHdoaWxlKDApCisjZWxzZQor I2RlZmluZSBEUFJJTlRLKF9tYXNrLCBzcmdzLi4uKSBkbyB7IH0gd2hpbGUoMCkKKyNlbmRpZiAv KiBERUJVRyAqLworCisjZGVmaW5lIFBSSU5USyhfbWFzaywgX3R5cGUsIF9sdmwsIF9mbXQsIGFy Z3MuLi4pCQkJXAorCWRvIHsJCQkJCQkJCVwKKwkJaWYgKChfbWFzaykgJiAoX3R5cGUpKQkJCQkJ XAorCQkJcHJpbnRrKF9sdmwgIlBQUE9MMlRQOiAiIF9mbXQsICMjYXJncyk7CQlcCisJfSB3aGls ZSgwKQorCisvKiBFeHRyYSBkcml2ZXIgZGVidWcuIFNob3VsZCBvbmx5IGJlIGVuYWJsZWQgYnkg ZGV2ZWxvcGVycyB3b3JraW5nIG9uCisgKiB0aGlzIGRyaXZlci4gCisgKi8KKyNpZmRlZiBERUJV RworI2RlZmluZSBFTlRFUl9GVU5DVElPTgkgcHJpbnRrKEtFUk5fREVCVUcgIlBQUE9MMlRQOiAt LT4gJXNcbiIsIF9fRlVOQ1RJT05fXykKKyNkZWZpbmUgRVhJVF9GVU5DVElPTgkgcHJpbnRrKEtF Uk5fREVCVUcgIlBQUE9MMlRQOiA8LS0gJXNcbiIsIF9fRlVOQ1RJT05fXykKKyNlbHNlCisjZGVm aW5lIEVOVEVSX0ZVTkNUSU9OCSBkbyB7IH0gd2hpbGUoMCkKKyNkZWZpbmUgRVhJVF9GVU5DVElP TgkgZG8geyB9IHdoaWxlKDApCisjZW5kaWYKKworc3RydWN0IHBwcG9sMnRwX3R1bm5lbDsKKwor LyogRGVzY3JpYmVzIGEgc2Vzc2lvbi4gSXQgaXMgdGhlIHNrX3VzZXJfZGF0YSBmaWVsZCBpbiB0 aGUgUFBQb0wyVFAKKyAqIHNvY2tldC4gQ29udGFpbnMgaW5mb3JtYXRpb24gdG8gZGV0ZXJtaW5l IGluY29taW5nIHBhY2tldHMgYW5kIHRyYW5zbWl0CisgKiBvdXRnb2luZyBvbmVzLgorICovCitz dHJ1Y3QgcHBwb2wydHBfc2Vzc2lvbgoreworCWludAkJCW1hZ2ljOwkJLyogc2hvdWxkIGJlIEwy VFBfU0VTU0lPTl9NQUdJQyAqLworCWludAkJCW93bmVyOwkJLyogcGlkIHRoYXQgb3BlbmVkIHRo ZSBzb2NrZXQgKi8KKwkKKwlzdHJ1Y3Qgc29jawkJKnNvY2s7CQkvKiBQb2ludGVyIHRvIHRoZSBz ZXNzaW9uCisJCQkJCQkgKiBQUFBvWCBzb2NrZXQgKi8KKwlzdHJ1Y3Qgc29jawkJKnR1bm5lbF9z b2NrOwkvKiBQb2ludGVyIHRvIHRoZSB0dW5uZWwgVURQIAorCQkJCQkJICogc29ja2V0ICovCisJ CisJc3RydWN0IHBwcG9sMnRwX2FkZHIJdHVubmVsX2FkZHI7CS8qIERlc2NyaXB0aW9uIG9mIHR1 bm5lbCAqLworCisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbAkqdHVubmVsOwkvKiBiYWNrIHBvaW50 ZXIgdG8gdHVubmVsIGNvbnRleHQgKi8KKwkKKwljaGFyCQkJbmFtZVsyMF07CS8qICJzZXNzIHh4 eHh4L3l5eXl5Iiwgd2hlcmUgCisJCQkJCQkgKiB4PXR1bm5lbF9pZCwgeT1zZXNzaW9uX2lkICov CisJaW50CQkJbXR1OworCWludAkJCW1ydTsKKwlpbnQJCQlmbGFnczsJCS8qIGFjY2Vzc2VkIGJ5 IFBQUElPQ0dGTEFHUy4gCisJCQkJCQkgKiBVbnVzZWQuICovCisJaW50CQkJcmVjdl9zZXE6MTsJ LyogZXhwZWN0IHJlY2VpdmUgcGFja2V0cyB3aXRoIAorCQkJCQkJICogc2VxdWVuY2UgbnVtYmVy cz8gKi8KKwlpbnQJCQlzZW5kX3NlcToxOwkvKiBzZW5kIHBhY2tldHMgd2l0aCBzZXF1ZW5jZSAK KwkJCQkJCSAqIG51bWJlcnM/ICovCisJaW50CQkJbG5zX21vZGU6MTsJLyogYmVoYXZlIGFzIExO Uz8gTEFDIGVuYWJsZXMgCisJCQkJCQkgKiBzZXF1ZW5jZSBudW1iZXJzIHVuZGVyIAorCQkJCQkJ ICogY29udHJvbCBvZiBMTlMuICovCisJaW50CQkJZGVidWc7CQkvKiBiaXRtYXNrIG9mIGRlYnVn IG1lc3NhZ2UgCisJCQkJCQkgKiBjYXRlZ29yaWVzICovCisJaW50CQkJcmVvcmRlcl90aW1lb3V0 OyAvKiBjb25maWd1cmVkIHJlb3JkZXIgdGltZW91dCAKKwkJCQkJCSAgKiAoaW4gamlmZmllcykg Ki8KKwl1MTYJCQlucjsJCS8qIHNlc3Npb24gTlIgc3RhdGUgKHJlY2VpdmUpICovCisJdTE2CQkJ bnM7CQkvKiBzZXNzaW9uIE5SIHN0YXRlIChzZW5kKSAqLworCXN0cnVjdCBwcHBvbDJ0cF9pb2Nf c3RhdHMgc3RhdHM7CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKm5leHQ7CQkvKiBOZXh0IGlu IHRoaXMgaGFzaCBjaGFpbiAqLworfTsKKworLyogVGhlIHNrX3VzZXJfZGF0YSBmaWVsZCBvZiB0 aGUgdHVubmVsJ3MgVURQIHNvY2tldC4gSXQgY29udGFpbnMgaW5mbyB0byB0cmFjaworICogYWxs IHRoZSBhc3NvY2lhdGVkIHNlc3Npb25zIHNvIGluY29taW5nIHBhY2tldHMgY2FuIGJlIHNvcnRl ZCBvdXQKKyAqLworc3RydWN0IHBwcG9sMnRwX3R1bm5lbAoreworCWludAkJCW1hZ2ljOwkJLyog U2hvdWxkIGJlIEwyVFBfVFVOTkVMX01BR0lDICovCisJCisJc3RydWN0IHByb3RvCQlvbGRfcHJv dG87CS8qIG9yaWdpbmFsIHByb3RvICovCisJc3RydWN0IHByb3RvCQlsMnRwX3Byb3RvOwkvKiBM MlRQIHByb3RvICovCisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKmhhc2hbUFBQT0wyVFBfSEFT SF9TSVpFXTsKKwlpbnQJCQlkZWJ1ZzsJCS8qIGJpdG1hc2sgb2YgZGVidWcgbWVzc2FnZSAKKwkJ CQkJCSAqIGNhdGVnb3JpZXMgKi8KKwljaGFyCQkJbmFtZVsxMl07CS8qICJ0dW5sIHh4eHh4IiAq LworCXN0cnVjdCBwcHBvbDJ0cF9pb2Nfc3RhdHMgc3RhdHM7CisJCisJdm9pZCAoKm9sZF9kYXRh X3JlYWR5KShzdHJ1Y3Qgc29jayAqLCBpbnQpOworCXZvaWQgKCpvbGRfc2tfZGVzdHJ1Y3QpKHN0 cnVjdCBzb2NrICopOworCisJc3RydWN0IHNvY2sJCSpzb2NrOwkJLyogUGFyZW50IHNvY2tldCAq LwkKKwlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsCSpuZXh0OwkJLyogS2VlcCBhIGxpc3Qgb2YgYWxs IG9wZW4gCisJCQkJCQkgKiBwcmVwYXJlZCBzb2NrZXRzICovCisKKwlhdG9taWNfdAkJc2Vzc2lv bl9jb3VudDsKK307CisKKy8qIE51bWJlciBvZiBieXRlcyB0byBidWlsZCB0cmFuc21pdCBMMlRQ IGhlYWRlcnMuCisgKiBVbmZvcnR1bmF0ZWx5IHRoZSBzaXplIGlzIGRpZmZlcmVudCBkZXBlbmRp bmcgb24gd2hldGhlciBzZXF1ZW5jZSBudW1iZXJzCisgKiBhcmUgZW5hYmxlZC4KKyAqLworI2Rl ZmluZSBQUFBPTDJUUF9MMlRQX0hEUl9TSVpFX1NFUQkJMTAKKyNkZWZpbmUgUFBQT0wyVFBfTDJU UF9IRFJfU0laRV9OT1NFUQkJNgorCisKK3N0YXRpYyBpbnQgcHBwb2wydHBfeG1pdChzdHJ1Y3Qg cHBwX2NoYW5uZWwgKmNoYW4sIHN0cnVjdCBza19idWZmICpza2IpOworCitzdGF0aWMgc3RydWN0 IHBwcF9jaGFubmVsX29wcyBwcHBvbDJ0cF9jaGFuX29wcyA9IHsgcHBwb2wydHBfeG1pdCAsIE5V TEwgfTsKK3N0YXRpYyBzdHJ1Y3QgcHJvdG9fb3BzIHBwcG9sMnRwX29wczsKK3N0YXRpYyBzdHJ1 Y3QgcHBwb2wydHBfdHVubmVsICpwcHBvbDJ0cF90dW5uZWxfbGlzdDsKKworLyogTWFjcm9zIHRv IGRlcml2ZSBzZXNzaW9uL3R1bm5lbCBjb250ZXh0IHBvaW50ZXJzIGZyb20gYSBzb2NrZXQuICov CisjZGVmaW5lIFNPQ0tfMl9TRVNTSU9OKHNvY2ssIHNlc3Npb24sIGVyciwgZXJydmFsLCBsYWJl bCwgcXVpZXQpIFwKKwlzZXNzaW9uID0gKHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICopKChzb2Nr KS0+c2tfdXNlcl9kYXRhKTsgIFwKKwlpZiAoIXNlc3Npb24gfHwgc2Vzc2lvbi0+bWFnaWMgIT0g TDJUUF9TRVNTSU9OX01BR0lDKSB7CSAgICAgICBcCisJCWlmICghcXVpZXQpIFwKKwkJCXByaW50 ayhLRVJOX0VSUiAiJXM6ICVzOiVkOiBCQUQgU0VTU0lPTiBNQUdJQyAiIFwKKwkJCSAgICAgICAi KCIgI3NvY2sgIj0lcCkgc2Vzc2lvbj0lcCBtYWdpYz0leFxuIiwgXAorCQkJICAgICAgIF9fRlVO Q1RJT05fXywgX19GSUxFX18sIF9fTElORV9fLCBzb2NrLCBcCisJCQkgICAgICAgc2Vzc2lvbiwg c2Vzc2lvbiA/IHNlc3Npb24tPm1hZ2ljIDogMCk7IFwKKwkJZXJyID0gZXJydmFsOyBcCisJCWdv dG8gbGFiZWw7IFwKKwl9CisJCisjZGVmaW5lIFNPQ0tfMl9UVU5ORUwoc29jaywgdHVubmVsLCBl cnIsIGVycnZhbCwgbGFiZWwsIHF1aWV0KSBcCisJdHVubmVsID0gKHN0cnVjdCBwcHBvbDJ0cF90 dW5uZWwgKikoKHNvY2spLT5za191c2VyX2RhdGEpOwkgXAorCWlmICghdHVubmVsIHx8IHR1bm5l bC0+bWFnaWMgIT0gTDJUUF9UVU5ORUxfTUFHSUMpIHsJICAgICBcCisJCWlmICghcXVpZXQpIFwK KwkJCXByaW50ayhLRVJOX0VSUiAiJXM6ICVzOiVkOiBCQUQgVFVOTkVMIE1BR0lDICIgXAorCQkJ ICAgICAgICIoIiAjc29jayAiPSVwKSB0dW5uZWw9JXAgbWFnaWM9JXhcbiIsIFwKKwkJCSAgICAg ICBfX0ZVTkNUSU9OX18sIF9fRklMRV9fLCBfX0xJTkVfXywgc29jaywgXAorCQkJICAgICAgIHR1 bm5lbCwgdHVubmVsID8gdHVubmVsLT5tYWdpYyA6IDApOyBcCisJCWVyciA9IGVycnZhbDsgXAor CQlnb3RvIGxhYmVsOyBcCisJfQorCisvKiBFYXN5IHdheSB0byBsb2NhdGUgZmVhdHVyZXMgbm90 IHlldCBpbXBsZW1lbnRlZCAKKyAqLworc3RhdGljIHZvaWQgcHBwb2wydHBfd2Fybl9ub3RfeWV0 X2ltcGxlbWVudGVkKGludCBkZWJ1Z19tYXNrLCBjb25zdCBjaGFyICp3aGF0KQoreworCVBSSU5U SyhkZWJ1Z19tYXNrLCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9XQVJOSU5HLCAKKwkgICAg ICAgImZlYXR1cmUgJXMgbm90IHlldCBpbXBsZW1lbnRlZFxuIiwgd2hhdCk7Cit9CisKK3N0YXRp YyByd2xvY2tfdCBwcHBvbDJ0cF9oYXNoX2xvY2sgPSBSV19MT0NLX1VOTE9DS0VEOworCisvKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioKKyAqIEhhc2ggdGFibGUgaW1wbGVtZW50YXRpb24uCisgKgorICog V2UgbmVlZCB0byBmaW5kIHNlc3Npb25zIGVmZmljaWVudGx5LCBpZGVudGlmaWVkIGJ5IGEgdHVu bmVsX2lkL3Nlc3Npb25faWQKKyAqIHBhaXIsIGhlbmNlIHdlIHVzZSBhIGhhc2ggdGFibGUuCisg KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKiovCisKK3N0YXRpYyBpbmxpbmUgaW50IGNtcF9hZGRyKHN0cnVj dCBwcHBvbDJ0cF9hZGRyICphZGRyLCB1MTYgdHVubmVsLCB1MTYgc2Vzc2lvbikKK3sKKwlyZXR1 cm4gKChhZGRyLT5zX3R1bm5lbCA9PSB0dW5uZWwpICYmIChhZGRyLT5zX3Nlc3Npb24gPT0gc2Vz c2lvbikpOworfQorCitzdGF0aWMgaW50IGhhc2hfaXRlbSh1MTYgdHVubmVsLCB1MTYgc2Vzc2lv bikKK3sKKwlpbnQgaSwgdGVtcCwgaGFzaDsKKworCWhhc2ggPSAwOwkKKwl0ZW1wID0gdHVubmVs IF4gc2Vzc2lvbjsKKworCWZvciAoaSA9IDA7IGkgPD0gc2l6ZW9mKHUxNikvUFBQT0wyVFBfSEFT SF9CSVRTOyArK2kpIHsKKwkJaGFzaCBePSB0ZW1wOworCQl0ZW1wID4+PSBQUFBPTDJUUF9IQVNI X0JJVFM7CisJfQorCXJldHVybiBoYXNoICYgKFBQUE9MMlRQX0hBU0hfU0laRSAtIDEpOworfQor CisvKiBTZXQvZ2V0L2RlbGV0ZS9yZWhhc2ggaXRlbXMJIChpbnRlcm5hbCB2ZXJzaW9ucykKKyAq Lworc3RhdGljIHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpfX2dldF9pdGVtKHN0cnVjdCBwcHBv bDJ0cF90dW5uZWwgKnR1bm5lbCwgCisJCQkJCSAgIHUxNiB0dW5uZWxfaWQsIHUxNiBzZXNzaW9u X2lkKQoreworCWludCBoYXNoID0gaGFzaF9pdGVtKHR1bm5lbF9pZCwgc2Vzc2lvbl9pZCk7CisJ c3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnJldDsKKworCXJldCA9IHR1bm5lbC0+aGFzaFtoYXNo XTsKKworCXdoaWxlIChyZXQgJiYgIWNtcF9hZGRyKCZyZXQtPnR1bm5lbF9hZGRyLCB0dW5uZWxf aWQsIHNlc3Npb25faWQpKQorCQlyZXQgPSByZXQtPm5leHQ7CisKKwlyZXR1cm4gcmV0OworfQor CitzdGF0aWMgaW50IF9fc2V0X2l0ZW0oc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsLCAK KwkJICAgICAgc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24pCit7CisJc3RydWN0IHBw cG9sMnRwX2FkZHIgKmFkZHIgPSAmc2Vzc2lvbi0+dHVubmVsX2FkZHI7CisJaW50IGhhc2ggPSBo YXNoX2l0ZW0oYWRkci0+c190dW5uZWwsIGFkZHItPnNfc2Vzc2lvbik7CisJc3RydWN0IHBwcG9s MnRwX3Nlc3Npb24gKnJldDsKKworCXJldCA9IHR1bm5lbC0+aGFzaFtoYXNoXTsKKwl3aGlsZSAo cmV0KSB7CisJCWlmIChjbXBfYWRkcigmcmV0LT50dW5uZWxfYWRkciwgYWRkci0+c190dW5uZWws IGFkZHItPnNfc2Vzc2lvbikpCisJCQlyZXR1cm4gLUVBTFJFQURZOworCisJCXJldCA9IHJldC0+ bmV4dDsKKwl9CisKKwlpZiAoIXJldCkgeworCQlzZXNzaW9uLT5uZXh0ID0gdHVubmVsLT5oYXNo W2hhc2hdOworCQl0dW5uZWwtPmhhc2hbaGFzaF0gPSBzZXNzaW9uOworCX0KKworCXJldHVybiAw OworfQorCitzdGF0aWMgc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKl9fZGVsZXRlX2l0ZW0oc3Ry dWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsLCAKKwkJCQkJICAgICAgdTE2IHR1bm5lbF9pZCwg dTE2IHNlc3Npb25faWQpCit7CisJaW50IGhhc2ggPSBoYXNoX2l0ZW0odHVubmVsX2lkLCBzZXNz aW9uX2lkKTsKKwlzdHJ1Y3QgcHBwb2wydHBfc2Vzc2lvbiAqcmV0LCAqKnNyYzsKKworCXJldCA9 IHR1bm5lbC0+aGFzaFtoYXNoXTsKKwlzcmMgPSAmdHVubmVsLT5oYXNoW2hhc2hdOworCisJd2hp bGUgKHJldCkgeworCQlpZiAoY21wX2FkZHIoJnJldC0+dHVubmVsX2FkZHIsIHR1bm5lbF9pZCwg c2Vzc2lvbl9pZCkpIHsKKwkJCSpzcmMgPSByZXQtPm5leHQ7CisJCQlicmVhazsKKwkJfQorCisJ CXNyYyA9ICZyZXQtPm5leHQ7CisJCXJldCA9IHJldC0+bmV4dDsKKwl9CisKKwlyZXR1cm4gcmV0 OworfQorCisvKiBTZXQvZ2V0L2RlbGV0ZS9yZWhhc2ggaXRlbXMKKyAqLworc3RhdGljIGlubGlu ZSBzdHJ1Y3QgcHBwb2wydHBfc2Vzc2lvbiAqZ2V0X2l0ZW0oc3RydWN0IHBwcG9sMnRwX3R1bm5l bCAqdHVubmVsLCAKKwkJCQkJCXUxNiB0dW5uZWxfaWQsIHUxNiBzZXNzaW9uX2lkKQoreworCXN0 cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uOworCQorCUVOVEVSX0ZVTkNUSU9OOworCisJ cmVhZF9sb2NrX2JoKCZwcHBvbDJ0cF9oYXNoX2xvY2spOworCXNlc3Npb24gPSBfX2dldF9pdGVt KHR1bm5lbCwgdHVubmVsX2lkLCBzZXNzaW9uX2lkKTsKKwlpZiAoc2Vzc2lvbikKKwkJc29ja19o b2xkKHNlc3Npb24tPnNvY2spOworCXJlYWRfdW5sb2NrX2JoKCZwcHBvbDJ0cF9oYXNoX2xvY2sp OworCisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm4gc2Vzc2lvbjsKK30KKworc3RhdGljIGlubGlu ZSBpbnQgc2V0X2l0ZW0oc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsLCAKKwkJCSAgIHN0 cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uKQoreworCWludCBpOworCQorCUVOVEVSX0ZV TkNUSU9OOworCisJaWYgKCFzZXNzaW9uKQorCQlyZXR1cm4gLUVJTlZBTDsKKworCXdyaXRlX2xv Y2tfYmgoJnBwcG9sMnRwX2hhc2hfbG9jayk7CisJaSA9IF9fc2V0X2l0ZW0odHVubmVsLCBzZXNz aW9uKTsKKwl3cml0ZV91bmxvY2tfYmgoJnBwcG9sMnRwX2hhc2hfbG9jayk7CisKKwlFWElUX0ZV TkNUSU9OOworCXJldHVybiBpOworfQorCitzdGF0aWMgaW5saW5lIHN0cnVjdCBwcHBvbDJ0cF9z ZXNzaW9uICpkZWxldGVfaXRlbShzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWwsCisJCQkJ CQkgICB1MTYgdHVubmVsX2lkLCAKKwkJCQkJCSAgIHUxNiBzZXNzaW9uX2lkKQoreworCXN0cnVj dCBwcHBvbDJ0cF9zZXNzaW9uICpyZXQ7CisKKwlFTlRFUl9GVU5DVElPTjsKKworCXdyaXRlX2xv Y2tfYmgoJnBwcG9sMnRwX2hhc2hfbG9jayk7CisJcmV0ID0gX19kZWxldGVfaXRlbSh0dW5uZWws IHR1bm5lbF9pZCwgc2Vzc2lvbl9pZCk7CisJd3JpdGVfdW5sb2NrX2JoKCZwcHBvbDJ0cF9oYXNo X2xvY2spOworCisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm4gcmV0OworfQorCisvKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioKKyAqIFJlY2VpdmUgZGF0YSBoYW5kbGluZworICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqLworCisvKiBJbnRlcm5hbCByZWNlaXZlIGZyYW1lLiBEbyB0aGUgcmVhbCB3b3JrIG9mIHJl Y2VpdmluZyBhbiBMMlRQIGRhdGEgZnJhbWUKKyAqIGhlcmUuCisgKiBSZXR1cm5zIDAgaWYgdGhl IHBhY2tldCB3YXMgYSBkYXRhIHBhY2tldCBhbmQgd2FzIHN1Y2Nlc3NmdWxseSBwYXNzZWQgb24u CisgKiBSZXR1cm5zIDEgaWYgdGhlIHBhY2tldCB3YXMgbm90IGEgZ29vZCBkYXRhIHBhY2tldCBh bmQgY291bGQgbm90IGJlCisgKiBmb3J3YXJkZWQuICBBbGwgc3VjaCBwYWNrZXRzIGFyZSBwYXNz ZWQgdXAgdG8gdXNlcnNwYWNlIHRvIGRlYWwgd2l0aC4KKyAqLworc3RhdGljIGludCBwcHBvbDJ0 cF9yZWN2X2NvcmUoc3RydWN0IHNvY2sgKnNvY2ssIHN0cnVjdCBza19idWZmICpza2IpCit7CisJ c3RydWN0IHBwcG94X29wdCAqcG87CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24g PSBOVUxMOworCWludCBlcnJvciA9IDA7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVs OworCXN0cnVjdCBzb2NrICpzZXNzaW9uX3NvY2sgPSBOVUxMOworCXVuc2lnbmVkIGNoYXIgKnB0 cjsKKwl1MTYgaGRyZmxhZ3M7CisJdTE2IHR1bm5lbF9pZCwgc2Vzc2lvbl9pZDsKKwlpbnQgbGVu Z3RoOworCWludCByZXN1bHQ7CisKKwlFTlRFUl9GVU5DVElPTjsKKworCVNPQ0tfMl9UVU5ORUwo c29jaywgdHVubmVsLCBlcnJvciwgMSwgZW5kLCAwKTsKKworCS8qIFNob3J0IHBhY2tldD8gKi8K KwlpZiAoc2tiLT5sZW4gPCBzaXplb2Yoc3RydWN0IHVkcGhkcikpIHsKKwkJUFJJTlRLKHR1bm5l bC0+ZGVidWcsIFBQUE9MMlRQX01TR19EQVRBLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiBy ZWN2IHNob3J0IHBhY2tldCAobGVuPSVkKVxuIiwgdHVubmVsLT5uYW1lLCBza2ItPmxlbik7CisJ CWdvdG8gZW5kOworCX0KKworCS8qIFBvaW50IHRvIEwyVFAgaGVhZGVyICovCisJcHRyID0gc2ti LT5kYXRhICsgc2l6ZW9mKHN0cnVjdCB1ZHBoZHIpOworCisJLyogR2V0IEwyVFAgaGVhZGVyIGZs YWdzICovCisJaGRyZmxhZ3MgPSBudG9ocygqKHUxNiopcHRyKTsKKworCS8qIFRyYWNlIHBhY2tl dCBjb250ZW50cywgaWYgZW5hYmxlZCAqLworCWlmICh0dW5uZWwtPmRlYnVnICYgUFBQT0wyVFBf TVNHX0RBVEEpIHsKKwkJcHJpbnRrKEtFUk5fREVCVUcgIiVzOiByZWN2OiAiIEtFUk5fREVCVUcs IHR1bm5lbC0+bmFtZSk7CisKKwkJZm9yIChsZW5ndGggPSAwOyBsZW5ndGggPCAxNjsgbGVuZ3Ro KyspCisJCQlwcmludGsoIiAlMDJYIiwgcHRyW2xlbmd0aF0pOworCQlwcmludGsoIlxuIik7CisJ fQorCisJLyogR2V0IGxlbmd0aCBvZiBMMlRQIHBhY2tldCAqLworCWxlbmd0aCA9IG50b2hzKHNr Yi0+aC51aC0+bGVuKSAtIHNpemVvZihzdHJ1Y3QgdWRwaGRyKTsKKwkKKwkvKiBUb28gc2hvcnQ/ ICovCisJaWYgKGxlbmd0aCA8IDEyKSB7CisJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQUFBPTDJU UF9NU0dfREFUQSwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogcmVjdiBzaG9ydCBMMlRQIHBh Y2tldCAobGVuPSVkKVxuIiwgdHVubmVsLT5uYW1lLCBsZW5ndGgpOworCQlnb3RvIGVuZDsKKwl9 CisJCisJLyogSWYgdHlwZSBpcyBjb250cm9sIHBhY2tldCwgaXQgaXMgaGFuZGxlZCBieSB1c2Vy c3BhY2UuICovCisJaWYgKGhkcmZsYWdzICYgTDJUUF9IRFJGTEFHX1QpIHsgCisJCVBSSU5USyh0 dW5uZWwtPmRlYnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAi JXM6IHJlY3YgY29udHJvbCBwYWNrZXQsIGxlbj0lZFxuIiwgdHVubmVsLT5uYW1lLCBsZW5ndGgp OworCQlnb3RvIGVuZDsKKwl9CisKKwkvKiBTa2lwIGZsYWdzICovCisJcHRyICs9IDI7CisJCisJ LyogSWYgbGVuZ3RoIGlzIHByZXNlbnQsIHNraXAgaXQgKi8KKwlpZiAoaGRyZmxhZ3MgJiBMMlRQ X0hEUkZMQUdfTCkKKwkJcHRyICs9IDI7CisKKwkvKiBFeHRyYWN0IHR1bm5lbCBhbmQgc2Vzc2lv biBJRCAqLworCXR1bm5lbF9pZCA9IG50b2hzKCoodTE2ICopIHB0cik7CisJcHRyICs9IDI7CisJ c2Vzc2lvbl9pZCA9IG50b2hzKCoodTE2ICopIHB0cik7CisJcHRyICs9IDI7CisKKwkvKiBGaW5k IHRoZSBzZXNzaW9uIGNvbnRleHQgKi8KKwlzZXNzaW9uID0gZ2V0X2l0ZW0odHVubmVsLCB0dW5u ZWxfaWQsIHNlc3Npb25faWQpOworCWlmICghc2Vzc2lvbikgeworCQkvKiBOb3QgZm91bmQ/IFBh c3MgdG8gdXNlcnNwYWNlIHRvIGRlYWwgd2l0aCAqLworCQlQUklOVEsodHVubmVsLT5kZWJ1Zywg UFBQT0wyVFBfTVNHX0RBVEEsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IG5vIHNvY2tldCBm b3VuZCAoJWh1LyVodSkuIFBhc3NpbmcgdXAuXG4iLCAKKwkJICAgICAgIHR1bm5lbC0+bmFtZSwg dHVubmVsX2lkLCBzZXNzaW9uX2lkKTsKKwkJZ290byBlbmQ7CisJfQorCisJRFBSSU5USyhzZXNz aW9uLT5kZWJ1ZywgIiVzOiBzb2NrZXQgcmN2YnVmIGFsbG9jPSVkXG4iLCAKKwkJc2Vzc2lvbi0+ bmFtZSwgYXRvbWljX3JlYWQoJnNvY2stPnNrX3JtZW1fYWxsb2MpKTsKKworCS8qIFRoZSByZWYg Y291bnQgb24gdGhlIHNvY2tldCB3YXMgaW5jcmVhc2VkIGJ5IHRoZSBhYm92ZSBjYWxsIHNpbmNl CisJICogd2Ugbm93IGhvbGQgYSBwb2ludGVyIHRvIHRoZSBzZXNzaW9uLiBUYWtlIGNhcmUgdG8g ZG8gc29ja19wdXQoKQorCSAqIHdoZW4gZXhpdGluZyB0aGlzIGZ1bmN0aW9uIGZyb20gbm93IG9u Li4uCisJICovCisKKwkvKiBIYW5kbGUgdGhlIG9wdGlvbmFsIHNlcXVlbmNlIG51bWJlcnMuICBJ ZiB3ZSBhcmUgdGhlIExBQywKKwkgKiBlbmFibGUvZGlzYWJsZSBzZXF1ZW5jZSBudW1iZXJzIHVu ZGVyIHRoZSBjb250cm9sIG9mIHRoZSBMTlMuICBJZgorCSAqIG5vIHNlcXVlbmNlIG51bWJlcnMg cHJlc2VudCBidXQgd2Ugd2VyZSBleHBlY3RpbmcgdGhlbSwgZGlzY2FyZAorCSAqIGZyYW1lLgor CSAqLworCWlmIChoZHJmbGFncyAmIEwyVFBfSERSRkxBR19TKSB7CisJCXUxNiBucywgbnI7CisJ CW5zID0gbnRvaHMoKih1MTYgKikgcHRyKTsKKwkJcHRyICs9IDI7CisJCW5yID0gbnRvaHMoKih1 MTYgKikgcHRyKTsKKwkJcHRyICs9IDI7CisKKwkJLyogUmVjZWl2ZWQgYSBwYWNrZXQgd2l0aCBz ZXF1ZW5jZSBudW1iZXJzLiBJZiB3ZSdyZSB0aGUgTE5TLAorCQkgKiBjaGVjayBpZiB3ZSBzcmUg c2VuZGluZyBzZXF1ZW5jZSBudW1iZXJzIGFuZCBpZiBub3QsCisJCSAqIGNvbmZpZ3VyZSBpdCBz by4KKwkJICovCisJCWlmICgoIXNlc3Npb24tPmxuc19tb2RlKSAmJiAoIXNlc3Npb24tPnNlbmRf c2VxKSkgeworCQkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfU0VRLCBLRVJO X0lORk8sIAorCQkJICAgICAgICIlczogcmVxdWVzdGVkIHRvIGVuYWJsZSBzZXEgbnVtYmVycyBi eSBMTlNcbiIsIAorCQkJICAgICAgIHNlc3Npb24tPm5hbWUpOworCQkJc2Vzc2lvbi0+c2VuZF9z ZXEgPSAtMTsKKwkJfQorCisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX1NF USwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6IHJlY3YgZGF0YSBucz0laHUsIG5yPSVodSwg c2Vzc2lvbiBucj0laHVcbiIsIAorCQkgICAgICAgc2Vzc2lvbi0+bmFtZSwgbnMsIG5yLCBzZXNz aW9uLT5ucik7CisKKwkJLyogRGlzY2FyZCBvdXQtb2Ytc2VxdWVuY2UgcGFja2V0cyAqLworCQlp ZiAobnMgIT0gc2Vzc2lvbi0+bnIpIHsKKwkJCXNlc3Npb24tPnN0YXRzLnJ4X29vc19wYWNrZXRz Kys7CisJCQlzZXNzaW9uLT5zdGF0cy5yeF9lcnJvcnMrKzsKKwkJCWdvdG8gZGlzY2FyZDsKKwkJ fQorCisJCS8qIEJ1bXAgb3VyIE5yICovCisJCXNlc3Npb24tPm5yKys7CisJCVBSSU5USyhzZXNz aW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX1NFUSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6 IHVwZGF0ZWQgbnIgdG8gJWh1XG4iLCBzZXNzaW9uLT5uYW1lLCBzZXNzaW9uLT5ucik7CisJfSBl bHNlIHsKKwkJLyogTm8gc2VxdWVuY2UgbnVtYmVycy4KKwkJICogSWYgdXNlciBoYXMgY29uZmln dXJlZCBtYW5kYXRvcnkgc2VxdWVuY2UgbnVtYmVycywgZGlzY2FyZC4KKwkJICovCisJCWlmIChz ZXNzaW9uLT5yZWN2X3NlcSkgeworCQkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9N U0dfU0VRLCBLRVJOX1dBUk5JTkcsIAorCQkJICAgICAgICIlczogcmVjdiBkYXRhIGhhcyBubyBz ZXEgbnVtYmVycyB3aGVuIHJlcXVpcmVkLiAiCisJCQkgICAgICAgIkRpc2NhcmRpbmdcbiIsIHNl c3Npb24tPm5hbWUpOworCQkJc2Vzc2lvbi0+c3RhdHMucnhfc2VxX2Rpc2NhcmRzKys7CisJCQlz ZXNzaW9uLT5zdGF0cy5yeF9lcnJvcnMrKzsKKwkJCWdvdG8gZGlzY2FyZDsKKwkJfQorCisJCS8q IElmIHdlJ3JlIHRoZSBMQUMgYW5kIHdlJ3JlIHNlbmRpbmcgc2VxdWVuY2UgbnVtYmVycywgdGhl CisJCSAqIExOUyBoYXMgcmVxdWVzdGVkIHRoYXQgd2Ugbm8gbG9uZ2VyIHNlbmQgc2VxdWVuY2Ug bnVtYmVycy4KKwkJICogSWYgd2UncmUgdGhlIExOUyBhbmQgd2UncmUgc2VuZGluZyBzZXF1ZW5j ZSBudW1iZXJzLCB0aGUKKwkJICogTEFDIGlzIGJyb2tlbi4gRGlzY2FyZCB0aGUgZnJhbWUuCisJ CSAqLworCQlpZiAoKCFzZXNzaW9uLT5sbnNfbW9kZSkgJiYgKHNlc3Npb24tPnNlbmRfc2VxKSkg eworCQkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfU0VRLCBLRVJOX0lORk8s IAorCQkJICAgICAgICIlczogcmVxdWVzdGVkIHRvIGRpc2FibGUgc2VxIG51bWJlcnMgYnkgTE5T XG4iLCAKKwkJCSAgICAgICBzZXNzaW9uLT5uYW1lKTsKKwkJCXNlc3Npb24tPnNlbmRfc2VxID0g MDsKKwkJfSBlbHNlIGlmIChzZXNzaW9uLT5zZW5kX3NlcSkgeworCQkJUFJJTlRLKHNlc3Npb24t PmRlYnVnLCBQUFBPTDJUUF9NU0dfU0VRLCBLRVJOX1dBUk5JTkcsIAorCQkJICAgICAgICIlczog cmVjdiBkYXRhIGhhcyBubyBzZXEgbnVtYmVycyB3aGVuIHJlcXVpcmVkLiAiCisJCQkgICAgICAg IkRpc2NhcmRpbmdcbiIsIHNlc3Npb24tPm5hbWUpOworCQkJc2Vzc2lvbi0+c3RhdHMucnhfc2Vx X2Rpc2NhcmRzKys7CisJCQlzZXNzaW9uLT5zdGF0cy5yeF9lcnJvcnMrKzsKKwkJCWdvdG8gZGlz Y2FyZDsKKwkJfQorCX0KKwkJCisJLyogSWYgb2Zmc2V0IGJpdCBzZXQsIHNraXAgaXQuICovCisJ aWYgKGhkcmZsYWdzICYgTDJUUF9IRFJGTEFHX08pCisJCXB0ciArPSAyICsgbnRvaHMoKih1MTYg KikgcHRyKTsKKworCXNrYl9wdWxsKHNrYiwgcHRyIC0gc2tiLT5kYXRhKTsKKworCS8qIFNraXAg UFBQIGhlYWRlciwgaWYgcHJlc2VudC4JIEluIHRlc3RpbmcsIE1pY3Jvc29mdCBMMlRQIGNsaWVu dHMKKwkgKiBkb24ndCBzZW5kIHRoZSBQUFAgaGVhZGVyIChQUFAgaGVhZGVyIGNvbXByZXNzaW9u IGVuYWJsZWQpLCBidXQKKwkgKiBvdGhlciBjbGllbnRzIGNhbiBpbmNsdWRlIHRoZSBoZWFkZXIu IFNvIHdlIGNvcGUgd2l0aCBib3RoIGNhc2VzCisJICogaGVyZS4gVGhlIFBQUCBoZWFkZXIgaXMg YWx3YXlzIEZGMDMgd2hlbiB1c2luZyBMMlRQLgorCSAqCisJICogTm90ZSB0aGF0IHNrYi0+ZGF0 YVtdIGlzbid0IGRlcmVmZXJlbmNlZCBmcm9tIGEgdTE2IHB0ciBoZXJlIHNpbmNlCisJICogdGhl IGZpZWxkIG1heSBiZSB1bmFsaWduZWQuCisJICovCisJaWYgKChza2ItPmRhdGFbMF0gPT0gMHhm ZikgJiYgKHNrYi0+ZGF0YVsxXSA9PSAweDAzKSkKKwkJc2tiX3B1bGwoc2tiLCAyKTsKKworCS8q IFdlJ3JlIGFib3V0IHRvIHJlcXVldWUgdGhlIHNrYiwgc28gdW5saW5rIGl0IGFuZCByZXR1cm4g cmVzb3VyY2VzCisJICogdG8gaXRzIGN1cnJlbnQgb3duZXIgKGEgc29ja2V0IHJlY2VpdmUgYnVm ZmVyKS4KKwkgKi8KKwlza2JfdW5saW5rKHNrYik7CisJc2tiX29ycGhhbihza2IpOworCisJdHVu bmVsLT5zdGF0cy5yeF9wYWNrZXRzKys7CisJdHVubmVsLT5zdGF0cy5yeF9ieXRlcyArPSBsZW5n dGg7CisJc2Vzc2lvbi0+c3RhdHMucnhfcGFja2V0cysrOworCXNlc3Npb24tPnN0YXRzLnJ4X2J5 dGVzICs9IGxlbmd0aDsKKworCS8qIElmIHRoZSBzb2NrZXQgaXMgYm91bmQsIHNlbmQgaXQgaW4g dG8gUFBQJ3MgaW5wdXQgcXVldWUuICBPdGhlcndpc2UKKwkgKiBxdWV1ZSBpdCBvbiB0aGUgc29j a2V0LgorCSAqLworCXNlc3Npb25fc29jayA9IHNlc3Npb24tPnNvY2s7CisJaWYgKHNlc3Npb25f c29jay0+c2tfc3RhdGUgJiBQUFBPWF9CT1VORCkgeworCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcs IFBQUE9MMlRQX01TR19EQVRBLCBLRVJOX0RFQlVHLCAKKwkJICAgICAgICIlczogcmVjdiAlZCBi eXRlIGRhdGEgZnJhbWUsIHBhc3NpbmcgdG8gcHBwXG4iLCAKKwkJICAgICAgIHNlc3Npb24tPm5h bWUsIGxlbmd0aCk7CisJCXBvID0gcHBwb3hfc2soc2Vzc2lvbl9zb2NrKTsKKwkJcHBwX2lucHV0 KCZwby0+Y2hhbiwgc2tiKTsKKwl9IGVsc2UgeworCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQ UE9MMlRQX01TR19EQVRBLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiBzb2NrZXQgbm90IGJv dW5kXG4iLCBzZXNzaW9uLT5uYW1lKTsKKwkJLyogTm90IGJvdW5kLiBRdWV1ZSBpdCBub3cgKi8K KwkJc29ja19xdWV1ZV9yY3Zfc2tiKHNlc3Npb25fc29jaywgc2tiKTsKKwl9CisKKwlyZXN1bHQg PSAwOworCitvdXQ6CisJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgImNhbGxpbmcgc29ja19wdXQ7 IHJlZmNudD0lZFxuIiwgCisJCXNlc3Npb24tPnNvY2stPnNrX3JlZmNudC5jb3VudGVyKTsKKwlz b2NrX3B1dChzZXNzaW9uLT5zb2NrKTsKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiByZXN1bHQ7 CisKK2Rpc2NhcmQ6CisJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgImRpc2NhcmRpbmcgc2tiLCBs ZW49JWRcbiIsIHNrYi0+bGVuKTsKKwlza2JfdW5saW5rKHNrYik7CisJa2ZyZWVfc2tiKHNrYik7 CisJcmVzdWx0ID0gMDsKKwlnb3RvIG91dDsKKworZW5kOgorCUVYSVRfRlVOQ1RJT047CisJcmV0 dXJuIDE7Cit9CisKKy8qIFRoZSBkYXRhX3JlYWR5IGhvb2sgb24gdGhlIFVEUCBzb2NrZXQuIFNj YW4gdGhlIGluY29taW5nIHBhY2tldCBsaXN0IGZvcgorICogcGFja2V0cyB0byBwcm9jZXNzCisg Ki8KK3N0YXRpYyB2b2lkIHBwcG9sMnRwX2RhdGFfcmVhZHkoc3RydWN0IHNvY2sgKnNrLCBpbnQg bGVuKQoreworCWludCBlcnI7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCXN0 cnVjdCBza19idWZmICpza2I7CisJaW50IHByb2Nlc3NlZCA9IDA7CisJCisJRU5URVJfRlVOQ1RJ T047CisJU09DS18yX1RVTk5FTChzaywgdHVubmVsLCBlcnIsIC1FQkFERiwgZW5kLCAwKTsKKwkK KwlQUklOVEsodHVubmVsLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0RBVEEsIEtFUk5fREVCVUcsIAor CSAgICAgICAiJXM6IHJlY2VpdmVkICVkIGJ5dGVzXG4iLCB0dW5uZWwtPm5hbWUsIGxlbik7CisJ CisJLyogRklYTUU6IERvIHdlIG5lZWQgdG8gbG9jayB0aGUgc29ja2V0IGhlcmU/ICovCisJc2ti X3F1ZXVlX3dhbGsoJnNrLT5za19yZWNlaXZlX3F1ZXVlLCBza2IpIHsKKwkJaWYgKHBwcG9sMnRw X3JlY3ZfY29yZShzaywgc2tiKSkgeworCQkJLyogc2tiIHdhcyBwYXNzZWQgdG8gdXNlcnNwYWNl ICovCisJCQlwcm9jZXNzZWQgPSAxOworCQkJUFJJTlRLKHR1bm5lbC0+ZGVidWcsIFBQUE9MMlRQ X01TR19EQVRBLCBLRVJOX0RFQlVHLCAKKwkJCSAgICAgICAiJXM6IHBhY2tldCBwYXNzZWQgdG8g dXNlcnNwYWNlXG4iLCAKKwkJCSAgICAgICB0dW5uZWwtPm5hbWUpOworCQl9IGVsc2UgeworCQkJ UFJJTlRLKHR1bm5lbC0+ZGVidWcsIFBQUE9MMlRQX01TR19EQVRBLCBLRVJOX0RFQlVHLCAKKwkJ CSAgICAgICAiJXM6IGRhdGEgcGFja2V0IGFjY2VwdGVkXG4iLCB0dW5uZWwtPm5hbWUpOworCQkJ LyogSWYgdGhlIHBhY2tldCBoYXMgYmVlbiBhY2NlcHRlZCBpdCBpcyB0aGUKKwkJCSAqIHJlc3Bv bnNpYmlsaXR5IG9mIHRoZSByZWNlaXZlciAoZWl0aGVyIHNvY2tldCBvcgorCQkJICogcHBwIGRl dmljZSkgdG8gZGlzcG9zZSBvZiBpdC4KKwkJCSAqCisJCQkgKiBBbHNvLCBzaW5jZSByZWN2X2Nv cmUgaGFzIHJlcXVldWVkIHRoZSBwYWNrZXQKKwkJCSAqIGVsc2V3aGVyZSwgaXQncyBub3Qgc2Fm ZSB0byBjb250aW51ZSB0aGlzIGxvb3AsIHNvCisJCQkgKiB3ZSBicmVhaworCQkJICovCisJCQli cmVhazsKKwkJfQorCX0KKwlpZiAocHJvY2Vzc2VkKSB7CisJCURQUklOVEsodHVubmVsLT5kZWJ1 ZywgIiVzOiBjYWxsaW5nIG9sZCBvbGRfZGF0YV9yZWFkeVxuIiwgCisJCQl0dW5uZWwtPm5hbWUp OworCQl0dW5uZWwtPm9sZF9kYXRhX3JlYWR5KHNrLCBsZW4pOworCX0KK2VuZDoKKwlFWElUX0ZV TkNUSU9OOworCXJldHVybjsKK30KKworLyogUmVjZWl2ZSBtZXNzYWdlLiBUaGlzIGlzIHRoZSBy ZWN2bXNnIGZvciB0aGUgUFBQb0wyVFAgc29ja2V0LgorICovCitzdGF0aWMgaW50IHBwcG9sMnRw X3JlY3Ztc2coc3RydWN0IGtpb2NiICppb2NiLCBzdHJ1Y3Qgc29ja2V0ICpzb2NrLCAKKwkJCSAg ICBzdHJ1Y3QgbXNnaGRyICptc2csIHNpemVfdCBsZW4sCisJCQkgICAgaW50IGZsYWdzKQorewor CWludCBlcnIgPSAwOworCXN0cnVjdCBza19idWZmICpza2IgPSBOVUxMOworCXN0cnVjdCBzb2Nr ICpzayA9IHNvY2stPnNrOworCisJRU5URVJfRlVOQ1RJT047CisKKwllcnIgPSAtRUlPOworCWlm IChzb2NrLT5zdGF0ZSAmIFBQUE9YX0JPVU5EKQorCQlnb3RvIGVycm9yOworCQkJCisJbXNnLT5t c2dfbmFtZWxlbiA9IDA7CisJCisJc2tiPXNrYl9yZWN2X2RhdGFncmFtKHNrLCBmbGFncyAmIH5N U0dfRE9OVFdBSVQsCisJCQkgICAgICBmbGFncyAmIE1TR19ET05UV0FJVCwgJmVycik7CisJaWYg KHNrYikgeworCQllcnIgPSBtZW1jcHlfdG9pb3ZlYyhtc2ctPm1zZ19pb3YsICh1bnNpZ25lZCBj aGFyICopIHNrYi0+ZGF0YSwKKwkJCQkgICAgIHNrYi0+bGVuKTsKKwkJaWYgKGVyciA8IDApCisJ CQlnb3RvIGRvX3NrYl9mcmVlOworCQllcnIgPSBza2ItPmxlbjsKKwl9Citkb19za2JfZnJlZToK KwlpZiAoc2tiKQorCQlrZnJlZV9za2Ioc2tiKTsKK2Vycm9yOgorCUVYSVRfRlVOQ1RJT047CisJ cmV0dXJuIGVycjsKK30KKworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogVHJhbnNtaXQgaGFuZGxpbmcK KyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKi8KKworLyogSW50ZXJuYWwgVURQIHNvY2tldCB0cmFuc21pc3Npb24K KyAqLworc3RhdGljIGludCBwcHBvbDJ0cF91ZHBfc29ja19zZW5kKHN0cnVjdCBraW9jYiAqaW9j YiwKKwkJCQkgIHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uLCAKKwkJCQkgIHN0cnVj dCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbCwKKwkJCQkgIHN0cnVjdCBtc2doZHIgKm1zZywgaW50 IHRvdGFsX2xlbikKK3sKKwltbV9zZWdtZW50X3QgZnM7CisJaW50IGVycm9yOworCisJRU5URVJf RlVOQ1RJT047CisKKwlEUFJJTlRLKHNlc3Npb24tPmRlYnVnLCAiJXM6IHVkcF9zZW5kbXNnIGNh bGwuLi5cbiIsIHNlc3Npb24tPm5hbWUpOworCisJLyogU2V0IHRvIHVzZXJzcGFjZSBkYXRhIHNl Z21lbnQgd2hpbGUgd2UgZG8gYSBzZW5kbXNnKCkgY2FsbC4JV2UncmUKKwkgKiBhY3R1YWxseSBj YWxsaW5nIGEgdXNlcnNwYWNlIEFQSSBmcm9tIHRoZSBrZXJuZWwgaGVyZS4uLgorCSAqLworCWZz ID0gZ2V0X2ZzKCk7CisJc2V0X2ZzKGdldF9kcygpKTsKKworCS8qIFRoZSBhY3R1YWwgc2VuZG1z ZygpIGNhbGwuLi4gKi8KKwllcnJvciA9IHR1bm5lbC0+b2xkX3Byb3RvLnNlbmRtc2coaW9jYiwg c2Vzc2lvbi0+dHVubmVsX3NvY2ssIG1zZywgdG90YWxfbGVuKTsKKwlpZiAoZXJyb3IgPT0gLUVJ T0NCUVVFVUVEKQorCQllcnJvciA9IHdhaXRfb25fc3luY19raW9jYihpb2NiKTsKKworCS8qIEJh Y2sgdG8ga2VybmVsIHNwYWNlICovCisJc2V0X2ZzKGZzKTsKKworCWlmIChlcnJvciA+PSAwKSB7 CisJCXR1bm5lbC0+c3RhdHMudHhfcGFja2V0cysrOworCQl0dW5uZWwtPnN0YXRzLnR4X2J5dGVz ICs9IGVycm9yOworCQlzZXNzaW9uLT5zdGF0cy50eF9wYWNrZXRzKys7CisJCXNlc3Npb24tPnN0 YXRzLnR4X2J5dGVzICs9IGVycm9yOworCX0gZWxzZSB7CisJCXR1bm5lbC0+c3RhdHMudHhfZXJy b3JzKys7CisJCXNlc3Npb24tPnN0YXRzLnR4X2Vycm9ycysrOworCX0KKworCURQUklOVEsoc2Vz c2lvbi0+ZGVidWcsICIlczogJXM6IHJldHVybmluZyByZXN1bHQgJWRcbiIsIF9fRlVOQ1RJT05f XywgCisJCXNlc3Npb24tPm5hbWUsIGVycm9yKTsKKwlrZnJlZShtc2ctPm1zZ19pb3YpOworCWtm cmVlKG1zZyk7CisJCisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm4gZXJyb3I7Cit9CisKKy8qIEJ1 aWxkIGFuIEwyVFAgaGVhZGVyIGZvciB0aGUgc2Vzc2lvbiBpbnRvIHRoZSBidWZmZXIgcHJvdmlk ZWQuCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wydHBfYnVpbGRfbDJ0cF9oZWFkZXIoc3RydWN0IHBw cG9sMnRwX3Nlc3Npb24gKnNlc3Npb24sIAorCQkJCSAgICAgIHZvaWQgKmJ1ZikKK3sKKwl1MTYg KmJ1ZnAgPSBidWY7CisJdTE2IGZsYWdzID0gTDJUUF9IRFJfVkVSOworCisJaWYgKHNlc3Npb24t PnNlbmRfc2VxKSB7CisJCWZsYWdzIHw9IEwyVFBfSERSRkxBR19TOworCX0KKworCS8qIFNldHVw IEwyVFAgaGVhZGVyLgorCSAqIEZJWE1FOiBDYW4gdGhpcyBldmVyIGJlIHVuYWxpZ25lZD8gSXMg ZGlyZWN0IGRlcmVmZXJlbmNpbmcgb2YKKwkgKiAxNi1iaXQgaGVhZGVyIGZpZWxkcyBzYWZlIGhl cmUgZm9yIGFsbCBhcmNoaXRlY3R1cmVzPworCSAqLwkKKwkqYnVmcCsrID0gaHRvbnMoZmxhZ3Mp OworCSpidWZwKysgPSBodG9ucyhzZXNzaW9uLT50dW5uZWxfYWRkci5kX3R1bm5lbCk7CisJKmJ1 ZnArKyA9IGh0b25zKHNlc3Npb24tPnR1bm5lbF9hZGRyLmRfc2Vzc2lvbik7CisJaWYgKHNlc3Np b24tPnNlbmRfc2VxKSB7CisJCSpidWZwKysgPSBodG9ucyhzZXNzaW9uLT5ucyk7CisJCSpidWZw KysgPSAwOworCQlzZXNzaW9uLT5ucysrOworCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9M MlRQX01TR19TRVEsIEtFUk5fREVCVUcsIAorCQkgICAgICAgIiVzOiB1cGRhdGVkIG5zIHRvICVo dVxuIiwgc2Vzc2lvbi0+bmFtZSwgc2Vzc2lvbi0+bnMpOworCX0KKworCXJldHVybiAoKHZvaWQg KikgYnVmcCkgLSBidWY7Cit9CisKKy8qIFRoaXMgaXMgdGhlIHNlbmRtc2cgZm9yIHRoZSBQUFBv TDJUUCBwcHBvbDJ0cF9zZXNzaW9uIHNvY2tldC4gIFdlIGNvbWUgaGVyZQorICogd2hlbiBhIHVz ZXIgYXBwbGljYXRpb24gZG9lcyBhIHNlbmRtc2coKSBvbiB0aGUgc2Vzc2lvbiBzb2NrZXQuIEwy VFAgYW5kCisgKiBQUFAgaGVhZGVycyBtdXN0IGJlIGluc2VydGVkIGludG8gdGhlIHVzZXIncyBk YXRhLgorICovCitzdGF0aWMgaW50IHBwcG9sMnRwX3NlbmRtc2coc3RydWN0IGtpb2NiICppb2Ni LCBzdHJ1Y3Qgc29ja2V0ICpzb2NrLCBzdHJ1Y3QgbXNnaGRyICptLAorCQkJICAgIHNpemVfdCB0 b3RhbF9sZW4pCit7CisJc3RhdGljIHVuc2lnbmVkIGNoYXIgcHBwaFsyXSA9IHsgMHhmZiwgMHgw MyB9OworCXN0cnVjdCBzb2NrICpzayA9IHNvY2stPnNrOworCWludCBlcnJvciA9IDA7CisJdTgg aGRyW1BQUE9MMlRQX0wyVFBfSERSX1NJWkVfU0VRXTsKKwlpbnQgaGRyX2xlbjsKKwlzdHJ1Y3Qg bXNnaGRyICptc2c7CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb247CisJc3RydWN0 IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCisJRU5URVJfRlVOQ1RJT047CisKKwlpZiAoc29j a19mbGFnKHNrLCBTT0NLX0RFQUQpIHx8ICEoc2stPnNrX3N0YXRlICYgUFBQT1hfQ09OTkVDVEVE KSkgeworCQllcnJvciA9IC1FTk9UQ09OTjsKKwkJZ290byBlbmQ7CisJfQorCisJLyogR2V0IHNl c3Npb24gYW5kIHR1bm5lbCBjb250ZXh0cyAqLworCVNPQ0tfMl9TRVNTSU9OKHNrLCBzZXNzaW9u LCBlcnJvciwgLUVCQURGLCBlbmQsIDApOworCVNPQ0tfMl9UVU5ORUwoc2Vzc2lvbi0+dHVubmVs X3NvY2ssIHR1bm5lbCwgZXJyb3IsIC1FQkFERiwgZW5kLCAwKTsKKworCS8qIFNldHVwIEwyVFAg aGVhZGVyICovCQorCWhkcl9sZW4gPSBwcHBvbDJ0cF9idWlsZF9sMnRwX2hlYWRlcihzZXNzaW9u LCAmaGRyKTsKKworCWlmIChzZXNzaW9uLT5zZW5kX3NlcSkKKwkJUFJJTlRLKHNlc3Npb24tPmRl YnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6IHNlbmQg JWQgYnl0ZXMsIG5zPSVodVxuIiwgc2Vzc2lvbi0+bmFtZSwgCisJCSAgICAgICB0b3RhbF9sZW4s IHNlc3Npb24tPm5zIC0gMSk7CisJZWxzZQorCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9M MlRQX01TR19EQVRBLCBLRVJOX0RFQlVHLCAKKwkJICAgICAgICIlczogc2VuZCAlZCBieXRlc1xu Iiwgc2Vzc2lvbi0+bmFtZSwgdG90YWxfbGVuKTsKKworCS8qIFVuZm9ydHVuYXRlbHksIHRoZXJl IGlzIG5vIGRpcmVjdCB3YXkgZm9yIHVzIHRvIHBhc3MgYW4gc2tiIHRvIHRoZQorCSAqIFVEUCBs YXllciwgd2UgaGF2ZSB0byBwcmV0ZW5kIHRvIGJlIHNlbmRpbmcgb3JkaW5hcnkgZGF0YSBhbmQg dXNlCisJICogc2VuZG1zZy4KKwkgKgorCSAqIFdlIGFkZCB0aGUgTDJUUCBhbmQgUFBQIGhlYWRl cnMgaGVyZS4gVG8gZG8gc28sIHdlIGNyZWF0ZSBhIG5ldworCSAqIHN0cnVjdCBtc2doZHIgYW5k IGluc2VydCB0aGUgaGVhZGVycyBhcyB0aGUgZmlyc3QgaW92ZWNzLgorCSAqLworCW1zZyA9IGtt YWxsb2Moc2l6ZW9mKHN0cnVjdCBtc2doZHIpLCBHRlBfS0VSTkVMKTsKKwlpZiAobXNnID09IE5V TEwpIHsKKwkJZXJyb3IgPSAtRU5PQlVGUzsKKwkJdHVubmVsLT5zdGF0cy50eF9lcnJvcnMrKzsK KwkJc2Vzc2lvbi0+c3RhdHMudHhfZXJyb3JzKys7CisJCWdvdG8gZW5kOworCX0KKworCW1zZy0+ bXNnX2lvdiA9IGttYWxsb2MoKG0tPm1zZ19pb3ZsZW4gKyAyKSAqIHNpemVvZihzdHJ1Y3QgaW92 ZWMpLCAKKwkJCSAgICAgICBHRlBfS0VSTkVMKTsKKwlpZiAobXNnLT5tc2dfaW92ID09IE5VTEwp IHsKKwkJZXJyb3IgPSAtRU5PQlVGUzsKKwkJdHVubmVsLT5zdGF0cy50eF9lcnJvcnMrKzsKKwkJ c2Vzc2lvbi0+c3RhdHMudHhfZXJyb3JzKys7CisJCWtmcmVlKG1zZyk7CisJCWdvdG8gZW5kOwor CX0KKworCW1zZy0+bXNnX2lvdlswXS5pb3ZfYmFzZSA9ICZoZHI7CisJbXNnLT5tc2dfaW92WzBd Lmlvdl9sZW4JID0gaGRyX2xlbjsKKwltc2ctPm1zZ19pb3ZbMV0uaW92X2Jhc2UgPSAmcHBwaDsK Kwltc2ctPm1zZ19pb3ZbMV0uaW92X2xlbgkgPSBzaXplb2YocHBwaCk7CisJbWVtY3B5KCZtc2ct Pm1zZ19pb3ZbMl0sICZtLT5tc2dfaW92WzBdLCAKKwkgICAgICAgbS0+bXNnX2lvdmxlbiAqIHNp emVvZihzdHJ1Y3QgaW92ZWMpKTsKKwltc2ctPm1zZ19pb3ZsZW4gPSBtLT5tc2dfaW92bGVuICsg MjsKKwkKKwkvKiBJZiB0aGUgdXNlciBjYWxscyBzZW5kdG8oKSB0aGF0J3MganVzdCB0b28gYmFk ICovCisJbXNnLT5tc2dfbmFtZQkgPSAmc2Vzc2lvbi0+dHVubmVsX2FkZHIuYWRkcjsKKwltc2ct Pm1zZ19uYW1lbGVuID0gc2l6ZW9mKHNlc3Npb24tPnR1bm5lbF9hZGRyLmFkZHIpOworCQorCW1z Zy0+bXNnX2NvbnRyb2wgICAgPSBtLT5tc2dfY29udHJvbDsKKwltc2ctPm1zZ19jb250cm9sbGVu ID0gbS0+bXNnX2NvbnRyb2xsZW47CisJbXNnLT5tc2dfZmxhZ3MJICAgID0gbS0+bXNnX2ZsYWdz OworCisJLyogRG8gdGhlIHJlYWwgd29yay4gVGhpcyBhbHdheXMgZnJlZXMgbXNnLCByZWdhcmRs ZXNzIG9mIHdoZXRoZXIKKwkgKiB0aGVyZSB3YXMgYW4gZXJyb3IKKwkgKi8KKwllcnJvciA9IHBw cG9sMnRwX3VkcF9zb2NrX3NlbmQoaW9jYiwgc2Vzc2lvbiwgdHVubmVsLCBtc2csIAorCQkJCSAg ICAgICB0b3RhbF9sZW4gKyBoZHJfbGVuICsgc2l6ZW9mKHBwcGgpKTsKKworZW5kOgorCUVYSVRf RlVOQ1RJT047CisJcmV0dXJuIGVycm9yOworfQorCisKKy8qIFRyYW5zbWl0IGZ1bmN0aW9uIGNh bGxlZCBieSBnZW5lcmljIFBQUCBkcml2ZXIuICBTZW5kcyBQUFAgZnJhbWUgb3ZlcgorICogUFBQ b0wyVFAgc29ja2V0LgorICoKKyAqIFRoaXMgaXMgYWxtb3N0IHRoZSBzYW1lIGFzIHBwcG9sMnRw X3NlbmRtc2coKSwgYnV0IHJhdGhlciB0aGFuIGJlaW5nIGNhbGxlZAorICogd2l0aCBhIG1zZ2hk ciBmcm9tIHVzZXJzcGFjZSwgaXQgaXMgY2FsbGVkIHdpdGggYSBza2IgZnJvbSB0aGUga2VybmVs LgorICovCitzdGF0aWMgaW50IHBwcG9sMnRwX3htaXQoc3RydWN0IHBwcF9jaGFubmVsICpjaGFu LCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQoreworCXN0cnVjdCBzb2NrICpzayA9IChzdHJ1Y3Qgc29j ayAqKSBjaGFuLT5wcml2YXRlOworCWludCBlcnJvciA9IDA7CisJdTggaGRyW1BQUE9MMlRQX0wy VFBfSERSX1NJWkVfU0VRXTsKKwlpbnQgaGRyX2xlbjsKKwlzdHJ1Y3QgbXNnaGRyICptc2c7CisJ c3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb247CisJc3RydWN0IHBwcG9sMnRwX3R1bm5l bCAqdHVubmVsOworCXN0cnVjdCBraW9jYiBpb2NiOworCXN0cnVjdCBzb2NrX2lvY2Igc2lvY2I7 CisJCisJRU5URVJfRlVOQ1RJT047CisJCisJaWYgKHNvY2tfZmxhZyhzaywgU09DS19ERUFEKSB8 fCAhKHNrLT5za19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpIHsKKwkJRFBSSU5USygtMSwgImRl YWQ9JWQgc3RhdGU9JXhcbiIsIHNvY2tfZmxhZyhzaywgU09DS19ERUFEKSwgc2stPnNrX3N0YXRl KTsKKwkJZXJyb3IgPSAtRU5PVENPTk47CisJCWdvdG8gZW5kOworCX0KKworCS8qIEdldCBzZXNz aW9uIGFuZCB0dW5uZWwgY29udGV4dHMgZnJvbSB0aGUgc29ja2V0ICovCisJU09DS18yX1NFU1NJ T04oc2ssIHNlc3Npb24sIGVycm9yLCAtRUJBREYsIGVuZCwgMCk7CisJU09DS18yX1RVTk5FTChz ZXNzaW9uLT50dW5uZWxfc29jaywgdHVubmVsLCBlcnJvciwgLUVCQURGLCBlbmQsIDApOworCisJ LyogU2V0dXAgTDJUUCBoZWFkZXIgKi8JCisJaGRyX2xlbiA9IHBwcG9sMnRwX2J1aWxkX2wydHBf aGVhZGVyKHNlc3Npb24sICZoZHIpOworCisJaWYgKHNlc3Npb24tPnNlbmRfc2VxKQorCQlQUklO VEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19EQVRBLCBLRVJOX0RFQlVHLCAKKwkJICAg ICAgICIlczogc2VuZCAlZCBieXRlcywgbnM9JWh1XG4iLCAKKwkJICAgICAgIHNlc3Npb24tPm5h bWUsIHNrYi0+bGVuLCBzZXNzaW9uLT5ucyAtIDEpOworCWVsc2UKKwkJUFJJTlRLKHNlc3Npb24t PmRlYnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6IHNl bmQgJWQgYnl0ZXNcbiIsIHNlc3Npb24tPm5hbWUsIHNrYi0+bGVuKTsKKworCS8qIFVuZm9ydHVu YXRseSB0aGVyZSBkb2Vzbid0IGFwcGVhciB0byBiZSBhIHdheSBmb3IgdXMgdG8gcGFzcyBhbiBz a2IKKwkgKiB0byB0aGUgVURQIGxheWVyLCB3ZSBoYXZlIHRvIHByZXRlbmQgdG8gYmUgc2VuZGlu ZyBvcmRpbmFyeSBkYXRhCisJICogYW5kIHVzZSBzZW5kbXNnCisJICovCisJbXNnID0ga21hbGxv YyhzaXplb2Yoc3RydWN0IG1zZ2hkciksIEdGUF9LRVJORUwpOworCWlmIChtc2cgPT0gTlVMTCkg eworCQllcnJvciA9IC1FTk9CVUZTOworCQl0dW5uZWwtPnN0YXRzLnR4X2Vycm9ycysrOworCQlz ZXNzaW9uLT5zdGF0cy50eF9lcnJvcnMrKzsKKwkJZ290byBlbmQ7CisJfQorCQorCW1zZy0+bXNn X2lvdiA9IGttYWxsb2MoMiAqIHNpemVvZihzdHJ1Y3QgaW92ZWMpLCBHRlBfS0VSTkVMKTsKKwlp ZiAobXNnLT5tc2dfaW92ID09IE5VTEwpIHsKKwkJZXJyb3IgPSAtRU5PQlVGUzsKKwkJdHVubmVs LT5zdGF0cy50eF9lcnJvcnMrKzsKKwkJc2Vzc2lvbi0+c3RhdHMudHhfZXJyb3JzKys7CisJCWtm cmVlKG1zZyk7CisJCWdvdG8gZW5kOworCX0KKwltc2ctPm1zZ19pb3ZbMF0uaW92X2Jhc2UgPSAm aGRyOworCW1zZy0+bXNnX2lvdlswXS5pb3ZfbGVuCSA9IGhkcl9sZW47CisJLyogRklYTUU6IGRv IHdlIG5lZWQgdG8gaGFuZGxlIHNrYiBmcmFnbWVudHMgaGVyZT8gKi8KKwltc2ctPm1zZ19pb3Zb MV0uaW92X2Jhc2UgPSBza2ItPmRhdGE7CisJbXNnLT5tc2dfaW92WzFdLmlvdl9sZW4JID0gc2ti LT5sZW47CisJbXNnLT5tc2dfaW92bGVuID0gMjsKKwkKKwkvKiBJZiB0aGUgdXNlciBjYWxscyBz ZW5kdG8oKSB0aGF0J3MganVzdCB0b28gYmFkICovCisJbXNnLT5tc2dfbmFtZQkgPSAmc2Vzc2lv bi0+dHVubmVsX2FkZHIuYWRkcjsKKwltc2ctPm1zZ19uYW1lbGVuID0gc2l6ZW9mKHNlc3Npb24t PnR1bm5lbF9hZGRyLmFkZHIpOworCQorCW1zZy0+bXNnX2NvbnRyb2wgICAgPSBOVUxMOworCW1z Zy0+bXNnX2NvbnRyb2xsZW4gPSAwOworCW1zZy0+bXNnX2ZsYWdzCSAgICA9IE1TR19ET05UV0FJ VDsJLyogTmVlZCB0aGlzIHRvIHByZXZlbnQgYmxvY2tpbmcgKi8KKworCS8qIERvIHRoZSByZWFs IHdvcmsuIFRoaXMgYWx3YXlzIGZyZWVzIG1zZywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyCisJICog dGhlcmUgd2FzIGFuIGVycm9yCisJICovCisJaW5pdF9zeW5jX2tpb2NiKCZpb2NiLCBOVUxMKTsK Kwlpb2NiLnByaXZhdGUgPSAmc2lvY2I7CisJZXJyb3IgPSBwcHBvbDJ0cF91ZHBfc29ja19zZW5k KCZpb2NiLCBzZXNzaW9uLCB0dW5uZWwsIG1zZywgCisJCQkJICAgICAgIHNrYi0+bGVuICsgaGRy X2xlbik7CisKKwlrZnJlZV9za2Ioc2tiKTsKKworZW5kOgorCUVYSVRfRlVOQ1RJT047CisJcmV0 dXJuIGVycm9yOworfQorCisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIFNlc3Npb24gKGFuZCB0 dW5uZWwgY29udHJvbCkgc29ja2V0IGNyZWF0ZS9kZXN0cm95LgorICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqLworCisvKiBXaGVuIHRoZSB0dW5uZWwgVURQIHNvY2tldCBpcyBjbG9zZWQsIGFsbCB0aGUg YXR0YWNoZWQgc29ja2V0cyBuZWVkIHRvIGdvCisgKiB0b28uIFRoaXMgaGFuZGxlcyB0aGF0Lgor ICovCitzdGF0aWMgdm9pZCBwcHBvbDJ0cF90dW5uZWxfY2xvc2VhbGwoc3RydWN0IHBwcG9sMnRw X3R1bm5lbCAqdHVubmVsKQoreworCWludCBoYXNoOworCisJRU5URVJfRlVOQ1RJT047CisJCisJ aWYgKHR1bm5lbCA9PSBOVUxMKQorCQlCVUcoKTsKKworCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQ UFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkgICAgICAgIiVzOiBjbG9zaW5nIGFs bCBzZXNzaW9ucy4uLlxuIiwgdHVubmVsLT5uYW1lKTsKKworCXJlYWRfbG9ja19iaCgmcHBwb2wy dHBfaGFzaF9sb2NrKTsKKwlmb3IgKGhhc2ggPSAwOyBoYXNoIDwgUFBQT0wyVFBfSEFTSF9TSVpF OyBoYXNoKyspIHsKKwkJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24gPSB0dW5uZWwt Pmhhc2hbaGFzaF07CisJCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpuZXh0OworCisJCXdoaWxl IChzZXNzaW9uICE9IE5VTEwpIHsKKwkJCXN0cnVjdCBzb2NrICpzayA9IHNlc3Npb24tPnNvY2s7 CisKKwkJCW5leHQgPSBzZXNzaW9uLT5uZXh0OworCisJCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcs IFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sCisJCQkgICAgICAgIiVzOiBjbG9zaW5n IHNlc3Npb25cbiIsIHNlc3Npb24tPm5hbWUpOworCisJCQlzb2NrX2hvbGQoc2spOworCisJCQkv KiBXZSBob2xkIGEgcmVmZXJlbmNlIHRvIFNLLCBub3cgZHJvcCB0aGUgaGFzaCB0YWJsZQorCQkJ ICogbG9jayBzbyB0aGF0IHdlIG1heSBhdHRlbXB0IHRvIGxvY2sgdGhlIHNvY2tldAorCQkJICog KHdoaWNoIGNhbiBzbGVlcCkuCisJCQkgKi8KKwkJCXJlYWRfdW5sb2NrX2JoKCZwcHBvbDJ0cF9o YXNoX2xvY2spOworCisJCQlsb2NrX3NvY2soc2spOworCisJCQkvKiBQdXJnZSBhbnkgcXVldWVk IGRhdGEgKi8KKwkJCXNrYl9xdWV1ZV9wdXJnZSgmc2stPnNrX3JlY2VpdmVfcXVldWUpOworCQkJ c2tiX3F1ZXVlX3B1cmdlKCZzay0+c2tfd3JpdGVfcXVldWUpOworCisJCQlpZiAoc2stPnNrX3N0 YXRlICYgKFBQUE9YX0NPTk5FQ1RFRCB8IFBQUE9YX0JPVU5EKSkgeworCQkJCXBwcG94X3VuYmlu ZF9zb2NrKHNrKTsKKwkJCQlzay0+c2tfc3RhdGUgPSBQUFBPWF9ERUFEOworCQkJCXNrLT5za19z dGF0ZV9jaGFuZ2Uoc2spOworCQkJfQorCisJCQlyZWxlYXNlX3NvY2soc2spOworCisJCQlEUFJJ TlRLKHNlc3Npb24tPmRlYnVnLCAiY2FsbGluZyBzb2NrX3B1dDsgcmVmY250PSVkXG4iLAorCQkJ CXNrLT5za19yZWZjbnQuY291bnRlcik7CisJCQlzb2NrX3B1dChzayk7CisKKwkJCXJlYWRfbG9j a19iaCgmcHBwb2wydHBfaGFzaF9sb2NrKTsKKworCQkJc2Vzc2lvbiA9IG5leHQ7CisJCX0KKwkJ dHVubmVsLT5oYXNoW2hhc2hdID0gTlVMTDsKKwl9CisJcmVhZF91bmxvY2tfYmgoJnBwcG9sMnRw X2hhc2hfbG9jayk7CisKKwlFWElUX0ZVTkNUSU9OOworfQorCisvKiBSZWFsbHkga2lsbCB0aGUg dHVubmVsLgorICogQ29tZSBoZXJlIG9ubHkgd2hlbiBhbGwgc2Vzc2lvbnMgaGF2ZSBiZWVuIGNs ZWFyZWQgZnJvbSB0aGUgdHVubmVsLgorICovCitzdGF0aWMgdm9pZCBwcHBvbDJ0cF90dW5uZWxf ZnJlZShzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWwpCit7CisJc3RydWN0IHBwcG9sMnRw X3R1bm5lbCAqKnB0cjsKKworCUVOVEVSX0ZVTkNUSU9OOworCisJLyogUmVtb3ZlIGZyb20gc29j a2V0IGxpc3QgKi8KKwlmb3IgKHB0ciA9ICZwcHBvbDJ0cF90dW5uZWxfbGlzdDsgKnB0cjsgcHRy ID0gJigqcHRyKS0+bmV4dCkgeworCQlpZiAoKnB0ciA9PSB0dW5uZWwpIHsKKwkJCSpwdHIgPSB0 dW5uZWwtPm5leHQ7CisJCQlicmVhazsKKwkJfQorCX0KKworCWtmcmVlKHR1bm5lbCk7CisKKwlF WElUX0ZVTkNUSU9OOworfQorCisvKiBUdW5uZWwgVURQIHNvY2tldCBkZXN0cnVjdCBob29rLgor ICogVGhlIHR1bm5lbCBjb250ZXh0IGlzIGRlbGV0ZWQgb25seSB3aGVuIGFsbCBzZXNzaW9uIHNv Y2tldHMgaGF2ZSBiZWVuCisgKiBjbG9zZWQuCisgKi8KK3N0YXRpYyB2b2lkIHBwcG9sMnRwX3R1 bm5lbF9kZXN0cnVjdChzdHJ1Y3Qgc29jayAqc2spCit7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5l bCAqdHVubmVsOworCWludCBlcnJvciA9IDA7CisJRU5URVJfRlVOQ1RJT047CisJCisJU09DS18y X1RVTk5FTChzaywgdHVubmVsLCBlcnJvciwgLUVCQURGLCBlbmQsIDApOworCisJUFJJTlRLKHR1 bm5lbC0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCSAgICAgICAi JXM6IGNsb3NpbmcuLi5cbiIsIHR1bm5lbC0+bmFtZSk7IAorCQorCXBwcG9sMnRwX3R1bm5lbF9j bG9zZWFsbCh0dW5uZWwpOworCitlbmQ6CisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm47Cit9CisK Ky8qIFJlYWxseSBraWxsIHRoZSBzb2NrZXQuIChDYWxsZWQgZnJvbSBzb2NrX3B1dCBpZiByZWZj bnQgPT0gMC4pCisgKi8KK3N0YXRpYyB2b2lkIHBwcG9sMnRwX3Nlc3Npb25fZGVzdHJ1Y3Qoc3Ry dWN0IHNvY2sgKnNrKQoreworCXN0cnVjdCBwcHBveF9vcHQgKnBvID0gcHBwb3hfc2soc2spOwor CXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uID0gTlVMTDsKKwlpbnQgZXJyb3IgPSAw OworCisJRU5URVJfRlVOQ1RJT047CisJCisJaWYgKHNrLT5za191c2VyX2RhdGEgIT0gTlVMTCkg eworCQlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWw7CisKKwkJU09DS18yX1NFU1NJT04o c2ssIHNlc3Npb24sIGVycm9yLCAtRUJBREYsIG91dCwgMCk7CisKKwkJLyogRG9uJ3QgdXNlIFNP Q0tfMl9UVU5ORUwoKSBoZXJlIHRvIGdldCB0aGUgdHVubmVsIGNvbnRleHQKKwkJICogYmVjYXVz ZSB0aGUgdHVubmVsIHNvY2tldCBtaWdodCBoYXZlIGFscmVhZHkgYmVlbiBjbG9zZWQKKwkJICog KGl0cyBzay0+c2tfdXNlcl9kYXRhIHdpbGwgYmUgTlVMTCkgc28gdXNlIHRoZSBzZXNzaW9uJ3MK KwkJICogcHJpdmF0ZSB0dW5uZWwgcHRyIGluc3RlYWQuCisJCSAqLworCQl0dW5uZWwgPSBzZXNz aW9uLT50dW5uZWw7CisJCWlmICh0dW5uZWwgIT0gTlVMTCkgeworCQkJaWYgKHR1bm5lbC0+bWFn aWMgIT0gTDJUUF9UVU5ORUxfTUFHSUMpIHsKKwkJCQlwcmludGsoS0VSTl9FUlIgIiVzOiAlczol ZDogQkFEIFRVTk5FTCBNQUdJQyAiCisJCQkJICAgICAgICIoIHR1bm5lbD0lcCBtYWdpYz0leCAp XG4iLAorCQkJCSAgICAgICBfX0ZVTkNUSU9OX18sIF9fRklMRV9fLCBfX0xJTkVfXywgCisJCQkJ ICAgICAgIHR1bm5lbCwgdHVubmVsLT5tYWdpYyk7CisJCQkJZ290byBvdXQ7CisJCQl9CisJCX0K KworCQkvKiBEZWxldGUgdHVubmVsIGNvbnRleHQgaWYgdGhpcyB3YXMgdGhlIGxhc3Qgc2Vzc2lv biBvbiB0aGUKKwkJICogdHVubmVsLiAgVGhpcyB3YXMgYWxsb2NhdGVkIHdoZW4gdGhlIGZpcnN0 IHNlc3Npb24gd2FzCisJCSAqIGNyZWF0ZWQgb24gdGhlIHR1bm5lbC4gU2VlCisJCSAqIHBwcG9s MnRwX3ByZXBhcmVfdHVubmVsX3NvY2tldCgpLgorCQkgKi8KKwkJRFBSSU5USyh0dW5uZWwtPmRl YnVnLCAiJXM6IHNlc3Npb25fY291bnQ9JWRcbiIsIAorCQkJdHVubmVsLT5uYW1lLCBhdG9taWNf cmVhZCgmdHVubmVsLT5zZXNzaW9uX2NvdW50KSk7CisJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0 KCZ0dW5uZWwtPnNlc3Npb25fY291bnQpKSB7CisJCQlwcHBvbDJ0cF90dW5uZWxfZnJlZSh0dW5u ZWwpOworCQl9CisJfQorCisJaWYgKHBvKQorCQlrZnJlZShwbyk7CisKKwlpZiAoc2Vzc2lvbiAh PSBOVUxMKQorCQlrZnJlZShzZXNzaW9uKTsKKworb3V0OgorCUVYSVRfRlVOQ1RJT047Cit9CisK Ky8qIENhbGxlZCB3aGVuIHRoZSBQUFBvWCBzb2NrZXQgKHNlc3Npb24pIGlzIGNsb3NlZC4KKyAq Lworc3RhdGljIGludCBwcHBvbDJ0cF9yZWxlYXNlKHN0cnVjdCBzb2NrZXQgKnNvY2spCit7CisJ c3RydWN0IHNvY2sgKnNrID0gc29jay0+c2s7CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNl c3Npb24gPSBOVUxMOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbDsKKwlpbnQgZXJy b3IgPSAwOworCUVOVEVSX0ZVTkNUSU9OOworCisJaWYgKCFzaykKKwkJcmV0dXJuIDA7CisKKwlp ZiAoc29ja19mbGFnKHNrLCBTT0NLX0RFQUQpICE9IDApCisJCXJldHVybiAtRUJBREY7CisKKwlE UFJJTlRLKC0xLCAiJXM6LCBzaz0lcCAoJXApLCByZWZjbnQ9JXVcbiIsIF9fRlVOQ1RJT05fXywg CisJCXNrLCBzay0+c2tfb3duZXIsIG1vZHVsZV9yZWZjb3VudChUSElTX01PRFVMRSkpOworCisJ aWYgKHNrLT5za191c2VyX2RhdGEpIHsJICAgIC8qIFdhcyB0aGlzIHNvY2tldCBhY3R1YWxseSBj b25uZWN0ZWQ/ICovCisJCVNPQ0tfMl9TRVNTSU9OKHNrLCBzZXNzaW9uLCBlcnJvciwgLUVCQURG LCBlbmQsIDApOworCisJCS8qIERvbid0IHVzZSBTT0NLXzJfVFVOTkVMKCkgaGVyZSB0byBnZXQg dGhlIHR1bm5lbCBjb250ZXh0CisJCSAqIGJlY2F1c2UgdGhlIHR1bm5lbCBzb2NrZXQgbWlnaHQg aGF2ZSBhbHJlYWR5IGJlZW4gY2xvc2VkCisJCSAqIChpdHMgc2stPnNrX3VzZXJfZGF0YSB3aWxs IGJlIE5VTEwpIHNvIHVzZSB0aGUgc2Vzc2lvbidzCisJCSAqIHByaXZhdGUgdHVubmVsIHB0ciBp bnN0ZWFkLgorCQkgKi8KKwkJdHVubmVsID0gc2Vzc2lvbi0+dHVubmVsOworCQlpZiAodHVubmVs ICE9IE5VTEwpIHsKKwkJCWlmICh0dW5uZWwtPm1hZ2ljID09IEwyVFBfVFVOTkVMX01BR0lDKSB7 CisJCQkJLyogRGVsZXRlIHRoZSBzZXNzaW9uIHNvY2tldCBmcm9tIHRoZSBoYXNoICovCisJCQkJ ZGVsZXRlX2l0ZW0odHVubmVsLCAKKwkJCQkJICAgIHNlc3Npb24tPnR1bm5lbF9hZGRyLnNfdHVu bmVsLCAKKwkJCQkJICAgIHNlc3Npb24tPnR1bm5lbF9hZGRyLnNfc2Vzc2lvbik7CisJCQl9IGVs c2UgeworCQkJCXByaW50ayhLRVJOX0VSUiAiJXM6ICVzOiVkOiBCQUQgVFVOTkVMIE1BR0lDICIK KwkJCQkgICAgICAgIiggdHVubmVsPSVwIG1hZ2ljPSV4IClcbiIsCisJCQkJICAgICAgIF9fRlVO Q1RJT05fXywgX19GSUxFX18sIF9fTElORV9fLCAKKwkJCQkgICAgICAgdHVubmVsLCB0dW5uZWwt Pm1hZ2ljKTsKKwkJCQlnb3RvIGVuZDsKKwkJCX0KKwkJfQorCX0KKworCWlmIChzay0+c2tfc3Rh dGUgJiAoUFBQT1hfQ09OTkVDVEVEIHwgUFBQT1hfQk9VTkQpKQorCQlwcHBveF91bmJpbmRfc29j ayhzayk7CisKKwkvKiBTaWduYWwgdGhlIGRlYXRoIG9mIHRoZSBzb2NrZXQuICovCisJc2stPnNr X3N0YXRlID0gUFBQT1hfREVBRDsKKwlzb2NrX29ycGhhbihzayk7CisJc29jay0+c2sgPSBOVUxM OworCisJLyogUHVyZ2UgYW55IHF1ZXVlZCBkYXRhICovCisJc2tiX3F1ZXVlX3B1cmdlKCZzay0+ c2tfcmVjZWl2ZV9xdWV1ZSk7CisJc2tiX3F1ZXVlX3B1cmdlKCZzay0+c2tfd3JpdGVfcXVldWUp OworCisJaWYgKHNlc3Npb24gIT0gTlVMTCkKKwkJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgImNh bGxpbmcgc29ja19wdXQ7IHJlZmNudD0lZFxuIiwgCisJCQlzZXNzaW9uLT5zb2NrLT5za19yZWZj bnQuY291bnRlcik7CisJc29ja19wdXQoc2spOworCitlbmQ6CisJRVhJVF9GVU5DVElPTjsKKwly ZXR1cm4gZXJyb3I7Cit9CisKKy8qIEludGVybmFsIGZ1bmN0aW9uIHRvIHByZXBhcmUgYSB0dW5u ZWwgKFVEUCkgc29ja2V0IHRvIGhhdmUgUFBQb1ggc29ja2V0cworICogYXR0YWNoZWQgdG8gaXQK KyAqLworc3RhdGljIHN0cnVjdCBzb2NrICpwcHBvbDJ0cF9wcmVwYXJlX3R1bm5lbF9zb2NrZXQo aW50IGZkLCB1MTYgdHVubmVsX2lkLCAKKwkJCQkJCSAgIGludCAqZXJyb3IpCit7CisJaW50IGVy cjsKKwlzdHJ1Y3Qgc29ja2V0ICpzb2NrID0gTlVMTDsKKwlzdHJ1Y3Qgc29jayAqc2s7CisJc3Ry dWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCXN0cnVjdCBzb2NrICpyZXQgPSBOVUxMOwor CisJRU5URVJfRlVOQ1RJT047CisJCisJLyogR2V0IHRoZSBzb2NrZXQgZnJvbSB0aGUgZmQgKi8K KwllcnIgPSAtRUJBREY7CisJc29jayA9IHNvY2tmZF9sb29rdXAoZmQsICZlcnIpOworCWlmICgh c29jaykgeworCQlQUklOVEsoLTEsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0VSUiwgCisJ CSAgICAgICAidHVubCAlaHU6IHNvY2tmZF9sb29rdXAoZmQ9JWQpIHJldHVybmVkICVkXG4iLCAK KwkJICAgICAgIHR1bm5lbF9pZCwgZmQsIGVycik7CisJCWdvdG8gZXJyOworCX0KKworCS8qIFF1 aWNrIHNhbml0eSBjaGVja3MgKi8KKwllcnIgPSAtRVNPQ0tUTk9TVVBQT1JUOworCWlmIChzb2Nr LT50eXBlICE9IFNPQ0tfREdSQU0pIHsKKwkJUFJJTlRLKC0xLCBQUFBPTDJUUF9NU0dfQ09OVFJP TCwgS0VSTl9FUlIsIAorCQkgICAgICAgInR1bmwgJWh1OiBmZCAlZCB3cm9uZyB0eXBlLCBnb3Qg JWQsIGV4cGVjdGVkICVkXG4iLCAKKwkJICAgICAgIHR1bm5lbF9pZCwgZmQsIHNvY2stPnR5cGUs IFNPQ0tfREdSQU0pOworCQlnb3RvIGVycjsKKwl9CisJZXJyID0gLUVBRk5PU1VQUE9SVDsKKwlp ZiAoc29jay0+b3BzLT5mYW1pbHkhPUFGX0lORVQpIHsKKwkJUFJJTlRLKC0xLCBQUFBPTDJUUF9N U0dfQ09OVFJPTCwgS0VSTl9FUlIsIAorCQkgICAgICAgInR1bmwgJWh1OiBmZCAlZCB3cm9uZyBm YW1pbHksIGdvdCAlZCwgZXhwZWN0ZWQgJWRcbiIsIAorCQkgICAgICAgdHVubmVsX2lkLCBmZCwg c29jay0+b3BzLT5mYW1pbHksIEFGX0lORVQpOworCQlnb3RvIGVycjsKKwl9CisKKwllcnIgPSAt RU5PVENPTk47CisJc2sgPSBzb2NrLT5zazsKKwkKKwkvKiBDaGVjayBpZiB0aGlzIHNvY2tldCBo YXMgYWxyZWFkeSBiZWVuIHByZXBwZWQgKi8KKwl0dW5uZWwgPSAoc3RydWN0IHBwcG9sMnRwX3R1 bm5lbCAqKXNrLT5za191c2VyX2RhdGE7CisJaWYgKHR1bm5lbCAhPSBOVUxMKSB7CisJCS8qIFVz ZXItZGF0YSBmaWVsZCBhbHJlYWR5IHNldCAqLworCQllcnIgPSAtRUJVU1k7CisJCWlmICh0dW5u ZWwtPm1hZ2ljICE9IEwyVFBfVFVOTkVMX01BR0lDKSB7CisJCQlwcmludGsoS0VSTl9FUlIgIiVz OiAlczolZDogQkFEIFRVTk5FTCBNQUdJQyAiCisJCQkgICAgICAgIiggdHVubmVsPSVwIG1hZ2lj PSV4IClcbiIsCisJCQkgICAgICAgX19GVU5DVElPTl9fLCBfX0ZJTEVfXywgX19MSU5FX18sIAor CQkJICAgICAgIHR1bm5lbCwgdHVubmVsLT5tYWdpYyk7CisJCQlnb3RvIGVycjsKKwkJfQorCisJ CS8qIFRoaXMgc29ja2V0IGhhcyBhbHJlYWR5IGJlZW4gcHJlcHBlZCAqLworCQlyZXQgPSB0dW5u ZWwtPnNvY2s7CisJCWdvdG8gb3V0OworCX0KKworCS8qIFRoaXMgc29ja2V0IGlzIGF2YWlsYWJs ZSBhbmQgbmVlZHMgcHJlcHBpbmcuIENyZWF0ZSBhbmV3IHR1bm5lbAorCSAqIGNvbnRleHQgYW5k IGluaXQgaXQuCisJICovCisJc2stPnNrX3VzZXJfZGF0YSA9IHR1bm5lbCA9IGttYWxsb2Moc2l6 ZW9mKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwpLCBHRlBfS0VSTkVMKTsKKwlpZiAoc2stPnNrX3Vz ZXJfZGF0YSA9PSBOVUxMKSB7CisJCWVyciA9IC1FTk9NRU07CisJCWdvdG8gZXJyOworCX0KKwor CURQUklOVEsoLTEsICJ0dW5sICVodTogYWxsb2NhdGVkIHR1bm5lbD0lcCwgc2s9JXAsIHNvY2s9 JXBcbiIsIAorCQl0dW5uZWxfaWQsIHR1bm5lbCwgc2ssIHNvY2spOworCisJbWVtc2V0KHR1bm5l bCwgMCwgc2l6ZW9mKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwpKTsKKwkKKwl0dW5uZWwtPm1hZ2lj ID0gTDJUUF9UVU5ORUxfTUFHSUM7CisJc3ByaW50ZigmdHVubmVsLT5uYW1lWzBdLCAidHVubCAl aHUiLCB0dW5uZWxfaWQpOworCisJdHVubmVsLT5zdGF0cy50dW5uZWxfaWQgPSB0dW5uZWxfaWQ7 CisKKwl0dW5uZWwtPmRlYnVnID0gUFBQT0wyVFBfREVGQVVMVF9ERUJVR19GTEFHUzsKKworCS8q IFNldHVwIHRoZSBuZXcgcHJvdG9jb2wgc3R1ZmYgKi8KKwl0dW5uZWwtPm9sZF9wcm90byAgPSAq c2stPnNrX3Byb3Q7CisJdHVubmVsLT5sMnRwX3Byb3RvID0gKnNrLT5za19wcm90OworCQorCXNr LT5za19wcm90ID0gJnR1bm5lbC0+bDJ0cF9wcm90bzsKKwkKKwl0dW5uZWwtPm9sZF9kYXRhX3Jl YWR5ID0gc2stPnNrX2RhdGFfcmVhZHk7CisJc2stPnNrX2RhdGFfcmVhZHkJICAgICAgID0gJnBw cG9sMnRwX2RhdGFfcmVhZHk7CisKKwl0dW5uZWwtPm9sZF9za19kZXN0cnVjdCA9IHNrLT5za19k ZXN0cnVjdDsKKwlzay0+c2tfZGVzdHJ1Y3QJCT0gJnBwcG9sMnRwX3R1bm5lbF9kZXN0cnVjdDsK KworCXR1bm5lbC0+c29jayAgID0gc2s7CisJc2stPnNrX2FsbG9jYXRpb24gPSBHRlBfQVRPTUlD OworCisJLyogQWRkIHR1bm5lbCB0byBvdXIgbGlzdCAqLworCXR1bm5lbC0+bmV4dAkgICAgID0g cHBwb2wydHBfdHVubmVsX2xpc3Q7CisJcHBwb2wydHBfdHVubmVsX2xpc3QgPSB0dW5uZWw7CisJ CisJcmV0ID0gdHVubmVsLT5zb2NrOworCQorCSplcnJvciA9IDA7CitvdXQ6CisJaWYgKHNvY2sp CisJCXNvY2tmZF9wdXQoc29jayk7CisJRVhJVF9GVU5DVElPTjsKKworCXJldHVybiByZXQ7CisK K2VycjoKKwkqZXJyb3IgPSBlcnI7CisJZ290byBvdXQ7Cit9CisKKy8qIHNvY2tldCgpIGhhbmRs ZXIuIEluaXRpYWxpemUgYSBuZXcgc3RydWN0IHNvY2suCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wy dHBfY3JlYXRlKHN0cnVjdCBzb2NrZXQgKnNvY2spCit7CisJaW50IGVycm9yID0gMDsKKwlzdHJ1 Y3Qgc29jayAqc2s7CisJc3RydWN0IHBwcG94X29wdCAqcG87CisKKwlFTlRFUl9GVU5DVElPTjsK KwlEUFJJTlRLKC0xLCAic29jaz0lcFxuIiwgc29jayk7CisKKwlzayA9IHNrX2FsbG9jKFBGX1BQ UE9YLCBHRlBfS0VSTkVMLCAxLCBOVUxMKTsKKwlpZiAoIXNrKQorCQlyZXR1cm4gLUVOT01FTTsK KwlEUFJJTlRLKC0xLCAic2tfYWxsb2MsIHNrPSVwXG4iLCBzayk7CisKKwlzb2NrX2luaXRfZGF0 YShzb2NrLCBzayk7CisJRFBSSU5USygtMSwgInNrX3NldF9vd25lciwgc2s9JXAgKCVwKSwgcmVm Y250PSV1XG4iLCAKKwkJc2ssIHNrLT5za19vd25lciwgbW9kdWxlX3JlZmNvdW50KFRISVNfTU9E VUxFKSk7CisKKwkvKiBGSVhNRTogTm90IHN1cmUgd2h5IHRoZSBtb2R1bGUgdXNlIGNvdW50ZXIg aXMgemVybyB3aGVuIHdlCisJICogZ2V0IGhlcmUuICBTaW1pbGFyIHNvY2tldCBjb2RlIGRvZXNu J3Qgc2VlbSB0byBidW1wIGl0cworCSAqIG1vZHVsZSB1c2UgY291bnQgYmVmb3JlIGNhbGxpbmcg c2tfc2V0X293bmVyKCksIHNvIHdoeQorCSAqIHBwcG9sMnRwPworCSAqLworCWlmICh0cnlfbW9k dWxlX2dldChUSElTX01PRFVMRSkpIHsKKwkJc2tfc2V0X293bmVyKHNrLCBUSElTX01PRFVMRSk7 CisJCW1vZHVsZV9wdXQoVEhJU19NT0RVTEUpOworCX0KKworCXNvY2stPnN0YXRlICA9IFNTX1VO Q09OTkVDVEVEOworCXNvY2stPm9wcyAgICA9ICZwcHBvbDJ0cF9vcHM7CisKKwlzay0+c2tfYmFj a2xvZ19yY3YgPSBwcHBvbDJ0cF9yZWN2X2NvcmU7CisJc2stPnNrX3Byb3RvY29sICAgID0gUFhf UFJPVE9fT0wyVFA7CisJc2stPnNrX2ZhbWlseSAgICAgID0gUEZfUFBQT1g7CisJc2stPnNrX3N0 YXRlICAgICAgID0gUFBQT1hfTk9ORTsKKwlzay0+c2tfdHlwZSAgICAgICAgPSBTT0NLX1NUUkVB TTsKKwlzay0+c2tfZGVzdHJ1Y3QgICAgPSBwcHBvbDJ0cF9zZXNzaW9uX2Rlc3RydWN0OworCisJ cG8gPSBzay0+c2tfcHJvdGluZm8gPSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgcHBwb3hfb3B0KSwg R0ZQX0tFUk5FTCk7CisJaWYgKCFwbykgeworCQllcnJvciA9IC1FTk9NRU07CisJCWdvdG8gZnJl ZV9zazsKKwl9CisKKwltZW1zZXQoKHZvaWQgKikgcG8sIDAsIHNpemVvZigqcG8pKTsKKwlwby0+ c2sgPSBzazsKKworCXNvY2stPnNrID0gc2s7CisKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiAw OworCitmcmVlX3NrOgorCXNrX2ZyZWUoc2spOworCUVYSVRfRlVOQ1RJT047CisJcmV0dXJuIGVy cm9yOworfQorCisvKiBjb25uZWN0KCkgaGFuZGxlci4uCUF0dGFjaCBhIFBQUG9YIHNvY2tldCB0 byBhIHR1bm5lbCBVRFAgc29ja2V0CisgKi8KK2ludCBwcHBvbDJ0cF9jb25uZWN0KHN0cnVjdCBz b2NrZXQgKnNvY2ssIHN0cnVjdCBzb2NrYWRkciAqdXNlcnZhZGRyLAorCQkgICAgIGludCBzb2Nr YWRkcl9sZW4sIGludCBmbGFncykKK3sKKwlzdHJ1Y3Qgc29jayAqc2sgPSBzb2NrLT5zazsKKwlz dHJ1Y3Qgc29ja2FkZHJfcHBwb3ggKnNwID0gKHN0cnVjdCBzb2NrYWRkcl9wcHBveCAqKSB1c2Vy dmFkZHI7CisJc3RydWN0IHBwcG94X29wdCAqcG8gPSBwcHBveF9zayhzayk7CisJc3RydWN0IHNv Y2sgKnR1bm5lbF9zb2NrID0gTlVMTDsKKwlzdHJ1Y3QgcHBwb2wydHBfc2Vzc2lvbiAqc2Vzc2lv biA9IE5VTEw7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCXN0cnVjdCBkc3Rf ZW50cnkgKmRzdDsKKwlpbnQgZXJyb3IgPSAwOworCisJRU5URVJfRlVOQ1RJT047CisJCisJRFBS SU5USygtMSwgInNvY2s9JXAsIHVzZXJ2YWRkcj0lcCwgc29ja2FkZHJfbGVuPSVkLCBmbGFncz0l ZFxuIiwgCisJCXNvY2ssIHVzZXJ2YWRkciwgc29ja2FkZHJfbGVuLCBmbGFncyk7CisJbG9ja19z b2NrKHNrKTsKKworCWVycm9yID0gLUVJTlZBTDsKKwlpZiAoc3AtPnNhX3Byb3RvY29sICE9IFBY X1BST1RPX09MMlRQKQorCQlnb3RvIGVuZDsKKworCS8qIENoZWNrIGZvciBhbHJlYWR5IGJvdW5k IHNvY2tldHMgKi8KKwllcnJvciA9IC1FQlVTWTsKKwlpZiAoc2stPnNrX3N0YXRlICYgUFBQT1hf Q09OTkVDVEVEKQorCQlnb3RvIGVuZDsKKworCS8qIFdlIGRvbid0IHN1cHBvcnRpbmcgcmViaW5k aW5nIGFueXdheSAqLwkJCisJaWYgKHNrLT5za191c2VyX2RhdGEpCisJCWdvdG8gZW5kOyAvKiBz b2NrZXQgaXMgYWxyZWFkeSBhdHRhY2hlZCAqLworCisJLyogRG9uJ3QgYmluZCBpZiBzX3R1bm5l bCBpcyAwICovCisJZXJyb3IgPSAtRUlOVkFMOworCWlmIChzcC0+c2FfYWRkci5wcHBvbDJ0cC5z X3R1bm5lbCA9PSAwKQorCQlnb3RvIGVuZDsKKworCS8qIFRoaXMgbG9va3MgdXAgdGhlIHR1bm5l bCBzb2NrZXQgYW5kIGNvbmZpZ3VyZXMgaXQgaWYgbmVjZXNzYXJ5ICovCisJdHVubmVsX3NvY2sg PSAKKwkJcHBwb2wydHBfcHJlcGFyZV90dW5uZWxfc29ja2V0KHNwLT5zYV9hZGRyLnBwcG9sMnRw LmZkLCAKKwkJCQkJICAgICAgIHNwLT5zYV9hZGRyLnBwcG9sMnRwLnNfdHVubmVsLCAKKwkJCQkJ ICAgICAgICZlcnJvcik7CisJaWYgKHR1bm5lbF9zb2NrID09IE5VTEwpCisJCWdvdG8gZW5kOwor CXR1bm5lbCA9IHR1bm5lbF9zb2NrLT5za191c2VyX2RhdGE7CisKKwkvKiBBbGxvY2F0ZSBhbmQg aW5pdGlhbGl6ZSBhIG5ldyBzZXNzaW9uIGNvbnRleHQuCisJICovCisJc2Vzc2lvbiA9IGttYWxs b2Moc2l6ZW9mKHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uKSwgR0ZQX0tFUk5FTCk7CisJaWYgKHNl c3Npb24gPT0gTlVMTCkgeworCQllcnJvciA9IC1FTk9NRU07CisJCWdvdG8gZW5kOworCX0KKwor CW1lbXNldChzZXNzaW9uLCAwLCBzaXplb2Yoc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24pKTsKKwor CXNlc3Npb24tPm1hZ2ljCSAgICAgPSBMMlRQX1NFU1NJT05fTUFHSUM7CisJc2Vzc2lvbi0+b3du ZXIJICAgICA9IGN1cnJlbnQtPnBpZDsKKwlzZXNzaW9uLT5zb2NrCSAgICAgPSBzazsKKwlzZXNz aW9uLT50dW5uZWwJICAgICA9IHR1bm5lbDsKKwlzZXNzaW9uLT50dW5uZWxfc29jayA9IHR1bm5l bF9zb2NrOworCXNlc3Npb24tPnR1bm5lbF9hZGRyID0gc3AtPnNhX2FkZHIucHBwb2wydHA7CisJ c3ByaW50Zigmc2Vzc2lvbi0+bmFtZVswXSwgInNlc3MgJWh1LyVodSIsIAorCQlzZXNzaW9uLT50 dW5uZWxfYWRkci5zX3R1bm5lbCwgCisJCXNlc3Npb24tPnR1bm5lbF9hZGRyLnNfc2Vzc2lvbik7 CisKKwlzZXNzaW9uLT5zdGF0cy50dW5uZWxfaWQgID0gc2Vzc2lvbi0+dHVubmVsX2FkZHIuc190 dW5uZWw7CisJc2Vzc2lvbi0+c3RhdHMuc2Vzc2lvbl9pZCA9IHNlc3Npb24tPnR1bm5lbF9hZGRy LnNfc2Vzc2lvbjsKKwkKKwlzZXNzaW9uLT5kZWJ1ZyA9IFBQUE9MMlRQX0RFRkFVTFRfREVCVUdf RkxBR1M7CisKKwkvKiBEZWZhdWx0IE1UVSBtdXN0IGFsbG93IHNwYWNlIGZvciBVRFAvTDJUUC9Q UFAKKwkgKiBoZWFkZXJzLiBMZWF2ZSBzb21lIHNsYWNrLiAKKwkgKi8KKwlzZXNzaW9uLT5tdHUg PSBzZXNzaW9uLT5tcnUgPSAxNTAwIC0gUFBQT0wyVFBfSEVBREVSX09WRVJIRUFEOworCisJLyog SWYgUE1UVSBkaXNjb3Zlcnkgd2FzIGVuYWJsZWQsIHVzZSB0aGUgTVRVIHRoYXQgd2FzIGRpc2Nv dmVyZWQgKi8KKwlkc3QgPSBza19kc3RfZ2V0KHNrKTsKKwlpZiAoZHN0ICE9IE5VTEwpIHsKKwkJ dTMyIHBtdHUgPSBkc3RfcG10dShfX3NrX2RzdF9nZXQoc2spKTsKKwkJaWYgKHBtdHUgIT0gMCkg eworCQkJc2Vzc2lvbi0+bXR1ID0gc2Vzc2lvbi0+bXJ1ID0gcG10dSAtIAorCQkJCVBQUE9MMlRQ X0hFQURFUl9PVkVSSEVBRDsKKwkJCURQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIAorCQkJCSIlczog TVRVIHNldCBieSBQYXRoIE1UVSBkaXNjb3Zlcnk6IG10dT0lZFxuIiwKKwkJCQlzZXNzaW9uLT5u YW1lLCBzZXNzaW9uLT5tdHUpOworCQl9CisJCWRzdF9yZWxlYXNlKGRzdCk7CisJfQorCisJLyog U3BlY2lhbCBjYXNlOiBpZiBzb3VyY2UgJiBkZXN0IHNlc3Npb25faWQgPT0gMHgwMDAwLCB0aGlz IHNvY2tldCBpcworCSAqIGJlaW5nIGNyZWF0ZWQgdG8gbWFuYWdlIHRoZSB0dW5uZWwuIERvbid0 IGFkZCB0aGUgc2Vzc2lvbiB0byB0aGUKKwkgKiBzZXNzaW9uIGhhc2ggbGlzdCwganVzdCBzZXQg dXAgdGhlIGludGVybmFsIGNvbnRleHQgZm9yIHVzZSBieQorCSAqIGlvY3RsKCkgYW5kIHNvY2tv cHQoKSBoYW5kbGVycy4KKwkgKi8KKwlpZiAoKHNlc3Npb24tPnR1bm5lbF9hZGRyLnNfc2Vzc2lv biA9PSAwKSAmJgorCSAgICAoc2Vzc2lvbi0+dHVubmVsX2FkZHIuZF9zZXNzaW9uID09IDApKSB7 CisJCWVycm9yID0gMDsKKwkJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgCisJCQkidHVubCAlaHU6 IHNvY2tldCBjcmVhdGVkIGZvciB0dW5uZWwgbWdtdCBvcHNcbiIsIAorCQkJc2Vzc2lvbi0+dHVu bmVsX2FkZHIuc190dW5uZWwpOworCQlzay0+c2tfdXNlcl9kYXRhID0gc2Vzc2lvbjsKKwkJZ290 byBvdXRfbm9fcHBwOworCX0KKworCURQUklOVEsoLTEsICIlczogYWxsb2NhdGVkIHNlc3Npb249 JXAsIHNvY2s9JXAsIG93bmVyPSVkXG4iLCAKKwkJc2Vzc2lvbi0+bmFtZSwgc2Vzc2lvbiwgc2ss IHNlc3Npb24tPm93bmVyKTsKKworCS8qIEFkZCBzZXNzaW9uIHRvIHRoZSB0dW5uZWwncyBoYXNo IGxpc3QgKi8KKwlTT0NLXzJfVFVOTkVMKHR1bm5lbF9zb2NrLCB0dW5uZWwsIGVycm9yLCAtRUJB REYsIGVuZCwgMCk7CisJaWYgKHNldF9pdGVtKHR1bm5lbCwgc2Vzc2lvbikpIHsKKwkJa2ZyZWUo c2Vzc2lvbik7CisJCWVycm9yID0gLUVBTFJFQURZOworCQlnb3RvIGVuZDsKKwl9CisJCisJLyog VGhpcyBpcyBob3cgd2UgZ2V0IHRoZSBzZXNzaW9uIGNvbnRleHQgZnJvbSB0aGUgc29ja2V0LiAq LworCXNrLT5za191c2VyX2RhdGEgPSBzZXNzaW9uOworCQkKKwkvKiBXZSBkb24ndCBzdG9yZSBh bnkgbW9yZSBvcHRpb25zIGluIHRoZSBwcHBveF9vcHQsIGV2ZXJ5dGhpbmcgaXMgaW4KKwkgKiB1 c2VyX2RhdGEgKHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uKQorCSAqLworCXBvLT5zayA9IHNrOwor CisJLyogUmlnaHQgbm93LCBiZWNhdXNlIHdlIGRvbid0IGhhdmUgYSB3YXkgdG8gcHVzaCB0aGUg aW5jb21pbmcgc2tiJ3MKKwkgKiBzdHJhaWdodCB0aHJvdWdoIHRoZSBVRFAgbGF5ZXIsIHRoZSBv bmx5IGhlYWRlciB3ZSBuZWVkIHRvIHdvcnJ5CisJICogYWJvdXQgaXMgdGhlIEwyVFAgaGVhZGVy LiBUaGlzIHNpemUgaXMgZGlmZmVyZW50IGRlcGVuZGluZyBvbgorCSAqIHdoZXRoZXIgc2VxdWVu Y2UgbnVtYmVycyBhcmUgZW5hYmxlZCBmb3IgdGhlIGRhdGEgY2hhbm5lbC4KKwkgKi8KKwlwby0+ Y2hhbi5oZHJsZW4gPSBQUFBPTDJUUF9MMlRQX0hEUl9TSVpFX05PU0VROworCisJcG8tPmNoYW4u cHJpdmF0ZSA9IHNrOworCXBvLT5jaGFuLm9wcwkgPSAmcHBwb2wydHBfY2hhbl9vcHM7CisKKwll cnJvciA9IHBwcF9yZWdpc3Rlcl9jaGFubmVsKCZwby0+Y2hhbik7CisJaWYgKGVycm9yKQorCQln b3RvIGVuZDsKKworb3V0X25vX3BwcDoKKwlhdG9taWNfaW5jKCZ0dW5uZWwtPnNlc3Npb25fY291 bnQpOworCXNrLT5za19zdGF0ZSA9IFBQUE9YX0NPTk5FQ1RFRDsKKwlQUklOVEsoc2Vzc2lvbi0+ ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCSAgICAgICAiJXM6IGNy ZWF0ZWRcbiIsIHNlc3Npb24tPm5hbWUpOworCitlbmQ6CisJcmVsZWFzZV9zb2NrKHNrKTsKKwor CWlmIChlcnJvciAhPSAwKQorCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19D T05UUk9MLCBLRVJOX1dBUk5JTkcsIAorCQkgICAgICAgIiVzOiBjb25uZWN0IGZhaWxlZDogJWRc biIsIHNlc3Npb24tPm5hbWUsIGVycm9yKTsKKworCUVYSVRfRlVOQ1RJT047CisKKwlyZXR1cm4g ZXJyb3I7Cit9CisKKy8qIGdldG5hbWUoKSBzdXBwb3J0LgorICovCitzdGF0aWMgaW50IHBwcG9s MnRwX2dldG5hbWUoc3RydWN0IHNvY2tldCAqc29jaywgc3RydWN0IHNvY2thZGRyICp1YWRkciwK KwkJCSAgICBpbnQgKnVzb2NrYWRkcl9sZW4sIGludCBwZWVyKQoreworCWludCBsZW4gPSBzaXpl b2Yoc3RydWN0IHNvY2thZGRyX3BwcG94KTsKKwlzdHJ1Y3Qgc29ja2FkZHJfcHBwb3ggc3A7CisJ aW50IGVycm9yID0gMDsKKwlzdHJ1Y3QgcHBwb2wydHBfc2Vzc2lvbiAqc2Vzc2lvbjsKKworCUVO VEVSX0ZVTkNUSU9OOworCQorCWVycm9yID0gLUVOT1RDT05OOworCWlmIChzb2NrLT5zay0+c2tf c3RhdGUgIT0gUFBQT1hfQ09OTkVDVEVEKQorCQlnb3RvIGVuZDsKKwkKKwlTT0NLXzJfU0VTU0lP Tihzb2NrLT5zaywgc2Vzc2lvbiwgZXJyb3IsIC1FQkFERiwgZW5kLCAwKTsKKwkKKwlzcC5zYV9m YW1pbHkJPSBBRl9QUFBPWDsKKwlzcC5zYV9wcm90b2NvbAk9IFBYX1BST1RPX09MMlRQOworCW1l bWNweSgmc3Auc2FfYWRkci5wcHBvbDJ0cCwgJnNlc3Npb24tPnR1bm5lbF9hZGRyLAorCSAgICAg ICBzaXplb2Yoc3RydWN0IHBwcG9sMnRwX2FkZHIpKTsKKworCW1lbWNweSh1YWRkciwgJnNwLCBs ZW4pOworCisJKnVzb2NrYWRkcl9sZW4gPSBsZW47CisKKwllcnJvciA9IDA7CitlbmQ6CisJRVhJ VF9GVU5DVElPTjsKKwlyZXR1cm4gZXJyb3I7Cit9CisKKy8qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisg KiBpb2N0bCgpIGhhbmRsZXJzLgorICoKKyAqIFRoZSBQUFBvWCBzb2NrZXQgaXMgY3JlYXRlZCBm b3IgTDJUUCBzZXNzaW9uczogdHVubmVscyBoYXZlIHRoZWlyIG93biBVRFAKKyAqIHNvY2tldHMu IEhvd2V2ZXIsIGluIG9yZGVyIHRvIGNvbnRyb2wga2VybmVsIHR1bm5lbCBmZWF0dXJlcywgd2Ug YWxsb3cKKyAqIHVzZXJzcGFjZSB0byBjcmVhdGUgYSBzcGVjaWFsICJ0dW5uZWwiIFBQUG9YIHNv Y2tldCB3aGljaCBpcyB1c2VkIGZvcgorICogY29udHJvbCBvbmx5LiAgVHVubmVsIFBQUG9YIHNv Y2tldHMgaGF2ZSBzZXNzaW9uX2lkID09IDAgYW5kIHNpbXBseSBhbGxvdworICogdGhlIHVzZXIg YXBwbGljYXRpb24gdG8gaXNzdWUgTDJUUCBzZXRzb2Nrb3B0KCksIGdldHNvY2tvcHQoKSBhbmQg aW9jdGwoKQorICogY2FsbHMuCisgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKworLyogU2Vzc2lvbiBp b2N0bCBoZWxwZXIuCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wydHBfc2Vzc2lvbl9pb2N0bChzdHJ1 Y3QgcHBwb2wydHBfc2Vzc2lvbiAqc2Vzc2lvbiwgCisJCQkJICB1bnNpZ25lZCBpbnQgY21kLCB1 bnNpZ25lZCBsb25nIGFyZykKK3sKKwlzdHJ1Y3QgaWZyZXEgaWZyOworCWludCBlcnIgPSAwOwor CXN0cnVjdCBzb2NrICpzayA9IHNlc3Npb24tPnNvY2s7CisJaW50IHZhbCA9IChpbnQpIGFyZzsK KworCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fREVC VUcsIAorCSAgICAgICAiJXM6IHBwcG9sMnRwX3Nlc3Npb25faW9jdGwoY21kPSUjeCwgYXJnPSUj bHgpXG4iLCAKKwkgICAgICAgc2Vzc2lvbi0+bmFtZSwgY21kLCBhcmcpOworCQorCXN3aXRjaCAo Y21kKSB7CisJY2FzZSBTSU9DR0lGTVRVOgorCQllcnIgPSAtRU5YSU87CisJCWlmICghKHNrLT5z a19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpCisJCQlicmVhazsKKworCQllcnIgPSAtRUZBVUxU OworCQlpZiAoY29weV9mcm9tX3VzZXIoJmlmciwgKHZvaWQgX191c2VyICopIGFyZywgc2l6ZW9m KHN0cnVjdCBpZnJlcSkpKQorCQkJYnJlYWs7CisJCWlmci5pZnJfbXR1ID0gc2Vzc2lvbi0+bXR1 OworCQlpZiAoY29weV90b191c2VyKCh2b2lkIF9fdXNlciAqKSBhcmcsICZpZnIsIHNpemVvZihz dHJ1Y3QgaWZyZXEpKSkKKwkJCWJyZWFrOworCisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQ T0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCBtdHU9JWRc biIsIHNlc3Npb24tPm5hbWUsIHNlc3Npb24tPm10dSk7CisJCWVyciA9IDA7CisJCWJyZWFrOwor CisJY2FzZSBTSU9DU0lGTVRVOgorCQllcnIgPSAtRU5YSU87CisJCWlmICghKHNrLT5za19zdGF0 ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpCisJCQlicmVhazsKKworCQllcnIgPSAtRUZBVUxUOworCQlp ZiAoY29weV9mcm9tX3VzZXIoJmlmciwgKHZvaWQgX191c2VyICopIGFyZywgc2l6ZW9mKHN0cnVj dCBpZnJlcSkpKQorCQkJYnJlYWs7CisKKwkJc2Vzc2lvbi0+bXR1ID0gaWZyLmlmcl9tdHU7Cis7 CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5G TywgCisJCSAgICAgICAiJXM6IHNldCBtdHU9JWRcbiIsIHNlc3Npb24tPm5hbWUsIHNlc3Npb24t Pm10dSk7CisJCWVyciA9IDA7CisJCWJyZWFrOworCisJY2FzZSBQUFBJT0NHTVJVOgorCQllcnIg PSAtRU5YSU87CisJCWlmICghKHNrLT5za19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpCisJCQli cmVhazsKKworCQllcnIgPSAtRUZBVUxUOworCQlpZiAocHV0X3VzZXIoc2Vzc2lvbi0+bXJ1LCAo aW50IF9fdXNlciAqKSBhcmcpKQorCQkJYnJlYWs7CisKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVn LCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogZ2V0IG1y dT0lZFxuIiwgc2Vzc2lvbi0+bmFtZSwgc2Vzc2lvbi0+bXJ1KTsKKwkJZXJyID0gMDsKKwkJYnJl YWs7CisKKwljYXNlIFBQUElPQ1NNUlU6CisJCWVyciA9IC1FTlhJTzsKKwkJaWYgKCEoc2stPnNr X3N0YXRlICYgUFBQT1hfQ09OTkVDVEVEKSkKKwkJCWJyZWFrOworCisJCWVyciA9IC1FRkFVTFQ7 CisJCWlmIChnZXRfdXNlcih2YWwsKGludCBfX3VzZXIgKikgYXJnKSkKKwkJCWJyZWFrOworCisJ CXNlc3Npb24tPm1ydSA9IHZhbDsKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9N U0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogc2V0IG1ydT0lZFxuIiwgc2Vz c2lvbi0+bmFtZSwgc2Vzc2lvbi0+bXJ1KTsKKwkJZXJyID0gMDsKKwkJYnJlYWs7CisKKwljYXNl IFBQUElPQ0dGTEFHUzoKKwkJZXJyID0gLUVGQVVMVDsKKwkJaWYgKHB1dF91c2VyKHNlc3Npb24t PmZsYWdzLCAoaW50IF9fdXNlciAqKSBhcmcpKQorCQkJYnJlYWs7CisKKwkJUFJJTlRLKHNlc3Np b24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIl czogZ2V0IGZsYWdzPSVkXG4iLCBzZXNzaW9uLT5uYW1lLCBzZXNzaW9uLT5mbGFncyk7CisJCWVy ciA9IDA7CisJCWJyZWFrOworCisJY2FzZSBQUFBJT0NTRkxBR1M6CisJCWVyciA9IC1FRkFVTFQ7 CisJCWlmIChnZXRfdXNlcih2YWwsIChpbnQgX191c2VyICopIGFyZykpCisJCQlicmVhazsKKwkJ c2Vzc2lvbi0+ZmxhZ3MgPSB2YWw7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBf TVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IHNldCBmbGFncz0lZFxuIiwg c2Vzc2lvbi0+bmFtZSwgc2Vzc2lvbi0+ZmxhZ3MpOworCQllcnIgPSAwOworCQlicmVhazsKKwor CWNhc2UgUFBQSU9DR0wyVFBTVEFUUzoKKwkJZXJyID0gLUVOWElPOworCisJCWlmICghKHNrLT5z a19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpCisJCQlicmVhazsKKworCQlpZiAoY29weV90b191 c2VyKCh2b2lkIF9fdXNlciAqKSBhcmcsICZzZXNzaW9uLT5zdGF0cywgCisJCQkJIHNpemVvZihz ZXNzaW9uLT5zdGF0cykpKQorCQkJYnJlYWs7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQ T0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCBMMlRQIHN0 YXRzXG4iLCBzZXNzaW9uLT5uYW1lKTsKKwkJZXJyID0gMDsKKwkJYnJlYWs7CisKKwlkZWZhdWx0 OgorCQllcnIgPSAtRU5PU1lTOworCQlicmVhazsKKwl9CisKKwlyZXR1cm4gZXJyOworfQorCisv KiBUdW5uZWwgaW9jdGwgaGVscGVyLgorICoKKyAqIE5vdGUgdGhlIHNwZWNpYWwgaGFuZGxpbmcg Zm9yIFBQUElPQ0dMMlRQU1RBVFMgYmVsb3cuIElmIHRoZSBpb2N0bCBkYXRhCisgKiBzcGVjaWZp ZXMgYSBzZXNzaW9uX2lkLCB0aGUgc2Vzc2lvbiBpb2N0bCBoYW5kbGVyIGlzIGNhbGxlZC4gVGhp cyBhbGxvd3MgYW4KKyAqIGFwcGxpY2F0aW9uIHRvIHJldHJpZXZlIHNlc3Npb24gc3RhdHMgdmlh IGEgdHVubmVsIHNvY2tldC4KKyAqLworc3RhdGljIGludCBwcHBvbDJ0cF90dW5uZWxfaW9jdGwo c3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsLCAKKwkJCQkgdW5zaWduZWQgaW50IGNtZCwg dW5zaWduZWQgbG9uZyBhcmcpCit7CisJaW50IGVyciA9IDA7CisJc3RydWN0IHNvY2sgKnNrID0g dHVubmVsLT5zb2NrOworCXN0cnVjdCBwcHBvbDJ0cF9pb2Nfc3RhdHMgc3RhdHNfcmVxOworCisJ UFJJTlRLKHR1bm5lbC0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0RFQlVHLCAK KwkgICAgICAgIiVzOiBwcHBvbDJ0cF90dW5uZWxfaW9jdGwoY21kPSUjeCwgYXJnPSUjbHgpXG4i LCB0dW5uZWwtPm5hbWUsIAorCSAgICAgICBjbWQsIGFyZyk7CisKKwlzd2l0Y2ggKGNtZCkgewor CWNhc2UgUFBQSU9DR0wyVFBTVEFUUzoKKwkJZXJyID0gLUVOWElPOworCisJCWlmICghKHNrLT5z a19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpCisJCQlicmVhazsKKworCQlpZiAoY29weV9mcm9t X3VzZXIoJnN0YXRzX3JlcSwgKHZvaWQgX191c2VyICopIGFyZywgCisJCQkJICAgc2l6ZW9mKHN0 YXRzX3JlcSkpKSB7CisJCQllcnIgPSAtRUZBVUxUOworCQkJYnJlYWs7CisJCX0KKwkJaWYgKHN0 YXRzX3JlcS5zZXNzaW9uX2lkICE9IDApIHsKKwkJCS8qIHJlc2VuZCB0byBzZXNzaW9uIGlvY3Rs IGhhbmRsZXIgKi8KKwkJCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uID0gCisJCQkJ Z2V0X2l0ZW0odHVubmVsLCBzdGF0c19yZXEudHVubmVsX2lkLCAKKwkJCQkJIHN0YXRzX3JlcS5z ZXNzaW9uX2lkKTsKKwkJCWlmIChzZXNzaW9uICE9IE5VTEwpCisJCQkJZXJyID0gcHBwb2wydHBf c2Vzc2lvbl9pb2N0bChzZXNzaW9uLCBjbWQsIGFyZyk7CisJCQllbHNlCisJCQkJZXJyID0gLUVC QURSOworCQkJYnJlYWs7CisJCX0KKwkJaWYgKGNvcHlfdG9fdXNlcigodm9pZCBfX3VzZXIgKikg YXJnLCAmdHVubmVsLT5zdGF0cywgCisJCQkJIHNpemVvZih0dW5uZWwtPnN0YXRzKSkpIHsKKwkJ CWVyciA9IC1FRkFVTFQ7CisJCQlicmVhazsKKwkJfQorCQlQUklOVEsodHVubmVsLT5kZWJ1Zywg UFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCBMMlRQ IHN0YXRzXG4iLCB0dW5uZWwtPm5hbWUpOworCQllcnIgPSAwOworCQlicmVhazsKKworCWRlZmF1 bHQ6CisJCWVyciA9IC1FTk9TWVM7CisJCWJyZWFrOworCX0KKworCXJldHVybiBlcnI7Cit9CisK Ky8qIE1haW4gaW9jdGwoKSBoYW5kbGVyLgorICogRGlzcGF0Y2ggdG8gdHVubmVsIG9yIHNlc3Np b24gaGVscGVycyBkZXBlbmRpbmcgb24gdGhlIHNvY2tldC4KKyAqLworc3RhdGljIGludCBwcHBv bDJ0cF9pb2N0bChzdHJ1Y3Qgc29ja2V0ICpzb2NrLCB1bnNpZ25lZCBpbnQgY21kLAorCQkJICAg IHVuc2lnbmVkIGxvbmcgYXJnKQoreworCXN0cnVjdCBzb2NrICpzayA9IHNvY2stPnNrOworCXN0 cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwg KnR1bm5lbDsKKwlpbnQgZXJyID0gMDsKKworCUVOVEVSX0ZVTkNUSU9OOworCQorCWlmICghc2sp CisJCXJldHVybiAwOworCisJaWYgKHNvY2tfZmxhZyhzaywgU09DS19ERUFEKSAhPSAwKQorCQly ZXR1cm4gLUVCQURGOworCisJaWYgKChzay0+c2tfdXNlcl9kYXRhID09IE5VTEwpIHx8IAorCSAg ICAoIShzay0+c2tfc3RhdGUgJiAoUFBQT1hfQ09OTkVDVEVEIHwgUFBQT1hfQk9VTkQpKSkpIHsK KwkJZXJyID0gLUVOT1RDT05OOworCQlEUFJJTlRLKC0xLCAiaW9jdGw6IHNvY2tldCAlcCBub3Qg Y29ubmVjdGVkLlxuIiwgc2spOworCQlnb3RvIGVuZDsKKwl9CisKKwlTT0NLXzJfU0VTU0lPTihz aywgc2Vzc2lvbiwgZXJyLCAtRUJBREYsIGVuZCwgMCk7CisJU09DS18yX1RVTk5FTChzZXNzaW9u LT50dW5uZWxfc29jaywgdHVubmVsLCBlcnIsIC1FQkFERiwgZW5kLCAxKTsKKworCS8qIFNwZWNp YWwgY2FzZTogaWYgc2Vzc2lvbidzIHNlc3Npb25faWQgaXMgemVybywgdHJlYXQgaW9jdGwgYXMg YQorCSAqIHR1bm5lbCBpb2N0bAorCSAqLworCWlmICgoc2Vzc2lvbi0+dHVubmVsX2FkZHIuc19z ZXNzaW9uID09IDApICYmCisJICAgIChzZXNzaW9uLT50dW5uZWxfYWRkci5kX3Nlc3Npb24gPT0g MCkpIHsKKwkJZXJyID0gcHBwb2wydHBfdHVubmVsX2lvY3RsKHR1bm5lbCwgY21kLCBhcmcpOwor CQlnb3RvIGVuZDsKKwl9CisKKwllcnIgPSBwcHBvbDJ0cF9zZXNzaW9uX2lvY3RsKHNlc3Npb24s IGNtZCwgYXJnKTsKKworZW5kOgorCUVYSVRfRlVOQ1RJT047CisJcmV0dXJuIGVycjsKK30KKwor LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqCisgKiBzZXRzb2Nrb3B0KCkgLyBnZXRzb2Nrb3B0KCkgc3Vw cG9ydC4KKyAqCisgKiBUaGUgUFBQb1ggc29ja2V0IGlzIGNyZWF0ZWQgZm9yIEwyVFAgc2Vzc2lv bnM6IHR1bm5lbHMgaGF2ZSB0aGVpciBvd24gVURQCisgKiBzb2NrZXRzLiBJbiBvcmRlciB0byBj b250cm9sIGtlcm5lbCB0dW5uZWwgZmVhdHVyZXMsIHdlIGFsbG93IHVzZXJzcGFjZSB0bworICog Y3JlYXRlIGEgc3BlY2lhbCAidHVubmVsIiBQUFBvWCBzb2NrZXQgd2hpY2ggaXMgdXNlZCBmb3Ig Y29udHJvbCBvbmx5LgorICogVHVubmVsIFBQUG9YIHNvY2tldHMgaGF2ZSBzZXNzaW9uX2lkID09 IDAgYW5kIHNpbXBseSBhbGxvdyB0aGUgdXNlcgorICogYXBwbGljYXRpb24gdG8gaXNzdWUgTDJU UCBzZXRzb2Nrb3B0KCksIGdldHNvY2tvcHQoKSBhbmQgaW9jdGwoKSBjYWxscy4KKyAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKi8KKworLyogVHVubmVsIHNldHNvY2tvcHQoKSBoZWxwZXIuCisgKi8KK3N0 YXRpYyBpbnQgcHBwb2wydHBfdHVubmVsX3NldHNvY2tvcHQoc3RydWN0IHBwcG9sMnRwX3R1bm5l bCAqdHVubmVsLCAKKwkJCQkgICAgICBpbnQgb3B0bmFtZSwgaW50IHZhbCkKK3sKKwlpbnQgZXJy ID0gMDsKKworCXN3aXRjaCAob3B0bmFtZSkgeworCWNhc2UgUFBQT0wyVFBfU09fREVCVUc6CisJ CXR1bm5lbC0+ZGVidWcgPSB2YWw7CisJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQUFBPTDJUUF9N U0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogc2V0IGRlYnVnPSV4XG4iLCB0 dW5uZWwtPm5hbWUsIHR1bm5lbC0+ZGVidWcpOworCQlicmVhazsKKworCWRlZmF1bHQ6CisJCWVy ciA9IC1FTk9QUk9UT09QVDsKKwkJYnJlYWs7CisJfQorCQorCXJldHVybiBlcnI7Cit9CisKKy8q IFNlc3Npb24gc2V0c29ja29wdCBoZWxwZXIuCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wydHBfc2Vz c2lvbl9zZXRzb2Nrb3B0KHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uLCAKKwkJCQkg ICAgICAgaW50IG9wdG5hbWUsIGludCB2YWwpCit7CisJaW50IGVyciA9IDA7CisKKwlzd2l0Y2gg KG9wdG5hbWUpIHsKKwljYXNlIFBQUE9MMlRQX1NPX1JFQ1ZTRVE6CisJCWlmICgodmFsICE9IDAp ICYmICh2YWwgIT0gMSkpIHsKKwkJCWVyciA9IC1FSU5WQUw7CisJCQlicmVhazsKKwkJfQorCQlz ZXNzaW9uLT5yZWN2X3NlcSA9IHZhbCA/IC0xIDogMDsKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVn LCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogc2V0IHJl Y3Zfc2VxPSVkXG4iLCBzZXNzaW9uLT5uYW1lLCAKKwkJICAgICAgIHNlc3Npb24tPnJlY3Zfc2Vx KTsKKwkJYnJlYWs7CisKKwljYXNlIFBQUE9MMlRQX1NPX1NFTkRTRVE6CisJCWlmICgodmFsICE9 IDApICYmICh2YWwgIT0gMSkpIHsKKwkJCWVyciA9IC1FSU5WQUw7CisJCQlicmVhazsKKwkJfQor CQlzZXNzaW9uLT5zZW5kX3NlcSA9IHZhbCA/IC0xIDogMDsKKwkJeworCQkJLyogRklYTUU6IGlz IGl0IHNhZmUgdG8gY2hhbmdlIHRoZSBwcHAgY2hhbm5lbCdzCisJCQkgKiBoZHJsZW4gb24gdGhl IGZseT8KKwkJCSAqLworCQkJc3RydWN0IHNvY2sgKnNrCSAgICAgPSBzZXNzaW9uLT5zb2NrOwor CQkJc3RydWN0IHBwcG94X29wdCAqcG8gPSBwcHBveF9zayhzayk7CisJCQlwby0+Y2hhbi5oZHJs ZW4gPSB2YWwgPyBQUFBPTDJUUF9MMlRQX0hEUl9TSVpFX1NFUSA6IAorCQkJCVBQUE9MMlRQX0wy VFBfSERSX1NJWkVfTk9TRVE7CisJCX0KKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJU UF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogc2V0IHNlbmRfc2VxPSVk XG4iLCBzZXNzaW9uLT5uYW1lLCBzZXNzaW9uLT5zZW5kX3NlcSk7CisJCWJyZWFrOworCisJY2Fz ZSBQUFBPTDJUUF9TT19MTlNNT0RFOgorCQlpZiAoKHZhbCAhPSAwKSAmJiAodmFsICE9IDEpKSB7 CisJCQllcnIgPSAtRUlOVkFMOworCQkJYnJlYWs7CisJCX0KKwkJc2Vzc2lvbi0+bG5zX21vZGUg PSB2YWwgPyAtMSA6IDA7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NP TlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IHNldCBsbnNfbW9kZT0lZFxuIiwgc2Vz c2lvbi0+bmFtZSwgCisJCSAgICAgICBzZXNzaW9uLT5sbnNfbW9kZSk7CisJCWJyZWFrOworCisJ Y2FzZSBQUFBPTDJUUF9TT19ERUJVRzoKKwkJc2Vzc2lvbi0+ZGVidWcgPSB2YWw7CisJCVBSSU5U SyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAg ICAgICAiJXM6IHNldCBkZWJ1Zz0leFxuIiwgc2Vzc2lvbi0+bmFtZSwgc2Vzc2lvbi0+ZGVidWcp OworCQlicmVhazsKKworCWNhc2UgUFBQT0wyVFBfU09fUkVPUkRFUlRPOgorCQlzZXNzaW9uLT5y ZW9yZGVyX3RpbWVvdXQgPSBNU19UT19KSUZGSUVTKHZhbCk7CisJCVBSSU5USyhzZXNzaW9uLT5k ZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IHNl dCByZW9yZGVyX3RpbWVvdXQ9JWRcbiIsIHNlc3Npb24tPm5hbWUsIAorCQkgICAgICAgc2Vzc2lv bi0+cmVvcmRlcl90aW1lb3V0KTsKKwkJaWYgKHNlc3Npb24tPnJlb3JkZXJfdGltZW91dCAhPSAw KQorCQkJcHBwb2wydHBfd2Fybl9ub3RfeWV0X2ltcGxlbWVudGVkKHNlc3Npb24tPmRlYnVnLCAi U09fUkVPUkRFUlRPIik7CisJCWJyZWFrOworCisJZGVmYXVsdDoKKwkJZXJyID0gLUVOT1BST1RP T1BUOworCQlicmVhazsKKwl9CisKKwlyZXR1cm4gZXJyOworfQorCisvKiBNYWluIHNldHNvY2tv cHQoKSBlbnRyeSBwb2ludC4KKyAqIERvZXMgQVBJIGNoZWNrcywgdGhlbiBjYWxscyBlaXRoZXIg dGhlIHR1bm5lbCBvciBzZXNzaW9uIHNldHNvY2tvcHQKKyAqIGhhbmRsZXIsIGFjY29yZGluZyB0 byB3aGV0aGVyIHRoZSBQUFBvTDJUUCBzb2NrZXQgaXMgYSBmb3IgYSByZWd1bGFyCisgKiBzZXNz aW9uIG9yIHRoZSBzcGVjaWFsIHR1bm5lbCB0eXBlLgorICovCitzdGF0aWMgaW50IHBwcG9sMnRw X3NldHNvY2tvcHQoc3RydWN0IHNvY2tldCAqc29jaywgaW50IGxldmVsLCBpbnQgb3B0bmFtZSwg CisJCQkgICAgICAgY2hhciAqb3B0dmFsLCBpbnQgb3B0bGVuKQoreworCXN0cnVjdCBzb2NrICpz ayA9IHNvY2stPnNrOworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uID0gc2stPnNr X3VzZXJfZGF0YTsKKwlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWw7CisJaW50IHZhbDsK KwlpbnQgZXJyID0gMDsKKworCWlmIChsZXZlbCAhPSBTT0xfUFBQT0wyVFApCisJCXJldHVybiAt RVNPQ0tUTk9TVVBQT1JUOworCisJaWYgKG9wdGxlbjxzaXplb2YoaW50KSkKKwkJcmV0dXJuIC1F SU5WQUw7CisKKwlpZiAoZ2V0X3VzZXIodmFsLCAoaW50IF9fdXNlciAqKW9wdHZhbCkpCisJCXJl dHVybiAtRUZBVUxUOworCisJaWYgKHNrLT5za191c2VyX2RhdGEgPT0gTlVMTCkgeworCQllcnIg PSAtRU5PVENPTk47CisJCURQUklOVEsoLTEsICJzZXRzb2Nrb3B0OiBzb2NrZXQgJXAgbm90IGNv bm5lY3RlZC5cbiIsIHNrKTsKKwkJZ290byBlbmQ7CisJfQorCisJU09DS18yX1NFU1NJT04oc2ss IHNlc3Npb24sIGVyciwgLUVCQURGLCBlbmQsIDApOworCVNPQ0tfMl9UVU5ORUwoc2Vzc2lvbi0+ dHVubmVsX3NvY2ssIHR1bm5lbCwgZXJyLCAtRUJBREYsIGVuZCwgMSk7CisKKwlsb2NrX3NvY2so c2spOworCisJLyogU3BlY2lhbCBjYXNlOiBpZiBzZXNzaW9uX2lkID09IDB4MDAwMCwgdHJlYXQg YXMgb3BlcmF0aW9uIG9uIHR1bm5lbAorCSAqLworCWlmICgoc2Vzc2lvbi0+dHVubmVsX2FkZHIu c19zZXNzaW9uID09IDApICYmCisJICAgIChzZXNzaW9uLT50dW5uZWxfYWRkci5kX3Nlc3Npb24g PT0gMCkpCisJCWVyciA9IHBwcG9sMnRwX3R1bm5lbF9zZXRzb2Nrb3B0KHR1bm5lbCwgb3B0bmFt ZSwgdmFsKTsKKwllbHNlCisJCWVyciA9IHBwcG9sMnRwX3Nlc3Npb25fc2V0c29ja29wdChzZXNz aW9uLCBvcHRuYW1lLCB2YWwpOworCQorCXJlbGVhc2Vfc29jayhzayk7CitlbmQ6CisJcmV0dXJu IGVycjsKK30KKworLyogVHVubmVsIGdldHNvY2tvcHQgaGVscGVyLgorICovCitzdGF0aWMgaW50 IHBwcG9sMnRwX3R1bm5lbF9nZXRzb2Nrb3B0KHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5l bCwgCisJCQkJICAgICAgaW50IG9wdG5hbWUsIGludCAqdmFsKQoreworCWludCBlcnIgPSAwOwor CisJc3dpdGNoIChvcHRuYW1lKSB7CisJY2FzZSBQUFBPTDJUUF9TT19ERUJVRzoKKwkJKnZhbCA9 IHR1bm5lbC0+ZGVidWc7CisJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQUFBPTDJUUF9NU0dfQ09O VFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogZ2V0IGRlYnVnPSV4XG4iLCB0dW5uZWwt Pm5hbWUsIHR1bm5lbC0+ZGVidWcpOworCQlicmVhazsKKworCWRlZmF1bHQ6CisJCWVyciA9IC1F Tk9QUk9UT09QVDsKKwkJYnJlYWs7CisJfQorCQorCXJldHVybiBlcnI7Cit9CisKKy8qIFNlc3Np b24gZ2V0c29ja29wdCBoZWxwZXIuCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wydHBfc2Vzc2lvbl9n ZXRzb2Nrb3B0KHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uLCAKKwkJCQkgICAgICAg aW50IG9wdG5hbWUsIGludCAqdmFsKQoreworCWludCBlcnIgPSAwOworCisJc3dpdGNoIChvcHRu YW1lKSB7CisJY2FzZSBQUFBPTDJUUF9TT19SRUNWU0VROgorCQkqdmFsID0gc2Vzc2lvbi0+cmVj dl9zZXE7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtF Uk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCByZWN2X3NlcT0lZFxuIiwgc2Vzc2lvbi0+bmFt ZSwgKnZhbCk7CisJCWJyZWFrOworCisJY2FzZSBQUFBPTDJUUF9TT19TRU5EU0VROgorCQkqdmFs ID0gc2Vzc2lvbi0+c2VuZF9zZXE7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBf TVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCBzZW5kX3NlcT0lZFxu Iiwgc2Vzc2lvbi0+bmFtZSwgKnZhbCk7CisJCWJyZWFrOworCisJY2FzZSBQUFBPTDJUUF9TT19M TlNNT0RFOgorCQkqdmFsID0gc2Vzc2lvbi0+bG5zX21vZGU7CisJCVBSSU5USyhzZXNzaW9uLT5k ZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdl dCBsbnNfbW9kZT0lZFxuIiwgc2Vzc2lvbi0+bmFtZSwgKnZhbCk7CisJCWJyZWFrOworCisJY2Fz ZSBQUFBPTDJUUF9TT19ERUJVRzoKKwkJKnZhbCA9IHNlc3Npb24tPmRlYnVnOworCQlQUklOVEso c2Vzc2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAg ICAgIiVzOiBnZXQgZGVidWc9JWRcbiIsIHNlc3Npb24tPm5hbWUsICp2YWwpOworCQlicmVhazsK KworCWNhc2UgUFBQT0wyVFBfU09fUkVPUkRFUlRPOgorCQkqdmFsID0gSklGRklFU19UT19NUyhz ZXNzaW9uLT5yZW9yZGVyX3RpbWVvdXQpOworCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9M MlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiBnZXQgcmVvcmRlcl90 aW1lb3V0PSVkXG4iLCBzZXNzaW9uLT5uYW1lLCAqdmFsKTsKKwkJYnJlYWs7CisKKwlkZWZhdWx0 OgorCQllcnIgPSAtRU5PUFJPVE9PUFQ7CisJfQorCisJcmV0dXJuIGVycjsKK30KKworLyogTWFp biBnZXRzb2Nrb3B0KCkgZW50cnkgcG9pbnQuCisgKiBEb2VzIEFQSSBjaGVja3MsIHRoZW4gY2Fs bHMgZWl0aGVyIHRoZSB0dW5uZWwgb3Igc2Vzc2lvbiBnZXRzb2Nrb3B0CisgKiBoYW5kbGVyLCBh Y2NvcmRpbmcgdG8gd2hldGhlciB0aGUgUFBQb1ggc29ja2V0IGlzIGEgZm9yIGEgcmVndWxhciBz ZXNzaW9uCisgKiBvciB0aGUgc3BlY2lhbCB0dW5uZWwgdHlwZS4KKyAqLworc3RhdGljIGludCBw cHBvbDJ0cF9nZXRzb2Nrb3B0KHN0cnVjdCBzb2NrZXQgKnNvY2ssIGludCBsZXZlbCwgCisJCQkg ICAgICAgaW50IG9wdG5hbWUsIGNoYXIgKm9wdHZhbCwgaW50ICpvcHRsZW4pCit7CisJc3RydWN0 IHNvY2sgKnNrID0gc29jay0+c2s7CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24g PSBzay0+c2tfdXNlcl9kYXRhOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbDsKKwlp bnQgdmFsLCBsZW47CisJaW50IGVyciA9IDA7CisKKwlpZiAobGV2ZWwgIT0gU09MX1BQUE9MMlRQ KQorCQlyZXR1cm4gLUVTT0NLVE5PU1VQUE9SVDsKKworCWlmIChnZXRfdXNlcihsZW4sIChpbnQg X191c2VyICopIG9wdGxlbikpCisJCXJldHVybiAtRUZBVUxUOworCisJbGVuID0gbWluX3QodW5z aWduZWQgaW50LCBsZW4sIHNpemVvZihpbnQpKTsKKwkKKwlpZiAobGVuIDwgMCkKKwkJcmV0dXJu IC1FSU5WQUw7CisKKwlpZiAoc2stPnNrX3VzZXJfZGF0YSA9PSBOVUxMKSB7CisJCWVyciA9IC1F Tk9UQ09OTjsKKwkJRFBSSU5USygtMSwgImdldHNvY2tvcHQ6IHNvY2tldCAlcCBub3QgY29ubmVj dGVkLlxuIiwgc2spOworCQlnb3RvIGVuZDsKKwl9CisKKwkvKiBHZXQgdGhlIHNlc3Npb24gYW5k IHR1bm5lbCBjb250ZXh0cyAqLworCVNPQ0tfMl9TRVNTSU9OKHNrLCBzZXNzaW9uLCBlcnIsIC1F QkFERiwgZW5kLCAwKTsKKwlTT0NLXzJfVFVOTkVMKHNlc3Npb24tPnR1bm5lbF9zb2NrLCB0dW5u ZWwsIGVyciwgLUVCQURGLCBlbmQsIDEpOworCisJLyogU3BlY2lhbCBjYXNlOiBpZiBzZXNzaW9u X2lkID09IDB4MDAwMCwgdHJlYXQgYXMgb3BlcmF0aW9uIG9uIHR1bm5lbCAqLworCWlmICgoc2Vz c2lvbi0+dHVubmVsX2FkZHIuc19zZXNzaW9uID09IDApICYmCisJICAgIChzZXNzaW9uLT50dW5u ZWxfYWRkci5kX3Nlc3Npb24gPT0gMCkpCisJCWVyciA9IHBwcG9sMnRwX3R1bm5lbF9nZXRzb2Nr b3B0KHR1bm5lbCwgb3B0bmFtZSwgJnZhbCk7CisJZWxzZQorCQllcnIgPSBwcHBvbDJ0cF9zZXNz aW9uX2dldHNvY2tvcHQoc2Vzc2lvbiwgb3B0bmFtZSwgJnZhbCk7CisJCisKKwlpZiAocHV0X3Vz ZXIobGVuLCAoaW50IF9fdXNlciAqKSBvcHRsZW4pKQorCQlyZXR1cm4gLUVGQVVMVDsKKworCWlm IChjb3B5X3RvX3VzZXIoKHZvaWQgX191c2VyICopIG9wdHZhbCwgJnZhbCwgbGVuKSkKKwkJcmV0 dXJuIC1FRkFVTFQ7CisKK2VuZDoKKwlyZXR1cm4gZXJyOworfQorCisvKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKKyAqIC9wcm9jIGZpbGVzeXN0ZW0gZm9yIGRlYnVnCisgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KiovCisKKyNpZmRlZiBDT05GSUdfUFJPQ19GUworCisjaW5jbHVkZSA8bGludXgvc2VxX2ZpbGUu aD4KKworI2lmIChMSU5VWF9WRVJTSU9OX0NPREUgIT0gS0VSTkVMX1ZFUlNJT04oMiw0LDI3KSkK KyNpZiAoTElOVVhfVkVSU0lPTl9DT0RFIDwgS0VSTkVMX1ZFUlNJT04oMiw1LDApKQorc3RhdGlj IGlubGluZSBzdHJ1Y3QgcHJvY19kaXJfZW50cnkgKlBERShjb25zdCBzdHJ1Y3QgaW5vZGUgKmlu b2RlKQoreworCXJldHVybiAoc3RydWN0IHByb2NfZGlyX2VudHJ5ICopaW5vZGUtPnUuZ2VuZXJp Y19pcDsKK30KKyNlbmRpZgorI2VuZGlmCitzdGF0aWMgc3RydWN0IHByb2NfZGlyX2VudHJ5ICpw cHBvbDJ0cF9wcm9jOworCitzdGF0aWMgaW50IHBwcG9sMnRwX3Byb2Nfb3BlbihzdHJ1Y3QgaW5v ZGUgKmlub2RlLCBzdHJ1Y3QgZmlsZSAqZmlsZSk7CitzdGF0aWMgdm9pZCAqcHBwb2wydHBfcHJv Y19zdGFydChzdHJ1Y3Qgc2VxX2ZpbGUgKnAsIGxvZmZfdCAqcG9zKTsKK3N0YXRpYyB2b2lkICpw cHBvbDJ0cF9wcm9jX25leHQoc3RydWN0IHNlcV9maWxlICpwLCB2b2lkICp2LCBsb2ZmX3QgKnBv cyk7CitzdGF0aWMgdm9pZCBwcHBvbDJ0cF9wcm9jX3N0b3Aoc3RydWN0IHNlcV9maWxlICpwLCB2 b2lkICp2KTsKK3N0YXRpYyBpbnQgcHBwb2wydHBfcHJvY19zaG93KHN0cnVjdCBzZXFfZmlsZSAq bSwgdm9pZCAqdik7CisKK3N0YXRpYyBzdHJ1Y3Qgc2VxX29wZXJhdGlvbnMgcHBwb2wydHBfcHJv Y19vcHMgPSB7CisJLnN0YXJ0CQk9IHBwcG9sMnRwX3Byb2Nfc3RhcnQsCisJLm5leHQJCT0gcHBw b2wydHBfcHJvY19uZXh0LAorCS5zdG9wCQk9IHBwcG9sMnRwX3Byb2Nfc3RvcCwKKwkuc2hvdwkJ PSBwcHBvbDJ0cF9wcm9jX3Nob3csCit9OworCitzdGF0aWMgc3RydWN0IGZpbGVfb3BlcmF0aW9u cyBwcHBvbDJ0cF9wcm9jX2ZvcHMgPSB7CisJLm93bmVyCQk9IFRISVNfTU9EVUxFLAorCS5vcGVu CQk9IHBwcG9sMnRwX3Byb2Nfb3BlbiwKKwkucmVhZAkJPSBzZXFfcmVhZCwKKwkubGxzZWVrCQk9 IHNlcV9sc2VlaywKKwkucmVsZWFzZQk9IHNlcV9yZWxlYXNlLAorfTsKKworc3RhdGljIGludCBw cHBvbDJ0cF9wcm9jX29wZW4oc3RydWN0IGlub2RlICppbm9kZSwgc3RydWN0IGZpbGUgKmZpbGUp Cit7CisJc3RydWN0IHNlcV9maWxlICptOworCWludCByZXQgPSAwOworCisJRU5URVJfRlVOQ1RJ T047CisJcmV0ID0gc2VxX29wZW4oZmlsZSwmcHBwb2wydHBfcHJvY19vcHMpOworCWlmIChyZXQ8 MCkKKwkJZ290byBvdXQ7CisKKwltCSAgID0gZmlsZS0+cHJpdmF0ZV9kYXRhOworCW0tPnByaXZh dGUgPSBQREUoaW5vZGUpLT5kYXRhOworCitvdXQ6CisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm4g cmV0OworfQorCitzdGF0aWMgdm9pZCAqcHBwb2wydHBfcHJvY19zdGFydChzdHJ1Y3Qgc2VxX2Zp bGUgKm0sIGxvZmZfdCAqX3BvcykKK3sKKwlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWw7 CisJbG9mZl90IHBvcyA9ICpfcG9zOworCisJRU5URVJfRlVOQ1RJT047CisKKwkvKiBsb2NrIHRo ZSBsaXN0IGFnYWluc3QgbW9kaWZpY2F0aW9uICovCisJd3JpdGVfbG9ja19iaCgmcHBwb2wydHBf aGFzaF9sb2NrKTsKKworCS8qIGFsbG93IGZvciB0aGUgaGVhZGVyIGxpbmUgKi8KKwlpZiAoIXBv cykKKwkJcmV0dXJuICh2b2lkICopMTsKKwlwb3MtLTsKKworCS8qIGZpbmQgdGhlIG4ndGggZWxl bWVudCBpbiB0aGUgbGlzdCAqLworCWZvciAodHVubmVsID0gcHBwb2wydHBfdHVubmVsX2xpc3Q7 IHR1bm5lbCAhPSBOVUxMOyAKKwkgICAgIHR1bm5lbCA9IHR1bm5lbC0+bmV4dCkKKwkJaWYgKCFw b3MtLSkKKwkJCWJyZWFrOworCisJRVhJVF9GVU5DVElPTjsKKworCXJldHVybiB0dW5uZWw7Cit9 CisKK3N0YXRpYyB2b2lkICpwcHBvbDJ0cF9wcm9jX25leHQoc3RydWN0IHNlcV9maWxlICpwLCB2 b2lkICp2LCBsb2ZmX3QgKnBvcykKK3sKKwlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWwg PSB2OworCisJRU5URVJfRlVOQ1RJT047CisKKwkoKnBvcykrKzsKKworCXR1bm5lbCA9ICh2ID09 ICh2b2lkICopMSkgPyBwcHBvbDJ0cF90dW5uZWxfbGlzdCA6IHR1bm5lbC0+bmV4dDsKKworCUVY SVRfRlVOQ1RJT047CisKKwlyZXR1cm4gdHVubmVsOworfQorCitzdGF0aWMgdm9pZCBwcHBvbDJ0 cF9wcm9jX3N0b3Aoc3RydWN0IHNlcV9maWxlICpwLCB2b2lkICp2KQoreworCUVOVEVSX0ZVTkNU SU9OOworCisJd3JpdGVfdW5sb2NrX2JoKCZwcHBvbDJ0cF9oYXNoX2xvY2spOworCisJRVhJVF9G VU5DVElPTjsKK30KKworc3RhdGljIGludCBwcHBvbDJ0cF9wcm9jX3Nob3coc3RydWN0IHNlcV9m aWxlICptLCB2b2lkICp2KQoreworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbCA9IHY7 CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb247CisJaW50IGk7CisKKwlFTlRFUl9G VU5DVElPTjsKKworCS8qIGRpc3BsYXkgaGVhZGVyIG9uIGxpbmUgMSAqLworCWlmICh2ID09ICh2 b2lkICopMSkgeworCQlzZXFfcHV0cyhtLCAiUFBQb0wyVFAgZHJpdmVyIGluZm8sICIgUFBQT0wy VFBfRFJWX1ZFUlNJT04gIlxuIik7CisJCXNlcV9wdXRzKG0sICJUVU5ORUwgbmFtZSwgdXNlci1k YXRhLW9rICIKKwkJCSAic2Vzc2lvbi1jb3VudCBtYWdpYy1va1xuIik7CisJCXNlcV9wdXRzKG0s ICIgZGVidWcgdHgtcGt0cy9ieXRlcy9lcnJzIHJ4LXBrdHMvYnl0ZXMvZXJyc1xuIik7CisJCXNl cV9wdXRzKG0sICIgIFNFU1NJT04gbmFtZSwgYWRkci9wb3J0IHNyYy10aWQvc2lkICIKKwkJCSAi ZGVzdC10aWQvc2lkIHN0YXRlIHVzZXItZGF0YS1vayBtYWdpYy1va1xuIik7CisJCXNlcV9wdXRz KG0sICIgICBtdHUvbXJ1L3JjdnNlcS9zZW5kc2VxL2xucyBkZWJ1ZyByZW9yZGVydG9cbiIpOwor CQlzZXFfcHV0cyhtLCAiICAgbnIvbnMgdHgtcGt0cy9ieXRlcy9lcnJzIHJ4LXBrdHMvYnl0ZXMv ZXJyc1xuIik7CisJCXNlcV9wdXRzKG0sICJcbiIpOworCQlnb3RvIG91dDsKKwl9CisKKwlzZXFf cHJpbnRmKG0sICJUVU5ORUwgJyVzJywgJWMgJWQgTUFHSUMgJXNcbiIsIAorCQkgICB0dW5uZWwt Pm5hbWUsCisJCSAgICh0dW5uZWwgPT0gdHVubmVsLT5zb2NrLT5za191c2VyX2RhdGEpID8gJ1kn OidOJywKKwkJICAgYXRvbWljX3JlYWQoJnR1bm5lbC0+c2Vzc2lvbl9jb3VudCksCisJCSAgICh0 dW5uZWwtPm1hZ2ljID09IEwyVFBfVFVOTkVMX01BR0lDKSA/ICJPSyIgOiAiQkFEIik7CisJc2Vx X3ByaW50ZihtLCAiICUwOHggJXUvJXUvJXUgJXUvJXUvJXVcbiIsCisJCSAgIHR1bm5lbC0+ZGVi dWcsCisJCSAgIHR1bm5lbC0+c3RhdHMudHhfcGFja2V0cywgdHVubmVsLT5zdGF0cy50eF9ieXRl cywgCisJCSAgIHR1bm5lbC0+c3RhdHMudHhfZXJyb3JzLAorCQkgICB0dW5uZWwtPnN0YXRzLnJ4 X3BhY2tldHMsIHR1bm5lbC0+c3RhdHMucnhfYnl0ZXMsIAorCQkgICB0dW5uZWwtPnN0YXRzLnJ4 X2Vycm9ycyk7CisKKwlpZiAodHVubmVsLT5tYWdpYyAhPSBMMlRQX1RVTk5FTF9NQUdJQykgewor CQlnb3RvIG91dDsKKwl9CisKKwlmb3IgKGkgPSAwOyBpIDwgUFBQT0wyVFBfSEFTSF9TSVpFOyBp KyspIHsKKwkJc2Vzc2lvbiA9IHR1bm5lbC0+aGFzaFtpXTsKKwkJd2hpbGUgKHNlc3Npb24pIHsK KwkJCXNlcV9wcmludGYobSwgIiAgU0VTU0lPTiAnJXMnICUwOFgvJWQgJTA0WC8lMDRYIC0+ICIK KwkJCQkgICAiJTA0WC8lMDRYICVkICVjIE1BR0lDICVzXG4iLAorCQkJCSAgIHNlc3Npb24tPm5h bWUsCisJCQkJICAgaHRvbmwoc2Vzc2lvbi0+dHVubmVsX2FkZHIuYWRkci5zaW5fYWRkci5zX2Fk ZHIpLAorCQkJCSAgIGh0b25zKHNlc3Npb24tPnR1bm5lbF9hZGRyLmFkZHIuc2luX3BvcnQpLAor CQkJCSAgIHNlc3Npb24tPnR1bm5lbF9hZGRyLnNfdHVubmVsLCAKKwkJCQkgICBzZXNzaW9uLT50 dW5uZWxfYWRkci5zX3Nlc3Npb24sCisJCQkJICAgc2Vzc2lvbi0+dHVubmVsX2FkZHIuZF90dW5u ZWwsIAorCQkJCSAgIHNlc3Npb24tPnR1bm5lbF9hZGRyLmRfc2Vzc2lvbiwKKwkJCQkgICBzZXNz aW9uLT5zb2NrLT5za19zdGF0ZSwKKwkJCQkgICAoc2Vzc2lvbiA9PSBzZXNzaW9uLT5zb2NrLT5z a191c2VyX2RhdGEpID8gCisJCQkJICAgJ1knIDogJ04nLAorCQkJCSAgIChzZXNzaW9uLT5tYWdp YyA9PSBMMlRQX1NFU1NJT05fTUFHSUMpID8gCisJCQkJICAgIk9LIiA6ICJCQUQiKTsKKworCQkJ c2VxX3ByaW50ZihtLCAiICAgJWQvJWQvJWMvJWMvJXMgJTA4eCAlZFxuIiwKKwkJCQkgICBzZXNz aW9uLT5tdHUsIHNlc3Npb24tPm1ydSwgCisJCQkJICAgc2Vzc2lvbi0+cmVjdl9zZXEgPyAnUicg OiAnLScsCisJCQkJICAgc2Vzc2lvbi0+c2VuZF9zZXEgPyAnUycgOiAnLScsCisJCQkJICAgc2Vz c2lvbi0+bG5zX21vZGUgPyAiTE5TIiA6ICJMQUMiLAorCQkJCSAgIHNlc3Npb24tPmRlYnVnLCBz ZXNzaW9uLT5yZW9yZGVyX3RpbWVvdXQpOworCQkJc2VxX3ByaW50ZihtLCAiICAgJWh1LyVodSAl dS8ldS8ldSAldS8ldS8ldVxuIiwKKwkJCQkgICBzZXNzaW9uLT5uciwgc2Vzc2lvbi0+bnMsCisJ CQkJICAgc2Vzc2lvbi0+c3RhdHMudHhfcGFja2V0cywgCisJCQkJICAgc2Vzc2lvbi0+c3RhdHMu dHhfYnl0ZXMsIAorCQkJCSAgIHNlc3Npb24tPnN0YXRzLnR4X2Vycm9ycywKKwkJCQkgICBzZXNz aW9uLT5zdGF0cy5yeF9wYWNrZXRzLCAKKwkJCQkgICBzZXNzaW9uLT5zdGF0cy5yeF9ieXRlcywg CisJCQkJICAgc2Vzc2lvbi0+c3RhdHMucnhfZXJyb3JzKTsKKworCQkJaWYgKHNlc3Npb24tPm1h Z2ljICE9IEwyVFBfU0VTU0lPTl9NQUdJQykgeworCQkJCXNlcV9wdXRzKG0sICIqKiogQWJvcnRp bmcgKioqXG4iKTsKKwkJCQlicmVhazsKKwkJCX0KKworCQkJc2Vzc2lvbiA9IHNlc3Npb24tPm5l eHQ7CisJCX0KKworCQlpZiAoc2Vzc2lvbikKKwkJCWJyZWFrOworCX0KKwlzZXFfcHV0cyhtLCAi XG4iKTsKKworb3V0OgorCUVYSVRfRlVOQ1RJT047CisKKwlyZXR1cm4gMDsKK30KKworI2VuZGlm IC8qIENPTkZJR19QUk9DX0ZTICovCisKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICogSW5pdCBh bmQgY2xlYW51cAorICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworCitzdGF0aWMgc3RydWN0IHByb3Rv X29wcyBwcHBvbDJ0cF9vcHMgPSB7CisJLmZhbWlseQkJPSBBRl9QUFBPWCwKKwkub3duZXIJCT0g VEhJU19NT0RVTEUsCisJLnJlbGVhc2UJPSBwcHBvbDJ0cF9yZWxlYXNlLAorCS5iaW5kCQk9IHNv Y2tfbm9fYmluZCwKKwkuY29ubmVjdAk9IHBwcG9sMnRwX2Nvbm5lY3QsCisJLnNvY2tldHBhaXIJ PSBzb2NrX25vX3NvY2tldHBhaXIsCisJLmFjY2VwdAkJPSBzb2NrX25vX2FjY2VwdCwKKwkuZ2V0 bmFtZQk9IHBwcG9sMnRwX2dldG5hbWUsCisJLnBvbGwJCT0gZGF0YWdyYW1fcG9sbCwKKwkubGlz dGVuCQk9IHNvY2tfbm9fbGlzdGVuLAorCS5zaHV0ZG93bgk9IHNvY2tfbm9fc2h1dGRvd24sCisJ LnNldHNvY2tvcHQJPSBwcHBvbDJ0cF9zZXRzb2Nrb3B0LAorCS5nZXRzb2Nrb3B0CT0gcHBwb2wy dHBfZ2V0c29ja29wdCwKKwkuc2VuZG1zZwk9IHBwcG9sMnRwX3NlbmRtc2csCisJLnJlY3Ztc2cJ PSBwcHBvbDJ0cF9yZWN2bXNnLAorCS5tbWFwCQk9IHNvY2tfbm9fbW1hcAorfTsKKworc3RydWN0 IHBwcG94X3Byb3RvIHBwcG9sMnRwX3Byb3RvID0geworCS5jcmVhdGUJCT0gcHBwb2wydHBfY3Jl YXRlLAorCS5pb2N0bAkJPSBwcHBvbDJ0cF9pb2N0bAorfTsKKworaW50IF9faW5pdCBwcHBvbDJ0 cF9pbml0KHZvaWQpCit7CisJaW50IGVyciA9IHJlZ2lzdGVyX3BwcG94X3Byb3RvKFBYX1BST1RP X09MMlRQLCAmcHBwb2wydHBfcHJvdG8pOworCisJaWYgKGVyciA9PSAwKSB7CisjaWZkZWYgQ09O RklHX1BST0NfRlMKKwkJcHBwb2wydHBfcHJvYyA9IGNyZWF0ZV9wcm9jX2VudHJ5KCJwcHBvbDJ0 cCIsIDAsIHByb2NfbmV0KTsKKwkJaWYgKCFwcHBvbDJ0cF9wcm9jKSB7CisJCQlyZXR1cm4gLUVO T01FTTsKKwkJfQorCQlwcHBvbDJ0cF9wcm9jLT5wcm9jX2ZvcHMgPSAmcHBwb2wydHBfcHJvY19m b3BzOworI2VuZGlmIC8qIENPTkZJR19QUk9DX0ZTICovCisJCXByaW50ayhLRVJOX0lORk8gIlBQ UG9MMlRQIGtlcm5lbCBkcml2ZXIsICVzXG4iLAorCQkgICAgICAgUFBQT0wyVFBfRFJWX1ZFUlNJ T04pOworCX0KKworCXJldHVybiBlcnI7Cit9CisKK3ZvaWQgX19leGl0IHBwcG9sMnRwX2V4aXQo dm9pZCkKK3sKKwl1bnJlZ2lzdGVyX3BwcG94X3Byb3RvKFBYX1BST1RPX09MMlRQKTsKKyNpZmRl ZiBDT05GSUdfUFJPQ19GUworCXJlbW92ZV9wcm9jX2VudHJ5KCJwcHBvbDJ0cCIsIHByb2NfbmV0 KTsKKyNlbmRpZgorfQorCittb2R1bGVfaW5pdChwcHBvbDJ0cF9pbml0KTsKK21vZHVsZV9leGl0 KHBwcG9sMnRwX2V4aXQpOworCitNT0RVTEVfQVVUSE9SKCJNYXJ0aWpuIHZhbiBPb3N0ZXJob3V0 IDxrbGVwdG9nQHN2YW5hLm9yZz4iKTsKK01PRFVMRV9ERVNDUklQVElPTigiUFBQIG92ZXIgTDJU UCBvdmVyIFVEUCwgIiBQUFBPTDJUUF9EUlZfVkVSU0lPTik7CitNT0RVTEVfTElDRU5TRSgiR1BM Iik7CmRpZmYgLU5hdXIgbGludXgtMi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvaWZfcHBwb2wy dHAuaCBsaW51eC0yLjYuOC4xL2luY2x1ZGUvbGludXgvaWZfcHBwb2wydHAuaAotLS0gbGludXgt Mi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvaWZfcHBwb2wydHAuaAkxOTcwLTAxLTAxIDAxOjAw OjAwLjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9pbmNsdWRlL2xpbnV4L2lmX3Bw cG9sMnRwLmgJMjAwNC0wOS0wMSAxNzozNzo1NC4wMDAwMDAwMDAgKzAxMDAKQEAgLTAsMCArMSw4 NSBAQAorLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgorICogTGludXggUFBQIG92ZXIgTDJUUCAoUFBQb0wy VFApIFNvY2tldCBJbXBsZW1lbnRhdGlvbiAoUkZDIDI2NjEpIAorICoKKyAqIFRoaXMgZmlsZSBz dXBwbGllcyBkZWZpbml0aW9ucyByZXF1aXJlZCBieSB0aGUgUFBQIG92ZXIgTDJUUCBkcml2ZXIK KyAqIChwcHBvbDJ0cC5jKS4gIEFsbCB2ZXJzaW9uIGluZm9ybWF0aW9uIHdydCB0aGlzIGZpbGUg aXMgbG9jYXRlZCBpbiBwcHBvbDJ0cC5jCisgKgorICogTGljZW5zZToKKyAqCQlUaGlzIHByb2dy YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKgkJ bW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu c2UKKyAqCQlhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0 aGVyIHZlcnNpb24KKyAqCQkyIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFu eSBsYXRlciB2ZXJzaW9uLgorICoKKyAqLworCisjaWZuZGVmIF9fTElOVVhfSUZfUFBQT0wyVFBf SAorI2RlZmluZSBfX0xJTlVYX0lGX1BQUE9MMlRQX0gKKworI2luY2x1ZGUgPGFzbS90eXBlcy5o PgorCisjaWZkZWYgX19LRVJORUxfXworI2luY2x1ZGUgPGxpbnV4L2luLmg+CisjZW5kaWYKKwor LyogU3RydWN0dXJlIHVzZWQgdG8gYmluZCgpIHRoZSBzb2NrZXQgdG8gYSBwYXJ0aWN1bGFyIHNv Y2tldCAmIHR1bm5lbCAqLworc3RydWN0IHBwcG9sMnRwX2FkZHIKK3sKKwlpbnQJZmQ7CQkgLyog RkQgb2YgVURQIHNvY2tldCB0byB1c2UgKi8KKwkKKwlzdHJ1Y3Qgc29ja2FkZHJfaW4gYWRkcjsg LyogSVAgYWRkcmVzcyBhbmQgcG9ydCB0byBzZW5kIHRvICovCisJCisJX191MTYgc190dW5uZWws IHNfc2Vzc2lvbjsgICAgLyogRm9yIG1hdGNoaW5nIGluY29taW5nIHBhY2tldHMgKi8KKwlfX3Ux NiBkX3R1bm5lbCwgZF9zZXNzaW9uOyAgICAvKiBGb3Igc2VuZGluZyBvdXRnb2luZyBwYWNrZXRz ICovCit9OworCisvKiBJb2N0bCBkZWZpbml0aW9uczoKKyAqIEdMMlRQU1RBVFMJLSBnZXQgTDJU UCB0dW5uZWwgb3Igc2Vzc2lvbiBzdGF0aXN0aWNzCisgKgorICogRklYTUUgLSBNT1ZFIFRPIGlm X3BwcC5oPz8/CisgKi8KKyNkZWZpbmUJUFBQSU9DR0wyVFBTVEFUUwlfSU9SKCd0JywgNTQsIHN0 cnVjdCBwcHBvbDJ0cF9pb2Nfc3RhdHMpCisKK3N0cnVjdCBwcHBvbDJ0cF9pb2Nfc3RhdHMgewor CV9fdTE2CXR1bm5lbF9pZDsJLyogcmVkdW5kYW50ICovCisJX191MTYJc2Vzc2lvbl9pZDsJLyog aWYgemVybywgZ2V0IHR1bm5lbCBzdGF0cyAqLworCV9fdTMyCXR4X3BhY2tldHM7CisJX191MzIJ dHhfYnl0ZXM7CisJX191MzIJdHhfZXJyb3JzOworCV9fdTMyCXJ4X3BhY2tldHM7CisJX191MzIJ cnhfYnl0ZXM7CisJX191MzIJcnhfc2VxX2Rpc2NhcmRzOworCV9fdTMyCXJ4X29vc19wYWNrZXRz OworCV9fdTMyCXJ4X2Vycm9yczsKK307CisKKy8qIFNvY2tldCBvcHRpb25zOgorICogREVCVUcJ LSBiaXRtYXNrIG9mIGRlYnVnIG1lc3NhZ2UgY2F0ZWdvcmllcworICogU0VORFNFUQktIDAgPT4g ZG9uJ3Qgc2VuZCBwYWNrZXRzIHdpdGggc2VxdWVuY2UgbnVtYmVycworICoJCSAgMSA9PiBzZW5k IHBhY2tldHMgd2l0aCBzZXF1ZW5jZSBudW1iZXJzCisgKiBSRUNWU0VRCS0gMCA9PiByZWNlaXZl IHBhY2tldCBzZXF1ZW5jZSBudW1iZXJzIGFyZSBvcHRpb25hbAorICoJCSAgMSA9PiBkcm9wIHJl Y2VpdmUgcGFja2V0cyB3aXRob3V0IHNlcXVlbmNlIG51bWJlcnMKKyAqIExOU01PREUJLSAwID0+ IGFjdCBhcyBMQUMuCisgKgkJICAxID0+IGFjdCBhcyBMTlMuCisgKiBSRU9SREVSVE8JLSByZW9y ZGVyIHRpbWVvdXQgKGluIG1pbGxpc2VjcykuIElmIDAsIGRvbid0IHRyeSB0byByZW9yZGVyLgor ICovCitlbnVtIHsKKwlQUFBPTDJUUF9TT19ERUJVRwk9IDEsCisJUFBQT0wyVFBfU09fUkVDVlNF UQk9IDIsCisJUFBQT0wyVFBfU09fU0VORFNFUQk9IDMsCisJUFBQT0wyVFBfU09fTE5TTU9ERQk9 IDQsCisJUFBQT0wyVFBfU09fUkVPUkRFUlRPCT0gNSwKK307CisKKy8qIERlYnVnIG1lc3NhZ2Ug Y2F0ZWdvcmllcyBmb3IgdGhlIERFQlVHIHNvY2tldCBvcHRpb24gKi8KK2VudW0geworCVBQUE9M MlRQX01TR19ERUJVRwk9ICgxIDw8IDApLAkvKiB2ZXJib3NlIGRlYnVnIChpZgorCQkJCQkJICog Y29tcGlsZWQgaW4pICovIAorCVBQUE9MMlRQX01TR19DT05UUk9MCT0gKDEgPDwgMSksCS8qIHVz ZXJzcGFjZSAtIGtlcm5lbAorCQkJCQkJICogaW50ZXJmYWNlICovCisJUFBQT0wyVFBfTVNHX1NF UQk9ICgxIDw8IDIpLAkvKiBzZXF1ZW5jZSBudW1iZXJzICovCisJUFBQT0wyVFBfTVNHX0RBVEEJ PSAoMSA8PCAzKSwJLyogZGF0YSBwYWNrZXRzICovCit9OworCisKKworI2VuZGlmCmRpZmYgLU5h dXIgbGludXgtMi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvaWZfcHBwb3guaCBsaW51eC0yLjYu OC4xL2luY2x1ZGUvbGludXgvaWZfcHBwb3guaAotLS0gbGludXgtMi42LjguMS5vcmlnL2luY2x1 ZGUvbGludXgvaWZfcHBwb3guaAkyMDA0LTA4LTE0IDExOjU0OjUwLjAwMDAwMDAwMCArMDEwMAor KysgbGludXgtMi42LjguMS9pbmNsdWRlL2xpbnV4L2lmX3BwcG94LmgJMjAwNC0wOS0wMSAxNzoz Nzo1NC4wMDAwMDAwMDAgKzAxMDAKQEAgLTI3LDYgKzI3LDcgQEAKICNpbmNsdWRlIDxhc20vc2Vt YXBob3JlLmg+CiAjaW5jbHVkZSA8bGludXgvcHBwX2NoYW5uZWwuaD4KICNlbmRpZiAvKiBfX0tF Uk5FTF9fICovCisjaW5jbHVkZSA8bGludXgvaWZfcHBwb2wydHAuaD4KIAogLyogRm9yIHVzZXIt c3BhY2UgcHJvZ3JhbXMgdG8gcGljayB1cCB0aGVzZSBkZWZpbml0aW9ucwogICogd2hpY2ggdGhl eSB3b3VsZG4ndCBnZXQgb3RoZXJ3aXNlIHdpdGhvdXQgZGVmaW5pbmcgX19LRVJORUxfXwpAQCAt NTAsMTMgKzUxLDE1IEBACiAgKiBQcm90b2NvbHMgc3VwcG9ydGVkIGJ5IEFGX1BQUE9YIAogICov IAogI2RlZmluZSBQWF9QUk9UT19PRSAgICAwIC8qIEN1cnJlbnRseSBqdXN0IFBQUG9FICovCi0j ZGVmaW5lIFBYX01BWF9QUk9UTyAgIDEJCisjZGVmaW5lIFBYX1BST1RPX09MMlRQIDEgLyogTm93 IEwyVFAgYWxzbyAqLworI2RlZmluZSBQWF9NQVhfUFJPVE8gICAyCQogIAogc3RydWN0IHNvY2th ZGRyX3BwcG94IHsgCiAgICAgICAgc2FfZmFtaWx5X3QgICAgIHNhX2ZhbWlseTsgICAgICAgICAg ICAvKiBhZGRyZXNzIGZhbWlseSwgQUZfUFBQT1ggKi8gCiAgICAgICAgdW5zaWduZWQgaW50ICAg IHNhX3Byb3RvY29sOyAgICAgICAgICAvKiBwcm90b2NvbCBpZGVudGlmaWVyICovIAogICAgICAg IHVuaW9ueyAKICAgICAgICAgICAgICAgIHN0cnVjdCBwcHBvZV9hZGRyICAgICAgIHBwcG9lOyAK KyAgICAgICAgICAgICAgIHN0cnVjdCBwcHBvbDJ0cF9hZGRyICAgIHBwcG9sMnRwOwogICAgICAg IH1zYV9hZGRyOyAKIH1fX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7IAogCmRpZmYgLU5hdXIgbGlu dXgtMi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvc29ja2V0LmggbGludXgtMi42LjguMS9pbmNs dWRlL2xpbnV4L3NvY2tldC5oCi0tLSBsaW51eC0yLjYuOC4xLm9yaWcvaW5jbHVkZS9saW51eC9z b2NrZXQuaAkyMDA0LTA4LTE0IDExOjU1OjU5LjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42 LjguMS9pbmNsdWRlL2xpbnV4L3NvY2tldC5oCTIwMDQtMDktMDEgMTc6Mzc6NTUuMDAwMDAwMDAw ICswMTAwCkBAIC0yNjgsNiArMjY4LDcgQEAKICNkZWZpbmUgU09MX0lSREEgICAgICAgIDI2Ngog I2RlZmluZSBTT0xfTkVUQkVVSQkyNjcKICNkZWZpbmUgU09MX0xMQwkJMjY4CisjZGVmaW5lIFNP TF9QUFBPTDJUUAkyNjkKIAogLyogSVBYIG9wdGlvbnMgKi8KICNkZWZpbmUgSVBYX1RZUEUJMQo= ---MOQ10944719560baa5174fac6e4ed97ac1aeaf3061f31-- From shemminger@osdl.org Mon Sep 6 05:15:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 05:15:41 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86CFala019966 for ; Mon, 6 Sep 2004 05:15:36 -0700 Received: from linux.site ([192.44.87.116]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i86CFFSf013899 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 05:15:18 -0700 Date: Mon, 6 Sep 2004 05:15:23 -0700 From: Stephen Hemminger To: David Miller Cc: netdev@oss.sgi.com Subject: [PATCH] bridge deadlock on device removal Message-Id: <20040906051523.16e6a431@linux.site> Organization: OSDL X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.73 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 8441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 667 Lines: 29 Fixes: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131569 Dead lock in bridge when removing device interface module. br_del_if assumes br->lock not held. This fixes case of: brctl addbr b0 brctl addif b0 eth0 rmmod eth0 Signed-off-by: Stephen Hemminger diff -Nru a/net/bridge/br_notify.c b/net/bridge/br_notify.c --- a/net/bridge/br_notify.c 2004-09-06 04:45:31 -07:00 +++ b/net/bridge/br_notify.c 2004-09-06 04:45:31 -07:00 @@ -76,10 +76,12 @@ break; case NETDEV_UNREGISTER: + spin_unlock_bh(&br->lock); br_del_if(br, dev); - break; + goto done; } spin_unlock_bh(&br->lock); + done: return NOTIFY_DONE; } From hch@lst.de Mon Sep 6 10:23:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 10:23:11 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86HN5W1002973 for ; Mon, 6 Sep 2004 10:23:06 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i86HMt95024218 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Sep 2004 19:22:55 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i86HMtci024216; Mon, 6 Sep 2004 19:22:55 +0200 Date: Mon, 6 Sep 2004 19:22:55 +0200 From: Christoph Hellwig To: netdev@oss.sgi.com, linux-scsi@vger.kernel.org Subject: Re: [PATCH] remove iph5526 driver Message-ID: <20040906172255.GA24194@lst.de> References: <20040906101014.GA17597@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906101014.GA17597@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 681 Lines: 17 On Mon, Sep 06, 2004 at 12:10:14PM +0200, Christoph Hellwig wrote: > This driver is for totally obsolete early fibrechannel hardware and > doesn't compile anymore since early 2.5.x. In addition it'll require > a major rewrite to fit into the current framework for fc drivers. In addition this makefile fixup is needed to build with CONFIG_NET_FC: --- 1.86/drivers/net/Makefile 2004-08-22 22:57:31 +02:00 +++ edited/drivers/net/Makefile 2004-09-06 19:06:10 +02:00 @@ -184,7 +184,6 @@ obj-$(CONFIG_FEC_8XX) += fec_8xx/ obj-$(CONFIG_ARM) += arm/ -obj-$(CONFIG_NET_FC) += fc/ obj-$(CONFIG_DEV_APPLETALK) += appletalk/ obj-$(CONFIG_TR) += tokenring/ obj-$(CONFIG_WAN) += wan/ From sam@errno.com Mon Sep 6 11:14:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 11:14:44 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86IEaZw004175 for ; Mon, 6 Sep 2004 11:14:36 -0700 Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i86IDVWi084251 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Sep 2004 11:13:32 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <757AB580-0030-11D9-9224-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit Cc: jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, Jean Tourrilhes , Jouni Malinen , prism54-devel@prism54.org From: Sam Leffler Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Mon, 6 Sep 2004 11:13:31 -0700 To: Denis Vlasenko X-Mailer: Apple Mail (2.619) X-archive-position: 8443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 2380 Lines: 54 On Aug 31, 2004, at 11:11 AM, Denis Vlasenko wrote: > Hi all, > > It looks like acx100 approaches state when we can consider it's > inclusion > into mainline kernel. > > Some background information: acx100 and acx111 hardware is a bit like > Atheros and possibly prism54 "softmac": it handles mostly low-level > rx/tx stuff, leaving 802.11 stack implementation up to OS > (which is good. To have largish potentially buggy binary-only firmware > to cope with is a nightmare). > > I think what acx100 devel is working on can be best described as > "yet another 802.11 stack implementation". This is not ok. > > I think we definitely need generic 802.11 stack, with individual > drivers > providing only needed callbacks, just like it is done for wired eth > drivers. > > I think 'senior' network guys are in position to decide upon which > of currently available 802.11 stacks we should continue to work. > (Atheros has one, said to be derived from BSD, is there any others?) To correct this oft-repeated misinformation: "Atheros has one" is wrong. There is a freely available device-independent 802.11 protocol stack that is dual BSD/GPL licensed. The only relationship between this code and Atheros is that the madwifi project uses it to support Atheros hardware under Linux. Atheros holds no copyrights on any of the net80211 code. As to it being derived from BSD, that is correct but misleading. The 1st generation of this code was done for netbsd but the current code is very different and has been developed almost exclusively in Linux for over a year (though I'm now trying to find time to backport to FreeBSD). The net80211 code is actively used in netbsd to support 6+ drivers and a similar number in freebsd. There is a fairly complete implementation of the 802.11 protocols (fragmentation isn't there but will be soon) including 11g, WPA/11i, WME and WSM (coming soon). WPA/802.11i supplicant support using wpa_supplicant has been available for a while and a hostapd-based authenticator will hit CVS shortly. The management API for Linux is based on wireless extensions (WE is insufficient so like everyone else you'll find lots of private ioctls). I've suggested this code as a good starting point for a "generic 802.11 stack" but received only misinformed responses. Folks who are unaware of the work should take a look at it. Sam From vkondra@mail.ru Mon Sep 6 11:58:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 11:58:36 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86IwUoI005337 for ; Mon, 6 Sep 2004 11:58:31 -0700 Received: from [212.179.200.204] (port=38255 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1C4Oh1-000OE2-00; Mon, 06 Sep 2004 22:58:20 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Mon, 6 Sep 2004 21:57:35 +0300 User-Agent: KMail/1.7 Cc: Sam Leffler , Denis Vlasenko , jgarzik@pobox.com, acx100-devel@lists.sourceforge.net, Jean Tourrilhes , Jouni Malinen , prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> In-Reply-To: <757AB580-0030-11D9-9224-000A95AD0668@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1520535.EX0V45s7vl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409062157.52042.vkondra@mail.ru> X-Spam: Probable Spam X-archive-position: 8444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 765 Lines: 32 --nextPart1520535.EX0V45s7vl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sam, could you please provide URL where this code is hosted? I know it only as p= art=20 of madwifi.=20 Vladimir SL> I've suggested this code as a good starting point for a "generic 802.11 SL> stack" but received only misinformed responses. Folks who are unaware SL> of the work should take a look at it. SL> SL> Sam --nextPart1520535.EX0V45s7vl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPLMvqxdj7mhC6o0RAj0KAJsExyiAY/GQGsH8FgpdbpfIq6G7ewCgqeq8 3H21MwboAZl/LwwDGEM6/AE= =5WfY -----END PGP SIGNATURE----- --nextPart1520535.EX0V45s7vl-- From sam@errno.com Mon Sep 6 12:31:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 12:31:51 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86JVjIx009382 for ; Mon, 6 Sep 2004 12:31:45 -0700 Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i86JUsWi084517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Sep 2004 12:30:54 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <200409062157.52042.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <200409062157.52042.vkondra@mail.ru> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44D53E64-003B-11D9-B426-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit Cc: Denis Vlasenko , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jgarzik@pobox.com, Jean Tourrilhes , Jouni Malinen , prism54-devel@prism54.org From: Sam Leffler Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Mon, 6 Sep 2004 12:30:54 -0700 To: Vladimir Kondratiev X-Mailer: Apple Mail (2.619) X-archive-position: 8445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 382 Lines: 16 On Sep 6, 2004, at 11:57 AM, Vladimir Kondratiev wrote: > Sam, > > could you please provide URL where this code is hosted? I know it only > as part > of madwifi. The madwifi project is hosted at sourceforge http;//sourceforge.net/projects/madwifi. Source code is currently available only via cvs (but there's a web interface that you can reach through the above url). Sam From vkondra@mail.ru Mon Sep 6 13:09:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 13:09:57 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86K9qGU010331 for ; Mon, 6 Sep 2004 13:09:52 -0700 Received: from [212.179.200.204] (port=56485 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C4Po5-0000id-00; Tue, 07 Sep 2004 00:09:42 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Mon, 6 Sep 2004 23:09:18 +0300 User-Agent: KMail/1.7 Cc: Sam Leffler , Denis Vlasenko , acx100-devel@lists.sourceforge.net, jgarzik@pobox.com, Jean Tourrilhes , Jouni Malinen , prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409062157.52042.vkondra@mail.ru> <44D53E64-003B-11D9-B426-000A95AD0668@errno.com> In-Reply-To: <44D53E64-003B-11D9-B426-000A95AD0668@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5058822.29dr7VZc3Q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409062309.26113.vkondra@mail.ru> X-Spam: Probable Spam X-archive-position: 8446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1054 Lines: 38 --nextPart5058822.29dr7VZc3Q Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I know about madwifi. I wondering whether there is URL for net80211, or it= =20 exist only as part of madwifi. Thanks, Vladimir On Monday 06 September 2004 22:30, Sam Leffler wrote: SL> On Sep 6, 2004, at 11:57 AM, Vladimir Kondratiev wrote: SL> SL> > Sam, SL> > SL> > could you please provide URL where this code is hosted? I know it only SL> > as part SL> > of madwifi. SL> SL> The madwifi project is hosted at sourceforge SL> http;//sourceforge.net/projects/madwifi. Source code is currently SL> available only via cvs (but there's a web interface that you can reach SL> through the above url). SL> SL> Sam --nextPart5058822.29dr7VZc3Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPMP2qxdj7mhC6o0RAvWCAKCOyYzH/QM+TncdMjwqMy/tRv4D6gCaAnmq V0Qm5+89YAX/B/uMhdZiUf8= =pcep -----END PGP SIGNATURE----- --nextPart5058822.29dr7VZc3Q-- From sam@errno.com Mon Sep 6 16:00:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 16:00:34 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i86N0RjV013700 for ; Mon, 6 Sep 2004 16:00:27 -0700 Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i86N06Wi085214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Sep 2004 16:00:06 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Vladimir Kondratiev Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Mon, 6 Sep 2004 16:04:13 -0700 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com, Denis Vlasenko , acx100-devel@lists.sourceforge.net, jgarzik@pobox.com, Jean Tourrilhes , Jouni Malinen , prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <44D53E64-003B-11D9-B426-000A95AD0668@errno.com> <200409062309.26113.vkondra@mail.ru> In-Reply-To: <200409062309.26113.vkondra@mail.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409061604.13045.sam@errno.com> X-archive-position: 8447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 255 Lines: 7 On Monday 06 September 2004 01:09 pm, Vladimir Kondratiev wrote: > I know about madwifi. I wondering whether there is URL for net80211, or it > exist only as part of madwifi. It only exists as part of other systems (madwifi, netbsd, freebsd, etc.) Sam From davem@davemloft.net Mon Sep 6 18:26:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 18:26:20 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i871QFeS020057 for ; Mon, 6 Sep 2004 18:26:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4Uhk-00006n-00; Mon, 06 Sep 2004 18:23:28 -0700 Date: Mon, 6 Sep 2004 18:23:28 -0700 From: "David S. Miller" To: Sam Leffler Cc: vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-Id: <20040906182328.08faf843.davem@davemloft.net> In-Reply-To: <757AB580-0030-11D9-9224-000A95AD0668@errno.com> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 470 Lines: 12 On Mon, 6 Sep 2004 11:13:31 -0700 Sam Leffler wrote: > I've suggested this code as a good starting point for a "generic 802.11 > stack" but received only misinformed responses. Sam, I've told you multiple times why your stack isn't a good starting point. It isn't implemented as a true network stack, like IPV4, Appletalk, etc. Instead it's a gross input packet hooked packet eater thing that's an ugly wart bolted onto the side of the driver API. From sam@errno.com Mon Sep 6 21:29:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 21:29:40 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i874TYRI001353 for ; Mon, 6 Sep 2004 21:29:35 -0700 Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i874SiWi086212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Sep 2004 21:28:44 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: "David S. Miller" Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Mon, 6 Sep 2004 21:32:49 -0700 User-Agent: KMail/1.6.2 Cc: vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> In-Reply-To: <20040906182328.08faf843.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409062132.49356.sam@errno.com> X-archive-position: 8449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 1625 Lines: 33 On Monday 06 September 2004 06:23 pm, David S. Miller wrote: > On Mon, 6 Sep 2004 11:13:31 -0700 > > Sam Leffler wrote: > > I've suggested this code as a good starting point for a "generic 802.11 > > stack" but received only misinformed responses. > > Sam, I've told you multiple times why your stack isn't a good > starting point. It isn't implemented as a true network stack, > like IPV4, Appletalk, etc. Instead it's a gross input packet > hooked packet eater thing that's an ugly wart bolted onto the > side of the driver API. Actually, this is the first time you've said anything to me about this code. We corresponded intensely for about a week 2+ years ago after which you declared you now knew how to "write an 802.11 stack right" and were going to do it that weekend. I waited but it seems the sum total result was the shell of code that Jeff referenced in a previous note. Perhaps you can point me at a description of what a "true network stack" means to you. I'm guessing this has to do with your wanting queues inserted at various places instead of direct handoffs. Regardless, I've never suggested the current code is suitable as-is but rather should be reshaped to suit the intended structure of the system. There is a lot of hard-earned experience in the code that is independent of coding style and operational infrastructure. Anyway, the point of my note was to correct a comment in the original posting and make folks aware that working code existed from which they could crib stuff. Good luck finding someone to reimplement eveything according to your wishes. Sam From davem@davemloft.net Mon Sep 6 23:51:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 06 Sep 2004 23:51:09 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i876p2vQ005579 for ; Mon, 6 Sep 2004 23:51:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4Zkr-0000Nd-00; Mon, 06 Sep 2004 23:47:01 -0700 Date: Mon, 6 Sep 2004 23:47:01 -0700 From: "David S. Miller" To: Sam Leffler Cc: vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-Id: <20040906234701.511a8940.davem@davemloft.net> In-Reply-To: <200409062132.49356.sam@errno.com> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1022 Lines: 23 On Mon, 6 Sep 2004 21:32:49 -0700 Sam Leffler wrote: > Actually, this is the first time you've said anything to me about this code. I do remember telling you how much I was against this element of your design. At the time, you were not willing to rearchitect things and you were in a sort-of bug-fix only mode. > Perhaps you can point me at a description of what a "true network stack" means > to you. It means passing the 802.11 protocol packets into the networking just like any other type of packet, via netif_rx() or netif_receive_skb(). Creating an ETH_P_80211 protocol type and registering the stack via dev_add_pack() just like any other real protocol layer does. Then responses generated in that 802.11 stack need to feed packets back out to the network via the normal and usual methods of transmitting packets in the networking, namely dev_queue_xmit(). That is exactly what my shell protocol layer does, and it is exactly how a real 802.11 soft stack should be implemented and operate. From olh@suse.de Tue Sep 7 03:00:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 03:00:45 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i879xxvr014849 for ; Tue, 7 Sep 2004 03:00:00 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 253AEB9CB72; Tue, 7 Sep 2004 11:59:45 +0200 (CEST) Date: Mon, 6 Sep 2004 15:36:00 +0200 From: Olaf Hering To: Jeff Garzik , netdev@oss.sgi.com Cc: linuxppc-dev@lists.linuxppc.org Subject: [PATCH] mark mace and bmac as ppc32 only Message-ID: <20040906133600.GA9143@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-archive-position: 8451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 974 Lines: 29 mace and bmac are only used in "oldworld" PowerMacs. Mark them as ppc32 only. diff -purN linux-2.6.9-rc1-bk13.orig/drivers/net/Kconfig linux-2.6.9-rc1-bk13/drivers/net/Kconfig --- linux-2.6.9-rc1-bk13.orig/drivers/net/Kconfig 2004-09-06 15:23:35.000000000 +0200 +++ linux-2.6.9-rc1-bk13/drivers/net/Kconfig 2004-09-06 15:27:26.290604859 +0200 @@ -200,7 +200,7 @@ source "drivers/net/arm/Kconfig" config MACE tristate "MACE (Power Mac ethernet) support" - depends on NET_ETHERNET && PPC_PMAC + depends on NET_ETHERNET && PPC_PMAC && PPC32 select CRC32 help Power Macintoshes and clones with Ethernet built-in on the @@ -223,7 +223,7 @@ config MACE_AAUI_PORT config BMAC tristate "BMAC (G3 ethernet) support" - depends on NET_ETHERNET && PPC_PMAC + depends on NET_ETHERNET && PPC_PMAC && PPC32 select CRC32 help Say Y for support of BMAC Ethernet interfaces. These are used on G3 -- USB is for mice, FireWire is for men! sUse lINUX ag, nÃœRNBERG From hadi@cyberus.ca Tue Sep 7 03:18:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 03:18:55 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87AIoQl015467 for ; Tue, 7 Sep 2004 03:18:50 -0700 Received: from localhost.tpn.ch ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090703200939:31348 ; Tue, 7 Sep 2004 03:20:09 -0700 Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system From: jamal Reply-To: hadi@cyberus.ca To: Jeff Sipek Cc: Stephen Hemminger , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <200409051219.47590.jeffpc@optonline.net> References: <200409031307.01240.jeffpc@optonline.net> <200409031744.32970.jeffpc@optonline.net> <1094303999.1633.116.camel@jzny.localdomain> <200409051219.47590.jeffpc@optonline.net> Organization: jamalopolis Message-Id: <1094460391.1151.26.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Sep 2004 06:18:11 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/07/2004 03:20:09 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/07/2004 03:20:12 AM, Serialize complete at 09/07/2004 03:20:12 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 566 Lines: 19 On Sun, 2004-09-05 at 12:19, Jeff Sipek wrote: > On Saturday 04 September 2004 09:19, jamal wrote: > > I have a feeling this was discussed somewhere(other than netdev) and i > > missed it. Why isnt this watch64 being done in user space? > > There was a discussion about 64-bit network statistics about a year ago on > lkml. Sorry unsubscribed from lkml since summer of '94. [net related discussions should really happen on netdev]. > watch64 is a generic so that anyone in the kernel can use it. Ok - so why does this have to be in the kernel? cheers, jamal From util@deuroconsult.ro Tue Sep 7 03:36:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 03:36:07 -0700 (PDT) Received: from hosting.rdsbv.ro (webhosting.rdsbv.ro [213.157.185.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Aa298016053 for ; Tue, 7 Sep 2004 03:36:02 -0700 Received: from hosting.rdsbv.ro (hosting.rdsbv.ro [213.157.185.164]) by hosting.rdsbv.ro (8.12.11/8.12.11) with ESMTP id i87AZq1Z009700; Tue, 7 Sep 2004 13:35:52 +0300 Date: Tue, 7 Sep 2004 13:35:52 +0300 (EEST) From: "Catalin(ux aka Dino) BOIE" X-X-Sender: util@hosting.rdsbv.ro To: netdev@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: [PATCH] Trivial fix for out of bounds array access in xfrm4_policy_check Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1646943047-1948299716-1094553352=:8637" X-archive-position: 8453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: util@deuroconsult.ro Precedence: bulk X-list: netdev Content-Length: 1831 Lines: 42 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1646943047-1948299716-1094553352=:8637 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hello! Coverity found a bug in accessing xfrm4_policy_check using XFRM_POLICY_FWD (=2) as index in sk->sk_policy. sk->sk_policy[] is defined in sock.h as: struct xfrm_policy *sk_policy[2]; Attached is the fix. http://linuxbugs.coverity.com/external/editbugparent.php?viewbugid=2138&checkers%5B%5D=all&status%5B%5D=BUG&status%5B%5D=UNINSPECTED&status%5B%5D=UNKNOWN&status%5B%5D=DON%27T%20CARE&status%5B%5D=PENDING&product%5B%5D=all&component%5B%5D=all&file=&fn=&sortby=reverse_rank&before=&after=&curpage=2&bugid=-1&comment=&reason= --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ---1646943047-1948299716-1094553352=:8637 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="out-of-bounds-xfrm_policy.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="out-of-bounds-xfrm_policy.patch" LS0tIGxpbnV4L2luY2x1ZGUvbmV0L3NvY2suaAkyMDA0LTA5LTA3IDEzOjEz OjMxLjAwMDAwMDAwMCArMDMwMA0KKysrIG15bGludXgvaW5jbHVkZS9uZXQv c29jay5oCTIwMDQtMDktMDcgMTM6MTQ6MzYuMDAwMDAwMDAwICswMzAwDQpA QCAtMjAxLDcgKzIwMSw3IEBAIHN0cnVjdCBzb2NrIHsNCiAJd2FpdF9xdWV1 ZV9oZWFkX3QJKnNrX3NsZWVwOw0KIAlzdHJ1Y3QgZHN0X2VudHJ5CSpza19k c3RfY2FjaGU7DQogCXJ3bG9ja190CQlza19kc3RfbG9jazsNCi0Jc3RydWN0 IHhmcm1fcG9saWN5CSpza19wb2xpY3lbMl07DQorCXN0cnVjdCB4ZnJtX3Bv bGljeQkqc2tfcG9saWN5WzNdOw0KIAlhdG9taWNfdAkJc2tfcm1lbV9hbGxv YzsNCiAJc3RydWN0IHNrX2J1ZmZfaGVhZAlza19yZWNlaXZlX3F1ZXVlOw0K IAlhdG9taWNfdAkJc2tfd21lbV9hbGxvYzsNCg== ---1646943047-1948299716-1094553352=:8637-- From ak@suse.de Tue Sep 7 04:57:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 04:57:17 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87BvASp022072 for ; Tue, 7 Sep 2004 04:57:11 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id BD582B9DCC9; Tue, 7 Sep 2004 13:56:55 +0200 (CEST) Date: Tue, 7 Sep 2004 13:56:55 +0200 From: Andi Kleen To: Herbert Xu Cc: Andi Kleen , davem@redhat.com, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [PATCH] Do less atomic count changes in dev_queue_xmit Message-ID: <20040907115655.GA25051@wotan.suse.de> References: <20040904135439.GA23934@wotan.suse.de> <20040905220341.GA13217@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040905220341.GA13217@gondor.apana.org.au> X-archive-position: 8454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 3842 Lines: 144 On Mon, Sep 06, 2004 at 08:03:41AM +1000, Herbert Xu wrote: > On Sat, Sep 04, 2004 at 01:54:39PM +0000, Andi Kleen wrote: > > > > diff -u linux-2.6.8/net/core/dev.c-o linux-2.6.8/net/core/dev.c > > --- linux-2.6.8/net/core/dev.c-o 2004-09-04 13:10:47.000000000 +0000 > > +++ linux-2.6.8/net/core/dev.c 2004-09-04 13:47:16.765722813 +0000 > > @@ -1249,14 +1249,14 @@ > > return 0; > > } > > > > -#define HARD_TX_LOCK_BH(dev, cpu) { \ > > +#define HARD_TX_LOCK(dev, cpu) { \ > > if ((dev->features & NETIF_F_LLTX) == 0) { \ > > spin_lock_bh(&dev->xmit_lock); \ > > You can remove the _bh here as well. Ok done. > > > @@ -1358,12 +1361,11 @@ > > Either shot noqueue qdisc, it is even simpler 8) > > */ > > if (dev->flags & IFF_UP) { > > - int cpu = get_cpu(); > > + int cpu = smp_processor_id(); /* ok because BHs are off */ > > Hmm this means that the loopback xmit function will now execute with > BH/preempt turned off. Is this what we want? I think so yes. It is not that costly. David, can you please consider this patch, thanks? -Andi --------------------------------------------------------------- Streamline atomic count handling in queue xmit fast path. Only do it once instead of multiple times. diff -u linux-2.6.8/net/core/dev.c-o linux-2.6.8/net/core/dev.c --- linux-2.6.8/net/core/dev.c-o 2004-09-04 13:10:47.000000000 +0000 +++ linux-2.6.8/net/core/dev.c 2004-09-07 08:09:52.000000000 +0000 @@ -1249,17 +1249,17 @@ return 0; } -#define HARD_TX_LOCK_BH(dev, cpu) { \ +#define HARD_TX_LOCK(dev, cpu) { \ if ((dev->features & NETIF_F_LLTX) == 0) { \ - spin_lock_bh(&dev->xmit_lock); \ + spin_lock(&dev->xmit_lock); \ dev->xmit_lock_owner = cpu; \ } \ } -#define HARD_TX_UNLOCK_BH(dev) { \ +#define HARD_TX_UNLOCK(dev) { \ if ((dev->features & NETIF_F_LLTX) == 0) { \ dev->xmit_lock_owner = -1; \ - spin_unlock_bh(&dev->xmit_lock); \ + spin_unlock(&dev->xmit_lock); \ } \ } @@ -1313,7 +1313,12 @@ if (skb_checksum_help(&skb, 0)) goto out_kfree_skb; - rcu_read_lock(); + + /* Disable soft irqs for various locks below. Also + * stops preemption for RCU. + */ + local_bh_disable(); + /* Updates of qdisc are serialized by queue_lock. * The struct Qdisc which is pointed to by qdisc is now a * rcu structure - it may be accessed without acquiring @@ -1332,18 +1337,16 @@ #endif if (q->enqueue) { /* Grab device queue */ - spin_lock_bh(&dev->queue_lock); + spin_lock(&dev->queue_lock); rc = q->enqueue(skb, q); qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); - rcu_read_unlock(); + spin_unlock(&dev->queue_lock); rc = rc == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : rc; goto out; } - rcu_read_unlock(); /* The device has no queue. Common case for software devices: loopback, all the sorts of tunnels... @@ -1358,12 +1361,11 @@ Either shot noqueue qdisc, it is even simpler 8) */ if (dev->flags & IFF_UP) { - int cpu = get_cpu(); + int cpu = smp_processor_id(); /* ok because BHs are off */ if (dev->xmit_lock_owner != cpu) { - HARD_TX_LOCK_BH(dev, cpu); - put_cpu(); + HARD_TX_LOCK(dev, cpu); if (!netif_queue_stopped(dev)) { if (netdev_nit) @@ -1371,17 +1373,16 @@ rc = 0; if (!dev->hard_start_xmit(skb, dev)) { - HARD_TX_UNLOCK_BH(dev); + HARD_TX_UNLOCK(dev); goto out; } } - HARD_TX_UNLOCK_BH(dev); + HARD_TX_UNLOCK(dev); if (net_ratelimit()) printk(KERN_CRIT "Virtual device %s asks to " "queue packet!\n", dev->name); goto out_enetdown; } else { - put_cpu(); /* Recursion is detected! It is possible, * unfortunately */ if (net_ratelimit()) @@ -1394,6 +1395,7 @@ out_kfree_skb: kfree_skb(skb); out: + local_bh_enable(); return rc; } From ak@suse.de Tue Sep 7 05:08:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 05:08:15 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87C893Z022627 for ; Tue, 7 Sep 2004 05:08:10 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 3D8EAB9AC39; Tue, 7 Sep 2004 14:05:32 +0200 (CEST) Date: Tue, 7 Sep 2004 14:05:32 +0200 From: Andi Kleen To: davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040907120532.GB25051@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 4874 Lines: 162 New version of the NETIF_F_LLTX for network devices patch. This allows network drivers to set the NETIF_F_LLTX flag and then do their own locking in start_queue_xmit. This lowers locking overhead in this critical path. The drivers can use try lock if they want and return -1 when the lock wasn't grabbed. In this case the packet will be requeued. For better compatibility this is only done for drivers with LLTX set, others don't give a special meaning to -1. Most of the modern drivers who have a lock around hard_start_xmit can just set this flag. It may be a good idea to convert the spin lock there to a try lock. The only thing that should be audited is that they do enough locking in the set_multicast_list function too, and not also rely on xmit_lock here. Now doesn't move any code around and does things with gotos instead. The loop printk is also still there even for NETIF_F_LLTX For drivers that don't set the new flag nothing changes. Please consider applying. -Andi diff -u linux-2.6.8/net/core/pktgen.c-LLTX linux-2.6.8/net/core/pktgen.c --- linux-2.6.8/net/core/pktgen.c-LLTX 2004-09-04 12:47:05.000000000 +0000 +++ linux-2.6.8/net/core/pktgen.c 2004-09-04 14:07:12.000000000 +0000 @@ -634,7 +634,8 @@ nr_frags = skb_shinfo(skb)->nr_frags; - spin_lock_bh(&odev->xmit_lock); + if (!(odev->features & NETIF_F_LLTX)) + spin_lock_bh(&odev->xmit_lock); if (!netif_queue_stopped(odev)) { atomic_inc(&skb->users); @@ -659,8 +660,8 @@ last_ok = 0; } - - spin_unlock_bh(&odev->xmit_lock); + if (!(odev->features & NETIF_F_LLTX)) + spin_unlock_bh(&odev->xmit_lock); if (info->ipg) { /* Try not to busy-spin if we have larger sleep times. diff -u linux-2.6.8/net/sched/sch_generic.c-LLTX linux-2.6.8/net/sched/sch_generic.c --- linux-2.6.8/net/sched/sch_generic.c-LLTX 2004-09-04 12:47:05.000000000 +0000 +++ linux-2.6.8/net/sched/sch_generic.c 2004-09-07 11:58:45.595363313 +0000 @@ -97,46 +97,73 @@ /* Dequeue packet */ if ((skb = q->dequeue(q)) != NULL) { - if (spin_trylock(&dev->xmit_lock)) { + unsigned nolock = (dev->features & NETIF_F_LLTX); + /* + * When the driver has LLTX set it does its own locking + * in start_xmit. No need to add additional overhead by + * locking again. These checks are worth it because + * even uncongested locks can be quite expensive. + * The driver can do trylock like here too, in case + * of lock congestion it should return -1 and the packet + * will be requeued. + */ + if (!nolock) { + if (!spin_trylock(&dev->xmit_lock)) { + collision: + /* So, someone grabbed the driver. */ + + /* It may be transient configuration error, + when hard_start_xmit() recurses. We detect + it by checking xmit owner and drop the + packet when deadloop is detected. + */ + if (dev->xmit_lock_owner == smp_processor_id()) { + kfree_skb(skb); + if (net_ratelimit()) + printk(KERN_DEBUG "Dead loop on netdevice %s, fix it urgently!\n", dev->name); + return -1; + } + __get_cpu_var(netdev_rx_stat).cpu_collision++; + goto requeue; + } /* Remember that the driver is grabbed by us. */ dev->xmit_lock_owner = smp_processor_id(); - + } + + { /* And release queue */ spin_unlock(&dev->queue_lock); if (!netif_queue_stopped(dev)) { + int ret; if (netdev_nit) dev_queue_xmit_nit(skb, dev); - if (dev->hard_start_xmit(skb, dev) == 0) { - dev->xmit_lock_owner = -1; - spin_unlock(&dev->xmit_lock); - + /* hard_start_xmit returns: + 0 device not ready + 1 everything ok + -1 didn't get device lock (for LLTX) + */ + ret = dev->hard_start_xmit(skb, dev); + if (ret == 0) { + if (!nolock) { + dev->xmit_lock_owner = -1; + spin_unlock(&dev->xmit_lock); + } spin_lock(&dev->queue_lock); return -1; } + if (ret == -1 && nolock) + goto collision; } /* Release the driver */ - dev->xmit_lock_owner = -1; - spin_unlock(&dev->xmit_lock); + if (!nolock) { + dev->xmit_lock_owner = -1; + spin_unlock(&dev->xmit_lock); + } spin_lock(&dev->queue_lock); q = dev->qdisc; - } else { - /* So, someone grabbed the driver. */ - - /* It may be transient configuration error, - when hard_start_xmit() recurses. We detect - it by checking xmit owner and drop the - packet when deadloop is detected. - */ - if (dev->xmit_lock_owner == smp_processor_id()) { - kfree_skb(skb); - if (net_ratelimit()) - printk(KERN_DEBUG "Dead loop on netdevice %s, fix it urgently!\n", dev->name); - return -1; - } - __get_cpu_var(netdev_rx_stat).cpu_collision++; } /* Device kicked us out :( @@ -149,6 +176,7 @@ 3. device is buggy (ppp) */ + requeue: q->ops->requeue(skb, q); netif_schedule(dev); return 1; From ak@suse.de Tue Sep 7 05:18:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 05:19:00 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87CItrb023062 for ; Tue, 7 Sep 2004 05:18:56 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 63E98B9E117; Tue, 7 Sep 2004 14:18:41 +0200 (CEST) Date: Tue, 7 Sep 2004 14:18:41 +0200 From: Andi Kleen To: davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] LLTX for tg3 Message-ID: <20040907121841.GA4398@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 959 Lines: 30 Add LLTX suppor to tg3. Locking was already safe for it, so only trivial changes. Depends on the LLTX patch sent earlier. diff -u linux-2.6.8/drivers/net/tg3.c-o linux-2.6.8/drivers/net/tg3.c --- linux-2.6.8/drivers/net/tg3.c-o 2004-09-04 13:10:46.000000000 +0000 +++ linux-2.6.8/drivers/net/tg3.c 2004-09-07 08:17:36.000000000 +0000 @@ -3036,7 +3036,11 @@ * So we really do need to disable interrupts when taking * tx_lock here. */ - spin_lock_irqsave(&tp->tx_lock, flags); + local_irq_save(flags); + if (!spin_trylock(&tp->tx_lock)) { + local_irq_restore(flags); + return -1; + } /* This is a hard error, log it. */ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { @@ -8255,6 +8259,7 @@ if (pci_using_dac) dev->features |= NETIF_F_HIGHDMA; + dev->features |= NETIF_F_LLTX; #if TG3_VLAN_TAG_USED dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX; dev->vlan_rx_register = tg3_vlan_rx_register; From herbert@gondor.apana.org.au Tue Sep 7 05:46:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 05:47:03 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Ckr69023753 for ; Tue, 7 Sep 2004 05:46:54 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4fMi-0008Q6-00; Tue, 07 Sep 2004 22:46:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4fMc-000817-00; Tue, 07 Sep 2004 22:46:22 +1000 From: Herbert Xu To: util@deuroconsult.ro (Catalinux aka Dino BOIE) Subject: Re: [PATCH] Trivial fix for out of bounds array access in xfrm4_policy_check Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Tue, 07 Sep 2004 22:46:22 +1000 X-archive-position: 8457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 552 Lines: 17 Catalinux aka Dino BOIE wrote: > > Coverity found a bug in accessing xfrm4_policy_check using XFRM_POLICY_FWD > (=2) as index in sk->sk_policy. > > sk->sk_policy[] is defined in sock.h as: > > struct xfrm_policy *sk_policy[2]; > > Attached is the fix. This is bogus as if the packet is forwarded then sk == NULL. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From SRS0+cdae3b82a2e6926aca13+380+infradead.org+dwmw2@canuck.srs.infradead.org Tue Sep 7 06:36:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 06:36:58 -0700 (PDT) Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Darn6025294 for ; Tue, 7 Sep 2004 06:36:54 -0700 Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with asmtp (Exim 4.33 #1 (Red Hat Linux)) id 1C4g9L-0008Vn-8j; Tue, 07 Sep 2004 09:36:43 -0400 Subject: [PATCH] Compat32 setsockopt overzealous conversions From: David Woodhouse To: netdev@oss.sgi.com Cc: davem@redhat.com Content-Type: text/plain Date: Tue, 07 Sep 2004 14:23:00 +0100 Message-Id: <1094563381.5122.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 1513 Lines: 38 compat_sys_setsockopt() is a little overzealous about converting 32-bit stuff into 64-bit. It should match on level _and_ optname, not just optname. Currently it eats the IPV6_V6ONLY sockopt because its value (26) happens to match SO_ATTACH_FILTER. This makes it at least check 'level' for everything but IPT_SO_SET_REPLACE == IPT6_SO_SET_REPLACE, because that does seem to be the same in different levels. But do_netfilter_replace() is another can of worms entirely -- it doesn't actually work either, because some netfilter modules (like ipt_limit) include kernel-only bits which change size in the structure they share with userspace. --- net/compat.c~ 2004-08-14 06:37:15.000000000 +0100 +++ net/compat.c 2004-09-03 17:47:26.260926176 +0100 @@ -455,13 +455,15 @@ asmlinkage long compat_sys_setsockopt(int fd, int level, int optname, char __user *optval, int optlen) { + /* SO_SET_REPLACE seems to be the same in all levels */ if (optname == IPT_SO_SET_REPLACE) return do_netfilter_replace(fd, level, optname, optval, optlen); - if (optname == SO_ATTACH_FILTER) + if (level == SOL_SOCKET && optname == SO_ATTACH_FILTER) return do_set_attach_filter(fd, level, optname, optval, optlen); - if (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO) + if (level == SOL_SOCKET && + (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO)) return do_set_sock_timeout(fd, level, optname, optval, optlen); return sys_setsockopt(fd, level, optname, optval, optlen); -- dwmw2 From hch@lst.de Tue Sep 7 08:18:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 08:18:12 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87FI6ki029520 for ; Tue, 7 Sep 2004 08:18:07 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i87FHr95009747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 17:17:53 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i87FHrVu009745; Tue, 7 Sep 2004 17:17:53 +0200 Date: Tue, 7 Sep 2004 17:17:53 +0200 From: Christoph Hellwig To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: [PATCH] remove secure_ipv6_id Message-ID: <20040907151753.GA9735@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 939 Lines: 36 looks like the ipv6 code doesn't need this one anymore --- 1.54/drivers/char/random.c 2004-09-03 11:08:21 +02:00 +++ edited/drivers/char/random.c 2004-09-07 15:51:23 +02:00 @@ -2279,19 +2279,7 @@ return seq; } EXPORT_SYMBOL(secure_tcpv6_sequence_number); - -__u32 secure_ipv6_id(__u32 *daddr) -{ - struct keydata *keyptr; - - keyptr = check_and_rekey(get_seconds()); - - return halfMD4Transform(daddr, keyptr->secret); -} - -EXPORT_SYMBOL(secure_ipv6_id); #endif - __u32 secure_tcp_sequence_number(__u32 saddr, __u32 daddr, __u16 sport, __u16 dport) --- 1.3/include/linux/random.h 2003-09-21 23:50:34 +02:00 +++ edited/include/linux/random.h 2004-09-07 14:07:58 +02:00 @@ -67,8 +67,6 @@ extern __u32 secure_tcpv6_sequence_number(__u32 *saddr, __u32 *daddr, __u16 sport, __u16 dport); -extern __u32 secure_ipv6_id(__u32 *daddr); - #ifndef MODULE extern struct file_operations random_fops, urandom_fops; #endif From hch@lst.de Tue Sep 7 08:19:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 08:19:34 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87FJSDA000418 for ; Tue, 7 Sep 2004 08:19:29 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i87FJJ95009785 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 17:19:19 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i87FJJZU009783; Tue, 7 Sep 2004 17:19:19 +0200 Date: Tue, 7 Sep 2004 17:19:18 +0200 From: Christoph Hellwig To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] mark inet_family_ops static Message-ID: <20040907151918.GB9735@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 1039 Lines: 34 except for a stale extern in net/sctp/protocol.c it's not referenced anywhere outside af_inet.c --- 1.74/net/ipv4/af_inet.c 2004-07-07 07:01:31 +02:00 +++ edited/net/ipv4/af_inet.c 2004-09-07 13:47:22 +02:00 @@ -837,7 +837,7 @@ .sendpage = inet_sendpage, }; -struct net_proto_family inet_family_ops = { +static struct net_proto_family inet_family_ops = { .family = PF_INET, .create = inet_create, .owner = THIS_MODULE, @@ -1157,7 +1157,6 @@ EXPORT_SYMBOL(inet_bind); EXPORT_SYMBOL(inet_dgram_connect); EXPORT_SYMBOL(inet_dgram_ops); -EXPORT_SYMBOL(inet_family_ops); EXPORT_SYMBOL(inet_getname); EXPORT_SYMBOL(inet_ioctl); EXPORT_SYMBOL(inet_listen); --- 1.72/net/sctp/protocol.c 2004-08-13 01:41:13 +02:00 +++ edited/net/sctp/protocol.c 2004-09-07 13:47:08 +02:00 @@ -81,8 +81,6 @@ kmem_cache_t *sctp_chunk_cachep; kmem_cache_t *sctp_bucket_cachep; -extern struct net_proto_family inet_family_ops; - extern int sctp_snmp_proc_init(void); extern int sctp_snmp_proc_exit(void); extern int sctp_eps_proc_init(void); From hch@lst.de Tue Sep 7 08:20:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 08:20:45 -0700 (PDT) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87FKdZg000763 for ; Tue, 7 Sep 2004 08:20:40 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i87FKU95009804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Sep 2004 17:20:30 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i87FKTfD009802; Tue, 7 Sep 2004 17:20:29 +0200 Date: Tue, 7 Sep 2004 17:20:29 +0200 From: Christoph Hellwig To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] unexport alloc_divert_blk/free_divert_blk Message-ID: <20040907152029.GC9735@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 8461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev Content-Length: 274 Lines: 14 these are called by dev.c for every device (and nowhere else) --- 1.10/net/core/dv.c 2004-04-16 22:56:10 +02:00 +++ edited/net/core/dv.c 2004-09-07 15:07:09 +02:00 @@ -553,6 +553,3 @@ break; } } - -EXPORT_SYMBOL(alloc_divert_blk); -EXPORT_SYMBOL(free_divert_blk); From greg@atheros.com Tue Sep 7 10:03:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 10:03:05 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87H2xRe003329 for ; Tue, 7 Sep 2004 10:03:00 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8808706; Tue, 07 Sep 2004 10:02:44 -0700 Message-ID: <413DE9ED.30300@atheros.com> Date: Tue, 07 Sep 2004 10:03:41 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler CC: "David S. Miller" , vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> In-Reply-To: <200409062132.49356.sam@errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 4139 Lines: 101 Oh really? What about eth_type_trans()? It is not implemented as a true network stack. Many drivers call it, but it is a gross input packet hooked eater thing that's an ugly wart bolted onto the side of the driver API. what's good for the goose, etc. My point is that there is ample precedent in the OS for common driver "assistance" subroutines that contain protocol knowledge or implement policy yet are not implemented in strict stack-like manner because it didn't make sense to do 'em that way. It seems to me that Sam's net80211 code is performing three essential functions: 1. encap/decap service for converting between 802.3 and 802.11 2. the MLME protocol (802.11 management messages and state keeping) 3. interface to upper layer ioctl stuff, particularly user-land crypto supplicants and authenticators in addition to the usual group of tools. The MLME protocol works as a stack already since it really does implement a protocol. The encap/decap could be implemented stack-like instead of eth_type_trans-like, but it seems very suboptimal to do it another way. The ioctl interfaces are a wart on the side of the driver API anyway, but let's not have an argument about that since it is a design feature of the OS inherited from unix. The complaint seems to be mainly about the encap/decap procedures which are implemented more as driver helper functions. If somebody wants to rewrite them as a stack, then go for it. I'll be interested in seeing whether or not good methods can be found for exporting driver-local information (e.g. the mac address of the AP, or the tx PHY rate needed to calculate the duration field value, or whether or not to do mac tx fragmentation, etc) up the stack without creating a pile of spaghetti to rival Microsoft's failed "native 802.11" project. I've thought about this problem and don't think there is a good answer if a layered approach to protocol implementation stipulates that each layer be self-contained. The 802.11 situation requires more data-sharing between layers than is conducive to a strict layering approach. I suspect that what's needed is a data structure tailored to wireless which can be shared between layers and common across devices. Perhaps it could be an extention to dev (wdev?) that captures the necessary sharing. But the problems don't stop there. Think for a moment about where power-save should be implemented - which layer? cheers, g Sam Leffler wrote: > On Monday 06 September 2004 06:23 pm, David S. Miller wrote: > >>On Mon, 6 Sep 2004 11:13:31 -0700 >> >>Sam Leffler wrote: >> >>>I've suggested this code as a good starting point for a "generic 802.11 >>>stack" but received only misinformed responses. >> >>Sam, I've told you multiple times why your stack isn't a good >>starting point. It isn't implemented as a true network stack, >>like IPV4, Appletalk, etc. Instead it's a gross input packet >>hooked packet eater thing that's an ugly wart bolted onto the >>side of the driver API. > > > Actually, this is the first time you've said anything to me about this code. > We corresponded intensely for about a week 2+ years ago after which you > declared you now knew how to "write an 802.11 stack right" and were going to > do it that weekend. I waited but it seems the sum total result was the shell > of code that Jeff referenced in a previous note. > > Perhaps you can point me at a description of what a "true network stack" means > to you. I'm guessing this has to do with your wanting queues inserted at > various places instead of direct handoffs. Regardless, I've never suggested > the current code is suitable as-is but rather should be reshaped to suit the > intended structure of the system. There is a lot of hard-earned experience > in the code that is independent of coding style and operational > infrastructure. > > Anyway, the point of my note was to correct a comment in the original posting > and make folks aware that working code existed from which they could crib > stuff. Good luck finding someone to reimplement eveything according to your > wishes. > > Sam From davem@davemloft.net Tue Sep 7 10:15:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 10:15:48 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87HFgjr003855 for ; Tue, 7 Sep 2004 10:15:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4jUB-0001KL-00; Tue, 07 Sep 2004 10:10:27 -0700 Date: Tue, 7 Sep 2004 10:10:27 -0700 From: "David S. Miller" To: greg chesson Cc: sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-Id: <20040907101027.7547e591.davem@davemloft.net> In-Reply-To: <413DE9ED.30300@atheros.com> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> <413DE9ED.30300@atheros.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1229 Lines: 32 On Tue, 07 Sep 2004 10:03:41 -0700 greg chesson wrote: > What about eth_type_trans()? It determines the protocol type from the ethernet header fields. It is a simple shorthand header field fetcher, not a protocol stack. You would need a eth80211_type_trans() for wireless drivers too, and surprise surprise my skeleton 802.11 stack code in fact does exactly this. > I've thought about this problem and don't think there is a good answer > if a layered approach to protocol implementation stipulates that each layer > be self-contained. In my 802.11 stack the 802.11 information structure can be found given a generic device pointer. All the wireless info can be retrieved from that, and you can use it to call the wireless stack routines if you wish as well. This is no different than how we keep ipv4 information hooked onto the generic device structure and walk between these various entities in the ipv4 and generic networking code. Please read my skeletal stack code, it is exactly how I truly believe something like this should be architected. It's all the base layout stuff that's important, the rest are details that will fit in cleanly and readily once you have a solid and firm foundation. From vkondra@mail.ru Tue Sep 7 10:22:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 10:22:52 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87HMk1I004293 for ; Tue, 7 Sep 2004 10:22:47 -0700 Received: from [81.218.208.137] (port=11904 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C4jft-000E28-00; Tue, 07 Sep 2004 21:22:35 +0400 From: Vladimir Kondratiev To: "David S. Miller" Subject: generic 802.11 stack Date: Tue, 7 Sep 2004 20:22:07 +0300 User-Agent: KMail/1.7 References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409062132.49356.sam@errno.com> <20040906234701.511a8940.davem@davemloft.net> In-Reply-To: <20040906234701.511a8940.davem@davemloft.net> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1168438.PPxzXlkP8u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409072022.14330.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2133 Lines: 65 --nextPart1168438.PPxzXlkP8u Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dave, I'd like to evaluate possibility to use your stack for real driver. 80211 h= ave=20 some specifics thus we need to answer following questions: =2D some devices handles almost all MAC in firmware; some - handle control = frame=20 exchange in firmware, rest - on host; some use other separation of work=20 between host and firmware. So, quite flexible mechanism to specify offloadi= ng=20 of parts of .11 stack to firmware required. What is best way?=20 netdev->features? =2D there are cases when PHY information needed, to make decisions (like se= lect=20 AP from list), or for information purposes (sniffer). What is your vision h= ow=20 to do this? I.e. provide some standard PHY header before MAC header, out of= =20 band (use cb?) I see the following info that may be interesting: rate;modulation;preamble;TSF timer;RSSI;antenna;signal;noise;AGC. This list= =20 may vary from NIC to NIC. =2D there is PHY level information that may be needed for Tx: modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS to= =20 self). Same question as above: how to provide it? =2D there is some interesting information that may come from Tx status, lik= e=20 success indication, last rate, retry count, energy in channel after packet,= =20 actual backoff time. =2D is it feasible to do rate scaling in generic way in stack? Or should it= be=20 done always in the driver? =2D Since WME and TGe introduction, NICs will likely to have multiple Tx qu= eues.=20 It would be wise for driver to use multiple Tx queues and start/stop them=20 separately, like have all functions netif_start_queue() etc. have additiona= l=20 parameter - queue number. Will it fit into your stack? --nextPart1168438.PPxzXlkP8u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPe5Fqxdj7mhC6o0RAmd7AKCJKmxTQk6dRx2cnDaYQyiLoQ0USwCglzfj aPOJ5j1um3UnBtf1NnS8H3w= =JkZo -----END PGP SIGNATURE----- --nextPart1168438.PPxzXlkP8u-- From davem@davemloft.net Tue Sep 7 10:34:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 10:34:56 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87HYqWP005415 for ; Tue, 7 Sep 2004 10:34:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4jp5-0001Ob-00; Tue, 07 Sep 2004 10:32:03 -0700 Date: Tue, 7 Sep 2004 10:32:03 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: netdev@oss.sgi.com Subject: Re: generic 802.11 stack Message-Id: <20040907103203.52199758.davem@davemloft.net> In-Reply-To: <200409072022.14330.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409062132.49356.sam@errno.com> <20040906234701.511a8940.davem@davemloft.net> <200409072022.14330.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2532 Lines: 57 On Tue, 7 Sep 2004 20:22:07 +0300 Vladimir Kondratiev wrote: > I'd like to evaluate possibility to use your stack for real driver. 80211 have > some specifics thus we need to answer following questions: > > - some devices handles almost all MAC in firmware; some - handle control frame > exchange in firmware, rest - on host; some use other separation of work > between host and firmware. So, quite flexible mechanism to specify offloading > of parts of .11 stack to firmware required. What is best way? > netdev->features? Use function pointers for the handlers that can be overridden by the driver, or something similar like that. Start with "pure %100 software" stack, then once that is fully functional work back to add the necessary hooks to support partial software stacks. > - there are cases when PHY information needed, to make decisions (like select > AP from list), or for information purposes (sniffer). What is your vision how > to do this? I.e. provide some standard PHY header before MAC header, out of > band (use cb?) This should be stored in the 802.11 specific information struct which I allocate for each generic device which registers with the 802.11 layer. There should be a standard 802.11 stack interface the driver can use the pass the information in so that the details of the layout inside of the 802.11 device information structure need not be exported publicly. > - there is PHY level information that may be needed for Tx: > modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS to > self). Same question as above: how to provide it? Same way. > - there is some interesting information that may come from Tx status, like > success indication, last rate, retry count, energy in channel after packet, > actual backoff time. Feed it back into the software stack with some kind of function call. > - is it feasible to do rate scaling in generic way in stack? Or should it be > done always in the driver? I believe so. > - Since WME and TGe introduction, NICs will likely to have multiple Tx queues. > It would be wise for driver to use multiple Tx queues and start/stop them > separately, like have all functions netif_start_queue() etc. have additional > parameter - queue number. Will it fit into your stack? We can represent this using multiple generic netdev objects, perhaps. Or we can finally start supporting multiple queues in the generic device struct. I like the latter idea better, and it allows us to do other things as well. From vkondra@mail.ru Tue Sep 7 11:06:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 11:06:48 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87I6hbr006528 for ; Tue, 7 Sep 2004 11:06:44 -0700 Received: from [81.218.208.137] (port=15401 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C4kMT-000NWo-00; Tue, 07 Sep 2004 22:06:34 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: generic 802.11 stack Date: Tue, 7 Sep 2004 21:06:24 +0300 User-Agent: KMail/1.7 Cc: "David S. Miller" References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072022.14330.vkondra@mail.ru> <20040907103203.52199758.davem@davemloft.net> In-Reply-To: <20040907103203.52199758.davem@davemloft.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1554531.97eGOXWn7S"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409072106.28334.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2025 Lines: 55 --nextPart1554531.97eGOXWn7S Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline DS> > - there are cases when PHY information needed, to make decisions (like select DS> > AP from list), or for information purposes (sniffer). What is your vision how DS> > to do this? I.e. provide some standard PHY header before MAC header, out of DS> > band (use cb?) DS> DS> This should be stored in the 802.11 specific information struct which DS> I allocate for each generic device which registers with the 802.11 DS> layer. There should be a standard 802.11 stack interface the driver DS> can use the pass the information in so that the details of the layout DS> inside of the 802.11 device information structure need not be exported DS> publicly. DS> DS> > - there is PHY level information that may be needed for Tx: DS> > modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, C= TS to DS> > self). Same question as above: how to provide it? DS> DS> Same way. May be I did not stated the question clearly. This information need to be=20 specified per packet. So question ramains: how to specify PHY info per skb. DS> DS> > - there is some interesting information that may come from Tx status, like DS> > success indication, last rate, retry count, energy in channel after packet, DS> > actual backoff time. DS> DS> Feed it back into the software stack with some kind of function call. DS> I tend to agree, with one note that it should be some mechanism to associat= e=20 this information with original packet. One implementation example would be = to=20 keep original skb in some "in process" queue, and actually free it after Tx= =20 status arrival. --nextPart1554531.97eGOXWn7S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPfikqxdj7mhC6o0RAiijAKCG1fmGpqfZ6gHtKGSB/adxuCe0FgCeMpk+ UwVP3MYd0InzHQF1JWAWCYQ= =Zv0P -----END PGP SIGNATURE----- --nextPart1554531.97eGOXWn7S-- From davem@davemloft.net Tue Sep 7 11:11:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 11:11:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87IB2e4006870 for ; Tue, 7 Sep 2004 11:11:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4kO5-0001TX-00; Tue, 07 Sep 2004 11:08:13 -0700 Date: Tue, 7 Sep 2004 11:08:13 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: netdev@oss.sgi.com Subject: Re: generic 802.11 stack Message-Id: <20040907110813.6b463f3a.davem@davemloft.net> In-Reply-To: <200409072106.28334.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072022.14330.vkondra@mail.ru> <20040907103203.52199758.davem@davemloft.net> <200409072106.28334.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 406 Lines: 15 On Tue, 7 Sep 2004 21:06:24 +0300 Vladimir Kondratiev wrote: > May be I did not stated the question clearly. This information need to be > specified per packet. So question ramains: how to specify PHY info per skb. Use the skb->cb[] area, create: struct p80211_skb_cb { int rate; int channel; /* whatever... */ }; #define P80211_SKB_CB(skb) ((struct p80211_skb_cb *)((skb)->cb)) From greg@atheros.com Tue Sep 7 11:13:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 11:13:43 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87IDZZi007201 for ; Tue, 7 Sep 2004 11:13:37 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8810597; Tue, 07 Sep 2004 11:13:20 -0700 Message-ID: <413DFA79.501@atheros.com> Date: Tue, 07 Sep 2004 11:14:17 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> <413DE9ED.30300@atheros.com> <20040907101027.7547e591.davem@davemloft.net> In-Reply-To: <20040907101027.7547e591.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 1424 Lines: 43 I certainly agree with you about getting the base design right. Where are these bits you refer to? g David S. Miller wrote: > On Tue, 07 Sep 2004 10:03:41 -0700 > greg chesson wrote: > > >>What about eth_type_trans()? > > > It determines the protocol type from the ethernet header > fields. It is a simple shorthand header field fetcher, > not a protocol stack. > > You would need a eth80211_type_trans() for wireless > drivers too, and surprise surprise my skeleton 802.11 > stack code in fact does exactly this. > > >>I've thought about this problem and don't think there is a good answer >>if a layered approach to protocol implementation stipulates that each layer >>be self-contained. > > > In my 802.11 stack the 802.11 information structure can be > found given a generic device pointer. All the wireless info > can be retrieved from that, and you can use it to call the > wireless stack routines if you wish as well. > > This is no different than how we keep ipv4 information hooked > onto the generic device structure and walk between these various > entities in the ipv4 and generic networking code. > > Please read my skeletal stack code, it is exactly how I truly > believe something like this should be architected. It's all > the base layout stuff that's important, the rest are details > that will fit in cleanly and readily once you have a solid > and firm foundation. > From davem@davemloft.net Tue Sep 7 11:22:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 11:22:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87IMKkB007762 for ; Tue, 7 Sep 2004 11:22:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4kVm-0001VE-00; Tue, 07 Sep 2004 11:16:10 -0700 Date: Tue, 7 Sep 2004 11:16:10 -0700 From: "David S. Miller" To: greg chesson Cc: sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-Id: <20040907111610.7441377e.davem@davemloft.net> In-Reply-To: <413DFA79.501@atheros.com> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> <413DE9ED.30300@atheros.com> <20040907101027.7547e591.davem@davemloft.net> <413DFA79.501@atheros.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 305 Lines: 11 On Tue, 07 Sep 2004 11:14:17 -0700 greg chesson wrote: > I certainly agree with you about getting the base design right. > Where are these bits you refer to? See earlier in this very thread you are replying to: http://marc.theaimsgroup.com/?l=linux-netdev&m=109415745726088&w=2 :-) From vkondra@mail.ru Tue Sep 7 11:42:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 11:42:25 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87IgJtg008380 for ; Tue, 7 Sep 2004 11:42:20 -0700 Received: from [81.218.208.137] (port=17176 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1C4kuv-000HFV-00; Tue, 07 Sep 2004 22:42:09 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: generic 802.11 stack Date: Tue, 7 Sep 2004 21:41:54 +0300 User-Agent: KMail/1.7 Cc: "David S. Miller" References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072106.28334.vkondra@mail.ru> <20040907110813.6b463f3a.davem@davemloft.net> In-Reply-To: <20040907110813.6b463f3a.davem@davemloft.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6771719.9nFv9mMZL8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409072141.58893.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1440 Lines: 47 --nextPart6771719.9nFv9mMZL8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 September 2004 21:08, David S. Miller wrote: DS> On Tue, 7 Sep 2004 21:06:24 +0300 DS> Vladimir Kondratiev wrote: DS> DS> > May be I did not stated the question clearly. This information need to be DS> > specified per packet. So question ramains: how to specify PHY info per skb. DS> DS> Use the skb->cb[] area, create: DS> DS> struct p80211_skb_cb { DS> int rate; DS> int channel; DS> /* whatever... */ DS> }; DS> DS> #define P80211_SKB_CB(skb) ((struct p80211_skb_cb *)((skb)->cb)) This should be done in generic way. This information used to communicate=20 berween particular driver and generic stack. For example, Rx PHY info and T= x=20 status info should be used for in-stack generic rate scaling algorithm. To complicate it a bit, cb[] is only 48 bytes long. PHY info may easily exc= eed=20 this size, so it's better to allocate something and free it in destructor. But again, point is this structure should be generic since it is used by=20 stack. --nextPart6771719.9nFv9mMZL8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPgD2qxdj7mhC6o0RAibiAJ0TQONrdNoltPzdbwE/ALFg9SCmegCglgwM hlrmFHhTK5SQ/pGISBiqHIY= =a5zw -----END PGP SIGNATURE----- --nextPart6771719.9nFv9mMZL8-- From davem@davemloft.net Tue Sep 7 12:13:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 12:13:15 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87JD8Zj009480 for ; Tue, 7 Sep 2004 12:13:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4lMB-0001bD-00; Tue, 07 Sep 2004 12:10:19 -0700 Date: Tue, 7 Sep 2004 12:10:19 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: netdev@oss.sgi.com Subject: Re: generic 802.11 stack Message-Id: <20040907121019.733cc7aa.davem@davemloft.net> In-Reply-To: <200409072141.58893.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072106.28334.vkondra@mail.ru> <20040907110813.6b463f3a.davem@davemloft.net> <200409072141.58893.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 677 Lines: 16 On Tue, 7 Sep 2004 21:41:54 +0300 Vladimir Kondratiev wrote: > This should be done in generic way. This information used to communicate > berween particular driver and generic stack. For example, Rx PHY info and Tx > status info should be used for in-stack generic rate scaling algorithm. > > To complicate it a bit, cb[] is only 48 bytes long. PHY info may easily exceed > this size, so it's better to allocate something and free it in destructor. > > But again, point is this structure should be generic since it is used by > stack. TCP does the same thing, and if space is an issue you can use pointers in the cb[] area, other subsystems do this. From vkondra@mail.ru Tue Sep 7 12:54:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 12:54:45 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87JsdAm013523 for ; Tue, 7 Sep 2004 12:54:40 -0700 Received: from [81.218.208.137] (port=19509 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1C4m2v-0006mg-00; Tue, 07 Sep 2004 23:54:29 +0400 From: Vladimir Kondratiev To: "David S. Miller" , Sam Leffler , Jeff Garzik Subject: Re: generic 802.11 stack Date: Tue, 7 Sep 2004 22:54:12 +0300 User-Agent: KMail/1.7 Cc: netdev@oss.sgi.com, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072141.58893.vkondra@mail.ru> <20040907121019.733cc7aa.davem@davemloft.net> In-Reply-To: <20040907121019.733cc7aa.davem@davemloft.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2008819.eKJUJ3LL4V"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409072254.18804.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1676 Lines: 52 --nextPart2008819.eKJUJ3LL4V Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline DS> > This should be done in generic way. This information used to communicate DS> > berween particular driver and generic stack. For example, Rx PHY info and Tx DS> > status info should be used for in-stack generic rate scaling algorithm. DS> > DS> > To complicate it a bit, cb[] is only 48 bytes long. PHY info may easi= ly exceed DS> > this size, so it's better to allocate something and free it in destructor. DS> > DS> > But again, point is this structure should be generic since it is used by DS> > stack. DS> DS> TCP does the same thing, and if space is an issue you can use DS> pointers in the cb[] area, other subsystems do this. Sure, I agree. But this structure for PHY should be defined in stack, it is= =20 not driver's decision. Actually, I'd like to fit this stack into real life. To get real, I want, for some wireless card, write driver that will be able= to=20 Tx/Rx 802.11 frames, and let stack handle the rest. Like association,=20 roaming... What should be done to get to this stage? Jeff, your opinion on this? Sam (you represent Atheros?), would you like to cooperate to make this=20 possible? Anyone doing drivers for Intersil and Broadcom, are you on this list? Would= =20 you join this effort? --nextPart2008819.eKJUJ3LL4V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBPhHqqxdj7mhC6o0RAvh1AKCG4t+46iEN4rezX3GPNbSSLGs0JgCgkHAp /Kb6ZYVrwnMoV1LrnwD57xI= =JkRX -----END PGP SIGNATURE----- --nextPart2008819.eKJUJ3LL4V-- From afleming@freescale.com Tue Sep 7 13:36:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 13:36:09 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Ka4Xd014637 for ; Tue, 7 Sep 2004 13:36:05 -0700 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i87KZt0k026324 for ; Tue, 7 Sep 2004 13:35:55 -0700 (MST) Received: from [10.82.16.241] ([10.82.16.241]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i87IZeGA010885 for ; Tue, 7 Sep 2004 13:35:41 -0500 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <840161B2-010D-11D9-AF95-000393C30512@freescale.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: netdev@oss.sgi.com From: Andy Fleming Subject: schedule_work, a summary Date: Tue, 7 Sep 2004 15:35:54 -0500 X-Mailer: Apple Mail (2.618) X-archive-position: 8473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev Content-Length: 907 Lines: 21 Ok, so I got no response. I will summarize on the theory that people tend to ignore long emails: 1) My ethernet driver works in 2.6.8.1, but does not in newer kernels. Note that nothing in the driver has changed. So either there is a bug in the kernel now, or one has been exposed in my driver. 2) The bug causes the kernel to stop doing useful work as soon as schedule_work is called. I can confirm that the function executes to completion, and that the process of scheduling the work is terminated in try_to_wake_up() when it determines that the task (presumably the task keventd is running in) is already running. Once this happens, the kernel stops printing out information, and the bdi2000 indicates it is frequently in interrupt handling routines. 3) I desperately need to know what's wrong, and if this is not the right place to ask, please tell me where is. Thanks, Andy Fleming From davem@redhat.com Tue Sep 7 13:38:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 13:38:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87KcLbX014839 for ; Tue, 7 Sep 2004 13:38:21 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i87Kc0S0025343; Tue, 7 Sep 2004 16:38:00 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i87Kbo323427; Tue, 7 Sep 2004 16:37:50 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i87Kbmll002485; Tue, 7 Sep 2004 16:37:48 -0400 Date: Tue, 7 Sep 2004 13:35:08 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, kaber@trash.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-Id: <20040907133508.5a7aeafb.davem@redhat.com> In-Reply-To: <20040903.104050.29603454.yoshfuji@linux-ipv6.org> References: <4137681D.3000902@trash.net> <20040902144436.2c8c1337.davem@redhat.com> <20040902220343.GA3250@gondor.apana.org.au> <20040903.104050.29603454.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i87KcLbX014839 X-archive-position: 8474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 450 Lines: 13 On Fri, 03 Sep 2004 10:40:50 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In this case, we know we need more fragment(s). > So, let's fill up to maxfraglen (instead of mtu) > to avoid needless copy in the next loop. > > Signed-off-by: Hideaki YOSHIFUJI Has anyone tested or reviewed this patch? I'm just walking through my backlog trying to figure out what I need to spend time on. From davem@davemloft.net Tue Sep 7 13:42:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 13:43:04 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87KgxKl015341 for ; Tue, 7 Sep 2004 13:42:59 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4ml6-0001mv-00; Tue, 07 Sep 2004 13:40:08 -0700 Date: Tue, 7 Sep 2004 13:40:08 -0700 From: "David S. Miller" To: Dave Jones Cc: netdev@oss.sgi.com Subject: Re: Too late check in af_packet.c Message-Id: <20040907134008.28c55c87.davem@davemloft.net> In-Reply-To: <20040903205206.GT26419@redhat.com> References: <20040903205206.GT26419@redhat.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 323 Lines: 12 On Fri, 3 Sep 2004 21:52:06 +0100 Dave Jones wrote: > Using the automated source checker at coverity.com, they picked up > on some code in packet_release() where a NULL check was done > after dereferencing. Patch below. > > Signed-off-by: Dave Jones Looks great, applied. Thanks. From davem@davemloft.net Tue Sep 7 13:53:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 13:53:44 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Krd2H015850 for ; Tue, 7 Sep 2004 13:53:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4mvE-0001oz-00; Tue, 07 Sep 2004 13:50:36 -0700 Date: Tue, 7 Sep 2004 13:50:36 -0700 From: "David S. Miller" To: Herbert Xu Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: neigh_create/inetdev_destroy race? Message-Id: <20040907135036.5c80714a.davem@davemloft.net> In-Reply-To: <20040903234941.GA26247@gondor.apana.org.au> References: <20040815191450.77532d5d.davem@redhat.com> <20040816105131.GA11299@gondor.apana.org.au> <20040828234201.79556f6e.davem@davemloft.net> <20040829065031.GA786@gondor.apana.org.au> <20040830230820.7514985d.davem@davemloft.net> <20040831104139.GA2124@gondor.apana.org.au> <20040901222118.0ce4bcc6.davem@davemloft.net> <20040902130605.GA32570@gondor.apana.org.au> <20040903133623.GA23179@gondor.apana.org.au> <20040903090053.22c67bb9@dell_ss3.pdx.osdl.net> <20040903234941.GA26247@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 40 Lines: 4 Looks great Herbert, applied. Thanks. From davem@davemloft.net Tue Sep 7 13:55:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 13:55:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87KtZTQ016170 for ; Tue, 7 Sep 2004 13:55:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4mx4-0001pS-00; Tue, 07 Sep 2004 13:52:30 -0700 Date: Tue, 7 Sep 2004 13:52:30 -0700 From: "David S. Miller" To: Andi Kleen Cc: herbert@gondor.apana.org.au, ak@suse.de, davem@redhat.com, netdev@oss.sgi.com, akepner@sgi.com Subject: Re: [PATCH] Do less atomic count changes in dev_queue_xmit Message-Id: <20040907135230.447a2d8b.davem@davemloft.net> In-Reply-To: <20040907115655.GA25051@wotan.suse.de> References: <20040904135439.GA23934@wotan.suse.de> <20040905220341.GA13217@gondor.apana.org.au> <20040907115655.GA25051@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 320 Lines: 13 On Tue, 7 Sep 2004 13:56:55 +0200 Andi Kleen wrote: > David, can you please consider this patch, thanks? Applied, thanks guys. Andi can you please start providing "Signed-off-by:" lines with your patches? I can only add my own at this time, but it makes me feel better if you provide one too. Thanks. From davem@davemloft.net Tue Sep 7 14:05:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:05:05 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87L50hn016607 for ; Tue, 7 Sep 2004 14:05:00 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4n6J-0001qv-00; Tue, 07 Sep 2004 14:02:03 -0700 Date: Tue, 7 Sep 2004 14:02:03 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] bridge deadlock on device removal Message-Id: <20040907140203.0e41c8e5.davem@davemloft.net> In-Reply-To: <20040906051523.16e6a431@linux.site> References: <20040906051523.16e6a431@linux.site> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 449 Lines: 17 On Mon, 6 Sep 2004 05:15:23 -0700 Stephen Hemminger wrote: > Fixes: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131569 > Dead lock in bridge when removing device interface module. br_del_if > assumes br->lock not held. > > This fixes case of: > brctl addbr b0 > brctl addif b0 eth0 > rmmod eth0 > > Signed-off-by: Stephen Hemminger Will apply, thanks Stephen. Is this a 2.6.x only issue? From davem@davemloft.net Tue Sep 7 14:05:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:05:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87L5k4J016824 for ; Tue, 7 Sep 2004 14:05:46 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4n6z-0001rI-00; Tue, 07 Sep 2004 14:02:45 -0700 Date: Tue, 7 Sep 2004 14:02:45 -0700 From: "David S. Miller" To: Herbert Xu Cc: util@deuroconsult.ro, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Trivial fix for out of bounds array access in xfrm4_policy_check Message-Id: <20040907140245.675b7240.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 459 Lines: 17 On Tue, 07 Sep 2004 22:46:22 +1000 Herbert Xu wrote: > Catalinux aka Dino BOIE wrote: > > > > Coverity found a bug in accessing xfrm4_policy_check using XFRM_POLICY_FWD > > (=2) as index in sk->sk_policy. > > > > sk->sk_policy[] is defined in sock.h as: > > > > struct xfrm_policy *sk_policy[2]; > > > > Attached is the fix. > > This is bogus as if the packet is forwarded then sk == NULL. Agreed. From davem@davemloft.net Tue Sep 7 14:09:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:09:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87L9keH017292 for ; Tue, 7 Sep 2004 14:09:46 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4nAv-0001rp-00; Tue, 07 Sep 2004 14:06:49 -0700 Date: Tue, 7 Sep 2004 14:06:49 -0700 From: "David S. Miller" To: David Woodhouse Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Compat32 setsockopt overzealous conversions Message-Id: <20040907140649.42eaa278.davem@davemloft.net> In-Reply-To: <1094563381.5122.8.camel@localhost.localdomain> References: <1094563381.5122.8.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 841 Lines: 19 On Tue, 07 Sep 2004 14:23:00 +0100 David Woodhouse wrote: > compat_sys_setsockopt() is a little overzealous about converting 32-bit > stuff into 64-bit. It should match on level _and_ optname, not just > optname. Currently it eats the IPV6_V6ONLY sockopt because its value > (26) happens to match SO_ATTACH_FILTER. > > This makes it at least check 'level' for everything but > IPT_SO_SET_REPLACE == IPT6_SO_SET_REPLACE, because that does seem to be > the same in different levels. But do_netfilter_replace() is another can > of worms entirely -- it doesn't actually work either, because some > netfilter modules (like ipt_limit) include kernel-only bits which change > size in the structure they share with userspace. Thanks, applied. I know it's a pain in the ass, but could you cook up a 2.4.x version? Thanks. From davem@redhat.com Tue Sep 7 14:42:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:42:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87LgUEB018022 for ; Tue, 7 Sep 2004 14:42:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i87LgGS0016083; Tue, 7 Sep 2004 17:42:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i87LgG311573; Tue, 7 Sep 2004 17:42:16 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i87LgDOx031067; Tue, 7 Sep 2004 17:42:14 -0400 Date: Tue, 7 Sep 2004 14:39:33 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-Id: <20040907143933.526ec7df.davem@redhat.com> In-Reply-To: <20040907120532.GB25051@wotan.suse.de> References: <20040907120532.GB25051@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 263 Lines: 7 This missed the current round of merges, I'll try to get it in by the end of the week. I'm probably going to put the infrastructure patch in first, then the tg3/e1000 bits. Can you resend me the e1000 patch under private cover btw? I've lost my copy, thanks. From peter@pantasys.com Tue Sep 7 14:46:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:46:37 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87LkVMs018385 for ; Tue, 7 Sep 2004 14:46:32 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 14:39:35 -0700 Message-ID: <413E2C26.5040108@pantasys.com> Date: Tue, 07 Sep 2004 14:46:14 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH 2.6] ipconfig accepts any DHCPACK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2004 21:39:35.0015 (UTC) FILETIME=[2AF28F70:01C49523] X-archive-position: 8482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 752 Lines: 27 Hi David, I was playing around with using ipconfig to initialise a bunch of systems and it turns out that the ipconfig code doesn't check to see whether the ACK is for it or another system. I've just added a simple check to compare the hardware address of the device to the one in the packet. peter Signed-off-by: Peter Buckingham --- linus-2.6/net/ipv4/ipconfig.c 2004-09-02 14:53:54.000000000 -0700 +++ local_linux/net/ipv4/ipconfig.c 2004-09-02 14:57:49.000000000 -0700 @@ -966,6 +966,12 @@ static int __init ic_bootp_recv(struct s break; case DHCPACK: + for (i = 0; (dev->dev_addr[i] == b->hw_addr[i]) + && (i < 16); i++); + if (i < 16) + goto drop_unlock; + /* Yeah! */ break; From hadi@cyberus.ca Tue Sep 7 14:53:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:53:49 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Lrhx9018767 for ; Tue, 7 Sep 2004 14:53:44 -0700 Received: from localhost.tpn.ch ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090714550263:32067 ; Tue, 7 Sep 2004 14:55:02 -0700 Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040907120532.GB25051@wotan.suse.de> References: <20040907120532.GB25051@wotan.suse.de> Organization: jamalopolis Message-Id: <1094593729.1079.32.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Sep 2004 17:53:04 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/07/2004 02:55:03 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/07/2004 02:55:05 PM, Serialize complete at 09/07/2004 02:55:05 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1005 Lines: 28 On Tue, 2004-09-07 at 08:05, Andi Kleen wrote: > New version of the NETIF_F_LLTX for network devices patch. > > This allows network drivers to set the NETIF_F_LLTX flag > The drivers can use try lock if they want and return -1 > when the lock wasn't grabbed. In this case the packet > will be requeued. For better compatibility this is only > done for drivers with LLTX set, others don't give a special > meaning to -1. Are you reinventing the rules or changing them? hard_start_xmit() return codes are intepreted as follows: 0: typically means the packet was put in the ring. It is being abused by a few drivers to mean a retry depending on the device state (which while may work results in a longer code path). 1: means packet was not put on the ring. i.e if you return 1, the toplayer will retry later with the same skb. [of course If you stash it on the ring, the danger is tx complete will try to free it later while the toplayer code is still referencing it. A good oops]. cheers, jamal From Rezwanul_Kabir@Dell.com Tue Sep 7 14:55:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 14:55:20 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87LtEqo018973 for ; Tue, 7 Sep 2004 14:55:14 -0700 Received: from ausx2kcpc115.aus.amer.dell.com (10.166.84.69) by ausc60pc101.us.dell.com with ESMTP; 07 Sep 2004 16:55:01 -0500 X-Ironport-AV: i="3.84,139,1091422800"; d="scan'208"; a="88084315:sNHT25363984" X-MimeOLE: Produced By Microsoft Exchange V6.0.6527.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ioctl() to get MAC address from EEPROM Date: Tue, 7 Sep 2004 16:55:00 -0500 Message-ID: <06226F23984D7A49A694576CF06603F908BBCE@ausx2kmpc106.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ioctl() to get MAC address from EEPROM Thread-Index: AcSR2EpqqtgahXMFRfmmyUt8DI/YOwDTAoaw From: To: X-OriginalArrivalTime: 07 Sep 2004 21:55:00.0367 (UTC) FILETIME=[528011F0:01C49525] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i87LtEqo018973 X-archive-position: 8484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Rezwanul_Kabir@Dell.com Precedence: bulk X-list: netdev Content-Length: 1182 Lines: 35 Any comments on below? If this is not the right forum to ask such questions, could anyone pls point me to an appropriate forum? I really need to figure out the best way to do it... Thanks.. --rez > -----Original Message----- > From: Kabir, Rezwanul > Sent: Friday, September 03, 2004 12:06 PM > To: netdev@oss.sgi.com > Subject: ioctl() to get MAC address from EEPROM > > > Hi > > There seems to be no standard way to retrieve the MAC > address of a NIC stored in the EEPROM ( ETHTOOL_GEEPROM ioctl > may be used to do such thing but there's a need for a more > direct standard interface).This is sometimes necessary when > the MAC address in EEPROM may differ from the one associated > with the software interface (i.e. dev_addr in struct > net_device).For example, in some modes of channel bonding , > the MAC address of the active NIC is duplicated on the rest > of the members of the specific bond/team. How to fetch the > "permanent" MAC address in this case? > Any plan to include such commands in ethtool ioctls? Is > there a better way to do this? > Any suggestions would be appreciated.. > Thanks.. > --rez > > > From davem@redhat.com Tue Sep 7 15:04:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 15:05:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87M4utp019669 for ; Tue, 7 Sep 2004 15:04:56 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i87M4lS0023484; Tue, 7 Sep 2004 18:04:47 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i87M4l317329; Tue, 7 Sep 2004 18:04:47 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i87M4ib0006941; Tue, 7 Sep 2004 18:04:45 -0400 Date: Tue, 7 Sep 2004 15:02:04 -0700 From: "David S. Miller" To: Peter Buckingham Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] ipconfig accepts any DHCPACK Message-Id: <20040907150204.119ba849.davem@redhat.com> In-Reply-To: <413E2C26.5040108@pantasys.com> References: <413E2C26.5040108@pantasys.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 537 Lines: 12 On Tue, 07 Sep 2004 14:46:14 -0700 Peter Buckingham wrote: > I was playing around with using ipconfig to initialise a bunch of > systems and it turns out that the ipconfig code doesn't check to see > whether the ACK is for it or another system. I've just added a simple > check to compare the hardware address of the device to the one in the > packet. Just because there are 16 bytes of hw address in the bootp packet layout doesn't mean the device actually has that many. Please fix it to use dev->addr_len. From davem@redhat.com Tue Sep 7 15:46:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 15:46:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87Mk8hX020746 for ; Tue, 7 Sep 2004 15:46:08 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i87MjwS0003680; Tue, 7 Sep 2004 18:45:58 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i87Mjw326569; Tue, 7 Sep 2004 18:45:58 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i87MjueW018939; Tue, 7 Sep 2004 18:45:56 -0400 Date: Tue, 7 Sep 2004 15:43:15 -0700 From: "David S. Miller" To: Peter Buckingham Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] ipconfig accepts any DHCPACK Message-Id: <20040907154315.067e9470.davem@redhat.com> In-Reply-To: <413E39F2.4070708@pantasys.com> References: <413E2C26.5040108@pantasys.com> <20040907150204.119ba849.davem@redhat.com> <413E39F2.4070708@pantasys.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 335 Lines: 12 On Tue, 07 Sep 2004 15:45:06 -0700 Peter Buckingham wrote: > David S. Miller wrote: > > Just because there are 16 bytes of hw address in the bootp packet > > layout doesn't mean the device actually has that many. Please fix > > it to use dev->addr_len. > > > > is this okay? yep, looks great, I'll apply it From peter@pantasys.com Tue Sep 7 15:45:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 15:45:30 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87MjOmX020580 for ; Tue, 7 Sep 2004 15:45:24 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 15:38:27 -0700 Message-ID: <413E39F2.4070708@pantasys.com> Date: Tue, 07 Sep 2004 15:45:06 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] ipconfig accepts any DHCPACK References: <413E2C26.5040108@pantasys.com> <20040907150204.119ba849.davem@redhat.com> In-Reply-To: <20040907150204.119ba849.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2004 22:38:27.0562 (UTC) FILETIME=[648274A0:01C4952B] X-archive-position: 8486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 682 Lines: 26 David S. Miller wrote: > Just because there are 16 bytes of hw address in the bootp packet > layout doesn't mean the device actually has that many. Please fix > it to use dev->addr_len. > is this okay? peter Signed-off-by: Peter Buckingham --- linus-2.6/net/ipv4/ipconfig.c 2004-09-02 14:53:54.000000000 -0700 +++ local_linux/net/ipv4/ipconfig.c 2004-09-07 15:43:39.000000000 -0700 @@ -966,6 +966,11 @@ static int __init ic_bootp_recv(struct s break; case DHCPACK: + for (i = 0; (dev->dev_addr[i] == b->hw_addr[i]) + && (i < dev->addr_len); i++); + if (i < dev->addr_len) + goto drop_unlock; + /* Yeah! */ break; From davem@davemloft.net Tue Sep 7 15:59:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 15:59:59 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87MxqPE021483 for ; Tue, 7 Sep 2004 15:59:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C4otV-00029C-00; Tue, 07 Sep 2004 15:56:57 -0700 Date: Tue, 7 Sep 2004 15:56:57 -0700 From: "David S. Miller" To: James Chapman Cc: netdev@oss.sgi.com, kleptog@svana.org Subject: Re: PPP-over-L2TP kernel support, patch for review Message-Id: <20040907155657.2ab6a4bb.davem@davemloft.net> In-Reply-To: <1094471956.413c5114de2d7@www.katalix.com> References: <1094471956.413c5114de2d7@www.katalix.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 802 Lines: 27 On Mon, 6 Sep 2004 12:59:16 +0100 James Chapman wrote: > I'm working towards having this driver integrated into the kernel > tree. Comments? Only two major comments: 1) Uses own linked list implementations. Please use linux/list.h interfaces for this. 2) Does this: struct sockaddr_pppox { sa_family_t sa_family; /* address family, AF_PPPOX */ unsigned int sa_protocol; /* protocol identifier */ union{ struct pppoe_addr pppoe; + struct pppol2tp_addr pppol2tp; }sa_addr; }__attribute__ ((packed)); Change the size of sockaddr_pppox on any platform? If so, you'll break pppox userspace with this change so we'd need find another way to do it. Thanks. From herbert@gondor.apana.org.au Tue Sep 7 16:16:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 16:16:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87NGdFw022046 for ; Tue, 7 Sep 2004 16:16:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4pBy-0006cg-00; Wed, 08 Sep 2004 09:16:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4pBt-0000bA-00; Wed, 08 Sep 2004 09:15:57 +1000 Date: Wed, 8 Sep 2004 09:15:57 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-ID: <20040907231557.GA2254@gondor.apana.org.au> References: <4137681D.3000902@trash.net> <20040902144436.2c8c1337.davem@redhat.com> <20040902220343.GA3250@gondor.apana.org.au> <20040903.104050.29603454.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903.104050.29603454.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 602 Lines: 21 On Fri, Sep 03, 2004 at 10:40:50AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > @@ -1026,18 +1033,22 @@ > > while (size > 0) { > int i; > - if ((len = mtu - skb->len) <= 0) { > + > + /* Check if the remaining data fits into current packet. */ > + len = mtu - skb->len; > + if (len > size) > + len = maxfraglen - skb->len; I think that should be len < size, right? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Tue Sep 7 16:25:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 16:25:39 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i87NPTfM025651 for ; Tue, 7 Sep 2004 16:25:30 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8487F33CE5; Wed, 8 Sep 2004 08:26:21 +0900 (JST) Date: Wed, 08 Sep 2004 08:26:20 +0900 (JST) Message-Id: <20040908.082620.60870352.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au, davem@davemloft.net Cc: kaber@trash.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040907231557.GA2254@gondor.apana.org.au> References: <20040902220343.GA3250@gondor.apana.org.au> <20040903.104050.29603454.yoshfuji@linux-ipv6.org> <20040907231557.GA2254@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 3608 Lines: 137 In article <20040907231557.GA2254@gondor.apana.org.au> (at Wed, 8 Sep 2004 09:15:57 +1000), Herbert Xu says: > > + len = mtu - skb->len; > > + if (len > size) > > + len = maxfraglen - skb->len; > > I think that should be len < size, right? oh, right, thanks. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/ip_output.c 1.67 vs edited ===== --- 1.67/net/ipv4/ip_output.c 2004-09-03 06:50:20 +09:00 +++ edited/net/ipv4/ip_output.c 2004-09-08 08:22:29 +09:00 @@ -811,26 +811,33 @@ goto alloc_new_skb; while (length > 0) { - if ((copy = mtu - skb->len) <= 0) { + /* Check if the remaining data fits into current packet. */ + copy = mtu - skb->len; + if (copy < length) + copy = maxfraglen - skb->len; + if (copy <= 0) { char *data; unsigned int datalen; unsigned int fraglen; unsigned int fraggap; unsigned int alloclen; struct sk_buff *skb_prev; - BUG_TRAP(copy == 0); - alloc_new_skb: skb_prev = skb; - fraggap = 0; if (skb_prev) - fraggap = mtu - maxfraglen; - - datalen = mtu - fragheaderlen; - if (datalen > length + fraggap) - datalen = length + fraggap; + fraggap = skb_prev->len - maxfraglen; + else + fraggap = 0; + /* + * If remaining data exceeds the mtu, + * we know we need more fragment(s). + */ + datalen = length + fraggap; + if (datalen > mtu - fragheaderlen) + datalen = maxfraglen - fragheaderlen; fraglen = datalen + fragheaderlen; + if ((flags & MSG_MORE) && !(rt->u.dst.dev->features&NETIF_F_SG)) alloclen = mtu; @@ -1026,18 +1033,22 @@ while (size > 0) { int i; - if ((len = mtu - skb->len) <= 0) { + + /* Check if the remaining data fits into current packet. */ + len = mtu - skb->len; + if (len < size) + len = maxfraglen - skb->len; + if (len <= 0) { struct sk_buff *skb_prev; char *data; struct iphdr *iph; int alloclen; - BUG_TRAP(len == 0); - skb_prev = skb; - fraggap = 0; if (skb_prev) - fraggap = mtu - maxfraglen; + fraggap = skb_prev->len - maxfraglen; + else + fraggap = 0; alloclen = fragheaderlen + hh_len + fraggap + 15; skb = sock_wmalloc(sk, alloclen, 1, sk->sk_allocation); ===== net/ipv6/ip6_output.c 1.72 vs edited ===== --- 1.72/net/ipv6/ip6_output.c 2004-09-03 06:50:20 +09:00 +++ edited/net/ipv6/ip6_output.c 2004-09-08 08:18:28 +09:00 @@ -898,26 +898,34 @@ goto alloc_new_skb; while (length > 0) { - if ((copy = mtu - skb->len) <= 0) { + /* Check if the remaining data fits into current packet. */ + copy = mtu - skb->len; + if (copy < length) + copy = maxfraglen - skb->len; + + if (copy <= 0) { char *data; unsigned int datalen; unsigned int fraglen; unsigned int fraggap; unsigned int alloclen; struct sk_buff *skb_prev; - BUG_TRAP(copy == 0); alloc_new_skb: skb_prev = skb; /* There's no room in the current skb */ - fraggap = 0; if (skb_prev) - fraggap = mtu - maxfraglen; - - datalen = mtu - fragheaderlen; + fraggap = skb_prev->len - maxfraglen; + else + fraggap = 0; - if (datalen > length + fraggap) - datalen = length + fraggap; + /* + * If remaining data exceeds the mtu, + * we know we need more fragment(s). + */ + datalen = length + fraggap; + if (datalen > mtu - fragheaderlen) + datalen = maxfraglen - fragheaderlen; fraglen = datalen + fragheaderlen; if ((flags & MSG_MORE) && -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From joe@perches.com Tue Sep 7 17:12:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 17:12:54 -0700 (PDT) Received: from Perches.com (DSL022.labridge.com [206.117.136.22]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i880CnVH026681 for ; Tue, 7 Sep 2004 17:12:49 -0700 Received: from [192.168.1.129] ([192.168.1.129]) by Perches.com (8.9.3/8.9.3) with ESMTP id RAA08642; Tue, 7 Sep 2004 17:58:15 -0700 Subject: Re: [PATCH 2.6] ipconfig accepts any DHCPACK From: Joe Perches To: Peter Buckingham Cc: David S Miller , netdev@oss.sgi.com In-Reply-To: <413E39F2.4070708@pantasys.com> References: <413E2C26.5040108@pantasys.com> <20040907150204.119ba849.davem@redhat.com> <413E39F2.4070708@pantasys.com> Content-Type: text/plain Message-Id: <1094602330.3076.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 07 Sep 2004 17:12:11 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 8491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joe@perches.com Precedence: bulk X-list: netdev Content-Length: 466 Lines: 23 On Tue, 2004-09-07 at 15:45, Peter Buckingham wrote: > is this okay? > + for (i = 0; (dev->dev_addr[i] == b->hw_addr[i]) > + && (i < dev->addr_len); i++); > + if (i < dev->addr_len) > + goto drop_unlock; > + I had to read that twice. How about something like: for (i=0;iaddr_len;i++) if (dev->dev_addr[i] != b->hw_addr[i]) goto drop_unlock; or if (memcmp(dev->dev_addr, b->hw_addr, dev->addr_len)!=0) goto drop_unlock; instead? From peter@pantasys.com Tue Sep 7 17:18:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 17:18:41 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i880IZQf027066 for ; Tue, 7 Sep 2004 17:18:36 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Sep 2004 17:11:38 -0700 Message-ID: <413E4FC9.8070800@pantasys.com> Date: Tue, 07 Sep 2004 17:18:17 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: Joe Perches CC: David S Miller , netdev@oss.sgi.com Subject: Re: [PATCH 2.6] ipconfig accepts any DHCPACK References: <413E2C26.5040108@pantasys.com> <20040907150204.119ba849.davem@redhat.com> <413E39F2.4070708@pantasys.com> <1094602330.3076.2.camel@localhost.localdomain> In-Reply-To: <1094602330.3076.2.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2004 00:11:38.0828 (UTC) FILETIME=[6929F0C0:01C49538] X-archive-position: 8492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 538 Lines: 22 Joe Perches wrote: > if (memcmp(dev->dev_addr, b->hw_addr, dev->addr_len)!=0) > goto drop_unlock; > I prefer this one. Signed-off-by: Peter Buckingham --- linus-2.6/net/ipv4/ipconfig.c 2004-09-02 14:53:54.000000000 -0700 +++ local_linux/net/ipv4/ipconfig.c 2004-09-07 17:16:55.000000000 -0700 @@ -966,6 +966,9 @@ static int __init ic_bootp_recv(struct s break; case DHCPACK: + if (memcmp(dev->dev_addr, b->hw_addr, dev->addr_len) != 0) + goto drop_unlock; + /* Yeah! */ break; From herbert@gondor.apana.org.au Tue Sep 7 20:11:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 20:11:46 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i883BaJK030776 for ; Tue, 7 Sep 2004 20:11:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4srR-0007Xt-00; Wed, 08 Sep 2004 13:11:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4srO-0002QW-00; Wed, 08 Sep 2004 13:11:02 +1000 Date: Wed, 8 Sep 2004 13:11:02 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [INET] Update ECN handling wrt RFC 3168 Message-ID: <20040908031102.GA9273@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5759 Lines: 196 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch brings the IP ECN handling up-to-date with repsect to RFC 3168. Mostly this means treating ECT(1) in the same way as ECT(0). Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/inet_ecn.h 1.5 vs edited ===== --- 1.5/include/net/inet_ecn.h 2004-07-23 05:16:04 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-08 12:00:01 +10:00 @@ -16,9 +16,9 @@ return (dsfield & INET_ECN_MASK) == INET_ECN_CE; } -static inline int INET_ECN_is_not_ce(__u8 dsfield) +static inline int INET_ECN_is_not_ect(__u8 dsfield) { - return (dsfield & INET_ECN_MASK) == INET_ECN_ECT_0; + return (dsfield & INET_ECN_MASK) == INET_ECN_NOT_ECT; } static inline int INET_ECN_is_capable(__u8 dsfield) @@ -29,8 +29,7 @@ static inline __u8 INET_ECN_encapsulate(__u8 outer, __u8 inner) { outer &= ~INET_ECN_MASK; - if (INET_ECN_is_capable(inner)) - outer |= (inner & INET_ECN_MASK); + outer |= (inner & INET_ECN_MASK) ?: INET_ECN_ECT_0; return outer; } @@ -50,7 +49,19 @@ static inline void IP_ECN_set_ce(struct iphdr *iph) { u32 check = iph->check; - check += __constant_htons(0xFFFE); + + switch (iph->tos & INET_ECN_MASK) { + default: + case INET_ECN_NOT_ECT: + case INET_ECN_CE: + return; + case INET_ECN_ECT_1: + check += __constant_htons(0xFFFD); + break; + case INET_ECN_ECT_0: + check += __constant_htons(0xFFFE); + break; + } iph->check = check + (check>=0xFFFF); iph->tos |= INET_ECN_CE; } @@ -60,10 +71,14 @@ iph->tos &= ~INET_ECN_MASK; } +#define ip6_get_dsfield(iph) ((ntohs(*(u16*)(iph)) >> 4) & 0xFF) + struct ipv6hdr; static inline void IP6_ECN_set_ce(struct ipv6hdr *iph) { + if (INET_ECN_is_not_ect(ip6_get_dsfield(iph))) + return; *(u32*)iph |= htonl(INET_ECN_CE << 20); } @@ -71,7 +86,5 @@ { *(u32*)iph &= ~htonl(INET_ECN_MASK << 20); } - -#define ip6_get_dsfield(iph) ((ntohs(*(u16*)(iph)) >> 4) & 0xFF) #endif ===== include/net/tcp_ecn.h 1.5 vs edited ===== --- 1.5/include/net/tcp_ecn.h 2003-06-05 10:57:07 +10:00 +++ edited/include/net/tcp_ecn.h 2004-09-08 11:59:33 +10:00 @@ -90,7 +90,7 @@ /* Funny extension: if ECT is not set on a segment, * it is surely retransmit. It is not in ECN RFC, * but Linux follows this rule. */ - else if (!INET_ECN_is_capable((TCP_SKB_CB(skb)->flags))) + else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags))) tcp_enter_quickack_mode(tp); } } ===== net/ipv4/ip_gre.c 1.40 vs edited ===== --- 1.40/net/ipv4/ip_gre.c 2004-06-24 11:19:28 +10:00 +++ edited/net/ipv4/ip_gre.c 2004-09-08 11:59:33 +10:00 @@ -533,11 +533,9 @@ { if (INET_ECN_is_ce(iph->tos)) { if (skb->protocol == htons(ETH_P_IP)) { - if (INET_ECN_is_not_ce(skb->nh.iph->tos)) - IP_ECN_set_ce(skb->nh.iph); + IP_ECN_set_ce(skb->nh.iph); } else if (skb->protocol == htons(ETH_P_IPV6)) { - if (INET_ECN_is_not_ce(ip6_get_dsfield(skb->nh.ipv6h))) - IP6_ECN_set_ce(skb->nh.ipv6h); + IP6_ECN_set_ce(skb->nh.ipv6h); } } } ===== net/ipv4/ipip.c 1.42 vs edited ===== --- 1.42/net/ipv4/ipip.c 2004-06-22 07:34:06 +10:00 +++ edited/net/ipv4/ipip.c 2004-09-08 11:59:34 +10:00 @@ -461,8 +461,7 @@ { struct iphdr *inner_iph = skb->nh.iph; - if (INET_ECN_is_ce(outer_iph->tos) && - INET_ECN_is_not_ce(inner_iph->tos)) + if (INET_ECN_is_ce(outer_iph->tos)) IP_ECN_set_ce(inner_iph); } ===== net/ipv4/xfrm4_input.c 1.10 vs edited ===== --- 1.10/net/ipv4/xfrm4_input.c 2004-02-14 18:06:45 +11:00 +++ edited/net/ipv4/xfrm4_input.c 2004-09-08 11:59:34 +10:00 @@ -24,8 +24,7 @@ struct iphdr *outer_iph = skb->nh.iph; struct iphdr *inner_iph = skb->h.ipiph; - if (INET_ECN_is_ce(outer_iph->tos) && - INET_ECN_is_not_ce(inner_iph->tos)) + if (INET_ECN_is_ce(outer_iph->tos)) IP_ECN_set_ce(inner_iph); } ===== net/ipv6/sit.c 1.39 vs edited ===== --- 1.39/net/ipv6/sit.c 2004-06-24 11:19:29 +10:00 +++ edited/net/ipv6/sit.c 2004-09-08 11:59:34 +10:00 @@ -360,8 +360,7 @@ static inline void ipip6_ecn_decapsulate(struct iphdr *iph, struct sk_buff *skb) { - if (INET_ECN_is_ce(iph->tos) && - INET_ECN_is_not_ce(ip6_get_dsfield(skb->nh.ipv6h))) + if (INET_ECN_is_ce(iph->tos)) IP6_ECN_set_ce(skb->nh.ipv6h); } ===== net/ipv6/xfrm6_input.c 1.17 vs edited ===== --- 1.17/net/ipv6/xfrm6_input.c 2004-08-19 07:51:27 +10:00 +++ edited/net/ipv6/xfrm6_input.c 2004-09-08 11:59:34 +10:00 @@ -21,8 +21,7 @@ struct ipv6hdr *outer_iph = skb->nh.ipv6h; struct ipv6hdr *inner_iph = skb->h.ipv6h; - if (INET_ECN_is_ce(ip6_get_dsfield(outer_iph)) && - INET_ECN_is_not_ce(ip6_get_dsfield(inner_iph))) + if (INET_ECN_is_ce(ip6_get_dsfield(outer_iph))) IP6_ECN_set_ce(inner_iph); } ===== net/sched/sch_red.c 1.15 vs edited ===== --- 1.15/net/sched/sch_red.c 2004-08-05 06:39:51 +10:00 +++ edited/net/sched/sch_red.c 2004-09-08 11:59:35 +10:00 @@ -162,13 +162,12 @@ switch (skb->protocol) { case __constant_htons(ETH_P_IP): - if (!INET_ECN_is_capable(skb->nh.iph->tos)) + if (INET_ECN_is_not_ect(skb->nh.iph->tos)) return 0; - if (INET_ECN_is_not_ce(skb->nh.iph->tos)) - IP_ECN_set_ce(skb->nh.iph); + IP_ECN_set_ce(skb->nh.iph); return 1; case __constant_htons(ETH_P_IPV6): - if (!INET_ECN_is_capable(ip6_get_dsfield(skb->nh.ipv6h))) + if (INET_ECN_is_not_ect(ip6_get_dsfield(skb->nh.ipv6h))) return 0; IP6_ECN_set_ce(skb->nh.ipv6h); return 1; --liOOAslEiF7prFVr-- From herbert@gondor.apana.org.au Tue Sep 7 20:22:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 20:22:39 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i883MU3h002047 for ; Tue, 7 Sep 2004 20:22:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4t22-0007cB-00; Wed, 08 Sep 2004 13:22:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4t1y-0002S3-00; Wed, 08 Sep 2004 13:21:58 +1000 Date: Wed, 8 Sep 2004 13:21:58 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-ID: <20040908032158.GA9414@gondor.apana.org.au> References: <20040902220343.GA3250@gondor.apana.org.au> <20040903.104050.29603454.yoshfuji@linux-ipv6.org> <20040907231557.GA2254@gondor.apana.org.au> <20040908.082620.60870352.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908.082620.60870352.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 458 Lines: 16 On Wed, Sep 08, 2004 at 08:26:20AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > oh, right, thanks. > > Signed-off-by: Hideaki YOSHIFUJI Looks good. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@suse.de Tue Sep 7 23:52:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 07 Sep 2004 23:52:16 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i886q7io008798 for ; Tue, 7 Sep 2004 23:52:08 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id E79DDBA8139; Wed, 8 Sep 2004 08:51:52 +0200 (CEST) Date: Wed, 8 Sep 2004 08:51:52 +0200 From: Andi Kleen To: jamal Cc: Andi Kleen , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040908065152.GC27886@wotan.suse.de> References: <20040907120532.GB25051@wotan.suse.de> <1094593729.1079.32.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094593729.1079.32.camel@jzny.localdomain> X-archive-position: 8495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1327 Lines: 32 On Tue, Sep 07, 2004 at 05:53:04PM -0400, jamal wrote: > On Tue, 2004-09-07 at 08:05, Andi Kleen wrote: > > New version of the NETIF_F_LLTX for network devices patch. > > > > This allows network drivers to set the NETIF_F_LLTX flag > > > The drivers can use try lock if they want and return -1 > > when the lock wasn't grabbed. In this case the packet > > will be requeued. For better compatibility this is only > > done for drivers with LLTX set, others don't give a special > > meaning to -1. > > Are you reinventing the rules or changing them? I'm just offering the driver an additional choice . > > hard_start_xmit() return codes are intepreted as follows: > > 0: typically means the packet was put in the ring. > It is being abused by a few drivers to mean a retry depending on the > device state (which while may work results in a longer code path). > 1: means packet was not put on the ring. i.e if you return > 1, the toplayer will retry later with the same skb. > [of course If you stash it on the ring, the danger is tx complete will > try to free it later while the toplayer code is still referencing it. A > good oops]. Actually when you return 1 then the kernel prints an ugly message and it is considered a bug. Here -1 is legal. For safety -1 should be only used for locking purposes though. -Andi From herbert@gondor.apana.org.au Wed Sep 8 00:08:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 00:08:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8878WaV009458 for ; Wed, 8 Sep 2004 00:08:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4wYp-0000Di-00; Wed, 08 Sep 2004 17:08:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4wYe-0005qT-00; Wed, 08 Sep 2004 17:07:56 +1000 From: Herbert Xu To: ak@suse.de (Andi Kleen) Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Cc: hadi@cyberus.ca, ak@suse.de, davem@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040908065152.GC27886@wotan.suse.de> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Wed, 08 Sep 2004 17:07:56 +1000 X-archive-position: 8496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 815 Lines: 23 Andi Kleen wrote: > >> 1: means packet was not put on the ring. i.e if you return >> 1, the toplayer will retry later with the same skb. >> [of course If you stash it on the ring, the danger is tx complete will >> try to free it later while the toplayer code is still referencing it. A >> good oops]. > > Actually when you return 1 then the kernel prints an ugly > message and it is considered a bug. Here -1 is legal. 1 is legal in contexts where queueing occurs. See for example qdisc_restart(). It's only illegal here because this is the direct xmit path without queueing. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@suse.de Wed Sep 8 00:24:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 00:24:50 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i887OPhL013234 for ; Wed, 8 Sep 2004 00:24:27 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id A8D74BA7AB8; Wed, 8 Sep 2004 09:24:11 +0200 (CEST) Date: Wed, 8 Sep 2004 09:24:08 +0200 From: Andi Kleen To: Herbert Xu Cc: Andi Kleen , hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040908072408.GI27886@wotan.suse.de> References: <20040908065152.GC27886@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 8497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 989 Lines: 33 On Wed, Sep 08, 2004 at 05:07:56PM +1000, Herbert Xu wrote: > Andi Kleen wrote: > > > >> 1: means packet was not put on the ring. i.e if you return > >> 1, the toplayer will retry later with the same skb. > >> [of course If you stash it on the ring, the danger is tx complete will > >> try to free it later while the toplayer code is still referencing it. A > >> good oops]. > > > > Actually when you return 1 then the kernel prints an ugly > > message and it is considered a bug. Here -1 is legal. > > 1 is legal in contexts where queueing occurs. See for example > qdisc_restart(). I agree my sentence was misleading. Basically the distinction here is: 1 is for flow control -1 is for lock contention I think it's better to separate them because it minimizes the risk of breaking old drivers. > > It's only illegal here because this is the direct xmit path without > queueing. You are thinking of the wrong patch. This patch is changing qdisc_restart -Andi From kleptog@svana.org Wed Sep 8 00:32:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 00:33:04 -0700 (PDT) Received: from svana.org (mail@svana.org [203.20.62.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i887WwLc014047 for ; Wed, 8 Sep 2004 00:32:59 -0700 Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 1C4wwb-0004zc-00; Wed, 08 Sep 2004 17:32:41 +1000 Date: Wed, 8 Sep 2004 17:32:41 +1000 From: Martijn van Oosterhout To: "David S. Miller" Cc: James Chapman , netdev@oss.sgi.com Subject: Re: PPP-over-L2TP kernel support, patch for review Message-ID: <20040908073238.GB18285@svana.org> Reply-To: Martijn van Oosterhout References: <1094471956.413c5114de2d7@www.katalix.com> <20040907155657.2ab6a4bb.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: <20040907155657.2ab6a4bb.davem@davemloft.net> User-Agent: Mutt/1.3.28i X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: X-archive-position: 8498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kleptog@svana.org Precedence: bulk X-list: netdev Content-Length: 2099 Lines: 61 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 07, 2004 at 03:56:57PM -0700, David S. Miller wrote: > On Mon, 6 Sep 2004 12:59:16 +0100 > James Chapman wrote: > 2) Does this: >=20 > struct sockaddr_pppox {=20 > sa_family_t sa_family; /* address family, AF_PPPOX= */=20 > unsigned int sa_protocol; /* protocol identifier */= =20 > union{=20 > struct pppoe_addr pppoe;=20 > + struct pppol2tp_addr pppol2tp; > }sa_addr;=20 > }__attribute__ ((packed));=20 >=20 > Change the size of sockaddr_pppox on any platform? If so, you'll > break pppox userspace with this change so we'd need find another > way to do it. By my calculations,=20 sizeof(struct pppoe_addr) =3D 2 + ETH_ALEN + IFNAMSIZ =3D 2 + 6 + 16 =3D 24= bytes sizeof(struct pppol2tp_addr) =3D sizeof(int) + sizeof(sockaddr_in) + 4 * 2 =3D 4 + 16 + 8 =3D 28 + possibly padding So the answer is: I think so. However, I'm not sure why this is an issue. struct sockaddr is passed back and forth between userspace and kernelspace has many varying sizes (sockaddr_un is quite large). What could be affected? getsockname, connect and bind all take a length argument. Or are you referring to the possibility of it affecting other structures it's embedded in? TIA, --=20 Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBPrWWY5Twig3Ge+YRAuZBAJ4x7d2TR8mDp0eJpNbluh1PMQlisgCggnKr SSp/IcrHI3VuhRLscjnIdhM= =4yOl -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- From hadi@cyberus.ca Wed Sep 8 00:39:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 00:39:44 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i887dcpY014481 for ; Wed, 8 Sep 2004 00:39:38 -0700 Received: from localhost.tpn.ch ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090800403504:32585 ; Wed, 8 Sep 2004 00:40:35 -0700 Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: greg chesson , sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org In-Reply-To: <20040907101027.7547e591.davem@davemloft.net> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> <413DE9ED.30300@atheros.com> <20040907101027.7547e591.davem@davemloft.net> Organization: jamalopolis Message-Id: <1094628909.1097.145.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Sep 2004 03:38:36 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/08/2004 12:40:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/08/2004 12:40:59 AM, Serialize complete at 09/08/2004 12:40:59 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 828 Lines: 26 On Tue, 2004-09-07 at 13:10, David S. Miller wrote: > On Tue, 07 Sep 2004 10:03:41 -0700 > greg chesson wrote: > > > What about eth_type_trans()? > > It determines the protocol type from the ethernet header > fields. It is a simple shorthand header field fetcher, > not a protocol stack. > > You would need a eth80211_type_trans() for wireless > drivers too, and surprise surprise my skeleton 802.11 > stack code in fact does exactly this. Or as Andi has been suggesting for sometime, not invoke it all ;-> This is possible if the DMA descriptor already has all the info needed (quiet a few modern hardware can be programmed to do this). .. er, at the driver level. So this is not "a gross input packet hooked eater thing that's an ugly wart bolted onto the side of the driver API.";-> cheers, jamal From hadi@cyberus.ca Wed Sep 8 00:48:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 00:48:42 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i887mb67015570 for ; Wed, 8 Sep 2004 00:48:37 -0700 Received: from localhost.tpn.ch ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004090800495509:32594 ; Wed, 8 Sep 2004 00:49:55 -0700 Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040908072408.GI27886@wotan.suse.de> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> Organization: jamalopolis Message-Id: <1094629677.1089.155.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Sep 2004 03:47:57 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/08/2004 12:49:55 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/08/2004 12:49:58 AM, Serialize complete at 09/08/2004 12:49:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1172 Lines: 38 On Wed, 2004-09-08 at 03:24, Andi Kleen wrote: > On Wed, Sep 08, 2004 at 05:07:56PM +1000, Herbert Xu wrote: > > Andi Kleen wrote: > > > > > >> 1: means packet was not put on the ring. i.e if you return > > >> 1, the toplayer will retry later with the same skb. > > >> [of course If you stash it on the ring, the danger is tx complete will > > >> try to free it later while the toplayer code is still referencing it. A > > >> good oops]. > > > > > > Actually when you return 1 then the kernel prints an ugly > > > message and it is considered a bug. Here -1 is legal. Is this an effect of your code? This is not so in existing code. > > 1 is legal in contexts where queueing occurs. See for example > > qdisc_restart(). > > I agree my sentence was misleading. > > Basically the distinction here is: > > 1 is for flow control > -1 is for lock contention > > I think it's better to separate them because it minimizes the risk > of breaking old drivers. > Dont see how its going to break old drivers since they wont be making this kind of call anyways. In both cases it is semantically a flow control i.e "transmit path is busy" cheers, jamal From herbert@gondor.apana.org.au Wed Sep 8 01:18:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 01:18:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i888I8N7017574 for ; Wed, 8 Sep 2004 01:18:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4xeE-0000uc-00; Wed, 08 Sep 2004 18:17:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4xe9-0005xL-00; Wed, 08 Sep 2004 18:17:41 +1000 From: Herbert Xu To: Martijn van Oosterhout Subject: Re: PPP-over-L2TP kernel support, patch for review Cc: davem@davemloft.net, jchapman@katalix.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040908073238.GB18285@svana.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Wed, 08 Sep 2004 18:17:41 +1000 X-archive-position: 8501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1053 Lines: 26 Martijn van Oosterhout wrote: > > By my calculations, > > sizeof(struct pppoe_addr) = 2 + ETH_ALEN + IFNAMSIZ = 2 + 6 + 16 = 24 bytes > sizeof(struct pppol2tp_addr) = sizeof(int) + sizeof(sockaddr_in) + 4 * 2 > = 4 + 16 + 8 = 28 + possibly padding > > So the answer is: I think so. However, I'm not sure why this is an > issue. struct sockaddr is passed back and forth between userspace and > kernelspace has many varying sizes (sockaddr_un is quite large). What > could be affected? getsockname, connect and bind all take a length > argument. Or are you referring to the possibility of it affecting other > structures it's embedded in? Any existing user-space binary that has struct sockaddr_pppox in it will be broken by your change. Perhaps you can create a new sockaddr type? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kleptog@svana.org Wed Sep 8 01:38:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 01:38:59 -0700 (PDT) Received: from svana.org (mail@svana.org [203.20.62.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i888cqQB021224 for ; Wed, 8 Sep 2004 01:38:52 -0700 Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 1C4xyG-0005Ky-00; Wed, 08 Sep 2004 18:38:28 +1000 Date: Wed, 8 Sep 2004 18:38:28 +1000 From: Martijn van Oosterhout To: Herbert Xu Cc: davem@davemloft.net, jchapman@katalix.com, netdev@oss.sgi.com Subject: Re: PPP-over-L2TP kernel support, patch for review Message-ID: <20040908083828.GE18285@svana.org> Reply-To: Martijn van Oosterhout References: <20040908073238.GB18285@svana.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vmttodhTwj0NAgWp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: X-archive-position: 8502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kleptog@svana.org Precedence: bulk X-list: netdev Content-Length: 2734 Lines: 65 --vmttodhTwj0NAgWp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 08, 2004 at 06:17:41PM +1000, Herbert Xu wrote: > Martijn van Oosterhout wrote: > > So the answer is: I think so. However, I'm not sure why this is an > > issue. struct sockaddr is passed back and forth between userspace and > > kernelspace has many varying sizes (sockaddr_un is quite large). What > > could be affected? getsockname, connect and bind all take a length > > argument. Or are you referring to the possibility of it affecting other > > structures it's embedded in? >=20 > Any existing user-space binary that has struct sockaddr_pppox in it will > be broken by your change. >=20 > Perhaps you can create a new sockaddr type? But within a single binary, it knows how big the structure was at the time it was compiled and has allocated the appropriate space. It also was compiled with a particular version of PX_MAX_PROTO so it should know if it's an unknown type. Any communication with the kernel includes the size so there is no possibility of buffer overruns AFAICS. The change is backward compatable in the sense that the sa_protocol field determines which union member is appropriate and hence the expected size of the structure. However, it's possible I've not thought of a failure case. Maybe some parts of kernel or userspace ignore the length or sa_protocol argument. It's possible to create a new sockaddr type. I didn't do that as I thought the point was to have all PPPoX sockets to use the same type. You could create a socket type sockaddr_pppox2 which is bigger than the current sockaddr_pppox but otherwise identical. Change the kernel to use this new structure (no actual code changes needed, just argument types). Worst case we get a new structure for each new type of PPPoX socket. The AF_PPPOX will be the same for all of them. Transistion userspace to use the new pppox2 structure for everything and you're done. Again, no code changes required, only the type is changed. I can create a patch if you want... --=20 Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. --vmttodhTwj0NAgWp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBPsUEY5Twig3Ge+YRAgDdAKCWWXVGbxoO4qXQjXSCoaCR64DR3ACePlXR XVSB6XhySEtHEi04Ns1zeRM= =h1Da -----END PGP SIGNATURE----- --vmttodhTwj0NAgWp-- From herbert@gondor.apana.org.au Wed Sep 8 01:46:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 01:47:06 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i888ku5F021768 for ; Wed, 8 Sep 2004 01:46:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4y66-00016z-00; Wed, 08 Sep 2004 18:46:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4y62-000620-00; Wed, 08 Sep 2004 18:46:30 +1000 Date: Wed, 8 Sep 2004 18:46:30 +1000 To: Martijn van Oosterhout Cc: davem@davemloft.net, jchapman@katalix.com, netdev@oss.sgi.com Subject: Re: PPP-over-L2TP kernel support, patch for review Message-ID: <20040908084630.GA23117@gondor.apana.org.au> References: <20040908073238.GB18285@svana.org> <20040908083828.GE18285@svana.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908083828.GE18285@svana.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1343 Lines: 28 On Wed, Sep 08, 2004 at 06:38:28PM +1000, Martijn van Oosterhout wrote: > > But within a single binary, it knows how big the structure was at the > time it was compiled and has allocated the appropriate space. It also > was compiled with a particular version of PX_MAX_PROTO so it should > know if it's an unknown type. Any communication with the kernel > includes the size so there is no possibility of buffer overruns AFAICS. > The change is backward compatable in the sense that the sa_protocol > field determines which union member is appropriate and hence the > expected size of the structure. It can break because people often initialise the size of the address by doing sizeof(struct sockaddr_pppox). For example, you'll see exactly this breakage in pppoe_getname in drivers/net/pppoe.c. Now granted you can work around this in pppoe.c and repair the kernel ABI. But user space has ABIs too. Think of a library that exports this stuff to other user space applications. If it does sizeof(struct sockaddr_pppox) then you're toast. IMHO this union was a silly idea to begin with. Let's not prolong its life any further. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kleptog@svana.org Wed Sep 8 02:05:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 02:05:28 -0700 (PDT) Received: from svana.org (mail@svana.org [203.20.62.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8895Mhv022444 for ; Wed, 8 Sep 2004 02:05:23 -0700 Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 1C4yNr-0005UF-00; Wed, 08 Sep 2004 19:04:55 +1000 Date: Wed, 8 Sep 2004 19:04:55 +1000 From: Martijn van Oosterhout To: Herbert Xu Cc: davem@davemloft.net, jchapman@katalix.com, netdev@oss.sgi.com Subject: Re: PPP-over-L2TP kernel support, patch for review Message-ID: <20040908090455.GF18285@svana.org> Reply-To: Martijn van Oosterhout References: <20040908073238.GB18285@svana.org> <20040908083828.GE18285@svana.org> <20040908084630.GA23117@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TeJTyD9hb8KJN2Jy" Content-Disposition: inline In-Reply-To: <20040908084630.GA23117@gondor.apana.org.au> User-Agent: Mutt/1.3.28i X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: X-archive-position: 8504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kleptog@svana.org Precedence: bulk X-list: netdev Content-Length: 2081 Lines: 56 --TeJTyD9hb8KJN2Jy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 08, 2004 at 06:46:30PM +1000, Herbert Xu wrote: > It can break because people often initialise the size of the > address by doing sizeof(struct sockaddr_pppox). For example, > you'll see exactly this breakage in pppoe_getname in > drivers/net/pppoe.c. /me looks... *BLINK* Ugh, getname takes a length argument but it's write only. So, hypothetically, if I get passed a file descriptor through a UNIX domain socket and do a getname on it, there is no way to guarentee that it won't go past the buffer I've allocated. Who came up with this lame API? > IMHO this union was a silly idea to begin with. Let's not prolong > its life any further. Well, I guess I'll have to agree to that. So, lets say we create two new types, one for each version of the union, sockaddr_pppox_pppoe and sockaddr_pppox_pppol2tp. Deprecate the current sockaddr_pppox altogether (can't get rid of it now). Possibly create a new sockaddr_pppox_generic for use in the actual pppox.c file. Sprinkle some typecasts around to make the compiler happy and voila! Then future userspace programs can use the structure appropriate for them. Does removing the union change the alignment on any architechture? Or will the dummy union have to stay in perpituity? Seems fairly straight forward... I'll see if I have time to whip something up... --=20 Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. --TeJTyD9hb8KJN2Jy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBPss3Y5Twig3Ge+YRAhNmAJ48pJZ5IKRSCFfECvL7hyXWA7/aPQCgtewS wmps98B3eRCfPfHHVbzrhpc= =CiBP -----END PGP SIGNATURE----- --TeJTyD9hb8KJN2Jy-- From herbert@gondor.apana.org.au Wed Sep 8 03:04:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 03:04:56 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88A4jv8029733 for ; Wed, 8 Sep 2004 03:04:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C4zJR-0001gh-00; Wed, 08 Sep 2004 20:04:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C4zJO-00069K-00; Wed, 08 Sep 2004 20:04:22 +1000 Date: Wed, 8 Sep 2004 20:04:22 +1000 To: Martijn van Oosterhout Cc: davem@davemloft.net, jchapman@katalix.com, netdev@oss.sgi.com Subject: Re: PPP-over-L2TP kernel support, patch for review Message-ID: <20040908100422.GB23578@gondor.apana.org.au> References: <20040908073238.GB18285@svana.org> <20040908083828.GE18285@svana.org> <20040908084630.GA23117@gondor.apana.org.au> <20040908090455.GF18285@svana.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908090455.GF18285@svana.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1304 Lines: 30 On Wed, Sep 08, 2004 at 07:04:55PM +1000, Martijn van Oosterhout wrote: > > So, hypothetically, if I get passed a file descriptor through a UNIX > domain socket and do a getname on it, there is no way to guarentee that > it won't go past the buffer I've allocated. Who came up with this lame > API? Nope. The code in net/socket.c ensures that the buffer does not overflow. > Well, I guess I'll have to agree to that. So, lets say we create two > new types, one for each version of the union, sockaddr_pppox_pppoe and > sockaddr_pppox_pppol2tp. Deprecate the current sockaddr_pppox > altogether (can't get rid of it now). Possibly create a new > sockaddr_pppox_generic for use in the actual pppox.c file. Sprinkle > some typecasts around to make the compiler happy and voila! Please call them sockaddr_pppoe and sockaddr_pppol2tp. > Then future userspace programs can use the structure appropriate for > them. Does removing the union change the alignment on any > architechture? Or will the dummy union have to stay in perpituity? The union doesn't change the size or alignemnt. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From sriharivijayaraghavan@yahoo.com.au Wed Sep 8 05:49:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 05:50:01 -0700 (PDT) Received: from smtp201.mail.sc5.yahoo.com (smtp201.mail.sc5.yahoo.com [216.136.129.91]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i88Cnu2r006024 for ; Wed, 8 Sep 2004 05:49:56 -0700 Received: from unknown (HELO ?192.168.0.2?) (sriharivijayaraghavan@150.101.158.114 with plain) by smtp201.mail.sc5.yahoo.com with SMTP; 8 Sep 2004 12:18:26 -0000 From: Srihari Vijayaraghavan To: romieu@fr.zoreil.com Subject: r8169 - panic and a fix Date: Wed, 8 Sep 2004 22:24:23 +1000 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> X-archive-position: 8507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sriharivijayaraghavan@yahoo.com.au Precedence: bulk X-list: netdev Content-Length: 3421 Lines: 76 As of 2.6.9-rc1-bk11, r8169 does not work on my Athlon 64 machine. It results in a panic :-(. Here is the oops message for your information: NET: Registered protocol family 1 ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at skbuff:91 invalid operand: 0000 [1] CPU 0 Modules linked in: r8169 af_packet ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables ide_cd cdrom via_rhine mii crc32 floppy radeon reiserfs dm_mod uhci_hcd ehci_hcd usbcore button rtc unix Pid: 1424, comm: ifup Not tainted 2.6.9-rc1-bk14 RIP: 0010:[] {skb_over_panic+50} RSP: 0000:ffffffff80399328 EFLAGS: 00010292 RAX: 0000000000000036 RBX: 0000000000000c00 RCX: 000000000001ffff RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffffffff802f8880 RBP: 0000010036eda360 R08: 0000000000000036 R09: 0000000000000003 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000bfc R13: 0000000000000000 R14: 0000000000000000 R15: 0000010036fca000 FS: 0000002a9556cd60(0000) GS:ffffffff803f0740(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000039cbd054d0 CR3: 0000000000101000 CR4: 00000000000006e0 Process ifup (pid: 1424, threadinfo 0000010036fd2000, task 000001003f7e07d0) Stack: 000000000000000a ffffffffa00faf66 0000000000000bfc ffffffffa00fb3c0 0000010080399368 0000010036eda000 000001003fc34c80 0000000000008001 ffffff0000052000 0000000000000014 Call Trace: {:r8169:rtl8169_rx_interrupt+502} {:r8169:pci_unmap_single+0} {:r8169:rtl8169_interrupt+147} {handle_IRQ_event+44} {do_IRQ+147} {ret_from_intr+0} Code: 0f 0b 8c 29 2d 80 ff ff ff ff 5b 00 48 83 c4 08 c3 66 66 66 RIP {skb_over_panic+50} RSP <0>Kernel panic - not syncing: Aiee, killing interrupt handler! Reversing this patch, which first appeared in 2.6.9-rc1-bk11, fixes the problem: diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2004-07-02 11:51:44 -07:00 +++ b/drivers/net/r8169.c 2004-08-31 00:15:35 -07:00 @@ -983,7 +983,7 @@ tp->cp_cmd = PCIMulRW | RxChkSum; - if ((sizeof(dma_addr_t) > 32) && + if ((sizeof(dma_addr_t) > 4) && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) tp->cp_cmd |= PCIDAC; else { In other words, no problem with 2.6.9-rc1-bk14 minus that patch. Here is the lspci -vv for my card: 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Giga-byte Technology: Unknown device e000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- ; Wed, 8 Sep 2004 06:46:38 -0700 Received: from tgr by rei.rakuen with local (Exim 4.34) id 1C52lk-0004ah-3H; Wed, 08 Sep 2004 15:45:52 +0200 Date: Wed, 8 Sep 2004 15:45:52 +0200 From: Thomas Graf To: Eric Lemoine Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Allow setting dev->weight using ip(8) Message-ID: <20040908134551.GP31616@rei.reeler.org> References: <5cac192f040830035669628d1@mail.gmail.com> <1093868860.1075.573.camel@jzny.localdomain> <5cac192f0408300733477c6c9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5cac192f0408300733477c6c9@mail.gmail.com> X-archive-position: 8508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 476 Lines: 10 * Eric Lemoine <5cac192f0408300733477c6c9@mail.gmail.com> 2004-08-30 16:33 > iproute still uses ioctl at that time, doesn't it? > [...] > I attached a patch to iproute-2.6.8. To make the patch compile I had > to tinker with the Makefile - it seems that KERNEL_INCLUDE does no > longer serve any purpose, except for ATM maybe. I have a patch for it and added support for your new changes. I'm currently holding it back until all issues with the 2.4 backport have been solved. From greg@atheros.com Wed Sep 8 09:02:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 09:02:33 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88G2FZT026312 for ; Wed, 8 Sep 2004 09:02:16 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8828928; Wed, 08 Sep 2004 09:02:01 -0700 Message-ID: <413F2D33.1000508@atheros.com> Date: Wed, 08 Sep 2004 09:02:59 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: "David S. Miller" , sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua, jgarzik@pobox.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, jt@bougret.hpl.hp.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <20040906182328.08faf843.davem@davemloft.net> <200409062132.49356.sam@errno.com> <413DE9ED.30300@atheros.com> <20040907101027.7547e591.davem@davemloft.net> <1094628909.1097.145.camel@jzny.localdomain> In-Reply-To: <1094628909.1097.145.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 2213 Lines: 64 You guys are too serious and, I believe, missed the real points. 1. There is a need in the OS for a "service" to convert between .11 and .3 packet formats. It should be designed for hw-independence. Everyone sees the same potential for unification of wireless drivers. 2. It's harder to do than it first appears because the complete transformation from .3 to .11 cannot be done in isolation from the driver(s) and there are monkey wrenches that get tossed in from crypto, interaction between crypto and fragementation, power-save, observing txoplimits, and other things that tend to cross architecture lines that would otherwise be nice and clean. 3. I personally don't have religion about whether a service that transforms headers is implemented as a stack or implemented as a side call. I think that a variety of factors are worth considering. In this particular case (header transformation), I believe a side call "helper function" is appropriate and has less overhead than the full protocol stack mechanism. But it's pointless to argue about it without measurements. 4. David's skeleton code is quite interesting and a good start. You won't know its usefulness until someone tries to implement a real driver. g jamal wrote: > On Tue, 2004-09-07 at 13:10, David S. Miller wrote: > >>On Tue, 07 Sep 2004 10:03:41 -0700 >>greg chesson wrote: >> >> >>>What about eth_type_trans()? >> >>It determines the protocol type from the ethernet header >>fields. It is a simple shorthand header field fetcher, >>not a protocol stack. >> >>You would need a eth80211_type_trans() for wireless >>drivers too, and surprise surprise my skeleton 802.11 >>stack code in fact does exactly this. > > > Or as Andi has been suggesting for sometime, not invoke it all ;-> > This is possible if the DMA descriptor already has all the info > needed (quiet a few modern hardware can be programmed to do this). > .. er, at the driver level. So this is not "a gross input packet > hooked eater thing that's an ugly wart bolted onto the > side of the driver API.";-> > > cheers, > jamal > > > From greearb@candelatech.com Wed Sep 8 10:11:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 10:12:07 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88HBusR029989 for ; Wed, 8 Sep 2004 10:11:57 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i88HDQLH008015; Wed, 8 Sep 2004 10:13:26 -0700 Message-ID: <413F3D53.2030505@candelatech.com> Date: Wed, 08 Sep 2004 10:11:47 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Linux 802.1Q VLAN" , "'netdev@oss.sgi.com'" Subject: Re: [VLAN] Bad: scheduling while atomic! in 2.6.8.1] References: <413F1707.1090508@pobox.com> In-Reply-To: <413F1707.1090508@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 4785 Lines: 107 Andre Correa wrote: > > Hi, I set up a Linux box as a firewall with 4 NICs (3C905) on a Dell > with 2.6.8.1 and iptables 1.2.11. 3 NICs have several IP addresses and > the 4th has 4 VLANs associated. This box is plugged on Cisco switches. > > Everything was fine, firewalling OK, until I plugged the 4th NIC. When > traffic start to flow the box logs a _LOT_ of errors on syslog: Mr. Hemminger recently added some RCU locking changes to VLAN. That said, I don't see any mention of vlan in the stack traces below, so it could be that there is some other problem. I'm forwarding this to the netdev mailing list as well. > > > Sep 1 03:58:48 fw01 kernel: bad: scheduling while atomic! > Sep 1 03:58:48 fw01 kernel: [] schedule+0x3c/0x428 > Sep 1 03:58:48 fw01 kernel: [] sys_socketcall+0x150/0x1f4 > Sep 1 03:58:48 fw01 kernel: [] work_resched+0x5/0x16 > Sep 1 03:58:48 fw01 kernel: bad: scheduling while atomic! > Sep 1 03:58:48 fw01 kernel: [] schedule+0x3c/0x428 > Sep 1 03:58:48 fw01 kernel: [] __kfree_skb+0xd3/0xd8 > Sep 1 03:58:48 fw01 kernel: [] schedule_timeout+0x14/0xb0 > Sep 1 03:58:48 fw01 kernel: [] unix_wait_for_peer+0xac/0xc8 > Sep 1 03:58:48 fw01 kernel: [] > autoremove_wake_function+0x0/0x40 > Sep 1 03:58:48 fw01 kernel: [] > autoremove_wake_function+0x0/0x40 > Sep 1 03:58:48 fw01 kernel: [] unix_dgram_sendmsg+0x39b/0x4b0 > Sep 1 03:58:48 fw01 kernel: [] sock_aio_write+0x101/0x10c > Sep 1 03:58:48 fw01 kernel: [] do_sync_write+0x7a/0xac > Sep 1 03:58:48 fw01 kernel: [] kfree_skbmem+0x17/0x1c > Sep 1 03:58:48 fw01 kernel: [] __kfree_skb+0xd3/0xd8 > Sep 1 03:58:48 fw01 kernel: [] vfs_write+0xb5/0xd4 > Sep 1 03:58:48 fw01 kernel: [] sys_write+0x40/0x6c > Sep 1 03:58:48 fw01 kernel: [] syscall_call+0x7/0xb > Sep 1 03:58:48 fw01 kernel: bad: scheduling while atomic! > Sep 1 03:58:48 fw01 kernel: [] schedule+0x3c/0x428 > Sep 1 03:58:49 fw01 kernel: [] sys_socketcall+0x150/0x1f4 > Sep 1 03:58:49 fw01 kernel: [] work_resched+0x5/0x16 > Sep 1 03:58:49 fw01 kernel: bad: scheduling while atomic! > Sep 1 03:58:49 fw01 kernel: [] schedule+0x3c/0x428 > Sep 1 03:58:49 fw01 kernel: [] __kfree_skb+0xd3/0xd8 > Sep 1 03:58:49 fw01 kernel: [] schedule_timeout+0x14/0xb0 > Sep 1 03:58:49 fw01 kernel: [] unix_wait_for_peer+0xac/0xc8 > Sep 1 03:58:49 fw01 kernel: [] > autoremove_wake_function+0x0/0x40 > Sep 1 03:58:49 fw01 kernel: [] > autoremove_wake_function+0x0/0x40 > Sep 1 03:58:49 fw01 kernel: [] unix_dgram_sendmsg+0x39b/0x4b0 > Sep 1 03:58:49 fw01 kernel: [] sock_aio_write+0x101/0x10c > Sep 1 03:58:49 fw01 kernel: [] do_sync_write+0x7a/0xac > Sep 1 03:58:49 fw01 kernel: [] kfree_skbmem+0x17/0x1c > Sep 1 03:58:49 fw01 kernel: [] __kfree_skb+0xd3/0xd8 > Sep 1 03:58:49 fw01 kernel: [] vfs_write+0xb5/0xd4 > Sep 1 03:58:49 fw01 kernel: [] sys_write+0x40/0x6c > Sep 1 03:58:49 fw01 kernel: [] syscall_call+0x7/0xb > > > I got more then 110Mb of it in ~2 hours of tests. Shutting down > interface doesn't stop it, just a reboot takes the machine back to its > normal state, if cable is unplugged. > > I've tested NIC, cable, PCI slot, switch port, switch and even changed > the box itself, but nothing helped. When I take VLAN down, on Cisco > switch, no errors are logged. If I go back to 2.6.7 + VLAN, no errors > too, all OK. > > It seens to be related to VLAN on 2.6.8.1 only. Searching kernel source > I found that it comes from kernel/sched.c, but it doesn't tells me much. > > > /* > * Test if we are atomic. Since do_exit() needs to call into > * schedule() atomically, we ignore that path for now. > * Otherwise, whine if we are scheduling when we should not be. > */ > if (likely(!(current->state & (TASK_DEAD | TASK_ZOMBIE)))) { > if (unlikely(in_atomic())) { > printk(KERN_ERR "bad: scheduling while atomic!\n"); > dump_stack(); > } > } > > > Does anybody can help on it?! Does it look like a bug or what? > > Any help is appreciated. > > tks > > Andre > > _______________________________________________ > VLAN mailing list - VLAN@wanfear.com > http://www.WANfear.com/mailman/listinfo/vlan > VLAN Page: http://scry.wanfear.com/~greear/vlan.html > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From a.verweij@student.tudelft.nl Wed Sep 8 12:07:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 12:07:56 -0700 (PDT) Received: from smtp05.wanadoo.nl (smtp05.wanadoo.nl [194.134.35.145]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88J7mR2004515 for ; Wed, 8 Sep 2004 12:07:49 -0700 Received: from [192.168.1.4] (c3eea2b62.cable.wanadoo.nl [62.234.43.98]) by smtp5.wanadoo.nl (Postfix) with ESMTP id C4A7E7CA5; Wed, 8 Sep 2004 21:07:36 +0200 (CEST) Message-ID: <413F587A.70902@student.tudelft.nl> Date: Wed, 08 Sep 2004 21:07:38 +0200 From: Arjen Verweij User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040819) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew de Quincey Cc: netdev@oss.sgi.com Subject: Re: wol support in forcedeth v25 References: <200404201236.41188.adq@lidskialf.net> In-Reply-To: <200404201236.41188.adq@lidskialf.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.verweij@student.tudelft.nl Precedence: bulk X-list: netdev Content-Length: 2916 Lines: 88 Dear Andrew, Today I upgraded to forcedeth v0.28. Looking at the Changelog, nothing indicates additional changes have been made to WOL support. Is there anything I can do to get this in motion again? I am willing to test stuff when needed, and give feedback based on my system. For now I just change: #define DEV_NEED_TIMERIRQ 0x0008 to #define DEV_NEED_TIMERIRQ 0x0000 and use pci-config to set the involved bits of the chip to get to D3. From http://www.hailfinger.org/carldani/linux/patches/forcedeth/ I gather that NVIDIA has contributed gigabit support. Maybe they can spill some code to help get WOL support as well? From earlier emails with NVIDIA engineers I was told that WOL support is not part of the Linux driver, so it may be a long shit :) Thank you all for a great driver, Arjen Andrew de Quincey wrote: >On Tuesday 20 April 2004 12:13, Arjen Verweij wrote: > >I found how I could get it going again, but its not the right way of doing >it.. In nv_close(), if you comment out the lines "nv_stop_rx(dev);" and "if >(np->wolenabled) nv_start_rx(dev);", WOL works. > >However this isn't the right way to do it, which is why I haven't supplied a >patch. What its supposed to do it stop receiving, clear any buffers, then >restart receiving again. But this seems to break WOL for some reason. There >must be some extra operation required for it all to work properly... I'll >keep looking. > > > >>OK, let me know if you need a guinea pig to test any patches you might >>have. >> >>Regards, >> >>Arjen >> >>On Tue, 20 Apr 2004, Andrew de Quincey wrote: >> >> >>>On Monday 19 April 2004 21:11, Arjen Verweij wrote: >>> >>> >>>>Hi, >>>> >>>>Is the wol support in forcedeth v25 complete yet? I was trying it with >>>>the 2.6.5 kernel it came with, tried the new forcedeth driver with a >>>>2.6.3 kernel (because firewire seems broken in 2.6.5) however, my box >>>>will not wake up as of yet. >>>> >>>> >>>You're right! It _was_ working with patch-forced-0.25, but it ain't in >>>2.6.5. I'll see if I can spot the problem. >>> >>> >>> >>>>According to the source there is a FIXME with a comment about powering >>>>down the NIC. Does this mean that support for wol is incomplete for >>>>now? Mind you, I am just curious, this is in no way meant as criticism. >>>> >>>> >>>That would only be for when WOL is NOT used; I think it has to leave the >>>NIC powered up for WOL to work... and as you say it ain't implemented >>>yet. >>> >>> >>> >>>>On another note, Carl-Daniel mentioned that DEV_NEED_TIMERIRQ might be >>>>removed from future releases. Is this still the case? Feedback would be >>>>much appreciated, so I can keep my humble audience up to date on what's >>>>going on at the wol front. >>>> >>>>Thank you guys for your excellent work, >>>> >>>>Arjen >>>>http://atlas.et.tudelft.nl/verwei90/nforce2/index.html >>>> >>>> From romieu@fr.zoreil.com Wed Sep 8 12:06:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 12:06:54 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88J6lCm004360 for ; Wed, 8 Sep 2004 12:06:48 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i88J63vr020743; Wed, 8 Sep 2004 21:06:03 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i88J63B6020742; Wed, 8 Sep 2004 21:06:03 +0200 Date: Wed, 8 Sep 2004 21:06:03 +0200 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: r8169 - panic and a fix Message-ID: <20040908190603.GA19634@electric-eye.fr.zoreil.com> References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1343 Lines: 39 Srihari Vijayaraghavan : > As of 2.6.9-rc1-bk11, r8169 does not work on my Athlon 64 machine. It results > in a panic :-(. [skb_over_panic] Can you: - make drivers/net/r8169.s and send me the r8169.s file - objdump -S drivers/net/r8169.o and send me output - Re-apply the patch which test size(dma_arrd_t), apply the patch below and report the (possibly oopsy) result ? --- drivers/net/r8169.c 2004-09-08 20:15:01.000000000 +0200 +++ dirvers/net/r8169.c 2004-09-08 20:49:58.000000000 +0200 @@ -52,6 +52,7 @@ VERSION 1.2 <2002/11/30> #define MODULENAME "r8169" #define RTL8169_DRIVER_NAME MODULENAME " Gigabit Ethernet driver " RTL8169_VERSION #define PFX MODULENAME ": " +#define RTL8169_DEBUG #ifdef RTL8169_DEBUG #define assert(expr) \ @@ -1308,7 +1309,7 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(EarlyTxThres, EarlyTxThld); // For gigabit rtl8169 - RTL_W16(RxMaxSize, RxPacketMaxSize); + RTL_W16(RxMaxSize, RX_BUF_SIZE); // Set Rx Config register i = rtl8169_rx_config | @@ -1698,6 +1699,7 @@ rtl8169_rx_interrupt(struct net_device * pci_action(tp->pci_dev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + assert(pkt_size <= RX_BUF_SIZE); skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); rtl8169_rx_skb(skb); From a.verweij@student.tudelft.nl Wed Sep 8 12:36:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 12:36:45 -0700 (PDT) Received: from smtp04.wanadoo.nl (smtp04.wanadoo.nl [194.134.35.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88Jac8G010542 for ; Wed, 8 Sep 2004 12:36:39 -0700 Received: from [192.168.1.4] (c3eea2b62.cable.wanadoo.nl [62.234.43.98]) by smtp4.wanadoo.nl (Postfix) with ESMTP id 86AFF54BD6 for ; Wed, 8 Sep 2004 21:36:27 +0200 (CEST) Message-ID: <413F5F3E.1060400@student.tudelft.nl> Date: Wed, 08 Sep 2004 21:36:30 +0200 From: Arjen Verweij User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040830) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: netdev@oss.sgi.com Subject: Re: wol support in forcedeth v25 References: <200404201236.41188.adq@lidskialf.net> In-Reply-To: <200404201236.41188.adq@lidskialf.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.verweij@student.tudelft.nl Precedence: bulk X-list: netdev Content-Length: 2237 Lines: 74 Ahum. I should have adapted the subject, and I did mean to write "long shot". NOFI at all, I was just typing too fast ;) Regards, Arjen Andrew de Quincey wrote: >On Tuesday 20 April 2004 12:13, Arjen Verweij wrote: > >I found how I could get it going again, but its not the right way of doing >it.. In nv_close(), if you comment out the lines "nv_stop_rx(dev);" and "if >(np->wolenabled) nv_start_rx(dev);", WOL works. > >However this isn't the right way to do it, which is why I haven't supplied a >patch. What its supposed to do it stop receiving, clear any buffers, then >restart receiving again. But this seems to break WOL for some reason. There >must be some extra operation required for it all to work properly... I'll >keep looking. > > > >>OK, let me know if you need a guinea pig to test any patches you might >>have. >> >>Regards, >> >>Arjen >> >>On Tue, 20 Apr 2004, Andrew de Quincey wrote: >> >> >>>On Monday 19 April 2004 21:11, Arjen Verweij wrote: >>> >>> >>>>Hi, >>>> >>>>Is the wol support in forcedeth v25 complete yet? I was trying it with >>>>the 2.6.5 kernel it came with, tried the new forcedeth driver with a >>>>2.6.3 kernel (because firewire seems broken in 2.6.5) however, my box >>>>will not wake up as of yet. >>>> >>>> >>>You're right! It _was_ working with patch-forced-0.25, but it ain't in >>>2.6.5. I'll see if I can spot the problem. >>> >>> >>> >>>>According to the source there is a FIXME with a comment about powering >>>>down the NIC. Does this mean that support for wol is incomplete for >>>>now? Mind you, I am just curious, this is in no way meant as criticism. >>>> >>>> >>>That would only be for when WOL is NOT used; I think it has to leave the >>>NIC powered up for WOL to work... and as you say it ain't implemented >>>yet. >>> >>> >>> >>>>On another note, Carl-Daniel mentioned that DEV_NEED_TIMERIRQ might be >>>>removed from future releases. Is this still the case? Feedback would be >>>>much appreciated, so I can keep my humble audience up to date on what's >>>>going on at the wol front. >>>> >>>>Thank you guys for your excellent work, >>>> >>>>Arjen >>>>http://atlas.et.tudelft.nl/verwei90/nforce2/index.html >>>> >>>> From vkondra@mail.ru Wed Sep 8 12:52:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 12:52:34 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88JqGsM011106 for ; Wed, 8 Sep 2004 12:52:17 -0700 Received: from [81.218.208.137] (port=40098 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C58U6-000HFa-00; Wed, 08 Sep 2004 23:52:04 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Wed, 8 Sep 2004 22:51:38 +0300 User-Agent: KMail/1.7 Cc: "David S. Miller" , acx100-devel@lists.sourceforge.net, greg chesson , hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <1094628909.1097.145.camel@jzny.localdomain> <413F2D33.1000508@atheros.com> In-Reply-To: <413F2D33.1000508@atheros.com> MIME-Version: 1.0 Message-Id: <200409082251.45771.vkondra@mail.ru> Content-Type: multipart/signed; boundary="nextPart1193371.lcs05vS5TV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-archive-position: 8514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 3976 Lines: 120 --nextPart1193371.lcs05vS5TV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Greg, you missed one important point. Besides data packets, that every driver now= =20 convert .11<->.3 using almost the same code, there is whole story of=20 management. Many modern cards are "softmac" and do all management on host. = I=20 see no point for every driver to implement its own scanning and association= =2E=20 It is simply waste of resources. To make step forward, I suggest the following: 1. Dave's code is at least year old. someone need to start maintain it,=20 starting with update for current kernel infrastructure. Get it compile and= =20 load for 2.6.9, for example. 2. To debug stack, you don't need real driver. I can write dummy .11 driver= =20 that will silently discard all Tx, and will provide some way for user level= =20 tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it= =20 is sufficient. Later, when it will come to timing, performance etc, it will= =20 be easy to strip some real driver. This may be king of "proof of concept". Vladimir On Wednesday 08 September 2004 19:02, greg chesson wrote: gc> You guys are too serious and, I believe, missed the real points. gc> gc> 1. There is a need in the OS for a "service" to convert between gc> .11 and .3 packet formats. It should be designed for gc> hw-independence. gc> Everyone sees the same potential for unification gc> of wireless drivers. gc> gc> 2. It's harder to do than it first appears because the complete gc> transformation from .3 to .11 cannot be done in isolation gc> from the driver(s) and there are monkey wrenches that get gc> tossed in from crypto, interaction between crypto and fragementation, gc> power-save, observing txoplimits, and other thin= gs that tend gc> to cross architecture lines that would otherwise be ni= ce and clean. gc> gc> 3. I personally don't have religion about whether a service gc> that transforms headers is implemented as a stack or implemented gc> as a side call. I think that a variety of factors are worth gc> considering. gc> In this particular case (header transformation), I believe a side call gc> "helper function" is appropriate and has less overhead than the full gc> protocol stack mechanism. But it's pointless to argue about it gc> without gc> measurements. gc> gc> 4. David's skeleton code is quite interesting and a good start. gc> You won't know its usefulness until someone tries to implement gc> a real driver. gc> gc> g gc> gc> gc> gc> jamal wrote: gc> > On Tue, 2004-09-07 at 13:10, David S. Miller wrote: gc> > gc> >>On Tue, 07 Sep 2004 10:03:41 -0700 gc> >>greg chesson wrote: gc> >> gc> >> gc> >>>What about eth_type_trans()? gc> >> gc> >>It determines the protocol type from the ethernet header gc> >>fields. It is a simple shorthand header field fetcher, gc> >>not a protocol stack. gc> >> gc> >>You would need a eth80211_type_trans() for wireless gc> >>drivers too, and surprise surprise my skeleton 802.11 gc> >>stack code in fact does exactly this. gc> > gc> > gc> > Or as Andi has been suggesting for sometime, not invoke it all ;-> gc> > This is possible if the DMA descriptor already has all the info gc> > needed (quiet a few modern hardware can be programmed to do this). gc> > .. er, at the driver level. So this is not "a gross input packet gc> > hooked eater thing that's an ugly wart bolted onto the gc> > side of the driver API.";-> gc> > gc> > cheers, gc> > jamal gc> > gc> > gc> > gc> gc> gc> gc> --nextPart1193371.lcs05vS5TV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBP2LRqxdj7mhC6o0RAi+gAKCtXlLW+VfAKBKgAI9zZJGInw1dXgCeJ4LB AdJQCCWxTrYNzMlF5N936m8= =w07b -----END PGP SIGNATURE----- --nextPart1193371.lcs05vS5TV-- From davem@davemloft.net Wed Sep 8 13:41:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 13:41:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88KfiAZ012788 for ; Wed, 8 Sep 2004 13:41:44 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C59Cp-00045t-00; Wed, 08 Sep 2004 13:38:15 -0700 Date: Wed, 8 Sep 2004 13:38:15 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, kaber@trash.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: Fix suboptimal fragment sizing for last fragment Message-Id: <20040908133815.6a02a0c6.davem@davemloft.net> In-Reply-To: <20040908032158.GA9414@gondor.apana.org.au> References: <20040902220343.GA3250@gondor.apana.org.au> <20040903.104050.29603454.yoshfuji@linux-ipv6.org> <20040907231557.GA2254@gondor.apana.org.au> <20040908.082620.60870352.yoshfuji@linux-ipv6.org> <20040908032158.GA9414@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 361 Lines: 14 On Wed, 8 Sep 2004 13:21:58 +1000 Herbert Xu wrote: > On Wed, Sep 08, 2004 at 08:26:20AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > oh, right, thanks. > > > > Signed-off-by: Hideaki YOSHIFUJI > > Looks good. > > Signed-off-by: Herbert Xu To me too, applied. From davem@davemloft.net Wed Sep 8 13:51:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 13:51:23 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88Kp6xg013225 for ; Wed, 8 Sep 2004 13:51:06 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C59LW-00046d-00; Wed, 08 Sep 2004 13:47:14 -0700 Date: Wed, 8 Sep 2004 13:47:13 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-Id: <20040908134713.1bcd46d3.davem@davemloft.net> In-Reply-To: <1094629677.1089.155.camel@jzny.localdomain> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1302 Lines: 29 On 08 Sep 2004 03:47:57 -0400 jamal wrote: > On Wed, 2004-09-08 at 03:24, Andi Kleen wrote: > > On Wed, Sep 08, 2004 at 05:07:56PM +1000, Herbert Xu wrote: > > > Andi Kleen wrote: > > > > > > > >> 1: means packet was not put on the ring. i.e if you return > > > >> 1, the toplayer will retry later with the same skb. > > > >> [of course If you stash it on the ring, the danger is tx complete will > > > >> try to free it later while the toplayer code is still referencing it. A > > > >> good oops]. > > > > > > > > Actually when you return 1 then the kernel prints an ugly > > > > message and it is considered a bug. Here -1 is legal. > > Is this an effect of your code? This is not so in existing code. We are merely moving the sch_generic.c locking logic into the drivers. The behavior is entirely equivalent except that one level of unnecessary locking has been removed. I think his change is valid, will not break existing drivers (as you mentioned as well Jamal), and works well for the cases he has shown patches of. So I'm going to apply his patch. BTW, if we are really concerned about some existing driver returning -1 from hard_start_xmit() without the new feature flag being enabled, we can test for that and log a debugging message if it happens. From greg@atheros.com Wed Sep 8 13:51:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 13:51:25 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88KpGJg013233 for ; Wed, 8 Sep 2004 13:51:16 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8835344; Wed, 08 Sep 2004 13:51:00 -0700 Message-ID: <413F70F0.6020709@atheros.com> Date: Wed, 08 Sep 2004 13:52:00 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <1094628909.1097.145.camel@jzny.localdomain> <413F2D33.1000508@atheros.com> <200409082251.45771.vkondra@mail.ru> In-Reply-To: <200409082251.45771.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 4412 Lines: 115 Vladimir Kondratiev wrote: > Greg, > you missed one important point. Besides data packets, that every driver now > convert .11<->.3 using almost the same code, there is whole story of > management. Many modern cards are "softmac" and do all management on host. I > see no point for every driver to implement its own scanning and association. Yes, Quite right. No disagreement. It is standard practice on NDIS and Apple Darwin that a common GUI-based application controls scanning, association, and manages keys+authentication+crypto. Linux does the same thing (driver is configured by application code) although there does not yet exist a single app that can serve as a common point of control for multiple vendor drivers. I believe that achieving that goal is the real payoff for wireless Linux users. > It is simply waste of resources. > > To make step forward, I suggest the following: > > 1. Dave's code is at least year old. someone need to start maintain it, > starting with update for current kernel infrastructure. Get it compile and > load for 2.6.9, for example. > > 2. To debug stack, you don't need real driver. I can write dummy .11 driver > that will silently discard all Tx, and will provide some way for user level > tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it > is sufficient. Later, when it will come to timing, performance etc, it will > be easy to strip some real driver. > > This may be king of "proof of concept". Yes, for logic it is sufficient. My personal approach would be to test the theory by examining what fits or doesn't fit into David's API if I were to port one of the MLME implementations that I work with. Discover if it fits or not. > > Vladimir > > On Wednesday 08 September 2004 19:02, greg chesson wrote: > gc> You guys are too serious and, I believe, missed the real points. > gc> > gc> 1. There is a need in the OS for a "service" to convert between > gc> .11 and .3 packet formats. It should be designed for > gc> hw-independence. > gc> Everyone sees the same potential for unification > gc> of wireless drivers. > gc> > gc> 2. It's harder to do than it first appears because the complete > gc> transformation from .3 to .11 cannot be done in isolation > gc> from the driver(s) and there are monkey wrenches that get > gc> tossed in from crypto, interaction between crypto and > fragementation, gc> power-save, observing txoplimits, and other things > that tend gc> to cross architecture lines that would otherwise be nice > and clean. gc> > gc> 3. I personally don't have religion about whether a service > gc> that transforms headers is implemented as a stack or implemented > gc> as a side call. I think that a variety of factors are worth > gc> considering. > gc> In this particular case (header transformation), I believe a side > call gc> "helper function" is appropriate and has less overhead than > the full gc> protocol stack mechanism. But it's pointless to argue > about it gc> without > gc> measurements. > gc> > gc> 4. David's skeleton code is quite interesting and a good start. > gc> You won't know its usefulness until someone tries to implement > gc> a real driver. > gc> > gc> g > gc> > gc> > gc> > gc> jamal wrote: > gc> > On Tue, 2004-09-07 at 13:10, David S. Miller wrote: > gc> > > gc> >>On Tue, 07 Sep 2004 10:03:41 -0700 > gc> >>greg chesson wrote: > gc> >> > gc> >> > gc> >>>What about eth_type_trans()? > gc> >> > gc> >>It determines the protocol type from the ethernet header > gc> >>fields. It is a simple shorthand header field fetcher, > gc> >>not a protocol stack. > gc> >> > gc> >>You would need a eth80211_type_trans() for wireless > gc> >>drivers too, and surprise surprise my skeleton 802.11 > gc> >>stack code in fact does exactly this. > gc> > > gc> > > gc> > Or as Andi has been suggesting for sometime, not invoke it all ;-> > gc> > This is possible if the DMA descriptor already has all the info > gc> > needed (quiet a few modern hardware can be programmed to do this). > gc> > .. er, at the driver level. So this is not "a gross input packet > gc> > hooked eater thing that's an ugly wart bolted onto the > gc> > side of the driver API.";-> > gc> > > gc> > cheers, > gc> > jamal > gc> > > gc> > > gc> > > gc> > gc> > gc> > gc > From davem@redhat.com Wed Sep 8 13:56:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 13:57:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i88KuwkM013931 for ; Wed, 8 Sep 2004 13:56:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i88KuaS0020557; Wed, 8 Sep 2004 16:56:36 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i88KuV328962; Wed, 8 Sep 2004 16:56:31 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i88KuS34009653; Wed, 8 Sep 2004 16:56:29 -0400 Date: Wed, 8 Sep 2004 13:53:28 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [INET] Update ECN handling wrt RFC 3168 Message-Id: <20040908135328.4431919a.davem@redhat.com> In-Reply-To: <20040908031102.GA9273@gondor.apana.org.au> References: <20040908031102.GA9273@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 255 Lines: 8 On Wed, 8 Sep 2004 13:11:02 +1000 Herbert Xu wrote: > This patch brings the IP ECN handling up-to-date with repsect to > RFC 3168. Mostly this means treating ECT(1) in the same way as > ECT(0). Looks great, patch applied. From vda@port.imtp.ilyichevsk.odessa.ua Wed Sep 8 14:19:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 14:20:01 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i88LJdvL014607 for ; Wed, 8 Sep 2004 14:19:43 -0700 Received: (qmail 9929 invoked by alias); 8 Sep 2004 21:19:26 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 08 Sep 2004 21:19:26 -0000 From: Denis Vlasenko To: acx100-devel@lists.sourceforge.net, Vladimir Kondratiev , netdev@oss.sgi.com Subject: Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Thu, 9 Sep 2004 00:19:21 +0300 User-Agent: KMail/1.5.4 Cc: "David S. Miller" , acx100-devel@lists.sourceforge.net, greg chesson , hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <413F2D33.1000508@atheros.com> <200409082251.45771.vkondra@mail.ru> In-Reply-To: <200409082251.45771.vkondra@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409090019.21105.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 8519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 1289 Lines: 31 On Wednesday 08 September 2004 22:51, Vladimir Kondratiev wrote: > Greg, > you missed one important point. Besides data packets, that every driver now > convert .11<->.3 using almost the same code, there is whole story of > management. Many modern cards are "softmac" and do all management on host. > I see no point for every driver to implement its own scanning and > association. It is simply waste of resources. This is exactly what I meant. We need generic 802.11 idioc^W management handling. And maybe also tx rate control, ACK/retries for "completely-softmac" cards like Atheros. Full spectrum of possible fullmac......softmac designs are not trivial to handle... > To make step forward, I suggest the following: > > 1. Dave's code is at least year old. someone need to start maintain it, > starting with update for current kernel infrastructure. Get it compile and > load for 2.6.9, for example. /me runs away and hides > 2. To debug stack, you don't need real driver. I can write dummy .11 driver > that will silently discard all Tx, and will provide some way for user level > tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it > is sufficient. Later, when it will come to timing, performance etc, it will > be easy to strip some real driver. -- vda From herbert@gondor.apana.org.au Wed Sep 8 17:04:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:04:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89045dY025399 for ; Wed, 8 Sep 2004 17:04:06 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5CPW-0000Pl-00; Thu, 09 Sep 2004 10:03:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5CPT-0001SU-00; Thu, 09 Sep 2004 10:03:31 +1000 Date: Thu, 9 Sep 2004 10:03:31 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [INET] Optimise away a branch in IP_ECN_set_ce Message-ID: <20040909000330.GA5581@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1662 Lines: 67 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: I was bored so here is a patch that optimises away a branch in IP_ECN_set_ce. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/inet_ecn.h 1.7 vs edited ===== --- 1.7/include/net/inet_ecn.h 2004-09-09 08:04:37 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-09 09:51:08 +10:00 @@ -49,19 +49,27 @@ static inline void IP_ECN_set_ce(struct iphdr *iph) { u32 check = iph->check; + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; - switch (iph->tos & INET_ECN_MASK) { - default: - case INET_ECN_NOT_ECT: - case INET_ECN_CE: + /* + * After the last operation we have (in binary): + * INET_ECN_NOT_ECT => 01 + * INET_ECN_ECT_1 => 10 + * INET_ECN_ECT_0 => 11 + * INET_ECN_CE => 00 + */ + if (!(ecn & 2)) return; - case INET_ECN_ECT_1: - check += __constant_htons(0xFFFD); - break; - case INET_ECN_ECT_0: - check += __constant_htons(0xFFFE); - break; - } + + /* + * The following gives us: + * INET_ECN_ECT_1 => check += __constant_htons(0xFFFD) + * INET_ECN_ECT_0 => check += __constant_htons(0xFFFE) + */ + if (__constant_htons(1) != 1) + ecn <<= 8; + check += __constant_htons(0xFFFB) + ecn; + iph->check = check + (check>=0xFFFF); iph->tos |= INET_ECN_CE; } --lrZ03NoBR/3+SXJZ-- From yoshfuji@linux-ipv6.org Wed Sep 8 17:23:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:23:40 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890NZD2026541 for ; Wed, 8 Sep 2004 17:23:36 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CB1CA33CE5; Thu, 9 Sep 2004 09:24:28 +0900 (JST) Date: Thu, 09 Sep 2004 09:24:28 +0900 (JST) Message-Id: <20040909.092428.125540781.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040909000330.GA5581@gondor.apana.org.au> References: <20040909000330.GA5581@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 834 Lines: 29 In article <20040909000330.GA5581@gondor.apana.org.au> (at Thu, 9 Sep 2004 10:03:31 +1000), Herbert Xu says: > + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; : > + /* > + * The following gives us: > + * INET_ECN_ECT_1 => check += __constant_htons(0xFFFD) > + * INET_ECN_ECT_0 => check += __constant_htons(0xFFFE) > + */ > + if (__constant_htons(1) != 1) > + ecn <<= 8; > + check += __constant_htons(0xFFFB) + ecn; > + > iph->check = check + (check>=0xFFFF); > iph->tos |= INET_ECN_CE; > } s/__constant_htons/htons/g here, please. And, I think u16 ecn = (iph->tos + 1) & INET_ECN_MASK; : check += (u32)htons(0xfffb) + (u32)htons(ecn); or something like that? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From acme@conectiva.com.br Wed Sep 8 17:28:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:28:14 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890S8jl027197 for ; Wed, 8 Sep 2004 17:28:09 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id 6802647391; Wed, 8 Sep 2004 21:27:56 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 02C9547646 for ; Wed, 8 Sep 2004 21:27:56 -0300 (BRT) Received: (qmail 2760 invoked by uid 0); 9 Sep 2004 01:25:42 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 9 Sep 2004 01:25:42 -0000 Received: from [192.168.0.2] (brinquedo [192.168.0.2]) by oops.ghostprotocols.net (Postfix) with ESMTP id 5D73B76C27; Wed, 8 Sep 2004 21:30:01 -0300 (BRT) From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. To: YOSHIFUJI Hideaki / =?utf-8?q?=E5=90=89=E8=97=A4=E8=8B=B1=E6=98=8E?= Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce Date: Wed, 8 Sep 2004 21:27:57 -0300 User-Agent: KMail/1.7 Cc: herbert@gondor.apana.org.au, davem@redhat.com, netdev@oss.sgi.com References: <20040909000330.GA5581@gondor.apana.org.au> <20040909.092428.125540781.yoshfuji@linux-ipv6.org> In-Reply-To: <20040909.092428.125540781.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200409082127.57827.acme@conectiva.com.br> X-Bogosity: No, tests=bogofilter, spamicity=0.004588, version=0.16.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i890S8jl027197 X-archive-position: 8522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 899 Lines: 30 Em Qua 08 Set 2004 21:24, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž escreveu: > In article <20040909000330.GA5581@gondor.apana.org.au> (at Thu, 9 Sep 2004 10:03:31 +1000), Herbert Xu says: > > + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; > > > > + /* > > + * The following gives us: > > + * INET_ECN_ECT_1 => check += __constant_htons(0xFFFD) > > + * INET_ECN_ECT_0 => check += __constant_htons(0xFFFE) > > + */ > > + if (__constant_htons(1) != 1) > > + ecn <<= 8; > > + check += __constant_htons(0xFFFB) + ecn; > > + > > iph->check = check + (check>=0xFFFF); > > iph->tos |= INET_ECN_CE; > > } > > s/__constant_htons/htons/g here, please. For Herbert understanding: the generated code is the same in this case. :) > > And, I think > u16 ecn = (iph->tos + 1) & INET_ECN_MASK; > > check += (u32)htons(0xfffb) + (u32)htons(ecn); > > or something like that? From yoshfuji@linux-ipv6.org Wed Sep 8 17:35:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:35:40 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890ZWWs027672 for ; Wed, 8 Sep 2004 17:35:32 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 088EB33CE6; Thu, 9 Sep 2004 09:36:26 +0900 (JST) Date: Thu, 09 Sep 2004 09:36:25 +0900 (JST) Message-Id: <20040909.093625.124940653.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au, acme@conectiva.com.br Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200409082127.57827.acme@conectiva.com.br> References: <20040909000330.GA5581@gondor.apana.org.au> <20040909.092428.125540781.yoshfuji@linux-ipv6.org> <200409082127.57827.acme@conectiva.com.br> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 8523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1071 Lines: 29 In article <200409082127.57827.acme@conectiva.com.br> (at Wed, 8 Sep 2004 21:27:57 -0300), Arnaldo Carvalho de Melo says: > Em Qua 08 Set 2004 21:24, YOSHIFUJI Hideaki / $B5HF#1QL@(B escreveu: > > In article <20040909000330.GA5581@gondor.apana.org.au> (at Thu, 9 Sep 2004 > 10:03:31 +1000), Herbert Xu says: > > > + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; > > > > > > + /* > > > + * The following gives us: > > > + * INET_ECN_ECT_1 => check += __constant_htons(0xFFFD) > > > + * INET_ECN_ECT_0 => check += __constant_htons(0xFFFE) > > > + */ > > > + if (__constant_htons(1) != 1) > > > + ecn <<= 8; > > > + check += __constant_htons(0xFFFB) + ecn; > > > + > > > iph->check = check + (check>=0xFFFF); > > > iph->tos |= INET_ECN_CE; > > > } > > > > s/__constant_htons/htons/g here, please. > > For Herbert understanding: the generated code is the same in this case. :) Yes, thanks. And, we don't use __const_{hton,ntoh}{s,l}() unless it is really required. e.g. variable initializer --yoshfuji From peter@pantasys.com Wed Sep 8 17:43:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:43:44 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890hcRc028117 for ; Wed, 8 Sep 2004 17:43:38 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 17:36:38 -0700 Message-ID: <413FA726.7070006@pantasys.com> Date: Wed, 08 Sep 2004 17:43:18 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH 2.6] IPCONFIG fix and cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2004 00:36:38.0718 (UTC) FILETIME=[1194BDE0:01C49605] X-archive-position: 8524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 729 Lines: 25 Hi David, The previous fix to DHCPACK missed declaring an iterator variable. based on some comments I modified the patch to look like the below. This will fix the promisicuous DHCPACK problem. thanks, peter Signed-off-by: Peter Buckingham --- linus-2.6/net/ipv4/ipconfig.c 2004-09-08 17:35:56.000000000 -0700 +++ local_linux/net/ipv4/ipconfig.c 2004-09-07 17:16:55.000000000 -0700 @@ -966,9 +966,7 @@ static int __init ic_bootp_recv(struct s break; case DHCPACK: - for (i = 0; (dev->dev_addr[i] == b->hw_addr[i]) - && (i < dev->addr_len); i++); - if (i < dev->addr_len) + if (memcmp(dev->dev_addr, b->hw_addr, dev->addr_len) != 0) goto drop_unlock; /* Yeah! */ From davem@redhat.com Wed Sep 8 17:48:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:48:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890mCh9028521 for ; Wed, 8 Sep 2004 17:48:12 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i890m2S0000439; Wed, 8 Sep 2004 20:48:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i890m2323806; Wed, 8 Sep 2004 20:48:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i890lx01014835; Wed, 8 Sep 2004 20:47:59 -0400 Date: Wed, 8 Sep 2004 17:48:00 -0700 From: "David S. Miller" To: Peter Buckingham Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] IPCONFIG fix and cleanup Message-Id: <20040908174800.11adc930.davem@redhat.com> In-Reply-To: <413FA726.7070006@pantasys.com> References: <413FA726.7070006@pantasys.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 428 Lines: 10 On Wed, 08 Sep 2004 17:43:18 -0700 Peter Buckingham wrote: > The previous fix to DHCPACK missed declaring an iterator variable. based > on some comments I modified the patch to look like the below. This will > fix the promisicuous DHCPACK problem. Peter, how are you generating your patches? They never apply cleanly. Maybe Mozilla is messing it up, who knows. Perhaps try using attachments instead. From acme@conectiva.com.br Wed Sep 8 17:53:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:53:37 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890rNrN028944 for ; Wed, 8 Sep 2004 17:53:24 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id DDE32476A8; Wed, 8 Sep 2004 21:53:13 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 5015D476DA for ; Wed, 8 Sep 2004 21:53:13 -0300 (BRT) Received: (qmail 4996 invoked by uid 0); 9 Sep 2004 01:51:01 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 9 Sep 2004 01:51:01 -0000 Received: from [192.168.0.2] (brinquedo [192.168.0.2]) by oops.ghostprotocols.net (Postfix) with ESMTP id 3327C76C54; Wed, 8 Sep 2004 21:55:22 -0300 (BRT) From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. To: YOSHIFUJI Hideaki / =?iso-2022-jp?q?=1B=24B5HF=231QL=40=1B=28B?= Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce Date: Wed, 8 Sep 2004 21:53:18 -0300 User-Agent: KMail/1.7 Cc: herbert@gondor.apana.org.au, davem@redhat.com, netdev@oss.sgi.com References: <20040909000330.GA5581@gondor.apana.org.au> <200409082127.57827.acme@conectiva.com.br> <20040909.093625.124940653.yoshfuji@linux-ipv6.org> In-Reply-To: <20040909.093625.124940653.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409082153.18678.acme@conectiva.com.br> X-Bogosity: No, tests=bogofilter, spamicity=0.218009, version=0.16.3 X-archive-position: 8526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 1348 Lines: 34 Em Qua 08 Set 2004 21:36, YOSHIFUJI Hideaki / $B5HF#1QL@(B escreveu: > In article <200409082127.57827.acme@conectiva.com.br> (at Wed, 8 Sep 2004 21:27:57 -0300), Arnaldo Carvalho de Melo says: > > Em Qua 08 Set 2004 21:24, YOSHIFUJI Hideaki / $B5HF#1QL@(B escreveu: > > > In article <20040909000330.GA5581@gondor.apana.org.au> (at Thu, 9 Sep > > > 2004 > > > > 10:03:31 +1000), Herbert Xu says: > > > > + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; > > > > > > > > + /* > > > > + * The following gives us: > > > > + * INET_ECN_ECT_1 => check += __constant_htons(0xFFFD) > > > > + * INET_ECN_ECT_0 => check += __constant_htons(0xFFFE) > > > > + */ > > > > + if (__constant_htons(1) != 1) > > > > + ecn <<= 8; > > > > + check += __constant_htons(0xFFFB) + ecn; > > > > + > > > > iph->check = check + (check>=0xFFFF); > > > > iph->tos |= INET_ECN_CE; > > > > } > > > > > > s/__constant_htons/htons/g here, please. > > > > For Herbert understanding: the generated code is the same in this case. > > :) > > Yes, thanks. > And, we don't use __const_{hton,ntoh}{s,l}() unless it is really required. > e.g. variable initializer Yes, that is the only case, like I learned in my early janitor days, using the __constant_ variations is not needed and makes the code needlessly ugly :) From peter@pantasys.com Wed Sep 8 17:54:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:54:52 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890slOw029290 for ; Wed, 8 Sep 2004 17:54:47 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 17:47:47 -0700 Message-ID: <413FA9C3.1080007@pantasys.com> Date: Wed, 08 Sep 2004 17:54:27 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] IPCONFIG fix and cleanup References: <413FA726.7070006@pantasys.com> <20040908174800.11adc930.davem@redhat.com> In-Reply-To: <20040908174800.11adc930.davem@redhat.com> Content-Type: multipart/mixed; boundary="------------060109070003080605060709" X-OriginalArrivalTime: 09 Sep 2004 00:47:47.0531 (UTC) FILETIME=[A03981B0:01C49606] X-archive-position: 8527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 1101 Lines: 36 This is a multi-part message in MIME format. --------------060109070003080605060709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > Peter, how are you generating your patches? They never apply > cleanly. Maybe Mozilla is messing it up, who knows. Perhaps > try using attachments instead. sorry, try this attachment instead. when i get sendmail configured properly i'll use mutt instead ;-) peter --------------060109070003080605060709 Content-Type: text/plain; name="p" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="p" --- linus-2.6/net/ipv4/ipconfig.c 2004-09-08 17:35:56.000000000 -0700 +++ local_linux/net/ipv4/ipconfig.c 2004-09-07 17:16:55.000000000 -0700 @@ -966,9 +966,7 @@ static int __init ic_bootp_recv(struct s break; case DHCPACK: - for (i = 0; (dev->dev_addr[i] == b->hw_addr[i]) - && (i < dev->addr_len); i++); - if (i < dev->addr_len) + if (memcmp(dev->dev_addr, b->hw_addr, dev->addr_len) != 0) goto drop_unlock; /* Yeah! */ --------------060109070003080605060709-- From davem@davemloft.net Wed Sep 8 17:58:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 17:59:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i890wNgB029793 for ; Wed, 8 Sep 2004 17:58:23 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5DGN-0000TQ-00; Wed, 08 Sep 2004 17:58:11 -0700 Date: Wed, 8 Sep 2004 17:58:11 -0700 From: "David S. Miller" To: Peter Buckingham Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] IPCONFIG fix and cleanup Message-Id: <20040908175811.78890c2e.davem@davemloft.net> In-Reply-To: <413FA9C3.1080007@pantasys.com> References: <413FA726.7070006@pantasys.com> <20040908174800.11adc930.davem@redhat.com> <413FA9C3.1080007@pantasys.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 481 Lines: 14 On Wed, 08 Sep 2004 17:54:27 -0700 Peter Buckingham wrote: > > Peter, how are you generating your patches? They never apply > > cleanly. Maybe Mozilla is messing it up, who knows. Perhaps > > try using attachments instead. > > sorry, try this attachment instead. when i get sendmail configured > properly i'll use mutt instead ;-) Applied, thanks. BTW I put the full fix into my 2.4.x tree as well and will push that to Marcelo when I get the chance. From peter@pantasys.com Wed Sep 8 18:02:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 18:02:10 -0700 (PDT) Received: from panta-1.pantasys.com (64-60-250-34.cust.telepacific.net [64.60.250.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89125Na030201 for ; Wed, 8 Sep 2004 18:02:05 -0700 Received: from [10.1.40.165] ([10.1.40.1]) by panta-1.pantasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Sep 2004 17:55:05 -0700 Message-ID: <413FAB79.2020205@pantasys.com> Date: Wed, 08 Sep 2004 18:01:45 -0700 From: Peter Buckingham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] IPCONFIG fix and cleanup References: <413FA726.7070006@pantasys.com> <20040908174800.11adc930.davem@redhat.com> <413FA9C3.1080007@pantasys.com> <20040908175811.78890c2e.davem@davemloft.net> In-Reply-To: <20040908175811.78890c2e.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2004 00:55:05.0734 (UTC) FILETIME=[A569FA60:01C49607] X-archive-position: 8529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: peter@pantasys.com Precedence: bulk X-list: netdev Content-Length: 178 Lines: 12 David S. Miller wrote: > Applied, thanks. > > BTW I put the full fix into my 2.4.x tree as well and will push > that to Marcelo when I get the chance. cool, thanks. peter From herbert@gondor.apana.org.au Wed Sep 8 18:10:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 18:10:52 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i891AgxW030752 for ; Wed, 8 Sep 2004 18:10:43 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5DS8-0000rP-00; Thu, 09 Sep 2004 11:10:20 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5DS4-0002Pg-00; Thu, 09 Sep 2004 11:10:16 +1000 Date: Thu, 9 Sep 2004 11:10:16 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce Message-ID: <20040909011016.GA9238@gondor.apana.org.au> References: <20040909000330.GA5581@gondor.apana.org.au> <20040909.092428.125540781.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20040909.092428.125540781.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1921 Lines: 75 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 09, 2004 at 09:24:28AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > s/__constant_htons/htons/g here, please. Good point. > And, I think > u16 ecn = (iph->tos + 1) & INET_ECN_MASK; > check += (u32)htons(0xfffb) + (u32)htons(ecn); The second htons is less optimal than the shift because htons doesn't know that ecn is only a byte. So it'll end up doing a full swap. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/inet_ecn.h 1.7 vs edited ===== --- 1.7/include/net/inet_ecn.h 2004-09-09 08:04:37 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-09 10:51:43 +10:00 @@ -49,19 +49,27 @@ static inline void IP_ECN_set_ce(struct iphdr *iph) { u32 check = iph->check; + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; - switch (iph->tos & INET_ECN_MASK) { - default: - case INET_ECN_NOT_ECT: - case INET_ECN_CE: + /* + * After the last operation we have (in binary): + * INET_ECN_NOT_ECT => 01 + * INET_ECN_ECT_1 => 10 + * INET_ECN_ECT_0 => 11 + * INET_ECN_CE => 00 + */ + if (!(ecn & 2)) return; - case INET_ECN_ECT_1: - check += __constant_htons(0xFFFD); - break; - case INET_ECN_ECT_0: - check += __constant_htons(0xFFFE); - break; - } + + /* + * The following gives us: + * INET_ECN_ECT_1 => check += htons(0xFFFD) + * INET_ECN_ECT_0 => check += htons(0xFFFE) + */ + if (htons(1) != 1) + ecn <<= 8; + check += htons(0xFFFB) + ecn; + iph->check = check + (check>=0xFFFF); iph->tos |= INET_ECN_CE; } --mYCpIKhGyMATD0i+-- From yoshfuji@linux-ipv6.org Wed Sep 8 18:26:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 18:26:50 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i891Qh1S031340 for ; Wed, 8 Sep 2004 18:26:43 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0B6CA33CE6; Thu, 9 Sep 2004 10:27:37 +0900 (JST) Date: Thu, 09 Sep 2004 10:27:36 +0900 (JST) Message-Id: <20040909.102736.94408944.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040909011016.GA9238@gondor.apana.org.au> References: <20040909000330.GA5581@gondor.apana.org.au> <20040909.092428.125540781.yoshfuji@linux-ipv6.org> <20040909011016.GA9238@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 760 Lines: 20 In article <20040909011016.GA9238@gondor.apana.org.au> (at Thu, 9 Sep 2004 11:10:16 +1000), Herbert Xu says: > On Thu, Sep 09, 2004 at 09:24:28AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > s/__constant_htons/htons/g here, please. > > Good point. > > > And, I think > > u16 ecn = (iph->tos + 1) & INET_ECN_MASK; > > check += (u32)htons(0xfffb) + (u32)htons(ecn); > > The second htons is less optimal than the shift because htons doesn't > know that ecn is only a byte. So it'll end up doing a full swap. Not true; gcc is clever enough to produces same code, and my code looks better. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From wolfgang.walter@studentenwerk.mhn.de Wed Sep 8 18:43:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 18:43:12 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i891h59d032012 for ; Wed, 8 Sep 2004 18:43:06 -0700 Received: (qmail 1496 invoked from network); 8 Sep 2004 21:42:38 -0000 Received: from mailhub.stusta.mhn.de (HELO eumel.h3.stusta.mhn.de) (10.150.127.10) by mailhub.stusta.mhn.de with SMTP; 8 Sep 2004 21:42:38 -0000 From: Wolfgang Walter To: netdev@oss.sgi.com Subject: Bad: scheduling while atomic! in 2.6.8.1 Date: Wed, 8 Sep 2004 23:42:37 +0200 User-Agent: KMail/1.7 Cc: greearb@candelatech.com Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409082342.37273.wolfgang.walter@studentenwerk.mhn.de> X-archive-position: 8532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 463 Lines: 12 We see the exactly the same with 2.6.8.1. Our host has 3 nics (all 3 are intel e100). We are using vlan, iptables (no nat or connection tracking, though) and ipsec. We tested it on other hardware (different mainboard, different nics) and the problem remains. We are getting the log for every received packet, doesn't matter if these are dhcp-requests, pings or something else. Kernel 2.6.7-rc2 works fine. We didn't test other kernels yet. Wolfgang Walter From herbert@gondor.apana.org.au Wed Sep 8 18:55:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 18:55:19 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i891t9Vs032646 for ; Wed, 8 Sep 2004 18:55:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5E97-00018B-00; Thu, 09 Sep 2004 11:54:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5E94-0003g6-00; Thu, 09 Sep 2004 11:54:42 +1000 Date: Thu, 9 Sep 2004 11:54:42 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce Message-ID: <20040909015442.GA12935@gondor.apana.org.au> References: <20040909000330.GA5581@gondor.apana.org.au> <20040909.092428.125540781.yoshfuji@linux-ipv6.org> <20040909011016.GA9238@gondor.apana.org.au> <20040909.102736.94408944.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <20040909.102736.94408944.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1993 Lines: 73 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 09, 2004 at 10:27:36AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > And, I think > > > u16 ecn = (iph->tos + 1) & INET_ECN_MASK; > > > check += (u32)htons(0xfffb) + (u32)htons(ecn); > > > > The second htons is less optimal than the shift because htons doesn't > > know that ecn is only a byte. So it'll end up doing a full swap. > > Not true; gcc is clever enough to produces same code, and my code looks better. Sorry, you're right. Here is an updated patch. Signed-off-by: Herbert Xu Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/inet_ecn.h 1.7 vs edited ===== --- 1.7/include/net/inet_ecn.h 2004-09-09 08:04:37 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-09 11:45:45 +10:00 @@ -49,19 +49,25 @@ static inline void IP_ECN_set_ce(struct iphdr *iph) { u32 check = iph->check; + u32 ecn = (iph->tos + 1) & INET_ECN_MASK; - switch (iph->tos & INET_ECN_MASK) { - default: - case INET_ECN_NOT_ECT: - case INET_ECN_CE: + /* + * After the last operation we have (in binary): + * INET_ECN_NOT_ECT => 01 + * INET_ECN_ECT_1 => 10 + * INET_ECN_ECT_0 => 11 + * INET_ECN_CE => 00 + */ + if (!(ecn & 2)) return; - case INET_ECN_ECT_1: - check += __constant_htons(0xFFFD); - break; - case INET_ECN_ECT_0: - check += __constant_htons(0xFFFE); - break; - } + + /* + * The following gives us: + * INET_ECN_ECT_1 => check += htons(0xFFFD) + * INET_ECN_ECT_0 => check += htons(0xFFFE) + */ + check += htons(0xFFFB) + htons(ecn); + iph->check = check + (check>=0xFFFF); iph->tos |= INET_ECN_CE; } --vkogqOf2sHV7VnPd-- From yoshfuji@linux-ipv6.org Wed Sep 8 18:57:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 18:57:16 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i891vARo000530 for ; Wed, 8 Sep 2004 18:57:11 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 5BCDF33CE6; Thu, 9 Sep 2004 10:58:04 +0900 (JST) Date: Thu, 09 Sep 2004 10:58:03 +0900 (JST) Message-Id: <20040909.105803.103588005.yoshfuji@linux-ipv6.org> To: davem@redhat.com, herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040909015442.GA12935@gondor.apana.org.au> References: <20040909011016.GA9238@gondor.apana.org.au> <20040909.102736.94408944.yoshfuji@linux-ipv6.org> <20040909015442.GA12935@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 435 Lines: 10 In article <20040909015442.GA12935@gondor.apana.org.au> (at Thu, 9 Sep 2004 11:54:42 +1000), Herbert Xu says: > Sorry, you're right. Here is an updated patch. > > Signed-off-by: Herbert Xu Signed-off-by: Hideaki YOSHIFUJI -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Wed Sep 8 19:35:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 19:35:22 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i892ZD3s002134 for ; Wed, 8 Sep 2004 19:35:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5Em2-0001Kn-00; Thu, 09 Sep 2004 12:34:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5Ely-00040r-00; Thu, 09 Sep 2004 12:34:54 +1000 Date: Thu, 9 Sep 2004 12:34:54 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPSEC] Fix ECN encapsulation for IPv6 Message-ID: <20040909023454.GA15407@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1850 Lines: 61 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: While doing the ECN patch I discovered that IPsec on IPv6 wasn't encapsulating the ECN correctly. This patch fixes that. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/xfrm6_output.c 1.4 vs edited ===== --- 1.4/net/ipv6/xfrm6_output.c 2004-08-25 04:30:14 +10:00 +++ edited/net/ipv6/xfrm6_output.c 2004-09-09 12:27:57 +10:00 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -36,6 +37,7 @@ struct dst_entry *dst = skb->dst; struct xfrm_state *x = dst->xfrm; struct ipv6hdr *iph, *top_iph; + int dsfield; skb_push(skb, x->props.header_len); iph = skb->nh.ipv6h; @@ -58,11 +60,14 @@ top_iph->version = 6; top_iph->priority = iph->priority; - if (x->props.flags & XFRM_STATE_NOECN) - IP6_ECN_clear(top_iph); top_iph->flow_lbl[0] = iph->flow_lbl[0]; top_iph->flow_lbl[1] = iph->flow_lbl[1]; top_iph->flow_lbl[2] = iph->flow_lbl[2]; + dsfield = ipv6_get_dsfield(top_iph); + dsfield = INET_ECN_encapsulate(dsfield, dsfield); + if (x->props.flags & XFRM_STATE_NOECN) + dsfield &= ~INET_ECN_MASK; + ipv6_change_dsfield(top_iph, 0, dsfield); top_iph->nexthdr = IPPROTO_IPV6; top_iph->hop_limit = dst_path_metric(dst, RTAX_HOPLIMIT); ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); --vtzGhvizbBRQ85DL-- From sam@errno.com Wed Sep 8 19:40:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 19:40:51 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i892ekCo003013 for ; Wed, 8 Sep 2004 19:40:46 -0700 Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i892eXWi097356 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 8 Sep 2004 19:40:33 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <200409072254.18804.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072141.58893.vkondra@mail.ru> <20040907121019.733cc7aa.davem@davemloft.net> <200409072254.18804.vkondra@mail.ru> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9F305268-0209-11D9-B232-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, "David S. Miller" , prism54-devel@prism54.org, Jeff Garzik From: Sam Leffler Subject: Re: generic 802.11 stack Date: Wed, 8 Sep 2004 19:40:33 -0700 To: Vladimir Kondratiev X-Mailer: Apple Mail (2.619) X-archive-position: 8537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 240 Lines: 10 On Sep 7, 2004, at 12:54 PM, Vladimir Kondratiev wrote: > Sam (you represent Atheros?), would you like to cooperate to make this > possible? I do not represent Atheros. I'm happy to offer advise but have zero time to write code. Sam From sam@errno.com Wed Sep 8 20:31:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 20:31:45 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i893VeYS008014 for ; Wed, 8 Sep 2004 20:31:40 -0700 Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i893VGWi097498 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 8 Sep 2004 20:31:16 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <200409090019.21105.vda@port.imtp.ilyichevsk.odessa.ua> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <413F2D33.1000508@atheros.com> <200409082251.45771.vkondra@mail.ru> <200409090019.21105.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com, Vladimir Kondratiev , prism54-devel@prism54.org, greg chesson , acx100-devel@lists.sourceforge.net, jgarzik@pobox.com, hadi@cyberus.ca, jkmaline@cc.hut.fi, "David S. Miller" From: Sam Leffler Subject: Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Wed, 8 Sep 2004 20:31:18 -0700 To: Denis Vlasenko X-Mailer: Apple Mail (2.619) X-archive-position: 8538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 3711 Lines: 87 On Sep 8, 2004, at 2:19 PM, Denis Vlasenko wrote: > On Wednesday 08 September 2004 22:51, Vladimir Kondratiev wrote: >> Greg, >> you missed one important point. Besides data packets, that every >> driver now >> convert .11<->.3 using almost the same code, there is whole story of >> management. Many modern cards are "softmac" and do all management on >> host. >> I see no point for every driver to implement its own scanning and >> association. It is simply waste of resources. > > This is exactly what I meant. We need generic 802.11 idioc^W management > handling. And maybe also tx rate control, ACK/retries for > "completely-softmac" > cards like Atheros. The net80211 code has generic 802.11 management handling based on wireless extensions. Drivers that sit beneath it and have the necessary capabilities automatically are usable, for example, with wpa_supplicant (and soon hostapd). At the moment there is one driver for Linux--the ath driver for Atheros h/w. Rate control is another can-o-worms. The model we've taken is that it is driver-specific. I'd be very surprised to see "softmac" h/w come along that requires the host to generate ACK frames explicitly; the timing is very tight and it would suck a lot of cycles from the host. > > Full spectrum of possible fullmac......softmac designs are not trivial > to handle... Experience with net80211 indicates you're fine if you have a good 802.11 protocol implementation to fall back on. Then devices that have functionality in h/w just supplant the s/w support. The net80211 code defines a set of device capabilities that indicate, for example, when a device supports various h/w crypto algorithms. Class-like method override mechanisms are used to handle other issues. This stuff is constantly evolving as more devices are hooked up but in general it's worked out pretty well. I've tried to avoid a spaghetti web of function pointers using callbacks only where it seems most drivers will make use of them. For other cases it often is easier to grab control early on so it's easier to optimize+share code. A concrete example of this is the processing of 802.11 management frames where the original code (that David saw) had an array of function pointers to little routines that handled each frame type--it turned out drivers didn't override these pointers so I removed them and drivers that want to override the default processing override the "recv management" method to intercept specific frames. > >> To make step forward, I suggest the following: >> >> 1. Dave's code is at least year old. someone need to start maintain >> it, >> starting with update for current kernel infrastructure. Get it >> compile and >> load for 2.6.9, for example. > > /me runs away and hides > >> 2. To debug stack, you don't need real driver. I can write dummy .11 >> driver >> that will silently discard all Tx, and will provide some way for user >> level >> tool to simulate Rx (ioctl, netlink, does not really matter). For >> logic, it >> is sufficient. Later, when it will come to timing, performance etc, >> it will >> be easy to strip some real driver. To evaluate a design and implementation show support for a few devices at each end of the spectrum. The Atheros h/w is probably a good example of softmac h/w. ADMTek 8211 is also in this category. I'd consider Prism devices toward the other end. You also need to be sure you handle single- and dual-band operation as each have different requirements. Also 11g support takes work to get right so be sure you have a softmac 11g card in the pile. Past that you get into the security protocols, WME/WMM, etc. Sound like a lot of work? It is. Sam From herbert@gondor.apana.org.au Wed Sep 8 20:45:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 20:46:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i893jqNV008680 for ; Wed, 8 Sep 2004 20:45:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5Fs2-0001YR-00; Thu, 09 Sep 2004 13:45:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5Frw-00055j-00; Thu, 09 Sep 2004 13:45:08 +1000 Date: Thu, 9 Sep 2004 13:45:08 +1000 To: "David S. Miller" , YOSHIFUJI Hideaki , vnourval@tcs.hut.fi, netdev@oss.sgi.com Subject: [IP6IP6] Handle ECN correctly Message-ID: <20040909034508.GA19547@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2360 Lines: 85 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch adds ECN encapsulation/decapsulation to ip6_tunnel.c. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv6/ip6_tunnel.c 1.23 vs edited ===== --- 1.23/net/ipv6/ip6_tunnel.c 2004-06-22 07:34:06 +10:00 +++ edited/net/ipv6/ip6_tunnel.c 2004-09-09 13:34:19 +10:00 @@ -48,6 +48,8 @@ #include #include #include +#include +#include MODULE_AUTHOR("Ville Nuorvala"); MODULE_DESCRIPTION("IPv6-in-IPv6 tunnel"); @@ -490,6 +492,15 @@ read_unlock(&ip6ip6_lock); } +static inline void ip6ip6_ecn_decapsulate(struct ipv6hdr *outer_iph, + struct sk_buff *skb) +{ + struct ipv6hdr *inner_iph = skb->nh.ipv6h; + + if (INET_ECN_is_ce(ipv6_get_dsfield(outer_iph))) + IP6_ECN_set_ce(inner_iph); +} + /** * ip6ip6_rcv - decapsulate IPv6 packet and retransmit it locally * @skb: received socket buffer @@ -531,6 +542,7 @@ skb->dev = t->dev; dst_release(skb->dst); skb->dst = NULL; + ip6ip6_ecn_decapsulate(ipv6h, skb); t->stat.rx_packets++; t->stat.rx_bytes += skb->len; netif_rx(skb); @@ -621,6 +633,7 @@ u8 proto; int err; int pkt_len; + int dsfield; if (t->recursion++) { stats->collisions++; @@ -646,6 +659,7 @@ memcpy(&fl, &t->fl, sizeof (fl)); proto = fl.proto; + dsfield = ipv6_get_dsfield(ipv6h); if ((t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS)) fl.fl6_flowlabel |= (*(__u32 *) ipv6h & IPV6_TCLASS_MASK); if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FLOWLABEL)) @@ -717,6 +731,8 @@ skb->nh.raw = skb_push(skb, sizeof(struct ipv6hdr)); ipv6h = skb->nh.ipv6h; *(u32*)ipv6h = fl.fl6_flowlabel | htonl(0x60000000); + dsfield = INET_ECN_encapsulate(0, dsfield); + ipv6_change_dsfield(ipv6h, ~INET_ECN_MASK, dsfield); ipv6h->payload_len = htons(skb->len - sizeof(struct ipv6hdr)); ipv6h->hop_limit = t->parms.hop_limit; ipv6h->nexthdr = proto; --UlVJffcvxoiEqYs2-- From davem@davemloft.net Wed Sep 8 21:27:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:27:19 -0700 (PDT) Received: from smtp105.mail.sc5.yahoo.com (smtp105.mail.sc5.yahoo.com [66.163.169.225]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i894RDAg010214 for ; Wed, 8 Sep 2004 21:27:13 -0700 Received: from unknown (HELO cheetah.davemloft.net) (davem?330@63.197.226.105 with login) by smtp105.mail.sc5.yahoo.com with SMTP; 9 Sep 2004 04:27:03 -0000 Date: Wed, 8 Sep 2004 21:26:59 -0700 From: "David S. Miller" To: Wolfgang Walter Cc: netdev@oss.sgi.com, greearb@candelatech.com, shemminger@osdl.org Subject: Re: Bad: scheduling while atomic! in 2.6.8.1 Message-Id: <20040908212659.4cd99935.davem@davemloft.net> In-Reply-To: <200409082342.37273.wolfgang.walter@studentenwerk.mhn.de> References: <200409082342.37273.wolfgang.walter@studentenwerk.mhn.de> Organization: DaveM Loft Enterprises X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1318 Lines: 41 On Wed, 8 Sep 2004 23:42:37 +0200 Wolfgang Walter wrote: > We see the exactly the same with 2.6.8.1. > > Our host has 3 nics (all 3 are intel e100). We are using vlan, iptables (no > nat or connection tracking, though) and ipsec. We tested it on other hardware > (different mainboard, different nics) and the problem remains. > > We are getting the log for every received packet, doesn't matter if these are > dhcp-requests, pings or something else. You have CONFIG_PREEMPT enabled don't you? This should fix it, it's a bug in Stephen's conversion of the VLAN code over to use RCU locking. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/08 21:07:49-07:00 davem@nuts.davemloft.net # [VLAN]: Fix thinko in RCU locking. # # Signed-off-by: David S. Miller # # net/8021q/vlan_dev.c # 2004/09/08 21:07:19-07:00 davem@nuts.davemloft.net +1 -1 # [VLAN]: Fix thinko in RCU locking. # diff -Nru a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c --- a/net/8021q/vlan_dev.c 2004-09-08 21:08:30 -07:00 +++ b/net/8021q/vlan_dev.c 2004-09-08 21:08:30 -07:00 @@ -244,7 +244,7 @@ /* TODO: Add a more specific counter here. */ stats->rx_errors++; } - rcu_read_lock(); + rcu_read_unlock(); return 0; } From davem@davemloft.net Wed Sep 8 21:35:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:35:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894ZlY3010736 for ; Wed, 8 Sep 2004 21:35:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5GeY-0000f1-00; Wed, 08 Sep 2004 21:35:22 -0700 Date: Wed, 8 Sep 2004 21:35:22 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [INET] Optimise away a branch in IP_ECN_set_ce Message-Id: <20040908213522.50fcd1f9.davem@davemloft.net> In-Reply-To: <20040909.105803.103588005.yoshfuji@linux-ipv6.org> References: <20040909011016.GA9238@gondor.apana.org.au> <20040909.102736.94408944.yoshfuji@linux-ipv6.org> <20040909015442.GA12935@gondor.apana.org.au> <20040909.105803.103588005.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i894ZlY3010736 X-archive-position: 8541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 290 Lines: 10 On Thu, 09 Sep 2004 10:58:03 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: >> Signed-off-by: Herbert Xu > Signed-off-by: Hideaki YOSHIFUJI Signed-off-by: David S. Miller :-) From mcgrof@studorgs.rutgers.edu Wed Sep 8 21:36:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:37:03 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894aw6b011048 for ; Wed, 8 Sep 2004 21:36:58 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id AAC44F99BE; Thu, 9 Sep 2004 00:36:48 -0400 (EDT) Date: Thu, 9 Sep 2004 00:36:48 -0400 To: Netdev Cc: prism54-devel@prism54.org Subject: Re: generic 802.11 stack Message-ID: <20040909043648.GJ31207@ruslug.rutgers.edu> Mail-Followup-To: Netdev , prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409072141.58893.vkondra@mail.ru> <20040907121019.733cc7aa.davem@davemloft.net> <200409072254.18804.vkondra@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409072254.18804.vkondra@mail.ru> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 8542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1566 Lines: 36 On Tue, Sep 07, 2004 at 10:54:12PM +0300, Vladimir Kondratiev wrote: > Anyone doing drivers for Intersil and Broadcom, are you on this list? Would > you join this effort? In regards to Intersil 802.11g chipsets and new card support lead by the prism54 project, we haven't yet been provided with specs for the new softmac chipsets nor an updated source base but regardless I'm sure we'll have to do a lot of cleaning/code nuking so sure why not. We still have work to complete for prism54 and have nothing solid to work on for a new softmac driver so participation with this effort may take a while. If we don't hear back from Conexant in regards to the softmac chipsets we will just have to use that old code posted earlier as base for new development. The softmac driver is "supposed" to be backward compatible with the fullmac chipsets as well as with the firmware for them but I've heard this backward compatiblity has been broken. This is unfortunate as if this backward compatibility does not work it would be the requirement of two separate prism54-type drivers. We've also discussed re-writing our current fullmac driver for two purposes: 1. Dual licensing (FBSD/GPL) 2. Start using/help writing this new generic 802.11 stack 3. Cleaning the code It may be the case that we can just re-write the fullmac driver in hopes that we can later adapt/include softmac code. We need questions answered for this though so hopefully Conexant will start talking to us again. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From davem@davemloft.net Wed Sep 8 21:39:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:39:20 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894dFHA011386 for ; Wed, 8 Sep 2004 21:39:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5Ghz-0000fl-00; Wed, 08 Sep 2004 21:38:55 -0700 Date: Wed, 8 Sep 2004 21:38:55 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPSEC] Fix ECN encapsulation for IPv6 Message-Id: <20040908213855.084f53e2.davem@davemloft.net> In-Reply-To: <20040909023454.GA15407@gondor.apana.org.au> References: <20040909023454.GA15407@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 483 Lines: 15 On Thu, 9 Sep 2004 12:34:54 +1000 Herbert Xu wrote: > While doing the ECN patch I discovered that IPsec on IPv6 wasn't > encapsulating the ECN correctly. This patch fixes that. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. Please use my davem@davemloft.net email address in the future, as that is what I'd like people to use to contact me. This is what is listed in CREDITS and MAINTAINERS as well. Thanks. From davem@davemloft.net Wed Sep 8 21:40:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:40:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894el6L011722 for ; Wed, 8 Sep 2004 21:40:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5GjP-0000g9-00; Wed, 08 Sep 2004 21:40:23 -0700 Date: Wed, 8 Sep 2004 21:40:23 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, vnourval@tcs.hut.fi, netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-Id: <20040908214023.08dec350.davem@davemloft.net> In-Reply-To: <20040909034508.GA19547@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 286 Lines: 10 On Thu, 9 Sep 2004 13:45:08 +1000 Herbert Xu wrote: > This patch adds ECN encapsulation/decapsulation to ip6_tunnel.c. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. How are those TTL encap fixes coming along? ;-) From herbert@gondor.apana.org.au Wed Sep 8 21:43:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:44:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894hp2S012073 for ; Wed, 8 Sep 2004 21:43:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5GmY-0001nc-00; Thu, 09 Sep 2004 14:43:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5GmW-0005Cu-00; Thu, 09 Sep 2004 14:43:36 +1000 Date: Thu, 9 Sep 2004 14:43:36 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-ID: <20040909044336.GA19999@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908214023.08dec350.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 437 Lines: 14 On Wed, Sep 08, 2004 at 09:40:23PM -0700, David S. Miller wrote: > > How are those TTL encap fixes coming along? ;-) It went so well that you've already merged it :) It's the last change on net/ipv*/xfrm*_output.c. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Wed Sep 8 21:49:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:49:54 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894nmUi012433 for ; Wed, 8 Sep 2004 21:49:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5GsA-0000hN-00; Wed, 08 Sep 2004 21:49:26 -0700 Date: Wed, 8 Sep 2004 21:49:26 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-Id: <20040908214926.51b56a66.davem@davemloft.net> In-Reply-To: <20040909044336.GA19999@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> <20040909044336.GA19999@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 650 Lines: 20 On Thu, 9 Sep 2004 14:43:36 +1000 Herbert Xu wrote: > On Wed, Sep 08, 2004 at 09:40:23PM -0700, David S. Miller wrote: > > > > How are those TTL encap fixes coming along? ;-) > > It went so well that you've already merged it :) > > It's the last change on net/ipv*/xfrm*_output.c. We were going to make all the ipv4 tunnels offer encapsulation behavior for these fields that matched the two major models of behavior described in the IP tunneling RFCs. Specifically I'm talking about the Uniform and the Pipe model described in RFC-2983. I would expect a change for that to occur in net/ipv4/ipip.c or similar. :) From herbert@gondor.apana.org.au Wed Sep 8 21:54:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 21:54:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i894sW8x012929 for ; Wed, 8 Sep 2004 21:54:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5Gwr-0001rT-00; Thu, 09 Sep 2004 14:54:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5Gwp-0005EI-00; Thu, 09 Sep 2004 14:54:15 +1000 Date: Thu, 9 Sep 2004 14:54:15 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-ID: <20040909045415.GA20079@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> <20040909044336.GA19999@gondor.apana.org.au> <20040908214926.51b56a66.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908214926.51b56a66.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 759 Lines: 23 On Wed, Sep 08, 2004 at 09:49:26PM -0700, David S. Miller wrote: > > We were going to make all the ipv4 tunnels offer encapsulation > behavior for these fields that matched the two major models > of behavior described in the IP tunneling RFCs. > > Specifically I'm talking about the Uniform and the Pipe model > described in RFC-2983. You mean the TOS field? > I would expect a change for that to occur in net/ipv4/ipip.c > or similar. :) OK, I'll take a look at this. I presume that the TOS options in ip6tunnel.c is to your liking? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Wed Sep 8 22:08:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 22:08:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8958SDi013433 for ; Wed, 8 Sep 2004 22:08:30 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5HAA-0000jW-00; Wed, 08 Sep 2004 22:08:02 -0700 Date: Wed, 8 Sep 2004 22:08:02 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-Id: <20040908220802.1c25b806.davem@davemloft.net> In-Reply-To: <20040909045415.GA20079@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> <20040909044336.GA19999@gondor.apana.org.au> <20040908214926.51b56a66.davem@davemloft.net> <20040909045415.GA20079@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 286 Lines: 10 On Thu, 9 Sep 2004 14:54:15 +1000 Herbert Xu wrote: > > I would expect a change for that to occur in net/ipv4/ipip.c > > or similar. :) > > OK, I'll take a look at this. I presume that the TOS options > in ip6tunnel.c is to your liking? It looks fine. From vkondra@mail.ru Wed Sep 8 22:16:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 08 Sep 2004 22:16:06 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i895FwZl013965 for ; Wed, 8 Sep 2004 22:16:01 -0700 Received: from [81.218.208.137] (port=45557 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C5HHg-0007Rf-00; Thu, 09 Sep 2004 09:15:48 +0400 From: Vladimir Kondratiev To: netdev@oss.sgi.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Thu, 9 Sep 2004 00:54:47 +0300 User-Agent: KMail/1.7 Cc: greg chesson , "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409082251.45771.vkondra@mail.ru> <413F70F0.6020709@atheros.com> In-Reply-To: <413F70F0.6020709@atheros.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1592424.FD8qnxMVIZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409090815.40358.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2119 Lines: 58 --nextPart1592424.FD8qnxMVIZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline gc> gc> Linux does the same thing (driver is configured by application code) gc> although there does not yet exist a single app gc> that can serve as a common point of control for multiple vendor drivers. gc> I believe that achieving that goal is the real payoff for wireless Linux gc> users. I would not fully agree here: for timing reasons, you can do scanning/AP=20 selection in user space, but for rate scaling, if we ever can do it generic= ,=20 you better be in kernel. =46rom architecture point of view, MLME should be stack, not user app. For = me,=20 management packets generation is same kind of activity as arp.=20 gc> gc> > It is simply waste of resources. gc> > gc> > To make step forward, I suggest the following: gc> > gc> > 1. Dave's code is at least year old. someone need to start maintain i= t, gc> > starting with update for current kernel infrastructure. Get it compile and gc> > load for 2.6.9, for example. gc> > gc> > 2. To debug stack, you don't need real driver. I can write dummy .11 driver gc> > that will silently discard all Tx, and will provide some way for user level gc> > tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it gc> > is sufficient. Later, when it will come to timing, performance etc, it will gc> > be easy to strip some real driver. gc> > gc> > This may be king of "proof of concept". gc> gc> Yes, for logic it is sufficient. gc> My personal approach would be to test the theory by examining gc> what fits or doesn't fit into David's API if I were to port one of the gc> MLME implementations that I work with. Discover if it fits or not. Sounds promising. Don't forget to share you findings. --nextPart1592424.FD8qnxMVIZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBP+b7qxdj7mhC6o0RAnVMAKCLcqspPDtHQ094POfHlsBkQkPheQCeLQMS bxubWRBaaZ6IlUdPinIB6YE= =UHCq -----END PGP SIGNATURE----- --nextPart1592424.FD8qnxMVIZ-- From pekkas@netcore.fi Thu Sep 9 00:05:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 00:05:22 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8975ETt017017 for ; Thu, 9 Sep 2004 00:05:15 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8974Yi23971; Thu, 9 Sep 2004 10:04:34 +0300 Date: Thu, 9 Sep 2004 10:04:33 +0300 (EEST) From: Pekka Savola To: "David S. Miller" cc: Herbert Xu , Subject: Re: [IP6IP6] Handle ECN correctly In-Reply-To: <20040908214926.51b56a66.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 729 Lines: 19 On Wed, 8 Sep 2004, David S. Miller wrote: > We were going to make all the ipv4 tunnels offer encapsulation > behavior for these fields that matched the two major models > of behavior described in the IP tunneling RFCs. > > Specifically I'm talking about the Uniform and the Pipe model > described in RFC-2983. Now that we're talking about RFCs and tunnels, I'd like to point out draft-ietf-v6ops-mech-v2-06.txt which replaces the old v6-in-v4 tunneling RFC, and is at the point of approval as RFC. Sorry for hijacking the thread :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jab@cs.sun.ac.za Thu Sep 9 00:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 00:24:16 -0700 (PDT) Received: from mail1.sun.ac.za (mail1.sun.ac.za [146.232.64.12]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i897O0pe020952 for ; Thu, 9 Sep 2004 00:24:02 -0700 Received: from eniac.cs.sun.ac.za ([146.232.212.17]) by mail1.sun.ac.za with esmtp (Exim 4.34) id 1C5JHa-0000xu-Dr for netdev@oss.sgi.com; Thu, 09 Sep 2004 09:23:50 +0200 Received: from poulenc.cs.sun.ac.za ([146.232.212.135]) by eniac.cs.sun.ac.za with esmtp (Exim 4.30) id 1C5JFV-00088N-42 for netdev@oss.sgi.com; Thu, 09 Sep 2004 09:21:41 +0200 Subject: [Fwd: Re: question: linux TCP/IP stack implementation] From: Hanno Reply-To: jab@cs.sun.ac.za To: netdev Content-Type: text/plain Organization: University of Stellenbosch Message-Id: <1094714541.15115.23.camel@poulenc.cs.sun.ac.za> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-2.1.92mdk Date: Thu, 09 Sep 2004 09:22:21 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 8551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jab@cs.sun.ac.za Precedence: bulk X-list: netdev Content-Length: 953 Lines: 29 Alan Cox refered me to here. Could you direct me to any good documentation on the implementation of the TCP/IP stack in the linux kernel. I'm a Msc sudent of the University of Stellenbosch, South Africa. As an experiment I wat to replace the linux TCP implementation with a model checked version. Regards. Hanno Bezuidenhout -----Forwarded Message----- From: Alan Cox To: jab@cs.sun.ac.za Subject: Re: question: linux TCP/IP stack implementation Date: Wed, 08 Sep 2004 13:41:50 +0100 On Mer, 2004-09-08 at 13:21, Hanno wrote: > The problem is this: I'm really strugling to find (relevant) > documentation on the implementation of the TCP/IP stack in the linux > kernel. Do any exist and if so where does one find it (links, etc). Other than the code I'm not sure there is a really good document. Sadly the late Richard Stevens never documented Linux TCP/IP as he did BSD. Your best place to ask is netdev@oss.sgi.com From SRS0+33a403b26adac0156962+382+infradead.org+dwmw2@canuck.srs.infradead.org Thu Sep 9 00:58:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 00:58:20 -0700 (PDT) Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i897wFQ1021977 for ; Thu, 9 Sep 2004 00:58:15 -0700 Received: from imladris.demon.co.uk ([193.237.130.41] helo=[192.168.1.253]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1C5Joi-0004xT-Cf; Thu, 09 Sep 2004 03:58:05 -0400 Subject: Re: [PATCH] Compat32 setsockopt overzealous conversions From: David Woodhouse To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20040907140649.42eaa278.davem@davemloft.net> References: <1094563381.5122.8.camel@localhost.localdomain> <20040907140649.42eaa278.davem@davemloft.net> Content-Type: text/plain Date: Thu, 09 Sep 2004 08:53:18 +0100 Message-Id: <1094716398.15909.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 (1.5.94.1-1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 3119 Lines: 76 On Tue, 2004-09-07 at 14:06 -0700, David S. Miller wrote: > I know it's a pain in the ass, but could you cook up > a 2.4.x version? Thanks. Untested -- I feel dirty enough just for _looking_ at such ancient code, let alone compiling it for all the various platforms which each used to have their own version of the 32/64 compatibility stuff in those days. I note mips64 and x86_64 have a 'do_set_icmpv6_filter' which the 2.6 compat_sys_setsockopt() lacks. Back in the real world of 2.6, we REALLY do need to stop trying to do all this in a sockopt syscall wrapper, and instead pass down a 32/64 bit flag to the code which actually handles the sockopt -- although the optlen ought to be sufficient for the _majority_ of cases. Or maybe we should handle it like we do ioctls? ===== arch/mips64/kernel/linux32.c 1.12 vs edited ===== --- 1.12/arch/mips64/kernel/linux32.c 2003-10-31 15:58:30 +00:00 +++ edited/arch/mips64/kernel/linux32.c 2004-09-09 08:51:03 +01:00 @@ -1568,7 +1568,7 @@ asmlinkage int sys32_setsockopt(int fd, int level, int optname, char *optval, int optlen) { - if (optname == SO_ATTACH_FILTER) + if (level == SOL_SOCKET && optname == SO_ATTACH_FILTER) return do_set_attach_filter(fd, level, optname, optval, optlen); if (level == SOL_ICMPV6 && optname == ICMPV6_FILTER) ===== arch/ppc64/kernel/sys_ppc32.c 1.8 vs edited ===== --- 1.8/arch/ppc64/kernel/sys_ppc32.c 2003-12-15 05:55:19 +00:00 +++ edited/arch/ppc64/kernel/sys_ppc32.c 2004-09-09 08:46:05 +01:00 @@ -3221,7 +3221,7 @@ PPCDBG(PPCDBG_SYS32,"sys32_setsockopt - running - pid=%ld, comm=%s\n", current->pid, current->comm); - if (optname == SO_ATTACH_FILTER) { + if (level == SOL_SOCKET && optname == SO_ATTACH_FILTER) { struct sock_fprog32 { __u16 len; __u32 filter; ===== arch/sparc64/kernel/sys_sparc32.c 1.33 vs edited ===== --- 1.33/arch/sparc64/kernel/sys_sparc32.c 2004-03-27 05:08:52 +00:00 +++ edited/arch/sparc64/kernel/sys_sparc32.c 2004-09-09 08:47:26 +01:00 @@ -2996,10 +2996,11 @@ if (optname == IPT_SO_SET_REPLACE) return do_netfilter_replace(fd, level, optname, optval, optlen); - if (optname == SO_ATTACH_FILTER) + if (level == SOL_SOCKET && optname == SO_ATTACH_FILTER) return do_set_attach_filter(fd, level, optname, optval, optlen); - if (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO) + if (level == SOL_SOCKET && + (optname == SO_RCVTIMEO || optname == SO_SNDTIMEO)) return do_set_sock_timeout(fd, level, optname, optval, optlen); return sys_setsockopt(fd, level, optname, optval, optlen); ===== arch/x86_64/ia32/socket32.c 1.4 vs edited ===== --- 1.4/arch/x86_64/ia32/socket32.c 2003-06-24 21:44:22 +01:00 +++ edited/arch/x86_64/ia32/socket32.c 2004-09-09 08:52:23 +01:00 @@ -555,7 +555,7 @@ asmlinkage long sys32_setsockopt(int fd, int level, int optname, char *optval, int optlen) { - if (optname == SO_ATTACH_FILTER) + if (level == SOL_SOCKET && optname == SO_ATTACH_FILTER) return do_set_attach_filter(fd, level, optname, optval, optlen); if (level == SOL_ICMPV6 && optname == ICMPV6_FILTER) -- dwmw2 From fork0@users.sourceforge.net Thu Sep 9 04:13:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 04:14:12 -0700 (PDT) Received: from mx1.valuehost.ru (mx1.valuehost.ru [62.118.251.208]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i89BDs8V010208 for ; Thu, 9 Sep 2004 04:13:54 -0700 Received: (qmail 50870 invoked by uid 89); 9 Sep 2004 15:13:44 +0400 Received: from unknown (HELO mx0.valuehost.ru) (62.118.251.6) by mx1.valuehost.ru with SMTP; 9 Sep 2004 15:13:43 +0400 Received: (qmail 50774 invoked by uid 89); 9 Sep 2004 15:12:43 +0400 Received: from unknown (HELO tigra.home) (fork0@delphiplus.org@80.140.236.152) by mx0.valuehost.ru with SMTP; 9 Sep 2004 15:12:39 +0400 Received: from steel.home ([192.168.1.2]) by tigra.home with esmtp (Exim 3.36 #1 (Debian)) id 1C5Mqw-0002Sr-00; Thu, 09 Sep 2004 13:12:34 +0200 Received: from raa by steel.home with local (Exim 4.24 #1 (Debian)) id 1C5Mqv-00013N-PP; Thu, 09 Sep 2004 13:12:33 +0200 Date: Thu, 9 Sep 2004 13:12:33 +0200 From: Alex Riesen To: linux-kernel Cc: netdev@oss.sgi.com Subject: 2.6.9-rc1+bk: assertion tcp_get_pcount failed at net/ipv4/tcp_input.c Message-ID: <20040909111233.GA3987@steel.home> Reply-To: Alex Riesen Mail-Followup-To: Alex Riesen , linux-kernel , netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 8553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fork0@users.sourceforge.net Precedence: bulk X-list: netdev Content-Length: 33623 Lines: 1519 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The box froze after being left for some time (some 10 hours) unattended. The only thing in I could find in logs was: Sep 8 22:30:18 steel kernel: KERNEL: assertion ((int)tcp_get_pcount(&tp->lost_out) >= 0) failed at net/ipv4/tcp_input.c (2422) Sep 8 22:30:18 steel kernel: Leak l=4294967295 4 Sep 8 22:32:49 steel kernel: KERNEL: assertion ((int)tcp_get_pcount(&tp->lost_out) >= 0) failed at net/ipv4/tcp_input.c (2422) Sep 8 22:32:50 steel last message repeated 2 times Sep 8 22:32:50 steel kernel: Leak l=4294967295 3 This can probably be not the reason. I do not know the actual time. There should have been some traffic (two bittorrents were running). The .config attached. --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".config" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.9-rc1+bk # Wed Sep 8 20:31:04 2004 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # CONFIG_EDD=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=m # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_PROC_INTF is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m # CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_TABLE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=m # CONFIG_SCSI_SATA_NV is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set # CONFIG_IEEE1394_RAWIO is not set # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m # CONFIG_IPV6_TUNNEL is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m # CONFIG_IP_NF_CT_ACCT is not set # CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m # CONFIG_IP_NF_MATCH_SCTP is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_TARGET_NOTRACK=m # CONFIG_IP_NF_ARPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set # CONFIG_IP6_NF_IPTABLES is not set CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_CLS_U32_PERF is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_L2CAP=m # CONFIG_BT_SCO is not set CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m # CONFIG_BT_HCIUSB_SCO is not set # CONFIG_BT_HCIUART is not set # CONFIG_BT_HCIBCM203X is not set # CONFIG_BT_HCIBFUSB is not set # CONFIG_BT_HCIVHCI is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m CONFIG_TULIP_MWI=y CONFIG_TULIP_MMIO=y # CONFIG_TULIP_NAPI is not set CONFIG_DE4X5=m # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m # CONFIG_E100_NAPI is not set # CONFIG_FEALNX is not set CONFIG_NATSEMI=m # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set CONFIG_8139TOO_TUNE_TWISTER=y CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_VELOCITY is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_UINPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set CONFIG_RTC=m # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m CONFIG_AGP_INTEL_MCH=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_ISA is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set CONFIG_I2C_PIIX4=m # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set CONFIG_VIDEO_SAA7134=m # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set CONFIG_USB_EHCI_ROOT_HUB_TT=y # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_RW_DETECT=y CONFIG_USB_STORAGE_DATAFAB=y # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y # CONFIG_REISERFS_FS_POSIX_ACL is not set # CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=y CONFIG_NLS_CODEPAGE_855=m # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set CONFIG_NLS_CODEPAGE_866=m # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=m # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_INFO is not set CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_4KSTACKS=y CONFIG_SCHEDSTATS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # CONFIG_SECURITY=y # CONFIG_SECURITY_NETWORK is not set CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set # CONFIG_SECURITY_SELINUX is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WHIRLPOOL=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC_CCITT=y CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --Kj7319i9nmIyA2yE-- From wolfgang.walter@studentenwerk.mhn.de Thu Sep 9 04:57:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 04:57:10 -0700 (PDT) Received: from mailin.studentenwerk.mhn.de (neu-ulm.studentenwerk.mhn.de [141.84.225.226]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i89Bv3YR014583 for ; Thu, 9 Sep 2004 04:57:04 -0700 Received: (qmail 14536 invoked from network); 9 Sep 2004 11:56:48 -0000 Received: from s007003.int.studentenwerk.mhn.de (HELO mailhub.studentenwerk.mhn.de) (10.148.7.3) by mailin.peri.studentenwerk.mhn.de with SMTP; 9 Sep 2004 11:56:48 -0000 Received: (qmail 3234 invoked from network); 9 Sep 2004 11:56:48 -0000 Received: from mist.studentenwerk.mhn.de (10.148.0.24) by mailhub.studentenwerk.mhn.de with SMTP; 9 Sep 2004 11:56:48 -0000 From: Wolfgang Walter Organization: Studentenwerk =?iso-8859-1?q?M=FCnchen?= To: "David S. Miller" Subject: Re: Bad: scheduling while atomic! in 2.6.8.1 Date: Thu, 9 Sep 2004 13:56:47 +0200 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com, greearb@candelatech.com, shemminger@osdl.org References: <200409082342.37273.wolfgang.walter@studentenwerk.mhn.de> <20040908212659.4cd99935.davem@davemloft.net> In-Reply-To: <20040908212659.4cd99935.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200409091356.47325.wolfgang.walter@studentenwerk.mhn.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i89Bv3YR014583 X-archive-position: 8554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wolfgang.walter@studentenwerk.mhn.de Precedence: bulk X-list: netdev Content-Length: 1648 Lines: 58 Am Donnerstag, 9. September 2004 06:26 schrieb David S. Miller: > On Wed, 8 Sep 2004 23:42:37 +0200 > > Wolfgang Walter wrote: > > We see the exactly the same with 2.6.8.1. > > > > Our host has 3 nics (all 3 are intel e100). We are using vlan, iptables > > (no nat or connection tracking, though) and ipsec. We tested it on other > > hardware (different mainboard, different nics) and the problem remains. > > > > We are getting the log for every received packet, doesn't matter if these > > are dhcp-requests, pings or something else. > > You have CONFIG_PREEMPT enabled don't you? > Yes. > This should fix it, it's a bug in Stephen's conversion of the VLAN > code over to use RCU locking. > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2004/09/08 21:07:49-07:00 davem@nuts.davemloft.net > # [VLAN]: Fix thinko in RCU locking. > # > # Signed-off-by: David S. Miller > # > # net/8021q/vlan_dev.c > # 2004/09/08 21:07:19-07:00 davem@nuts.davemloft.net +1 -1 > # [VLAN]: Fix thinko in RCU locking. > # > diff -Nru a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c > --- a/net/8021q/vlan_dev.c 2004-09-08 21:08:30 -07:00 > +++ b/net/8021q/vlan_dev.c 2004-09-08 21:08:30 -07:00 > @@ -244,7 +244,7 @@ > /* TODO: Add a more specific counter here. */ > stats->rx_errors++; > } > - rcu_read_lock(); > + rcu_read_unlock(); > return 0; > } Yes, this fixes the problem. Thank you very much, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts EDV Leopoldstraße 15 80802 München http://www.studentenwerk.mhn.de/ From herbert@gondor.apana.org.au Thu Sep 9 05:15:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 05:15:20 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89CF7uJ015596 for ; Thu, 9 Sep 2004 05:15:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5No6-0004Pt-00; Thu, 09 Sep 2004 22:13:42 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5Nnw-0000eq-00; Thu, 09 Sep 2004 22:13:32 +1000 Date: Thu, 9 Sep 2004 22:13:32 +1000 To: kuznet@ms2.inr.ac.ru, davem@davemloft.net, jmorris@redhat.com, netdev@oss.sgi.com Subject: [IPSEC] Find larval SAs by sequence number Message-ID: <20040909121332.GA31902@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4829 Lines: 190 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: When larval states are generated along with ACQUIRE messages, we should use the sequence to find the corresponding larval state when creating states with ADD_SA or ALLOC_SPI. If we don't do that, then it may take down an unrelated larval state with the same parameters (think different TCP sessions). This not only leaves behind a larval state that shouldn't be there, it may also cause another ACQUIRE message to be sent unnecessarily. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="byseq.patch" ===== include/net/xfrm.h 1.70 vs edited ===== --- 1.70/include/net/xfrm.h 2004-08-25 20:48:11 +10:00 +++ edited/include/net/xfrm.h 2004-09-09 22:05:12 +10:00 @@ -896,4 +896,17 @@ extern void skb_icv_walk(const struct sk_buff *skb, struct crypto_tfm *tfm, int offset, int len, icv_update_fn_t icv_update); +static inline int xfrm_addr_cmp(xfrm_address_t *a, xfrm_address_t *b, + int family) +{ + switch (family) { + default: + case AF_INET: + return a->a4 - b->a4; + case AF_INET6: + return ipv6_addr_cmp((struct in6_addr *)a, + (struct in6_addr *)b); + } +} + #endif /* _NET_XFRM_H */ ===== net/key/af_key.c 1.68 vs edited ===== --- 1.68/net/key/af_key.c 2004-08-25 20:48:13 +10:00 +++ edited/net/key/af_key.c 2004-09-09 22:05:05 +10:00 @@ -1156,7 +1156,16 @@ break; #endif } - if (xdaddr) + + if (hdr->sadb_msg_seq) { + x = xfrm_find_acq_byseq(hdr->sadb_msg_seq); + if (x && xfrm_addr_cmp(&x->id.daddr, xdaddr, family)) { + xfrm_state_put(x); + x = NULL; + } + } + + if (!x) x = xfrm_find_acq(mode, reqid, proto, xdaddr, xsaddr, 1, family); if (x == NULL) ===== net/xfrm/xfrm_state.c 1.51 vs edited ===== --- 1.51/net/xfrm/xfrm_state.c 2004-08-02 07:15:03 +10:00 +++ edited/net/xfrm/xfrm_state.c 2004-09-09 22:05:05 +10:00 @@ -387,13 +387,17 @@ spin_unlock_bh(&xfrm_state_lock); } +static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq); + int xfrm_state_add(struct xfrm_state *x) { struct xfrm_state_afinfo *afinfo; struct xfrm_state *x1; + int family; int err; - afinfo = xfrm_state_get_afinfo(x->props.family); + family = x->props.family; + afinfo = xfrm_state_get_afinfo(family); if (unlikely(afinfo == NULL)) return -EAFNOSUPPORT; @@ -407,9 +411,18 @@ goto out; } - x1 = afinfo->find_acq( - x->props.mode, x->props.reqid, x->id.proto, - &x->id.daddr, &x->props.saddr, 0); + if (x->km.seq) { + x1 = __xfrm_find_acq_byseq(x->km.seq); + if (x1 && xfrm_addr_cmp(&x1->id.daddr, &x->id.daddr, family)) { + xfrm_state_put(x1); + x1 = NULL; + } + } + + if (!x1) + x1 = afinfo->find_acq( + x->props.mode, x->props.reqid, x->id.proto, + &x->id.daddr, &x->props.saddr, 0); __xfrm_state_insert(x); err = 0; @@ -570,12 +583,11 @@ /* Silly enough, but I'm lazy to build resolution list */ -struct xfrm_state * xfrm_find_acq_byseq(u32 seq) +static struct xfrm_state *__xfrm_find_acq_byseq(u32 seq) { int i; struct xfrm_state *x; - spin_lock_bh(&xfrm_state_lock); for (i = 0; i < XFRM_DST_HSIZE; i++) { list_for_each_entry(x, xfrm_state_bydst+i, bydst) { if (x->km.seq == seq) { @@ -585,8 +597,17 @@ } } } - spin_unlock_bh(&xfrm_state_lock); return NULL; +} + +struct xfrm_state *xfrm_find_acq_byseq(u32 seq) +{ + struct xfrm_state *x; + + spin_lock_bh(&xfrm_state_lock); + x = __xfrm_find_acq_byseq(seq); + spin_unlock_bh(&xfrm_state_lock); + return x; } u32 xfrm_get_acqseq(void) ===== net/xfrm/xfrm_user.c 1.50 vs edited ===== --- 1.50/net/xfrm/xfrm_user.c 2004-08-25 20:48:13 +10:00 +++ edited/net/xfrm/xfrm_user.c 2004-09-09 22:05:05 +10:00 @@ -470,16 +470,32 @@ struct xfrm_state *x; struct xfrm_userspi_info *p; struct sk_buff *resp_skb; + xfrm_address_t *daddr; + int family; int err; p = NLMSG_DATA(nlh); err = verify_userspi_info(p); if (err) goto out_noput; - x = xfrm_find_acq(p->info.mode, p->info.reqid, p->info.id.proto, - &p->info.id.daddr, - &p->info.saddr, 1, - p->info.family); + + family = p->info.family; + daddr = &p->info.id.daddr; + + x = NULL; + if (p->info.seq) { + x = xfrm_find_acq_byseq(p->info.seq); + if (x && xfrm_addr_cmp(&x->id.daddr, daddr, family)) { + xfrm_state_put(x); + x = NULL; + } + } + + if (!x) + x = xfrm_find_acq(p->info.mode, p->info.reqid, + p->info.id.proto, daddr, + &p->info.saddr, 1, + family); err = -ENOENT; if (x == NULL) goto out_noput; --yrj/dFKFPuw6o+aM-- From herbert@gondor.apana.org.au Thu Sep 9 05:23:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 05:23:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89CNYm9016557 for ; Thu, 9 Sep 2004 05:23:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5NwF-0004T4-00; Thu, 09 Sep 2004 22:22:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5NwB-0001bG-00; Thu, 09 Sep 2004 22:22:03 +1000 Date: Thu, 9 Sep 2004 22:22:02 +1000 To: kuznet@ms2.inr.ac.ru, davem@davemloft.net, jmorris@redhat.com, netdev@oss.sgi.com Subject: [IPCOMP] Use per-cpu buffers Message-ID: <20040909122202.GA3170@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 14351 Lines: 665 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: Here is a really ugly patch to get IPCOMP to use per-cpu buffers. But I'm afraid it really is necessary. At 300K per SA IPCOMP isn't very affordable at all. With per-cpu buffers this goes down to 300K per CPU. I've also turned the kmalloc'ed scratch space into a vmalloc'ed one since people may be loading the ipcomp module after the system has been running for a while. On an i386 machine with 64M of RAM or less this can often cause a 64K kmalloc to fail. The crypto deflate buffer space are vmalloc'ed already as well. Part of the ugliness comes from the lazy allocation. However we need the lazy initialisation since new IPCOMP algorithms may be introduced in future. That means we can't allocate space for every single IPCOMP algorithm at module-load time. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipcomp.patch" ===== include/net/ipcomp.h 1.1 vs edited ===== --- 1.1/include/net/ipcomp.h 2003-05-17 07:02:27 +10:00 +++ edited/include/net/ipcomp.h 2004-09-09 21:28:02 +10:00 @@ -5,8 +5,7 @@ struct ipcomp_data { u16 threshold; - u8 *scratch; - struct crypto_tfm *tfm; + struct crypto_tfm **tfms; }; #endif ===== net/ipv4/ipcomp.c 1.33 vs edited ===== --- 1.33/net/ipv4/ipcomp.c 2004-08-25 20:48:12 +10:00 +++ edited/net/ipv4/ipcomp.c 2004-09-09 21:32:44 +10:00 @@ -16,25 +16,48 @@ #include #include #include +#include #include #include +#include +#include +#include +#include +#include #include #include #include #include +struct ipcomp_tfms { + struct list_head list; + struct crypto_tfm **tfms; + int users; +}; + +static DECLARE_MUTEX(ipcomp_resource_sem); +static void **ipcomp_scratches; +static int ipcomp_scratch_users; +static LIST_HEAD(ipcomp_tfms_list); + static int ipcomp_decompress(struct xfrm_state *x, struct sk_buff *skb) { int err, plen, dlen; struct iphdr *iph; struct ipcomp_data *ipcd = x->data; - u8 *start, *scratch = ipcd->scratch; + u8 *start, *scratch; + struct crypto_tfm *tfm; + int cpu; plen = skb->len; dlen = IPCOMP_SCRATCH_SIZE; start = skb->data; - err = crypto_comp_decompress(ipcd->tfm, start, plen, scratch, &dlen); + cpu = get_cpu(); + scratch = *per_cpu_ptr(ipcomp_scratches, cpu); + tfm = *per_cpu_ptr(ipcd->tfms, cpu); + + err = crypto_comp_decompress(tfm, start, plen, scratch, &dlen); if (err) goto out; @@ -52,6 +75,7 @@ iph = skb->nh.iph; iph->tot_len = htons(dlen + iph->ihl * 4); out: + put_cpu(); return err; } @@ -97,14 +121,20 @@ int err, plen, dlen, ihlen; struct iphdr *iph = skb->nh.iph; struct ipcomp_data *ipcd = x->data; - u8 *start, *scratch = ipcd->scratch; + u8 *start, *scratch; + struct crypto_tfm *tfm; + int cpu; ihlen = iph->ihl * 4; plen = skb->len - ihlen; dlen = IPCOMP_SCRATCH_SIZE; start = skb->data + ihlen; - err = crypto_comp_compress(ipcd->tfm, start, plen, scratch, &dlen); + cpu = get_cpu(); + scratch = *per_cpu_ptr(ipcomp_scratches, cpu); + tfm = *per_cpu_ptr(ipcd->tfms, cpu); + + err = crypto_comp_compress(tfm, start, plen, scratch, &dlen); if (err) goto out; @@ -114,9 +144,13 @@ } memcpy(start + sizeof(struct ip_comp_hdr), scratch, dlen); + put_cpu(); + pskb_trim(skb, ihlen + dlen + sizeof(struct ip_comp_hdr)); + return 0; out: + put_cpu(); return err; } @@ -260,12 +294,132 @@ return err; } +static void ipcomp_free_scratches(void) +{ + int i; + void **scratches; + + if (--ipcomp_scratch_users) + return; + + scratches = ipcomp_scratches; + if (!scratches) + return; + + for_each_cpu(i) { + void *scratch = *per_cpu_ptr(scratches, i); + if (scratch) + vfree(scratch); + } + + free_percpu(scratches); +} + +static void **ipcomp_alloc_scratches(void) +{ + int i; + void **scratches; + + if (ipcomp_scratch_users++) + return ipcomp_scratches; + + scratches = alloc_percpu(void *); + if (!scratches) + return NULL; + + ipcomp_scratches = scratches; + + for_each_cpu(i) { + void *scratch = vmalloc(IPCOMP_SCRATCH_SIZE); + if (!scratch) + return NULL; + *per_cpu_ptr(scratches, i) = scratch; + } + + return scratches; +} + +static void ipcomp_free_tfms(struct crypto_tfm **tfms) +{ + struct ipcomp_tfms *pos; + int cpu; + + list_for_each_entry(pos, &ipcomp_tfms_list, list) { + if (pos->tfms == tfms) + break; + } + + BUG_TRAP(pos); + + if (--pos->users) + return; + + list_del(&pos->list); + kfree(pos); + + if (!tfms) + return; + + for_each_cpu(cpu) { + struct crypto_tfm *tfm = *per_cpu_ptr(tfms, cpu); + if (tfm) + crypto_free_tfm(tfm); + } + free_percpu(tfms); +} + +static struct crypto_tfm **ipcomp_alloc_tfms(const char *alg_name) +{ + struct ipcomp_tfms *pos; + struct crypto_tfm **tfms; + int cpu; + + /* This can be any valid CPU ID so we don't need locking. */ + cpu = smp_processor_id(); + + list_for_each_entry(pos, &ipcomp_tfms_list, list) { + struct crypto_tfm *tfm; + + tfms = pos->tfms; + tfm = *per_cpu_ptr(tfms, cpu); + + if (!strcmp(crypto_tfm_alg_name(tfm), alg_name)) { + pos->users++; + return tfms; + } + } + + pos = kmalloc(sizeof(*pos), GFP_KERNEL); + if (!pos) + return NULL; + + pos->users = 1; + INIT_LIST_HEAD(&pos->list); + list_add(&pos->list, &ipcomp_tfms_list); + + pos->tfms = tfms = alloc_percpu(struct crypto_tfm *); + if (!tfms) + goto error; + + for_each_cpu(cpu) { + struct crypto_tfm *tfm = crypto_alloc_tfm(alg_name, 0); + if (!tfm) + goto error; + *per_cpu_ptr(tfms, cpu) = tfm; + } + + return tfms; + +error: + ipcomp_free_tfms(tfms); + return NULL; +} + static void ipcomp_free_data(struct ipcomp_data *ipcd) { - if (ipcd->tfm) - crypto_free_tfm(ipcd->tfm); - if (ipcd->scratch) - kfree(ipcd->scratch); + if (ipcd->tfms) + ipcomp_free_tfms(ipcd->tfms); + ipcomp_free_scratches(); } static void ipcomp_destroy(struct xfrm_state *x) @@ -274,7 +428,9 @@ if (!ipcd) return; xfrm_state_delete_tunnel(x); + down(&ipcomp_resource_sem); ipcomp_free_data(ipcd); + up(&ipcomp_resource_sem); kfree(ipcd); } @@ -294,25 +450,26 @@ err = -ENOMEM; ipcd = kmalloc(sizeof(*ipcd), GFP_KERNEL); if (!ipcd) - goto error; + goto out; memset(ipcd, 0, sizeof(*ipcd)); x->props.header_len = 0; if (x->props.mode) x->props.header_len += sizeof(struct iphdr); - ipcd->scratch = kmalloc(IPCOMP_SCRATCH_SIZE, GFP_KERNEL); - if (!ipcd->scratch) + down(&ipcomp_resource_sem); + if (!ipcomp_alloc_scratches()) goto error; - - ipcd->tfm = crypto_alloc_tfm(x->calg->alg_name, 0); - if (!ipcd->tfm) + + ipcd->tfms = ipcomp_alloc_tfms(x->calg->alg_name); + if (!ipcd->tfms) goto error; + up(&ipcomp_resource_sem); if (x->props.mode) { err = ipcomp_tunnel_attach(x); if (err) - goto error; + goto error_tunnel; } calg_desc = xfrm_calg_get_byname(x->calg->alg_name); @@ -323,11 +480,12 @@ out: return err; +error_tunnel: + down(&ipcomp_resource_sem); error: - if (ipcd) { - ipcomp_free_data(ipcd); - kfree(ipcd); - } + ipcomp_free_data(ipcd); + up(&ipcomp_resource_sem); + kfree(ipcd); goto out; } ===== net/ipv6/ipcomp6.c 1.24 vs edited ===== --- 1.24/net/ipv6/ipcomp6.c 2004-08-25 20:48:12 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-09-09 21:36:23 +10:00 @@ -36,14 +36,31 @@ #include #include #include +#include #include #include #include +#include +#include +#include +#include +#include #include #include #include #include +struct ipcomp6_tfms { + struct list_head list; + struct crypto_tfm **tfms; + int users; +}; + +static DECLARE_MUTEX(ipcomp6_resource_sem); +static void **ipcomp6_scratches; +static int ipcomp6_scratch_users; +static LIST_HEAD(ipcomp6_tfms_list); + static int ipcomp6_input(struct xfrm_state *x, struct xfrm_decap_state *decap, struct sk_buff *skb) { int err = 0; @@ -53,7 +70,9 @@ struct ipv6hdr *iph; int plen, dlen; struct ipcomp_data *ipcd = x->data; - u8 *start, *scratch = ipcd->scratch; + u8 *start, *scratch; + struct crypto_tfm *tfm; + int cpu; if ((skb_is_nonlinear(skb) || skb_cloned(skb)) && skb_linearize(skb, GFP_ATOMIC) != 0) { @@ -82,20 +101,24 @@ dlen = IPCOMP_SCRATCH_SIZE; start = skb->data; - err = crypto_comp_decompress(ipcd->tfm, start, plen, scratch, &dlen); + cpu = get_cpu(); + scratch = *per_cpu_ptr(ipcomp6_scratches, cpu); + tfm = *per_cpu_ptr(ipcd->tfms, cpu); + + err = crypto_comp_decompress(tfm, start, plen, scratch, &dlen); if (err) { err = -EINVAL; - goto out; + goto out_put_cpu; } if (dlen < (plen + sizeof(struct ipv6_comp_hdr))) { err = -EINVAL; - goto out; + goto out_put_cpu; } err = pskb_expand_head(skb, 0, dlen - plen, GFP_ATOMIC); if (err) { - goto out; + goto out_put_cpu; } skb_put(skb, dlen - plen); @@ -104,6 +127,8 @@ iph = skb->nh.ipv6h; iph->payload_len = htons(skb->len); +out_put_cpu: + put_cpu(); out: if (tmp_hdr) kfree(tmp_hdr); @@ -124,7 +149,9 @@ struct ipv6_comp_hdr *ipch; struct ipcomp_data *ipcd = x->data; int plen, dlen; - u8 *start, *scratch = ipcd->scratch; + u8 *start, *scratch; + struct crypto_tfm *tfm; + int cpu; hdr_len = skb->h.raw - skb->data; @@ -144,14 +171,21 @@ dlen = IPCOMP_SCRATCH_SIZE; start = skb->h.raw; - err = crypto_comp_compress(ipcd->tfm, start, plen, scratch, &dlen); + cpu = get_cpu(); + scratch = *per_cpu_ptr(ipcomp6_scratches, cpu); + tfm = *per_cpu_ptr(ipcd->tfms, cpu); + + err = crypto_comp_compress(tfm, start, plen, scratch, &dlen); if (err) { + put_cpu(); goto error; } if ((dlen + sizeof(struct ipv6_comp_hdr)) >= plen) { + put_cpu(); goto out_ok; } memcpy(start + sizeof(struct ip_comp_hdr), scratch, dlen); + put_cpu(); pskb_trim(skb, hdr_len + dlen + sizeof(struct ip_comp_hdr)); /* insert ipcomp header and replace datagram */ @@ -254,12 +288,132 @@ return err; } +static void ipcomp6_free_scratches(void) +{ + int i; + void **scratches; + + if (--ipcomp6_scratch_users) + return; + + scratches = ipcomp6_scratches; + if (!scratches) + return; + + for_each_cpu(i) { + void *scratch = *per_cpu_ptr(scratches, i); + if (scratch) + vfree(scratch); + } + + free_percpu(scratches); +} + +static void **ipcomp6_alloc_scratches(void) +{ + int i; + void **scratches; + + if (ipcomp6_scratch_users++) + return ipcomp6_scratches; + + scratches = alloc_percpu(void *); + if (!scratches) + return NULL; + + ipcomp6_scratches = scratches; + + for_each_cpu(i) { + void *scratch = vmalloc(IPCOMP_SCRATCH_SIZE); + if (!scratch) + return NULL; + *per_cpu_ptr(scratches, i) = scratch; + } + + return scratches; +} + +static void ipcomp6_free_tfms(struct crypto_tfm **tfms) +{ + struct ipcomp6_tfms *pos; + int cpu; + + list_for_each_entry(pos, &ipcomp6_tfms_list, list) { + if (pos->tfms == tfms) + break; + } + + BUG_TRAP(pos); + + if (--pos->users) + return; + + list_del(&pos->list); + kfree(pos); + + if (!tfms) + return; + + for_each_cpu(cpu) { + struct crypto_tfm *tfm = *per_cpu_ptr(tfms, cpu); + if (tfm) + crypto_free_tfm(tfm); + } + free_percpu(tfms); +} + +static struct crypto_tfm **ipcomp6_alloc_tfms(const char *alg_name) +{ + struct ipcomp6_tfms *pos; + struct crypto_tfm **tfms; + int cpu; + + /* This can be any valid CPU ID so we don't need locking. */ + cpu = smp_processor_id(); + + list_for_each_entry(pos, &ipcomp6_tfms_list, list) { + struct crypto_tfm *tfm; + + tfms = pos->tfms; + tfm = *per_cpu_ptr(tfms, cpu); + + if (!strcmp(crypto_tfm_alg_name(tfm), alg_name)) { + pos->users++; + return tfms; + } + } + + pos = kmalloc(sizeof(*pos), GFP_KERNEL); + if (!pos) + return NULL; + + pos->users = 1; + INIT_LIST_HEAD(&pos->list); + list_add(&pos->list, &ipcomp6_tfms_list); + + pos->tfms = tfms = alloc_percpu(struct crypto_tfm *); + if (!tfms) + goto error; + + for_each_cpu(cpu) { + struct crypto_tfm *tfm = crypto_alloc_tfm(alg_name, 0); + if (!tfm) + goto error; + *per_cpu_ptr(tfms, cpu) = tfm; + } + + return tfms; + +error: + ipcomp6_free_tfms(tfms); + return NULL; +} + static void ipcomp6_free_data(struct ipcomp_data *ipcd) { - if (ipcd->tfm) - crypto_free_tfm(ipcd->tfm); - if (ipcd->scratch) - kfree(ipcd->scratch); + if (ipcd->tfms) + ipcomp6_free_tfms(ipcd->tfms); + ipcomp6_free_scratches(); } static void ipcomp6_destroy(struct xfrm_state *x) @@ -268,7 +422,9 @@ if (!ipcd) return; xfrm_state_delete_tunnel(x); + down(&ipcomp6_resource_sem); ipcomp6_free_data(ipcd); + up(&ipcomp6_resource_sem); kfree(ipcd); xfrm6_tunnel_free_spi((xfrm_address_t *)&x->props.saddr); @@ -290,25 +446,26 @@ err = -ENOMEM; ipcd = kmalloc(sizeof(*ipcd), GFP_KERNEL); if (!ipcd) - goto error; + goto out; memset(ipcd, 0, sizeof(*ipcd)); x->props.header_len = 0; if (x->props.mode) x->props.header_len += sizeof(struct ipv6hdr); - ipcd->scratch = kmalloc(IPCOMP_SCRATCH_SIZE, GFP_KERNEL); - if (!ipcd->scratch) + down(&ipcomp6_resource_sem); + if (!ipcomp6_alloc_scratches()) goto error; - ipcd->tfm = crypto_alloc_tfm(x->calg->alg_name, 0); - if (!ipcd->tfm) + ipcd->tfms = ipcomp6_alloc_tfms(x->calg->alg_name); + if (!ipcd->tfms) goto error; + up(&ipcomp6_resource_sem); if (x->props.mode) { err = ipcomp6_tunnel_attach(x); if (err) - goto error; + goto error_tunnel; } calg_desc = xfrm_calg_get_byname(x->calg->alg_name); @@ -318,11 +475,12 @@ err = 0; out: return err; +error_tunnel: + down(&ipcomp6_resource_sem); error: - if (ipcd) { - ipcomp6_free_data(ipcd); - kfree(ipcd); - } + ipcomp6_free_data(ipcd); + up(&ipcomp6_resource_sem); + kfree(ipcd); goto out; } --ew6BAiZeqk4r7MaW-- From sriharivijayaraghavan@yahoo.com.au Thu Sep 9 07:02:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 07:02:19 -0700 (PDT) Received: from smtp209.mail.sc5.yahoo.com (smtp209.mail.sc5.yahoo.com [216.136.130.117]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i89E2B2P025658 for ; Thu, 9 Sep 2004 07:02:12 -0700 Received: from unknown (HELO ?192.168.0.2?) (sriharivijayaraghavan@150.101.158.114 with plain) by smtp209.mail.sc5.yahoo.com with SMTP; 9 Sep 2004 14:01:59 -0000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: r8169 - panic and a fix Date: Fri, 10 Sep 2004 00:08:06 +1000 User-Agent: KMail/1.6.2 References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <20040908190603.GA19634@electric-eye.fr.zoreil.com> In-Reply-To: <20040908190603.GA19634@electric-eye.fr.zoreil.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_GPGQBRhEbDUVND1" Message-Id: <200409100008.06541.sriharivijayaraghavan@yahoo.com.au> X-archive-position: 8557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sriharivijayaraghavan@yahoo.com.au Precedence: bulk X-list: netdev Content-Length: 40583 Lines: 563 --Boundary-00=_GPGQBRhEbDUVND1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, 9 Sep 2004 05:06 am, you wrote: > Srihari Vijayaraghavan : > > As of 2.6.9-rc1-bk11, r8169 does not work on my Athlon 64 machine. It > > results in a panic :-(. > > [skb_over_panic] > > Can you: > - make drivers/net/r8169.s and send me the r8169.s file Please refer to the attachment (r8169.s.bz2). > - objdump -S drivers/net/r8169.o and send me output Please refer to the attachment (objdump-r8169.bz2). > - Re-apply the patch which test size(dma_arrd_t), apply the patch below > and report the (possibly oopsy) result ? I am doing this task, and will post the results a little later. > > --- drivers/net/r8169.c 2004-09-08 20:15:01.000000000 +0200 > +++ dirvers/net/r8169.c 2004-09-08 20:49:58.000000000 +0200 > @@ -52,6 +52,7 @@ VERSION 1.2 <2002/11/30> Thanks. Hari. --Boundary-00=_GPGQBRhEbDUVND1 Content-Type: application/x-bzip2; name="objdump-r8169.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="objdump-r8169.bz2" QlpoOTFBWSZTWS6w6/8AG3TfgH18zn//9QQAAAC////wYG1eD4Q+sx9uZ9VSAoiUA+tJUil7x3zu x1l2xFQRWuzyqH2OffIjgT7H2NK1lF3mHNZFRK+9rbgBDsfTkp8HovmjQ9rA+nyfPfXHRvYdfda9 3Abu7Z88Abke9a9883r5LAnH3t9bW0utynfb6FAqhZgbqZvbbd2IHkGPWoDkHuPo+vvd99Pkp8g3 tkByGNYUYhmsAxHd0p2fd69lp82+LvM8xYPIIAAAKAAD6ADAV33zU7Q8Rngnq4DxDnnh68p3s8Qx 9fPXhpEHz1HdoenDu5jBgcI4eAeykimFMyVa1CfAHVDbhpogAAiSJNqaaZIg9AIZDIBqegCApJBR 6aQAxA0AAGgaeShETRBGU9UAND1NAAAABJ6pRKSZR6aQNGnqAAAyYhoABCkkEwmgI0BNJtEaj1Hq DQDRkESIQTQIQIFINNAAGgNA6KAiHt+wYgqi4SHylEwJEBA1IUgNAgYECOQKUgqODkZgTVKMMCgG CkgqnT8lVTRI0AUAsQArQIKkQCUAkSqgxKC0KNIqlAoM7cm9K6IAEk70U3Aq24Yl3cl4xgxGY8kk sNk2iomrdMgQjaKt2NooF+gDY2A0jDMaK1RdyqwXgoqG8brObbKiw2dkFE0psG2wb6FADKbk2Ny7 9k1LErQUBEIFCUBQjwVslKpQKnY407MAVb7G1EpjqDMNGhWHaEbMHJClbMYkyAwsIIks22NsNJrM 3K6HTUe8+a9r41JXxZfGqvm3TtU0rbFsMHJKDRIQa1g44OlTA0TdiNhTYVAsoirV0tpd2DdXY3GD lwrQYBpaKRqFQSgmG4tgFurrzty08lvFedWVvN6GTJipVjzymYt13I7uJ1a17s3rM1IYg2io7e53 b1grrCwLAZcDmSZkmtwLpLN2OuJN0wJiWIOlByGVsQbUGwtYlCpdQMmohMMQ06BMkDbY0MpVuMDN +sNIDCBsGILi5oBKKDg/X8/3v/IIAAgwxZ+11qf1oOUAADexpGxiQI0ssVjFn+LZU/1D8v5O/0nr fnN9dePBaISSYWHiWscOWcZI1rShCFRZFJZQiAcV7d5swIE8a5zO+7YkrbFY93vxqkNeI5LuTAqI xf6nnvOWHB/YkPpfIZVnQhnXqO7EK6aXbRR0HuCx03djGcuWxKygNsDT51fMdI7AkVYI2nt8KlgN KCR/ioQKgQ1UqKm21VVmjTqXOk78de09E9c6nc82xhPKx16jHwcV2XvPBgQJ41zPZfMNa9pQSGdB KhCVBZQW1DBxT15Z1jZxuQ4rFzpdgqrqURIahZF5k63RsOM0LIK7067KlCpJpExV51WsaI3Q0cfO STKIS6O6lUVVVUKbQlXRWKBaxJFbegRu0wCcG2tkR4ShZBIvfJEizdqCcnQKEFuhGK1RWpLXesbI JBI3Gq1hUtsrtEgW7IiKwRECZV3ZSCz1RXOM/PDkyKBNkHo0TsEh0XWOEFJoEOZBIL37jM+CIaI4 qrFY6vfNUhp3CwEcreJzIN63zdYo4JwSOsHiaFnqEbsZhn0Dw4khDjhRlY9CKtOykFremZHUmqVV CIgR1imUgs2YOdb5PUVngSbThATXRsgtswZNh7o9VVT1dHOcTWs4qQxgwWFSCRpBVe87IPA5NyrO fpv5c3Dc4VjVpUngtiahKDFJSNi+zD17/Hx7fGfBCQSPNyBIq8kavGSC2FJOrTHSeuhXoShRBdXc IhKBJBBKBUlGe1Odb5zmOEEgkdiZ3PAX0/B8UnhlhF1OtoFnLlbll55DXZMy2cZ0NvE0CU+tbbyK FIYtzhKohK0S0A8HbYtARFxiaoNBoVEJIEBUJIaVOdb5GcZOCcEjtWB7k7pwmFSErDnBOK+o8ht8 QcEiKm8IUnnXa8EkOCzOXZGZJaDCBPhW8PFvO10WpECOUHEUkKgZAimxBBeYpL0Nhg4OZAGMsK0r kshCprSqwREkkmkN5zeLOCQSNS3ChJvATZOpxRxWovfymKlTIogsrZTMlEvVjXh8zfU9eTtY2Q6O h/uVVT/0qUKE/ZWUUSDEQVQpUq5gZUrbORsgkalMWRVs2mG8OIeDWLgV06fDkEjTNbyLtng1iSCQ SKoRgmGQm9ZsgQJvc3h57ttsCBAstoiIUhkmcMcTUPEEIrJGHOCcEiGjEFO7twTgkDQL7SFexkjL Z0QSSawJIBKs0CTMORzOAAAHV5nRBpt5zmcMDOtTz2PedGBgYd7kOs7slN8TnbZ2Q3vpkQAAACSW k06KXSYgQQSK7nU5BGl1gDGlOwVMNFYrFjNS+Z7Bqb0xx1NBdQ9GwJZymYMEYqoS1L51WcZOCQSN zvBOLq96vcyzlmZVCIiogLtU1tc9VnFxJzhDlJR1QkpLs0Ne5bGArGJegtvpsKefnroo6jGDB2Wz vWpdGtOoagqixe22O34nwQflvlQYrAAZAhAj2WXpAGUAHsnvO7vY84gTRsaony7hA2cdZw6E0R1b okgACoAAc65GE1tdqqqqqqqsFhipropvvOuS6UOJ1z17de3E6nm+LCXRVQkuYlBd4yQ0VSTMYk4J EsGXDEMwa3EcYOc4cb7E1Zdm+G/2UH9tyqZP3kLBUXHMURQBxTIfDkYqvXX7eXqcN+EAj/eaxXID 0ndKbEgn7SG4jcSm3+hBj/ngYhxgoN/N6umi/6ijN1nyx3y6NIMCBkCBDZFY+C1WWyMAh3Ou9RFz 37ftvN8UXyixRaZqNtfTq1rVreC0CWA0Y2REEe1CHUFbFFQMv/OBogGSDQOQkQMwAYSZCeQA+s0D 8K3ZGg2yRii2Ki1y10tf+VUl419933fw/PL5ZZnoAAD/meTLX0UcXoCAOvi88uXACDBzNKzJpw0y UjQ3vWjIkwcu6vQAAAB8966ePI9hMJsCaDAaBznudOJvDfrMJgswwcmzKAMN8O+MlTdbEGASbrTf FeLyNnjHeOSi97XV7qlaLgZtWhC3NEySsSCQcwMhDEDJNwEOMMsjuqUmTShtiAYiRq2+d34fh5eb mrhV4rxp3aoTG28mtuiZJJEJEhNqTbGZUaay0VQairltQa0ZgTqWiloNVZr2EA8oQ/pZCq0UChSp vhHJQKRVyFMhEoWhFpyFLMQCgRKQotrS7tWua1RVRWqK3IoEyADUhkApqFTJUDJFMW1Y2prhm8lx XOc5gdzju7vrtr25r9SroSFu+d4d26WZQE7q3QxFfRXnmuy7uyQgc69dFdxu7u/W7pGPjblZLWvW 21XSq0YsYsUUKgEQuSIZADEArkgmStApSjSmoHJApU1AZAlIoH0lEex7T42euOeZrYTZWJSmmmpI hYjbSNYpjWvPPr+e75SPy37/j8dyi6kHehmvPYMKojU4zBAiwGIwGAlUpKRpf2GcYxrffAauY+/5 /XMyKqvdFGizRv5hzRMjvhDtpPcj8shma/F37nb10EM+crMl4/V+d3tVIhWLGpYSrtoIMCXRRQNB oh7mZ0Y4M7u+wcbyi7NSuKIkImbEu1CQA44GZBrWruLCNTEJA/g3nI3hsbG12N1t5nCORTCVJdxu hjApgwIqc4xkDgoCBIHMi6xUgT1tsY7ZxsAcu72P5wCWHrz3SjGqXAGjSeR32h1mHMHAVXfoETrD 4xAJ5hMIBdwuFvORe9EkOdbAdkrC+O+63nsVfnmyvN65dxxrqIFw64YRtwQuOMMhQc2SwpgLGG5Q u3iFWmHbnjb0njHHX1ZZhJ3zwVQy7GZ0OmBWQnam8QGevKjbTRTvJ3Xh2c3I0j93nfX3FbafTG60 OIr795257y+4eSu91ENTZt4ka1vBXvvac1y47Wt5WzMCjkEA64hQZUIq0YYFBSlJiVsIAMoidhPA HlA5V0J5A6B56njx4AyHPJWYAmRxqrUDoryZXIdk8HkWkFErdBQ3UN0SKeFDuiZUgqYf5f4n5gXd 1bGNMxciYMMuVJKxWYAZkciKf95JZcgSaY3DLJaRMtiSslIyXxPK651et0r3Jce9eKuuusayHDzD YQfxQJlYYQgZQmRIDeO3sY5KSQ4y/gKjxhSZVT6lWl9y6x96223wDUYs0FQAa87b6N41rm0axtFc 2kIoqjYxWRCFtrb6swoZIW2GQJiRjIlCalPmkhssgNapJX+jI+KB7FEie6FGkyVoiL1Dx0r7G4xU dpA3SJqUKvzk/X61721+jCFRkBcxUkQE2xoloo7ZKBA2Iv6IL+eOeuvXbR+mc9HN0UL+pjhA8vOe Q0IHRE1BHYKVpF8Q1EN4mWdyW9jwX1AN4aSqIxIciU1C683iX3odooagm3NeYSG4yoDcmaZVEmYg ZIr26cmoY2gDUEzEHMQC2LDcYBhBkIUPUhNzdydeRpmDldBgjMEDCN8YQ0ATcnWaEhIsjCHAt4XO pXAkkkkcyaz54pEwMBlCAmiFBMePO5vwTtvwY1zjmZ5thaVdtpLAeIoBqBCG49s7ncTIeXh5W3zP B0HjsY8oPJsYyERycBx0VZtmgqg1lRTkJ55zo2rh8XJhaHMaxilwCiYJKGd2RSgrESBoHAKuGTWD jQB9tNM+CuA4OEMEkWcwgzTnjYxFJtXHbVm2qAYgIlGi2AVN1rMDFvYUb5jQt1zgJl9UMMvdzMSn kqeCJBp0KoQZROqjRoDmA+DY1CEYTG/GxnUQNQWO+O9lTAZknmu5tXVwNh8JlGAzciASeFOnGwBI Q4kTgi04B3GOiazcC/BYXGGIqGHGjwfsYHTh8WXIUkhvAHqeC6V6ks7dHRiBejjYToXigDyHXKbU aIDk5G05RCWcclp0Ffu8BTA98FPEjllSwCirCwteGjeChQQQQxUkhgpOkxPseENrvxsTdKHIOCBw PlrLOAqB8Q0gdlTM9Zs8XrvtvsBA2MagVB+PaSEJEISQIpA+mDQwy5VPj471fxIRPfXc9fGa85b7 AEAn6Mj7J4kAdRl/acYkch5nGvJLoKFghHerbMxJL5h813xvsBvtjtv2dzYM3Ckne6tYodQTiT0J 1VnMM96MzncKOCg6rjDg7kaCUzezEzDQUGMmiYxopwYdOxdyPzypTY+TOCRzOMAaIQxppR3HMiQo 4R8n2t9hUmNRw7GGwbwggjvhDISJJYlKmtTZSpqKiopTM1ZMxmZtFr4rprKbZKgAg4BOA0GQ7Qad HDcwowE9YAbkNciYTFkKcQgS9BOz6NIyIAnQ2l8/PoZchUrksgkxw7Pd4wlEUccQA1iO3AoAvl2y XwMDxEHDbPlk/WgjBEXudS3wOj92mNW6Z8EAbAwo7xOMkOTrnfCVzueoTGCy+iGbA12pzohxCbUG K6wYv1y7GvR1vvxwQu6tLbZpLDEkJdBx3vt7Xq3vvXiHnW4Rd468BtWDGDCR6NtJ32mdZyV60S93 aGxmOJZdLGDXUwMTEADVAKtBBHAjBgUCYqLAngvz2g8HERnIjA3Acd4w+qpWrwpEDZ6O3ABR73tO PMrincrst888ZxjXZAnOjXmVjKtVKErEoDntvwVwVjooo0gbBwkYyUrmCYgGKzwR1dmxIMPHspLH 34x324b27djqMJIe+x5JYSTjv0GofCAQCDglHWR2hwsSiO3Gbno9Z1v0YPHbFh4PO+HlgRIxhGd6 dHHKC7EDgCZ3oBQXD4444GbYzoKg4hnGHwEBG7KYBiRLrHJCKQ0/L1hGaeEmTjAU6IBVan5EjCHU t0YbIXGfHBxCMucyJDiY2KCOyKkQkFkAa44yVJCXThEM0WNedYCzVc1RgKlVXPV0R7EDEHjv2Qvj zby9ru83eXch4gKFNW4xWGd4YNMB7rAZgcGkgobVN8+N9u/btGdSGoJhj5xRIbGK7PEoWxIkMIEq wk0bjGbJZzy6dZLAyvJCWrGFlIOzbEGsNEqRp66DGWANDnLaVgtgXUEzS0txI11zgTaJIg8LdnLS vBCaCKaJYnRsbp0akdEBlhPF0ZsmiSbXM3pnjmPC6cDLCVK47ELDXessQ1sZtkIRSBAkxvRZJFUg 9xnYICHSlsFwQ8wA7woxEHAv5DtiRCMPQkfI4wiRkq1oVZAn6qL4gqAOm7VQMQoqw3w8+u6YKNiL l8DeGa2SSEFH60mPHDEOva+jmBggiePyXAS+SiJt9wo1aPmV49bHBPMEHo7Bpe7zGabFO5kszhS8 uKwyO6dlB0ioTGUpfmcJgbxFiAcTsenTobGlHQQCDiM9JXPigfBxZA50Jgje1zXCLhkBzb0KocMj rB5TfGWspjG6QAF32yd3A685NreDgb2iZTFEDauGbHulMAza2CH6OlgxOPbQALw69j2ExBazgbXf A5FUwkpGPBVAXBI0OIFmFWECfSqb/GgW5mK5zjFTisgGCvO5zvvq9nFHjMDeyk4m760Y8hanHAbx TA4EDdQJxPenjZM4iFdcVW9OTYNuMa1sWmxsZDfFlkVDW+zlnFeOd8mEnJuS04lIPJq4YsqQYS0t AUFBUMs9pN+FrQm7MQAkBRTNy9ZdAPmQSJZOZ0MQmHipEzGtD173gv4S+RrXNlWlnu7Q4znWwRMw OYxVBQdAQuHRBuYyct6MIChEymbTGIxZZmAtLCADKBHFaizJKU11gTCXqGDAIGBiUnWgOVoljQAj eQLl3IJYBgF42EKohISgEVeDvi7AWfBQEGMDM3Mh4xg9LheXtgNgHCV3g+UJ1oaBTmYnUuwQxxaF BrR2N90Lve1S/13LDjHPu9q7bGHBZ2vnhphqFeDBa337nvjI96W6+1vgbFWMLDc6CmThwdoZjXF1 ULDyAK+O0PsJu+yBcjDrkaQtgBxiR6pcYd9QGSavMYkMUCB57cBhy9yqXR4O/fMeVml1iOeqKimM 4rD4vnYw0+MFIptOEHOaZoD7I1vUK04A7SDfr2gaFrfR7tDUXh547OP3YTH/2B+0YGP1gAD8dVZa Vr/Hq7LSbIW1yK7urdYs1zoVo01y62aZlXNrtEsYd3Xdcomkru27LMMJVSc5R027TZ3bopLOu5iW aZNsl/ra4YMawccHHAMSyacMzMgckWhKBmo1tV3aMDMIBAzRpCLJAJpQxsm8RWvDZbx0FbFiAhXM io1BoRJdWCsuGArY0NBqaJZMyBJDMpGJBYiqSIoxIkSKqAMVTEVSJEiKj/lkyRB0wtXK3loqV5pd c13dy7gAAq4o4ijFYitmZbMMklkCYGSAZiY4qiqgCoAKNzCTLcxADITIgCqoKqsbMhMcwmrENGtJ pczFgkApoKFDQIayErMhIsiQSTMuYVVTIoqpEiqqqqsiYijiKpExVVW5JMykuOZImZlkooyJFBSJ EiKqxQYqkRIoOJFUigBZACqiCWg2jUltFFgCFKgUI6JdAjoFwoo1UunQjKjKDikgUChSiAUSBUs+ jqecz4xeC7rBd61KQhgZCjMPy1coGGEOcaYzctzX3I5cNjxLe3670Qk5uhZ0HX271ITbrB3Yy5mr 9JdQz7guAAAB7O50qTrpus1LOSWBAJCEISYYeQAutWVjjq0m9Rzz2y7jBZ1e9M0jMCPRZWRz0dmo TX6SWWWs7s1WwLKGQhMDAzIGAlEK/Vms9H/al2FQSzxFGUIEUuoScnzLoTL1yXNP4v6vrrzzceid 7z5etSaXQfJH4lcAqhhJtkcRoRloDNSsITXXy5+N+PXt6+Xt5v6zm/Zzf1n7hXn+AKhIXi2qMSSU l11EO7u6QYJJJJCRG3mdVMzMzMzMzMytGgUKVSEfXs/Tm8IBAwJTE2hGGZCEIAqjCCm/a6IBm2MJ wzGdfsyfpDNuJP5hhgV2m3pCr1ePZpvFfSV7T2fPO8shvfxXn4DelyD1fswq8y5vH0MFLUokg5mz CyLiihG98JrBsRbB31UmZCZAZC5KZINKRw3mUWjvQlOWLnesGEooYWkuypmqZd3tes6NXjZWJmJg IEMZCc6ZdcWc1jUiFhx0GlmwrCCsCBsiYEgcYwvGNI5O28MOt6RwzWxLAmGsJJjIZiTvO8ZPXd3N B4xdNeoVTEyxaxrHC6t4pJ3ycsk1IThujk1hJ9Mz5fu/sf1X9eKKmQZ/LbNOTUq5Wa04EwyBYWMt WLH9ZwumAAEgDS1VNFJDu1/aRL3h+tsGttprWMkwYNsYlzAgOghA6iFQM1TLuFRY/dIug0KgtXJY IJ3d7Jud8jw4ZzYvNOkjN6uHjc3DbN72Tm9x8ujKZduXWO7jTCWyWNWv0+PzPVkrPz/cZr+clo7z 7cd81XDhx/V3z751kDhGBCEIZnpyQ8WeDzv4KLI+wk2RkAgaZzX1e++XqnjpObhFfj63aKaX1/d7 Nd9M86+Tf79MwDrpyeiZNQyEAKf2+HoyXQCisyyxVMmcF/mPzi9wYj+JH7RWE0Ub1+GoR5dPhokn JChUwLCfKcQjfx70u4FTf0I+qRjJ0n6DsLghxKFw3Bv0O5SUmN4qR4oeGgQ8ZVnvBH49/pyfTjxX bn2LLr4+2tjFCaHIUuTz6QmR8/Ulbxh58+/k0uQ7Mvayj5HD1W0gSA74zMCLEcdd84O0JH6/NGDD hh1jkvPisJuGLtsui6oAyFiX+77gjt+Wtt8Nqx9W8GAxhERSWaSigXzlPqS2Tff0sn1hw8AZ1CIm xJJ89MsNG4TO69k9ufPWqQKskwm7/GTU67UIQkMocZTAktbhgoToSFcSdVhAJvbSTZFzxbU5q59y b2DNw8wkFsSfmgylr6NBPEjic2zo873XZE1qecLZrZo5pkobN5HvjucmTc4cUDZEIGnUhZ0pNzI7 1Z7LM6rrDNG7+POqnc70wkeatMFYsm3N6qlOXGMYxkvaVrOJ/n64LTXIqwBRB9KxD5NxxVSE6fyw /cHgRNvFq8rk6N6hftLLl1a9sphMDLyu9QMtG0Hl/GO9vkmh9xi0ybPc7J3zeU3pnWzcdqT5E3X8 FwoHgk6Dt6sVkLODykC8j7bUJUo78rs51p8hBPqCC7IAvq/YO22CA35UUIDpbyzsYIUGFT8zwu2l gHDBtU7Pi06qNKRgjAYQNcM/cYjqowP0+yApcjDRmN1zv8ttU/HvMoN8PdreayuXT/E/f7n1/Az8 s70BA9oX1lB8yDUHrfGfSU8Y4QL3xAd4gFEBEl6l+oFREXHrksATYNSJBkBgOVLW9S8fvzzmccXB OK2KzKq6tqrsLN/34q9RK/BrHBo35dXa7Zcb125SzO/FYE2zUv7VzK2rIaIDTttaiHwgodIKh0EU QzxQWEQVKg8QAA3mZnfVig9oojoIomx2oAPFNGcNMivbFia540hqN8+Mbb6AYTvGRAHYN3nbubaC pswANRXmNEN7ph243weYuS86h1lyHlAuC3ZMTQedGjDxNoO0exDHYxQkUERBPXnRwK6EKJZnCIHh yuyBD4RuqgYRWKMACFoFi8AX4AlKxFRVIPGtC9gZWwmaY0JgSe+YsChmKYqmmgKCFrVsl7pmwdSE kvVIXvDbA0PKLx3DxtMC9uG622xWAvg4BA1PDiz1MdshlBBdBC5KZ3lwII4GvJksO1+AoK2GGISj MsQqDvb2JWVF6vM3mrWJUoiI1rhNyMc85sx+GeCahNTpeyavn21eQMnDCUxHJ1JRPfHLR+aeV8lD j4dd/Wep1SigoYECBD2YvPm61DRiYZHAxmIxm0LviOyD4iohCuguZyJoLCkVoJgKbIEAh4FmTAgE NQoGR2zKZsm7HMpslqpWCjEHfFD7gaiVVFwmqqKyGYFDqvu21avx0ZQoFIoYmKGbERYVSUVttUog xMJCqjJBQqgUyBIIzChSNKtFLSBy3c+b158+fFCeUyyjcKvqEktr5h8XRnqhQMVsGvnF9ZdvdDKk ICkrxv68YAwQlRoISjImZTbz0rtWqeePGGHlQTsXcfM3xv3waIbCB6ihOqbMJBR9Y4jWESJABEmQ GYkkAgge7a8S/NAoDyLiaIAg6XByEhrw24l1a2i+RMwiC4OtveWV1vn3znbY3BPFEuiHb1LxNplJ NIQqBJPWevex59bm84VANu3L3MOjXloIzqFkPO8brOl503m1LKhuiDYJDBiTq+ZXN95nMPzczi7v 1zP13swrTNMm+gs1oTzumzEo31zMxa2/aRssJQc4vrZ10nH89fXuv6970z7+Lvr/EUyk/PfNNuA2 +6n17oW3y65FWNbbeUb225ql3qs7r9Bsx6bW7gZR0bbvt82p5lU5S9PKUfPp1blW3a0IErlPaPMu GHth+JOA1ewEneEW/AdscHYx4bwbQ2aMr6ffQwPiAipqKo3VAmxgDHlUEp7rZqt1mbmLEoKoALow UMFJJJvfMI6M73xSpBIsAOHbBwJGaTqoplz8zzikjU2CIMXZxBJDKevTdhw367ZwriD2GRhHjImQ UVUQRJQxUzoNpo8PHx7HHpXTpnTv58/ce5mDv/mArkCGaAgkdI2gcYT/izVQCNyVcjNGXJcjqORm jJdTUq5jLS3ArGEaRwqYVtqmpAl3TZVDGJa22c0gxgUDCYjsai1RYRmOJliebrzyE3lq8quRnd75 5qDtrAMCaYnRsuZhttWDABOwaYlljYUCYLCNhEpoxaN4LmAJUxWy8Ja6te5LXnh1Dxu8vUexbKMQ haWlsokBogzFNFjeGyWmzRrRQaXQTJsEGxp2TLaHWy1XquybvMlShLXsyJfq65LGgdgQyU3BhNtG jQ5hbNaUgyxoMdLhTMwZGBh9t2FO4h2N+FHd0RPp5mPLfFdPnXpXN76N0uswGmpqTWmMA0xLGlwY hNTRI61LxXPN7d7eW7NFLzzpXm6URUYaXBszHF1BkKaq8EeknLww6+p2L9Vn7/fff3wGxtwofjg3 tBzFk33lQz9SRSqOm3BAEfrvQ3BITMRddbmvtjmceOeFOagdxzdGjAJNjiGopgqI71sLYPudtWuc hs2JF89ft66+kLQ9TUHMXtLm84mJ2g4h9hQN+jYdJjsaBT3D3CED8xmfbhPxXKS/LvWtiQJsCwyU 3tg7uTcgOCQM+0kc4nYfXcjIJxpEraYKQv7MHAh3XAd0VUvJSZqkxEq8tuYBMXZmSJmJ/fFTC3x3 qutzskjVRUoSGtJzroVIcqo9lQkI4BAwAaGhQhFJBCQEo+fGMnbfewKi8Vm3BAl0ksoqXFKg6jWc 2GcUe/vfrj8fGtg1xS1B4qjwj2gni8Yq5JcHMCXV3WRRwn2/H2wAm3Dvu3VhaeoBiHMZGhDQUAlE WDmGDB6oLY/fXz5ve+voMFNEJwAAQ83QE84RcgHBD2hYhDRczB1dG0biTFFYoKgYyXjDUqVFfxnr 4+L+/fvby/XIdoeCPiBqFqM1DJFzDApgTxQki2VHU1misUyJqNwMxaxQ385NfjxttiZ3p3zQXOBI lwdc0uYfCCiYDxpw7wxOIGI7SYrELuqgZxQB988W6ifaG25YoqMLLReVNrRFigoUhQKAxSrlAen0 eiSuECSkoG9UbsJEkHL4odQZmiqaahmDqDpo/V79t7RjD1b1GLgI4oBgoAcKiKCHoiBPhGDbxVID sTS1tYWOt6DU0Qmqbi9yXHECQJs0nj8ff7Tvt1sVx2sKgEuhwdU3jtYXdBVUZD5BoxGYyluZtGRG jagvWrSapAvFGJV7/jx9Z+/3rfjqq7SkDEHqB1HETns95Xzs4fHOhmB9dB+IO9f8daPmBd0L2feL 4eLaAlKVHe1t4td3Vnz+5xH9oHJuLDxYjvst430a1SSk3F9XSO3bZfXDtAvl8hN3QngvX3jCfeAn 4/fUPrqmoZIlfFI4zRi7uQuGI1E+0TMTGq88fbPnnvex2jIuI8wLgyEhYc05zSGJcDMTEcwMzMJm g+vXx6rn489d+F5i3OoSSNxOoWgfXgM4IYrMSyLIoX7pNoOYyLWdWBiOIVv65z9pnv18eMVyvU6i 4k8USScRzAwYXzq8ZJKpuJqCahiqqqcsF5Ae7LBGeoECgpq4g+mcedXFRIhEsRMgkDBJRnvO3Os0 E2TpZM62ybhNVbbIEm3qg7hu0pF1d3zq8bgAqqCWVBKZBCBwAsyMmcJOccDLpzhgbuOU2RKbqn2+ nZ5+/PPt8XfievZ6JREiuRJAlMT1yyZJPf5SRhJA9FeKjdT1GFU49w8fVGTUm0TYNohmDIDkmzev GIUzPM5LKxMWYNjUPe/2yVggIWFaeQEpoLWC+Tw+ogq2mDkYQmCqSqqiAfaEMFukUoGTTUxUEPkg nvolP298vBl2KiAe+873xCQPo1d2O0V6n2gn0QIRUAQKI8u1xhMgkPVQBz2clyvmzp3He36dAOfL B6w000ZGMmrsd56HB22t8O+BqD7im+KCRxmm5pi1i7+/HXW3x9XvvzE0SeyyiYezlLos6hyWG4mZ syOvVmTXSokC8sQpRSgcqgkQOOzwvPc4+rdqilBYgXLfmvMMwqdQzBxqj51GFGIFYqQLztYl3i1C oPuBmGcWWuZjjPx48X4NZvY3ivMHtExBuNYoNXWQUQ0xezgwE1QYkgjijFCygOcoWDFflVk2G6t7 +UvE1LKtxpCCGZ71CsRqlvny8LgiUybfCLPg/j4sUqIho81ha8vd/r5fOYs5CSMomnZcqo8MyqVI IKkY3hscbz5iAmaElTUXAAHigIjg4kF7AlWa7+7e/nj8a7GxItNUKyx6MoIwEFiCpa1ZtZ9Lwu6h jQMCQyye/3k3Gaut3R8m/LcNIV1l9sWBeKxtGb8S6X7caz6W1ZB8dnMZ1lVnIOdI7JGkdC6b7o61 OvZTTXuGWULdYZ1cx30yK6uU1d3yg3c37q86DBYRguaWw17yBLQmKrMZRohyiNectnikKVVUJGea peGqzaYKqFJNeq6wepZVBvLrctXWMUnyur2ECNIMqGcSVJPLTvN+HeSw/GfNwzDIZURPCEChlDmZ y11WNa247HZtSxv1CznAlmZiV1vmYZznTU13cg4ki5yUYEsVA1aLmZ07cu6PaK3xVCj7f6gHRHqc 1XwdWG2vfUsPeU22yiWKm4CXRnsSUebMepjYwGCFx6SHyF9fJZfPJ2MS4Xe3D9d/HmtrqpXi91xE KIqEgiiFypOkKGT01107ooDt3mdvE6HQtBAGJD6RD5rPxx3OwZ3AYQCQ2qqsrCbhppSnWlrVZ/k7 kAoLQLAlVVVUrcD0IkIQiRi984C6zZi+MYJe3WD6+KNa5N6YukrFlnF3Nu31u7thbi17BVOEZwLF xXqw40nvMCpCmQApMfEdAwKhTdc3lyGvdbh2g9kMYdoDbbEHwLnBysSFtLWFnjzzU7CqWbAzWCIi QDy+axIcRmDmE90vrcHZt5VLwSxJKquECdEoIgf6sGMVVewzLzULw8qEdSqgrdERLvcUAR7wyhVT DCc8+59kKCikETsLIXOcaKzDct2317ZpKlFKicc5d036TN1vDbtC1sNDWpQZ7s2oj7TE8WjKuBRL zW597L+vjb9v1V1J36a0y8K53lo3aZ0nISHSxnj6z3liBwylPvueSx314G8SvI9mLer0731cVLJf EnDDP3uz1KLPUrawadFBMUqnQChQh6Oe8EopF761TPdazU1sUYjCIMjKAM8vKhVJpSpr02t5Wlaq EQXF1ARnelWKKR7vznI3jnLO88PNiWDAhTlV2j0UPLlLABm9rJdvu+7Q7RrLSyJZAzPUqpU49zXE PYx1rUJWwLhzxNJEIEqxZYdu/dCLbObGO5JSYWmTKemXn5fSH16mMhsa2A08bcQOJ6QIHDHeO8Cj V1eN7tZgyXOK1xXOsy4Bv2Ckm8pkxFHKsBsC6TiHmZzQQ3CqYEDUaJC2IP1K8alMY1O7avlpV5Mx MWTfVJc1C8QhAOQjtkqLUSp2h1vdtwbSJ9QzBJMgQMERKTJaW6IDiyqopO0F2lmiUDGNUUNQ52Ch yVqSdt9zQwx3tkPOyCigTbDHbI66B2xSyGbLuBCBDtTQTnGwDucdjGt+Dh8Ed7zWgCMbSsICeshA 0yaSDK6AzVEaCH6Wq5lNbkqQnfGb26kAgGlPQOT8BCz96Qm/DMh0EyWWEGPqqHvhunF7jvdvACQI IRBMEBHqD4VUqHRjLOoal3gsnt3xymS2hpWrFJRgkrUJt9kzy8FIhqv+Uza8hSdAStgBYaG3iEAF Kq7e8NCggYsyrRAAzMir8X58pPFtfWcILVuuEGiAUKKAQCREiZO0I6zqvF3bPU9z67+eQ3DfXZHq RYgxCC9Z2mdUUza6Pfr329HvbebpMyLAIMyVMRD4nclLm4c0NIeTj1SaPBsgA988bA7GJPq255OP uO3mLEC10QeAAkghEKEIgIxIADMHMkAxmQPHwcHxjnfW5jeE4KFCAiJ0FBFHh5JJBdTtWo1IhFh5 kSvPO94l7YVkvhhAi0M4rXHVu69IYy/OYXm1XGJveOBKGIKwLxOq7BW58D31anrN90a2nUHebzpE dm1Gt0nKf27uphlaeOkZt1adcPzWvh7wnOq07d2hDcUrG96Wo0H0bKRuKCE0vFlbXUGyFog6CirW HHmPHz1eKVqIFqkHq7evnG8vulACiVKAhEQJSqI5KkgkWdW+t5u/ohjlxa5CAZyETxggcSSSCdti /mMy3ZOtUkAm4ArdnEAvs+q8OM+a1qlsC6kGC8Er+eQpWcwQQiDNDgDAJqiEKxIBfRKvkQL8lTJt 9Z9T6lZWrdVYYIR9eXfVHM3+R0tjdDSRJMVRUoc06HdrTbShlZkUIQxBWYLBmDOIRxSLZlsENnN4 3tKx3x4z4BTvOoDvBPEcxaqoWU4gklsoLwPEvFB5L0YDfz5DbM2U+pIMshXyofxveyOgGQiHQhIf 5S85KPEnMzUoSKDrvXPJ9jnCypCNFD7uYHjOEpyzyfsvJ6epsTcaQICOM4z9w/VbQdq9EoahAiqS cS57zdoNKgMxRETaIAU6zihIFeVy/en4GfKjFhMEC6BMKwPK5dveN5dy8aVuAHjOxAPgt7clzFC2 J57OOQl75QBziKL0PgSMX8usunOJ8FgoqcIVQk6mOarWYkkrZfK7TfdcbfGRZbUhyLjQLw9tG7xq OBW844Ft5u+sszne1MVzVeTjPyHhX2736B3q6jpWc5t+VoNatPbiOS2uJzOfZ1C3Fuucw+b7vft7 SG53c917Q8ilYiLSlGlciWReGiTc5ritpQmvyjvUCAqCRbPOWtau916CngRAI0cLh5Gl52LRfd17 0oJEhKoibRACoDEAob0pk1rXQ7O5FSCRYIObZHEgkecff3K5znRtO1rhB6FYggp73MdYxm+Tzd+H wyMQUT7Em/ciTwEKI3dN/OM/XW3XcThN0FE3DMHgj65x48t8Uaqg3h2mxwVczv7ut97k1zZe5ouo BTTIARgEuO2oe1DK4jYCPgM2Ai8tJzzqZ6j0tZEGYyGGCwwD2qB1VVd6rc0Fdeu8mpqx4+QU9ePR 4aDl+ZYQpAhgiIQtPWAXwc7kE2uDNsZzfTbvhLCZ31zOkqg8fR0799pOBrVKgsHEEg1UDFX89w49 1CtaEgE2AaOGAT18HkKUPcCWLXlI101D/tcAAKMPQJwwce5s7see5rlmqJE3RIgs0bFmDZ+t+M8V ub+Jmc/SKKdG9CDbjMjJ95UPM7eznbT2x3AmKkEk3IF2Ug/Ob+ePduF9XncVndAkICyeIxra85gm Ouzpn5pnQnkUygkri5bzc+WGcREEIgREEQShOpDXkpvGmxuG94lnzN7tbFQ0339mEx1Cxmd1Vadl 0ipvel5WX6tz+/LNtI5Z+X4s/wdV+03rto+WkGp3pe6+XxBMU0TE5d/Vdch09zOtQoTicnm9ZfOy J4vulfJ5vDridK7prSdT53BPNDMqXtxoY8oKk3CPYMe74/vXZxjFPjvMjAyiIlmAi4k81jPZQrjA ZKAmwF2YGfFdKUharq3qJ2Ab45x6VNlnO1sGx5y9qcvhlymArE381qF++dfnYp3x20yBkjMhIoT4 EQWA0gmqurCYWS5ePkD3eTJWqo7s2EfWfdobmpvIXovJISe8KoYjIDdGDR40U0e9BtdDKE2IBIxg kEo5axXUyMiw0NfBeGRLjIjpBBBedG/LRI3l5Q9kJt3rtPgRsz59eCXo7hAYi6EBxC5FKD1/eAm1 LVF8vfaM0E1BNZQRzgW1jsOCMTJEe6O4QL7MMnfO8uJGGgaA9yFAYGNxGvfYRJkJhEQFAEKAJh1c iDEjLPr1sW45+OS52wS5yNFAEJRcqiMGAcSQC6RnTwmG4hJTKevcSTA3tOjexECUmlCQUaNVDwCU LYnlutv2KTMwlBUglb9hl8IRJJJJnbV6ztxoYxT3KXbAQKoBPD72vfbX7G00FS6uqZD+uhyFllhe 5r1t01DE6neIRWcJZLXm4yhnHxsuwZTOpvyYP+CPTyB4q0mY+F9rmeXEbQrVynxHnHzinp9POWsu FfSxtay0eO06X51OcE2vO6vf4LppTvPQOfNcgk/HB7QWywJekW0NcCDH2BE8KUyOOoFKbnd+aa9h bNBUqiqBZAByuR69Iered9drzcM4finbYI0E0HroPeSbPta3nXyFKg9VKuBDbmsa1c0RaFw06pUA keFHo94KEjGdDuZ8hzL97i4WszXzQ7vG2KJpaJHdpQ0LpTSGupgQub9x1kxUaDmjWKVIJQG2TAu3 xA6oi0mEUAfgE8Bc0RZH32pXFqikQ70MUC5qPO17uDWJ9u0eNzBThglnwbXk0c3sU7b0YUU9bna6 8bewLXM8pOCTxuhXmjLnY85xZnMyiDDSJBLKmAyAD0YsYZKV8+0FhphYxSQjkJHinmcdyjUNAAD0 QEKLhRvQbGPPjtp86vnw3k75SHfttOkhGTJEKiIAFUKiHBuHwZGYKxrN0USuF62NUDrhmzFdKGge ylSrXXSaIuX83yzCJrFHgIEYB2AJTHwohZBvUtiLGVs7m72uZt1RS+QCcYiWG7cYAZAmBgQIb97f S61761pTQ5DGTBi0FEYk/ZPgiY68vrk3zjbWMFh1XbBRCBHMjDDAjAwjHDmaDCDQbEd5GxeF4N6M 2fcQ+8e58nBnT9bJsSbmp+YnxA+OAJJBxNp12614cqasCCSgqSDjBQgFASUs1YGrt+QoqZru9fPP d5dfXt48uVPeJh2MO22xevp6e245+2/w249wckpiQGJSWCgAgKAhCCrEm2/XZ122ub5adwgGAhCM wJJn7+uK+o61sq7iBAZAgwVl3GTv6+fVSfcxmAjMwJvhp6355WE6gBycVEZ1yFHkeylA5y1ABwAn 6VHhKh4J85ixdvNuc9jrvtEwdAcI1GGCbFEm2pNkgivxLdSRGmLTEykaJYIEgixiSIqYxJJ530fX bx7331nbJ9e/c4dCGhXb7kWaj6jT5wWTUtKNqEyW0GuvvWM65NXY3Wus6zW69WzzTy/WTTcbmye8 8uu+szz3tdRPasd1LCMy6e12ie80Hm24Fzw83D50kjsdVc6WIs3ztTGl0sO5dWa+53ea609x3eYo ZxoWIOhkzVpLvWdhQRKbZeZtJdNeSzHKhAQUJABQIyW00ULG1YtSSysomZKEpIqVfXRtVdOvbnz3 cu/x0d1NREXHjx493nw2u3qTndVVVe/sIeEpSoC5HEgyCqR6oM3dn8gIzRVI9EtMOb9+bScCdIgq AzE3x23heG1RpHO87GwlIE+3sw9DCUQyM+KMBrB5G4HPzXb6sJT3qkhbNUEjWSszELMUA3GQeIjo bpCZpXUZAu6dmpGRS1GHDbn5cLN/PiZ2snuqDvUjaNTzkKBwk4ztFG6Q3QG05tib5VoOkqbpCgIh G7YagHrAd8iYgWnLj2+PpBQ+g8B8zIzaet/j5PfqaHcDM0CqhxzWZV2roXmLGhJlknlYSzlJCeQF W6gRHcnQkA8RIEkQFApqbXXdlPhW4komE8KICGZCty2MVu4RkihizqX3vlc2zmwscJ2ahsvUOpLc G7uj5zoAPngRzgYSvm+7aoKWqoJjtfDSdxzcXQEyMh9KG69y96tWvj4U66OKytwQiaUBhB9l8iHL d6RrW12eJvixV6fsjupuD94rkcjveZnNcXzDvOvrhpleOvd+G+0qn3ud8kDStrnoDLGdqaXpmNMq tZxzAtl7CGbGzgiBEQclsFMUrx1xy964nFKmxUEcvfHA6VrW1vt7p6iDKOZxRCby8a1rPYOAiR8C VRBVFDBxJHIetSlMbnA1RVB89zSlILevbe9GhieQnk3OJLw2fcRzmbr8hcW2JHkeFvXYtB5xp78S 0ywodZCvuLG/HUf2WKJSas17XDcf2Z0M80+i2fdj2++VeZzrOYFYN3Cp3vZ3Hfeyp06dHPcu1dFd bbnc8m0lqfuzeSltdPm83DDV90MvHQlUh71tlijw+Y53SatvZhM37fNbrqlYldB8lN8He6W9cfyR np3JZ78GvMi3hKE7btc8mWnne2D7rV597KiFR19p6hi6ayuWz2e54sJAe409XC3jhIbS+OcuvStE 7CqQBotlofWg67felipbLVwbXr3ujMbCarMO9hKpeV5/CvNto3UPOnFJ2ark9be86hYRfdc5lYWn Qy05zFbqevajmtifeWRVRQRLLNYjqR4izw9TuuZ8uaWZd48zsL7Ge9GUMSg8L3Tjp5yvb1qaVc55 PduufbBfV9l4mK1mfVyIsPmVxwhiMKekWRs4JXLzwd70P0Nuu3xYndPU37eUm+53v3F8TxbeeZzQ 0WzG2sq0XuvP6FHj3i8L636BSeou+TOsrvns+puRHPJI7etTzgHNK/t+92GLvE8fUNGLnnvSu9pl Ybc503KFnryPV23caXOYddw+NcA2KkE12d5plqbfqt7WXGl9evZ4gfuUuXarJL5rTnkoxrbLY1Bs r7zdlCo0b0vuwPIh7ejbZ2iXN2mvRALlxt3cjfdR2DVwzVpzUezvstTabTclJ02/d7Gekj1I0RE6 87dfR5G7Sju4SVKZyNHuuJTHcRmBpJmtcw58wpNX3e55cIm+7V15EeW4YL5QtsvC/Agjt65lSMhO Nzzdtplt8XOtJvU9uOkVNVXdoiPFXAW91vslM5tOR1q9MUsezxZ0w0Zz1eyVe/OeBrMb6uViVzSu VxcXvWuchzX+NrFTTJnikY3YLfMKuD8q4WtUfEv24V0cbab+DOilKD6XnkbyIWNQPeWb5m++feQ6 6ce6sN7jIp7G857rN2mUKpp3ZlVV1rWtau7tsvp3WFVVVXZmZmZmmXd3zndVVVWUTLuzOic5vXN6 1rOSQqqrMzNXLrlVVWzMyqq3d3dVVcRCSec1nmua1nPKrlVyqmczOZmkRmVRve853d3bafTusKpM y7u8IlTMzEZzuqqqqqqqqqptPp35zeubznecqqqmkd2duXfKq6pEQZh8u6QiIm971nObzaqqk5RE RBp3Zt3czMyzMzW727oiPUzaaQ9zvV32F3fNRmGjPp9rsOs895OlL4c9746571V7x2Kao1tu7SrG taite7JjgkjOeNlo6ee2YDI3l4+dP6Oxot7L77p8uqa8sbSXbfb8S9ou69LrU8V628ROslbxnijN tmOS0aa7cb3kHK8V8tA07Rns1yNN1dalutKX7O17ftQqqJqBo37lPMaRm3rur7XOKD3nFvvdTVeP F6rjQhVuduncxCcJDadc8S3yvE7F7yqerV63u9TFxepl9+6KW9TqVno5xXGro9PuWkT6u+Vri5V9 ch8Gl877jnc37bRVp01Mz1fT06jmynhjGJ0cvWtM1p9E0SnhZZ7ercAN7soW2ze17KqHFSrllRES kRERWqWFl7hBLOpNswUAyRD1nUAxLz4a3vumluWs3nY5JKVM1e496pvnKY0Eit60PDcNlcjWuVL9 9Ol2Ws9t/TmBWnFW4qzFR3K6WyjVtJyOLSL3tP3eVy7CH1U0ukUXqM6UKvmvU+oard3N33fjnlSH 0Ut4tr22tN3be2zcbq3scO9cVbatXCCH4YHqFXx6eaSqhk9veo5zXt1I6UkIjvsllMD3qLXCh/Na O6+gQ+5zPhmIqmucw7eZdsDdu54m+7uDmdPezsnWdBeDjjqrYvo7yJDIG1cZe7mJysRV0kQKeI5G ZSAdU3RFLub0HnarWdRoafF71lEflELMajetSlYbbh0nd9e+GHqecCe35k003nr1kuHylOr1rlbv w7Mxl4L/zT/siAJ/X9kH2AACBIysanXXj+pdeHf6tIb6xPrkcCJcLcXFbFb1h4JHcBI+0e6FIbIi zOdjBkQv4k/84wH04b15Hcg2DaV3/ZavAz4VEAMLmMmQNg5W1xMFhuVKl1OCJlF7+PvMQeB23Il0 7uejdHZ1ryj2VJbUZpARmDppighIc49GShTLNeoMOwsSkhdo3gztGFyIuzNlkHsqkH0REE5BQ9gV vRs3BIjBoLuG8RzZ1N0ezMvyzR+d0q1ufgHonuT6tk9fNsqUjM/V3ijC2htrY556zOQQHpQx+v7R RygweBOUJFh/8DAfsn2COHdAaB/pGL/wHgehyGV3HShBiDbrWMQDCS09mr663y17to/u0YJvkIqp rcAaQw/mOgMEgeyPEcGCE0Eokrv98zVaFDRxLHgAsU3QyoUcA0H8j5AxboDuBQD3BAcyDkmyVVRH QQ0PAONVRGEpih/P7+BF/+P4MWn9fvirk4Mi/9cucd81j9GINZlHNfxf8wOf6KD+ogZTf747S85/ szaWX4WZRV+PqZJOSoT+QwJgOEk/FI/s9CdXk0p2m+/34cznldTbbbZ96CiZnby9MrTs0fewq7dt 3j7mJLvFlxVIJzt+PqSn5PlKAlCCJ+ZhqdRKRAPnGYEEwn3bxmjiLSDwSCQD1ffIVm7me9rQ7CBw ZiZs2a3nmkCk1Qn+iACsLd4HQSJBOXRhYSXV/XToUNbZc4nfMPfO+GEriHc6pPri6E0iKPdL2fkt Gcwv034BZ3r33zM8deCXzNfWszoTe+xLp6b3ydK+/Ufb2jXLomdzc9dU9e17wJaVzXQkPmY1rmd8 Z8vt+8aFRs8/X0O23QW+tWOj53mu/uGF+0CSucuWXZfBKHwJVWP0qV48P9ta2l7eokQf3GPCzgCU JH1Lfw3a8/AgkJkA0CDaDQ+z3k3IXq/L3vFXQ7UASqAKgIAFr+dwIlGcTCr/PX/bWfNvDnHRSMu7 fy9vX16eW/n168+lX/iKf1HoCIeiAcveP8cR+yA/UF07dEFE0LuP0KIZSUYoLISfYNO6UoIjUREm 1kYsmbbEzRizKgo1JuJdLJGUsUlI1mqWCtTbWubRrtnLmatzmYBd3V3cRbtwRZSnhuPIMj+yofBS KT190dsA+acu42Hj7vPCPntpncOXsidz/AD86gHyDf2jlAPHfvVocevJua/QSCec3qB/MNoaKpKS OZhq3hpwh2hoRMhe6Q4kiOSGCIcQaiEirxwca1xzsAbwfRDlhtQKfhahAXX/sQCf/Bl+/7ANL9U+ r4/o6KW/UjsY2/n8rH2/sS6yWWl2Yp12vl4CBMSoKfBLEcb3qxj+UhWpsiqCJOvCcMmMkDBFIZSq BmUMUzw23aExnUxR4iPqwH9IJCDlVkL+x8dulucM/K2E7hERkXDOAcjtU5q/nkRM0RA7xQKgPeVX WhCqyzfk6UB/nYMqlCWDEPKw1qznaV9ItNEShy4OIOBz3Ht9ztOglyBzanN1kLcGJSor6xvPLQiL XPKwizRjERv7a0XsldVde5We+zTO7qs882o3p1Jdtz1rpPe1kz3yNUul8mPNlJ1xd+8i5S+Qc+LL r0+h20/GPctXuWuZnU65tDPpyuvC1e557X3cmc7v3Op+UEog6r7cngQC4QDahQTbpF7QOaZv0T4A PBX9QEvgFCCUDnCBcvKUqPjN2XzPnu3PsSTcfCiVRyOJPs5Rh4b685S1iiKFP0vc4rXec5+Clgf3 H4+gBohASiFC8PIFL8t5nMHZzH2tbi4AKFNAopv490FmPf6ceHP37d/j4+PjzOn0B+4/wT/lFjmf d2QH7o+DKtLBNCAEMo0IXqgWIJaZtSySaY0VJLMzZKVkyZqqVpW0vwq/qBgkjCE8/n8h8T595P6C 6Nfyb7D9OjRvJx9i5eEDRv+6k1ezVhyl1WaCkt4CueM7Zu5eBZWrE5sDvtOnoKppIEYkfjBbiJii mqbINz8G4nMIc9ucbio9v2664du18YuQ63nwQBiPCBno7IxGfzVBoPrdD4ICoEJOFZD/lxiw2zid 6vnzAvNFwknuu7wle1Ba9e9dGgJD8iSAX3lC8mytnzvazC5uVRNkIPUD3BHggkar2VLNDE1mRUIk SzAAknXZV1LP8I1SaChqp6FSIUFxnx8/PrPHnPjvrRxOUU4q5dfOO2tXusHD84UmKIgVFBPPMOM7 Ttiy+VmlkCcQADemcHkg9V8dvjO2L4l5Lhul/0LDICAaQgkAgxJopKZGExoxY0VFQQwUFJBJQtwx V8Nt2+y5+nDoc5PYyIqgS4T1ziDX0RrWnbdxCFe6ux0AmlYOUb7ud72bNPRZRXm3hRvvbQaGjU0D e4w0IzjWBczN8vQzrWol/re6Pedv78pyXHPTqA9+zca7xsvp0jullIkokBizrUu0J19Dq8UVfqtM qNVGzz2ky8bO+8Rql0v0x5spOk0DKRXO+6Ifmqrxrzvm564tSLSzt2q3EM5lQay9km1P7An2CZCD 4M8XxSD5fd7mfuMSnT6AQIBZET4cPDyyi8ob8+Z0da8HzFycDRQJTTygBeSU+UnDve4yY5ha1gbo M6c9yvR+2y1bG1vLP3NK+i4T/kgZyE8z8buanObxPlrcnrFmR4dOOc+l06XHiXn8gf0A9gfr6ZQY PwP670cFlkEIdy7n61REFRMkUTEkTRQ0BRCyEj39/y8I6kfL6wzNFlWC2OFlIQnMXUsaQmvvuf1T n8wpWSBiChCYkZZIdG3w+KHbwph/MLkJyrgih3U61+/Gq28cMryVo7Szc2Dc21/H6IbFlVUR1GoV AOwEMwowcAaqsjMdC+ybxsjGOkoE2ASObXBmH9AD8fALkiE9kMWRugO73k91mHv84cnxjizBAmwF 3B71LK9h/AImhD+2LJVBsfp+dyUOYExm/8GwpabioQKoNb/S6bc4RBJkEHxdBwUOXOYVtFv+axJk ny3l/4I+EQqqCefaM+To33nMmgQe+hGcH17AHvy/ZiZqiYX1ykzEaw9vBtv+YfQkAg2dBnAEgkEl Pt+PMyxmCJ+kCWlsgClicEZ7MaqE1Ro7owNUAHT0I5xPc6tm1LqfKRqKsbDGGcCdbdSne3oJ0DRc b0jh1RmgMB10OdqMdtHdsYqHvGGnQdZbzP238Xu7/prO+R35vfaW37Rrrd+fGnVx1KZON24qc1Tr 8z1eN0K7HTV2XL6e9tettKq3uy+zWfBePPEL2q9EiUmIfPb23Z1uPYzHG9vglPOTK1IwrB9gtEcX EFYLb7yh+UXMqInoEb/J+lsybGJfFhr19JBPsgCIEF0CKPs5SCc+fMXphnZAEpmoRNgIrEE2K/Vr 7x8+sNrVIg4NsgIAFmWBbz6y51rWs0aPjQVAH6oEZuLx7nO98rO9z5aZ9REqUFR+AlwAlIiBD1B7 785H6822tv7WwIwFH6D7pV9qLQwk1FiCQLYszUmtiqLSkbapU1Fh+J+SrGx5j9Y9zvOBVMkxQQTU QjBpSjfO25ZRNYZCkWFycCJaKIok956nz7g/CKCvnJ+3tm2sANaxb+SKHv+ldzdA+M9AxNbbGPrL u+In8Q5/yS6yO9ON+PHw58B57/joTr9AzBFohAJH6R97LmTTNEO9gmF+c1pFe3/hVBKcQTsDC9Fl wsUDzDx6fogeTrjwUQeEAlBcE9X9XbWsjL6YRuIzdgZkbZu0Gvy5ef2FOvqe78NiAAU6Y/yH62jK fPu/5UUFUqpVEvIK4EOUu+vp1IqfylJy/swZggr91u9Hkmn8Pu+VOUlMgUCfstw5SQa8/PfkEhNE yfHODKo7Wcp08Pur2tYKk+hWcSW7SUXpARCDuFGqGEAUUCkfPC/Io4tIgmgRATe7nxff3Pfxzucc FQpV+gVJCARZAE9AAuAPXwBaTWNHayM9hMG6XQEFEx4qPD4Wp7E+Y5GvsaVJ1aTo19pDbY5KUYMJ umsYRlHkS+6zl69+alofk3vOfq6hLLP84fLWrFdUej2t937K+flm7bvF6Z1ceSmTjea4pc1Tr7PU XiZ7zyRUlofPrgxet575XmoQXxm8rL+8wSe6YfGx7Klt6SkqFIJjnRzqvpG/LTuX6ViGIwHc/l+f 51+npc0QAR+g8x0IvxA9Pa6ntv+Hl6a4fZG5C/iAonM/hB6yT9cdc/j848fnjiE6UU+yvcBP6xmT G+/HVvvL6/JR/uAlEH5JlEATIAGylAL5mSn8frV+0+0eVr2B5D8QHpAAy47ARETYQdyoeA8uvU1n eeNTH3G5x/EKEI6gPbDY+1h7dufTO3bt8Pd6c/Ae3s4PiAfmcDB+wGyQH4KL+CJ8E2CEXSAuCfb7 nIgiCAKFIhDQqR8h/v09hH4n3h70FKIWf1+qv7LGAGQSswD8fx/ZPzwVKA40Bg2hmyuJTLJk5Gv6 DY0fxis4K4r+zUrC3suyWMV/iqm4WGSMyVe0MrJtNlYySRIEma2s0aPG2dKrh13gpxpnF9apUGf3 P+I8YN5WaDQQszmyiV5Z34CBNJdNiFv6djOpQAXIvwfooJ5Kl4Yxjmnb8P8o5AzngTKsDbS23D3r 5P2GYg4Xk5OjSEj+sxf9kBZnAknfY4zg586PdWGE3RQMKHBV9g3kVgTFEqQFYZpXsZYb1JzBoAB4 BbKhGAf+8FR9F18xTb0kTRBVCjBiHw7zvFhEGSACKHQRziSZZhK3lD7qtBWyKQhqGU2oW1lrb0+E rPmXRp2GfVNXb2+lr6QO32WUjUx+Gs75S5nvL+K6wm03wx6r0fd5IZ++xPKXLDaNmPUO95N5te9b 3O2u9B2PkWs8pW7oz2WTS9zps81PpVJuU1ew/NLn3T084hlOuH8ss89rm273DL7u64r1FGm826zv waVbxEZFRseBEKDuB0oc5vva0jfizNUAshEAQgZxMnUdKfjnRkiCYOgQmHh5Nsa3qF8Zy7yOPMB+ DkBAVJB8trC3vmOYnvb2gLoj+qEDOJ15R2K4x23dt6c+49T1Ee9exKqUwSEhSncTjRKS0oD4O1tm ERwOGE5hz9eXl5+nHw8vLx7+nXh3iOs8jEOsAfUd/5LhD5fdT7qaH9BPv+ocCij5jsbkdAQxA9vQ L+AineWa2vdt9lW914gELGMRkiIoiISxgpIoIiIEyABjAGgMWQgEZJgAkAojEGAKIMaGkky+/fyt FneUtmrNNDGgZsSSIG0VEY3379cE1uq80jA0yUzWSNIx54fgt1AQlHcfof7lHQUBuAfyoZP7Q5NA ZPv3oD+pIveqd3EHSi8VXg8RICGg2Ef7PRHsSe3np1YAJuQeQoD+h4g4VOAD6ENgjI/OZQH4OCCR N6Pv9OOIzgB7pzWGBOZh4k7REByX93o0RUNBRQQS3oHRNVw3B1NjK15iipps6HX+v/ScFFD8CLoX 9qKF/CpsvQihyOFgIh6Eo5e47CfQ/HZ/Kr4E6APeodhkTiIdgAVOkgEPEbBEkZQQgE8EGElfc7Az SUhS0kcRP3HDEPJVwY3AJ5nqjwVf7Q7CK+B7IKGwlgIb/x/EtV+yA/gf3EPo+R7t4AYq+Y+9BQ+Q imgCFJD3Kr2FOgy16J0X1A6oKK/HtDEIDJFSSEQZMkGSKGYZIhQSyaSIBBiEpJft6tq82sqotbNa u1vK0jYyWZJTKlQEqFJEgFCJBBC965g0yldd3d13O7V04bFFa7ZubU02aU0kuldNHbrc0GJASMAP r5HJ+gMimwBA8FKQBwHQAsCwhFiNg7KLaGABeU7inUAfenhUIVSBD5RDCHzDxQJZFAjtyUHhA6WF NPdBD+wIC/qIWN4GxRBLQGAqJ4R6GA90gsFSB2BwI/yA/zuvQzbkFdKKwJIqJyBfMUVPZReJw5ig ewnyG0+jqLt2Si5/J3/TAdl/d/TuHQobA6HDiiDgspIcjcVMREUsSUTUmTLGLTJjS0trNDFJQRHg G4DASAOYnsJpFRNCmwe3ZFGxEgbvZIKlCWJ2RRzw8wO+mKgJTIDuzVrNThhVEOTcQp29fu5cmWtV bBB0OgkkpRoKCSSgpEcqGyCibipwDgMgOlF5QF/h06APB+z2Q7CipyaSIn7RWQT+F7kEooHgEMip 2+7Qlj34UXoHmALuD1FEB7cATOY8DBEH7Oeig/NX91eAD28J7R5WSGZjZVgaczUBqlhMRZbVVjEG XArAmRqJbLC1hBLlwlJWkbAlG5CRRpAqWJCWIEwwmWiKRQSTLAscpAmWLTElwMMSrVkIVZKtbGyR gYBliMcJBoNMJSEsQQhlWkyqW5AskMAjCRLXAlmGDi2twbVRIDECWNW0aJYpMCFgxJBapCxyiUIN QjLhCYEaOSgYCRgZbVsoSEEyVZkAKTTMtO7UBN5vLMq8aKvGKxygrMxgy2UzLVkCYFjCkYMXOvOu JeO8vHXiqNbmjbs2NcyUjWkkgZEgDagsDGSxSwlkBbWJjDIsjLWWjAksMSYVilpWEBzHCBCVxEyK OBWksEYmWxyxwJERY4EyAwIJmJrMU1aIyMsq/URQQ/1lU5eNBRBU2VopZpLUVJNXbWsHjgBPlVaf p7gPwPynoFP/4u5IpwoSBdYdf+A= --Boundary-00=_GPGQBRhEbDUVND1 Content-Type: application/x-bzip2; name="r8169.s.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="r8169.s.bz2" QlpoOTFBWSZTWWUwAeEAA0tfgEAwfv///3/n/2S////wYDU/cCEhQ8vvCvu+3NhgKUXt51ahnFaY +pUkeB99g1V2wduspO7AcAZ8+ATzk83V0rlijk7u67Ua0uxoKJJloDOgKoUHmpq2017z3e219Y+e B0pwPZ69Nu2SXaBQHtBtIDbKngvrvWPmwBfAAD3BpoJoECAQJE2o0NBoNAGgA0BpoCUxJpBCaSmK Y1NqA0ANAAAAAABKeSpRTKTJoMNNCMAAjAAJgE00wAJPVKVI1B6QaDQAaAAAAAAAABEkmgQCYgmh oTEp+mKT1N6ppo08oGYk9TTNTIIUiERGQmp6p7TRTxT9UyDQAD0jamgekDxIPY6FP1AP3yv6rQp9 r9z/1H7NTiRRUlIhMc7u7kQsbWrKdGV7dohN2tBdScJxm5ReFc7hQR4YQ6dl1jCbnjc9iyJsFG5D lroJ6TccJw6OzyPEJkw9088FdcBrhE7iHhTjPPIRQEdIAOxOUeQO9dwbwBJUEVB/YwqUIbhpf88w 1IvMLqFKQzthqHcKbiUDUEQsQhmpcQWTJcADnBcFIIYkDcEMKi0K61QYHWZDRDLypTwfjP4E1wSa uymiV5PbHmjxw4XlajOKA2hcnZM9Jx49nJxPEir2VGbwd5q0txmopKqon7g8RE++KAZlUCRJFF51 Gzv0lBCFkVlT+GZA1rx1cYXHDpHIDISUSiL05hkGuNhjaeJGgweINRqXZZITAyHDsGOER7F3Hdet cvcQ+WPhoPBQDTIBOGKgm4FDUCSHjPjJpQ3hiqnSSgJjySxHJAYUTpVUWwsFYcISNbTYimz8IEwR SGSlUuCICjqMijlXJkVy5Yq5XSS5F0pIi5dKuVdIpJlXrbrpGxQwgOYVMcwQXJVfkFPtPnlDj8O/ n/PAfd3fXt+LmSMjG8vTbMw5WtgfODPnWjMw6fIRz7E+psR4J/1DqwdjsRBQ6z9LhqqTHrziYDl4 anbzA+Ve/1fKai//buJu/u2ca06A2fcz4/7H07151t1keNaeXqW6iPTb8ffm4puaNN7+Heo9aCHO z+kZ4hQwlfYDfkzewz60ccGZ9+PgZHAQkSU9iECBiSmm4QOcDhfYDWu/bDcdpVUNRWSSEGoCUtU7 2rBvdLGrePIX6e522ZoGsfCWA0C08gsrhTC41Xf3Ma/B13lyo38+HXLBXDn8L7Wu8IW3iGoeXGl8 EDvTZj2xzqNRXEfDMHirtIa1J6UqdPfBxdnghQVeF9xNxvNCKgioaqk9TEWrOKgfjj+FWhGNnyx1 0Em0rOnedYWfbbbSlinPRFG55lj8RCkifqYLV2Q6J6dnfnvkB3JMqjwdYHnA15Ukg9AQUlSjFAzy ouGWeJfgJdq8tu5YX4KPoXirBaE2kNWpBNHPCLvrvKv7U/L2j7E1x1hw2xurSX3vLLFiDQ3Qk1nk uP8/75l0WktCo9b+ZX1Pd4tE6fpWq2mkYwa2K/ob4EZp4+U17pViJkGQ6cEiINKnpOgvbBiUKqju /txiKUL0o6uRNssOpS1BGnV3hMWyzrrRkDkZICst1A77IHgFCffGbqHQpAKixXYOKO465j0qoMKl ypBnfzVgWeCHGDARSGIRGKCTrmH+OOCvwQ0AhRut2UbAjyK8aNXHJWizCLQGF1Hd3RtmuR8Rxv7n 7dL3qNWb0xG0BUIMKUU8NLDj2NNiCe8pYSro9r+a6Uca5WT5nrhehG7W0GpYMreI6OMEDqXmqMCK szYZWQlDy0L1p7NU6UlmpxtdIw6KNXD7C2aDmIeXTakufeqT6eYWEEWVAGJJBAZUWsgesqkwFT14 vm1Bckk5BIhwajPjijvxPbC3idaiDkCkDw7O6qklTzSq7+/xuxKljWnsQj4yRXxDFSG9xu/iLVEg kE0xRF6WZhKhq8qvaSCold6h7kWw7J5xmt4NwuD5eqsqjTHdp6LkgVxhQyk01EWIjLVZ0HBTc7Hx mm6/FF9ceJioqpUlJ6LvvRGS6zJ9KPQRhFDGQnzqaosh8uSmK/hV0qqovqWfR/YjxE2xDKOvhRR3 TC9VNKohC/OqC1SQ3eFj0QT6TtdeQpfwoDqsFI5bx2eNvLoWA08KMIiE4REwJ0BtQ8/Lk0URSdRo 8Oqcly6OtuUMfk4jcaoDuVu3DTl0OiU2d9ce45wOVR7Op1b5jUozUJSFrFl2SkIxHHIzsXYHeCet 6TOTxuNa88xIqG3BhFSpsOYA0Hxrm7jYkjkGed5KS40RA4m6XhBA6+yjp38V6+e/qnFmzrttSikd CntDtp14FAog6MfEOn8Tu7yqtWq+tO0nRe6lvOfpebbD1+J2sooPAny8oGk3ivLwccYT6kBY1jfF dYM01dYLg1nz6L7uBPKc+SngKqhIZR0KOqj0AqAjt0UhC1AGAU8AjcEepHc00zVxnwt3VPXoOnDp pSus7jrIsdjFdLPuT2K8mCixtr2y6IS+yubOurqA9SuhoVag3euPdPEcz3uL5e2HFqy98dvrPAya yXCiCwrK9hz38/bwe0+k1mDqV1VawZAS1ZKdqmd/AA/Wq3CKfxiKDZSCikIqiJ5lw9Vs4AHmAvts oPP9p4+jAUcgiE3FC8oAbpGCgeHGm4EAYkjCIwgSpK9oTBCUDoSQ2dmQpgpgCBuM8zzm+9zDXvte Seie6F5/OcHQCOLtzt/PUWpnOOiIP2Uvaobv9mLNF6XZ4d+34UQNW/Hxw8tvx5pyFJ9op6MteT/T 8+CmgbOzHn5tS3eW+f/n+Je+YHT1f99+AeqL+/8KDP9R5vy/LOZfx93p+r5+81/kewQMWRkX+37A EcAQMAkECJAYJRIlAT50xMhWQhlJJCYqFWimgChEKATYMmKCylFKkzEVSFaW0taaltpCFyESjFSQ KACE6wyKa2TFNNSqEwRL9VehG0Vry1pdvNFvKyhLJGloIhoY0LgDo1hCUspJUpFFvNmt1FGMtJRB qda4daHAkNGDixKhqaRKGqMWA0qamhNKDBiaHRFJJEwzVIiElKeVtZrUq6rkoyJKptpDEk7bbdta sdSJYhQaWNIoEIBigYmpUqkaS0A0GgCMIR0qMoOaVzSiEogGDZ/j+syaIKN0X7X9H5/2y5/CO3f8 bkZtYWaNSDuWJ6eRIzFapIilK7kVF1b/glxt7y4jLTvWibu/2rdfkSe8a5fHOoc8Nv8OU4mr3uxW tSQ1cbczcxXNXiVace8dTTbcl0xzWo64j0KojVxjIxirQKJJG7vHHpoWrt7VU949bHHoI7UuRjlJ iEljmgVwwuYnaNO022mqbd4jN2K0EZ47PUevsvPW9jvYBa/M7s7IQS2GkC/5wfsR8IpsJA2VP0ZS BlafnYcE8ZmO0qHJrXxDJpwby/GvhGXPe1t9bmaRq754mZq8NXM1v577s4XJwurtTohqxCtNqKav S1GajUGkRRIcZHcl85V6NVoYhyXE5dt3kVwiuSQbtPU1FSTpU023Wu9aw51zY74UFKQ2Pau6Sqk5 LUC6Y114hebq9b0NAkHriFUfe9p9b3T5v1imG2/baFGcKqarzHdjq0DQoakXhGoeHt6R09ynq8C8 qw9VzMSp6RHGCBqFtIhHUNMKtCVFQVbyVdvboLnPCnpvX3GvIXgRa6PSbuCQkA0y46DjrDMw27gw qJ4wznnhNr1fhFUe9tcYDgkqTbQIRU4dlpjsgm0PWxraO9sSj4nmJ9revpG9HENnazU2Lu8NzcXJ 4h6a5FE0oyQe1hXauzPB6uQyCskb1g8rwfJe67vGHVyrwvJ6SheK3VHicovOtbWgoZV42vPBofcb 064NgoHMu60hTuidE2CBp4NzngsrgH8gcsCSUI9frBvMeHt/UZ1F+QQESSOm1VV9gmcKmuumGqAo Nx2g1vA4jUUBL7MMKhjyi0B5Rvt5Qhiao+U+HVkDXCWtVV+GFiNCEckxDXat3JnK00oyAxhquqLj RksdKqirkudIZVwbyRAYZtLOWgC7wIY5h8GNBM3tXr6eazbqHSTWKCdHx3ZZuCfE8SrBdXBfDwgw tFNG0IkzFCg0zDtq0aZ1uwztrNxQQ+i1nDzRKAYIre6S7FXztM2BAYh3u0m1lTLKgOxe0zGPodi6 fiBNKmk2wZbS7XXmPOJrnZaLxVonFd4s/qmb2blx+1aPGmq9WoYgvzd4r75U/z9abQSSHQUEJx4z xiDy8sA336MtOrc5IQU1FBdcGHlzvRpabGgappJIpjb7fMVvdtAcypwqaSq8jIOwhIfjTVHKzzj1 xHWlBHC1NXq24/ec34XS2c4Xxmh3JeMVaT7tZL1j3M31M42fHGeuoep5ucdLj0+eq1wMLUPDB1zL sowRitC4eZnh+5qpp+kkEVF8eIdnoG1yg+1HHLQuPPmmCXfi7u2NjQhMSSbGkqRdsurE6V3ZaRbu DR9L4a1O8uLXwZLVKFAYu+zcvCevhQvf5A44H5edahmoPBDhd3as1Dr7otWBgxEeOBXXDruASo6t 53VwUMdunk1+My6le9phmU9u8s8Kxnqw8zr0WtJBHGIe0KIEQNSm+5oxcFSdFC7rvQvZc0aTEwVK YW5Qdn4kc2CxLKtrAXA6jqOYlH62TS/XcTtkzQghl5xwc9dVw/O1r2dkZuWVU+I521I8dMb3GneR oUkzoqZ1vWsDvRXUB2AUG4XVgobmYwousJmqhSFHbfZ8Xt3YPI1uniihefMOKDtzrUM1B3IcL0dq zUOveLVgYMRHbpv4pwVroy41vvHHz6/k9OnWg7ni1+Tft3HWQAPJCQe56fltHzcfuxxuzk5N87zz EX4USzVE1RQFNNDQETJfKflUHeo8vgfRFrerFaWZiKhLnTEq0nwXvfWp/wgEi4z/CBZhtn4HhEB9 3vUHanoyAhJNw7AoTbs+MkAMABAERIAIRAwISAIAAICIQACSSCIgCAAAIAkhAgCCyFEABBkAAAMA QSQYEoAwABBBergADvc+eEgAAEgQAHzenf9kMgQ+uAYpAUTOKDICB71CKj5EBEz73h+eB7OXjVsa lGHnn91dNMys3CWqZ2JpVvU1NagrkE6eh0wtkjVKm6JUTtE++JqxBk2scu1ETX1LEkGJJPgtbRHq jnroQ6DiuAwN2SNNBuM5zfaw4nmoA3AcvCbYgrF4LCqIY0WhBwglKvln5aNLpXSqmLauZCIi6OHI Il8aMKcCS7ZAQpVypLh3oDWW+4/N8ZDWWjqYitPoYDl/X4MDLBBm504LaPrhmO7al4ZyM4AH6sKO K5HJE1INi7MWuoGGXKEFqF3lnd9bqdRrMaNWRXW88D6vzoeyE5508p7LPMoKUOzUoPXgHVpyz01Z vlswvicppCJthlB7F1cES51vtz3fQSgZIBvvvM2P6416mOQS1SRMLptvQZgJwOzdrWGBFHdA1INr EBuyeOnV1bL8ejnV+OaAEqaCogqjrOlcYplloVTi7LGZfZDQwDhNdNmexQIRZFCxppCFl0gZRczE eGGdrovVQYlSIA4pVRwqxOkb45DF8zs2HmA1qznvvso0xyvUTWQBpGaDnDSEjiSOu5QEL2qKTMLt FAHWmjMCaC5SoD0GK2MRa04fTLCuM3YEok1thr4LYB3o7tIo7tHm6ZqoigYI4KZh3xYQNYnKI6xE NlazC2BnoZ28etGUMTXbBpb0tXE2muWxJGY8vV21KEFps8bgWJJsVsLRX2I0u2JD06PHm5HqG+GB pD0VR9SKD6F+E4fekixtR0nq7ossKEgezOnaEL1KkZGMqqcqxs0R/EdnS2umbCog8pGIF30alWkj obOUhspI+b86LVj0C0XwvmulnWZnAjRwJOg5o9MJaEme1UW++9dmG8bpCQktgwaVMaJetsnebqmZ KC66nLdx11rrtsyHqgcR8fWd67wJrtw8kFFFGB5kvmeWGx7ZeOanu5SoZfFRy7udK7EkXD4Sxdeb XnjRi0TPjeLV77nXJo15qdNukc8vrknefCOxDbpCtUf5EW0rcZvEyASCSS1BcAHG82scM2uZlW1g VTU09yABYB6DjxZjnlsyamtEo1jOVDkQH0SLu7b3nj49d/X2F8C9TVkNAed6IN24PUBnVbGdoZvh 9mvYjvT2Lvqr5KzhTMl8oRctFKWQMJ0eUHafZ4gZb7a4/R4+ixg4ra22Aulr2mq3G8JaQVIqClZr FAvhPejuCEusdM+lhBfoV14pJeL+AhFn1Bjr111lWvjJl8igvsod6clzVxPE2vSFqGzEVn3ABUQA KRK+XxQ7Da4HIdzqeFVBfZvSpeNFzmuEbHUQ+9p+2DLbEhg6nH16LWigSKSzBDDitmo1irlxVNNI OUy9OaXAqEymgVVqvTNa9ZPhHEaxgpNxnbNwb9U8WmcXaKSqm4Mkyx3yUUVxZ8b77eISqmim2FU1 T1kIBdgOWxTZJpuQCcZyppWoIoqbBwQp8iJvZOrZqzYCiVvD1YRW7F1xoH06OjWe3Xnkl89d81V5 wmbos51qcT2VyMkqoEYMzBUUMmyZwdtkFkGSCUTUovGX2e9tVO5d78cstM9OwNEXSKDhMYwlQQtr na5LoaVjIIo88+lfNtqW+cPLdeEGhp0vQewkrrxWWkVoXPvZx7WXmzc1noZWGjZko40a4uYqVyIw LpCNbRevgXwipnGcIv6AStBRdHQlEDlBNQupQLMtG8BrgpOiVu6UNrKS6SGbjXu/PC3j9Dfj5lUe VxtxKHFCjxItsLLLEkgRC7SARL1c69MkdNANVluirClVINoGDdN6hoPNtVqtIvWknwjwtWjapcVV G+DlQNlP360x5bOeUw82yLWuT4uh8MvXK6os8/AZmddvrs7siB0AlQey2DhQgyjFDChTxrZINsDC 61Dqzw60NEWw21h68efMb+L0itJV2DSbqqqgJ7ei+JPmqzaNfD8Qy9+MX0KKaKqIotBVPza+X7ti 2Tz1Pd/F3vFi7rz2/mrh8iMXYYL4Hs6BHs58UTUsS+aW1OSCFfNplwYUmxVzVVFNYXTTS7ybu8RG vA7oBEQoU7Yv2wUzR5dzmJDJSlq0psEAe5PfXHGR6yBipmtXrihuLetwvdQVFvbphU2O0JDSReOt EqbabDJDLIqSxJUDyh7xDkBKgJ0GShKB+dBnD5eJvOA4mEYszciwCJWq6yqysNueeUR9gpNqqtel RUmmrRT6OelppFftVQCstK01o2FnYcHAx5YNZmFXyCqwNgaWvZ0lHNVje19b3vOEwCrWg4Souk4h BYFMqMhQKIXQs7clxVd2hbKyxWgyH31r2GiWk4JfBx3u7MuBs70Er4wvfsmXa9d361UeqiZd3TN9 4DylwQFchdFqxBJRNCpvqoiEkC4NNSErRSpJwysy11znFVnSTD60pNqxJQIiADYAGff98fX6fH9v 4525bNxvpwvEss8TaK0k2tMWZ62oX3Xcb8TY5N2actjOmjT7mD1vU2VXMPNDBqt1Kq/3JccLJi1W Wom00gytM8t9bPSbVN7u7a/Cq3uK2qpjQS1FKzSxEzOLVwNoW1mq9RExjSb0oLN9fjbluG68uHpQ SQsPqy9T94SrteooIpaz2579N+fTgPShlWNuwwx54Za4D3QqEWQJIT7E8VA+QfBU593by3ba5TjC TkVVN5aGwED2L/IPiif/MQImgphCYApT7FvxPyoge7f/B9z4dEhP0WFH5L20v7Pl/7iaJP37ZNq8 TBvwzQESEFQi2/52OJY+J5uYI6nE/D9AR3AI5uoY9AEbGP3TP+GHVCl6HXB4kMhJ84bzcvP9E6/Z CfKp87V7vy/d9l7ZYY1jl1BHgvqXuX0/nJIfsR++EhOlJIVVFf0E9Z/enB7F3pw+hbC4+CET7QYm J95D/pwkJWPiuCHvU2CYNFwgbEwIlESlZnoFyzkNwr8zAQ3BiJ4QE0sKeCaQxE7BEUFBPjx3vSp9 6bf8tHeH457xNU/cNlN4YtfgGoO8bcJJCSSrs+b0cu+4luqqvPlINp/eddAeRyJ2E/NKSlID96n1 cV2l5QXSIkSycqQ4hFLDfrISQnRTJuo3E5CXXsGEyYhE3iXANy5JSchpORzTIvykISS6u1NUtznb IGWKm8YnboumrAwGdxx0kCCqq8AzC/E32D3AHu7rrtRFWK4nP9Wl1fnKEgRQhR3CHA2H3GMAkNhJ PINRyUv6BeaaRqB5KAcd+vVT8Q9B6UzB64AJVKb/rV9SABBDsDAEQ7PI4RIVgJnmW+V0A7PbpuzX qCWOTZQDmJtzQ6g4OSbcwqvsniCHsC547tFPLm+fTepW4ciMaxajaXtdrndxq3LVxlmYwSbWSaqC GWZl27dpAEQw0SBLC06MFDAUNS1zNtcrs05ScFdd0zmuVZKWFL5B719T7gKaPQhDSXE45nq1jrMC qKpZ354xr9wPsgOxDkmHpBx85ig+s5BCPh5L3oHl/ZiSRByOae0HhMNPdQ7p3D82g9x7aYkKaBCg GQFGDAAkBk2Kh7UNbjkgeBo55ksYsY2ysyZJtTNWNIqqYlVgSECIT63Xz9tbwD6VjRSA6AiGmczD S8aTIiZxdm4MxzIh7xQ8e4ncmJqCqPPAh9B10GSOGSxGJiCEPphNQBzmKej4bXn3B3Ta82rd29aR QIyowQiVUsTFAEhIeAtvWv0fHeGvh9scWt5f0qmXS/T/ruXenIjefdN8MZtCjQPL7752GsFf3tWs S81LWbvoowb2JJNShCk6aKGDk4AxjNsPWapMzNEhk70o1D1I8I0KkICgdAUKAHsCTqJShjioBQHQ EqaL2ft7s32+ZN0LDhD5G/KSYIkVmCqYhKQpiiiiJsqStaVNqm16r2LHgo4tK+0ikhIZG8DBY+4u qtjUgnYXo7vhJERQQ94xIKWqSCViZqAzGTImFtlty5iGimoqKPJPfx8U+rEfisxE29YwiqiKmpBV 6YQmFQqPhTlTQUlbw+Ol41ianAI9h+TWZ8frqgAAAAAAAAAAAAAAAAAAAAA89Ps/C9N56L6Hl5z2 1egWmRBLbHjHFSZ6qhhLvhc61Da5OeIFt6xMtYZkNKsyk6yakzJr3mfIcYGqKS0tk2Jk0BEzNmSJ k/aRFDmCKNtj3DEDigW0UbqDq59MLOm6VpYpIETJUOAkRE0QNqBFDh9MswMEy50mSdx3xCfIsrzD PoZDpTahslRoLGtVlGpCE+GYlwMOonaLYEywBeiahqichFnc5CiUpFGJ1YKnMqKQ7EgkGKSQ0RVS BJCYsHw+T5MwN7R8ALJlSOGPp0QN6e30cMTwLmCcC42TRTTaJnBbAEXop0UoOKRPg7Ff6qD45gJ2 wX6BIHz8zGkiaqh4XOiZeD6fARupigcEsuQgJhgF1IOAmFnoTzvX9VAVsGPepZSgpVGJmDzRNPVJ hfUIyxRGxsRJJRbRqKRZURQMxGKkoJrJsmswmTTMRoWGFNY003tVvE7fU9v1vLLSZKMFNNlAyoSR NEaLRAVmkYGmIkisa9f0nnl5lwUuxZffHB7edhVVAuKVVYQkkklC3Ez3wOaOxOW5PAb80lCf6GIg JXrADgXhbpwKErBPZEMg8/iDIuJPXteikkmn9wFESXnlwEhpph5oBFHvIdkdkU1EcwCkwgtAkfpo o5gugkCP1RYZBSzU2Jx8Q8D6juIyEHAu5JADYau/kmwOy0SEjJ5+2i1CmwBoDkUhxRA4KCYIEAV0 85vM4LiQPxcWPIsFjJGJx/gjJZZWUUSqo906+yg6ifVTkQh8CchyE0aMSkM8jWheOyXv7vTcseKm TJ2prudda46I0holkurEKhKx+pTmoRGi3T+us2Ks8U2odokZhZhgOR6u06tWQJxYQYBdScjvKOYN xorcObgtaSUlWnQwhGDMlZa0LIO6TKsSMSc2ZIbhdk4qvP4bo2GFuUI6bBVSFwiIO0HOzCjCOOcy KRtQWAU9hDrMFKQNzzIHO8BXo3hojiuLMEMZM+1iUth2ekIEgSsKeA6M0DROY6swMrXte2FbVUAl YWQinBOPapFwDI9OvEfd47iMoPkw0awwMMMIizMgxfa9LKjAdHO+BgLk+jcoCUPeREuZGBvgohQw G+qcFPGylUqapcTmJMg3hgWLezw6odRDgp4HMgUQSDyfnh/CyFqoWtyX5dL2kl6rLcr51eiwTTrW EkISsgciGsCdChbKc4ikHVJQCIRGKqIdwCUIONnbmK4xFdogJ02+fB/sqR5imgaCfOE59L/KujsC cKDhk3GCQAPH0I8QErQTHp3OAmxePLJTIBYqRAdYqm2EAKMDtJ091zcJmZR4BFiOgIS9KmCz4bxf J28NLKVDFR9PkJ70Ck7IA+kXVEgDb6J61fUXX0jcTcli2wUXASlNFSyUvu3pcfqAFg98boe0OS+Z 8s1NaSyh7FAhGRGEByy6Bg7kzTqnr1DOHPw8w6dwIHGIiC/drQCevexe4FkkhBFfHdTd3ZUoFJQS EAQMISULHdNa0zQ73W7xpdpyJiyzNjYxotJoxkLG51So1jZMasaLSTClptpzmGW5Xddx3dq6bmNq 7ZtzUWyM2SV3XSUu7tcOS5t0oqmbJIHpQAMTvuhS4iGwygGg7SiPlPwnt2mCSbzdu+IoHSB4pJ0J 7w4CtqWRNXUALqXEUilJcRSRThiDe8FPJbhuBIm9k5qYqYiKRTQbF0Pignz1JV9Lme3RSQkp5+8T DVLDRVFoxMCllKjHgB2/MhyrAR82wQ27HYkBJa2Mgb0GwIY0nUml0BYPEn0rYhI8MNUhs4gIAliO 3DtANKbRITNSiTAsQtAvyTSyHjAYGSPd1lUdpDcjkUtPUboikYNxgUIUhOlrmqBIJQkSHO1vlBsT ZoSyzINQhDKkpMFMETwV6uMZCoqWJi6UPzAij5sgff+8QuIcclxUJDDyz7Uz3ciqnDAAj6tb0gOV 4hlZURL9pdTvB6ocuHFA7rrCBfRl549t4noHaatZAkDJgqeSCYncENwjwD1gPchqL1InZEENFpDa gdUTVdvlmvMB0yFNyisUYiomgWQEP+fZ3/DPX6tjV8p1Frquq6rquqztZ2s7XVcVdXmNrqurzGR1 0jWdEXl15eO0FQVdV1QSNBMlRna6oKs7WdrO11WdrO1naCZKs7QVcVZ2s7WdEqFdoJxTJ5qebGpJ jQL2oe9JOnsjJ40CpdAyIOXB0j5n5oPnebHuFZlLKL/M0RBqAAw2PBXepAdgW5b47WTtcE8FHSOW hBJBJR8RPnDxLQnKnMiDtDnxCooIFkUpSbRRmxmSZlIiYRZKkpCb0BygYo8ggdeCYImRuE9YlldM 0VE8rOcR2JYeCa5QIcF8MlSwgZX4hucFViRR3qFQBIKlJ68ksEXTB97z4aWE2VRMS4epciCBIqkk kIpIoEXvQNjPDg/V4OeGbvja4Q10+UO7Ioy+h09aiFrE6HVFc0XNVVEaXcmCaoiqt6TQiYvAUmKa ghsLiLBWgwX3uQkjQQ2xDAx0D20wIUCb0BeCBmf7k3hExdcwtmbReu8NtCclHiRQbUB7UyBNgI5A KBsDUuJ13exMlE3kUNHfXZAE7VrfAjCUJsUobimB2AgbLcFPgroKn19bruLu15ewXIMx17FBlzRX W3SxRyXoCefLf2tR3mziALuTnisTWlOgEWuZSKYKRME6IVXAQ4QC1keCUCIL4idIrtjIwiGEkELW LfRx17gfkamvAP1q1bdAXr0ezKGZS92UamqLTrMYy06kJ21GUkSSnsqoQqc6WRTI6nqhTnkTl0KT yRBkLXdMDwvGMs4rOM1zimeNoFjdtKFhF4t3RiDhHbD1ZSw5trokJDRUGsZ4FOHMK6WwxGcbPZ57 G6PgO88YF5HOYMSvLw0WEujWEJEee4HjUEPYlWBRwEnJ3SDo7MuLZzFbnMKHSorTXvfb6Pm+Hp2Y fVs2S2cVE8Z7HEyz3RlINklVcRK88ONRh7MauXMrmRHNbrHu3GQ3htx2e7p6e7pOF4hEVk5gkdJG Y2wTL212K5saEQyTwTsUZoHnjnkyywo7QJguzxc5WQ6QqCSalAVYE+5dB2Hq8wvQq8ece34yAG1J CeilXAiBr2b1CviqtIFzrC9U10RLIc1sKBtDtRe5EDvFpX/8XckU4UJBlMAHhA== --Boundary-00=_GPGQBRhEbDUVND1-- From francois@baligant.net Thu Sep 9 09:11:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 09:11:23 -0700 (PDT) Received: from mwinf1003.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89GBG0X002018 for ; Thu, 9 Sep 2004 09:11:17 -0700 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1003.wanadoo.fr (SMTP Server) with SMTP id DAFD318000C9 for ; Thu, 9 Sep 2004 18:11:01 +0200 (CEST) Received: from [192.168.254.21] (ASt-Lambert-152-1-14-75.w82-124.abo.wanadoo.fr [82.124.44.75]) by mwinf1003.wanadoo.fr (SMTP Server) with ESMTP id 75EE118001A7 for ; Thu, 9 Sep 2004 18:11:01 +0200 (CEST) Message-ID: <4140801F.4050208@baligant.net> Date: Thu, 09 Sep 2004 18:09:03 +0200 From: =?ISO-8859-1?Q?Fran=E7ois_Baligant?= User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Help interpreting ethtool -S for tg3 (rx_discards and such) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: francois@baligant.net Precedence: bulk X-list: netdev Content-Length: 3618 Lines: 118 Hi, We have a tg3 NIC under heavy load (30megabit/s, around 15k to 20k packet/sec) Under 2.6.7, the NIC behaves quite correctly (except errors see below) Under 2.6.8, the NIC's link will go down after some time and not come up again (rx_discards grow more quickly than in 2.6.7) Under 2.6.9-rc1, the NIC will go down from time to time also but recover after 5 seconds and link goes up again (dito) Should I worry about the errors in ethtool, like rx_discards ? What does it mean ? Can i tune something to avoid them ? (netdev backlog?) Is there any way to lower the amount of interrupt needed to handle this load? (it's eating quite a lot of CPU) Here is ethtool -S under 2.6.7 root# ethtool -S eth1 NIC statistics: rx_octets: 965700844 rx_fragments: 0 rx_ucast_packets: 828761367 rx_mcast_packets: 80 rx_bcast_packets: 4768 rx_fcs_errors: 0 rx_align_errors: 0 rx_xon_pause_rcvd: 0 rx_xoff_pause_rcvd: 0 rx_mac_ctrl_rcvd: 0 rx_xoff_entered: 0 rx_frame_too_long_errors: 0 rx_jabbers: 0 rx_undersize_packets: 0 rx_in_length_errors: 0 rx_out_length_errors: 0 rx_64_or_less_octet_packets: 366875287 rx_65_to_127_octet_packets: 438933359 rx_128_to_255_octet_packets: 18104208 rx_256_to_511_octet_packets: 2937651 rx_512_to_1023_octet_packets: 956801 rx_1024_to_1522_octet_packets: 958902 rx_1523_to_2047_octet_packets: 0 rx_2048_to_4095_octet_packets: 0 rx_4096_to_8191_octet_packets: 0 rx_8192_to_9022_octet_packets: 0 tx_octets: 3659297 tx_collisions: 0 tx_xon_sent: 0 tx_xoff_sent: 0 tx_flow_control: 0 tx_mac_errors: 0 tx_single_collisions: 0 tx_mult_collisions: 0 tx_deferred: 0 tx_excessive_collisions: 0 tx_late_collisions: 0 tx_collide_2times: 0 tx_collide_3times: 0 tx_collide_4times: 0 tx_collide_5times: 0 tx_collide_6times: 0 tx_collide_7times: 0 tx_collide_8times: 0 tx_collide_9times: 0 tx_collide_10times: 0 tx_collide_11times: 0 tx_collide_12times: 0 tx_collide_13times: 0 tx_collide_14times: 0 tx_collide_15times: 0 tx_ucast_packets: 832632783 tx_mcast_packets: 5 tx_bcast_packets: 65 tx_carrier_sense_errors: 0 tx_discards: 0 tx_errors: 0 dma_writeq_full: 496271 dma_write_prioq_full: 0 rxbds_empty: 0 rx_discards: 157542 rx_errors: 0 rx_threshold_hit: 828579298 dma_readq_full: 71729839 dma_read_prioq_full: 87219 tx_comp_queue_full: 53098049 ring_set_send_prod_index: 763849878 ring_status_update: 906065223 nic_irqs: 647367776 nic_avoided_irqs: 258697447 nic_tx_threshold_hit: 24570520 root# mpstat 1 Linux 2.6.7-mjb1 (localhost) 09/09/2004 10:58:02 AM CPU %user %nice %system %iowait %idle intr/s 10:58:03 AM all 21.66 0.00 14.65 0.00 63.69 29276.92 10:58:04 AM all 21.25 0.00 15.00 0.00 63.75 28553.75 10:58:05 AM all 14.81 0.00 10.49 0.00 74.69 26353.09 10:58:06 AM all 13.94 0.00 10.91 0.00 75.15 24815.85 10:58:07 AM all 12.50 0.00 10.12 0.00 77.38 23850.00 10:58:08 AM all 16.77 0.00 9.58 0.00 73.65 23755.42 10:58:09 AM all 14.12 0.00 9.41 0.00 76.47 22460.00 root# ethtool -a eth1 Pause parameters for eth1: Autonegotiate: off RX: off TX: off root# ethtool -k eth1 Offload parameters for eth1: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: off From davem@davemloft.net Thu Sep 9 09:18:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 09:18:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89GI5gi002406 for ; Thu, 9 Sep 2004 09:18:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5RbQ-0002y1-00; Thu, 09 Sep 2004 09:16:52 -0700 Date: Thu, 9 Sep 2004 09:16:52 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [IPCOMP] Use per-cpu buffers Message-Id: <20040909091652.490c7833.davem@davemloft.net> In-Reply-To: <20040909122202.GA3170@gondor.apana.org.au> References: <20040909122202.GA3170@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 629 Lines: 20 On Thu, 9 Sep 2004 22:22:02 +1000 Herbert Xu wrote: > With per-cpu buffers this goes down to 300K per CPU. That amount of space just for decompression state is rediculious. I seem to recall that the last time I looked at this the reason the tables are so huge is that the zlib we use in the kernel isn't configurable. The table configuration is compile time decided. Yes, it's because of linux/zlib.h's cpp settings. I guess it would be a lot of surgery to make this dynamic. A second thought is that we may not be the only part of the kernel interested in a per-cpu zlib scratch buffer, no? From davem@davemloft.net Thu Sep 9 09:56:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 09:56:06 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89Gtxg1003371 for ; Thu, 9 Sep 2004 09:56:01 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5SCp-00032k-00; Thu, 09 Sep 2004 09:55:31 -0700 Date: Thu, 9 Sep 2004 09:55:31 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Catch wrong RTATTR_MAX with BUG() Message-Id: <20040909095531.331fd168.davem@davemloft.net> In-Reply-To: <20040909164346.GA18994@postel.suug.ch> References: <20040909164346.GA18994@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 699 Lines: 30 On Thu, 9 Sep 2004 18:43:46 +0200 Thomas Graf wrote: > Catches outdated/invalid RTATTR_MAX and therefore avoids possible stack > corruption. Your test has an off by one error, but more importantly, it's probably better to do this at compile time with something like: extern void rtattr_max_too_small(void); ... void __init rtnetlink_init(void) { if (IFLA_MAX > RTATTR_MAX || IFA_MAX > RTATTR_MAX || RTA_MAX > RTATTR_MAX || NDA_MAX > RTATTR_MAX || TCA_MAX > RTATTR_MAX || TCAA_MAX > RTATTR_MAX) rtattr_max_too_small(); I would therefore accept a patch that did things this way. BUG()'ing at runtime for something like this is too rude. :) Thanks. From tgraf@suug.ch Thu Sep 9 09:57:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 09:57:14 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89Gv8NL003562 for ; Thu, 9 Sep 2004 09:57:08 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 4869E84; Thu, 9 Sep 2004 18:56:35 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id A2D791C0E7; Thu, 9 Sep 2004 18:31:31 +0200 (CEST) Date: Thu, 9 Sep 2004 18:31:31 +0200 From: Thomas Graf To: "David S. Miller" Cc: Jamal Hadi Salim , Eric Lemoine , netdev@oss.sgi.com Subject: [PATCH 2.6 NET] Adjust RTATTR_MAX to IFLA_* changes Message-ID: <20040909163131.GA18951@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 551 Lines: 17 IFLA_MAX is now bigger than RTA_MAX with the latest changes in IFLA_*. Adjust RTATTR to point to IFLA_MAX to have big enough buffer in rtnetlink_rcv_msg. Signed-off-by: Thomas Graf --- linux-2.6.9-rc1-bk15.orig/include/linux/rtnetlink.h 2004-09-08 18:32:05.000000000 +0200 +++ linux-2.6.9-rc1-bk15/include/linux/rtnetlink.h 2004-09-09 17:32:14.000000000 +0200 @@ -662,7 +662,7 @@ /* SUMMARY: maximal rtattr understood by kernel */ -#define RTATTR_MAX RTA_MAX +#define RTATTR_MAX IFLA_MAX /* RTnetlink multicast groups */ From akepner@sgi.com Thu Sep 9 10:00:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:00:15 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89H0BfJ004093 for ; Thu, 9 Sep 2004 10:00:11 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i89H010f000911 for ; Thu, 9 Sep 2004 12:00:01 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i89H01l229282144 for ; Thu, 9 Sep 2004 10:00:01 -0700 (PDT) From: akepner@sgi.com Received: from [192.168.2.3] (mtv-vpn-sw-corp-0-15.corp.sgi.com [134.15.0.15]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i89GwvYA9268172; Thu, 9 Sep 2004 09:58:59 -0700 (PDT) Date: Thu, 9 Sep 2004 09:47:51 -0700 (PDT) X-X-Sender: To: =?ISO-8859-1?Q?Fran=E7ois_Baligant?= cc: Subject: Re: Help interpreting ethtool -S for tg3 (rx_discards and such) In-Reply-To: <4140801F.4050208@baligant.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-archive-position: 8562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 34 On Thu, 9 Sep 2004, François Baligant wrote: > Hi, > > We have a tg3 NIC under heavy load (30megabit/s, around 15k to 20k > packet/sec) > > Under 2.6.7, the NIC behaves quite correctly (except errors see below) > Under 2.6.8, the NIC's link will go down after some time and not come up > again (rx_discards grow more quickly than in 2.6.7) > Under 2.6.9-rc1, the NIC will go down from time to time also but recover > after 5 seconds and link goes up again (dito) > > Should I worry about the errors in ethtool, like rx_discards ? What does > it mean ? Can i tune something to avoid them ? (netdev backlog?) I believe that when rx_discards increments, it means that the card dropped the packet due to a resource constraint. I've seen similar behavior (but at much higher data rates.) In my case, enabling h/w flow control fixed things. If it's possible to use h/w flow control in your configuration, then you might give that a try. > > Is there any way to lower the amount of interrupt needed to handle this > load? (it's eating quite a lot of CPU) > .... That is a _feature_ of NAPI ;-) -- Arthur From greg@atheros.com Thu Sep 9 10:05:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:05:42 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89H5XMS004514 for ; Thu, 9 Sep 2004 10:05:35 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8851964; Thu, 09 Sep 2004 10:05:17 -0700 Message-ID: <41408D8A.5010307@atheros.com> Date: Thu, 09 Sep 2004 10:06:18 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409082251.45771.vkondra@mail.ru> <413F70F0.6020709@atheros.com> <200409090815.40358.vkondra@mail.ru> In-Reply-To: <200409090815.40358.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 2711 Lines: 60 good discussion. some complementary thoughts below. Vladimir Kondratiev wrote: > gc> > gc> Linux does the same thing (driver is configured by application code) > gc> although there does not yet exist a single app > gc> that can serve as a common point of control for multiple vendor drivers. > gc> I believe that achieving that goal is the real payoff for wireless Linux > gc> users. > > I would not fully agree here: for timing reasons, you can do scanning/AP > selection in user space, but for rate scaling, if we ever can do it generic, > you better be in kernel. Existing APIs have a command to tell the driver to scan and return the result. There are sometimes parameters to limit the scan to a certain amount of time or certain channels or to sort the scan results on some metric, e.g. is-WPA. The user-space app then selects an AP and commands the driver to associate. That's all fine and well-understood. An exception to this arrangement is background scanning where the driver is expected to go off-channel and search around for other APs while remaining associated with one AP. The driver goes into power-save state with the current AP while doing the scan. There's enough of a real-time component to this, that it needs to be implemented in the driver. An extreme example is the work being done for voip over 802.11. Every vendor as well as the 802.11 TGe and TGr groups are pursuing techniques whereby the wireless subsystem goes into power-save between voip codec samples (usually at 20ms intervals) except for those times when it is doing off-channel background scanning (also between codec samples!). This is an interesting implementation challenge.... and it's also necessary since it is the only way to get cell-phone equivalent battery life for 802.11 devices while also running at 802.11 power and phy rates. The phone people in TGr also have a goal of implementing fast handoff of an active voip call between APs within 20ms. The heavy problem with that is moving the security context in a low-overhead manner without opening up new security holes. I can see the possibility of enabling fast handoff via application > From architecture point of view, MLME should be stack, not user app. For me, > management packets generation is same kind of activity as arp. I agree with this and tried to say it in previous emails.... > > gc> Yes, for logic it is sufficient. > gc> My personal approach would be to test the theory by examining > gc> what fits or doesn't fit into David's API if I were to port one of the > gc> MLME implementations that I work with. Discover if it fits or not. > > Sounds promising. Don't forget to share you findings. roger. From tgraf@suug.ch Thu Sep 9 10:12:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:12:09 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HC3P3005910 for ; Thu, 9 Sep 2004 10:12:03 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 01E2C81; Thu, 9 Sep 2004 18:43:13 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 7EF471C0E8; Thu, 9 Sep 2004 18:43:46 +0200 (CEST) Date: Thu, 9 Sep 2004 18:43:46 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6 NET] Catch wrong RTATTR_MAX with BUG() Message-ID: <20040909164346.GA18994@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 487 Lines: 17 Catches outdated/invalid RTATTR_MAX and therefore avoids possible stack corruption. Signed-off-by: Thomas Graf --- linux-2.6.9-rc1-bk15.orig/net/core/rtnetlink.c 2004-09-08 18:33:42.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/rtnetlink.c 2004-09-09 18:18:22.000000000 +0200 @@ -450,6 +450,9 @@ sz_idx = type>>2; kind = type&3; + if (RTATTR_MAX < rta_max[sz_idx]) + BUG(); + if (kind != 2 && security_netlink_recv(skb)) { *errp = -EPERM; return -1; From tgraf@suug.ch Thu Sep 9 10:12:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:12:10 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HC3bG005909 for ; Thu, 9 Sep 2004 10:12:03 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E758882; Thu, 9 Sep 2004 18:47:51 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id E2B8B1C0E8; Thu, 9 Sep 2004 18:48:34 +0200 (CEST) Date: Thu, 9 Sep 2004 18:48:34 +0200 From: Thomas Graf To: Jamal Hadi Salim , Stephen Hemminger , Eric Lemoine Cc: netdev@oss.sgi.com Subject: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-ID: <20040909164834.GB18994@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 8068 Lines: 301 - Convert mtu and txqlen to use rtnetlink instead of ioctl. - Introduces weight. - Updates local copy of rtnetlink.h. Against iproute2-2.6.9-jamal, tested and working. Will look into remaining ioctls later. diff -urN iproute2-2.6.9-jamal.orig/include/linux/rtnetlink.h iproute2-2.6.9-jamal/include/linux/rtnetlink.h --- iproute2-2.6.9-jamal.orig/include/linux/rtnetlink.h 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/include/linux/rtnetlink.h 2004-09-08 19:41:36.000000000 +0200 @@ -561,6 +561,12 @@ #define IFLA_WIRELESS IFLA_WIRELESS IFLA_PROTINFO, /* Protocol specific information for a link */ #define IFLA_PROTINFO IFLA_PROTINFO + IFLA_TXQLEN, +#define IFLA_TXQLEN IFLA_TXQLEN + IFLA_MAP, +#define IFLA_MAP IFLA_MAP + IFLA_WEIGHT, +#define IFLA_WEIGHT IFLA_WEIGHT __IFLA_MAX }; @@ -693,6 +699,88 @@ /* End of information exported to user level */ +#ifdef __KERNEL__ + +#include + +static __inline__ int rtattr_strcmp(const struct rtattr *rta, const char *str) +{ + int len = strlen(str) + 1; + return len > rta->rta_len || memcmp(RTA_DATA(rta), str, len); +} + +extern int rtattr_parse(struct rtattr *tb[], int maxattr, struct rtattr *rta, int len); + +extern struct sock *rtnl; + +struct rtnetlink_link +{ + int (*doit)(struct sk_buff *, struct nlmsghdr*, void *attr); + int (*dumpit)(struct sk_buff *, struct netlink_callback *cb); +}; + +extern struct rtnetlink_link * rtnetlink_links[NPROTO]; +extern int rtnetlink_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb); +extern int rtnetlink_send(struct sk_buff *skb, u32 pid, u32 group, int echo); +extern int rtnetlink_put_metrics(struct sk_buff *skb, u32 *metrics); + +extern void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data); + +#define RTA_PUT(skb, attrtype, attrlen, data) \ +({ if (unlikely(skb_tailroom(skb) < (int)RTA_SPACE(attrlen))) \ + goto rtattr_failure; \ + __rta_fill(skb, attrtype, attrlen, data); }) + +static inline struct rtattr * +__rta_reserve(struct sk_buff *skb, int attrtype, int attrlen) +{ + struct rtattr *rta; + int size = RTA_LENGTH(attrlen); + + rta = (struct rtattr*)skb_put(skb, RTA_ALIGN(size)); + rta->rta_type = attrtype; + rta->rta_len = size; + return rta; +} + +#define __RTA_PUT(skb, attrtype, attrlen) \ +({ if (unlikely(skb_tailroom(skb) < (int)RTA_SPACE(attrlen))) \ + goto rtattr_failure; \ + __rta_reserve(skb, attrtype, attrlen); }) + +extern void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change); + +extern struct semaphore rtnl_sem; + +#define rtnl_shlock() down(&rtnl_sem) +#define rtnl_shlock_nowait() down_trylock(&rtnl_sem) + +#define rtnl_shunlock() do { up(&rtnl_sem); \ + if (rtnl && rtnl->sk_receive_queue.qlen) \ + rtnl->sk_data_ready(rtnl, 0); \ + } while(0) + +extern void rtnl_lock(void); +extern void rtnl_unlock(void); +extern void rtnetlink_init(void); + +#define ASSERT_RTNL() do { \ + if (unlikely(down_trylock(&rtnl_sem) == 0)) { \ + up(&rtnl_sem); \ + printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \ + __FILE__, __LINE__); \ + dump_stack(); \ + } \ +} while(0) + +#define BUG_TRAP(x) do { \ + if (unlikely(!(x))) { \ + printk(KERN_ERR "KERNEL: assertion (%s) failed at %s (%d)\n", \ + #x, __FILE__ , __LINE__); \ + } \ +} while(0) + +#endif /* __KERNEL__ */ #endif /* __LINUX_RTNETLINK_H */ diff -urN iproute2-2.6.9-jamal.orig/ip/ipaddress.c iproute2-2.6.9-jamal/ip/ipaddress.c --- iproute2-2.6.9-jamal.orig/ip/ipaddress.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/ip/ipaddress.c 2004-09-08 19:57:30.000000000 +0200 @@ -182,6 +182,8 @@ fprintf(fp, "mtu %u ", *(int*)RTA_DATA(tb[IFLA_MTU])); if (tb[IFLA_QDISC]) fprintf(fp, "qdisc %s ", (char*)RTA_DATA(tb[IFLA_QDISC])); + if (tb[IFLA_WEIGHT]) + fprintf(fp, "weight %u ", *(uint32_t*)RTA_DATA(tb[IFLA_WEIGHT])); #ifdef IFLA_MASTER if (tb[IFLA_MASTER]) { SPRINT_BUF(b1); diff -urN iproute2-2.6.9-jamal.orig/ip/iplink.c iproute2-2.6.9-jamal/ip/iplink.c --- iproute2-2.6.9-jamal.orig/ip/iplink.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/ip/iplink.c 2004-09-08 19:51:33.000000000 +0200 @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -46,7 +47,8 @@ fprintf(stderr, " txqueuelen PACKETS |\n"); fprintf(stderr, " name NEWNAME |\n"); fprintf(stderr, " address LLADDR | broadcast LLADDR |\n"); - fprintf(stderr, " mtu MTU }\n"); + fprintf(stderr, " mtu MTU |\n"); + fprintf(stderr, " weight WEIGHT }\n"); fprintf(stderr, " ip link show [ DEVICE ]\n"); exit(-1); } @@ -130,50 +132,6 @@ return err; } -static int set_qlen(char *dev, int qlen) -{ - struct ifreq ifr; - int s; - - s = get_ctl_fd(); - if (s < 0) - return -1; - - memset(&ifr, 0, sizeof(ifr)); - strcpy(ifr.ifr_name, dev); - ifr.ifr_qlen = qlen; - if (ioctl(s, SIOCSIFTXQLEN, &ifr) < 0) { - perror("SIOCSIFXQLEN"); - close(s); - return -1; - } - close(s); - - return 0; -} - -static int set_mtu(char *dev, int mtu) -{ - struct ifreq ifr; - int s; - - s = get_ctl_fd(); - if (s < 0) - return -1; - - memset(&ifr, 0, sizeof(ifr)); - strcpy(ifr.ifr_name, dev); - ifr.ifr_mtu = mtu; - if (ioctl(s, SIOCSIFMTU, &ifr) < 0) { - perror("SIOCSIFMTU"); - close(s); - return -1; - } - close(s); - - return 0; -} - static int get_address(char *dev, int *htype) { struct ifreq ifr; @@ -249,19 +207,36 @@ return 0; } +struct link_request +{ + struct nlmsghdr nl_msg; + struct ifinfomsg ifi; + char buf[256]; +}; + static int do_set(int argc, char **argv) { char *dev = NULL; __u32 mask = 0; __u32 flags = 0; - int qlen = -1; - int mtu = -1; + int32_t qlen = -1; + int32_t mtu = -1; + int32_t weight = -1; char *newaddr = NULL; char *newbrd = NULL; struct ifreq ifr0, ifr1; char *newname = NULL; int htype, halen; + struct rtnl_handle rth; + + struct link_request req = { + .nl_msg = { + .nlmsg_type = RTM_SETLINK, + .nlmsg_flags = NLM_F_REQUEST, + .nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)), + }, + }; while (argc > 0) { if (strcmp(*argv, "up") == 0) { @@ -288,12 +263,14 @@ duparg("txqueuelen", *argv); if (get_integer(&qlen, *argv, 0)) invarg("Invalid \"txqueuelen\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_TXQLEN, &qlen, sizeof(qlen)); } else if (strcmp(*argv, "mtu") == 0) { NEXT_ARG(); if (mtu != -1) duparg("mtu", *argv); if (get_integer(&mtu, *argv, 0)) invarg("Invalid \"mtu\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_MTU, &mtu, sizeof(mtu)); } else if (strcmp(*argv, "multicast") == 0) { NEXT_ARG(); mask |= IFF_MULTICAST; @@ -339,6 +316,13 @@ flags |= IFF_NOARP; } else return on_off("noarp"); + } else if (matches(*argv, "weight") == 0) { + NEXT_ARG(); + if (weight != -1) + duparg("weight", *argv); + if (get_integer(&weight, *argv, 0)) + invarg("Invalid \"weight\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_WEIGHT, &weight, sizeof(weight)); #ifdef IFF_DYNAMIC } else if (matches(*argv, "dynamic") == 0) { NEXT_ARG(); @@ -387,14 +371,6 @@ return -1; dev = newname; } - if (qlen != -1) { - if (set_qlen(dev, qlen) < 0) - return -1; - } - if (mtu != -1) { - if (set_mtu(dev, mtu) < 0) - return -1; - } if (newaddr || newbrd) { if (newbrd) { if (set_address(&ifr1, 1) < 0) @@ -407,6 +383,20 @@ } if (mask) return do_chflags(dev, flags, mask); + + if (rtnl_open(&rth, 0) < 0) + exit(1); + + ll_init_map(&rth); + + if ((req.ifi.ifi_index = ll_name_to_index(dev)) == 0) { + fprintf(stderr, "Cannot find device \"%s\"\n", dev); + return -1; + } + + if (rtnl_talk(&rth, &req.nl_msg, 0, 0, NULL, NULL, NULL) < 0) + exit(2); + return 0; } From yoshfuji@linux-ipv6.org Thu Sep 9 10:23:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:23:45 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HNaom006731 for ; Thu, 9 Sep 2004 10:23:39 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 97A4133CE6; Fri, 10 Sep 2004 02:24:30 +0900 (JST) Date: Fri, 10 Sep 2004 02:24:28 +0900 (JST) Message-Id: <20040910.022428.58971457.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6 NET] Catch wrong RTATTR_MAX with BUG() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040909164346.GA18994@postel.suug.ch> References: <20040909164346.GA18994@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 394 Lines: 15 In article <20040909164346.GA18994@postel.suug.ch> (at Thu, 9 Sep 2004 18:43:46 +0200), Thomas Graf says: > kind = type&3; > > + if (RTATTR_MAX < rta_max[sz_idx]) > + BUG(); > + Something like: if (rta_max[sz_idx] > RTATTR_MAX) goto err_inval; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@davemloft.net Thu Sep 9 10:33:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:33:18 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HXBwQ007703 for ; Thu, 9 Sep 2004 10:33:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5Slx-00037a-00; Thu, 09 Sep 2004 10:31:49 -0700 Date: Thu, 9 Sep 2004 10:31:49 -0700 From: "David S. Miller" To: Thomas Graf Cc: hadi@cyberus.ca, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Adjust RTATTR_MAX to IFLA_* changes Message-Id: <20040909103149.248a603e.davem@davemloft.net> In-Reply-To: <20040909163131.GA18951@postel.suug.ch> References: <20040909163131.GA18951@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2653 Lines: 99 On Thu, 9 Sep 2004 18:31:31 +0200 Thomas Graf wrote: > IFLA_MAX is now bigger than RTA_MAX with the latest changes in IFLA_*. > Adjust RTATTR to point to IFLA_MAX to have big enough buffer in > rtnetlink_rcv_msg. Ok, this is going to get silly if some other attribute gets larger than IFLA_* next. We should just compute this thing at run time. Else, if the macro can't be deleted because there are non-trivial other uses, use some expression involving max(). I just checked iproute2 sources and it does not reference this thing, so probably best to kill it off, like so. ===== include/linux/rtnetlink.h 1.42 vs edited ===== --- 1.42/include/linux/rtnetlink.h 2004-09-02 13:12:43 -07:00 +++ edited/include/linux/rtnetlink.h 2004-09-09 10:10:08 -07:00 @@ -660,10 +660,6 @@ #define TCA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct tcmsg)) -/* SUMMARY: maximal rtattr understood by kernel */ - -#define RTATTR_MAX RTA_MAX - /* RTnetlink multicast groups */ #define RTMGRP_LINK 1 ===== net/core/rtnetlink.c 1.24 vs edited ===== --- 1.24/net/core/rtnetlink.c 2004-09-02 13:12:43 -07:00 +++ edited/net/core/rtnetlink.c 2004-09-09 10:08:44 -07:00 @@ -401,6 +401,10 @@ return 0; } +/* Protected by RTNL sempahore. */ +static struct rtattr **rta_buf; +static int rtattr_max; + /* Process one rtnetlink message. */ static __inline__ int @@ -408,8 +412,6 @@ { struct rtnetlink_link *link; struct rtnetlink_link *link_tab; - struct rtattr *rta[RTATTR_MAX]; - int sz_idx, kind; int min_len; int family; @@ -476,7 +478,7 @@ return -1; } - memset(&rta, 0, sizeof(rta)); + memset(rta_buf, 0, (rtattr_max * sizeof(struct rtattr *))); min_len = rtm_min[sz_idx]; if (nlh->nlmsg_len < min_len) @@ -491,7 +493,7 @@ if (flavor) { if (flavor > rta_max[sz_idx]) goto err_inval; - rta[flavor-1] = attr; + rta_buf[flavor-1] = attr; } attr = RTA_NEXT(attr, attrlen); } @@ -501,7 +503,7 @@ link = &(rtnetlink_links[PF_UNSPEC][type]); if (link->doit == NULL) goto err_inval; - err = link->doit(skb, nlh, (void *)&rta); + err = link->doit(skb, nlh, (void *)&rta_buf[0]); *errp = err; return err; @@ -621,6 +623,16 @@ void __init rtnetlink_init(void) { + int i; + + rtattr_max = 0; + for (i = 0; i < ARRAY_SIZE(rta_max); i++) + if (rta_max[i] > rtattr_max) + rtattr_max = rta_max[i]; + rta_buf = kmalloc(rtattr_max * sizeof(struct rtattr *), GFP_KERNEL); + if (!rta_buf) + panic("rtnetlink_init: cannot allocate rta_buf\n"); + rtnl = netlink_kernel_create(NETLINK_ROUTE, rtnetlink_rcv); if (rtnl == NULL) panic("rtnetlink_init: cannot initialize rtnetlink\n"); From davem@davemloft.net Thu Sep 9 10:34:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:34:23 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HYIFb007908 for ; Thu, 9 Sep 2004 10:34:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5Snp-00037w-00; Thu, 09 Sep 2004 10:33:45 -0700 Date: Thu, 9 Sep 2004 10:33:44 -0700 From: "David S. Miller" To: Thomas Graf Cc: hadi@cyberus.ca, shemminger@osdl.org, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-Id: <20040909103344.5a448b01.davem@davemloft.net> In-Reply-To: <20040909164834.GB18994@postel.suug.ch> References: <20040909164834.GB18994@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 451 Lines: 13 On Thu, 9 Sep 2004 18:48:34 +0200 Thomas Graf wrote: > - Convert mtu and txqlen to use rtnetlink instead of ioctl. > - Introduces weight. > - Updates local copy of rtnetlink.h. > > Against iproute2-2.6.9-jamal, tested and working. > Will look into remaining ioctls later. Please don't blindly update rtnetlink.h in iproute2 with the current kernel copy. The "__KERNEL__" ifdef area is omitted on purpose, yet you added it back in. From tgraf@suug.ch Thu Sep 9 10:49:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:49:38 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HnXkv008630 for ; Thu, 9 Sep 2004 10:49:33 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 1BF5C81; Thu, 9 Sep 2004 19:49:01 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 2C9B81C0E7; Thu, 9 Sep 2004 19:49:43 +0200 (CEST) Date: Thu, 9 Sep 2004 19:49:43 +0200 From: Thomas Graf To: "David S. Miller" Cc: hadi@cyberus.ca, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Adjust RTATTR_MAX to IFLA_* changes Message-ID: <20040909174943.GA19155@postel.suug.ch> References: <20040909163131.GA18951@postel.suug.ch> <20040909103149.248a603e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909103149.248a603e.davem@davemloft.net> X-archive-position: 8569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 748 Lines: 20 * David S. Miller <20040909103149.248a603e.davem@davemloft.net> 2004-09-09 10:31 > On Thu, 9 Sep 2004 18:31:31 +0200 > Thomas Graf wrote: > > > IFLA_MAX is now bigger than RTA_MAX with the latest changes in IFLA_*. > > Adjust RTATTR to point to IFLA_MAX to have big enough buffer in > > rtnetlink_rcv_msg. > > Ok, this is going to get silly if some other attribute gets > larger than IFLA_* next. > > We should just compute this thing at run time. > Else, if the macro can't be deleted because there > are non-trivial other uses, use some expression > involving max(). > > I just checked iproute2 sources and it does not reference > this thing, so probably best to kill it off, like so. This is even better, works fine for me. From davem@davemloft.net Thu Sep 9 10:53:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:53:54 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89HrnXA009090 for ; Thu, 9 Sep 2004 10:53:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5T6i-0003Ap-00; Thu, 09 Sep 2004 10:53:16 -0700 Date: Thu, 9 Sep 2004 10:53:16 -0700 From: "David S. Miller" To: Thomas Graf Cc: hadi@cyberus.ca, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Adjust RTATTR_MAX to IFLA_* changes Message-Id: <20040909105316.7a013c1b.davem@davemloft.net> In-Reply-To: <20040909174943.GA19155@postel.suug.ch> References: <20040909163131.GA18951@postel.suug.ch> <20040909103149.248a603e.davem@davemloft.net> <20040909174943.GA19155@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 360 Lines: 11 On Thu, 9 Sep 2004 19:49:43 +0200 Thomas Graf wrote: > * David S. Miller <20040909103149.248a603e.davem@davemloft.net> 2004-09-09 10:31 > > I just checked iproute2 sources and it does not reference > > this thing, so probably best to kill it off, like so. > > This is even better, works fine for me. Great, this is what I'll push upstream. From tgraf@suug.ch Thu Sep 9 10:54:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 10:54:07 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89Hs1h2009154 for ; Thu, 9 Sep 2004 10:54:02 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id B775B81; Thu, 9 Sep 2004 19:53:29 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id BAC5B1C0E7; Thu, 9 Sep 2004 19:54:11 +0200 (CEST) Date: Thu, 9 Sep 2004 19:54:11 +0200 From: Thomas Graf To: "David S. Miller" Cc: hadi@cyberus.ca, shemminger@osdl.org, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-ID: <20040909175411.GB19155@postel.suug.ch> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909103344.5a448b01.davem@davemloft.net> X-archive-position: 8571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 5932 Lines: 225 * David S. Miller <20040909103344.5a448b01.davem@davemloft.net> 2004-09-09 10:33 > On Thu, 9 Sep 2004 18:48:34 +0200 > Thomas Graf wrote: > > > - Convert mtu and txqlen to use rtnetlink instead of ioctl. > > - Introduces weight. > > - Updates local copy of rtnetlink.h. > > > > Against iproute2-2.6.9-jamal, tested and working. > > Will look into remaining ioctls later. > > Please don't blindly update rtnetlink.h in iproute2 with > the current kernel copy. The "__KERNEL__" ifdef area > is omitted on purpose, yet you added it back in. Sorry, included old patch, this is a correct one: diff -Nru iproute2-2.6.9-jamal.orig/include/linux/rtnetlink.h iproute2-2.6.9-jamal/include/linux/rtnetlink.h --- iproute2-2.6.9-jamal.orig/include/linux/rtnetlink.h 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/include/linux/rtnetlink.h 2004-09-09 19:46:26.000000000 +0200 @@ -561,6 +561,12 @@ #define IFLA_WIRELESS IFLA_WIRELESS IFLA_PROTINFO, /* Protocol specific information for a link */ #define IFLA_PROTINFO IFLA_PROTINFO + IFLA_TXQLEN, +#define IFLA_TXQLEN IFLA_TXQLEN + IFLA_MAP, +#define IFLA_MAP IFLA_MAP + IFLA_WEIGHT, +#define IFLA_WEIGHT IFLA_WEIGHT __IFLA_MAX }; diff -Nru iproute2-2.6.9-jamal.orig/ip/ipaddress.c iproute2-2.6.9-jamal/ip/ipaddress.c --- iproute2-2.6.9-jamal.orig/ip/ipaddress.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/ip/ipaddress.c 2004-09-08 19:57:30.000000000 +0200 @@ -182,6 +182,8 @@ fprintf(fp, "mtu %u ", *(int*)RTA_DATA(tb[IFLA_MTU])); if (tb[IFLA_QDISC]) fprintf(fp, "qdisc %s ", (char*)RTA_DATA(tb[IFLA_QDISC])); + if (tb[IFLA_WEIGHT]) + fprintf(fp, "weight %u ", *(uint32_t*)RTA_DATA(tb[IFLA_WEIGHT])); #ifdef IFLA_MASTER if (tb[IFLA_MASTER]) { SPRINT_BUF(b1); diff -Nru iproute2-2.6.9-jamal.orig/ip/iplink.c iproute2-2.6.9-jamal/ip/iplink.c --- iproute2-2.6.9-jamal.orig/ip/iplink.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/ip/iplink.c 2004-09-09 19:50:51.000000000 +0200 @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -46,7 +47,8 @@ fprintf(stderr, " txqueuelen PACKETS |\n"); fprintf(stderr, " name NEWNAME |\n"); fprintf(stderr, " address LLADDR | broadcast LLADDR |\n"); - fprintf(stderr, " mtu MTU }\n"); + fprintf(stderr, " mtu MTU |\n"); + fprintf(stderr, " weight WEIGHT }\n"); fprintf(stderr, " ip link show [ DEVICE ]\n"); exit(-1); } @@ -130,50 +132,6 @@ return err; } -static int set_qlen(char *dev, int qlen) -{ - struct ifreq ifr; - int s; - - s = get_ctl_fd(); - if (s < 0) - return -1; - - memset(&ifr, 0, sizeof(ifr)); - strcpy(ifr.ifr_name, dev); - ifr.ifr_qlen = qlen; - if (ioctl(s, SIOCSIFTXQLEN, &ifr) < 0) { - perror("SIOCSIFXQLEN"); - close(s); - return -1; - } - close(s); - - return 0; -} - -static int set_mtu(char *dev, int mtu) -{ - struct ifreq ifr; - int s; - - s = get_ctl_fd(); - if (s < 0) - return -1; - - memset(&ifr, 0, sizeof(ifr)); - strcpy(ifr.ifr_name, dev); - ifr.ifr_mtu = mtu; - if (ioctl(s, SIOCSIFMTU, &ifr) < 0) { - perror("SIOCSIFMTU"); - close(s); - return -1; - } - close(s); - - return 0; -} - static int get_address(char *dev, int *htype) { struct ifreq ifr; @@ -249,19 +207,39 @@ return 0; } +struct link_request +{ + struct nlmsghdr nl_msg; + struct ifinfomsg ifi; + char buf[256]; +}; + static int do_set(int argc, char **argv) { char *dev = NULL; __u32 mask = 0; __u32 flags = 0; - int qlen = -1; - int mtu = -1; + int32_t qlen = -1; + int32_t mtu = -1; + int32_t weight = -1; char *newaddr = NULL; char *newbrd = NULL; struct ifreq ifr0, ifr1; char *newname = NULL; int htype, halen; + struct rtnl_handle rth; + + struct link_request req = { + .nl_msg = { + .nlmsg_type = RTM_SETLINK, + .nlmsg_flags = NLM_F_REQUEST, + .nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)), + }, + .ifi = { + .ifi_family = PF_PACKET, + }, + }; while (argc > 0) { if (strcmp(*argv, "up") == 0) { @@ -288,12 +266,14 @@ duparg("txqueuelen", *argv); if (get_integer(&qlen, *argv, 0)) invarg("Invalid \"txqueuelen\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_TXQLEN, &qlen, sizeof(qlen)); } else if (strcmp(*argv, "mtu") == 0) { NEXT_ARG(); if (mtu != -1) duparg("mtu", *argv); if (get_integer(&mtu, *argv, 0)) invarg("Invalid \"mtu\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_MTU, &mtu, sizeof(mtu)); } else if (strcmp(*argv, "multicast") == 0) { NEXT_ARG(); mask |= IFF_MULTICAST; @@ -339,6 +319,13 @@ flags |= IFF_NOARP; } else return on_off("noarp"); + } else if (matches(*argv, "weight") == 0) { + NEXT_ARG(); + if (weight != -1) + duparg("weight", *argv); + if (get_integer(&weight, *argv, 0)) + invarg("Invalid \"weight\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_WEIGHT, &weight, sizeof(weight)); #ifdef IFF_DYNAMIC } else if (matches(*argv, "dynamic") == 0) { NEXT_ARG(); @@ -387,14 +374,6 @@ return -1; dev = newname; } - if (qlen != -1) { - if (set_qlen(dev, qlen) < 0) - return -1; - } - if (mtu != -1) { - if (set_mtu(dev, mtu) < 0) - return -1; - } if (newaddr || newbrd) { if (newbrd) { if (set_address(&ifr1, 1) < 0) @@ -407,6 +386,20 @@ } if (mask) return do_chflags(dev, flags, mask); + + if (rtnl_open(&rth, 0) < 0) + exit(1); + + ll_init_map(&rth); + + if ((req.ifi.ifi_index = ll_name_to_index(dev)) == 0) { + fprintf(stderr, "Cannot find device \"%s\"\n", dev); + return -1; + } + + if (rtnl_talk(&rth, &req.nl_msg, 0, 0, NULL, NULL, NULL) < 0) + exit(2); + return 0; } From Adam.Lewis@motorola.com Thu Sep 9 11:07:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 11:07:24 -0700 (PDT) Received: from motgate6.mot.com (motgate6.mot.com [144.189.100.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89I7DnX010331 for ; Thu, 9 Sep 2004 11:07:14 -0700 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i89I74Ma026967 for ; Thu, 9 Sep 2004 11:07:04 -0700 (MST) Received: from il02exm12.corp.mot.com (il02exm12.corp.mot.com [10.0.111.23]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i89I4xMq003974 for ; Thu, 9 Sep 2004 13:04:59 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Sep 2004 13:07:03 -0500 Message-ID: From: Lewis Adam-CAL022 To: netdev@oss.sgi.com Subject: Processor off in La-La land Date: Thu, 9 Sep 2004 13:07:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 8572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Adam.Lewis@motorola.com Precedence: bulk X-list: netdev Content-Length: 613 Lines: 9 Hi all, I am writing a WLAN driver and every now and then Linux hangs (no oops). I hooked up a jtag device in an effort to determine where the code was getting deadlocked. However what I saw was that the CPU was not even looking at my code (or any Linux code for that matter) but was somewhere off in the weeds. Can somebody shed some light on what type of condition could cause such a a corruption of the stack? The only one I can think of is doing a memcpy beyond the bounds of an array allocated on the stack, but to the best of my debugging I cannot find a case where that would happen. Thanks! Adam From Adam.Lewis@motorola.com Thu Sep 9 15:10:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 15:10:23 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89MAHUh021461 for ; Thu, 9 Sep 2004 15:10:17 -0700 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i89MA7Z0017295 for ; Thu, 9 Sep 2004 15:10:07 -0700 (MST) Received: from il02exm12.corp.mot.com (il02exm12.corp.mot.com [10.0.111.23]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i89M9pSh018642 for ; Thu, 9 Sep 2004 17:09:51 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Sep 2004 17:10:06 -0500 Message-ID: From: Lewis Adam-CAL022 To: netdev@oss.sgi.com Subject: hard_start_xmit and Linux bridging Date: Thu, 9 Sep 2004 17:10:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 8573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Adam.Lewis@motorola.com Precedence: bulk X-list: netdev Content-Length: 802 Lines: 10 Hi all, I tried going to the bridge@lists.osdl.org for this question but got no response, I'm hoping somebody here has had a similar experience as me. Basically, I put my wlan0 driver in a bridge with eth0. When my hard_start_xmit() function is called (as a result of a packet received on eth0 and bridged to my driver), the skb that I am passed contains an extra four bytes (e.g. the Ethernet FCS). In my mind, this should be stripped off. But I have looked at all the open source net drivers I could find and nobody seems to care. Is there a way to know if the skb has been forwarded by a bridged interface? If I forward on the extra bytes, then a 1500 byte packet becomes 1504 and fails the MTU check on the other side of the wireless interface (when it is passed back to eth0). TIA, Adam From romieu@fr.zoreil.com Thu Sep 9 15:46:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 15:47:01 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89MkrMM023004 for ; Thu, 9 Sep 2004 15:46:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i89Mjevr010143; Fri, 10 Sep 2004 00:45:40 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i89Mjd2R010142; Fri, 10 Sep 2004 00:45:39 +0200 Date: Fri, 10 Sep 2004 00:45:39 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc1-mm4 1/4] r8169: miscalculation of available Tx descriptors Message-ID: <20040909224539.GA9629@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1716 Lines: 54 The count of available entries in the Tx descriptors ring is badly wrong. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-130 drivers/net/r8169.c --- linux-2.6.9-rc1/drivers/net/r8169.c~r8169-130 2004-09-08 22:02:35.000000000 +0200 +++ linux-2.6.9-rc1-fr/drivers/net/r8169.c 2004-09-08 22:02:35.000000000 +0200 @@ -77,6 +77,9 @@ VERSION 1.6LK <2004/04/14> #define dprintk(fmt, args...) do {} while (0) #endif /* RTL8169_DEBUG */ +#define TX_BUFFS_AVAIL(tp) \ + (tp->dirty_tx + NUM_TX_DESC - tp->cur_tx - 1) + #ifdef CONFIG_R8169_NAPI #define rtl8169_rx_skb netif_receive_skb #define rtl8169_rx_hwaccel_skb vlan_hwaccel_rx @@ -1766,8 +1769,7 @@ static int rtl8169_start_xmit(struct sk_ u32 status, len; u32 opts1; - if (unlikely(tp->cur_tx - tp->dirty_tx < skb_shinfo(skb)->nr_frags)) { - netif_stop_queue(dev); + if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) { printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); return 1; @@ -1816,10 +1818,10 @@ static int rtl8169_start_xmit(struct sk_ RTL_W8(TxPoll, 0x40); //set polling bit - if (tp->cur_tx - tp->dirty_tx < MAX_SKB_FRAGS) { + if (TX_BUFFS_AVAIL(tp) < MAX_SKB_FRAGS) { netif_stop_queue(dev); smp_rmb(); - if (tp->cur_tx - tp->dirty_tx >= MAX_SKB_FRAGS) + if (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS) netif_wake_queue(dev); } @@ -1874,8 +1876,10 @@ rtl8169_tx_interrupt(struct net_device * if (tp->dirty_tx != dirty_tx) { tp->dirty_tx = dirty_tx; smp_wmb(); - if (netif_queue_stopped(dev)) + if (netif_queue_stopped(dev) && + (TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) { netif_wake_queue(dev); + } } } _ From romieu@fr.zoreil.com Thu Sep 9 15:50:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 15:51:00 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89Mortw023355 for ; Thu, 9 Sep 2004 15:50:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i89Mnlvr010205; Fri, 10 Sep 2004 00:49:47 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i89Mnlai010204; Fri, 10 Sep 2004 00:49:47 +0200 Date: Fri, 10 Sep 2004 00:49:47 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc1-mm4 3/4] r8169: TSO support. Message-ID: <20040909224947.GB10144@electric-eye.fr.zoreil.com> References: <20040909224539.GA9629@electric-eye.fr.zoreil.com> <20040909224817.GA10144@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909224817.GA10144@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2018 Lines: 63 TSO support. Suggestion of Jeff Garzik. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-160 drivers/net/r8169.c --- linux-2.6.9-rc1/drivers/net/r8169.c~r8169-160 2004-09-08 22:53:47.000000000 +0200 +++ linux-2.6.9-rc1-fr/drivers/net/r8169.c 2004-09-08 22:53:47.000000000 +0200 @@ -323,6 +323,9 @@ enum _DescStatusBit { LastFrag = (1 << 28), /* Final segment of a packet */ /* Tx private */ + LargeSend = (1 << 27), /* TCP Large Send Offload (TSO) */ + MSSShift = 16, /* MSS value position */ + MSSMask = 0xfff, /* MSS value + LargeSend bit: 12 bits */ IPCS = (1 << 18), /* Calculate IP checksum */ UDPCS = (1 << 17), /* Calculate UDP/IP checksum */ TCPCS = (1 << 16), /* Calculate TCP/IP checksum */ @@ -844,6 +847,8 @@ static struct ethtool_ops rtl8169_ethtoo .set_tx_csum = ethtool_op_set_tx_csum, .get_sg = ethtool_op_get_sg, .set_sg = ethtool_op_set_sg, + .get_tso = ethtool_op_get_tso, + .set_tso = ethtool_op_set_tso, .get_regs = rtl8169_get_regs, }; @@ -1745,8 +1750,14 @@ static int rtl8169_xmit_frags(struct rtl return cur_frag; } -static inline u32 rtl8169_tx_csum(struct sk_buff *skb) +static inline u32 rtl8169_tso_csum(struct sk_buff *skb, struct net_device *dev) { + if (dev->features & NETIF_F_TSO) { + u32 mss = skb_shinfo(skb)->tso_size; + + if (mss) + return LargeSend | ((mss & MSSMask) << MSSShift); + } if (skb->ip_summed == CHECKSUM_HW) { const struct iphdr *ip = skb->nh.iph; @@ -1754,7 +1765,7 @@ static inline u32 rtl8169_tx_csum(struct return IPCS | TCPCS; else if (ip->protocol == IPPROTO_UDP) return IPCS | UDPCS; - BUG(); + WARN_ON(1); /* we need a WARN() */ } return 0; } @@ -1779,7 +1790,7 @@ static int rtl8169_start_xmit(struct sk_ if (unlikely(le32_to_cpu(txd->opts1) & DescOwn)) goto err_stop; - opts1 = DescOwn | rtl8169_tx_csum(skb); + opts1 = DescOwn | rtl8169_tso_csum(skb, dev); frags = rtl8169_xmit_frags(tp, skb, opts1); if (frags) { _ From romieu@fr.zoreil.com Thu Sep 9 15:50:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 15:50:59 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89MorCO023354 for ; Thu, 9 Sep 2004 15:50:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i89MmHvr010200; Fri, 10 Sep 2004 00:48:17 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i89MmHEu010199; Fri, 10 Sep 2004 00:48:17 +0200 Date: Fri, 10 Sep 2004 00:48:17 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc1-mm4 2/4] r8169: hint for Tx flow control Message-ID: <20040909224817.GA10144@electric-eye.fr.zoreil.com> References: <20040909224539.GA9629@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909224539.GA9629@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1086 Lines: 44 return 1 in start_xmit() when the required descriptors are not available and wait for more room. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-140 drivers/net/r8169.c --- linux-2.6.9-rc1/drivers/net/r8169.c~r8169-140 2004-09-08 22:02:53.000000000 +0200 +++ linux-2.6.9-rc1-fr/drivers/net/r8169.c 2004-09-08 22:04:04.000000000 +0200 @@ -1768,15 +1768,16 @@ static int rtl8169_start_xmit(struct sk_ dma_addr_t mapping; u32 status, len; u32 opts1; + int ret = 0; if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) { printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", dev->name); - return 1; + goto err_stop; } if (unlikely(le32_to_cpu(txd->opts1) & DescOwn)) - goto err_drop; + goto err_stop; opts1 = DescOwn | rtl8169_tx_csum(skb); @@ -1826,10 +1827,11 @@ static int rtl8169_start_xmit(struct sk_ } out: - return 0; + return ret; -err_drop: - dev_kfree_skb(skb); +err_stop: + netif_stop_queue(dev); + ret = 1; err_update_stats: tp->stats.tx_dropped++; goto out; _ From romieu@fr.zoreil.com Thu Sep 9 15:54:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 15:55:01 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89Mss1q024096 for ; Thu, 9 Sep 2004 15:54:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i89Mqmvr010324; Fri, 10 Sep 2004 00:52:48 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i89MqlRA010323; Fri, 10 Sep 2004 00:52:47 +0200 Date: Fri, 10 Sep 2004 00:52:47 +0200 From: Francois Romieu To: Jeff Garzik Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc1-mm4 4/4] r8169: Mac identifier extracted from Realtek's driver v2.2 Message-ID: <20040909225247.GC10144@electric-eye.fr.zoreil.com> References: <20040909224539.GA9629@electric-eye.fr.zoreil.com> <20040909224817.GA10144@electric-eye.fr.zoreil.com> <20040909224947.GB10144@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909224947.GB10144@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 901 Lines: 28 Mac identifier extracted from Realtek's driver v2.2. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-170 drivers/net/r8169.c --- linux-2.6.9-rc1/drivers/net/r8169.c~r8169-170 2004-09-08 22:55:42.000000000 +0200 +++ linux-2.6.9-rc1-fr/drivers/net/r8169.c 2004-09-08 23:31:09.000000000 +0200 @@ -136,7 +136,8 @@ enum mac_version { RTL_GIGA_MAC_VER_B = 0x00, /* RTL_GIGA_MAC_VER_C = 0x03, */ RTL_GIGA_MAC_VER_D = 0x01, - RTL_GIGA_MAC_VER_E = 0x02 + RTL_GIGA_MAC_VER_E = 0x02, + RTL_GIGA_MAC_VER_X = 0x04 /* Greater than RTL_GIGA_MAC_VER_E */ }; enum phy_version { @@ -869,6 +870,7 @@ static void rtl8169_get_mac_version(stru u32 mask; int mac_version; } mac_info[] = { + { 0x1 << 28, RTL_GIGA_MAC_VER_X }, { 0x1 << 26, RTL_GIGA_MAC_VER_E }, { 0x1 << 23, RTL_GIGA_MAC_VER_D }, { 0x00000000, RTL_GIGA_MAC_VER_B } /* Catch-all */ _ From greearb@candelatech.com Thu Sep 9 16:30:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 16:30:28 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89NUNH6028001 for ; Thu, 9 Sep 2004 16:30:23 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i89NVwLH031775; Thu, 9 Sep 2004 16:31:59 -0700 Message-ID: <4140E782.2000505@candelatech.com> Date: Thu, 09 Sep 2004 16:30:10 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lewis Adam-CAL022 CC: netdev@oss.sgi.com Subject: Re: hard_start_xmit and Linux bridging References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1261 Lines: 27 Lewis Adam-CAL022 wrote: > Hi all, > > I tried going to the bridge@lists.osdl.org for this question but got no response, I'm hoping somebody here has had a similar experience as me. > > Basically, I put my wlan0 driver in a bridge with eth0. When my hard_start_xmit() function is called (as a result of a packet received on eth0 and bridged to my driver), the skb that I am passed contains an extra four bytes (e.g. the Ethernet FCS). > > In my mind, this should be stripped off. But I have looked at all the open source net drivers I could find and nobody seems to care. Is there a way to know if the skb has been forwarded by a bridged interface? If I forward on the extra bytes, then a 1500 byte packet becomes 1504 and fails the MTU check on the other side of the wireless interface (when it is passed back to eth0). > > TIA, > Adam I added some ioctls to allow one to turn on the ability to receive the CRC, but I don't know of any drivers that include it by default. What driver/hardware is your eth0 device? How are you determining the size, by the skb->len ? Does tcpdump/ethereal show the extra 4 bytes if you sniff eth0 w/out bridging? Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From max@stro.at Thu Sep 9 16:41:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 16:41:07 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i89Nf2R7028644 for ; Thu, 9 Sep 2004 16:41:02 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id DF9C35C067; Fri, 10 Sep 2004 01:40:49 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30310-02; Fri, 10 Sep 2004 01:40:49 +0200 (CEST) Received: from sputnik (M932P013.adsl.highway.telekom.at [62.47.148.109]) by baikonur.stro.at (Postfix) with ESMTP id 339795C008; Fri, 10 Sep 2004 01:40:49 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1C5YX5-0006B6-3O; Fri, 10 Sep 2004 01:40:51 +0200 Date: Fri, 10 Sep 2004 01:40:50 +0200 From: maks attems To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [patch] compile fix 3c59x for eisa without pci Message-ID: <20040909234050.GK1927@stro.at> Mail-Followup-To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 8579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1880 Lines: 54 drivers/net/3c59x.c: In function `vortex_ioctl': drivers/net/3c59x.c:2916: warning: dereferencing `void *' pointer drivers/net/3c59x.c:2916: error: request for member `current_state' in something not a structure or union make[3]: *** [drivers/net/3c59x.o] Error 1 make[2]: *** [drivers/net] Error 2 make[1]: *** [drivers] Error 2 make: *** [stamp-build] Error 2 # CONFIG_PCI is not set CONFIG_EISA=y compile fix below, quite an ugly addition of ifdefs. please tell me if better method exists. --- kernel-source-2.6.8/drivers/net/3c59x.c 2004-08-14 07:36:10.000000000 +0200 +++ b/drivers/net/3c59x.c 2004-09-10 01:29:14.000000000 +0200 @@ -900,7 +900,9 @@ static void dump_tx_ring(struct net_devi static void update_stats(long ioaddr, struct net_device *dev); static struct net_device_stats *vortex_get_stats(struct net_device *dev); static void set_rx_mode(struct net_device *dev); +#ifdef CONFIG_PCI static int vortex_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); +#endif static void vortex_tx_timeout(struct net_device *dev); static void acpi_set_WOL(struct net_device *dev); static struct ethtool_ops vortex_ethtool_ops; @@ -1468,7 +1470,9 @@ static int __devinit vortex_probe1(struc dev->stop = vortex_close; dev->get_stats = vortex_get_stats; +#ifdef CONFIG_PCI dev->do_ioctl = vortex_ioctl; +#endif dev->ethtool_ops = &vortex_ethtool_ops; dev->set_multicast_list = set_rx_mode; dev->tx_timeout = vortex_tx_timeout; @@ -2868,6 +2872,7 @@ static struct ethtool_ops vortex_ethtool .get_drvinfo = vortex_get_drvinfo, }; +#ifdef CONFIG_PCI static int vortex_do_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct vortex_private *vp = netdev_priv(dev); @@ -2925,6 +2930,7 @@ static int vortex_ioctl(struct net_devic return err; } +#endif /* Pre-Cyclone chips have no documented multicast filter, so the only From herbert@gondor.apana.org.au Thu Sep 9 17:32:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 17:32:25 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A0WH3I030130 for ; Thu, 9 Sep 2004 17:32:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5ZKb-0002qV-00; Fri, 10 Sep 2004 10:32:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5ZKY-0006b7-00; Fri, 10 Sep 2004 10:31:58 +1000 Date: Fri, 10 Sep 2004 10:31:58 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-ID: <20040910003158.GA25335@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> <20040909044336.GA19999@gondor.apana.org.au> <20040908214926.51b56a66.davem@davemloft.net> <20040909045415.GA20079@gondor.apana.org.au> <20040908220802.1c25b806.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040908220802.1c25b806.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 834 Lines: 26 On Wed, Sep 08, 2004 at 10:08:02PM -0700, David S. Miller wrote: > > > > I would expect a change for that to occur in net/ipv4/ipip.c > > > or similar. :) > > > > OK, I'll take a look at this. I presume that the TOS options > > in ip6tunnel.c is to your liking? > > It looks fine. Hmm, perhaps I'm still confused. But it seems that the ability to set the TOS to any value other than *1 is already there for ipip/ip_gre. That feature is missing for SIT and IPsec though. We may also want to use the TOS value from parms to decide whether we want to encapsulate/decapsulate ECN. Is my understanding correct? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@wide.ad.jp Thu Sep 9 18:32:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 18:33:00 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A1Wqg8032408 for ; Thu, 9 Sep 2004 18:32:55 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id B0F4333CE6; Fri, 10 Sep 2004 10:33:46 +0900 (JST) Date: Fri, 10 Sep 2004 10:33:41 +0900 (JST) Message-Id: <20040910.103341.28767986.yoshfuji@wide.ad.jp> To: tgraf@suug.ch Cc: davem@davemloft.net, hadi@cyberus.ca, shemminger@osdl.org, eric.lemoine@gmail.com, netdev@oss.sgi.com, yoshfuji@wide.ad.jp Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040909175411.GB19155@postel.suug.ch> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> <20040909175411.GB19155@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 987 Lines: 25 In article <20040909175411.GB19155@postel.suug.ch> (at Thu, 9 Sep 2004 19:54:11 +0200), Thomas Graf says: > * David S. Miller <20040909103344.5a448b01.davem@davemloft.net> 2004-09-09 10:33 > > On Thu, 9 Sep 2004 18:48:34 +0200 > > Thomas Graf wrote: > > > > > - Convert mtu and txqlen to use rtnetlink instead of ioctl. > > > - Introduces weight. > > > - Updates local copy of rtnetlink.h. > > > > > > Against iproute2-2.6.9-jamal, tested and working. > > > Will look into remaining ioctls later. > > > > Please don't blindly update rtnetlink.h in iproute2 with > > the current kernel copy. The "__KERNEL__" ifdef area > > is omitted on purpose, yet you added it back in. > > Sorry, included old patch, this is a correct one: Well, I think we should maintain old ioctl path for backward compatibility. (or ifdefs at least.) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Sep 9 18:47:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 18:47:47 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A1lfQL001002 for ; Thu, 9 Sep 2004 18:47:41 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 99C6633CE6; Fri, 10 Sep 2004 10:48:35 +0900 (JST) Date: Fri, 10 Sep 2004 10:48:30 +0900 (JST) Message-Id: <20040910.104830.121402882.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: pekkas@netcore.fi, netdev@oss.sgi.com, kunitake@linux-ipv6.org, yoshfuji@linux-ipv6.org, aesop-core@kame.net Subject: [PATCH] IPV6: Deprecate All-on-link Assumption From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1493 Lines: 49 Hello. If we don't have IPv6 default routes, we assume all ipv6 destinations are on-link as specified in RFC2461. It, however, is considered harmful now; it is problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (eg no default routers) and such nodes will take a few seconds until they fall back to use IPv4. See for details. Thanks. From: KUNITAKE Koichi Signed-off-by: KUNITAKE Koichi Signed-off-by: YOSHIFUJI Hideaki ===== net/ipv6/addrconf.c 1.106 vs edited ===== --- 1.106/net/ipv6/addrconf.c 2004-08-17 11:25:06 +09:00 +++ edited/net/ipv6/addrconf.c 2004-09-10 01:49:17 +09:00 @@ -2107,21 +2107,13 @@ ndisc_send_rs(ifp->idev->dev, &ifp->addr, &all_routers); } else { - struct in6_rtmsg rtmsg; - spin_unlock(&ifp->lock); - + /* + * Note: we do not support deprecated "all on-link" + * assumption any longer. + */ printk(KERN_DEBUG "%s: no IPv6 routers present\n", ifp->idev->dev->name); - - memset(&rtmsg, 0, sizeof(struct in6_rtmsg)); - rtmsg.rtmsg_type = RTMSG_NEWROUTE; - rtmsg.rtmsg_metric = IP6_RT_PRIO_ADDRCONF; - rtmsg.rtmsg_flags = (RTF_ALLONLINK | RTF_DEFAULT | RTF_UP); - - rtmsg.rtmsg_ifindex = ifp->idev->dev->ifindex; - - ip6_route_add(&rtmsg, NULL, NULL); } out: -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Thu Sep 9 20:31:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 20:31:34 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A3VOET006570 for ; Thu, 9 Sep 2004 20:31:25 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5c7m-0003ne-00; Fri, 10 Sep 2004 13:30:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5c7j-0006yb-00; Fri, 10 Sep 2004 13:30:55 +1000 Date: Fri, 10 Sep 2004 13:30:55 +1000 To: Alex Riesen , "David S. Miller" Cc: linux-kernel , netdev@oss.sgi.com Subject: Re: 2.6.9-rc1+bk: assertion tcp_get_pcount failed at net/ipv4/tcp_input.c Message-ID: <20040910033055.GA26790@gondor.apana.org.au> References: <20040909111233.GA3987@steel.home> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20040909111233.GA3987@steel.home> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1586 Lines: 52 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 09, 2004 at 11:12:33AM +0000, Alex Riesen wrote: > The box froze after being left for some time (some 10 hours) unattended. > The only thing in I could find in logs was: > > Sep 8 22:30:18 steel kernel: KERNEL: assertion ((int)tcp_get_pcount(&tp->lost_out) >= 0) failed at net/ipv4/tcp_input.c (2422) > Sep 8 22:30:18 steel kernel: Leak l=4294967295 4 Looks like the factor isn't set early enough. Can you please check that you had the changeset titled [TCP]: Make sure SKB tso factor is setup early enough. from davem? If you did, then please apply the following patch and tell us what the resulting messages. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/tcp.h 1.87 vs edited ===== --- 1.87/include/net/tcp.h 2004-09-10 01:51:02 +10:00 +++ edited/include/net/tcp.h 2004-09-10 13:24:25 +10:00 @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -1195,6 +1196,7 @@ */ static inline int tcp_skb_pcount(struct sk_buff *skb) { + BUG_TRAP(TCP_SKB_CB(skb)->tso_factor); return TCP_SKB_CB(skb)->tso_factor; } --UlVJffcvxoiEqYs2-- From davem@davemloft.net Thu Sep 9 22:29:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 22:29:46 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A5TdQN008520 for ; Thu, 9 Sep 2004 22:29:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5duo-0004Lz-00; Thu, 09 Sep 2004 22:25:42 -0700 Date: Thu, 9 Sep 2004 22:25:42 -0700 From: "David S. Miller" To: Herbert Xu Cc: fork0@users.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1+bk: assertion tcp_get_pcount failed at net/ipv4/tcp_input.c Message-Id: <20040909222542.7a30c0e4.davem@davemloft.net> In-Reply-To: <20040910033055.GA26790@gondor.apana.org.au> References: <20040909111233.GA3987@steel.home> <20040910033055.GA26790@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1047 Lines: 27 On Fri, 10 Sep 2004 13:30:55 +1000 Herbert Xu wrote: > On Thu, Sep 09, 2004 at 11:12:33AM +0000, Alex Riesen wrote: > > The box froze after being left for some time (some 10 hours) unattended. > > The only thing in I could find in logs was: > > > > Sep 8 22:30:18 steel kernel: KERNEL: assertion ((int)tcp_get_pcount(&tp->lost_out) >= 0) failed at net/ipv4/tcp_input.c (2422) > > Sep 8 22:30:18 steel kernel: Leak l=4294967295 4 > > Looks like the factor isn't set early enough. Can you please check > that you had the changeset titled > > [TCP]: Make sure SKB tso factor is setup early enough. > > from davem? > > If you did, then please apply the following patch and tell us what > the resulting messages. Herbert did you see my division fix I made today for tso_factor calculation? I was dividing by the TSO mss instead of the normal one :-) I think that is the cause of these problems. It was definitely the cause of a BUG() trap hit in tcp_transmit_skb() that someone else reported in the past day. From herbert@gondor.apana.org.au Thu Sep 9 22:57:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 22:57:11 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A5v1P4009392 for ; Thu, 9 Sep 2004 22:57:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5eOi-0004LG-00; Fri, 10 Sep 2004 15:56:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5eOf-0007AQ-00; Fri, 10 Sep 2004 15:56:33 +1000 Date: Fri, 10 Sep 2004 15:56:33 +1000 To: "David S. Miller" Cc: fork0@users.sourceforge.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1+bk: assertion tcp_get_pcount failed at net/ipv4/tcp_input.c Message-ID: <20040910055633.GA27539@gondor.apana.org.au> References: <20040909111233.GA3987@steel.home> <20040910033055.GA26790@gondor.apana.org.au> <20040909222542.7a30c0e4.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909222542.7a30c0e4.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 443 Lines: 12 On Thu, Sep 09, 2004 at 10:25:42PM -0700, David S. Miller wrote: > > Herbert did you see my division fix I made today for > tso_factor calculation? I was dividing by the TSO mss > instead of the normal one :-) That would do it :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Thu Sep 9 23:30:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 23:30:58 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A6Uqvf010407 for ; Thu, 9 Sep 2004 23:30:52 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 7E55533CE6; Fri, 10 Sep 2004 15:31:44 +0900 (JST) Date: Fri, 10 Sep 2004 15:31:35 +0900 (JST) Message-Id: <20040910.153135.121099678.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: [PATCH] [NETFILTER] Fix "undefined reference" error if CONFIG_SYSCTL=n From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1597 Lines: 41 Hello. Fix the following error if CONFIG_SYSCTL=n. | net/built-in.o: In function `tcp_in_window': | net/built-in.o(.text+0x49571): undefined reference to `ip_ct_log_invalid' | net/built-in.o: In function `tcp_error': | net/built-in.o(.text+0x49715): undefined reference to `ip_ct_log_invalid' | net/built-in.o(.text+0x49756): undefined reference to `ip_ct_log_invalid' | net/built-in.o(.text+0x497f1): undefined reference to `ip_ct_log_invalid' | net/built-in.o(.text+0x49823): undefined reference to `ip_ct_log_invalid' | net/built-in.o(.text+0x49998): more undefined references to `ip_ct_log_invalid' follow | make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/netfilter/ip_conntrack_standalone.c 1.40 vs edited ===== --- 1.40/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-09-01 00:27:37 +09:00 +++ edited/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-09-10 15:16:34 +09:00 @@ -48,6 +48,8 @@ extern atomic_t ip_conntrack_count; DECLARE_PER_CPU(struct ip_conntrack_stat, ip_conntrack_stat); +unsigned int ip_ct_log_invalid = 0; + static int kill_proto(const struct ip_conntrack *i, void *data) { return (i->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.protonum == @@ -522,7 +524,6 @@ extern unsigned long ip_ct_generic_timeout; /* Log invalid packets of a given protocol */ -unsigned int ip_ct_log_invalid = 0; static int log_invalid_proto_min = 0; static int log_invalid_proto_max = 255; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Sep 9 23:37:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 23:37:55 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A6bnwt010900 for ; Thu, 9 Sep 2004 23:37:49 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9FBBB33CE6; Fri, 10 Sep 2004 15:38:43 +0900 (JST) Date: Fri, 10 Sep 2004 15:38:43 +0900 (JST) Message-Id: <20040910.153843.62140098.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] [NETFILTER] Fix "undefined reference" error if CONFIG_SYSCTL=n From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040910.153135.121099678.yoshfuji@linux-ipv6.org> References: <20040910.153135.121099678.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 8587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1827 Lines: 50 In article <20040910.153135.121099678.yoshfuji@linux-ipv6.org> (at Fri, 10 Sep 2004 15:31:35 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > +unsigned int ip_ct_log_invalid = 0; > + > static int kill_proto(const struct ip_conntrack *i, void *data) > { > return (i->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.protonum == > @@ -522,7 +524,6 @@ > extern unsigned long ip_ct_generic_timeout; > > /* Log invalid packets of a given protocol */ > -unsigned int ip_ct_log_invalid = 0; > static int log_invalid_proto_min = 0; > static int log_invalid_proto_max = 255; Or, you may prefer to move related things as well. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv4/netfilter/ip_conntrack_standalone.c 1.40 vs edited ===== --- 1.40/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-09-01 00:27:37 +09:00 +++ edited/net/ipv4/netfilter/ip_conntrack_standalone.c 2004-09-10 15:32:44 +09:00 @@ -48,6 +48,11 @@ extern atomic_t ip_conntrack_count; DECLARE_PER_CPU(struct ip_conntrack_stat, ip_conntrack_stat); +/* Log invalid packets of a given protocol */ +unsigned int ip_ct_log_invalid = 0; +static int log_invalid_proto_min = 0; +static int log_invalid_proto_max = 255; + static int kill_proto(const struct ip_conntrack *i, void *data) { return (i->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.protonum == @@ -520,11 +525,6 @@ /* From ip_conntrack_proto_icmp.c */ extern unsigned long ip_ct_generic_timeout; - -/* Log invalid packets of a given protocol */ -unsigned int ip_ct_log_invalid = 0; -static int log_invalid_proto_min = 0; -static int log_invalid_proto_max = 255; static struct ctl_table_header *ip_ct_sysctl_header; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From niv@us.ibm.com Thu Sep 9 23:40:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 09 Sep 2004 23:40:20 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A6eEKj011248 for ; Thu, 9 Sep 2004 23:40:14 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (sccrmhc12) with ESMTP id <2004091006395701200idbfne>; Fri, 10 Sep 2004 06:39:58 +0000 Message-ID: <41414C3D.2090606@us.ibm.com> Date: Thu, 09 Sep 2004 23:39:57 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , fork0@users.sourceforge.net, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1+bk: assertion tcp_get_pcount failed at net/ipv4/tcp_input.c References: <20040909111233.GA3987@steel.home> <20040910033055.GA26790@gondor.apana.org.au> <20040909222542.7a30c0e4.davem@davemloft.net> In-Reply-To: <20040909222542.7a30c0e4.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 501 Lines: 18 David S. Miller wrote: > Herbert did you see my division fix I made today for > tso_factor calculation? I was dividing by the TSO mss > instead of the normal one :-) Dave, I'm just catching up with the most recent kernel (from 2.6.8.1 and a hiatus), and I believe the fixes you refer to as well as the change in tcp_init_cwnd (tso_factor etc) make TSO consistent with the standard now. That correct? (And thanks, much appreciated, I was about to fiddle with the same stuff :)). thanks, Nivedita From herbert@gondor.apana.org.au Fri Sep 10 00:03:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 00:03:09 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A72xGF012040 for ; Fri, 10 Sep 2004 00:03:00 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5fQj-0004lQ-00; Fri, 10 Sep 2004 17:02:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5fQg-0007IA-00; Fri, 10 Sep 2004 17:02:42 +1000 Date: Fri, 10 Sep 2004 17:02:42 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-ID: <20040910070242.GA28017@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> <20040909044336.GA19999@gondor.apana.org.au> <20040908214926.51b56a66.davem@davemloft.net> <20040909045415.GA20079@gondor.apana.org.au> <20040908220802.1c25b806.davem@davemloft.net> <20040910003158.GA25335@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910003158.GA25335@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 753 Lines: 23 On Fri, Sep 10, 2004 at 10:31:58AM +1000, herbert wrote: > > Hmm, perhaps I'm still confused. But it seems that the ability to > set the TOS to any value other than *1 is already there for ipip/ip_gre. > > That feature is missing for SIT and IPsec though. > > We may also want to use the TOS value from parms to decide whether we want > to encapsulate/decapsulate ECN. > > Is my understanding correct? Obviously not. Although we've got this stuff on the transmit side, we don't do this on the receive side. I'll look into it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From francois.echantillac@ens-lyon.fr Fri Sep 10 02:08:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 02:08:35 -0700 (PDT) Received: from relaissmtp.ens-lyon.fr (pluvier.ens-lyon.fr [140.77.167.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A98T53026505 for ; Fri, 10 Sep 2004 02:08:29 -0700 Received: from mouette.ens-lyon.fr ([140.77.167.4]) by relaissmtp.ens-lyon.fr with esmtp (Exim 3.35 #1 (Debian)) id 1C5hO3-00035m-00; Fri, 10 Sep 2004 11:08:07 +0200 Received: by mouette.ens-lyon.fr (Postfix, from userid 33) id 7F54C3C61C2; Fri, 10 Sep 2004 11:08:02 +0200 (CEST) To: jab@cs.sun.ac.za Subject: Re: [Fwd: Re: question: linux TCP/IP stack implementation] Message-ID: <1094807281.41416ef16a42e@mouette.ens-lyon.fr> Date: Fri, 10 Sep 2004 11:08:01 +0200 (CEST) From: Francois Echantillac Cc: netdev References: <1094714541.15115.23.camel@poulenc.cs.sun.ac.za> In-Reply-To: <1094714541.15115.23.camel@poulenc.cs.sun.ac.za> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 82.122.11.198 X-archive-position: 8590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: francois.echantillac@ens-lyon.fr Precedence: bulk X-list: netdev Content-Length: 925 Lines: 22 > Could you direct me to any good documentation on the implementation of > the TCP/IP stack in the linux kernel. > > I'm a Msc sudent of the University of Stellenbosch, South Africa. > As an experiment I wat to replace the linux TCP implementation with a > model checked version. May i suggest you http://datatag.web.cern.ch/datatag/papers/tr-datatag-2004-1.pdf "In this technical report, we describe the structure and organization of the networking code of Linux kernel 2.4.20. This release is the first of the 2.4 branch to support network interrupt mitigation via a mechanism known as NAPI. We describe the main data structures, the sub-IP layer, the IP layer, and two transport layers: TCP and UDP. This material is meant for people who are familiar with operating systems but are not Linux kernel experts." Included a lot of helpful figures. Not sure it is what you are searching for. Hope it will help. Francois From tgraf@suug.ch Fri Sep 10 02:29:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 02:29:47 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A9TeR9027190 for ; Fri, 10 Sep 2004 02:29:40 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7F71981; Fri, 10 Sep 2004 11:29:07 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 1F25A1C0E7; Fri, 10 Sep 2004 11:29:49 +0200 (CEST) Date: Fri, 10 Sep 2004 11:29:49 +0200 From: Thomas Graf To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, hadi@cyberus.ca, shemminger@osdl.org, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-ID: <20040910092948.GB19930@postel.suug.ch> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> <20040909175411.GB19155@postel.suug.ch> <20040910.103341.28767986.yoshfuji@wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910.103341.28767986.yoshfuji@wide.ad.jp> X-archive-position: 8591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 773 Lines: 16 * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <20040910.103341.28767986.yoshfuji@wide.ad.jp> 2004-09-10 10:33 > > > On Thu, 9 Sep 2004 18:48:34 +0200 > > > Thomas Graf wrote: > > > > > > > - Convert mtu and txqlen to use rtnetlink instead of ioctl. > > > > - Introduces weight. > > > > - Updates local copy of rtnetlink.h. > Well, I think we should maintain old ioctl path for backward compatibility. > (or ifdefs at least.) I agree, however I think that the only good solution would be to have iproute2 negotiate with the kernel at runtime. I therefore suggest to consider my iproute2 patches as development only and don't include them in any releases as long as the whole 'new iproute2 with old kernel' issue, also affecting the new tc-actions, has been resolved. From shemminger@osdl.org Fri Sep 10 02:41:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 02:41:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8A9f7QZ029623 for ; Fri, 10 Sep 2004 02:41:07 -0700 Received: from linux.site (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8A9e5102779; Fri, 10 Sep 2004 02:40:05 -0700 Date: Fri, 10 Sep 2004 02:40:30 -0700 From: Stephen Hemminger To: Thomas Graf Cc: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , davem@davemloft.net, hadi@cyberus.ca, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-Id: <20040910024030.28b7c66c@linux.site> In-Reply-To: <20040910092948.GB19930@postel.suug.ch> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> <20040909175411.GB19155@postel.suug.ch> <20040910.103341.28767986.yoshfuji@wide.ad.jp> <20040910092948.GB19930@postel.suug.ch> Organization: OSDL X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 153 Lines: 2 Unless there is some compelling reason, I think that keeping the old ioctl interface for a least a year until the kernel changes become more ubiquitous. From herbert@gondor.apana.org.au Fri Sep 10 04:12:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 04:12:46 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ABCPFH003246 for ; Fri, 10 Sep 2004 04:12:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5jIt-0006jx-00; Fri, 10 Sep 2004 21:10:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5jIl-0007f4-00; Fri, 10 Sep 2004 21:10:47 +1000 Date: Fri, 10 Sep 2004 21:10:47 +1000 To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com, linux-ppp@vger.kernel.org, paulus@samba.org Subject: Re: [IPCOMP] Use per-cpu buffers Message-ID: <20040910111047.GA29330@gondor.apana.org.au> References: <20040909122202.GA3170@gondor.apana.org.au> <20040909091652.490c7833.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909091652.490c7833.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1924 Lines: 49 On Thu, Sep 09, 2004 at 09:16:52AM -0700, David S. Miller wrote: > > > With per-cpu buffers this goes down to 300K per CPU. > > That amount of space just for decompression state is > rediculious. Actually most of that space is for compression. The space for decompression is only 32K if I read the zlib comment correctly. However, due to the current crypto interface, you always have to allocate both and you have to reserve a 64K buffer just in case the packet is large. There's gotta be a better way though. What if the packet length field was 32 bits? Surely we aren't going to allocate a 4G buffer :) James, can you think of a general solution to the 64K buffer in terms of the crypto decompression interface? > A second thought is that we may not be the only part > of the kernel interested in a per-cpu zlib scratch > buffer, no? There are two other users. JFFS2 is already using one global copy accessed through a semaphore. Maybe we should move the IPCOMP processing into process context as well since it's so slow. PPP is the other user and allocates one for each device that requests for deflate compression. The problem isn't as bad for PPP as it is for IPsec because firstly PPP is less scalable anyway due to the device/process overhead. More importantly if compression allocation fails PPP can still carry on. Unfortunately for IPsec, the compression allocation is done after the negotiation so there is no room for recovery (you'll have to redo the negotiation). On a totally orthogonal topic, has any body thought of doing a PPP daemon like the IPsec daemons? That is, have one process that manages all PPP sessions. This could be useful for large L2TP servers and alike. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From xavier.droubay@laposte.net Fri Sep 10 04:23:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 04:23:48 -0700 (PDT) Received: from mx.laposte.net (mx.laposte.net [81.255.54.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ABNfl4006983 for ; Fri, 10 Sep 2004 04:23:42 -0700 Received: from laposte.net (127.0.0.1) by mx.laposte.net (7.0.028) id 41348965004521F9 for netdev@oss.sgi.com; Fri, 10 Sep 2004 13:23:26 +0200 Date: Fri, 10 Sep 2004 13:23:26 +0200 Message-Id: Subject: =?iso-8859-1?Q?3C900-COMBO_lan_minor_problem?= MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?xavier.droubay@laposte.net?=" To: "=?iso-8859-1?Q?netdev?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 82.67.184.130 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8ABNfl4006983 X-archive-position: 8594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xavier.droubay@laposte.net Precedence: bulk X-list: netdev Content-Length: 1914 Lines: 65 Hello, and sorry to bother you concerning my problems, but I am quite new in linux and don't know much about bug reportings. I got your address in vortext.txt file from kernel 2.6.8. I use the 3c59x driver for my 3COM 900 Combo Ethernet Card on a box B1. I use this card on a lan, which is a set of 2 boxes connected with a crossover cable. When I disconnect the cable for a while (about 30 seconds), or boot my box B2 after box B1, I always have to restart network '/etc/init. d/network restart' or do a 'ifconfig eth1 down ; ifconfig eth1 up' on box B1. I have double boot with windows on both boxes, and I tested with windows on box1: I had no problem to ping both boxes. I can try to generate a bug report as mentionned in file vortext.txt, but you may know this problem, that seems to have been already reproduced see page http://lists.debian. org/debian-user/2001/08/msg01564.html It is a closely related or same problem. I found on libranet site an update of the 3c59x driver for kernel greater than 2.4.23. They mentionned an eventual improvement of the driver for the problem, at page: http://libranet.com/support/2.8/0305 I tried this update, upgrading to kernel 2.4.27 on box B1, with no improvement for the problem. I cannot get the latest source driver, and don't know if improvements have been done after 2.4.23. Do you know if an improvement of this driver has been released for the problem ? Or should I set options I did not find for this module ? Even though I guess it is not directly related to my problem, tried the option "enable_wol=1" in my modules.conf file, with no effect. This is a minor problem, but I would like to know if it can be solved. I have seen that you still did a lot of work for kernel v2.6.x versions, so are there improvements for 2.6.x kerenels ? Thank you, Xavier. From hadi@cyberus.ca Fri Sep 10 06:17:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 06:17:17 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ADHAKa025587 for ; Fri, 10 Sep 2004 06:17:11 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091006182601:35752 ; Fri, 10 Sep 2004 06:18:26 -0700 Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Stephen Hemminger Cc: Thomas Graf , YOSHIFUJI "Hideaki / ?$B5HF#1QL@" , davem@davemloft.net, eric.lemoine@gmail.com, netdev@oss.sgi.com In-Reply-To: <20040910024030.28b7c66c@linux.site> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> <20040909175411.GB19155@postel.suug.ch> <20040910.103341.28767986.yoshfuji@wide.ad.jp> <20040910092948.GB19930@postel.suug.ch> <20040910024030.28b7c66c@linux.site> Organization: jamalopolis Message-Id: <1094822205.1125.113.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 09:16:46 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 06:18:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 06:18:30 AM, Serialize complete at 09/10/2004 06:18:30 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 358 Lines: 12 On Fri, 2004-09-10 at 05:40, Stephen Hemminger wrote: > Unless there is some compelling reason, I think that keeping the old ioctl > interface for a least a year until the kernel changes become more ubiquitous. I think that iproute2 should first attempt to use netlink and on failure switch to ioctls. Maybe Thomas can create such a patch. cheers, jamal From hadi@cyberus.ca Fri Sep 10 06:34:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 06:34:10 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ADY3je026115 for ; Fri, 10 Sep 2004 06:34:04 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091006351510:35770 ; Fri, 10 Sep 2004 06:35:15 -0700 Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20040908134713.1bcd46d3.davem@davemloft.net> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> Organization: jamalopolis Message-Id: <1094823215.1121.129.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 09:33:35 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 06:35:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 06:35:23 AM, Serialize complete at 09/10/2004 06:35:23 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 756 Lines: 21 On Wed, 2004-09-08 at 16:47, David S. Miller wrote: > > We are merely moving the sch_generic.c locking logic into the > drivers. The behavior is entirely equivalent except that one > level of unnecessary locking has been removed. > > I think his change is valid, will not break existing drivers (as > you mentioned as well Jamal), and works well for the cases he has > shown patches of. So I'm going to apply his patch. > > BTW, if we are really concerned about some existing driver returning > -1 from hard_start_xmit() without the new feature flag being enabled, > we can test for that and log a debugging message if it happens. I am not 100% happy but let me do some testing on it. Would the best image be the latest bk snapshot? cheers, jamal From tgraf@suug.ch Fri Sep 10 06:36:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 06:36:34 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ADaRQA026467 for ; Fri, 10 Sep 2004 06:36:28 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 1556D81; Fri, 10 Sep 2004 15:35:56 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 838E31C0E7; Fri, 10 Sep 2004 15:36:37 +0200 (CEST) Date: Fri, 10 Sep 2004 15:36:37 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910133637.GA20088@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2064 Lines: 55 Allows changing of device name via rtnetlink. Last bit needed to do full link configuration via rtnetlink. Signed-off-by: Thomas Graf diff -Nru linux-2.6.9-rc1-bk15.orig/include/linux/netdevice.h linux-2.6.9-rc1-bk15/include/linux/netdevice.h --- linux-2.6.9-rc1-bk15.orig/include/linux/netdevice.h 2004-09-08 18:32:05.000000000 +0200 +++ linux-2.6.9-rc1-bk15/include/linux/netdevice.h 2004-09-10 12:42:07.000000000 +0200 @@ -677,6 +677,7 @@ extern int dev_ethtool(struct ifreq *); extern unsigned dev_get_flags(const struct net_device *); extern int dev_change_flags(struct net_device *, unsigned); +extern int dev_change_name(struct net_device *, char *); extern int dev_set_mtu(struct net_device *, int); extern void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev); diff -Nru linux-2.6.9-rc1-bk15.orig/net/core/dev.c linux-2.6.9-rc1-bk15/net/core/dev.c --- linux-2.6.9-rc1-bk15.orig/net/core/dev.c 2004-09-08 18:33:42.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/dev.c 2004-09-10 12:41:19.000000000 +0200 @@ -3347,6 +3347,7 @@ EXPORT_SYMBOL(dev_set_allmulti); EXPORT_SYMBOL(dev_set_promiscuity); EXPORT_SYMBOL(dev_change_flags); +EXPORT_SYMBOL(dev_change_name); EXPORT_SYMBOL(dev_set_mtu); EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(netdev_boot_setup_check); diff -Nru linux-2.6.9-rc1-bk15.orig/net/core/rtnetlink.c linux-2.6.9-rc1-bk15/net/core/rtnetlink.c --- linux-2.6.9-rc1-bk15.orig/net/core/rtnetlink.c 2004-09-08 18:33:42.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/rtnetlink.c 2004-09-10 12:36:54.000000000 +0200 @@ -345,6 +345,23 @@ dev->weight = *((u32 *) RTA_DATA(ida[IFLA_WEIGHT - 1])); } + if (ida[IFLA_IFNAME - 1]) { + char ifname[IFNAMSIZ]; + + if (ida[IFLA_IFNAME - 1]->rta_len > RTA_LENGTH(IFNAMSIZ)) + goto out; + + memset(ifname, 0, sizeof(ifname)); + memcpy(ifname, RTA_DATA(ida[IFLA_IFNAME - 1]), + RTA_PAYLOAD(ida[IFLA_IFNAME - 1])); + ifname[IFNAMSIZ - 1] = '\0'; + + err = dev_change_name(dev, ifname); + + if (err) + goto out; + } + err = 0; out: From jhaller@lucent.com Fri Sep 10 06:40:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 06:41:01 -0700 (PDT) Received: from hoemail1.lucent.com (hoemail1.lucent.com [192.11.226.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ADesfa026824 for ; Fri, 10 Sep 2004 06:40:55 -0700 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i8ADeaqB027332; Fri, 10 Sep 2004 08:40:37 -0500 (CDT) Received: from lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i8ADeak08352; Fri, 10 Sep 2004 08:40:36 -0500 (CDT) Message-ID: <4141AED3.4080807@lucent.com> Date: Fri, 10 Sep 2004 08:40:35 -0500 From: John Haller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jab@cs.sun.ac.za CC: Francois Echantillac , netdev Subject: Re: [Fwd: Re: question: linux TCP/IP stack implementation] References: <1094714541.15115.23.camel@poulenc.cs.sun.ac.za> <1094807281.41416ef16a42e@mouette.ens-lyon.fr> In-Reply-To: <1094807281.41416ef16a42e@mouette.ens-lyon.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jhaller@lucent.com Precedence: bulk X-list: netdev Content-Length: 620 Lines: 14 >>Could you direct me to any good documentation on the implementation of >>the TCP/IP stack in the linux kernel. >> >>I'm a Msc sudent of the University of Stellenbosch, South Africa. >>As an experiment I wat to replace the linux TCP implementation with a >>model checked version. There is a new (June, 2004) book on the TCP/IP stack in Linux 2.6: The Linux TCP/IP Stack: Networking for Embedded Systems by Thomas Herbert, ISBN 1584502843, list price US$49.95, 586 pages While I haven't read this book, there was a positive review in this month's IEEE Computer Magazine. -- John Haller 630-979-6407 jhaller@lucent.com From yoshfuji@linux-ipv6.org Fri Sep 10 07:00:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 07:00:55 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AE0mZo027517 for ; Fri, 10 Sep 2004 07:00:48 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id DF87533CE7; Fri, 10 Sep 2004 23:00:38 +0900 (JST) Date: Fri, 10 Sep 2004 23:00:38 +0900 (JST) Message-Id: <20040910.230038.322907649.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040910133637.GA20088@postel.suug.ch> References: <20040910133637.GA20088@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 524 Lines: 15 In article <20040910133637.GA20088@postel.suug.ch> (at Fri, 10 Sep 2004 15:36:37 +0200), Thomas Graf says: > Allows changing of device name via rtnetlink. Last bit needed to do full > link configuration via rtnetlink. > > Signed-off-by: Thomas Graf : > + if (ida[IFLA_IFNAME - 1]->rta_len > RTA_LENGTH(IFNAMSIZ)) > + goto out; Please use sizeof(ifname) instead. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From tgraf@suug.ch Fri Sep 10 07:27:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 07:28:05 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AERxDY028245 for ; Fri, 10 Sep 2004 07:27:59 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E3E8381; Fri, 10 Sep 2004 16:27:22 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id B5BCE1C0E7; Fri, 10 Sep 2004 16:28:04 +0200 (CEST) Date: Fri, 10 Sep 2004 16:28:04 +0200 From: Thomas Graf To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910142804.GC20088@postel.suug.ch> References: <20040910133637.GA20088@postel.suug.ch> <20040910.230038.322907649.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910.230038.322907649.yoshfuji@linux-ipv6.org> X-archive-position: 8600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2322 Lines: 66 * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <20040910.230038.322907649.yoshfuji@linux-ipv6.org> 2004-09-10 23:00 > In article <20040910133637.GA20088@postel.suug.ch> (at Fri, 10 Sep 2004 15:36:37 +0200), Thomas Graf says: > > > Allows changing of device name via rtnetlink. Last bit needed to do full > > link configuration via rtnetlink. > > > > Signed-off-by: Thomas Graf > : > > + if (ida[IFLA_IFNAME - 1]->rta_len > RTA_LENGTH(IFNAMSIZ)) > > + goto out; > > Please use sizeof(ifname) instead. Thanks for the hint. Allows changing of device name via rtnetlink. Last bit needed to do full link configuration via rtnetlink. Signed-off-by: Thomas Graf --- linux-2.6.9-rc1-bk15.orig/include/linux/netdevice.h 2004-09-08 18:32:05.000000000 +0200 +++ linux-2.6.9-rc1-bk15/include/linux/netdevice.h 2004-09-10 12:42:07.000000000 +0200 @@ -677,6 +677,7 @@ extern int dev_ethtool(struct ifreq *); extern unsigned dev_get_flags(const struct net_device *); extern int dev_change_flags(struct net_device *, unsigned); +extern int dev_change_name(struct net_device *, char *); extern int dev_set_mtu(struct net_device *, int); extern void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev); --- linux-2.6.9-rc1-bk15.orig/net/core/dev.c 2004-09-08 18:33:42.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/dev.c 2004-09-10 12:41:19.000000000 +0200 @@ -3347,6 +3347,7 @@ EXPORT_SYMBOL(dev_set_allmulti); EXPORT_SYMBOL(dev_set_promiscuity); EXPORT_SYMBOL(dev_change_flags); +EXPORT_SYMBOL(dev_change_name); EXPORT_SYMBOL(dev_set_mtu); EXPORT_SYMBOL(free_netdev); EXPORT_SYMBOL(netdev_boot_setup_check); --- linux-2.6.9-rc1-bk15.orig/net/core/rtnetlink.c 2004-09-08 18:33:42.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/rtnetlink.c 2004-09-10 16:13:46.000000000 +0200 @@ -345,6 +345,23 @@ dev->weight = *((u32 *) RTA_DATA(ida[IFLA_WEIGHT - 1])); } + if (ida[IFLA_IFNAME - 1]) { + char ifname[IFNAMSIZ]; + + if (ida[IFLA_IFNAME - 1]->rta_len > RTA_LENGTH(sizeof(ifname))) + goto out; + + memset(ifname, 0, sizeof(ifname)); + memcpy(ifname, RTA_DATA(ida[IFLA_IFNAME - 1]), + RTA_PAYLOAD(ida[IFLA_IFNAME - 1])); + ifname[IFNAMSIZ - 1] = '\0'; + + err = dev_change_name(dev, ifname); + + if (err) + goto out; + } + err = 0; out: From yoshfuji@linux-ipv6.org Fri Sep 10 07:32:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 07:32:20 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AEWDCX028596 for ; Fri, 10 Sep 2004 07:32:14 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6A3CE33CE7; Fri, 10 Sep 2004 23:32:04 +0900 (JST) Date: Fri, 10 Sep 2004 23:31:57 +0900 (JST) Message-Id: <20040910.233157.362649106.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040910142804.GC20088@postel.suug.ch> References: <20040910133637.GA20088@postel.suug.ch> <20040910.230038.322907649.yoshfuji@linux-ipv6.org> <20040910142804.GC20088@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 436 Lines: 15 In article <20040910142804.GC20088@postel.suug.ch> (at Fri, 10 Sep 2004 16:28:04 +0200), Thomas Graf says: > > Please use sizeof(ifname) instead. > > Thanks for the hint. > > Allows changing of device name via rtnetlink. Last bit needed to do full > link configuration via rtnetlink. > > Signed-off-by: Thomas Graf Thanks. Ack. Signed-off-by: Hideaki YOSHIFUJI --yoshfuji From Adam.Lewis@motorola.com Fri Sep 10 08:24:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 08:24:28 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AFOLfG000635 for ; Fri, 10 Sep 2004 08:24:21 -0700 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i8AFPIF7023019 for ; Fri, 10 Sep 2004 08:25:18 -0700 (MST) Received: from il02exm12.corp.mot.com (il02exm12.corp.mot.com [10.0.111.23]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i8AFMuV1028800 for ; Fri, 10 Sep 2004 10:22:57 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Sep 2004 10:24:11 -0500 Message-ID: From: Lewis Adam-CAL022 To: Ben Greear , Lewis Adam-CAL022 Cc: netdev@oss.sgi.com Subject: RE: hard_start_xmit and Linux bridging Date: Fri, 10 Sep 2004 10:24:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 8602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Adam.Lewis@motorola.com Precedence: bulk X-list: netdev Content-Length: 1244 Lines: 34 Hi Ben, > -----Original Message----- > From: Ben Greear [mailto:greearb@candelatech.com] > Sent: Thursday, September 09, 2004 6:30 PM > To: Lewis Adam-CAL022 > Cc: netdev@oss.sgi.com > Subject: Re: hard_start_xmit and Linux bridging > > I added some ioctls to allow one to turn on the ability to > receive the CRC, but I don't know of any drivers that include > it by default. Right, this is what I would have expected since no other driver account for it. > > What driver/hardware is your eth0 device? It is a custom board but a Xilinx PCORE and using a Montavista driver. Based on what you said above, it seems that I might want to pursue this with them. > > How are you determining the size, by the skb->len ? Exactly. And not only does it include the FCS/CRC, but in the case of an ARP, there are an extra 14 trailing 0's. I thought this was a bridging issue, now I'm thinking it's a xilinx/mvista issue. > > Does tcpdump/ethereal show the extra 4 bytes if you sniff > eth0 w/out bridging? Yeah. And in the case of ARP it is even weirder, and extra 18 bytes, mostly zeros. So case in point, it sounds like this is not proper operation? I want to confirm before I bring it up with Xilinx and Montavista. Thanks! Adam From jmorris@redhat.com Fri Sep 10 08:42:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 08:43:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AFgtxu001273 for ; Fri, 10 Sep 2004 08:42:55 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i8AFg270008512; Fri, 10 Sep 2004 11:42:07 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8AFg1310348; Fri, 10 Sep 2004 11:42:01 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8AFg0iS007412; Fri, 10 Sep 2004 11:42:00 -0400 Date: Fri, 10 Sep 2004 11:42:00 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , , , , Subject: Re: [IPCOMP] Use per-cpu buffers In-Reply-To: <20040910111047.GA29330@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 378 Lines: 16 On Fri, 10 Sep 2004, Herbert Xu wrote: > James, can you think of a general solution to the 64K buffer in > terms of the crypto decompression interface? I haven't looked at the code for a while, but I think we might be able to save some memory by specifying compression parameters and making the appropriate changes to zlib. - James -- James Morris From jt@bougret.hpl.hp.com Fri Sep 10 12:50:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 12:50:22 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AJoImO010368 for ; Fri, 10 Sep 2004 12:50:18 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 921AFA826; Fri, 10 Sep 2004 12:50:08 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA28163; Fri, 10 Sep 2004 12:52:55 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1C5rPH-00042N-00; Fri, 10 Sep 2004 12:50:03 -0700 Date: Fri, 10 Sep 2004 12:50:03 -0700 To: Thomas Graf , netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910195003.GA13912@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 8604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 1215 Lines: 47 Thomas Graf wrote : > > Allows changing of device name via rtnetlink. Last bit needed to do full > link configuration via rtnetlink. > > Signed-off-by: Thomas Graf This does not work, because you don't return the new name to user space. If the new name is a pattern, such as "eth%d" or "wlan%d", you absolutely need to return the new instanciated device name to user space so that userspace doesn't loose track of the device. Please look at this snipset from dev.c : ----------------------------------------------------------------- /* * These ioctl calls: * - require superuser power. * - require strict serialization. * - return a value */ case SIOCGMIIPHY: case SIOCGMIIREG: case SIOCSIFNAME: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); rtnl_lock(); ret = dev_ifsioc(&ifr, cmd); rtnl_unlock(); if (!ret) { if (colon) *colon = ':'; if (copy_to_user(arg, &ifr, sizeof(struct ifreq))) ret = -EFAULT; } return ret; ----------------------------------------------------------------- I'm all for converting stuff to RtNetlink, but please don't criple the functionality... Have fun... Jean From tgraf@suug.ch Fri Sep 10 13:06:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:06:43 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AK6bDm010976 for ; Fri, 10 Sep 2004 13:06:38 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6A2FC81; Fri, 10 Sep 2004 22:06:02 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 907031C0EA; Fri, 10 Sep 2004 22:06:44 +0200 (CEST) Date: Fri, 10 Sep 2004 22:06:44 +0200 From: Thomas Graf To: jt@hpl.hp.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910200644.GJ20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910195003.GA13912@bougret.hpl.hp.com> X-archive-position: 8605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 924 Lines: 23 * Jean Tourrilhes <20040910195003.GA13912@bougret.hpl.hp.com> 2004-09-10 12:50 > Thomas Graf wrote : > > > > Allows changing of device name via rtnetlink. Last bit needed to do full > > link configuration via rtnetlink. > > > > Signed-off-by: Thomas Graf > > This does not work, because you don't return the new name to > user space. If the new name is a pattern, such as "eth%d" or "wlan%d", > you absolutely need to return the new instanciated device name to user > space so that userspace doesn't loose track of the device. The ifindex stays the same, therefore the user space application can simply dump the link list and fetch the new interface name. It would theoretically be possible to provide the new name via an ACK but this would break the RFC. > if (colon) > *colon = ':'; I ignored the colon handling on purpose, this is better done in user space. I can change this if required. From jt@bougret.hpl.hp.com Fri Sep 10 13:13:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:13:19 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AKDFBr011360 for ; Fri, 10 Sep 2004 13:13:15 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id BF4542DF5; Fri, 10 Sep 2004 13:13:02 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA28779; Fri, 10 Sep 2004 13:15:53 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1C5rlW-0004JG-00; Fri, 10 Sep 2004 13:13:02 -0700 Date: Fri, 10 Sep 2004 13:13:02 -0700 To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910201302.GA16556@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910200644.GJ20088@postel.suug.ch> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 8606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 1030 Lines: 27 On Fri, Sep 10, 2004 at 10:06:44PM +0200, Thomas Graf wrote: > * Jean Tourrilhes <20040910195003.GA13912@bougret.hpl.hp.com> 2004-09-10 12:50 > > Thomas Graf wrote : > > > > > > Allows changing of device name via rtnetlink. Last bit needed to do full > > > link configuration via rtnetlink. > > > > > > Signed-off-by: Thomas Graf > > > > This does not work, because you don't return the new name to > > user space. If the new name is a pattern, such as "eth%d" or "wlan%d", > > you absolutely need to return the new instanciated device name to user > > space so that userspace doesn't loose track of the device. > > The ifindex stays the same, therefore the user space application can > simply dump the link list and fetch the new interface name. It's so simple to return the new name, so why not do it ? There is no need to make applications more complex. > It would > theoretically be possible to provide the new name via an ACK but > this would break the RFC. What do you mean, break the RFC ? Jean From tgraf@suug.ch Fri Sep 10 13:22:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:22:30 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AKMPF9011736 for ; Fri, 10 Sep 2004 13:22:25 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 806E481; Fri, 10 Sep 2004 22:21:53 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id C64551C0EA; Fri, 10 Sep 2004 22:22:35 +0200 (CEST) Date: Fri, 10 Sep 2004 22:22:35 +0200 From: Thomas Graf To: jt@hpl.hp.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910202235.GK20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910201302.GA16556@bougret.hpl.hp.com> X-archive-position: 8607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1652 Lines: 38 * Jean Tourrilhes <20040910201302.GA16556@bougret.hpl.hp.com> 2004-09-10 13:13 > On Fri, Sep 10, 2004 at 10:06:44PM +0200, Thomas Graf wrote: > > * Jean Tourrilhes <20040910195003.GA13912@bougret.hpl.hp.com> 2004-09-10 12:50 > > > Thomas Graf wrote : > > > > > > > > Allows changing of device name via rtnetlink. Last bit needed to do full > > > > link configuration via rtnetlink. > > > > > > > > Signed-off-by: Thomas Graf > > > > > > This does not work, because you don't return the new name to > > > user space. If the new name is a pattern, such as "eth%d" or "wlan%d", > > > you absolutely need to return the new instanciated device name to user > > > space so that userspace doesn't loose track of the device. > > > > The ifindex stays the same, therefore the user space application can > > simply dump the link list and fetch the new interface name. > > It's so simple to return the new name, so why not do it ? > There is no need to make applications more complex. Oh, I didn't realize that, can you enlighten me? > > It would > > theoretically be possible to provide the new name via an ACK but > > this would break the RFC. > > What do you mean, break the RFC ? I can think of 2 ways implementing this: 1) Send an ACK and change IFLA_IFNAME in the original message. However, RFC 3549 specifies it to be the old message so user space applications can directly reuse it (forward, redirect, log, ...) 2) Implement NETDEV_CHANGE, I was actually about to implement this but it's not directly related to this change and requires the same effort by the user space application has refetching the link list. From tgraf@suug.ch Fri Sep 10 13:27:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:27:15 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AKR7Ef012092 for ; Fri, 10 Sep 2004 13:27:10 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id B982181; Fri, 10 Sep 2004 22:26:35 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 71CB61C0E7; Fri, 10 Sep 2004 18:55:08 +0200 (CEST) Date: Fri, 10 Sep 2004 18:55:08 +0200 From: Thomas Graf To: jamal Cc: Stephen Hemminger , "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , davem@davemloft.net, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-ID: <20040910165508.GI20088@postel.suug.ch> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> <20040909175411.GB19155@postel.suug.ch> <20040910.103341.28767986.yoshfuji@wide.ad.jp> <20040910092948.GB19930@postel.suug.ch> <20040910024030.28b7c66c@linux.site> <1094822205.1125.113.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094822205.1125.113.camel@jzny.localdomain> X-archive-position: 8608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 11688 Lines: 423 * jamal <1094822205.1125.113.camel@jzny.localdomain> 2004-09-10 09:16 > > On Fri, 2004-09-10 at 05:40, Stephen Hemminger wrote: > > Unless there is some compelling reason, I think that keeping the old ioctl > > interface for a least a year until the kernel changes become more ubiquitous. > > I think that iproute2 should first attempt to use netlink and on failure > switch to ioctls. > Maybe Thomas can create such a patch. - Uses rtnetlink whenver possible and falls back to ioctl if the rtnetlink call fails or one of the changes was not successful. Not 100% perfect yet but you'll get the point. - Fixes memory corruption issue. buffer for address and brd was too small (14) for bigger addresses, e.g. interfaces with ipv6 ll addresses. Introduced a ADDRBUFSIZ and a check in ll_init_map to avoid further problems. - Uses ifinfomsg.ifi_type instead of getting hw type from packet socket. I hope this is correct. just a small hack... diff -Nru iproute2-2.6.9-jamal.orig/include/linux/rtnetlink.h iproute2-2.6.9-jamal/include/linux/rtnetlink.h --- iproute2-2.6.9-jamal.orig/include/linux/rtnetlink.h 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/include/linux/rtnetlink.h 2004-09-10 17:51:28.000000000 +0200 @@ -561,6 +561,12 @@ #define IFLA_WIRELESS IFLA_WIRELESS IFLA_PROTINFO, /* Protocol specific information for a link */ #define IFLA_PROTINFO IFLA_PROTINFO + IFLA_TXQLEN, +#define IFLA_TXQLEN IFLA_TXQLEN + IFLA_MAP, +#define IFLA_MAP IFLA_MAP + IFLA_WEIGHT, +#define IFLA_WEIGHT IFLA_WEIGHT __IFLA_MAX }; diff -Nru iproute2-2.6.9-jamal.orig/include/ll_map.h iproute2-2.6.9-jamal/include/ll_map.h --- iproute2-2.6.9-jamal.orig/include/ll_map.h 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/include/ll_map.h 2004-09-10 18:37:45.000000000 +0200 @@ -1,12 +1,17 @@ #ifndef __LL_MAP_H__ #define __LL_MAP_H__ 1 +#define ADDRBUFSIZ 32 + extern int ll_remember_index(struct sockaddr_nl *who, struct nlmsghdr *n, void *arg); extern int ll_init_map(struct rtnl_handle *rth); extern int ll_name_to_index(char *name); extern const char *ll_index_to_name(int idx); extern const char *ll_idx_n2a(int idx, char *buf); extern int ll_index_to_type(int idx); +extern int ll_index_to_alen(int idx); +extern unsigned char *ll_index_to_addr(int idx); +extern unsigned char *ll_index_to_brd(int idx); extern unsigned ll_index_to_flags(int idx); #endif /* __LL_MAP_H__ */ diff -Nru iproute2-2.6.9-jamal.orig/ip/ipaddress.c iproute2-2.6.9-jamal/ip/ipaddress.c --- iproute2-2.6.9-jamal.orig/ip/ipaddress.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/ip/ipaddress.c 2004-09-10 17:52:38.000000000 +0200 @@ -182,6 +182,10 @@ fprintf(fp, "mtu %u ", *(int*)RTA_DATA(tb[IFLA_MTU])); if (tb[IFLA_QDISC]) fprintf(fp, "qdisc %s ", (char*)RTA_DATA(tb[IFLA_QDISC])); +#ifdef IFLA_WEIGT + if (tb[IFLA_WEIGHT]) + fprintf(fp, "weight %u ", *(uint32_t*)RTA_DATA(tb[IFLA_WEIGHT])); +#endif #ifdef IFLA_MASTER if (tb[IFLA_MASTER]) { SPRINT_BUF(b1); diff -Nru iproute2-2.6.9-jamal.orig/ip/iplink.c iproute2-2.6.9-jamal/ip/iplink.c --- iproute2-2.6.9-jamal.orig/ip/iplink.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/ip/iplink.c 2004-09-10 18:43:04.000000000 +0200 @@ -25,7 +25,7 @@ #include #include #include -#include +#include #include "rt_names.h" #include "utils.h" @@ -46,6 +46,9 @@ fprintf(stderr, " txqueuelen PACKETS |\n"); fprintf(stderr, " name NEWNAME |\n"); fprintf(stderr, " address LLADDR | broadcast LLADDR |\n"); +#ifdef IFLA_WEIGHT + fprintf(stderr, " weight WEIGHT |\n"); +#endif fprintf(stderr, " mtu MTU }\n"); fprintf(stderr, " ip link show [ DEVICE ]\n"); exit(-1); @@ -174,48 +177,6 @@ return 0; } -static int get_address(char *dev, int *htype) -{ - struct ifreq ifr; - struct sockaddr_ll me; - int alen; - int s; - - s = socket(PF_PACKET, SOCK_DGRAM, 0); - if (s < 0) { - perror("socket(PF_PACKET)"); - return -1; - } - - memset(&ifr, 0, sizeof(ifr)); - strcpy(ifr.ifr_name, dev); - if (ioctl(s, SIOCGIFINDEX, &ifr) < 0) { - perror("SIOCGIFINDEX"); - close(s); - return -1; - } - - memset(&me, 0, sizeof(me)); - me.sll_family = AF_PACKET; - me.sll_ifindex = ifr.ifr_ifindex; - me.sll_protocol = htons(ETH_P_LOOP); - if (bind(s, (struct sockaddr*)&me, sizeof(me)) == -1) { - perror("bind"); - close(s); - return -1; - } - - alen = sizeof(me); - if (getsockname(s, (struct sockaddr*)&me, &alen) == -1) { - perror("getsockname"); - close(s); - return -1; - } - close(s); - *htype = me.sll_hatype; - return me.sll_halen; -} - static int parse_address(char *dev, int hatype, int halen, char *lla, struct ifreq *ifr) { int alen; @@ -223,7 +184,7 @@ memset(ifr, 0, sizeof(*ifr)); strcpy(ifr->ifr_name, dev); ifr->ifr_hwaddr.sa_family = hatype; - alen = ll_addr_a2n(ifr->ifr_hwaddr.sa_data, 14, lla); + alen = ll_addr_a2n(ifr->ifr_hwaddr.sa_data, ADDRBUFSIZ, lla); if (alen < 0) return -1; if (alen != halen) { @@ -249,19 +210,46 @@ return 0; } +struct link_request +{ + struct nlmsghdr nl_msg; + struct ifinfomsg ifi; + char buf[256]; +}; + +#define USE_IOCTL_MTU 1 +#define USE_IOCTL_TXQLEN 2 +#define USE_IOCTL_FLAGS 4 +#define USE_IOCTL_NAME 8 +#define USE_IOCTL_ADDR 16 +#define USE_IOCTL_BRD 32 static int do_set(int argc, char **argv) { char *dev = NULL; __u32 mask = 0; __u32 flags = 0; - int qlen = -1; - int mtu = -1; + int32_t qlen = -1; + int32_t mtu = -1; + int32_t weight = -1; char *newaddr = NULL; char *newbrd = NULL; struct ifreq ifr0, ifr1; char *newname = NULL; int htype, halen; + struct rtnl_handle rth; + int use_ioctl_mask = 0; + + struct link_request req = { + .nl_msg = { + .nlmsg_type = RTM_SETLINK, + .nlmsg_flags = NLM_F_REQUEST, + .nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)), + }, + .ifi = { + .ifi_family = PF_PACKET, + }, + }; while (argc > 0) { if (strcmp(*argv, "up") == 0) { @@ -288,12 +276,22 @@ duparg("txqueuelen", *argv); if (get_integer(&qlen, *argv, 0)) invarg("Invalid \"txqueuelen\" value\n", *argv); +#ifdef IFLA_TXQLEN + addattr_l(&req.nl_msg, sizeof(req), IFLA_TXQLEN, &qlen, sizeof(qlen)); +#else + use_ioctl_mask |= USE_IOCTL_TXQLEN; +#endif } else if (strcmp(*argv, "mtu") == 0) { NEXT_ARG(); if (mtu != -1) duparg("mtu", *argv); if (get_integer(&mtu, *argv, 0)) invarg("Invalid \"mtu\" value\n", *argv); +#ifdef IFLA_MTU + addattr_l(&req.nl_msg, sizeof(req), IFLA_MTU, &mtu, sizeof(mtu)); +#else + use_ioctl_mask |= USE_IOCTL_MTU; +#endif } else if (strcmp(*argv, "multicast") == 0) { NEXT_ARG(); mask |= IFF_MULTICAST; @@ -339,6 +337,15 @@ flags |= IFF_NOARP; } else return on_off("noarp"); +#ifdef IFLA_WEIGHT + } else if (matches(*argv, "weight") == 0) { + NEXT_ARG(); + if (weight != -1) + duparg("weight", *argv); + if (get_integer(&weight, *argv, 0)) + invarg("Invalid \"weight\" value\n", *argv); + addattr_l(&req.nl_msg, sizeof(req), IFLA_WEIGHT, &weight, sizeof(weight)); +#endif #ifdef IFF_DYNAMIC } else if (matches(*argv, "dynamic") == 0) { NEXT_ARG(); @@ -367,20 +374,85 @@ fprintf(stderr, "Not enough of information: \"dev\" argument is required.\n"); exit(-1); } + + if (rtnl_open(&rth, 0) < 0) + exit(1); + + ll_init_map(&rth); + + if ((req.ifi.ifi_index = ll_name_to_index(dev)) == 0) { + fprintf(stderr, "Cannot find device \"%s\"\n", dev); + return -1; + } + + if (mask) { + req.ifi.ifi_flags = ll_index_to_flags(req.ifi.ifi_index); + if ((req.ifi.ifi_flags ^ flags) & mask) { + req.ifi.ifi_flags &= ~mask; + req.ifi.ifi_flags |= mask & flags; + } + } if (newaddr || newbrd) { - halen = get_address(dev, &htype); + halen = ll_index_to_alen(req.ifi.ifi_index); + htype = ll_index_to_type(req.ifi.ifi_index); + if (halen < 0) return -1; + if (newaddr) { if (parse_address(dev, htype, halen, newaddr, &ifr0) < 0) return -1; + + addattr_l(&req.nl_msg, sizeof(req), IFLA_ADDRESS, ifr0.ifr_hwaddr.sa_data, halen); } + if (newbrd) { if (parse_address(dev, htype, halen, newbrd, &ifr1) < 0) return -1; + addattr_l(&req.nl_msg, sizeof(req), IFLA_BROADCAST, ifr1.ifr_hwaddr.sa_data, halen); } } + + if (newname && strcmp(dev, newname)) { + char ifname[IFNAMSIZ] = {0}; + + strncpy(ifname, newname, sizeof(ifname) - 1); + addattr_l(&req.nl_msg, sizeof(req), IFLA_IFNAME, ifname, + strlen(ifname) + 1); + } + + if (rtnl_talk(&rth, &req.nl_msg, 0, 0, NULL, NULL, NULL) == 0) + { + /* successful but check if everything is implemented */ + ll_init_map(&rth); + + if (mask) + if ((ll_index_to_flags(req.ifi.ifi_index) ^ flags) & mask) + use_ioctl_mask |= USE_IOCTL_FLAGS; + + if (newaddr) + if (memcmp(ifr0.ifr_hwaddr.sa_data, + ll_index_to_addr(req.ifi.ifi_index), + ll_index_to_alen(req.ifi.ifi_index))) + use_ioctl_mask |= USE_IOCTL_ADDR; + + if (newbrd) + if (memcmp(ifr1.ifr_hwaddr.sa_data, + ll_index_to_brd(req.ifi.ifi_index), + ll_index_to_alen(req.ifi.ifi_index))) + use_ioctl_mask |= USE_IOCTL_BRD; + + if (newname && strcmp(dev, newname)) + if (strcmp(newname, ll_index_to_name(req.ifi.ifi_index))) + use_ioctl_mask |= USE_IOCTL_NAME; + + if (use_ioctl_mask == 0) + return 0; + } + + printf("rtnetlink method failed, trying ioctl...\n"); + /* rtnetlink method failed, try ioctl */ if (newname && strcmp(dev, newname)) { if (do_changename(dev, newname) < 0) @@ -407,6 +479,7 @@ } if (mask) return do_chflags(dev, flags, mask); + return 0; } diff -Nru iproute2-2.6.9-jamal.orig/lib/ll_map.c iproute2-2.6.9-jamal/lib/ll_map.c --- iproute2-2.6.9-jamal.orig/lib/ll_map.c 2004-09-08 19:23:18.000000000 +0200 +++ iproute2-2.6.9-jamal/lib/ll_map.c 2004-09-10 18:33:53.000000000 +0200 @@ -29,7 +29,8 @@ int type; int alen; unsigned flags; - unsigned char addr[8]; + unsigned char addr[ADDRBUFSIZ]; + unsigned char brd[ADDRBUFSIZ]; char name[16]; }; @@ -74,6 +75,10 @@ if (tb[IFLA_ADDRESS]) { int alen; im->alen = alen = RTA_PAYLOAD(tb[IFLA_ADDRESS]); + if (alen > ADDRBUFSIZ) { + fprintf(stderr, "Increase ADDRBUFSIZ\n"); + return -1; + } if (alen > sizeof(im->addr)) alen = sizeof(im->addr); memcpy(im->addr, RTA_DATA(tb[IFLA_ADDRESS]), alen); @@ -81,6 +86,17 @@ im->alen = 0; memset(im->addr, 0, sizeof(im->addr)); } + if (tb[IFLA_BROADCAST]) { + int alen = RTA_PAYLOAD(tb[IFLA_BROADCAST]); + if (alen > ADDRBUFSIZ) { + fprintf(stderr, "Increase ADDRBUFSIZ\n"); + return -1; + } + if (alen != im->alen) + return -1; + memcpy(im->brd, RTA_DATA(tb[IFLA_BROADCAST]), alen); + } else + memset(im->brd, 0, sizeof(im->brd)); strcpy(im->name, RTA_DATA(tb[IFLA_IFNAME])); return 0; } @@ -118,6 +134,42 @@ return -1; } +int ll_index_to_alen(int idx) +{ + struct idxmap *im; + + if (idx == 0) + return -1; + for (im = idxmap[idx&0xF]; im; im = im->next) + if (im->index == idx) + return im->alen; + return -1; +} + +unsigned char * ll_index_to_addr(int idx) +{ + struct idxmap *im; + + if (idx == 0) + return NULL; + for (im = idxmap[idx&0xF]; im; im = im->next) + if (im->index == idx) + return im->addr; + return NULL; +} + +unsigned char * ll_index_to_brd(int idx) +{ + struct idxmap *im; + + if (idx == 0) + return NULL; + for (im = idxmap[idx&0xF]; im; im = im->next) + if (im->index == idx) + return im->brd; + return NULL; +} + unsigned ll_index_to_flags(int idx) { struct idxmap *im; From jt@bougret.hpl.hp.com Fri Sep 10 13:32:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:32:18 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AKWDmm012476 for ; Fri, 10 Sep 2004 13:32:13 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 27FDB409427; Fri, 10 Sep 2004 13:32:04 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA29241; Fri, 10 Sep 2004 13:34:54 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1C5s3v-0004SK-00; Fri, 10 Sep 2004 13:32:03 -0700 Date: Fri, 10 Sep 2004 13:32:03 -0700 To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910203203.GA17078@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910202235.GK20088@postel.suug.ch> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 8610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 476 Lines: 13 On Fri, Sep 10, 2004 at 10:22:35PM +0200, Thomas Graf wrote: > > 2) Implement NETDEV_CHANGE, I was actually about to implement this > but it's not directly related to this change and requires the same > effort by the user space application has refetching the link list. Do you have any info on NETDEV_CHANGE, I've got a potential use for it. (By the way, there are other ways to do it, but if NETDEV_CHANGE is the proposed standard, I might as well use it). Jean From hadi@cyberus.ca Fri Sep 10 13:32:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:32:05 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AKW0Ll012448 for ; Fri, 10 Sep 2004 13:32:00 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C5s3i-00032B-4K for netdev@oss.sgi.com; Fri, 10 Sep 2004 16:31:50 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C5s3e-0001nc-66; Fri, 10 Sep 2004 16:31:46 -0400 Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: jt@hpl.hp.com, netdev@oss.sgi.com In-Reply-To: <20040910202235.GK20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1094848300.1029.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 16:31:41 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 359 Lines: 12 On Fri, 2004-09-10 at 16:22, Thomas Graf wrote: > 2) Implement NETDEV_CHANGE, I was actually about to implement this > but it's not directly related to this change and requires the same > effort by the user space application has refetching the link list. This is what he needs. Essentially NETDEV_CHANGE will generate a netlink event. cheers, jamal From tgraf@suug.ch Fri Sep 10 13:43:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:43:45 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AKhcCo013259 for ; Fri, 10 Sep 2004 13:43:40 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 9A13481; Fri, 10 Sep 2004 22:43:06 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id A722C1C0E8; Fri, 10 Sep 2004 22:43:48 +0200 (CEST) Date: Fri, 10 Sep 2004 22:43:48 +0200 From: Thomas Graf To: jt@hpl.hp.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910204348.GL20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910203203.GA17078@bougret.hpl.hp.com> X-archive-position: 8611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 897 Lines: 18 * Jean Tourrilhes <20040910203203.GA17078@bougret.hpl.hp.com> 2004-09-10 13:32 > On Fri, Sep 10, 2004 at 10:22:35PM +0200, Thomas Graf wrote: > > > > 2) Implement NETDEV_CHANGE, I was actually about to implement this > > but it's not directly related to this change and requires the same > > effort by the user space application has refetching the link list. > > Do you have any info on NETDEV_CHANGE, I've got a potential > use for it. > (By the way, there are other ways to do it, but if > NETDEV_CHANGE is the proposed standard, I might as well use it). Currently call_netdevice_notifiers is called and sends out a RTM_NEWLINK message with the new interface name to everyone wanting to be notified. However, ifi_change is kept to 0 so far, which means you have to look what has changed yourself. I'm not sure if this can be changed without too much troubles but I will look into it. From dave@thedillows.org Fri Sep 10 13:47:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 13:47:41 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8AKlY1t013596 for ; Fri, 10 Sep 2004 13:47:34 -0700 Received: (qmail 3806 invoked by uid 0); 10 Sep 2004 20:47:45 -0000 Received: from user-69-1-45-93.knology.net (HELO ori.thedillows.org) (69.1.45.93) by smtp6.knology.net with SMTP; 10 Sep 2004 20:47:45 -0000 Received: from ori.thedillows.org (localhost.thedillows.org [127.0.0.1]) by ori.thedillows.org (8.12.8/8.12.8) with ESMTP id i8AKlJMn004056; Fri, 10 Sep 2004 16:47:19 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i8AKlITw004054; Fri, 10 Sep 2004 16:47:18 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: [PATCH 2.6-bk] typhoon: PCI cleanups and ethtool_ops conversion From: David Dillow To: Jeff Garzik Cc: linux-net@vger.kernel.org, Netdev , rl@hellgate.ch Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1094849238.3900.11.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Sep 2004 16:47:18 -0400 X-archive-position: 8612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 17293 Lines: 597 Jeff, please do a bk pull http://typhoon.bkbits.net/typhoon-2.5 This will update the following files: drivers/net/typhoon.c | 259 ++++++++++++++++++++++++++------------------------ 1 files changed, 136 insertions(+), 123 deletions(-) through these ChangeSets: (04/09/09 1.2061) PCI cleanups and convert to ethtool_ops *) Reorder MWI initialization *) Perform proper cleanup on probe failure *) Remove cruft, and avoid locking up NIC on reset Signed-off-by: David A. Dillow # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/09 22:57:10-04:00 dave@thedillows.org # PCI cleanups and convert to ethtool_ops # *) Reorder MWI initialization # *) Perform proper cleanup on probe failure # *) Remove cruft, and avoid locking up NIC on reset # # Signed-off-by: David A. Dillow # # drivers/net/typhoon.c # 2004/09/09 22:49:47-04:00 dave@thedillows.org +12 -4 # Update release date and version, add TODO list. # # drivers/net/typhoon.c # 2004/09/09 00:55:56-04:00 dave@thedillows.org +0 -6 # Remove cruft from when the typhoon driver left the NIC in D3 state. # Its remove could be a problem on a warm-boot from Windows if 3Com's # drivers left the card in D3, but they don't do that, and the code # is blocking progress elsewhere in the PCI system. # # drivers/net/typhoon.c # 2004/09/09 00:30:09-04:00 dave@thedillows.org +81 -84 # Convert to using ethtool_ops, and add some extra abilities. # # drivers/net/typhoon.c # 2004/09/08 23:30:07-04:00 dave@thedillows.org +14 -14 # Make use of netdev_priv() # # drivers/net/typhoon.c # 2004/09/08 01:28:47-04:00 dave@thedillows.org +9 -8 # Still seeing hangs with 100us wait, so bump it to 5ms if we can # sleep, and 500us otherwise. # # drivers/net/typhoon.c # 2004/09/08 00:50:01-04:00 dave@thedillows.org +21 -8 # PCI cleanups: # * move pci_set_mwi() earlier in setup # * call pci_clear_mwi() in ->remove() and ->probe() error path # * call pci_disable_device() on probe error # * make use of DMA_32BIT_MASK constant # diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c 2004-09-09 22:59:32 -04:00 +++ b/drivers/net/typhoon.c 2004-09-09 22:59:32 -04:00 @@ -1,6 +1,6 @@ /* typhoon.c: A Linux Ethernet device driver for 3Com 3CR990 family of NICs */ /* - Written 2002-2003 by David Dillow + Written 2002-2004 by David Dillow Based on code written 1998-2000 by Donald Becker and Linux 2.2.x driver by David P. McLean . @@ -33,8 +33,16 @@ *) Waiting for a command response takes 8ms due to non-preemptable polling. Only significant for getting stats and creating SAs, but an ugly wart never the less. - *) I've not tested multicast. I think it works, but reports welcome. + + TODO: *) Doesn't do IPSEC offloading. Yet. Keep yer pants on, it's coming. + *) Add more support for ethtool (especially for NIC stats) + *) Allow disabling of RX checksum offloading + *) Fix MAC changing to work while the interface is up + (Need to put commands on the TX ring, which changes + the locking) + *) Add in FCS to {rx,tx}_bytes, since the hardware doesn't. See + http://oss.sgi.com/cgi-bin/mesg.cgi?a=netdev&i=20031215152211.7003fe8e.rddunlap%40osdl.org */ /* Set the copy breakpoint for the copy-only-tiny-frames scheme. @@ -85,8 +93,8 @@ #define PKT_BUF_SZ 1536 #define DRV_MODULE_NAME "typhoon" -#define DRV_MODULE_VERSION "1.5.3" -#define DRV_MODULE_RELDATE "03/12/15" +#define DRV_MODULE_VERSION "1.5.4" +#define DRV_MODULE_RELDATE "04/09/09" #define PFX DRV_MODULE_NAME ": " #define ERR_PFX KERN_ERR PFX @@ -410,21 +418,22 @@ out: writel(TYPHOON_INTR_ALL, ioaddr + TYPHOON_REG_INTR_MASK); writel(TYPHOON_INTR_ALL, ioaddr + TYPHOON_REG_INTR_STATUS); - udelay(100); - return err; /* The 3XP seems to need a little extra time to complete the load * of the sleep image before we can reliably boot it. Failure to * do this occasionally results in a hung adapter after boot in * typhoon_init_one() while trying to read the MAC address or * putting the card to sleep. 3Com's driver waits 5ms, but - * that seems to be overkill -- with a 50usec delay, it survives - * 35000 typhoon_init_one() calls, where it only make it 25-100 - * without it. - * - * As it turns out, still occasionally getting a hung adapter, - * so I'm bumping it to 100us. + * that seems to be overkill. However, if we can sleep, we might + * as well give it that much time. Otherwise, we'll give it 500us, + * which should be enough (I've see it work well at 100us, but still + * saw occasional problems.) */ + if(wait_type == WaitSleep) + msleep(5); + else + udelay(500); + return err; } static int @@ -688,7 +697,7 @@ static void typhoon_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; int err; @@ -726,7 +735,7 @@ static void typhoon_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); spin_lock_bh(&tp->state_lock); if(tp->vlgrp) tp->vlgrp->vlan_devices[vid] = NULL; @@ -757,7 +766,7 @@ static int typhoon_start_tx(struct sk_buff *skb, struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct transmit_ring *txRing; struct tx_desc *txd, *first_txd; dma_addr_t skb_dma; @@ -908,7 +917,7 @@ static void typhoon_set_rx_mode(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; u32 mc_filter[2]; u16 filter; @@ -965,6 +974,9 @@ /* 3Com's Linux driver uses txMultipleCollisions as it's * collisions value, but there is some other collision info as well... + * + * The extra status reported would be a good candidate for + * ethtool_ops->get_{strings,stats}() */ stats->tx_packets = le32_to_cpu(s->txPackets); stats->tx_bytes = le32_to_cpu(s->txBytes); @@ -1002,7 +1014,7 @@ static struct net_device_stats * typhoon_get_stats(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct net_device_stats *stats = &tp->stats; struct net_device_stats *saved = &tp->stats_saved; @@ -1030,9 +1042,10 @@ return 0; } -static inline void -typhoon_ethtool_gdrvinfo(struct typhoon *tp, struct ethtool_drvinfo *info) +static void +typhoon_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { + struct typhoon *tp = netdev_priv(dev); struct pci_dev *pci_dev = tp->pdev; struct cmd_desc xp_cmd; struct resp_desc xp_resp[3]; @@ -1055,9 +1068,11 @@ strcpy(info->bus_info, pci_name(pci_dev)); } -static inline void -typhoon_ethtool_gset(struct typhoon *tp, struct ethtool_cmd *cmd) +static int +typhoon_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { + struct typhoon *tp = netdev_priv(dev); + cmd->supported = SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | SUPPORTED_Autoneg; @@ -1107,15 +1122,19 @@ cmd->autoneg = AUTONEG_DISABLE; cmd->maxtxpkt = 1; cmd->maxrxpkt = 1; + + return 0; } -static inline int -typhoon_ethtool_sset(struct typhoon *tp, struct ethtool_cmd *cmd) +static int +typhoon_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; int xcvr; int err; + err = -EINVAL; if(cmd->autoneg == AUTONEG_ENABLE) { xcvr = TYPHOON_XCVR_AUTONEG; } else { @@ -1125,23 +1144,23 @@ else if(cmd->speed == SPEED_100) xcvr = TYPHOON_XCVR_100HALF; else - return -EINVAL; + goto out; } else if(cmd->duplex == DUPLEX_FULL) { if(cmd->speed == SPEED_10) xcvr = TYPHOON_XCVR_10FULL; else if(cmd->speed == SPEED_100) xcvr = TYPHOON_XCVR_100FULL; else - return -EINVAL; + goto out; } else - return -EINVAL; + goto out; } INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_XCVR_SELECT); xp_cmd.parm1 = cpu_to_le16(xcvr); err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL); if(err < 0) - return err; + goto out; tp->xcvr_select = xcvr; if(cmd->autoneg == AUTONEG_ENABLE) { @@ -1152,93 +1171,80 @@ tp->duplex = cmd->duplex; } - return 0; +out: + return err; } -static inline int -typhoon_ethtool_ioctl(struct net_device *dev, void __user *useraddr) +static void +typhoon_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { - struct typhoon *tp = (struct typhoon *) dev->priv; - u32 ethcmd; + struct typhoon *tp = netdev_priv(dev); - if(copy_from_user(ðcmd, useraddr, sizeof(ethcmd))) - return -EFAULT; - - switch (ethcmd) { - case ETHTOOL_GDRVINFO: { - struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; - - typhoon_ethtool_gdrvinfo(tp, &info); - if(copy_to_user(useraddr, &info, sizeof(info))) - return -EFAULT; - return 0; - } - case ETHTOOL_GSET: { - struct ethtool_cmd cmd = { ETHTOOL_GSET }; - - typhoon_ethtool_gset(tp, &cmd); - if(copy_to_user(useraddr, &cmd, sizeof(cmd))) - return -EFAULT; - return 0; - } - case ETHTOOL_SSET: { - struct ethtool_cmd cmd; - if(copy_from_user(&cmd, useraddr, sizeof(cmd))) - return -EFAULT; + wol->supported = WAKE_PHY | WAKE_MAGIC; + wol->wolopts = 0; + if(tp->wol_events & TYPHOON_WAKE_LINK_EVENT) + wol->wolopts |= WAKE_PHY; + if(tp->wol_events & TYPHOON_WAKE_MAGIC_PKT) + wol->wolopts |= WAKE_MAGIC; + memset(&wol->sopass, 0, sizeof(wol->sopass)); +} - return typhoon_ethtool_sset(tp, &cmd); - } - case ETHTOOL_GLINK:{ - struct ethtool_value edata = { ETHTOOL_GLINK }; +static int +typhoon_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct typhoon *tp = netdev_priv(dev); - edata.data = netif_carrier_ok(dev) ? 1 : 0; - if(copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_GWOL: { - struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; + if(wol->wolopts & ~(WAKE_PHY | WAKE_MAGIC)) + return -EINVAL; - if(tp->wol_events & TYPHOON_WAKE_LINK_EVENT) - wol.wolopts |= WAKE_PHY; - if(tp->wol_events & TYPHOON_WAKE_MAGIC_PKT) - wol.wolopts |= WAKE_MAGIC; - if(copy_to_user(useraddr, &wol, sizeof(wol))) - return -EFAULT; - return 0; - } - case ETHTOOL_SWOL: { - struct ethtool_wolinfo wol; - - if(copy_from_user(&wol, useraddr, sizeof(wol))) - return -EFAULT; - tp->wol_events = 0; - if(wol.wolopts & WAKE_PHY) - tp->wol_events |= TYPHOON_WAKE_LINK_EVENT; - if(wol.wolopts & WAKE_MAGIC) - tp->wol_events |= TYPHOON_WAKE_MAGIC_PKT; - return 0; - } - default: - break; - } + tp->wol_events = 0; + if(wol->wolopts & WAKE_PHY) + tp->wol_events |= TYPHOON_WAKE_LINK_EVENT; + if(wol->wolopts & WAKE_MAGIC) + tp->wol_events |= TYPHOON_WAKE_MAGIC_PKT; - return -EOPNOTSUPP; + return 0; } -static int -typhoon_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static u32 +typhoon_get_rx_csum(struct net_device *dev) { - switch (cmd) { - case SIOCETHTOOL: - return typhoon_ethtool_ioctl(dev, ifr->ifr_data); - default: - break; - } - - return -EOPNOTSUPP; + /* For now, we don't allow turning off RX checksums. + */ + return 1; } +static void +typhoon_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) +{ + ering->rx_max_pending = RXENT_ENTRIES; + ering->rx_mini_max_pending = 0; + ering->rx_jumbo_max_pending = 0; + ering->tx_max_pending = TXLO_ENTRIES - 1; + + ering->rx_pending = RXENT_ENTRIES; + ering->rx_mini_pending = 0; + ering->rx_jumbo_pending = 0; + ering->tx_pending = TXLO_ENTRIES - 1; +} + +static struct ethtool_ops typhoon_ethtool_ops = { + .get_settings = typhoon_get_settings, + .set_settings = typhoon_set_settings, + .get_drvinfo = typhoon_get_drvinfo, + .get_wol = typhoon_get_wol, + .set_wol = typhoon_set_wol, + .get_link = ethtool_op_get_link, + .get_rx_csum = typhoon_get_rx_csum, + .get_tx_csum = ethtool_op_get_tx_csum, + .set_tx_csum = ethtool_op_set_tx_csum, + .get_sg = ethtool_op_get_sg, + .set_sg = ethtool_op_set_sg, + .get_tso = ethtool_op_get_tso, + .set_tso = ethtool_op_set_tso, + .get_ringparam = typhoon_get_ringparam, +}; + static int typhoon_wait_interrupt(unsigned long ioaddr) { @@ -1756,7 +1762,7 @@ static int typhoon_poll(struct net_device *dev, int *total_budget) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct typhoon_indexes *indexes = tp->indexes; int orig_budget = *total_budget; int budget, work_done, done; @@ -2068,7 +2074,7 @@ static void typhoon_tx_timeout(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); if(typhoon_reset(dev->base_addr, WaitNoSleep) < 0) { printk(KERN_WARNING "%s: could not reset in tx timeout\n", @@ -2098,7 +2104,7 @@ static int typhoon_open(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); int err; err = typhoon_wakeup(tp, WaitSleep); @@ -2140,7 +2146,7 @@ static int typhoon_close(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); netif_stop_queue(dev); @@ -2168,7 +2174,7 @@ typhoon_resume(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); /* If we're down, resume when we are upped. */ @@ -2200,7 +2206,7 @@ typhoon_suspend(struct pci_dev *pdev, u32 state) { struct net_device *dev = pci_get_drvdata(pdev); - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; /* If we're down, we're already suspended. @@ -2303,17 +2309,17 @@ goto error_out_dev; } - /* If we transitioned from D3->D0 in pci_enable_device(), - * we lost our configuration and need to restore it to the - * conditions at boot. - */ - pci_restore_state(pdev, NULL); + err = pci_set_mwi(pdev); + if(err < 0) { + printk(ERR_PFX "%s: unable to set MWI\n", pci_name(pdev)); + goto error_out_disable; + } - err = pci_set_dma_mask(pdev, 0xffffffffULL); + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if(err < 0) { printk(ERR_PFX "%s: No usable DMA configuration\n", pci_name(pdev)); - goto error_out_dev; + goto error_out_mwi; } /* sanity checks, resource #1 is our mmio area @@ -2323,25 +2329,22 @@ "%s: region #1 not a PCI MMIO resource, aborting\n", pci_name(pdev)); err = -ENODEV; - goto error_out_dev; + goto error_out_mwi; } if(pci_resource_len(pdev, 1) < 128) { printk(ERR_PFX "%s: Invalid PCI MMIO region size, aborting\n", pci_name(pdev)); err = -ENODEV; - goto error_out_dev; + goto error_out_mwi; } err = pci_request_regions(pdev, "typhoon"); if(err < 0) { printk(ERR_PFX "%s: could not request regions\n", pci_name(pdev)); - goto error_out_dev; + goto error_out_mwi; } - pci_set_master(pdev); - pci_set_mwi(pdev); - /* map our MMIO region */ ioaddr = pci_resource_start(pdev, 1); @@ -2366,7 +2369,7 @@ } dev->irq = pdev->irq; - tp = dev->priv; + tp = netdev_priv(dev); tp->shared = (struct typhoon_shared *) shared; tp->shared_dma = shared_dma; tp->pdev = pdev; @@ -2391,6 +2394,11 @@ goto error_out_dma; } + /* Now that we've reset the 3XP and are sure it's not going to + * write all over memory, enable bus mastering. + */ + pci_set_master(pdev); + /* dev->name is not valid until we register, but we need to * use some common routines to initialize the card. So that those * routines print the right name, we keep our oun pointer to the name @@ -2460,11 +2468,11 @@ dev->set_multicast_list = typhoon_set_rx_mode; dev->tx_timeout = typhoon_tx_timeout; dev->poll = typhoon_poll; + dev->ethtool_ops = &typhoon_ethtool_ops; dev->weight = 16; dev->watchdog_timeo = TX_TIMEOUT; dev->get_stats = typhoon_get_stats; dev->set_mac_address = typhoon_set_mac_address; - dev->do_ioctl = typhoon_ioctl; dev->vlan_rx_register = typhoon_vlan_rx_register; dev->vlan_rx_kill_vid = typhoon_vlan_rx_kill_vid; @@ -2527,6 +2535,10 @@ iounmap((void *) ioaddr); error_out_regions: pci_release_regions(pdev); +error_out_mwi: + pci_clear_mwi(pdev); +error_out_disable: + pci_disable_device(pdev); error_out_dev: free_netdev(dev); error_out: @@ -2537,7 +2549,7 @@ typhoon_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct typhoon *tp = (struct typhoon *) (dev->priv); + struct typhoon *tp = netdev_priv(dev); unregister_netdev(dev); pci_set_power_state(pdev, 0); @@ -2547,6 +2559,7 @@ pci_free_consistent(pdev, sizeof(struct typhoon_shared), tp->shared, tp->shared_dma); pci_release_regions(pdev); + pci_clear_mwi(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); free_netdev(dev); From davem@davemloft.net Fri Sep 10 14:13:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 14:13:29 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ALDJcC014632 for ; Fri, 10 Sep 2004 14:13:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5sdY-0005YB-00; Fri, 10 Sep 2004 14:08:52 -0700 Date: Fri, 10 Sep 2004 14:08:52 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: herbert@gondor.apana.org.au, fork0@users.sourceforge.net, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1+bk: assertion tcp_get_pcount failed at net/ipv4/tcp_input.c Message-Id: <20040910140852.7a970f3c.davem@davemloft.net> In-Reply-To: <41414C3D.2090606@us.ibm.com> References: <20040909111233.GA3987@steel.home> <20040910033055.GA26790@gondor.apana.org.au> <20040909222542.7a30c0e4.davem@davemloft.net> <41414C3D.2090606@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 657 Lines: 20 On Thu, 09 Sep 2004 23:39:57 -0700 Nivedita Singhvi wrote: > David S. Miller wrote: > > > Herbert did you see my division fix I made today for > > tso_factor calculation? I was dividing by the TSO mss > > instead of the normal one :-) > > Dave, I'm just catching up with the most recent > kernel (from 2.6.8.1 and a hiatus), and I believe > the fixes you refer to as well as the change in > tcp_init_cwnd (tso_factor etc) make TSO consistent > with the standard now. > > That correct? (And thanks, much appreciated, I was > about to fiddle with the same stuff :)). That's absolutely correct and this was the purpose of these changes. From davem@davemloft.net Fri Sep 10 14:25:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 14:25:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ALPGlR015025 for ; Fri, 10 Sep 2004 14:25:16 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5siW-0005Z0-00; Fri, 10 Sep 2004 14:14:00 -0700 Date: Fri, 10 Sep 2004 14:14:00 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: shemminger@osdl.org, tgraf@suug.ch, yoshfuji@wide.ad.jp, eric.lemoine@gmail.com, netdev@oss.sgi.com Subject: Re: iproute2 patch introducing mtu/txqlen/weight via rtnetlink Message-Id: <20040910141400.1cdf2e18.davem@davemloft.net> In-Reply-To: <1094822205.1125.113.camel@jzny.localdomain> References: <20040909164834.GB18994@postel.suug.ch> <20040909103344.5a448b01.davem@davemloft.net> <20040909175411.GB19155@postel.suug.ch> <20040910.103341.28767986.yoshfuji@wide.ad.jp> <20040910092948.GB19930@postel.suug.ch> <20040910024030.28b7c66c@linux.site> <1094822205.1125.113.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 417 Lines: 12 On 10 Sep 2004 09:16:46 -0400 jamal wrote: > > On Fri, 2004-09-10 at 05:40, Stephen Hemminger wrote: > > Unless there is some compelling reason, I think that keeping the old ioctl > > interface for a least a year until the kernel changes become more ubiquitous. > > I think that iproute2 should first attempt to use netlink and on failure > switch to ioctls. This is what I would recommend too. From davem@davemloft.net Fri Sep 10 14:55:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 14:55:36 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ALtU0l015715 for ; Fri, 10 Sep 2004 14:55:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5tL4-0005iO-00; Fri, 10 Sep 2004 14:53:50 -0700 Date: Fri, 10 Sep 2004 14:53:50 -0700 From: "David S. Miller" To: Herbert Xu Cc: kuznet@ms2.inr.ac.ru, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [IPSEC] Find larval SAs by sequence number Message-Id: <20040910145350.26847bec.davem@davemloft.net> In-Reply-To: <20040909121332.GA31902@gondor.apana.org.au> References: <20040909121332.GA31902@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 560 Lines: 13 On Thu, 9 Sep 2004 22:13:32 +1000 Herbert Xu wrote: > When larval states are generated along with ACQUIRE messages, we should > use the sequence to find the corresponding larval state when creating > states with ADD_SA or ALLOC_SPI. > > If we don't do that, then it may take down an unrelated larval state > with the same parameters (think different TCP sessions). This not only > leaves behind a larval state that shouldn't be there, it may also cause > another ACQUIRE message to be sent unnecessarily. Looks good, applied. From davem@davemloft.net Fri Sep 10 14:56:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 14:56:43 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ALucKU015899 for ; Fri, 10 Sep 2004 14:56:38 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5tMI-0005ip-00; Fri, 10 Sep 2004 14:55:06 -0700 Date: Fri, 10 Sep 2004 14:55:06 -0700 From: "David S. Miller" To: James Morris Cc: herbert@gondor.apana.org.au, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-ppp@vger.kernel.org, paulus@samba.org Subject: Re: [IPCOMP] Use per-cpu buffers Message-Id: <20040910145506.4b3933c4.davem@davemloft.net> In-Reply-To: References: <20040910111047.GA29330@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 536 Lines: 14 On Fri, 10 Sep 2004 11:42:00 -0400 (EDT) James Morris wrote: > On Fri, 10 Sep 2004, Herbert Xu wrote: > > > James, can you think of a general solution to the 64K buffer in > > terms of the crypto decompression interface? > > I haven't looked at the code for a while, but I think we might be able to > save some memory by specifying compression parameters and making the > appropriate changes to zlib. For now I'm going to put in Herbert's per-cpu patch, and we can try to come up with something better later. From davem@davemloft.net Fri Sep 10 14:59:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 14:59:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ALxHqm016369 for ; Fri, 10 Sep 2004 14:59:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5tPT-0005jH-00; Fri, 10 Sep 2004 14:58:23 -0700 Date: Fri, 10 Sep 2004 14:58:22 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IP6IP6] Handle ECN correctly Message-Id: <20040910145822.09b58835.davem@davemloft.net> In-Reply-To: <20040910070242.GA28017@gondor.apana.org.au> References: <20040909034508.GA19547@gondor.apana.org.au> <20040908214023.08dec350.davem@davemloft.net> <20040909044336.GA19999@gondor.apana.org.au> <20040908214926.51b56a66.davem@davemloft.net> <20040909045415.GA20079@gondor.apana.org.au> <20040908220802.1c25b806.davem@davemloft.net> <20040910003158.GA25335@gondor.apana.org.au> <20040910070242.GA28017@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 702 Lines: 20 On Fri, 10 Sep 2004 17:02:42 +1000 Herbert Xu wrote: > On Fri, Sep 10, 2004 at 10:31:58AM +1000, herbert wrote: > > > > Hmm, perhaps I'm still confused. But it seems that the ability to > > set the TOS to any value other than *1 is already there for ipip/ip_gre. > > > > That feature is missing for SIT and IPsec though. > > > > We may also want to use the TOS value from parms to decide whether we want > > to encapsulate/decapsulate ECN. > > > > Is my understanding correct? > > Obviously not. Although we've got this stuff on the transmit side, > we don't do this on the receive side. That's right, on decap we don't provide a way to choose the TOS selection. From jdmason@us.ibm.com Fri Sep 10 14:59:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 14:59:36 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ALxU4s016412 for ; Fri, 10 Sep 2004 14:59:31 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8ALx3bZ674480; Fri, 10 Sep 2004 17:59:03 -0400 Received: from dreadnought.austin.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ALx2gB379632; Fri, 10 Sep 2004 15:59:03 -0600 From: Jon Mason Organization: IBM To: netdev@oss.sgi.com Subject: [PATCH] r8169 cleanup Date: Fri, 10 Sep 2004 16:59:00 -0500 User-Agent: KMail/1.6.2 Cc: romieu@fr.zoreil.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200409101659.00322.jdmason@us.ltcfwd.linux.ibm.com> X-archive-position: 8618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1306 Lines: 39 Removal of unnecessary code. In the first part, the double not is not necessary. In the second part, Tx timeouts are already logged and this line is not needed. Finally, a bit of code beautification (though it may only be for my eyes). Thanks, Jon --- /usr/src/linux-2.6.9-rc1-mm4/drivers/net/r8169.c 2004-09-10 11:16:57.535521016 -0500 +++ r8169.c 2004-09-10 16:06:49.398539048 -0500 @@ -654,7 +654,7 @@ static u32 rtl8169_get_rx_csum(struct ne { struct rtl8169_private *tp = netdev_priv(dev); - return !!(tp->cp_cmd & RxChkSum); + return (tp->cp_cmd & RxChkSum); } static int rtl8169_set_rx_csum(struct net_device *dev, u32 data) @@ -1694,7 +1694,6 @@ rtl8169_tx_timeout(struct net_device *de void *ioaddr = tp->mmio_addr; u8 tmp8; - printk(KERN_INFO "%s: TX Timeout\n", dev->name); /* disable Tx, if not already */ tmp8 = RTL_R8(ChipCmd); if (tmp8 & CmdTxEnb) @@ -1779,8 +1778,7 @@ static int rtl8169_start_xmit(struct sk_ struct TxDesc *txd = tp->TxDescArray + entry; void *ioaddr = tp->mmio_addr; dma_addr_t mapping; - u32 status, len; - u32 opts1; + u32 status, len, opts1; int ret = 0; if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) { From davem@davemloft.net Fri Sep 10 15:09:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 15:09:22 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AM9GpW017192 for ; Fri, 10 Sep 2004 15:09:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5tZ3-0005o6-00; Fri, 10 Sep 2004 15:08:17 -0700 Date: Fri, 10 Sep 2004 15:08:17 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: pekkas@netcore.fi, netdev@oss.sgi.com, kunitake@linux-ipv6.org, yoshfuji@linux-ipv6.org, aesop-core@kame.net Subject: Re: [PATCH] IPV6: Deprecate All-on-link Assumption Message-Id: <20040910150817.1c86df86.davem@davemloft.net> In-Reply-To: <20040910.104830.121402882.yoshfuji@linux-ipv6.org> References: <20040910.104830.121402882.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8AM9GpW017192 X-archive-position: 8619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 538 Lines: 13 On Fri, 10 Sep 2004 10:48:30 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > If we don't have IPv6 default routes, we assume all ipv6 destinations > are on-link as specified in RFC2461. It, however, is considered harmful now; > it is problematic with IPv6-capable nodes that do not have off-link > IPv6 connectivity (eg no default routers) and such nodes will take > a few seconds until they fall back to use IPv4. > > See for details. Applied, thank you. From davem@davemloft.net Fri Sep 10 15:11:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 15:11:28 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AMBNiY017528 for ; Fri, 10 Sep 2004 15:11:23 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5tbB-0006Bj-00; Fri, 10 Sep 2004 15:10:29 -0700 Date: Fri, 10 Sep 2004 15:10:29 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] [NETFILTER] Fix "undefined reference" error if CONFIG_SYSCTL=n Message-Id: <20040910151029.7795e336.davem@davemloft.net> In-Reply-To: <20040910.153135.121099678.yoshfuji@linux-ipv6.org> References: <20040910.153135.121099678.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8AMBNiY017528 X-archive-position: 8620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 372 Lines: 12 On Fri, 10 Sep 2004 15:31:35 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Fix the following error if CONFIG_SYSCTL=n. > > | net/built-in.o: In function `tcp_in_window': > | net/built-in.o(.text+0x49571): undefined reference to `ip_ct_log_invalid' ... > Signed-off-by: Hideaki YOSHIFUJI Applied, thanks. From herbert@gondor.apana.org.au Fri Sep 10 15:34:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 15:34:28 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AMYKIT018021 for ; Fri, 10 Sep 2004 15:34:20 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C5txK-0003V3-00; Sat, 11 Sep 2004 08:33:22 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C5txD-0000Lo-00; Sat, 11 Sep 2004 08:33:15 +1000 Date: Sat, 11 Sep 2004 08:33:15 +1000 To: James Morris Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-ppp@vger.kernel.org, paulus@samba.org Subject: Re: [IPCOMP] Use per-cpu buffers Message-ID: <20040910223315.GA1335@gondor.apana.org.au> References: <20040910111047.GA29330@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 689 Lines: 18 On Fri, Sep 10, 2004 at 11:42:00AM -0400, James Morris wrote: > > I haven't looked at the code for a while, but I think we might be able to > save some memory by specifying compression parameters and making the > appropriate changes to zlib. It'd also be nice to add a compression algorithm that requires little memory to run. That way we can get a clear picture of what interface changes are OK and what aren't. Could we perhaps use v44? Is the patent an issue? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Fri Sep 10 15:51:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 15:51:58 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AMpo2i018449 for ; Fri, 10 Sep 2004 15:51:51 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 949F381 for ; Sat, 11 Sep 2004 00:51:16 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 6F8DE1C0E8; Sat, 11 Sep 2004 00:51:58 +0200 (CEST) Date: Sat, 11 Sep 2004 00:51:58 +0200 From: Thomas Graf To: netdev@oss.sgi.com Subject: [RFC] Extend netlink error codes Message-ID: <20040910225158.GO20088@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1123 Lines: 37 The current situation with error codes sent back to a netlink application is unsatisfactory. Most often, the application receives EINVAL but has no idea what was wrong. Here is my plan: Introduce some macros: #define NLERR_MAJ_MASK (0x7FFF0000U) #define NLERR_MIN_MASK (0x0000FFFFU) #define NLERR_MAJ(e) ((abs(e) & NLERR_MAJ_MASK) >> 16) #define NLERR_MIN(e) (abs(e) & NLERR_MIN_MASK) #define NLERR_MAKE(err, nle) ((((nle) << 16) & NLERR_MAJ_MASK) | ((err) & NLERR_MIN_MASK)) Specify netlink specific error codes, e.g.: #define NLE_SUCCESS 0 #define NLE_NOQDISC 1 #define NLE_NOTCLASFUL 2 ... Predefined error messages could be provided by libnetlink via nl_strerror(). Replace vague error return calls with something like: return -NLERR_MAKE(EINVAL, NLE_NOQDISC); Once in netlink_ack, split the combined error message again, fill the existing errno into nlerrmsg.error and provide the netlink specific error code in a newly introduced TLV. This way, no binaries or old applications would break, but applications can support it and provide more meanigful error message with almost no effort. Comments? From hadi@cyberus.ca Fri Sep 10 15:58:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 15:58:19 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AMwErd018915 for ; Fri, 10 Sep 2004 15:58:14 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091015593161:36359 ; Fri, 10 Sep 2004 15:59:31 -0700 Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: jt@hpl.hp.com, netdev@oss.sgi.com In-Reply-To: <20040910204348.GL20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> Organization: jamalopolis Message-Id: <1094857082.1041.19.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 18:58:02 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 03:59:32 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 03:59:33 PM, Serialize complete at 09/10/2004 03:59:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1294 Lines: 30 On Fri, 2004-09-10 at 16:43, Thomas Graf wrote: > * Jean Tourrilhes <20040910203203.GA17078@bougret.hpl.hp.com> 2004-09-10 13:32 > > On Fri, Sep 10, 2004 at 10:22:35PM +0200, Thomas Graf wrote: > > > > > > 2) Implement NETDEV_CHANGE, I was actually about to implement this > > > but it's not directly related to this change and requires the same > > > effort by the user space application has refetching the link list. > > > > Do you have any info on NETDEV_CHANGE, I've got a potential > > use for it. > > (By the way, there are other ways to do it, but if > > NETDEV_CHANGE is the proposed standard, I might as well use it). > > Currently call_netdevice_notifiers is called and sends out a > RTM_NEWLINK message with the new interface name to everyone > wanting to be notified. However, ifi_change is kept to 0 > so far, which means you have to look what has changed yourself. I'm > not sure if this can be changed without too much troubles but > I will look into it. I missed the RTM_NEWLINK part. It is easier to just keep it that way and make sure it is well documented as so. It may not be trivial (as an example all the inetdev name attributes change - look at inetdev_event). So suggestion is to leave it to user space to find more details about the event. cheers, jamal From davem@davemloft.net Fri Sep 10 16:03:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 16:03:14 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AN39QR019603 for ; Fri, 10 Sep 2004 16:03:10 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5uPB-0006Gz-00; Fri, 10 Sep 2004 16:02:09 -0700 Date: Fri, 10 Sep 2004 16:02:09 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-Id: <20040910160209.4f5d8577.davem@davemloft.net> In-Reply-To: <1094823215.1121.129.camel@jzny.localdomain> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 998 Lines: 24 On 10 Sep 2004 09:33:35 -0400 jamal wrote: > On Wed, 2004-09-08 at 16:47, David S. Miller wrote: > > > > > We are merely moving the sch_generic.c locking logic into the > > drivers. The behavior is entirely equivalent except that one > > level of unnecessary locking has been removed. > > > > I think his change is valid, will not break existing drivers (as > > you mentioned as well Jamal), and works well for the cases he has > > shown patches of. So I'm going to apply his patch. > > > > BTW, if we are really concerned about some existing driver returning > > -1 from hard_start_xmit() without the new feature flag being enabled, > > we can test for that and log a debugging message if it happens. > > I am not 100% happy but let me do some testing on it. Would the best > image be the latest bk snapshot? Yes, Andi's code plus e1000 and tg3 driver uses are in current 2.6.x BK. Just grep for NETIF_F_LLTX in drivers/net/tg3.c to be sure you've got it in your tree. From davem@davemloft.net Fri Sep 10 16:08:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 16:08:34 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8AN8Th5020283 for ; Fri, 10 Sep 2004 16:08:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5uUT-0006Hr-00; Fri, 10 Sep 2004 16:07:37 -0700 Date: Fri, 10 Sep 2004 16:07:36 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [RFC] Extend netlink error codes Message-Id: <20040910160736.309bc29c.davem@davemloft.net> In-Reply-To: <20040910225158.GO20088@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 477 Lines: 13 On Sat, 11 Sep 2004 00:51:58 +0200 Thomas Graf wrote: > Once in netlink_ack, split the combined error message again, > fill the existing errno into nlerrmsg.error and provide the > netlink specific error code in a newly introduced TLV. This > way, no binaries or old applications would break, but > applications can support it and provide more meanigful error > message with almost no effort. It sounds like it could work. Jamal, any objections to his idea? From davem@davemloft.net Fri Sep 10 16:11:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 16:11:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ANBlMj020652 for ; Fri, 10 Sep 2004 16:11:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5uRX-0006HN-00; Fri, 10 Sep 2004 16:04:35 -0700 Date: Fri, 10 Sep 2004 16:04:34 -0700 From: "David S. Miller" To: Thomas Graf Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-Id: <20040910160434.3c24cafd.davem@davemloft.net> In-Reply-To: <20040910204348.GL20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1139 Lines: 26 On Fri, 10 Sep 2004 22:43:48 +0200 Thomas Graf wrote: > * Jean Tourrilhes <20040910203203.GA17078@bougret.hpl.hp.com> 2004-09-10 13:32 > > On Fri, Sep 10, 2004 at 10:22:35PM +0200, Thomas Graf wrote: > > > > > > 2) Implement NETDEV_CHANGE, I was actually about to implement this > > > but it's not directly related to this change and requires the same > > > effort by the user space application has refetching the link list. > > > > Do you have any info on NETDEV_CHANGE, I've got a potential > > use for it. > > (By the way, there are other ways to do it, but if > > NETDEV_CHANGE is the proposed standard, I might as well use it). > > Currently call_netdevice_notifiers is called and sends out a > RTM_NEWLINK message with the new interface name to everyone > wanting to be notified. However, ifi_change is kept to 0 > so far, which means you have to look what has changed yourself. I'm > not sure if this can be changed without too much troubles but > I will look into it. For now I'm going to apply Thomas's name changing patch (with the sizeof() fix suggested by Yoshifuji), and we can enhance it later. From tgraf@suug.ch Fri Sep 10 16:17:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 16:17:23 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ANHHdX021183 for ; Fri, 10 Sep 2004 16:17:17 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 5714581; Sat, 11 Sep 2004 01:16:44 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 9DA931C0E8; Sat, 11 Sep 2004 01:17:26 +0200 (CEST) Date: Sat, 11 Sep 2004 01:17:26 +0200 From: Thomas Graf To: jamal Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040910231726.GP20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094857082.1041.19.camel@jzny.localdomain> X-archive-position: 8627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1793 Lines: 40 * jamal <1094857082.1041.19.camel@jzny.localdomain> 2004-09-10 18:58 > On Fri, 2004-09-10 at 16:43, Thomas Graf wrote: > > Currently call_netdevice_notifiers is called and sends out a > > RTM_NEWLINK message with the new interface name to everyone > > wanting to be notified. However, ifi_change is kept to 0 > > so far, which means you have to look what has changed yourself. I'm > > not sure if this can be changed without too much troubles but > > I will look into it. > > I missed the RTM_NEWLINK part. It is easier to just keep it that way and > make sure it is well documented as so. It may not be trivial (as an > example all the inetdev name attributes change - look at inetdev_event). > So suggestion is to leave it to user space to find more details about > the event. I agree, most applications will hold a cache of all links, like iproute2 is doing, and just update the cache. There is one remaining problem, currently, changes via rtnetlink will result in multiple notifies being sent out because NETDEV_CHANGEMTU and NETDEV_CHANGENAME are invoked as well and result in a netlink message. Changing them to not do anything in rtnetlink context would solve it but we would lose the notify if the change was made via ioctl. The patch below would fixes the multiple notifies issue but prevents notification upon ioctl via rtnetlink.. Any ideas how to work around this other than not using dev_change_name and dev_set_mtu? --- linux-2.6.9-rc1-bk15.orig/net/core/rtnetlink.c 2004-09-08 18:33:42.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/rtnetlink.c 2004-09-11 01:06:29.000000000 +0200 @@ -607,6 +626,8 @@ break; case NETDEV_CHANGE: case NETDEV_GOING_DOWN: + case NETDEV_CHANGEMTU: + case NETDEV_CHANGENAME: break; default: rtmsg_ifinfo(RTM_NEWLINK, dev, 0); From davem@davemloft.net Fri Sep 10 16:44:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 16:44:59 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ANispH025463 for ; Fri, 10 Sep 2004 16:44:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5v3a-0006Lk-00; Fri, 10 Sep 2004 16:43:54 -0700 Date: Fri, 10 Sep 2004 16:43:54 -0700 From: "David S. Miller" To: David Woodhouse Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Compat32 setsockopt overzealous conversions Message-Id: <20040910164354.3cdffa59.davem@davemloft.net> In-Reply-To: <1094716398.15909.27.camel@localhost.localdomain> References: <1094563381.5122.8.camel@localhost.localdomain> <20040907140649.42eaa278.davem@davemloft.net> <1094716398.15909.27.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 618 Lines: 14 On Thu, 09 Sep 2004 08:53:18 +0100 David Woodhouse wrote: 2.4.x patch applied, thanks David. > Back in the real world of 2.6, we REALLY do need to stop trying to do > all this in a sockopt syscall wrapper, and instead pass down a 32/64 bit > flag to the code which actually handles the sockopt -- although the > optlen ought to be sufficient for the _majority_ of cases. Or maybe we > should handle it like we do ioctls? That latter idea (doing it like ioctls) is an option, and in fact I like it since it would allow us to push the complicated netfilter translators into the netfilter code. From wsonguci@yahoo.com Fri Sep 10 17:52:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 17:53:04 -0700 (PDT) Received: from web40007.mail.yahoo.com (web40007.mail.yahoo.com [66.218.78.25]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8B0qx2G026429 for ; Fri, 10 Sep 2004 17:52:59 -0700 Message-ID: <20040911005245.61679.qmail@web40007.mail.yahoo.com> Received: from [63.87.1.243] by web40007.mail.yahoo.com via HTTP; Fri, 10 Sep 2004 17:52:45 PDT Date: Fri, 10 Sep 2004 17:52:45 -0700 (PDT) From: Song Wang Subject: [Routing] Performance Comparison between 2.6 and 2.4 kernel To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wsonguci@yahoo.com Precedence: bulk X-list: netdev Content-Length: 543 Lines: 22 Hi, I'm looking for the network packet routing performance comparison between the latest 2.4 and 2.6 kernel. I did some initial testing on my mips-based router. 2.6 kernel (2.6.8.1) performed way below 2.4 kernel (2.4.17). It sucks. Turning on preemption on 2.6 kernel even makes routing performance worse. Anybody did a comprehensive study on the routing performance for 2.6 and 2.4 kernel? Thanks. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From wsonguci@yahoo.com Fri Sep 10 17:55:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 17:55:26 -0700 (PDT) Received: from web40007.mail.yahoo.com (web40007.mail.yahoo.com [66.218.78.25]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8B0tLmm026681 for ; Fri, 10 Sep 2004 17:55:21 -0700 Message-ID: <20040911005507.62262.qmail@web40007.mail.yahoo.com> Received: from [63.87.1.243] by web40007.mail.yahoo.com via HTTP; Fri, 10 Sep 2004 17:55:07 PDT Date: Fri, 10 Sep 2004 17:55:07 -0700 (PDT) From: Song Wang Subject: [PATCH 2.6.9-rc1] handle error msg "driver changed get_stats after register" To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wsonguci@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1665 Lines: 63 This patch is against 2.6.9-rc1. In net/core/dev.c: dev_open if (get_stats_changed(dev) && net_ratelimit()) { printk(KERN_ERR "%s: driver changed get_stats after register\n", dev->name); } static inline int get_stats_changed(struct net_device *dev) { int changed = dev->last_stats != dev->get_stats; dev->last_stats = dev->get_stats; return changed; } get_stats_changed checks if dev->last_stats has been changed after the registration when opening the net device. However, the initialization of dev->last_stats is done in net/core/net-sysfs.c, which is only compiled when CONFIG_SYSFS is enabled. So if we don't enable CONFIG_SYSFS (for example, embedded system may not need it for saving space.), all the network device drivers will have an error message "driver changed get_stats after register" printed on the console when you try to ifconfig it, because dev->last_stats is never initialized. The following patch adds the initialization of dev->last_stats in register_netdevice function. -Song diff -Naur linux-2.6.9-rc1/net/core/dev.c linux-2.6.9-rc1.mod/net/core/dev.c --- linux-2.6.9-rc1/net/core/dev.c 2004-08-31 18:51:06.000000000 -0700 +++ linux-2.6.9-rc1.mod/net/core/dev.c 2004-08-31 19:11:35.407452369 -0700 @@ -2872,6 +2872,8 @@ dev->iflink = -1; + dev->last_stats = dev->get_stats; + /* Init, if this function is available */ if (dev->init) { ret = dev->init(dev); __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From davem@davemloft.net Fri Sep 10 18:02:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 18:02:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B1265M027199 for ; Fri, 10 Sep 2004 18:02:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C5wGP-0006QY-00; Fri, 10 Sep 2004 18:01:13 -0700 Date: Fri, 10 Sep 2004 18:01:13 -0700 From: "David S. Miller" To: Song Wang Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [PATCH 2.6.9-rc1] handle error msg "driver changed get_stats after register" Message-Id: <20040910180113.47d13658.davem@davemloft.net> In-Reply-To: <20040911005507.62262.qmail@web40007.mail.yahoo.com> References: <20040911005507.62262.qmail@web40007.mail.yahoo.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 457 Lines: 17 On Fri, 10 Sep 2004 17:55:07 -0700 (PDT) Song Wang wrote: > This patch is against 2.6.9-rc1. > > In net/core/dev.c: dev_open > > if (get_stats_changed(dev) && net_ratelimit()) { > printk(KERN_ERR "%s: driver changed > get_stats after register\n", > dev->name); > } I think we should just get rid of this debugging hack, we fixed all the drivers I think. Stephen, what do you think? From hadi@cyberus.ca Fri Sep 10 18:39:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 18:39:17 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B1dCcP027871 for ; Fri, 10 Sep 2004 18:39:12 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091018402776:36477 ; Fri, 10 Sep 2004 18:40:27 -0700 Subject: Re: [RFC] Extend netlink error codes From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Thomas Graf , netdev@oss.sgi.com In-Reply-To: <20040910160736.309bc29c.davem@davemloft.net> References: <20040910225158.GO20088@postel.suug.ch> <20040910160736.309bc29c.davem@davemloft.net> Organization: jamalopolis Message-Id: <1094866738.1042.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 21:38:59 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 06:40:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 06:40:31 PM, Serialize complete at 09/10/2004 06:40:31 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1536 Lines: 49 On Fri, 2004-09-10 at 19:07, David S. Miller wrote: > On Sat, 11 Sep 2004 00:51:58 +0200 > Thomas Graf wrote: > > > Once in netlink_ack, split the combined error message again, > > fill the existing errno into nlerrmsg.error and provide the > > netlink specific error code in a newly introduced TLV. This > > way, no binaries or old applications would break, but > > applications can support it and provide more meanigful error > > message with almost no effort. > > It sounds like it could work. > > Jamal, any objections to his idea? I think its a good idea. so, questions: classical ABI issues a) old kernel vs new app b) new kernel vs old app i.e: The use of existing error codes is still valuable. Existing apps will do: errno = msg->error perror("some message"); and lastly: c) how to make sure no conflicts ever with updates to errno.h in the case of b) one solution is to introduce a new flag NLM_F_NERR that signals kernel that we have a new app. In such a case, a newer kernel gives a more precise error code and sets that same flag; old kernels ignore such a flag - and by not setting it newer apps understand to use old errno scheme. In this case old apps should ignore the flag. All this is assuming that previously unused flags followed principle of "Must be Zero on sending and ignore when receiving" principle for reserved bits ;-> or as otherwise known as Postels rule these days "Be liberal in what you accept and conservative in what you send"[1] cheers, jamal [1] Jon Postel, RFC 1122 From sriharivijayaraghavan@yahoo.com.au Fri Sep 10 18:41:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 18:41:27 -0700 (PDT) Received: from smtp207.mail.sc5.yahoo.com (smtp207.mail.sc5.yahoo.com [216.136.129.97]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8B1fEFH028083 for ; Fri, 10 Sep 2004 18:41:15 -0700 Received: from unknown (HELO ?192.168.0.2?) (sriharivijayaraghavan@150.101.153.12 with plain) by smtp207.mail.sc5.yahoo.com with SMTP; 11 Sep 2004 01:41:04 -0000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: r8169 - panic and a fix Date: Sat, 11 Sep 2004 11:47:23 +1000 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <20040908190603.GA19634@electric-eye.fr.zoreil.com> <200409100008.06541.sriharivijayaraghavan@yahoo.com.au> In-Reply-To: <200409100008.06541.sriharivijayaraghavan@yahoo.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_rklQBn9CAyBYVfG" Message-Id: <200409111147.24064.sriharivijayaraghavan@yahoo.com.au> X-archive-position: 8633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sriharivijayaraghavan@yahoo.com.au Precedence: bulk X-list: netdev Content-Length: 4787 Lines: 120 --Boundary-00=_rklQBn9CAyBYVfG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, 10 Sep 2004 12:08 am, Srihari Vijayaraghavan wrote: > ... > I am doing this task, and will post the results a little later. > > > --- drivers/net/r8169.c 2004-09-08 20:15:01.000000000 +0200 > > +++ dirvers/net/r8169.c 2004-09-08 20:49:58.000000000 +0200 > > @@ -52,6 +52,7 @@ VERSION 1.2 <2002/11/30> > Francois, (Sorry I have to reply to my own email, that is because of the private emails we had.) Thanks for your debug patch (against 2.6.9-rc1-bk17) and complete r8169.c, although I only used the debug patch. I have attached your debug patch for completeness. The bad news is that I see no "Assertion failed!" messages from the kernel. Here is the complete kernel BUG and subsequent panic messages: NET: Registered protocol family 1 ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at skbuff:91 invalid operand: 0000 [1] CPU 0 Modules linked in: r8169 af_packet ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables ide_cd cdrom via_rhine mii cr c32 floppy radeon reiserfs dm_mod uhci_hcd ehci_hcd usbcore button rtc unix Pid: 1421, comm: ifup Not tainted 2.6.9-rc1-bk17-r8169 RIP: 0010:[] {skb_over_panic+50} RSP: 0000:ffffffff8039bc28 EFLAGS: 00010292 RAX: 0000000000000036 RBX: 0000000000000c00 RCX: 000000000001ffff RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffffffff802fa2a0 RBP: 000001003a233360 R08: 0000000000000036 R09: 0000000000000003 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000bfc R13: 0000000000000000 R14: 0000000000000000 R15: 0000010036fb6000 FS: 0000002a9556cd60(0000) GS:ffffffff803f3040(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000039cbd054d0 CR3: 0000000000101000 CR4: 00000000000006e0 Process ifup (pid: 1421, threadinfo 0000010036ed6000, task 000001003f76e0b0) Stack: 000000000000000a ffffffffa00fb380 0000000000000bfc ffffffffa00fb7e0 000001008039bc68 000001003a233000 000001003fc36a80 0000000000008001 ffffff0000052000 0000000000000014 Call Trace: {:r8169:rtl8169_rx_interrupt+688} {:r8169:pci_unmap_single+0} {:r8169:rtl8169_interrupt+147} {handle_IRQ_event+44} {do_IRQ+147} {ret_from_intr+0} {__alloc_pages+830} {wake_up_page+12} {wake_up_page+9} {do_wp_page+132} {handle_mm_fault+330} {do_page_fault+350} {do_fork+324} {thread_return+41} {error_exit+0} Code: 0f 0b f4 47 2d 80 ff ff ff ff 5b 00 48 83 c4 08 c3 66 66 66 RIP {skb_over_panic+50} RSP <0>Kernel panic - not syncing: Aiee, killing interrupt handler! (As you would have probably guessed the vanilla 2.6.9-rc1 r8169.c on 2.6.9-rc1-bk17 works just fine.) Thank you. Hari. --Boundary-00=_rklQBn9CAyBYVfG Content-Type: text/x-diff; charset="utf-8"; name="r8169-dbg.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="r8169-dbg.patch" --- linux-2.6.9-rc1-bk17.orig/drivers/net/r8169.c 2004-09-10 21:57:57.000000000 +0200 +++ linux-2.6.9-rc1-bk17/drivers/net/r8169.c 2004-09-10 22:35:39.000000000 +0200 @@ -53,13 +53,14 @@ VERSION 1.2 <2002/11/30> #define RTL8169_DRIVER_NAME MODULENAME " Gigabit Ethernet driver " RTL8169_VERSION #define PFX MODULENAME ": " +#define RTL8169_DEBUG #ifdef RTL8169_DEBUG #define assert(expr) \ if(!(expr)) { \ - printk( "Assertion failed! %s,%s,%s,line=%d\n", \ + printk(KERN_ERR "Assertion failed! %s,%s,%s,line=%d\n", \ #expr,__FILE__,__FUNCTION__,__LINE__); \ } -#define dprintk(fmt, args...) do { printk(PFX fmt, ## args) } while (0) +#define dprintk(fmt, args...) do { printk(PFX fmt, ## args); } while (0) #else #define assert(expr) do {} while (0) #define dprintk(fmt, args...) do {} while (0) @@ -1308,7 +1309,7 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(EarlyTxThres, EarlyTxThld); // For gigabit rtl8169 - RTL_W16(RxMaxSize, RxPacketMaxSize); + RTL_W16(RxMaxSize, RX_BUF_SIZE); // Set Rx Config register i = rtl8169_rx_config | @@ -1698,6 +1699,7 @@ rtl8169_rx_interrupt(struct net_device * pci_action(tp->pci_dev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + assert(pkt_size <= RX_BUF_SIZE); skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); rtl8169_rx_skb(skb); --Boundary-00=_rklQBn9CAyBYVfG-- From hadi@cyberus.ca Fri Sep 10 19:01:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 19:01:26 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B21MME028886 for ; Fri, 10 Sep 2004 19:01:22 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091019023953:36495 ; Fri, 10 Sep 2004 19:02:39 -0700 Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: jt@hpl.hp.com, netdev@oss.sgi.com In-Reply-To: <20040910231726.GP20088@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> <20040910231726.GP20088@postel.suug.ch> Organization: jamalopolis Message-Id: <1094868070.1042.77.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 22:01:10 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 07:02:39 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 07:02:41 PM, Serialize complete at 09/10/2004 07:02:41 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 571 Lines: 18 On Fri, 2004-09-10 at 19:17, Thomas Graf wrote: > There is one remaining problem, currently, changes via rtnetlink will > result in multiple notifies being sent out because NETDEV_CHANGEMTU > and NETDEV_CHANGENAME are invoked as well and result in a netlink > message. Changing them to not do anything in rtnetlink context > would solve it but we would lose the notify if the change was made > via ioctl. > notify via ioctls is still needed. Are you changing MTU and NAME at the same time? Valid to receive the two updates i would think in that case. cheers, jamal From hadi@cyberus.ca Fri Sep 10 19:11:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 19:11:49 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B2BjYI029316 for ; Fri, 10 Sep 2004 19:11:45 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091019130265:36502 ; Fri, 10 Sep 2004 19:13:02 -0700 Subject: Re: [Routing] Performance Comparison between 2.6 and 2.4 kernel From: jamal Reply-To: hadi@cyberus.ca To: Song Wang Cc: netdev@oss.sgi.com In-Reply-To: <20040911005245.61679.qmail@web40007.mail.yahoo.com> References: <20040911005245.61679.qmail@web40007.mail.yahoo.com> Organization: jamalopolis Message-Id: <1094868693.1041.86.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Sep 2004 22:11:34 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 07:13:03 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/10/2004 07:13:03 PM, Serialize complete at 09/10/2004 07:13:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 8635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 946 Lines: 36 What mips board is this? NAPI based? I would say that you should get higher numbers with 2.6.x. Are you running any sort of apps that need gettimeofday? I have certainly seen higher numbers on 2.6 vs 2.4 starting at some point where Andis gettimeofday patch went in - but this was on x86. cheers, jamal On Fri, 2004-09-10 at 20:52, Song Wang wrote: > Hi, > > I'm looking for the network packet routing > performance comparison between the latest 2.4 > and 2.6 kernel. > > I did some initial testing on my mips-based router. > 2.6 kernel (2.6.8.1) performed way below 2.4 kernel > (2.4.17). It sucks. Turning on preemption on 2.6 > kernel even makes routing performance worse. > > Anybody did a comprehensive study on the routing > performance for 2.6 and 2.4 kernel? > > Thanks. > > > > __________________________________ > Do you Yahoo!? > Y! Messenger - Communicate in real time. Download now. > http://messenger.yahoo.com > > From acme@conectiva.com.br Fri Sep 10 20:23:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 10 Sep 2004 20:23:58 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B3Nics001141 for ; Fri, 10 Sep 2004 20:23:45 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id D4732473CC; Sat, 11 Sep 2004 00:23:30 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 144CA47402 for ; Sat, 11 Sep 2004 00:23:30 -0300 (BRT) Received: (qmail 17260 invoked by uid 0); 11 Sep 2004 04:21:17 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 11 Sep 2004 04:21:17 -0000 Received: from [192.168.0.2] (brinquedo [192.168.0.2]) by oops.ghostprotocols.net (Postfix) with ESMTP id D2C001462B; Sat, 11 Sep 2004 00:25:42 -0300 (BRT) From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. To: "David S.Miller" Subject: [PATCH][NET] generalise per socket slab cache use Date: Sat, 11 Sep 2004 00:23:32 -0300 User-Agent: KMail/1.7 Cc: Sridhar Samudrala , YOSHIFUJI Hideaki , netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_2+mQBno0jqk1vLs" Message-Id: <200409110023.34342.acme@conectiva.com.br> X-Bogosity: No, tests=bogofilter, spamicity=0.499981, version=0.16.3 X-archive-position: 8636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 25274 Lines: 910 --Boundary-00=_2+mQBno0jqk1vLs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Please see if it is acceptable, if it is, please pull from: bk://kernel.bkbits.net/acme/net-2.6 I want to improve it a bit by not passing the slab cache name to sk_alloc_slab, but create the name from the sk->sk_prot->name member, but unfortunately the kmem_cache_t struct stores a pointer to the slab cache name, which also creates problems for other improvements, like my __initstr patch, that moves the strings in __init and __exit functions to .text.init and .text.exit, perhaps I should send a patch to the slab code to have a char array to store the slab cache name. Comments? Best Regards, - Arnaldo --Boundary-00=_2+mQBno0jqk1vLs Content-Type: text/x-diff; charset="us-ascii"; name="slab.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slab.patch" You can import this changeset into BK by piping this whole message to: '| bk receive [path to repository]' or apply the patch as usual. =================================================================== ChangeSet@1.2165, 2004-09-11 00:02:02-03:00, acme@conectiva.com.br [NET] generalise per socket slab cache use With this patch we get two new slabcaches, for sctp socks, that previously were being allocated on the default, that was tcp[6]_sock, i.e. wasting 288 bytes per sock in the IPv4 case and 256 bytes for the IPv6 version, this is in preparation for DCCP (or any other new protocol :) ). With this in place another nice side effect that is easier to achieve is to get rid of struct sock sk->sk_slab, and instead use sk->sk_prot->slab, saving sizeof(void *) on every struct sock instance, but this unfortunatly has to wait for the conversion of all protocols that use per socket slabcaches to use sk->sk_prot, AF_UNIX is the only one AFAIK, so I'll try to convert it to use sk->sk_prot and then get rid of sk->sk_slab. As for the protocols that don't use per socket slabcaches its just a matter of defaulting to sk_cachep at sk_free time if sk->sk_prot is NULL. [root@qemu ~]# modprobe sctp [root@qemu ~]# grep _sock /proc/slabinfo sctpv6_sock 9 9 864 9 2 : tunables 54 27 0 : sctp_sock 0 0 736 5 1 : tunables 54 27 0 : rawv6_sock 3 6 640 6 1 : tunables 54 27 0 : udpv6_sock 0 0 608 6 1 : tunables 54 27 0 : tcpv6_sock 1 7 1120 7 2 : tunables 24 12 0 : unix_sock 6 10 384 10 1 : tunables 54 27 0 : raw_sock 2 8 480 8 1 : tunables 54 27 0 : udp_sock 0 0 512 7 1 : tunables 54 27 0 : tcp_sock 0 0 1024 4 1 : tunables 54 27 0 : include/linux/ipv6.h | 4 + include/net/raw.h | 1 include/net/sctp/sctp.h | 1 include/net/sock.h | 7 ++ include/net/tcp.h | 3 net/core/sock.c | 21 ++++++ net/ipv4/af_inet.c | 103 ++++++++++++++------------------ net/ipv4/raw.c | 1 net/ipv4/tcp_ipv4.c | 1 net/ipv4/tcp_minisocks.c | 2 net/ipv4/udp.c | 1 net/ipv6/af_inet6.c | 151 +++++++++++++++++++---------------------------- net/ipv6/raw.c | 6 + net/ipv6/tcp_ipv6.c | 6 + net/ipv6/udp.c | 6 + net/sctp/ipv6.c | 24 +++++-- net/sctp/protocol.c | 26 +++++--- net/sctp/socket.c | 30 +++++++++ 18 files changed, 231 insertions(+), 163 deletions(-) diff -Nru a/include/linux/ipv6.h b/include/linux/ipv6.h --- a/include/linux/ipv6.h 2004-09-11 00:15:42 -03:00 +++ b/include/linux/ipv6.h 2004-09-11 00:15:42 -03:00 @@ -282,6 +282,10 @@ return &((struct raw6_sock *)__sk)->raw6; } +struct ipv6_sk_offset { + int offset; +}; + #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) #define __ipv6_only_sock(sk) (inet6_sk(sk)->ipv6only) #define ipv6_only_sock(sk) ((sk)->sk_family == PF_INET6 && __ipv6_only_sock(sk)) diff -Nru a/include/net/raw.h b/include/net/raw.h --- a/include/net/raw.h 2004-09-11 00:15:42 -03:00 +++ b/include/net/raw.h 2004-09-11 00:15:42 -03:00 @@ -17,7 +17,6 @@ #ifndef _RAW_H #define _RAW_H - extern struct proto raw_prot; diff -Nru a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h --- a/include/net/sctp/sctp.h 2004-09-11 00:15:42 -03:00 +++ b/include/net/sctp/sctp.h 2004-09-11 00:15:42 -03:00 @@ -505,6 +505,7 @@ /* External references. */ extern struct proto sctp_prot; +extern struct proto sctpv6_prot; extern struct proc_dir_entry *proc_net_sctp; void sctp_put_port(struct sock *sk); diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h 2004-09-11 00:15:42 -03:00 +++ b/include/net/sock.h 2004-09-11 00:15:42 -03:00 @@ -410,6 +410,9 @@ return test_bit(flag, &sk->sk_flags); } +extern int sk_alloc_slab(struct proto *prot, char *name); +extern void sk_free_slab(struct proto *prot); + static inline void sk_acceptq_removed(struct sock *sk) { sk->sk_ack_backlog--; @@ -554,6 +557,10 @@ int *sysctl_wmem; int *sysctl_rmem; int max_header; + + kmem_cache_t *slab; + int slab_obj_size; + void *af_specific; char name[32]; diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-09-11 00:15:42 -03:00 +++ b/include/net/tcp.h 2004-09-11 00:15:42 -03:00 @@ -153,9 +153,6 @@ #define tcp_lhash_wait (tcp_hashinfo.__tcp_lhash_wait) #define tcp_portalloc_lock (tcp_hashinfo.__tcp_portalloc_lock) -/* SLAB cache for TCP socks */ -extern kmem_cache_t *tcp_sk_cachep; - extern kmem_cache_t *tcp_bucket_cachep; extern struct tcp_bind_bucket *tcp_bucket_create(struct tcp_bind_hashbucket *head, unsigned short snum); diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c 2004-09-11 00:15:42 -03:00 +++ b/net/core/sock.c 2004-09-11 00:15:42 -03:00 @@ -1343,6 +1343,27 @@ EXPORT_SYMBOL(sk_common_release); +int sk_alloc_slab(struct proto *prot, char *name) +{ + prot->slab = kmem_cache_create(name, + prot->slab_obj_size, 0, + SLAB_HWCACHE_ALIGN, NULL, NULL); + + return prot->slab != NULL ? 0 : -ENOBUFS; +} + +EXPORT_SYMBOL(sk_alloc_slab); + +void sk_free_slab(struct proto *prot) +{ + if (prot->slab != NULL) { + kmem_cache_destroy(prot->slab); + prot->slab = NULL; + } +} + +EXPORT_SYMBOL(sk_free_slab); + EXPORT_SYMBOL(__lock_sock); EXPORT_SYMBOL(__release_sock); EXPORT_SYMBOL(sk_alloc); diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv4/af_inet.c 2004-09-11 00:15:42 -03:00 @@ -121,11 +121,6 @@ extern void ip_mc_drop_socket(struct sock *sk); -/* Per protocol sock slabcache */ -kmem_cache_t *tcp_sk_cachep; -static kmem_cache_t *udp_sk_cachep; -static kmem_cache_t *raw4_sk_cachep; - /* The inetsw table contains everything that inet_create needs to * build a new socket. */ @@ -228,28 +223,6 @@ return err; } -static __inline__ kmem_cache_t *inet_sk_slab(int protocol) -{ - kmem_cache_t* rc = tcp_sk_cachep; - - if (protocol == IPPROTO_UDP) - rc = udp_sk_cachep; - else if (protocol == IPPROTO_RAW) - rc = raw4_sk_cachep; - return rc; -} - -static __inline__ int inet_sk_size(int protocol) -{ - int rc = sizeof(struct tcp_sock); - - if (protocol == IPPROTO_UDP) - rc = sizeof(struct udp_sock); - else if (protocol == IPPROTO_RAW) - rc = sizeof(struct raw_sock); - return rc; -} - /* * Create an inet socket. */ @@ -260,13 +233,12 @@ struct list_head *p; struct inet_protosw *answer; struct inet_opt *inet; - int err = -ENOBUFS; + struct proto *answer_prot; + unsigned char answer_flags; + char answer_no_check; + int err; sock->state = SS_UNCONNECTED; - sk = sk_alloc(PF_INET, GFP_KERNEL, inet_sk_size(protocol), - inet_sk_slab(protocol)); - if (!sk) - goto out; /* Look for the requested type/protocol pair. */ answer = NULL; @@ -292,21 +264,35 @@ err = -ESOCKTNOSUPPORT; if (!answer) - goto out_sk_free; + goto out_rcu_unlock; err = -EPERM; if (answer->capability > 0 && !capable(answer->capability)) - goto out_sk_free; + goto out_rcu_unlock; err = -EPROTONOSUPPORT; if (!protocol) - goto out_sk_free; - err = 0; + goto out_rcu_unlock; + sock->ops = answer->ops; - sk->sk_prot = answer->prot; - sk->sk_no_check = answer->no_check; - if (INET_PROTOSW_REUSE & answer->flags) - sk->sk_reuse = 1; + answer_prot = answer->prot; + answer_no_check = answer->no_check; + answer_flags = answer->flags; rcu_read_unlock(); + BUG_TRAP(answer_prot->slab != NULL); + + err = -ENOBUFS; + sk = sk_alloc(PF_INET, GFP_KERNEL, + answer_prot->slab_obj_size, + answer_prot->slab); + if (sk == NULL) + goto out; + + err = 0; + sk->sk_prot = answer_prot; + sk->sk_no_check = answer_no_check; + if (INET_PROTOSW_REUSE & answer_flags) + sk->sk_reuse = 1; + inet = inet_sk(sk); if (SOCK_RAW == sock->type) { @@ -359,9 +345,8 @@ } out: return err; -out_sk_free: +out_rcu_unlock: rcu_read_unlock(); - sk_free(sk); goto out; } @@ -1010,24 +995,23 @@ struct sk_buff *dummy_skb; struct inet_protosw *q; struct list_head *r; + int rc = -EINVAL; if (sizeof(struct inet_skb_parm) > sizeof(dummy_skb->cb)) { printk(KERN_CRIT "%s: panic\n", __FUNCTION__); - return -EINVAL; + goto out; } - tcp_sk_cachep = kmem_cache_create("tcp_sock", - sizeof(struct tcp_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - udp_sk_cachep = kmem_cache_create("udp_sock", - sizeof(struct udp_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - raw4_sk_cachep = kmem_cache_create("raw4_sock", - sizeof(struct raw_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - if (!tcp_sk_cachep || !udp_sk_cachep || !raw4_sk_cachep) - printk(KERN_CRIT - "inet_init: Can't create protocol sock SLAB caches!\n"); + rc = sk_alloc_slab(&tcp_prot, "tcp_sock"); + if (rc) + goto out; + rc = sk_alloc_slab(&udp_prot, "udp_sock"); + if (rc) + goto out_tcp_free_slab; + rc = sk_alloc_slab(&raw_prot, "raw_sock"); + if (rc) + goto out_udp_free_slab; + /* * Tell SOCKET that we are alive... */ @@ -1097,7 +1081,14 @@ ipfrag_init(); - return 0; + rc = 0; +out: + return rc; +out_tcp_free_slab: + sk_free_slab(&tcp_prot); +out_udp_free_slab: + sk_free_slab(&udp_prot); + goto out; } module_init(inet_init); diff -Nru a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv4/raw.c 2004-09-11 00:15:42 -03:00 @@ -719,6 +719,7 @@ .backlog_rcv = raw_rcv_skb, .hash = raw_v4_hash, .unhash = raw_v4_unhash, + .slab_obj_size = sizeof(struct raw_sock), }; #ifdef CONFIG_PROC_FS diff -Nru a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv4/tcp_ipv4.c 2004-09-11 00:15:42 -03:00 @@ -2617,6 +2617,7 @@ .sysctl_wmem = sysctl_tcp_wmem, .sysctl_rmem = sysctl_tcp_rmem, .max_header = MAX_TCP_HEADER, + .slab_obj_size = sizeof(struct tcp_sock), }; diff -Nru a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c --- a/net/ipv4/tcp_minisocks.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv4/tcp_minisocks.c 2004-09-11 00:15:42 -03:00 @@ -687,7 +687,7 @@ /* allocate the newsk from the same slab of the master sock, * if not, at sk_free time we'll try to free it from the wrong * slabcache (i.e. is it TCPv4 or v6?) -acme */ - struct sock *newsk = sk_alloc(PF_INET, GFP_ATOMIC, 0, sk->sk_slab); + struct sock *newsk = sk_alloc(PF_INET, GFP_ATOMIC, 0, sk->sk_prot->slab); if(newsk != NULL) { struct tcp_opt *newtp; diff -Nru a/net/ipv4/udp.c b/net/ipv4/udp.c --- a/net/ipv4/udp.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv4/udp.c 2004-09-11 00:15:42 -03:00 @@ -1320,6 +1320,7 @@ .hash = udp_v4_hash, .unhash = udp_v4_unhash, .get_port = udp_v4_get_port, + .slab_obj_size = sizeof(struct udp_sock), }; /* ------------------------------------------------------------------------ */ diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv6/af_inet6.c 2004-09-11 00:15:42 -03:00 @@ -90,11 +90,6 @@ atomic_t inet6_sock_nr; #endif -/* Per protocol sock slabcache */ -kmem_cache_t *tcp6_sk_cachep; -kmem_cache_t *udp6_sk_cachep; -kmem_cache_t *raw6_sk_cachep; - /* The inetsw table contains everything that inet_create needs to * build a new socket. */ @@ -110,37 +105,11 @@ #endif } -static __inline__ kmem_cache_t *inet6_sk_slab(int protocol) -{ - kmem_cache_t* rc = tcp6_sk_cachep; - - if (protocol == IPPROTO_UDP) - rc = udp6_sk_cachep; - else if (protocol == IPPROTO_RAW) - rc = raw6_sk_cachep; - return rc; -} - -static __inline__ int inet6_sk_size(int protocol) +static inline struct ipv6_pinfo *inet6_sk_generic(struct sock *sk) { - int rc = sizeof(struct tcp6_sock); + const struct ipv6_sk_offset *offset = sk->sk_prot->af_specific; - if (protocol == IPPROTO_UDP) - rc = sizeof(struct udp6_sock); - else if (protocol == IPPROTO_RAW) - rc = sizeof(struct raw6_sock); - return rc; -} - -static __inline__ struct ipv6_pinfo *inet6_sk_generic(struct sock *sk) -{ - struct ipv6_pinfo *rc = (&((struct tcp6_sock *)sk)->inet6); - - if (sk->sk_protocol == IPPROTO_UDP) - rc = (&((struct udp6_sock *)sk)->inet6); - else if (sk->sk_protocol == IPPROTO_RAW) - rc = (&((struct raw6_sock *)sk)->inet6); - return rc; + return (struct ipv6_pinfo *)(((u8 *)sk) + offset->offset); } static int inet6_create(struct socket *sock, int protocol) @@ -151,11 +120,10 @@ struct tcp6_sock* tcp6sk; struct list_head *p; struct inet_protosw *answer; - - sk = sk_alloc(PF_INET6, GFP_KERNEL, inet6_sk_size(protocol), - inet6_sk_slab(protocol)); - if (sk == NULL) - goto do_oom; + struct proto *answer_prot; + unsigned char answer_flags; + char answer_no_check; + int rc; /* Look for the requested type/protocol pair. */ answer = NULL; @@ -179,22 +147,40 @@ answer = NULL; } + rc = -ESOCKTNOSUPPORT; if (!answer) - goto free_and_badtype; + goto out_rcu_unlock; + rc = -EPERM; if (answer->capability > 0 && !capable(answer->capability)) - goto free_and_badperm; + goto out_rcu_unlock; + rc = -EPROTONOSUPPORT; if (!protocol) - goto free_and_noproto; + goto out_rcu_unlock; sock->ops = answer->ops; + + answer_prot = answer->prot; + answer_no_check = answer->no_check; + answer_flags = answer->flags; + rcu_read_unlock(); + + BUG_TRAP(answer_prot->slab != NULL); + + rc = -ENOBUFS; + sk = sk_alloc(PF_INET6, GFP_KERNEL, + answer_prot->slab_obj_size, + answer_prot->slab); + if (sk == NULL) + goto out; + sock_init_data(sock, sk); sk_set_owner(sk, THIS_MODULE); - sk->sk_prot = answer->prot; - sk->sk_no_check = answer->no_check; - if (INET_PROTOSW_REUSE & answer->flags) + rc = 0; + sk->sk_prot = answer_prot; + sk->sk_no_check = answer_no_check; + if (INET_PROTOSW_REUSE & answer_flags) sk->sk_reuse = 1; - rcu_read_unlock(); inet = inet_sk(sk); @@ -248,28 +234,17 @@ sk->sk_prot->hash(sk); } if (sk->sk_prot->init) { - int err = sk->sk_prot->init(sk); - if (err != 0) { + rc = sk->sk_prot->init(sk); + if (rc) { sk_common_release(sk); - return err; + goto out; } } - return 0; - -free_and_badtype: - rcu_read_unlock(); - sk_free(sk); - return -ESOCKTNOSUPPORT; -free_and_badperm: - rcu_read_unlock(); - sk_free(sk); - return -EPERM; -free_and_noproto: +out: + return rc; +out_rcu_unlock: rcu_read_unlock(); - sk_free(sk); - return -EPROTONOSUPPORT; -do_oom: - return -ENOBUFS; + goto out; } @@ -709,24 +684,20 @@ #endif #endif - if (sizeof(struct inet6_skb_parm) > sizeof(dummy_skb->cb)) - { + if (sizeof(struct inet6_skb_parm) > sizeof(dummy_skb->cb)) { printk(KERN_CRIT "inet6_proto_init: size fault\n"); return -EINVAL; } - /* allocate our sock slab caches */ - tcp6_sk_cachep = kmem_cache_create("tcp6_sock", - sizeof(struct tcp6_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - udp6_sk_cachep = kmem_cache_create("udp6_sock", - sizeof(struct udp6_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - raw6_sk_cachep = kmem_cache_create("raw6_sock", - sizeof(struct raw6_sock), 0, - SLAB_HWCACHE_ALIGN, NULL, NULL); - if (!tcp6_sk_cachep || !udp6_sk_cachep || !raw6_sk_cachep) - printk(KERN_CRIT "%s: Can't create protocol sock SLAB " - "caches!\n", __FUNCTION__); + + err = sk_alloc_slab(&tcpv6_prot, "tcpv6_sock"); + if (err) + goto out; + err = sk_alloc_slab(&udpv6_prot, "udpv6_sock"); + if (err) + goto out_tcp_free_slab; + err = sk_alloc_slab(&rawv6_prot, "rawv6_sock"); + if (err) + goto out_udp_free_slab; /* Register the socket-side information for inet6_create. */ for(r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r) @@ -745,7 +716,7 @@ /* Initialise ipv6 mibs */ err = init_ipv6_mibs(); if (err) - goto init_mib_fail; + goto out_raw_free_slab; /* * ipngwg API draft makes clear that the correct semantics @@ -798,8 +769,9 @@ /* Init v6 transport protocols. */ udpv6_init(); tcpv6_init(); - - return 0; + err = 0; +out: + return err; #ifdef CONFIG_PROC_FS proc_if6_fail: @@ -824,8 +796,13 @@ ipv6_sysctl_unregister(); #endif cleanup_ipv6_mibs(); -init_mib_fail: - return err; +out_raw_free_slab: + sk_free_slab(&rawv6_prot); +out_udp_free_slab: + sk_free_slab(&udpv6_prot); +out_tcp_free_slab: + sk_free_slab(&tcpv6_prot); + goto out; } module_init(inet6_init); @@ -854,9 +831,9 @@ ipv6_sysctl_unregister(); #endif cleanup_ipv6_mibs(); - kmem_cache_destroy(tcp6_sk_cachep); - kmem_cache_destroy(udp6_sk_cachep); - kmem_cache_destroy(raw6_sk_cachep); + sk_free_slab(&rawv6_prot); + sk_free_slab(&udpv6_prot); + sk_free_slab(&tcpv6_prot); } module_exit(inet6_exit); diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv6/raw.c 2004-09-11 00:15:42 -03:00 @@ -973,6 +973,10 @@ return(0); } +struct ipv6_sk_offset raw_sock_offset = { + .offset = offsetof(struct udp6_sock, inet6), +}; + struct proto rawv6_prot = { .name = "RAW", .close = rawv6_close, @@ -989,6 +993,8 @@ .backlog_rcv = rawv6_rcv_skb, .hash = raw_v6_hash, .unhash = raw_v6_unhash, + .slab_obj_size = sizeof(struct raw6_sock), + .af_specific = &raw_sock_offset, }; #ifdef CONFIG_PROC_FS diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv6/tcp_ipv6.c 2004-09-11 00:15:42 -03:00 @@ -2119,6 +2119,10 @@ } #endif +struct ipv6_sk_offset tcp_sock_offset = { + .offset = offsetof(struct tcp6_sock, inet6), +}; + struct proto tcpv6_prot = { .name = "TCPv6", .close = tcp_close, @@ -2145,6 +2149,8 @@ .sysctl_wmem = sysctl_tcp_wmem, .sysctl_rmem = sysctl_tcp_rmem, .max_header = MAX_TCP_HEADER, + .slab_obj_size = sizeof(struct tcp6_sock), + .af_specific = &tcp_sock_offset, }; static struct inet6_protocol tcpv6_protocol = { diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c 2004-09-11 00:15:42 -03:00 +++ b/net/ipv6/udp.c 2004-09-11 00:15:42 -03:00 @@ -1031,6 +1031,10 @@ /* ------------------------------------------------------------------------ */ +struct ipv6_sk_offset udp_sock_offset = { + .offset = offsetof(struct udp6_sock, inet6), +}; + struct proto udpv6_prot = { .name = "UDP", .close = udpv6_close, @@ -1046,6 +1050,8 @@ .hash = udp_v6_hash, .unhash = udp_v6_unhash, .get_port = udp_v6_get_port, + .slab_obj_size = sizeof(struct udp6_sock), + .af_specific = &udp_sock_offset, }; extern struct proto_ops inet6_dgram_ops; diff -Nru a/net/sctp/ipv6.c b/net/sctp/ipv6.c --- a/net/sctp/ipv6.c 2004-09-11 00:15:42 -03:00 +++ b/net/sctp/ipv6.c 2004-09-11 00:15:42 -03:00 @@ -583,8 +583,8 @@ struct ipv6_pinfo *newnp, *np = inet6_sk(sk); struct sctp6_sock *newsctp6sk; - newsk = sk_alloc(PF_INET6, GFP_KERNEL, sizeof(struct sctp6_sock), - sk->sk_slab); + newsk = sk_alloc(PF_INET6, GFP_KERNEL, sk->sk_prot->slab_obj_size, + sk->sk_prot->slab); if (!newsk) goto out; @@ -892,7 +892,7 @@ static struct inet_protosw sctpv6_seqpacket_protosw = { .type = SOCK_SEQPACKET, .protocol = IPPROTO_SCTP, - .prot = &sctp_prot, + .prot = &sctpv6_prot, .ops = &inet6_seqpacket_ops, .capability = -1, .no_check = 0, @@ -901,7 +901,7 @@ static struct inet_protosw sctpv6_stream_protosw = { .type = SOCK_STREAM, .protocol = IPPROTO_SCTP, - .prot = &sctp_prot, + .prot = &sctpv6_prot, .ops = &inet6_seqpacket_ops, .capability = -1, .no_check = 0, @@ -963,9 +963,14 @@ /* Initialize IPv6 support and register with inet6 stack. */ int sctp_v6_init(void) { + int rc = sk_alloc_slab(&sctpv6_prot, "sctpv6_sock"); + + if (rc) + goto out; /* Register inet6 protocol. */ + rc = -EAGAIN; if (inet6_add_protocol(&sctpv6_protocol, IPPROTO_SCTP) < 0) - return -EAGAIN; + goto out_sctp_free_slab; /* Add SCTPv6(UDP and TCP style) to inetsw6 linked list. */ inet6_register_protosw(&sctpv6_seqpacket_protosw); @@ -979,8 +984,12 @@ /* Register notifier for inet6 address additions/deletions. */ register_inet6addr_notifier(&sctp_inetaddr_notifier); - - return 0; + rc = 0; +out: + return rc; +out_sctp_free_slab: + sk_free_slab(&sctpv6_prot); + goto out; } /* IPv6 specific exit support. */ @@ -991,4 +1000,5 @@ inet6_unregister_protosw(&sctpv6_seqpacket_protosw); inet6_unregister_protosw(&sctpv6_stream_protosw); unregister_inet6addr_notifier(&sctp_inetaddr_notifier); + sk_free_slab(&sctpv6_prot); } diff -Nru a/net/sctp/protocol.c b/net/sctp/protocol.c --- a/net/sctp/protocol.c 2004-09-11 00:15:42 -03:00 +++ b/net/sctp/protocol.c 2004-09-11 00:15:42 -03:00 @@ -554,8 +554,8 @@ struct inet_opt *inet = inet_sk(sk); struct inet_opt *newinet; - newsk = sk_alloc(PF_INET, GFP_KERNEL, sizeof(struct sctp_sock), - sk->sk_slab); + newsk = sk_alloc(PF_INET, GFP_KERNEL, sk->sk_prot->slab_obj_size, + sk->sk_prot->slab); if (!newsk) goto out; @@ -962,23 +962,29 @@ __init int sctp_init(void) { int i; - int status = 0; + int status = -EINVAL; unsigned long goal; int order; /* SCTP_DEBUG sanity check. */ if (!sctp_sanity_check()) - return -EINVAL; + goto out; + + status = sk_alloc_slab(&sctp_prot, "sctp_sock"); + if (status) + goto out; /* Add SCTP to inet_protos hash table. */ + status = -EAGAIN; if (inet_add_protocol(&sctp_protocol, IPPROTO_SCTP) < 0) - return -EAGAIN; + goto err_add_protocol; /* Add SCTP(TCP and UDP style) to inetsw linked list. */ inet_register_protosw(&sctp_seqpacket_protosw); inet_register_protosw(&sctp_stream_protosw); /* Allocate a cache pools. */ + status = -ENOBUFS; sctp_bucket_cachep = kmem_cache_create("sctp_bind_bucket", sizeof(struct sctp_bind_bucket), 0, SLAB_HWCACHE_ALIGN, @@ -1154,8 +1160,11 @@ sctp_get_local_addr_list(); __unsafe(THIS_MODULE); - return 0; - + status = 0; +out: + return status; +err_add_protocol: + sk_free_slab(&sctp_prot); err_ctl_sock_init: sctp_v6_exit(); err_v6_init: @@ -1183,7 +1192,7 @@ inet_del_protocol(&sctp_protocol, IPPROTO_SCTP); inet_unregister_protosw(&sctp_seqpacket_protosw); inet_unregister_protosw(&sctp_stream_protosw); - return status; + goto out; } /* Exit handler for the SCTP protocol. */ @@ -1224,6 +1233,7 @@ inet_del_protocol(&sctp_protocol, IPPROTO_SCTP); inet_unregister_protosw(&sctp_seqpacket_protosw); inet_unregister_protosw(&sctp_stream_protosw); + sk_free_slab(&sctp_prot); } module_init(sctp_init); diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c 2004-09-11 00:15:42 -03:00 +++ b/net/sctp/socket.c 2004-09-11 00:15:42 -03:00 @@ -4622,4 +4622,34 @@ .hash = sctp_hash, .unhash = sctp_unhash, .get_port = sctp_get_port, + .slab_obj_size = sizeof(struct sctp_sock), }; + +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) +struct ipv6_sk_offset sctp_sock_offset = { + .offset = offsetof(struct sctp6_sock, inet6), +}; + +struct proto sctpv6_prot = { + .name = "SCTPv6", + .close = sctp_close, + .connect = sctp_connect, + .disconnect = sctp_disconnect, + .accept = sctp_accept, + .ioctl = sctp_ioctl, + .init = sctp_init_sock, + .destroy = sctp_destroy_sock, + .shutdown = sctp_shutdown, + .setsockopt = sctp_setsockopt, + .getsockopt = sctp_getsockopt, + .sendmsg = sctp_sendmsg, + .recvmsg = sctp_recvmsg, + .bind = sctp_bind, + .backlog_rcv = sctp_backlog_rcv, + .hash = sctp_hash, + .unhash = sctp_unhash, + .get_port = sctp_get_port, + .slab_obj_size = sizeof(struct sctp6_sock), + .af_specific = &sctp_sock_offset, +}; +#endif /* defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) */ --Boundary-00=_2+mQBno0jqk1vLs-- From ja@ssi.bg Sat Sep 11 00:21:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 00:22:09 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B7Lqer007703 for ; Sat, 11 Sep 2004 00:21:55 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8B7Lb4E013850; Sat, 11 Sep 2004 10:21:39 +0300 Date: Sat, 11 Sep 2004 10:21:36 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com, Wensong Zhang Subject: [PATCH 2.6] ipvs - do not use skb_checksum_help, nf_reset Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 2485 Lines: 82 Hello, Some IPVS changes for 2.6.9-rc1-bk17: - do not use skb_checksum_help in input path as ipvs can handle incoming CHECKSUM_HW packets - remove useless skb_checksum_help from forwarding path - claim that checksum is valid (CHECKSUM_NONE) when entering output path for out->in packets - do not reset/destroy the nfct in IP_VS_XMIT, the intention is to reset the debugging field just to avoid log floods from nf_debug_ip_* functions, it is known that the out->in ipvs packets traverse hooks in non-standard way, eg. LOCAL_IN->LOCAL_OUT Signed-off-by: Julian Anastasov diff -ur v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_core.c linux/net/ipv4/ipvs/ip_vs_core.c --- v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_core.c 2004-09-11 09:35:19.000000000 +0300 +++ linux/net/ipv4/ipvs/ip_vs_core.c 2004-09-11 09:37:57.868509136 +0300 @@ -743,13 +743,6 @@ if (skb->nfcache & NFC_IPVS_PROPERTY) return NF_ACCEPT; - if (skb->ip_summed == CHECKSUM_HW) { - if (skb_checksum_help(pskb, (out == NULL))) - return NF_DROP; - if (skb != *pskb) - skb = *pskb; - } - iph = skb->nh.iph; if (unlikely(iph->protocol == IPPROTO_ICMP)) { int related, verdict = ip_vs_out_icmp(pskb, &related); @@ -993,13 +986,6 @@ return NF_ACCEPT; } - if (skb->ip_summed == CHECKSUM_HW) { - if (skb_checksum_help(pskb, (out == NULL))) - return NF_DROP; - if (skb != *pskb) - skb = *pskb; - } - iph = skb->nh.iph; if (unlikely(iph->protocol == IPPROTO_ICMP)) { int related, verdict = ip_vs_in_icmp(pskb, &related); diff -ur v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_xmit.c linux/net/ipv4/ipvs/ip_vs_xmit.c --- v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-11 09:35:33.000000000 +0300 +++ linux/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-11 09:42:28.497367296 +0300 @@ -124,11 +124,17 @@ dst_release(old_dst); } +#ifdef CONFIG_NETFILTER_DEBUG +#define reset_nf_debugging(skb) do { (skb)->nf_debug = 0; } while (0) +#else +#define reset_nf_debugging(skb) do { } while (0) +#endif #define IP_VS_XMIT(skb, rt) \ do { \ - nf_reset(skb); \ + reset_nf_debugging(skb); \ (skb)->nfcache |= NFC_IPVS_PROPERTY; \ + (skb)->ip_summed = CHECKSUM_NONE; \ NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, (skb), NULL, \ (rt)->u.dst.dev, dst_output); \ } while (0) @@ -408,8 +414,6 @@ ip_select_ident(iph, &rt->u.dst, NULL); ip_send_check(iph); - skb->ip_summed = CHECKSUM_NONE; - /* Another hack: avoid icmp_send in ip_fragment */ skb->local_df = 1; From ja@ssi.bg Sat Sep 11 00:53:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 00:54:02 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8B7rso1008426 for ; Sat, 11 Sep 2004 00:53:56 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8B7rr4E014243; Sat, 11 Sep 2004 10:53:56 +0300 Date: Sat, 11 Sep 2004 10:53:53 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Harald Welte cc: netdev@oss.sgi.com, Rusty Russell Subject: [PATCH 2.6] ip_nat_ftp - manip at the right place Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 1582 Lines: 47 Hello, This is a resend/resync for v2.6.9-rc1-bk17: change the way the ip_nat_ftp helper manipulates the packets: - no manips => no fixup - check the direction, do manip once and at the same time when the headers are changed This is needed mostly for IPVS setups and I hope we do not create troubles for other setups or FTP software. Signed-off-by: Julian Anastasov diff -ur v2.6.9-rc1-bk17/linux/net/ipv4/netfilter/ip_nat_ftp.c linux/net/ipv4/netfilter/ip_nat_ftp.c --- v2.6.9-rc1-bk17/linux/net/ipv4/netfilter/ip_nat_ftp.c 2004-09-11 09:35:33.000000000 +0300 +++ linux/net/ipv4/netfilter/ip_nat_ftp.c 2004-09-11 10:29:38.343165344 +0300 @@ -237,17 +237,23 @@ unsigned int datalen; int dir; struct ip_ct_ftp_expect *exp_ftp_info; + int i, do_manip = 0; if (!exp) DEBUGP("ip_nat_ftp: no exp!!"); exp_ftp_info = &exp->help.exp_ftp_info; - /* Only mangle things once: original direction in POST_ROUTING - and reply direction on PRE_ROUTING. */ + /* Only mangle things once: for the first manip in this direction. */ dir = CTINFO2DIR(ctinfo); - if (!((hooknum == NF_IP_POST_ROUTING && dir == IP_CT_DIR_ORIGINAL) - || (hooknum == NF_IP_PRE_ROUTING && dir == IP_CT_DIR_REPLY))) { + for (i = 0; i < info->num_manips; i++) { + if (info->manips[i].direction == dir) { + if (info->manips[i].hooknum == hooknum) + do_manip = 1; + break; + } + } + if (!do_manip) { DEBUGP("nat_ftp: Not touching dir %s at hook %s\n", dir == IP_CT_DIR_ORIGINAL ? "ORIG" : "REPLY", hooknum == NF_IP_POST_ROUTING ? "POSTROUTING" From yoshfuji@linux-ipv6.org Sat Sep 11 04:10:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 04:10:47 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BBAcgO013629 for ; Sat, 11 Sep 2004 04:10:39 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id BFBA833CE7; Sat, 11 Sep 2004 20:10:29 +0900 (JST) Date: Sat, 11 Sep 2004 20:10:29 +0900 (JST) Message-Id: <20040911.201029.21582458.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] IPV6: fix an oops in rt6_device_match() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 879 Lines: 27 Hello. This fixes panic in rt6_device_match(). Well, rt->rt6i_idev is always set if it is dynamically allocated. However, when we hit ip6_null_entry here, its rt6i_idev is NULL. This patch is minimum fix to avoid the oops for now. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/route.c 1.89 vs edited ===== --- 1.89/net/ipv6/route.c 2004-08-25 03:20:43 +09:00 +++ edited/net/ipv6/route.c 2004-09-11 19:31:24 +09:00 @@ -184,7 +184,8 @@ if (dev->ifindex == oif) return sprt; if (dev->flags & IFF_LOOPBACK) { - if (sprt->rt6i_idev->dev->ifindex != oif) { + if (sprt->rt6i_idev == NULL || + sprt->rt6i_idev->dev->ifindex != oif) { if (strict && oif) continue; if (local && (!oif || -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From romieu@fr.zoreil.com Sat Sep 11 05:22:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 05:23:00 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BCMrBf018318 for ; Sat, 11 Sep 2004 05:22:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8BCJqvr004237; Sat, 11 Sep 2004 14:19:52 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8BCJqFh004236; Sat, 11 Sep 2004 14:19:52 +0200 Date: Sat, 11 Sep 2004 14:19:52 +0200 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: r8169 - panic and a fix Message-ID: <20040911121952.GA3134@electric-eye.fr.zoreil.com> References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <20040908190603.GA19634@electric-eye.fr.zoreil.com> <200409100008.06541.sriharivijayaraghavan@yahoo.com.au> <200409111147.24064.sriharivijayaraghavan@yahoo.com.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <200409111147.24064.sriharivijayaraghavan@yahoo.com.au> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 3603 Lines: 105 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Srihari Vijayaraghavan : [...] > The bad news is that I see no "Assertion failed!" messages from the kernel. > Here is the complete kernel BUG and subsequent panic messages: [oops] R12 is confusing me. Can you do two more subsequent tests with the patch attached ? They apply against vanilla 2.6.9-rc1-bk{11/17}. I assume the oops happen immediately and you can not even tell if a few packets were transmitted/received, right ? I'll welcome the objdump -S of both r8169.o modules as well as the section of the vmlinux file where skb_over_panic() appears. -- Ueimor --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-dbg-a.patch" --- linux-2.6.9-rc1-bk17.orig/drivers/net/r8169.c 2004-09-10 21:57:57.000000000 +0200 +++ linux-2.6.9-rc1-bk17/drivers/net/r8169.c 2004-09-11 14:05:17.000000000 +0200 @@ -1308,7 +1308,7 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(EarlyTxThres, EarlyTxThld); // For gigabit rtl8169 - RTL_W16(RxMaxSize, RxPacketMaxSize); + RTL_W16(RxMaxSize, RX_BUF_SIZE); // Set Rx Config register i = rtl8169_rx_config | @@ -1681,7 +1681,7 @@ rtl8169_rx_interrupt(struct net_device * } else { struct RxDesc *desc = tp->RxDescArray + entry; struct sk_buff *skb = tp->Rx_skbuff[entry]; - int pkt_size = (status & 0x00001FFF) - 4; + int pkt_size = (status & 0x00003FFF) - 4; void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int) = pci_dma_sync_single_for_device; @@ -1698,6 +1698,7 @@ rtl8169_rx_interrupt(struct net_device * pci_action(tp->pci_dev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + BUG_ON(pkt_size > (RX_BUF_SIZE - 4)); skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); rtl8169_rx_skb(skb); --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-dbg-b.patch" --- linux-2.6.9-rc1-bk17.orig/drivers/net/r8169.c 2004-09-10 21:57:57.000000000 +0200 +++ linux-2.6.9-rc1-bk17/drivers/net/r8169.c 2004-09-11 14:06:33.000000000 +0200 @@ -984,9 +984,10 @@ rtl8169_init_board(struct pci_dev *pdev, tp->cp_cmd = PCIMulRW | RxChkSum; if ((sizeof(dma_addr_t) > 4) && - !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { tp->cp_cmd |= PCIDAC; - else { + dev->features |= NETIF_F_HIGHDMA; + } else { rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc < 0) { printk(KERN_ERR PFX "DMA configuration failed.\n"); @@ -1308,7 +1309,7 @@ rtl8169_hw_start(struct net_device *dev) RTL_W8(EarlyTxThres, EarlyTxThld); // For gigabit rtl8169 - RTL_W16(RxMaxSize, RxPacketMaxSize); + RTL_W16(RxMaxSize, RX_BUF_SIZE); // Set Rx Config register i = rtl8169_rx_config | @@ -1681,7 +1682,7 @@ rtl8169_rx_interrupt(struct net_device * } else { struct RxDesc *desc = tp->RxDescArray + entry; struct sk_buff *skb = tp->Rx_skbuff[entry]; - int pkt_size = (status & 0x00001FFF) - 4; + int pkt_size = (status & 0x00003FFF) - 4; void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int) = pci_dma_sync_single_for_device; @@ -1698,6 +1699,7 @@ rtl8169_rx_interrupt(struct net_device * pci_action(tp->pci_dev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + BUG_ON(pkt_size > (RX_BUF_SIZE - 4)); skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); rtl8169_rx_skb(skb); --mYCpIKhGyMATD0i+-- From tgraf@suug.ch Sat Sep 11 06:44:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 06:44:06 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BDhxFO019557 for ; Sat, 11 Sep 2004 06:44:00 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 8B99381; Sat, 11 Sep 2004 15:43:27 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id DFECD1C0E8; Sat, 11 Sep 2004 15:44:09 +0200 (CEST) Date: Sat, 11 Sep 2004 15:44:09 +0200 From: Thomas Graf To: jamal Cc: jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040911134409.GA21181@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> <20040910231726.GP20088@postel.suug.ch> <1094868070.1042.77.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094868070.1042.77.camel@jzny.localdomain> X-archive-position: 8641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2706 Lines: 90 * jamal <1094868070.1042.77.camel@jzny.localdomain> 2004-09-10 22:01 > On Fri, 2004-09-10 at 19:17, Thomas Graf wrote: > > > There is one remaining problem, currently, changes via rtnetlink will > > result in multiple notifies being sent out because NETDEV_CHANGEMTU > > and NETDEV_CHANGENAME are invoked as well and result in a netlink > > message. Changing them to not do anything in rtnetlink context > > would solve it but we would lose the notify if the change was made > > via ioctl. > > > Are you changing MTU and NAME at the same time? Possibly, I change everything the user requests me to do. > Valid to receive the two updates i would think in that case. That's not the problem, the problem is that you may receive more updates than requested changes. Let's assume you're changing the MTU using IFLA_MTU and it succeeds. dev_set_mtu will send out the first update, at the end the do_setlink will send out another update. Changing MTU and ifname would result in 3 updates: 1) RTM_NEWLINK with updated mtu (old name) 2) RTM_NEWLINK with mtu and name updated 3) same again as 2) I personally have no problem with the current behaviour but maybe we should clean this up a bit. Suggestion: Send out a notify for every change we make. This can result in 7 updates being sent out. It would allow the application to see how far the kernel was successful quite easly or do a revision control and switch back to older configurations. Something like this: --- linux-2.6.9-rc1-bk15.orig/net/core/rtnetlink.c 2004-09-11 15:39:06.000000000 +0200 +++ linux-2.6.9-rc1-bk15/net/core/rtnetlink.c 2004-09-11 15:39:37.000000000 +0200 @@ -295,6 +295,7 @@ if (err) goto out; + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } if (ida[IFLA_ADDRESS - 1]) { @@ -312,6 +313,7 @@ err = dev->set_mac_address(dev, RTA_DATA(ida[IFLA_ADDRESS - 1])); if (err) goto out; + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } if (ida[IFLA_BROADCAST - 1]) { @@ -319,6 +321,7 @@ goto out; memcpy(dev->broadcast, RTA_DATA(ida[IFLA_BROADCAST - 1]), dev->addr_len); + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } if (ida[IFLA_MTU - 1]) { @@ -336,6 +339,7 @@ goto out; dev->tx_queue_len = *((u32 *) RTA_DATA(ida[IFLA_TXQLEN - 1])); + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } if (ida[IFLA_WEIGHT - 1]) { @@ -343,6 +347,7 @@ goto out; dev->weight = *((u32 *) RTA_DATA(ida[IFLA_WEIGHT - 1])); + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } if (ida[IFLA_IFNAME - 1]) { @@ -365,8 +370,6 @@ err = 0; out: - if (!err) - call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); dev_put(dev); return err; From ak@suse.de Sat Sep 11 07:21:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 07:21:38 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BELWRC020585 for ; Sat, 11 Sep 2004 07:21:34 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id F29FFBCB438; Sat, 11 Sep 2004 16:21:17 +0200 (CEST) Date: Sat, 11 Sep 2004 16:21:16 +0200 From: Andi Kleen To: jamal Cc: "David S. Miller" , ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040911142116.GL4431@wotan.suse.de> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094823215.1121.129.camel@jzny.localdomain> X-archive-position: 8642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 28 On Fri, Sep 10, 2004 at 09:33:35AM -0400, jamal wrote: > On Wed, 2004-09-08 at 16:47, David S. Miller wrote: > > > > > We are merely moving the sch_generic.c locking logic into the > > drivers. The behavior is entirely equivalent except that one > > level of unnecessary locking has been removed. > > > > I think his change is valid, will not break existing drivers (as > > you mentioned as well Jamal), and works well for the cases he has > > shown patches of. So I'm going to apply his patch. > > > > BTW, if we are really concerned about some existing driver returning > > -1 from hard_start_xmit() without the new feature flag being enabled, > > we can test for that and log a debugging message if it happens. The -1 test is only done when LLTX is set. So even when a existing driver does that it's fine. Only the drivers that set the new bit need to be checked. > > I am not 100% happy but let me do some testing on it. Would the best > image be the latest bk snapshot? What exactly are you not happy about? -Andi From tgraf@suug.ch Sat Sep 11 08:49:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 08:49:11 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BFn53W025344 for ; Sat, 11 Sep 2004 08:49:05 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id D4F7781; Sat, 11 Sep 2004 17:48:32 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 675611C0E8; Sat, 11 Sep 2004 17:49:14 +0200 (CEST) Date: Sat, 11 Sep 2004 17:49:14 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040911154914.GB21181@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040910160736.309bc29c.davem@davemloft.net> <1094866738.1042.53.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094866738.1042.53.camel@jzny.localdomain> X-archive-position: 8643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1249 Lines: 32 * jamal <1094866738.1042.53.camel@jzny.localdomain> 2004-09-10 21:38 > I think its a good idea. > > so, questions: > classical ABI issues > a) old kernel vs new app > b) new kernel vs old app > and lastly: > c) how to make sure no conflicts ever with updates to errno.h in the > case of b) Outdated error string table should result in a unknown error like in strerror. 2^16 errno codes should be sufficient forever. The only problem to be solved I see is where to specify the error codes or how to distribute them between netlink users in kernel context. Manage them as 512 blocks of 64 error codes and hand them out to netlink users? > one solution is to introduce a new flag NLM_F_NERR that signals kernel > that we have a new app. Another solution would be to add a new TLV to the ACK holding the additional error code. However, I do like your idea better as it's less work and easier for the userspace application. Both, a) and b) are not problem in my eyes and can be easily solved: a) the user space application has to set NLM_F_ERR on all outgoing messages and check for the flag again in the NLMSG_ERROR handler and handle nlmsgerr::error differently. b) check nlh->nlmsg_flags & NLM_F_ERR in netlink_ack, 1-line change From ak@suse.de Sat Sep 11 08:59:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 08:59:19 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BFxET3026004 for ; Sat, 11 Sep 2004 08:59:15 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 60997BCBCE2; Sat, 11 Sep 2004 17:58:59 +0200 (CEST) Date: Sat, 11 Sep 2004 17:58:39 +0200 From: Andi Kleen To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040911155839.GN4431@wotan.suse.de> References: <20040910225158.GO20088@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910225158.GO20088@postel.suug.ch> X-archive-position: 8644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1013 Lines: 27 On Sat, Sep 11, 2004 at 12:51:58AM +0200, Thomas Graf wrote: > The current situation with error codes sent back to a netlink > application is unsatisfactory. Most often, the application > receives EINVAL but has no idea what was wrong. [...] IMHO it would be far better to just pass text errors in a variable length packet back. It's a bit plan9ish, but it would work nicely here and be a bit improvement (especially for the qdiscs) Otherwise you will end up with a mainteance nightmare of a long list of error codes that needs to be updated for every new subsystem. And everybody who has a patch to add a new netlink user would always fight with conflicts in this file. I don't think an very specific error like "CFQ subsystem parameter X is FOO, can be only upto BAR" can be nicely put into a global error file. And most errors can only be handled by passing them to the user anyways, text errors would be fine for that. There could be still an errno provided for easy success/failure checking. -Andi From tgraf@suug.ch Sat Sep 11 09:24:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 09:24:30 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BGOOXZ026963 for ; Sat, 11 Sep 2004 09:24:24 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 48C9281; Sat, 11 Sep 2004 18:23:51 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id A76701C0E8; Sat, 11 Sep 2004 18:24:33 +0200 (CEST) Date: Sat, 11 Sep 2004 18:24:33 +0200 From: Thomas Graf To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040911162433.GC21181@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911155839.GN4431@wotan.suse.de> X-archive-position: 8645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1369 Lines: 38 * Andi Kleen <20040911155839.GN4431@wotan.suse.de> 2004-09-11 17:58 > IMHO it would be far better to just pass text errors > in a variable length packet back. It's a bit plan9ish, > but it would work nicely here and be a bit improvement > (especially for the qdiscs) I had the same idea and the only good way to do so would be to add a char * errbuf or alike to struct netlink_opt and access it via skb.sk.sk_protinfo. The bad side is that the for example cls and sch api don't provide the skb to the implementing modules and therefore they can't access the error buffer. I don't want to change all netlink users because of this. Changing all paths back to netlink_ack to provide a struct containing the errno and an additional text error buffer is no option for me either. Correct me if I'm wrong. > Otherwise you will end up with a mainteance nightmare of a > long list of error codes that needs to be updated for every new > subsystem. I would suggst to split them up and assign blocks of free codes to subsystems. > And everybody who has a patch to add a new netlink > user would always fight with conflicts in this file. This is indeed a problem. > I don't think an very specific error like > "CFQ subsystem parameter X is FOO, can be only upto BAR" > can be nicely put into a global error file. True, I would really like to have such error messages. From ak@suse.de Sat Sep 11 09:51:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 09:51:16 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BGpBQ7027671 for ; Sat, 11 Sep 2004 09:51:12 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 97D41BCC2B9; Sat, 11 Sep 2004 18:50:56 +0200 (CEST) Date: Sat, 11 Sep 2004 18:50:56 +0200 From: Andi Kleen To: Thomas Graf Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040911165056.GQ4431@wotan.suse.de> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911162433.GC21181@postel.suug.ch> X-archive-position: 8646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1265 Lines: 31 On Sat, Sep 11, 2004 at 06:24:33PM +0200, Thomas Graf wrote: > * Andi Kleen <20040911155839.GN4431@wotan.suse.de> 2004-09-11 17:58 > > IMHO it would be far better to just pass text errors > > in a variable length packet back. It's a bit plan9ish, > > but it would work nicely here and be a bit improvement > > (especially for the qdiscs) > > I had the same idea and the only good way to do so would > be to add a char * errbuf or alike to struct netlink_opt > and access it via skb.sk.sk_protinfo. I was thinking about a variable length netlink packet that contains it and that is sent back to the application. No need to store it anywhere else. > > The bad side is that the for example cls and sch api don't > provide the skb to the implementing modules and therefore > they can't access the error buffer. I don't want to change > all netlink users because of this. Indeed, that's an issue. Even with the retry packet you need the sequence number. On the other hand there are not that many sched/cls modules and some minor changes to them are probably ok. In the worst case you can define new entry points and keep the old ones for compatibility, but it is probably not worth it to be that compatible because there are not enough different users. -Andi From tgraf@suug.ch Sat Sep 11 10:57:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 10:57:57 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BHvgj1029107 for ; Sat, 11 Sep 2004 10:57:42 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id E962681; Sat, 11 Sep 2004 19:57:09 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id BA1271C0E8; Sat, 11 Sep 2004 19:57:52 +0200 (CEST) Date: Sat, 11 Sep 2004 19:57:52 +0200 From: Thomas Graf To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040911175752.GE21181@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <20040911165056.GQ4431@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911165056.GQ4431@wotan.suse.de> X-archive-position: 8647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1238 Lines: 29 * Andi Kleen <20040911165056.GQ4431@wotan.suse.de> 2004-09-11 18:50 > I was thinking about a variable length netlink packet > that contains it and that is sent back to the application. All solutions discussed so far are based on sending a netlink message back to the application. Changing the existing nlmsgerr.error or adding a TLV with an error message doesn't make much difference from an implementors view. > No need to store it anywhere else. Not storing it would mean to call netlink_ack from everywhere which requires knowledge of the original netlink skb and the original netlink message in order to get the pid and sequence number right. (We can't use the pid assigned to the peer's sock.) It would also mean to set a bit to avoid sending out the ack again. Wrong? > On the other hand there are not > that many sched/cls modules and some minor changes to them > are probably ok. True, but also think of xfrm, tcp_diag, netfilter, dnrmg. I haven't checked how much work it would actually be to improve better error messages for them but I plan to at least extend all error codes related to the data passed via a netlink socket. Will wait for some comments. I guess I would be swamped with something like discussed above. From sam@errno.com Sat Sep 11 11:48:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 11:49:03 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BImweB030247 for ; Sat, 11 Sep 2004 11:48:59 -0700 Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i8BImmWi016089 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 11 Sep 2004 11:48:49 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <20040911162433.GC21181@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3A0D075D-0423-11D9-BBE1-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit Cc: Andi Kleen , netdev@oss.sgi.com From: Sam Leffler Subject: Re: [RFC] Extend netlink error codes Date: Sat, 11 Sep 2004 11:48:52 -0700 To: Thomas Graf X-Mailer: Apple Mail (2.619) X-archive-position: 8648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 2144 Lines: 55 On Sep 11, 2004, at 9:24 AM, Thomas Graf wrote: > * Andi Kleen <20040911155839.GN4431@wotan.suse.de> 2004-09-11 17:58 >> IMHO it would be far better to just pass text errors >> in a variable length packet back. It's a bit plan9ish, >> but it would work nicely here and be a bit improvement >> (especially for the qdiscs) > > I had the same idea and the only good way to do so would > be to add a char * errbuf or alike to struct netlink_opt > and access it via skb.sk.sk_protinfo. > > The bad side is that the for example cls and sch api don't > provide the skb to the implementing modules and therefore > they can't access the error buffer. I don't want to change > all netlink users because of this. > > Changing all paths back to netlink_ack to provide a struct > containing the errno and an additional text error buffer is > no option for me either. > > Correct me if I'm wrong. > >> Otherwise you will end up with a mainteance nightmare of a >> long list of error codes that needs to be updated for every new >> subsystem. > > I would suggst to split them up and assign blocks of free codes > to subsystems. > >> And everybody who has a patch to add a new netlink >> user would always fight with conflicts in this file. > > This is indeed a problem. > >> I don't think an very specific error like >> "CFQ subsystem parameter X is FOO, can be only upto BAR" >> can be nicely put into a global error file. > > True, I would really like to have such error messages. A technique used for mbuf packet tags in FreeBSD is to define a 32-bit cookie that uniquely identifies a module or ABI code and concatenate this with the 16-bit tag number. The ABI code is defined as the date+time that the module is created, expressed as the number of seconds since the epoch (e.g. the output of date -u +'%s'). Tag numbers are meaningful only within the context of the module/ABI. A default/compatibility cookie is used for compatibility with previously defined tag values. This scheme effectively distributes management of tags (so far there have been no collisions). Check the comments in sys/sys/mbuf.h on FreeBSD for more details. Sam From i@stingr.net Sat Sep 11 12:41:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 12:41:26 -0700 (PDT) Received: from stingr.net (stingr.net [212.193.32.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BJfJru002182 for ; Sat, 11 Sep 2004 12:41:19 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by stingr.net (Postfix) with ESMTP id 0D8EB42B9; Sat, 11 Sep 2004 23:41:09 +0400 (MSD) Received: from stingr.net ([127.0.0.1]) by localhost (stingr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13450-03; Sat, 11 Sep 2004 23:41:08 +0400 (MSD) Received: by stingr.net (Postfix, from userid 1000) id 18B4A42C0; Sat, 11 Sep 2004 23:41:08 +0400 (MSD) Date: Sat, 11 Sep 2004 23:41:08 +0400 From: Paul P Komkoff Jr To: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-ID: <20040911194108.GS28258@stingr.sgu.ru> Mail-Followup-To: netdev@oss.sgi.com, Linux Kernel Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Agent Darien Fawkes X-Mailer: Intel Ultra ATA Storage Driver X-RealName: Stingray Greatest Jr Organization: Department of Fish & Wildlife X-Virus-Scanned: by amavisd-new at stingr.net X-archive-position: 8649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: i@stingr.net Precedence: bulk X-list: netdev Content-Length: 1636 Lines: 50 Hello! Some time ago I posted the following patch. It indeed adds support for wccp version 1 and 2 decapsulation in ip_gre.c. But there is an open question. I surrounded all decapsulation stuff in if (1). Which knob I should use instead of that 1 to make this change acceptable into mainline kernel? Thanks in advance. diff -urN linux-2.6.6-1.435/net/ipv4/ip_gre.c linux-2.6.6-1.435a/net/ipv4/ip_gre.c --- linux-2.6.6-1.435/net/ipv4/ip_gre.c 2004-05-10 06:32:54.000000000 +0400 +++ linux-2.6.6-1.435a/net/ipv4/ip_gre.c 2004-06-30 16:38:43.781838344 +0400 @@ -553,6 +553,8 @@ return INET_ECN_encapsulate(tos, inner); } +#define ETH_P_WCCP 0x883E + int ipgre_rcv(struct sk_buff *skb) { struct iphdr *iph; @@ -605,13 +607,21 @@ if ((tunnel = ipgre_tunnel_lookup(iph->saddr, iph->daddr, key)) != NULL) { secpath_reset(skb); + skb->protocol = *(u16*)(h + 2); + if (1) { + if ((flags == 0) && (skb->protocol == __constant_htons(ETH_P_WCCP))) { + skb->protocol = __constant_htons(ETH_P_IP); + if ((*(h + offset) & 0xF0) != 0x40) + offset += 4; + } + } + skb->mac.raw = skb->nh.raw; skb->nh.raw = __pskb_pull(skb, offset); memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); if (skb->ip_summed == CHECKSUM_HW) skb->csum = csum_sub(skb->csum, csum_partial(skb->mac.raw, skb->nh.raw-skb->mac.raw, 0)); - skb->protocol = *(u16*)(h + 2); skb->pkt_type = PACKET_HOST; #ifdef CONFIG_NET_IPGRE_BROADCAST if (MULTICAST(iph->daddr)) { -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From hadi@cyberus.ca Sat Sep 11 13:00:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 13:00:15 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BK0ArG002810 for ; Sat, 11 Sep 2004 13:00:10 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C6E2R-0002NB-AZ for netdev@oss.sgi.com; Sat, 11 Sep 2004 15:59:59 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C6E2P-0004z1-Bx; Sat, 11 Sep 2004 15:59:57 -0400 Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: jt@hpl.hp.com, netdev@oss.sgi.com In-Reply-To: <20040911134409.GA21181@postel.suug.ch> References: <20040910195003.GA13912@bougret.hpl.hp.com> <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> <20040910231726.GP20088@postel.suug.ch> <1094868070.1042.77.camel@jzny.localdomain> <20040911134409.GA21181@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1094932793.2344.82.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Sep 2004 15:59:53 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2144 Lines: 58 On Sat, 2004-09-11 at 09:44, Thomas Graf wrote: > * jamal <1094868070.1042.77.camel@jzny.localdomain> 2004-09-10 22:01 > > On Fri, 2004-09-10 at 19:17, Thomas Graf wrote: > Possibly, I change everything the user requests me to do. > > > Valid to receive the two updates i would think in that case. > > That's not the problem, the problem is that you may receive > more updates than requested changes. Let's assume you're changing > the MTU using IFLA_MTU and it succeeds. dev_set_mtu will send > out the first update, at the end the do_setlink will send > out another update. Ok, this doesnt sound right. > Changing MTU and ifname would result in 3 updates: > > 1) RTM_NEWLINK with updated mtu (old name) > > 2) RTM_NEWLINK with mtu and name updated > 3) same again as 2) > > I personally have no problem with the current behaviour but maybe > we should clean this up a bit. > > Suggestion: > Send out a notify for every change we make. This can result > in 7 updates being sent out. It would allow the application > to see how far the kernel was successful quite easly or > do a revision control and switch back to older configurations. > Not necessary to send all those updates. do_setlink was doing the right thing before your patch. It was announcing the change of addresses (broadcast, etc). You introduced new features which while related to link level have nothing to do with address changes. So my suggestion is making your code the exception. i.e something along the lines of: addrchg = 1; if (mtu/weight/name related) addrchng = 0; if (!err & addrchang) call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); Also note, the semantics of netlink are all-or-nothing transaction. i.e if one of the things requested for fails then you undo the rest. We can probably loosely say that unles the ATOMIC flag is set you dont need to undo that .. something to think about (summary is you probably dont want to send progress update to user space unless the transaction is successful; you however want to report progress of where failure happens - as we are discussing at the moment in the error code thread). cheers, jamal From hadi@cyberus.ca Sat Sep 11 13:15:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 13:15:54 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BKFojU003395 for ; Sat, 11 Sep 2004 13:15:50 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C6EHb-00046v-4i for netdev@oss.sgi.com; Sat, 11 Sep 2004 16:15:39 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C6EHX-00068Y-MI; Sat, 11 Sep 2004 16:15:35 -0400 Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20040911142116.GL4431@wotan.suse.de> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> Content-Type: text/plain Organization: jamalopolous Message-Id: <1094933731.2343.109.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Sep 2004 16:15:32 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2202 Lines: 62 On Sat, 2004-09-11 at 10:21, Andi Kleen wrote: > On Fri, Sep 10, 2004 at 09:33:35AM -0400, jamal wrote: > > > > I am not 100% happy but let me do some testing on it. Would the best > > image be the latest bk snapshot? > > What exactly are you not happy about? > Grr, Andi, Did you really have to force me to explain why i am unhappy? As a general principle i think it is against human nature to be happy. In this specific case, though: Remember that famous movie breakup line "its just me not you"? Well, this is along those lines;-> I am not as conservative as say Donald Becker, but it worries me messing with code that might have repurcassions (as innocent as that code seems). It doesnt help that recently theres more breakages in the netsched code than there have been in the last few years put together. If Alexey(who knows that piece of code better than anybody) was awake and he ACKed i wouldnt be commenting. Having said that, when i saw your patch with the comment: /* hard_start_xmit returns: 0 device not ready 1 everything ok -1 didn't get device lock (for LLTX) */ my mythical level of unhapiness went up;-> Clearly for 0 and 1 your comments are misleading/wrong (even though your code does the right thing). If i was the one who had thought of the need for this new lock-riddance then i would have done it as follows: - have a devices xmit_lock as an alias to this other lock in case of NETIF_F_LLTX Then you wouldnt have to touch this code. Infact if it is not too late why not do it like that? To add to all this, theres well known semantics of what the return code means: -> 0 means the packet was swallowed by driver. -> 1 means packet was not swallowed. I dont know why you would need to introduce a new return code. All the device is saying is "sorry, I am busy, come back later". Infact in the pre-softnet days the flag was called precisely "tbusy". Now, it would make a lot of sense to introduce new return code if you actually have plans to use it. You probably do but havent stated it. Do you have plans to use that return code? Does that explain my unhappiness? ;-> Does that make you happy? ;-> Now i need to refill my coffee. cheers, jamal From hadi@cyberus.ca Sat Sep 11 14:10:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 14:10:58 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BLAq3v004565 for ; Sat, 11 Sep 2004 14:10:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C6F8t-00010n-LD for netdev@oss.sgi.com; Sat, 11 Sep 2004 17:10:43 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C6F8p-00024W-HI; Sat, 11 Sep 2004 17:10:39 -0400 Subject: Re: [RFC] Extend netlink error codes From: jamal Reply-To: hadi@cyberus.ca To: Sam Leffler Cc: Thomas Graf , Andi Kleen , netdev@oss.sgi.com In-Reply-To: <3A0D075D-0423-11D9-BBE1-000A95AD0668@errno.com> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <3A0D075D-0423-11D9-BBE1-000A95AD0668@errno.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1094937035.2344.189.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Sep 2004 17:10:35 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2772 Lines: 67 On Sat, 2004-09-11 at 14:48, Sam Leffler wrote: > On Sep 11, 2004, at 9:24 AM, Thomas Graf wrote: > > > * Andi Kleen <20040911155839.GN4431@wotan.suse.de> 2004-09-11 17:58 > >> IMHO it would be far better to just pass text errors > >> in a variable length packet back. It's a bit plan9ish, > >> but it would work nicely here and be a bit improvement > >> (especially for the qdiscs) > > > > I had the same idea and the only good way to do so would > > be to add a char * errbuf or alike to struct netlink_opt > > and access it via skb.sk.sk_protinfo. > > > > The bad side is that the for example cls and sch api don't > > provide the skb to the implementing modules and therefore > > they can't access the error buffer. I don't want to change > > all netlink users because of this. > > > > Changing all paths back to netlink_ack to provide a struct > > containing the errno and an additional text error buffer is > > no option for me either. > > > > Correct me if I'm wrong. > > just reuse skb->cb[] and intepret it in rtnetlink in the case of failures. > A technique used for mbuf packet tags in FreeBSD is to define a 32-bit > cookie that uniquely identifies a module or ABI code and concatenate > this with the 16-bit tag number. The ABI code is defined as the > date+time that the module is created, expressed as the number of > seconds since the epoch (e.g. the output of date -u +'%s'). Tag > numbers are meaningful only within the context of the module/ABI. A > default/compatibility cookie is used for compatibility with previously > defined tag values. This scheme effectively distributes management of > tags (so far there have been no collisions). This sounds similar to the skb tags of different sorts that exist. It does however bring out a good point into the discussion. I think we need to identify errors by IDs - dont think we can avoid that. The IDs could be the T in TLV; their scope is per socket level (eg at rtnetlink); This means there are 16 bits space per socket type. The next level to addressing is at each submodule level eg qdisc, ipv4route, etc. Assuming we have 8 bits there that leaves upto 8 bits per submodule for different error types. 256 error codes per submodule liek a qdisc sounds very reasonable to me. We could reserve the last entry for future extensions. Example: socket: rtnetlink submodule: qdisc (module 1) error id: Q_NASTYTHING which is 0x10 qdisc_errors[Q_NASTYTHING] is "something really nasty just happened" Then T = 0x110 L length(qdisc_errors[Q_NASTYTHING]) V = qdisc_errors[Q_NASTYTHING] BTW, there was someone from IBM a while back who was talking about having drivers send error messages via netlink; someone needs to look at the ideas they have maybe we can borrow something. cheers, jamal From tgraf@suug.ch Sat Sep 11 15:06:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 15:06:12 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BM65Mb005549 for ; Sat, 11 Sep 2004 15:06:06 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7E52381; Sun, 12 Sep 2004 00:05:32 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 823DD1C0E8; Sun, 12 Sep 2004 00:06:14 +0200 (CEST) Date: Sun, 12 Sep 2004 00:06:14 +0200 From: Thomas Graf To: jamal Cc: jt@hpl.hp.com, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-ID: <20040911220614.GF21181@postel.suug.ch> References: <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> <20040910231726.GP20088@postel.suug.ch> <1094868070.1042.77.camel@jzny.localdomain> <20040911134409.GA21181@postel.suug.ch> <1094932793.2344.82.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094932793.2344.82.camel@jzny.localdomain> X-archive-position: 8653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2956 Lines: 86 * jamal <1094932793.2344.82.camel@jzny.localdomain> 2004-09-11 15:59 > So my suggestion is making your code the exception. > i.e something along the lines of: > > addrchg = 1; > > if (mtu/weight/name related) > addrchng = 0; > if (!err & addrchang) > call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); OK, however I'd prefer to invert the concept. See patch below. This would send out the following updates: ififlags - NETDEV_(UP|DOWN) if IFF_UP has changed IFLA_MAP - none IFLA_ADDRESS|IFLA_BROADCAST - NETDEV_CHANGEADDR IFLA_MTU - NETDEV_CHANGEMTU IFLA_WEIGHT - none IFLA_IFNAME - NETDEVCHANGENAME PATCH: Only send NETDEV_CHANGEADDR notifies for address and broadcast changes. Notify is also sent out if only one of the 2 changes is successful. Signed-off-by: Thomas Graf --- linux-2.6.9-rc1-bk18.orig/net/core/rtnetlink.c 2004-09-11 16:30:30.000000000 +0200 +++ linux-2.6.9-rc1-bk18/net/core/rtnetlink.c 2004-09-11 23:30:05.000000000 +0200 @@ -265,7 +265,7 @@ struct ifinfomsg *ifm = NLMSG_DATA(nlh); struct rtattr **ida = arg; struct net_device *dev; - int err; + int err, send_addr_notify = 0; dev = dev_get_by_index(ifm->ifi_index); if (!dev) @@ -312,6 +312,7 @@ err = dev->set_mac_address(dev, RTA_DATA(ida[IFLA_ADDRESS - 1])); if (err) goto out; + send_addr_notify = 1; } if (ida[IFLA_BROADCAST - 1]) { @@ -319,6 +320,7 @@ goto out; memcpy(dev->broadcast, RTA_DATA(ida[IFLA_BROADCAST - 1]), dev->addr_len); + send_addr_notify = 1; } if (ida[IFLA_MTU - 1]) { @@ -365,7 +367,7 @@ err = 0; out: - if (!err) + if (send_addr_notify) call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); dev_put(dev); > Also note, the semantics of netlink are all-or-nothing transaction. i.e > if one of the things requested for fails then you undo the rest. We can > probably loosely say that unles the ATOMIC flag is set you dont need to > undo that .. something to think about (summary is you probably dont want > to send progress update to user space unless the transaction is > successful; you however want to report progress of where failure happens > - as we are discussing at the moment in the error code thread). Agreed, I think undo should happen from user space though. In the example of do_setlink, you can see that while it would be quite easy to do the sanity checks before actually doing something you can't catch all errors if you don't want to implement the name/mtu/addr change routines yourself. Keeping in mind that those sanity checks will probably only fail during the development of a application it doesn't really help. That's why I implemented it this way. I'm experimenting with a commit/fallback netlink library which basically fetches the subject of change and stores the netlink message to be used in case of fallback. NLM_F_ATOMIC makes it even more useable but is quite expensive. A netlink change daemon would probably solve the problem better. From sneakums@zork.net Sat Sep 11 16:17:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 16:17:11 -0700 (PDT) Received: from zork.zork.net (Debian-exim@zork.zork.net [64.81.246.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8BNH4QU007459 for ; Sat, 11 Sep 2004 16:17:06 -0700 Received: from sneakums by zork.zork.net with local (Exim 4.34) id 1C6H6p-0007mS-MB; Sat, 11 Sep 2004 16:16:44 -0700 To: romieu@fr.zoreil.com Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout From: Sean Neakums Mail-Followup-To: romieu@fr.zoreil.com, jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Date: Sun, 12 Sep 2004 00:16:43 +0100 Message-ID: <6upt4s4cro.fsf@zork.zork.net> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: sneakums@zork.net X-SA-Exim-Scanned: No (on zork.zork.net); SAEximRunCond expanded to false X-archive-position: 8654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sneakums@zork.net Precedence: bulk X-list: netdev Content-Length: 498 Lines: 17 irq 16: nobody cared! [] __report_bad_irq+0x24/0x90 [] note_interrupt+0x92/0x160 [] do_IRQ+0x162/0x1a0 [] common_interrupt+0x18/0x20 [] default_idle+0x0/0x40 [] default_idle+0x2c/0x40 [] cpu_idle+0x34/0x50 handlers: [] (rtl8169_interrupt+0x0/0x1d0) Disabling IRQ #16 NETDEV WATCHDOG: eth2: transmit timed out eth2: TX Timeout CONFIG_R8169_NAPI=y I downed and upped the interface and it started working again. From davem@davemloft.net Sat Sep 11 17:41:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 17:41:29 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8C0fMhl013543 for ; Sat, 11 Sep 2004 17:41:23 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6IPI-0007um-00; Sat, 11 Sep 2004 17:39:52 -0700 Date: Sat, 11 Sep 2004 17:39:52 -0700 From: "David S. Miller" To: Julian Anastasov Cc: netdev@oss.sgi.com, wensong@linux-vs.org Subject: Re: [PATCH 2.6] ipvs - do not use skb_checksum_help, nf_reset Message-Id: <20040911173952.5092aa65.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 517 Lines: 14 On Sat, 11 Sep 2004 10:21:36 +0300 (EEST) Julian Anastasov wrote: > - do not reset/destroy the nfct in IP_VS_XMIT, the intention is to > reset the debugging field just to avoid log floods from nf_debug_ip_* > functions, it is known that the out->in ipvs packets traverse hooks in > non-standard way, eg. LOCAL_IN->LOCAL_OUT Please add a generic nf_reset_debug() in linux/skbuff.h instead of this version local to the IPVS code. I'll apply a resubmitted full patch with this change made to it. Thanks. From davem@davemloft.net Sat Sep 11 17:53:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 17:53:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8C0rHou014160 for ; Sat, 11 Sep 2004 17:53:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6IUp-0007vB-00; Sat, 11 Sep 2004 17:45:35 -0700 Date: Sat, 11 Sep 2004 17:45:35 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-Id: <20040911174535.2acbb957.davem@davemloft.net> In-Reply-To: <1094933731.2343.109.camel@jzny.localdomain> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 850 Lines: 20 On 11 Sep 2004 16:15:32 -0400 jamal wrote: > If i was the one who had thought of the need for this new lock-riddance > then i would have done it as follows: > - have a devices xmit_lock as an alias to this other lock in case of > NETIF_F_LLTX > Then you wouldnt have to touch this code. Infact if it is not too late > why not do it like that? If you turn dev->xmit_lock into a spinlock pointer, that would incur much deeper changes across the tree than Andi's version because there are a lot of xmit_lock explicit references out there. I think Andi made the right choice for his implementation. And frankly I don't what is worrying about the "-1" return value, it can occur in only one spot in a very specific controlled case and it's behavior is incredibly well defined (if not by accurate comments then by the code itself :-) From cranium2003@yahoo.com Sat Sep 11 21:40:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 21:40:52 -0700 (PDT) Received: from web41409.mail.yahoo.com (web41409.mail.yahoo.com [66.218.93.75]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8C4elHS022473 for ; Sat, 11 Sep 2004 21:40:47 -0700 Message-ID: <20040912044029.82969.qmail@web41409.mail.yahoo.com> Received: from [66.218.69.220] by web41409.mail.yahoo.com via HTTP; Sat, 11 Sep 2004 21:40:29 PDT Date: Sat, 11 Sep 2004 21:40:29 -0700 (PDT) From: cranium2003 Subject: Tcp sequence number calculation To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 409 Lines: 17 Hello, i want know how 2.4 kernel decides which sequence no. to be sent with next packet? I am unable to find the location in kernel? Also what does following statement does? TCP_SKB_CB(__skb)= ((struct tcp_skb_cb *)&((__skb)->cb[0])) in tcp.h regards, cranium2003. _______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool From ja@ssi.bg Sat Sep 11 21:51:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 11 Sep 2004 21:51:12 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8C4p25m022927 for ; Sat, 11 Sep 2004 21:51:04 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8C4p13O004844; Sun, 12 Sep 2004 07:51:02 +0300 Date: Sun, 12 Sep 2004 07:51:01 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com, Wensong Zhang Subject: [PATCH 2.6] ipvs - v2: do not use skb_checksum_help, nf_reset In-Reply-To: <20040911173952.5092aa65.davem@davemloft.net> Message-ID: References: <20040911173952.5092aa65.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 2858 Lines: 93 Hello, Appended is a 2nd version that uses nf_reset_debug. - do not use skb_checksum_help in input path as ipvs can handle incoming CHECKSUM_HW packets - do not use skb_checksum_help in forwarding path - claim that checksum is valid (CHECKSUM_NONE) when entering output path for out->in packets - do not reset/destroy the nfct in IP_VS_XMIT, the intention is to reset the debugging field just to avoid log floods from nf_debug_ip_* functions, it is known that the ipvs packets traverse other hooks, eg. LOCAL_IN->LOCAL_OUT. Use nf_reset_debug instead of nf_reset. Signed-off-by: Julian Anastasov diff -ur v2.6.9-rc1-bk17/linux/include/linux/skbuff.h linux/include/linux/skbuff.h --- v2.6.9-rc1-bk17/linux/include/linux/skbuff.h 2004-09-11 09:35:19.000000000 +0300 +++ linux/include/linux/skbuff.h 2004-09-12 07:37:28.305973640 +0300 @@ -1159,6 +1159,12 @@ skb->nf_debug = 0; #endif } +static inline void nf_reset_debug(struct sk_buff *skb) +{ +#ifdef CONFIG_NETFILTER_DEBUG + skb->nf_debug = 0; +#endif +} #ifdef CONFIG_BRIDGE_NETFILTER static inline void nf_bridge_put(struct nf_bridge_info *nf_bridge) diff -ur v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_core.c linux/net/ipv4/ipvs/ip_vs_core.c --- v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_core.c 2004-09-11 09:59:19.000000000 +0300 +++ linux/net/ipv4/ipvs/ip_vs_core.c 2004-09-12 07:36:42.548929768 +0300 @@ -743,13 +743,6 @@ if (skb->nfcache & NFC_IPVS_PROPERTY) return NF_ACCEPT; - if (skb->ip_summed == CHECKSUM_HW) { - if (skb_checksum_help(pskb, (out == NULL))) - return NF_DROP; - if (skb != *pskb) - skb = *pskb; - } - iph = skb->nh.iph; if (unlikely(iph->protocol == IPPROTO_ICMP)) { int related, verdict = ip_vs_out_icmp(pskb, &related); @@ -993,13 +986,6 @@ return NF_ACCEPT; } - if (skb->ip_summed == CHECKSUM_HW) { - if (skb_checksum_help(pskb, (out == NULL))) - return NF_DROP; - if (skb != *pskb) - skb = *pskb; - } - iph = skb->nh.iph; if (unlikely(iph->protocol == IPPROTO_ICMP)) { int related, verdict = ip_vs_in_icmp(pskb, &related); diff -ur v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_xmit.c linux/net/ipv4/ipvs/ip_vs_xmit.c --- v2.6.9-rc1-bk17/linux/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-11 09:59:19.000000000 +0300 +++ linux/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-12 07:38:29.351693280 +0300 @@ -124,11 +124,11 @@ dst_release(old_dst); } - #define IP_VS_XMIT(skb, rt) \ do { \ - nf_reset(skb); \ + nf_reset_debug(skb); \ (skb)->nfcache |= NFC_IPVS_PROPERTY; \ + (skb)->ip_summed = CHECKSUM_NONE; \ NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, (skb), NULL, \ (rt)->u.dst.dev, dst_output); \ } while (0) @@ -408,8 +408,6 @@ ip_select_ident(iph, &rt->u.dst, NULL); ip_send_check(iph); - skb->ip_summed = CHECKSUM_NONE; - /* Another hack: avoid icmp_send in ip_fragment */ skb->local_df = 1; From sriharivijayaraghavan@yahoo.com.au Sun Sep 12 01:26:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 01:26:57 -0700 (PDT) Received: from smtp203.mail.sc5.yahoo.com (smtp203.mail.sc5.yahoo.com [216.136.129.93]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8C8QoVi030078 for ; Sun, 12 Sep 2004 01:26:51 -0700 Received: from unknown (HELO ?192.168.0.2?) (sriharivijayaraghavan@150.101.153.12 with plain) by smtp203.mail.sc5.yahoo.com with SMTP; 12 Sep 2004 08:26:27 -0000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: r8169 - panic and a fix Date: Sun, 12 Sep 2004 18:32:57 +1000 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <200409111147.24064.sriharivijayaraghavan@yahoo.com.au> <20040911121952.GA3134@electric-eye.fr.zoreil.com> In-Reply-To: <20040911121952.GA3134@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_5mARBfai7A4iOym" Message-Id: <200409121832.57233.sriharivijayaraghavan@yahoo.com.au> X-archive-position: 8659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sriharivijayaraghavan@yahoo.com.au Precedence: bulk X-list: netdev Content-Length: 88747 Lines: 1213 --Boundary-00=_5mARBfai7A4iOym Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 11 Sep 2004 10:19 pm, Francois Romieu wrote: > ... > R12 is confusing me. > > Can you do two more subsequent tests with the patch attached ? > They apply against vanilla 2.6.9-rc1-bk{11/17}. Sure. This is from r8169-dbg-a.patch: ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at r8169:1701 invalid operand: 0000 [1] CPU 0 Modules linked in: snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart sx Pid: 0, comm: swapper Not tainted 2.6.9-rc1-bk17-r8169-a RIP: 0010:[] {:r8169:rtl8169_rx_interrupt+436} RSP: 0018:ffffffff8039bc38 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 0000000000000c00 RCX: 0000000000000000 RDX: 0000000000000600 RSI: 000000003ea17012 RDI: 00000100023c3070 RBP: 0000010036e71360 R08: 0000000000000000 R09: 0000000000000000 R10: 000001003f613b28 R11: 0000000000000001 R12: 0000000000000bfc R13: 0000000000000000 R14: 0000000000000000 R15: 00000100370e7000 FS: 0000002a95577da0(0000) GS:ffffffff803f3040(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000002a95557000 CR3: 0000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff803f6000, task ffffffff802ef480) Stack: 0000000000000bfc ffffffffa00ea3e0 0000010000000286 0000010036e71000 000001003fc36880 0000000000008001 ffffff0000056000 0000000000000014 0000010036e71360 0000010036e71000 Call Trace: {:r8169:pci_unmap_single+0} {:r8169:rtl8169_interrupt+147} {handle_IRQ_event+44} {do_IRQ+147} {default_idle+0} {ret_from_intr+0} {default_idle+36} {cpu_idle+26} {start_kernel+339} Code: 0f 0b a9 a5 0e a0 ff ff ff ff a5 06 48 8b 7c 24 20 8b 87 9c RIP {:r8169:rtl8169_rx_interrupt+436} RSP <0>Kernel panic - not syncing: Aiee, killing interrupt handler! Whereas this one is from r8169-dbg-b.patch: ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at r8169:1702 invalid operand: 0000 [1] CPU 0 Modules linked in: r8169 af_packet ide_cd cdrom via_rhine mii crc32 floppy radeon reiserfs dm_mod uhci_hcd ehci_hcd usbcorx Pid: 0, comm: swapper Not tainted 2.6.9-rc1-bk17-r8169-b RIP: 0010:[] {:r8169:rtl8169_rx_interrupt+436} RSP: 0018:ffffffff8039bc38 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 0000000000000c00 RCX: 0000000000000000 RDX: 0000000000000600 RSI: 000000003ef4d012 RDI: 00000100023c3070 RBP: 0000010038ee4360 R08: 0000000000000000 R09: 0000000000000000 R10: 000001003f614e28 R11: 000001003bacdda0 R12: 0000000000000bfc R13: 0000000000000000 R14: 0000000000000000 R15: 0000010036f70000 FS: 0000002a9556dd40(0000) GS:ffffffff803f3040(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000039cbb8bd60 CR3: 0000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff803f6000, task ffffffff802ef480) Stack: 0000000000000bfc ffffffffa00ea3e0 0000010000000286 0000010038ee4000 000001003fc36b80 0000000000008001 ffffff0000056000 0000000000000014 0000010038ee4360 0000010038ee4000 Call Trace: {:r8169:pci_unmap_single+0} {:r8169:rtl8169_interrupt+147} {handle_IRQ_event+44} {do_IRQ+147} {default_idle+0} {ret_from_intr+0} {default_idle+36} {cpu_idle+26} {start_kernel+339} Code: 0f 0b a9 a5 0e a0 ff ff ff ff a6 06 48 8b 7c 24 20 8b 87 9c RIP {:r8169:rtl8169_rx_interrupt+436} RSP <0>Kernel panic - not syncing: Aiee, killing interrupt handler! > I assume the oops happen immediately and you can not even tell if a few > packets were transmitted/received, right ? Not really. If I disconnect the network cable, then it does not crash on 2.6.9-rc1-bk17, and on r8169-dbg-a.patch and .r8169-dbg-b.patch too. So from this machine if I ping a remote machine, ping never succeeds, but it does not crash either. OTOH, when I ping from a remote machine, it crashes instantaneously. (So it seems it is somehow related to RX related functionality). > I'll welcome the objdump -S of both r8169.o modules as well as the section > of the vmlinux file where skb_over_panic() appears. With objdumb of r8169 I have no problems (please refer to the attachments), but I do not know how to extract the skb_over_panic() section from vmlinux. Could you please explain it to me as to how to do that?, perhaps in a private email. Thank you. Hari. --Boundary-00=_5mARBfai7A4iOym Content-Type: application/x-bzip2; name="objdump-2.6.9-rc1-bk17-r8169.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="objdump-2.6.9-rc1-bk17-r8169.bz2" QlpoOTFBWSZTWS6w6/8AG3TfgH18zn//9QQAAAC////wYG1eD4Q+sx9uZ9VSAoiUA+tJUil7x3zu x1l2xFQRWuzyqH2OffIjgT7H2NK1lF3mHNZFRK+9rbgBDsfTkp8HovmjQ9rA+nyfPfXHRvYdfda9 3Abu7Z88Abke9a9883r5LAnH3t9bW0utynfb6FAqhZgbqZvbbd2IHkGPWoDkHuPo+vvd99Pkp8g3 tkByGNYUYhmsAxHd0p2fd69lp82+LvM8xYPIIAAAKAAD6ADAV33zU7Q8Rngnq4DxDnnh68p3s8Qx 9fPXhpEHz1HdoenDu5jBgcI4eAeykimFMyVa1CfAHVDbhpogAAiSJNqaaZIg9AIZDIBqegCApJBR 6aQAxA0AAGgaeShETRBGU9UAND1NAAAABJ6pRKSZR6aQNGnqAAAyYhoABCkkEwmgI0BNJtEaj1Hq DQDRkESIQTQIQIFINNAAGgNA6KAiHt+wYgqi4SHylEwJEBA1IUgNAgYECOQKUgqODkZgTVKMMCgG CkgqnT8lVTRI0AUAsQArQIKkQCUAkSqgxKC0KNIqlAoM7cm9K6IAEk70U3Aq24Yl3cl4xgxGY8kk sNk2iomrdMgQjaKt2NooF+gDY2A0jDMaK1RdyqwXgoqG8brObbKiw2dkFE0psG2wb6FADKbk2Ny7 9k1LErQUBEIFCUBQjwVslKpQKnY407MAVb7G1EpjqDMNGhWHaEbMHJClbMYkyAwsIIks22NsNJrM 3K6HTUe8+a9r41JXxZfGqvm3TtU0rbFsMHJKDRIQa1g44OlTA0TdiNhTYVAsoirV0tpd2DdXY3GD lwrQYBpaKRqFQSgmG4tgFurrzty08lvFedWVvN6GTJipVjzymYt13I7uJ1a17s3rM1IYg2io7e53 b1grrCwLAZcDmSZkmtwLpLN2OuJN0wJiWIOlByGVsQbUGwtYlCpdQMmohMMQ06BMkDbY0MpVuMDN +sNIDCBsGILi5oBKKDg/X8/3v/IIAAgwxZ+11qf1oOUAADexpGxiQI0ssVjFn+LZU/1D8v5O/0nr fnN9dePBaISSYWHiWscOWcZI1rShCFRZFJZQiAcV7d5swIE8a5zO+7YkrbFY93vxqkNeI5LuTAqI xf6nnvOWHB/YkPpfIZVnQhnXqO7EK6aXbRR0HuCx03djGcuWxKygNsDT51fMdI7AkVYI2nt8KlgN KCR/ioQKgQ1UqKm21VVmjTqXOk78de09E9c6nc82xhPKx16jHwcV2XvPBgQJ41zPZfMNa9pQSGdB KhCVBZQW1DBxT15Z1jZxuQ4rFzpdgqrqURIahZF5k63RsOM0LIK7067KlCpJpExV51WsaI3Q0cfO STKIS6O6lUVVVUKbQlXRWKBaxJFbegRu0wCcG2tkR4ShZBIvfJEizdqCcnQKEFuhGK1RWpLXesbI JBI3Gq1hUtsrtEgW7IiKwRECZV3ZSCz1RXOM/PDkyKBNkHo0TsEh0XWOEFJoEOZBIL37jM+CIaI4 qrFY6vfNUhp3CwEcreJzIN63zdYo4JwSOsHiaFnqEbsZhn0Dw4khDjhRlY9CKtOykFremZHUmqVV CIgR1imUgs2YOdb5PUVngSbThATXRsgtswZNh7o9VVT1dHOcTWs4qQxgwWFSCRpBVe87IPA5NyrO fpv5c3Dc4VjVpUngtiahKDFJSNi+zD17/Hx7fGfBCQSPNyBIq8kavGSC2FJOrTHSeuhXoShRBdXc IhKBJBBKBUlGe1Odb5zmOEEgkdiZ3PAX0/B8UnhlhF1OtoFnLlbll55DXZMy2cZ0NvE0CU+tbbyK FIYtzhKohK0S0A8HbYtARFxiaoNBoVEJIEBUJIaVOdb5GcZOCcEjtWB7k7pwmFSErDnBOK+o8ht8 QcEiKm8IUnnXa8EkOCzOXZGZJaDCBPhW8PFvO10WpECOUHEUkKgZAimxBBeYpL0Nhg4OZAGMsK0r kshCprSqwREkkmkN5zeLOCQSNS3ChJvATZOpxRxWovfymKlTIogsrZTMlEvVjXh8zfU9eTtY2Q6O h/uVVT/0qUKE/ZWUUSDEQVQpUq5gZUrbORsgkalMWRVs2mG8OIeDWLgV06fDkEjTNbyLtng1iSCQ SKoRgmGQm9ZsgQJvc3h57ttsCBAstoiIUhkmcMcTUPEEIrJGHOCcEiGjEFO7twTgkDQL7SFexkjL Z0QSSawJIBKs0CTMORzOAAAHV5nRBpt5zmcMDOtTz2PedGBgYd7kOs7slN8TnbZ2Q3vpkQAAACSW k06KXSYgQQSK7nU5BGl1gDGlOwVMNFYrFjNS+Z7Bqb0xx1NBdQ9GwJZymYMEYqoS1L51WcZOCQSN zvBOLq96vcyzlmZVCIiogLtU1tc9VnFxJzhDlJR1QkpLs0Ne5bGArGJegtvpsKefnroo6jGDB2Wz vWpdGtOoagqixe22O34nwQflvlQYrAAZAhAj2WXpAGUAHsnvO7vY84gTRsaony7hA2cdZw6E0R1b okgACoAAc65GE1tdqqqqqqqsFhipropvvOuS6UOJ1z17de3E6nm+LCXRVQkuYlBd4yQ0VSTMYk4J EsGXDEMwa3EcYOc4cb7E1Zdm+G/2UH9tyqZP3kLBUXHMURQBxTIfDkYqvXX7eXqcN+EAj/eaxXID 0ndKbEgn7SG4jcSm3+hBj/ngYhxgoN/N6umi/6ijN1nyx3y6NIMCBkCBDZFY+C1WWyMAh3Ou9RFz 37ftvN8UXyixRaZqNtfTq1rVreC0CWA0Y2REEe1CHUFbFFQMv/OBogGSDQOQkQMwAYSZCeQA+s0D 8K3ZGg2yRii2Ki1y10tf+VUl419933fw/PL5ZZnoAAD/meTLX0UcXoCAOvi88uXACDBzNKzJpw0y UjQ3vWjIkwcu6vQAAAB8966ePI9hMJsCaDAaBznudOJvDfrMJgswwcmzKAMN8O+MlTdbEGASbrTf FeLyNnjHeOSi97XV7qlaLgZtWhC3NEySsSCQcwMhDEDJNwEOMMsjuqUmTShtiAYiRq2+d34fh5eb mrhV4rxp3aoTG28mtuiZJJEJEhNqTbGZUaay0VQairltQa0ZgTqWiloNVZr2EA8oQ/pZCq0UChSp vhHJQKRVyFMhEoWhFpyFLMQCgRKQotrS7tWua1RVRWqK3IoEyADUhkApqFTJUDJFMW1Y2prhm8lx XOc5gdzju7vrtr25r9SroSFu+d4d26WZQE7q3QxFfRXnmuy7uyQgc69dFdxu7u/W7pGPjblZLWvW 21XSq0YsYsUUKgEQuSIZADEArkgmStApSjSmoHJApU1AZAlIoH0lEex7T42euOeZrYTZWJSmmmpI hYjbSNYpjWvPPr+e75SPy37/j8dyi6kHehmvPYMKojU4zBAiwGIwGAlUpKRpf2GcYxrffAauY+/5 /XMyKqvdFGizRv5hzRMjvhDtpPcj8shma/F37nb10EM+crMl4/V+d3tVIhWLGpYSrtoIMCXRRQNB oh7mZ0Y4M7u+wcbyi7NSuKIkImbEu1CQA44GZBrWruLCNTEJA/g3nI3hsbG12N1t5nCORTCVJdxu hjApgwIqc4xkDgoCBIHMi6xUgT1tsY7ZxsAcu72P5wCWHrz3SjGqXAGjSeR32h1mHMHAVXfoETrD 4xAJ5hMIBdwuFvORe9EkOdbAdkrC+O+63nsVfnmyvN65dxxrqIFw64YRtwQuOMMhQc2SwpgLGG5Q u3iFWmHbnjb0njHHX1ZZhJ3zwVQy7GZ0OmBWQnam8QGevKjbTRTvJ3Xh2c3I0j93nfX3FbafTG60 OIr795257y+4eSu91ENTZt4ka1vBXvvac1y47Wt5WzMCjkEA64hQZUIq0YYFBSlJiVsIAMoidhPA HlA5V0J5A6B56njx4AyHPJWYAmRxqrUDoryZXIdk8HkWkFErdBQ3UN0SKeFDuiZUgqYf5f4n5gXd 1bGNMxciYMMuVJKxWYAZkciKf95JZcgSaY3DLJaRMtiSslIyXxPK651et0r3Jce9eKuuusayHDzD YQfxQJlYYQgZQmRIDeO3sY5KSQ4y/gKjxhSZVT6lWl9y6x96223wDUYs0FQAa87b6N41rm0axtFc 2kIoqjYxWRCFtrb6swoZIW2GQJiRjIlCalPmkhssgNapJX+jI+KB7FEie6FGkyVoiL1Dx0r7G4xU dpA3SJqUKvzk/X61721+jCFRkBcxUkQE2xoloo7ZKBA2Iv6IL+eOeuvXbR+mc9HN0UL+pjhA8vOe Q0IHRE1BHYKVpF8Q1EN4mWdyW9jwX1AN4aSqIxIciU1C683iX3odooagm3NeYSG4yoDcmaZVEmYg ZIr26cmoY2gDUEzEHMQC2LDcYBhBkIUPUhNzdydeRpmDldBgjMEDCN8YQ0ATcnWaEhIsjCHAt4XO pXAkkkkcyaz54pEwMBlCAmiFBMePO5vwTtvwY1zjmZ5thaVdtpLAeIoBqBCG49s7ncTIeXh5W3zP B0HjsY8oPJsYyERycBx0VZtmgqg1lRTkJ55zo2rh8XJhaHMaxilwCiYJKGd2RSgrESBoHAKuGTWD jQB9tNM+CuA4OEMEkWcwgzTnjYxFJtXHbVm2qAYgIlGi2AVN1rMDFvYUb5jQt1zgJl9UMMvdzMSn kqeCJBp0KoQZROqjRoDmA+DY1CEYTG/GxnUQNQWO+O9lTAZknmu5tXVwNh8JlGAzciASeFOnGwBI Q4kTgi04B3GOiazcC/BYXGGIqGHGjwfsYHTh8WXIUkhvAHqeC6V6ks7dHRiBejjYToXigDyHXKbU aIDk5G05RCWcclp0Ffu8BTA98FPEjllSwCirCwteGjeChQQQQxUkhgpOkxPseENrvxsTdKHIOCBw PlrLOAqB8Q0gdlTM9Zs8XrvtvsBA2MagVB+PaSEJEISQIpA+mDQwy5VPj471fxIRPfXc9fGa85b7 AEAn6Mj7J4kAdRl/acYkch5nGvJLoKFghHerbMxJL5h813xvsBvtjtv2dzYM3Ckne6tYodQTiT0J 1VnMM96MzncKOCg6rjDg7kaCUzezEzDQUGMmiYxopwYdOxdyPzypTY+TOCRzOMAaIQxppR3HMiQo 4R8n2t9hUmNRw7GGwbwggjvhDISJJYlKmtTZSpqKiopTM1ZMxmZtFr4rprKbZKgAg4BOA0GQ7Qad HDcwowE9YAbkNciYTFkKcQgS9BOz6NIyIAnQ2l8/PoZchUrksgkxw7Pd4wlEUccQA1iO3AoAvl2y XwMDxEHDbPlk/WgjBEXudS3wOj92mNW6Z8EAbAwo7xOMkOTrnfCVzueoTGCy+iGbA12pzohxCbUG K6wYv1y7GvR1vvxwQu6tLbZpLDEkJdBx3vt7Xq3vvXiHnW4Rd468BtWDGDCR6NtJ32mdZyV60S93 aGxmOJZdLGDXUwMTEADVAKtBBHAjBgUCYqLAngvz2g8HERnIjA3Acd4w+qpWrwpEDZ6O3ABR73tO PMrincrst888ZxjXZAnOjXmVjKtVKErEoDntvwVwVjooo0gbBwkYyUrmCYgGKzwR1dmxIMPHspLH 34x324b27djqMJIe+x5JYSTjv0GofCAQCDglHWR2hwsSiO3Gbno9Z1v0YPHbFh4PO+HlgRIxhGd6 dHHKC7EDgCZ3oBQXD4444GbYzoKg4hnGHwEBG7KYBiRLrHJCKQ0/L1hGaeEmTjAU6IBVan5EjCHU t0YbIXGfHBxCMucyJDiY2KCOyKkQkFkAa44yVJCXThEM0WNedYCzVc1RgKlVXPV0R7EDEHjv2Qvj zby9ru83eXch4gKFNW4xWGd4YNMB7rAZgcGkgobVN8+N9u/btGdSGoJhj5xRIbGK7PEoWxIkMIEq wk0bjGbJZzy6dZLAyvJCWrGFlIOzbEGsNEqRp66DGWANDnLaVgtgXUEzS0txI11zgTaJIg8LdnLS vBCaCKaJYnRsbp0akdEBlhPF0ZsmiSbXM3pnjmPC6cDLCVK47ELDXessQ1sZtkIRSBAkxvRZJFUg 9xnYICHSlsFwQ8wA7woxEHAv5DtiRCMPQkfI4wiRkq1oVZAn6qL4gqAOm7VQMQoqw3w8+u6YKNiL l8DeGa2SSEFH60mPHDEOva+jmBggiePyXAS+SiJt9wo1aPmV49bHBPMEHo7Bpe7zGabFO5kszhS8 uKwyO6dlB0ioTGUpfmcJgbxFiAcTsenTobGlHQQCDiM9JXPigfBxZA50Jgje1zXCLhkBzb0KocMj rB5TfGWspjG6QAF32yd3A685NreDgb2iZTFEDauGbHulMAza2CH6OlgxOPbQALw69j2ExBazgbXf A5FUwkpGPBVAXBI0OIFmFWECfSqb/GgW5mK5zjFTisgGCvO5zvvq9nFHjMDeyk4m760Y8hanHAbx TA4EDdQJxPenjZM4iFdcVW9OTYNuMa1sWmxsZDfFlkVDW+zlnFeOd8mEnJuS04lIPJq4YsqQYS0t AUFBUMs9pN+FrQm7MQAkBRTNy9ZdAPmQSJZOZ0MQmHipEzGtD173gv4S+RrXNlWlnu7Q4znWwRMw OYxVBQdAQuHRBuYyct6MIChEymbTGIxZZmAtLCADKBHFaizJKU11gTCXqGDAIGBiUnWgOVoljQAj eQLl3IJYBgF42EKohISgEVeDvi7AWfBQEGMDM3Mh4xg9LheXtgNgHCV3g+UJ1oaBTmYnUuwQxxaF BrR2N90Lve1S/13LDjHPu9q7bGHBZ2vnhphqFeDBa337nvjI96W6+1vgbFWMLDc6CmThwdoZjXF1 ULDyAK+O0PsJu+yBcjDrkaQtgBxiR6pcYd9QGSavMYkMUCB57cBhy9yqXR4O/fMeVml1iOeqKimM 4rD4vnYw0+MFIptOEHOaZoD7I1vUK04A7SDfr2gaFrfR7tDUXh547OP3YTH/2B+0YGP1gAD8dVZa Vr/Hq7LSbIW1yK7urdYs1zoVo01y62aZlXNrtEsYd3Xdcomkru27LMMJVSc5R027TZ3bopLOu5iW aZNsl/ra4YMawccHHAMSyacMzMgckWhKBmo1tV3aMDMIBAzRpCLJAJpQxsm8RWvDZbx0FbFiAhXM io1BoRJdWCsuGArY0NBqaJZMyBJDMpGJBYiqSIoxIkSKqAMVTEVSJEiKj/lkyRB0wtXK3loqV5pd c13dy7gAAq4o4ijFYitmZbMMklkCYGSAZiY4qiqgCoAKNzCTLcxADITIgCqoKqsbMhMcwmrENGtJ pczFgkApoKFDQIayErMhIsiQSTMuYVVTIoqpEiqqqqsiYijiKpExVVW5JMykuOZImZlkooyJFBSJ EiKqxQYqkRIoOJFUigBZACqiCWg2jUltFFgCFKgUI6JdAjoFwoo1UunQjKjKDikgUChSiAUSBUs+ jqecz4xeC7rBd61KQhgZCjMPy1coGGEOcaYzctzX3I5cNjxLe3670Qk5uhZ0HX271ITbrB3Yy5mr 9JdQz7guAAAB7O50qTrpus1LOSWBAJCEISYYeQAutWVjjq0m9Rzz2y7jBZ1e9M0jMCPRZWRz0dmo TX6SWWWs7s1WwLKGQhMDAzIGAlEK/Vms9H/al2FQSzxFGUIEUuoScnzLoTL1yXNP4v6vrrzzceid 7z5etSaXQfJH4lcAqhhJtkcRoRloDNSsITXXy5+N+PXt6+Xt5v6zm/Zzf1n7hXn+AKhIXi2qMSSU l11EO7u6QYJJJJCRG3mdVMzMzMzMzMytGgUKVSEfXs/Tm8IBAwJTE2hGGZCEIAqjCCm/a6IBm2MJ wzGdfsyfpDNuJP5hhgV2m3pCr1ePZpvFfSV7T2fPO8shvfxXn4DelyD1fswq8y5vH0MFLUokg5mz CyLiihG98JrBsRbB31UmZCZAZC5KZINKRw3mUWjvQlOWLnesGEooYWkuypmqZd3tes6NXjZWJmJg IEMZCc6ZdcWc1jUiFhx0GlmwrCCsCBsiYEgcYwvGNI5O28MOt6RwzWxLAmGsJJjIZiTvO8ZPXd3N B4xdNeoVTEyxaxrHC6t4pJ3ycsk1IThujk1hJ9Mz5fu/sf1X9eKKmQZ/LbNOTUq5Wa04EwyBYWMt WLH9ZwumAAEgDS1VNFJDu1/aRL3h+tsGttprWMkwYNsYlzAgOghA6iFQM1TLuFRY/dIug0KgtXJY IJ3d7Jud8jw4ZzYvNOkjN6uHjc3DbN72Tm9x8ujKZduXWO7jTCWyWNWv0+PzPVkrPz/cZr+clo7z 7cd81XDhx/V3z751kDhGBCEIZnpyQ8WeDzv4KLI+wk2RkAgaZzX1e++XqnjpObhFfj63aKaX1/d7 Nd9M86+Tf79MwDrpyeiZNQyEAKf2+HoyXQCisyyxVMmcF/mPzi9wYj+JH7RWE0Ub1+GoR5dPhokn JChUwLCfKcQjfx70u4FTf0I+qRjJ0n6DsLghxKFw3Bv0O5SUmN4qR4oeGgQ8ZVnvBH49/pyfTjxX bn2LLr4+2tjFCaHIUuTz6QmR8/Ulbxh58+/k0uQ7Mvayj5HD1W0gSA74zMCLEcdd84O0JH6/NGDD hh1jkvPisJuGLtsui6oAyFiX+77gjt+Wtt8Nqx9W8GAxhERSWaSigXzlPqS2Tff0sn1hw8AZ1CIm xJJ89MsNG4TO69k9ufPWqQKskwm7/GTU67UIQkMocZTAktbhgoToSFcSdVhAJvbSTZFzxbU5q59y b2DNw8wkFsSfmgylr6NBPEjic2zo873XZE1qecLZrZo5pkobN5HvjucmTc4cUDZEIGnUhZ0pNzI7 1Z7LM6rrDNG7+POqnc70wkeatMFYsm3N6qlOXGMYxkvaVrOJ/n64LTXIqwBRB9KxD5NxxVSE6fyw /cHgRNvFq8rk6N6hftLLl1a9sphMDLyu9QMtG0Hl/GO9vkmh9xi0ybPc7J3zeU3pnWzcdqT5E3X8 FwoHgk6Dt6sVkLODykC8j7bUJUo78rs51p8hBPqCC7IAvq/YO22CA35UUIDpbyzsYIUGFT8zwu2l gHDBtU7Pi06qNKRgjAYQNcM/cYjqowP0+yApcjDRmN1zv8ttU/HvMoN8PdreayuXT/E/f7n1/Az8 s70BA9oX1lB8yDUHrfGfSU8Y4QL3xAd4gFEBEl6l+oFREXHrksATYNSJBkBgOVLW9S8fvzzmccXB OK2KzKq6tqrsLN/34q9RK/BrHBo35dXa7Zcb125SzO/FYE2zUv7VzK2rIaIDTttaiHwgodIKh0EU QzxQWEQVKg8QAA3mZnfVig9oojoIomx2oAPFNGcNMivbFia540hqN8+Mbb6AYTvGRAHYN3nbubaC pswANRXmNEN7ph243weYuS86h1lyHlAuC3ZMTQedGjDxNoO0exDHYxQkUERBPXnRwK6EKJZnCIHh yuyBD4RuqgYRWKMACFoFi8AX4AlKxFRVIPGtC9gZWwmaY0JgSe+YsChmKYqmmgKCFrVsl7pmwdSE kvVIXvDbA0PKLx3DxtMC9uG622xWAvg4BA1PDiz1MdshlBBdBC5KZ3lwII4GvJksO1+AoK2GGISj MsQqDvb2JWVF6vM3mrWJUoiI1rhNyMc85sx+GeCahNTpeyavn21eQMnDCUxHJ1JRPfHLR+aeV8lD j4dd/Wep1SigoYECBD2YvPm61DRiYZHAxmIxm0LviOyD4iohCuguZyJoLCkVoJgKbIEAh4FmTAgE NQoGR2zKZsm7HMpslqpWCjEHfFD7gaiVVFwmqqKyGYFDqvu21avx0ZQoFIoYmKGbERYVSUVttUog xMJCqjJBQqgUyBIIzChSNKtFLSBy3c+b158+fFCeUyyjcKvqEktr5h8XRnqhQMVsGvnF9ZdvdDKk ICkrxv68YAwQlRoISjImZTbz0rtWqeePGGHlQTsXcfM3xv3waIbCB6ihOqbMJBR9Y4jWESJABEmQ GYkkAgge7a8S/NAoDyLiaIAg6XByEhrw24l1a2i+RMwiC4OtveWV1vn3znbY3BPFEuiHb1LxNplJ NIQqBJPWevex59bm84VANu3L3MOjXloIzqFkPO8brOl503m1LKhuiDYJDBiTq+ZXN95nMPzczi7v 1zP13swrTNMm+gs1oTzumzEo31zMxa2/aRssJQc4vrZ10nH89fXuv6970z7+Lvr/EUyk/PfNNuA2 +6n17oW3y65FWNbbeUb225ql3qs7r9Bsx6bW7gZR0bbvt82p5lU5S9PKUfPp1blW3a0IErlPaPMu GHth+JOA1ewEneEW/AdscHYx4bwbQ2aMr6ffQwPiAipqKo3VAmxgDHlUEp7rZqt1mbmLEoKoALow UMFJJJvfMI6M73xSpBIsAOHbBwJGaTqoplz8zzikjU2CIMXZxBJDKevTdhw367ZwriD2GRhHjImQ UVUQRJQxUzoNpo8PHx7HHpXTpnTv58/ce5mDv/mArkCGaAgkdI2gcYT/izVQCNyVcjNGXJcjqORm jJdTUq5jLS3ArGEaRwqYVtqmpAl3TZVDGJa22c0gxgUDCYjsai1RYRmOJliebrzyE3lq8quRnd75 5qDtrAMCaYnRsuZhttWDABOwaYlljYUCYLCNhEpoxaN4LmAJUxWy8Ja6te5LXnh1Dxu8vUexbKMQ haWlsokBogzFNFjeGyWmzRrRQaXQTJsEGxp2TLaHWy1XquybvMlShLXsyJfq65LGgdgQyU3BhNtG jQ5hbNaUgyxoMdLhTMwZGBh9t2FO4h2N+FHd0RPp5mPLfFdPnXpXN76N0uswGmpqTWmMA0xLGlwY hNTRI61LxXPN7d7eW7NFLzzpXm6URUYaXBszHF1BkKaq8EeknLww6+p2L9Vn7/fff3wGxtwofjg3 tBzFk33lQz9SRSqOm3BAEfrvQ3BITMRddbmvtjmceOeFOagdxzdGjAJNjiGopgqI71sLYPudtWuc hs2JF89ft66+kLQ9TUHMXtLm84mJ2g4h9hQN+jYdJjsaBT3D3CED8xmfbhPxXKS/LvWtiQJsCwyU 3tg7uTcgOCQM+0kc4nYfXcjIJxpEraYKQv7MHAh3XAd0VUvJSZqkxEq8tuYBMXZmSJmJ/fFTC3x3 qutzskjVRUoSGtJzroVIcqo9lQkI4BAwAaGhQhFJBCQEo+fGMnbfewKi8Vm3BAl0ksoqXFKg6jWc 2GcUe/vfrj8fGtg1xS1B4qjwj2gni8Yq5JcHMCXV3WRRwn2/H2wAm3Dvu3VhaeoBiHMZGhDQUAlE WDmGDB6oLY/fXz5ve+voMFNEJwAAQ83QE84RcgHBD2hYhDRczB1dG0biTFFYoKgYyXjDUqVFfxnr 4+L+/fvby/XIdoeCPiBqFqM1DJFzDApgTxQki2VHU1misUyJqNwMxaxQ385NfjxttiZ3p3zQXOBI lwdc0uYfCCiYDxpw7wxOIGI7SYrELuqgZxQB988W6ifaG25YoqMLLReVNrRFigoUhQKAxSrlAen0 eiSuECSkoG9UbsJEkHL4odQZmiqaahmDqDpo/V79t7RjD1b1GLgI4oBgoAcKiKCHoiBPhGDbxVID sTS1tYWOt6DU0Qmqbi9yXHECQJs0nj8ff7Tvt1sVx2sKgEuhwdU3jtYXdBVUZD5BoxGYyluZtGRG jagvWrSapAvFGJV7/jx9Z+/3rfjqq7SkDEHqB1HETns95Xzs4fHOhmB9dB+IO9f8daPmBd0L2feL 4eLaAlKVHe1t4td3Vnz+5xH9oHJuLDxYjvst430a1SSk3F9XSO3bZfXDtAvl8hN3QngvX3jCfeAn 4/fUPrqmoZIlfFI4zRi7uQuGI1E+0TMTGq88fbPnnvex2jIuI8wLgyEhYc05zSGJcDMTEcwMzMJm g+vXx6rn489d+F5i3OoSSNxOoWgfXgM4IYrMSyLIoX7pNoOYyLWdWBiOIVv65z9pnv18eMVyvU6i 4k8USScRzAwYXzq8ZJKpuJqCahiqqqcsF5Ae7LBGeoECgpq4g+mcedXFRIhEsRMgkDBJRnvO3Os0 E2TpZM62ybhNVbbIEm3qg7hu0pF1d3zq8bgAqqCWVBKZBCBwAsyMmcJOccDLpzhgbuOU2RKbqn2+ nZ5+/PPt8XfievZ6JREiuRJAlMT1yyZJPf5SRhJA9FeKjdT1GFU49w8fVGTUm0TYNohmDIDkmzev GIUzPM5LKxMWYNjUPe/2yVggIWFaeQEpoLWC+Tw+ogq2mDkYQmCqSqqiAfaEMFukUoGTTUxUEPkg nvolP298vBl2KiAe+873xCQPo1d2O0V6n2gn0QIRUAQKI8u1xhMgkPVQBz2clyvmzp3He36dAOfL B6w000ZGMmrsd56HB22t8O+BqD7im+KCRxmm5pi1i7+/HXW3x9XvvzE0SeyyiYezlLos6hyWG4mZ syOvVmTXSokC8sQpRSgcqgkQOOzwvPc4+rdqilBYgXLfmvMMwqdQzBxqj51GFGIFYqQLztYl3i1C oPuBmGcWWuZjjPx48X4NZvY3ivMHtExBuNYoNXWQUQ0xezgwE1QYkgjijFCygOcoWDFflVk2G6t7 +UvE1LKtxpCCGZ71CsRqlvny8LgiUybfCLPg/j4sUqIho81ha8vd/r5fOYs5CSMomnZcqo8MyqVI IKkY3hscbz5iAmaElTUXAAHigIjg4kF7AlWa7+7e/nj8a7GxItNUKyx6MoIwEFiCpa1ZtZ9Lwu6h jQMCQyye/3k3Gaut3R8m/LcNIV1l9sWBeKxtGb8S6X7caz6W1ZB8dnMZ1lVnIOdI7JGkdC6b7o61 OvZTTXuGWULdYZ1cx30yK6uU1d3yg3c37q86DBYRguaWw17yBLQmKrMZRohyiNectnikKVVUJGea peGqzaYKqFJNeq6wepZVBvLrctXWMUnyur2ECNIMqGcSVJPLTvN+HeSw/GfNwzDIZURPCEChlDmZ y11WNa247HZtSxv1CznAlmZiV1vmYZznTU13cg4ki5yUYEsVA1aLmZ07cu6PaK3xVCj7f6gHRHqc 1XwdWG2vfUsPeU22yiWKm4CXRnsSUebMepjYwGCFx6SHyF9fJZfPJ2MS4Xe3D9d/HmtrqpXi91xE KIqEgiiFypOkKGT01107ooDt3mdvE6HQtBAGJD6RD5rPxx3OwZ3AYQCQ2qqsrCbhppSnWlrVZ/k7 kAoLQLAlVVVUrcD0IkIQiRi984C6zZi+MYJe3WD6+KNa5N6YukrFlnF3Nu31u7thbi17BVOEZwLF xXqw40nvMCpCmQApMfEdAwKhTdc3lyGvdbh2g9kMYdoDbbEHwLnBysSFtLWFnjzzU7CqWbAzWCIi QDy+axIcRmDmE90vrcHZt5VLwSxJKquECdEoIgf6sGMVVewzLzULw8qEdSqgrdERLvcUAR7wyhVT DCc8+59kKCikETsLIXOcaKzDct2317ZpKlFKicc5d036TN1vDbtC1sNDWpQZ7s2oj7TE8WjKuBRL zW597L+vjb9v1V1J36a0y8K53lo3aZ0nISHSxnj6z3liBwylPvueSx314G8SvI9mLer0731cVLJf EnDDP3uz1KLPUrawadFBMUqnQChQh6Oe8EopF761TPdazU1sUYjCIMjKAM8vKhVJpSpr02t5Wlaq EQXF1ARnelWKKR7vznI3jnLO88PNiWDAhTlV2j0UPLlLABm9rJdvu+7Q7RrLSyJZAzPUqpU49zXE PYx1rUJWwLhzxNJEIEqxZYdu/dCLbObGO5JSYWmTKemXn5fSH16mMhsa2A08bcQOJ6QIHDHeO8Cj V1eN7tZgyXOK1xXOsy4Bv2Ckm8pkxFHKsBsC6TiHmZzQQ3CqYEDUaJC2IP1K8alMY1O7avlpV5Mx MWTfVJc1C8QhAOQjtkqLUSp2h1vdtwbSJ9QzBJMgQMERKTJaW6IDiyqopO0F2lmiUDGNUUNQ52Ch yVqSdt9zQwx3tkPOyCigTbDHbI66B2xSyGbLuBCBDtTQTnGwDucdjGt+Dh8Ed7zWgCMbSsICeshA 0yaSDK6AzVEaCH6Wq5lNbkqQnfGb26kAgGlPQOT8BCz96Qm/DMh0EyWWEGPqqHvhunF7jvdvACQI IRBMEBHqD4VUqHRjLOoal3gsnt3xymS2hpWrFJRgkrUJt9kzy8FIhqv+Uza8hSdAStgBYaG3iEAF Kq7e8NCggYsyrRAAzMir8X58pPFtfWcILVuuEGiAUKKAQCREiZO0I6zqvF3bPU9z67+eQ3DfXZHq RYgxCC9Z2mdUUza6Pfr329HvbebpMyLAIMyVMRD4nclLm4c0NIeTj1SaPBsgA988bA7GJPq255OP uO3mLEC10QeAAkghEKEIgIxIADMHMkAxmQPHwcHxjnfW5jeE4KFCAiJ0FBFHh5JJBdTtWo1IhFh5 kSvPO94l7YVkvhhAi0M4rXHVu69IYy/OYXm1XGJveOBKGIKwLxOq7BW58D31anrN90a2nUHebzpE dm1Gt0nKf27uphlaeOkZt1adcPzWvh7wnOq07d2hDcUrG96Wo0H0bKRuKCE0vFlbXUGyFog6CirW HHmPHz1eKVqIFqkHq7evnG8vulACiVKAhEQJSqI5KkgkWdW+t5u/ohjlxa5CAZyETxggcSSSCdti /mMy3ZOtUkAm4ArdnEAvs+q8OM+a1qlsC6kGC8Er+eQpWcwQQiDNDgDAJqiEKxIBfRKvkQL8lTJt 9Z9T6lZWrdVYYIR9eXfVHM3+R0tjdDSRJMVRUoc06HdrTbShlZkUIQxBWYLBmDOIRxSLZlsENnN4 3tKx3x4z4BTvOoDvBPEcxaqoWU4gklsoLwPEvFB5L0YDfz5DbM2U+pIMshXyofxveyOgGQiHQhIf 5S85KPEnMzUoSKDrvXPJ9jnCypCNFD7uYHjOEpyzyfsvJ6epsTcaQICOM4z9w/VbQdq9EoahAiqS cS57zdoNKgMxRETaIAU6zihIFeVy/en4GfKjFhMEC6BMKwPK5dveN5dy8aVuAHjOxAPgt7clzFC2 J57OOQl75QBziKL0PgSMX8usunOJ8FgoqcIVQk6mOarWYkkrZfK7TfdcbfGRZbUhyLjQLw9tG7xq OBW844Ft5u+sszne1MVzVeTjPyHhX2736B3q6jpWc5t+VoNatPbiOS2uJzOfZ1C3Fuucw+b7vft7 SG53c917Q8ilYiLSlGlciWReGiTc5ritpQmvyjvUCAqCRbPOWtau916CngRAI0cLh5Gl52LRfd17 0oJEhKoibRACoDEAob0pk1rXQ7O5FSCRYIObZHEgkecff3K5znRtO1rhB6FYggp73MdYxm+Tzd+H wyMQUT7Em/ciTwEKI3dN/OM/XW3XcThN0FE3DMHgj65x48t8Uaqg3h2mxwVczv7ut97k1zZe5ouo BTTIARgEuO2oe1DK4jYCPgM2Ai8tJzzqZ6j0tZEGYyGGCwwD2qB1VVd6rc0Fdeu8mpqx4+QU9ePR 4aDl+ZYQpAhgiIQtPWAXwc7kE2uDNsZzfTbvhLCZ31zOkqg8fR0799pOBrVKgsHEEg1UDFX89w49 1CtaEgE2AaOGAT18HkKUPcCWLXlI101D/tcAAKMPQJwwce5s7see5rlmqJE3RIgs0bFmDZ+t+M8V ub+Jmc/SKKdG9CDbjMjJ95UPM7eznbT2x3AmKkEk3IF2Ug/Ob+ePduF9XncVndAkICyeIxra85gm Ouzpn5pnQnkUygkri5bzc+WGcREEIgREEQShOpDXkpvGmxuG94lnzN7tbFQ0339mEx1Cxmd1Vadl 0ipvel5WX6tz+/LNtI5Z+X4s/wdV+03rto+WkGp3pe6+XxBMU0TE5d/Vdch09zOtQoTicnm9ZfOy J4vulfJ5vDridK7prSdT53BPNDMqXtxoY8oKk3CPYMe74/vXZxjFPjvMjAyiIlmAi4k81jPZQrjA ZKAmwF2YGfFdKUharq3qJ2Ab45x6VNlnO1sGx5y9qcvhlymArE381qF++dfnYp3x20yBkjMhIoT4 EQWA0gmqurCYWS5ePkD3eTJWqo7s2EfWfdobmpvIXovJISe8KoYjIDdGDR40U0e9BtdDKE2IBIxg kEo5axXUyMiw0NfBeGRLjIjpBBBedG/LRI3l5Q9kJt3rtPgRsz59eCXo7hAYi6EBxC5FKD1/eAm1 LVF8vfaM0E1BNZQRzgW1jsOCMTJEe6O4QL7MMnfO8uJGGgaA9yFAYGNxGvfYRJkJhEQFAEKAJh1c iDEjLPr1sW45+OS52wS5yNFAEJRcqiMGAcSQC6RnTwmG4hJTKevcSTA3tOjexECUmlCQUaNVDwCU LYnlutv2KTMwlBUglb9hl8IRJJJJnbV6ztxoYxT3KXbAQKoBPD72vfbX7G00FS6uqZD+uhyFllhe 5r1t01DE6neIRWcJZLXm4yhnHxsuwZTOpvyYP+CPTyB4q0mY+F9rmeXEbQrVynxHnHzinp9POWsu FfSxtay0eO06X51OcE2vO6vf4LppTvPQOfNcgk/HB7QWywJekW0NcCDH2BE8KUyOOoFKbnd+aa9h bNBUqiqBZAByuR69Iered9drzcM4finbYI0E0HroPeSbPta3nXyFKg9VKuBDbmsa1c0RaFw06pUA keFHo94KEjGdDuZ8hzL97i4WszXzQ7vG2KJpaJHdpQ0LpTSGupgQub9x1kxUaDmjWKVIJQG2TAu3 xA6oi0mEUAfgE8Bc0RZH32pXFqikQ70MUC5qPO17uDWJ9u0eNzBThglnwbXk0c3sU7b0YUU9bna6 8bewLXM8pOCTxuhXmjLnY85xZnMyiDDSJBLKmAyAD0YsYZKV8+0FhphYxSQjkJHinmcdyjUNAAD0 QEKLhRvQbGPPjtp86vnw3k75SHfttOkhGTJEKiIAFUKiHBuHwZGYKxrN0USuF62NUDrhmzFdKGge ylSrXXSaIuX83yzCJrFHgIEYB2AJTHwohZBvUtiLGVs7m72uZt1RS+QCcYiWG7cYAZAmBgQIb97f S61761pTQ5DGTBi0FEYk/ZPgiY68vrk3zjbWMFh1XbBRCBHMjDDAjAwjHDmaDCDQbEd5GxeF4N6M 2fcQ+8e58nBnT9bJsSbmp+YnxA+OAJJBxNp12614cqasCCSgqSDjBQgFASUs1YGrt+QoqZru9fPP d5dfXt48uVPeJh2MO22xevp6e245+2/w249wckpiQGJSWCgAgKAhCCrEm2/XZ122ub5adwgGAhCM wJJn7+uK+o61sq7iBAZAgwVl3GTv6+fVSfcxmAjMwJvhp6355WE6gBycVEZ1yFHkeylA5y1ABwAn 6VHhKh4J85ixdvNuc9jrvtEwdAcI1GGCbFEm2pNkgivxLdSRGmLTEykaJYIEgixiSIqYxJJ530fX bx7331nbJ9e/c4dCGhXb7kWaj6jT5wWTUtKNqEyW0GuvvWM65NXY3Wus6zW69WzzTy/WTTcbmye8 8uu+szz3tdRPasd1LCMy6e12ie80Hm24Fzw83D50kjsdVc6WIs3ztTGl0sO5dWa+53ea609x3eYo ZxoWIOhkzVpLvWdhQRKbZeZtJdNeSzHKhAQUJABQIyW00ULG1YtSSysomZKEpIqVfXRtVdOvbnz3 cu/x0d1NREXHjx493nw2u3qTndVVVe/sIeEpSoC5HEgyCqR6oM3dn8gIzRVI9EtMOb9+bScCdIgq AzE3x23heG1RpHO87GwlIE+3sw9DCUQyM+KMBrB5G4HPzXb6sJT3qkhbNUEjWSszELMUA3GQeIjo bpCZpXUZAu6dmpGRS1GHDbn5cLN/PiZ2snuqDvUjaNTzkKBwk4ztFG6Q3QG05tib5VoOkqbpCgIh G7YagHrAd8iYgWnLj2+PpBQ+g8B8zIzaet/j5PfqaHcDM0CqhxzWZV2roXmLGhJlknlYSzlJCeQF W6gRHcnQkA8RIEkQFApqbXXdlPhW4komE8KICGZCty2MVu4RkihizqX3vlc2zmwscJ2ahsvUOpLc G7uj5zoAPngRzgYSvm+7aoKWqoJjtfDSdxzcXQEyMh9KG69y96tWvj4U66OKytwQiaUBhB9l8iHL d6RrW12eJvixV6fsjupuD94rkcjveZnNcXzDvOvrhpleOvd+G+0qn3ud8kDStrnoDLGdqaXpmNMq tZxzAtl7CGbGzgiBEQclsFMUrx1xy964nFKmxUEcvfHA6VrW1vt7p6iDKOZxRCby8a1rPYOAiR8C VRBVFDBxJHIetSlMbnA1RVB89zSlILevbe9GhieQnk3OJLw2fcRzmbr8hcW2JHkeFvXYtB5xp78S 0ywodZCvuLG/HUf2WKJSas17XDcf2Z0M80+i2fdj2++VeZzrOYFYN3Cp3vZ3Hfeyp06dHPcu1dFd bbnc8m0lqfuzeSltdPm83DDV90MvHQlUh71tlijw+Y53SatvZhM37fNbrqlYldB8lN8He6W9cfyR np3JZ78GvMi3hKE7btc8mWnne2D7rV597KiFR19p6hi6ayuWz2e54sJAe409XC3jhIbS+OcuvStE 7CqQBotlofWg67felipbLVwbXr3ujMbCarMO9hKpeV5/CvNto3UPOnFJ2ark9be86hYRfdc5lYWn Qy05zFbqevajmtifeWRVRQRLLNYjqR4izw9TuuZ8uaWZd48zsL7Ge9GUMSg8L3Tjp5yvb1qaVc55 PduufbBfV9l4mK1mfVyIsPmVxwhiMKekWRs4JXLzwd70P0Nuu3xYndPU37eUm+53v3F8TxbeeZzQ 0WzG2sq0XuvP6FHj3i8L636BSeou+TOsrvns+puRHPJI7etTzgHNK/t+92GLvE8fUNGLnnvSu9pl Ybc503KFnryPV23caXOYddw+NcA2KkE12d5plqbfqt7WXGl9evZ4gfuUuXarJL5rTnkoxrbLY1Bs r7zdlCo0b0vuwPIh7ejbZ2iXN2mvRALlxt3cjfdR2DVwzVpzUezvstTabTclJ02/d7Gekj1I0RE6 87dfR5G7Sju4SVKZyNHuuJTHcRmBpJmtcw58wpNX3e55cIm+7V15EeW4YL5QtsvC/Agjt65lSMhO Nzzdtplt8XOtJvU9uOkVNVXdoiPFXAW91vslM5tOR1q9MUsezxZ0w0Zz1eyVe/OeBrMb6uViVzSu VxcXvWuchzX+NrFTTJnikY3YLfMKuD8q4WtUfEv24V0cbab+DOilKD6XnkbyIWNQPeWb5m++feQ6 6ce6sN7jIp7G857rN2mUKpp3ZlVV1rWtau7tsvp3WFVVVXZmZmZmmXd3zndVVVWUTLuzOic5vXN6 1rOSQqqrMzNXLrlVVWzMyqq3d3dVVcRCSec1nmua1nPKrlVyqmczOZmkRmVRve853d3bafTusKpM y7u8IlTMzEZzuqqqqqqqqqptPp35zeubznecqqqmkd2duXfKq6pEQZh8u6QiIm971nObzaqqk5RE RBp3Zt3czMyzMzW727oiPUzaaQ9zvV32F3fNRmGjPp9rsOs895OlL4c9746571V7x2Kao1tu7SrG taite7JjgkjOeNlo6ee2YDI3l4+dP6Oxot7L77p8uqa8sbSXbfb8S9ou69LrU8V628ROslbxnijN tmOS0aa7cb3kHK8V8tA07Rns1yNN1dalutKX7O17ftQqqJqBo37lPMaRm3rur7XOKD3nFvvdTVeP F6rjQhVuduncxCcJDadc8S3yvE7F7yqerV63u9TFxepl9+6KW9TqVno5xXGro9PuWkT6u+Vri5V9 ch8Gl877jnc37bRVp01Mz1fT06jmynhjGJ0cvWtM1p9E0SnhZZ7ercAN7soW2ze17KqHFSrllRES kRERWqWFl7hBLOpNswUAyRD1nUAxLz4a3vumluWs3nY5JKVM1e496pvnKY0Eit60PDcNlcjWuVL9 9Ol2Ws9t/TmBWnFW4qzFR3K6WyjVtJyOLSL3tP3eVy7CH1U0ukUXqM6UKvmvU+oard3N33fjnlSH 0Ut4tr22tN3be2zcbq3scO9cVbatXCCH4YHqFXx6eaSqhk9veo5zXt1I6UkIjvsllMD3qLXCh/Na O6+gQ+5zPhmIqmucw7eZdsDdu54m+7uDmdPezsnWdBeDjjqrYvo7yJDIG1cZe7mJysRV0kQKeI5G ZSAdU3RFLub0HnarWdRoafF71lEflELMajetSlYbbh0nd9e+GHqecCe35k003nr1kuHylOr1rlbv w7Mxl4L/zT/siAJ/X9kH2AACBIysanXXj+pdeHf6tIb6xPrkcCJcLcXFbFb1h4JHcBI+0e6FIbIi zOdjBkQv4k/84wH04b15Hcg2DaV3/ZavAz4VEAMLmMmQNg5W1xMFhuVKl1OCJlF7+PvMQeB23Il0 7uejdHZ1ryj2VJbUZpARmDppighIc49GShTLNeoMOwsSkhdo3gztGFyIuzNlkHsqkH0REE5BQ9gV vRs3BIjBoLuG8RzZ1N0ezMvyzR+d0q1ufgHonuT6tk9fNsqUjM/V3ijC2htrY556zOQQHpQx+v7R RygweBOUJFh/8DAfsn2COHdAaB/pGL/wHgehyGV3HShBiDbrWMQDCS09mr663y17to/u0YJvkIqp rcAaQw/mOgMEgeyPEcGCE0Eokrv98zVaFDRxLHgAsU3QyoUcA0H8j5AxboDuBQD3BAcyDkmyVVRH QQ0PAONVRGEpih/P7+BF/+P4MWn9fvirk4Mi/9cucd81j9GINZlHNfxf8wOf6KD+ogZTf747S85/ szaWX4WZRV+PqZJOSoT+QwJgOEk/FI/s9CdXk0p2m+/34cznldTbbbZ96CiZnby9MrTs0fewq7dt 3j7mJLvFlxVIJzt+PqSn5PlKAlCCJ+ZhqdRKRAPnGYEEwn3bxmjiLSDwSCQD1ffIVm7me9rQ7CBw ZiZs2a3nmkCk1Qn+iACsLd4HQSJBOXRhYSXV/XToUNbZc4nfMPfO+GEriHc6pPri6E0iKPdL2fkt Gcwv034BZ3r33zM8deCXzNfWszoTe+xLp6b3ydK+/Ufb2jXLomdzc9dU9e17wJaVzXQkPmY1rmd8 Z8vt+8aFRs8/X0O23QW+tWOj53mu/uGF+0CSucuWXZfBKHwJVWP0qV48P9ta2l7eokQf3GPCzgCU JH1Lfw3a8/AgkJkA0CDaDQ+z3k3IXq/L3vFXQ7UASqAKgIAFr+dwIlGcTCr/PX/bWfNvDnHRSMu7 fy9vX16eW/n168+lX/iKf1HoCIeiAcveP8cR+yA/UF07dEFE0LuP0KIZSUYoLISfYNO6UoIjUREm 1kYsmbbEzRizKgo1JuJdLJGUsUlI1mqWCtTbWubRrtnLmatzmYBd3V3cRbtwRZSnhuPIMj+yofBS KT190dsA+acu42Hj7vPCPntpncOXsidz/AD86gHyDf2jlAPHfvVocevJua/QSCec3qB/MNoaKpKS OZhq3hpwh2hoRMhe6Q4kiOSGCIcQaiEirxwca1xzsAbwfRDlhtQKfhahAXX/sQCf/Bl+/7ANL9U+ r4/o6KW/UjsY2/n8rH2/sS6yWWl2Yp12vl4CBMSoKfBLEcb3qxj+UhWpsiqCJOvCcMmMkDBFIZSq BmUMUzw23aExnUxR4iPqwH9IJCDlVkL+x8dulucM/K2E7hERkXDOAcjtU5q/nkRM0RA7xQKgPeVX WhCqyzfk6UB/nYMqlCWDEPKw1qznaV9ItNEShy4OIOBz3Ht9ztOglyBzanN1kLcGJSor6xvPLQiL XPKwizRjERv7a0XsldVde5We+zTO7qs882o3p1Jdtz1rpPe1kz3yNUul8mPNlJ1xd+8i5S+Qc+LL r0+h20/GPctXuWuZnU65tDPpyuvC1e557X3cmc7v3Op+UEog6r7cngQC4QDahQTbpF7QOaZv0T4A PBX9QEvgFCCUDnCBcvKUqPjN2XzPnu3PsSTcfCiVRyOJPs5Rh4b685S1iiKFP0vc4rXec5+Clgf3 H4+gBohASiFC8PIFL8t5nMHZzH2tbi4AKFNAopv490FmPf6ceHP37d/j4+PjzOn0B+4/wT/lFjmf d2QH7o+DKtLBNCAEMo0IXqgWIJaZtSySaY0VJLMzZKVkyZqqVpW0vwq/qBgkjCE8/n8h8T595P6C 6Nfyb7D9OjRvJx9i5eEDRv+6k1ezVhyl1WaCkt4CueM7Zu5eBZWrE5sDvtOnoKppIEYkfjBbiJii mqbINz8G4nMIc9ucbio9v2664du18YuQ63nwQBiPCBno7IxGfzVBoPrdD4ICoEJOFZD/lxiw2zid 6vnzAvNFwknuu7wle1Ba9e9dGgJD8iSAX3lC8mytnzvazC5uVRNkIPUD3BHggkar2VLNDE1mRUIk SzAAknXZV1LP8I1SaChqp6FSIUFxnx8/PrPHnPjvrRxOUU4q5dfOO2tXusHD84UmKIgVFBPPMOM7 Ttiy+VmlkCcQADemcHkg9V8dvjO2L4l5Lhul/0LDICAaQgkAgxJopKZGExoxY0VFQQwUFJBJQtwx V8Nt2+y5+nDoc5PYyIqgS4T1ziDX0RrWnbdxCFe6ux0AmlYOUb7ud72bNPRZRXm3hRvvbQaGjU0D e4w0IzjWBczN8vQzrWol/re6Pedv78pyXHPTqA9+zca7xsvp0jullIkokBizrUu0J19Dq8UVfqtM qNVGzz2ky8bO+8Rql0v0x5spOk0DKRXO+6Ifmqrxrzvm564tSLSzt2q3EM5lQay9km1P7An2CZCD 4M8XxSD5fd7mfuMSnT6AQIBZET4cPDyyi8ob8+Z0da8HzFycDRQJTTygBeSU+UnDve4yY5ha1gbo M6c9yvR+2y1bG1vLP3NK+i4T/kgZyE8z8buanObxPlrcnrFmR4dOOc+l06XHiXn8gf0A9gfr6ZQY PwP670cFlkEIdy7n61REFRMkUTEkTRQ0BRCyEj39/y8I6kfL6wzNFlWC2OFlIQnMXUsaQmvvuf1T n8wpWSBiChCYkZZIdG3w+KHbwph/MLkJyrgih3U61+/Gq28cMryVo7Szc2Dc21/H6IbFlVUR1GoV AOwEMwowcAaqsjMdC+ybxsjGOkoE2ASObXBmH9AD8fALkiE9kMWRugO73k91mHv84cnxjizBAmwF 3B71LK9h/AImhD+2LJVBsfp+dyUOYExm/8GwpabioQKoNb/S6bc4RBJkEHxdBwUOXOYVtFv+axJk ny3l/4I+EQqqCefaM+To33nMmgQe+hGcH17AHvy/ZiZqiYX1ykzEaw9vBtv+YfQkAg2dBnAEgkEl Pt+PMyxmCJ+kCWlsgClicEZ7MaqE1Ro7owNUAHT0I5xPc6tm1LqfKRqKsbDGGcCdbdSne3oJ0DRc b0jh1RmgMB10OdqMdtHdsYqHvGGnQdZbzP238Xu7/prO+R35vfaW37Rrrd+fGnVx1KZON24qc1Tr 8z1eN0K7HTV2XL6e9tettKq3uy+zWfBePPEL2q9EiUmIfPb23Z1uPYzHG9vglPOTK1IwrB9gtEcX EFYLb7yh+UXMqInoEb/J+lsybGJfFhr19JBPsgCIEF0CKPs5SCc+fMXphnZAEpmoRNgIrEE2K/Vr 7x8+sNrVIg4NsgIAFmWBbz6y51rWs0aPjQVAH6oEZuLx7nO98rO9z5aZ9REqUFR+AlwAlIiBD1B7 785H6822tv7WwIwFH6D7pV9qLQwk1FiCQLYszUmtiqLSkbapU1Fh+J+SrGx5j9Y9zvOBVMkxQQTU QjBpSjfO25ZRNYZCkWFycCJaKIok956nz7g/CKCvnJ+3tm2sANaxb+SKHv+ldzdA+M9AxNbbGPrL u+In8Q5/yS6yO9ON+PHw58B57/joTr9AzBFohAJH6R97LmTTNEO9gmF+c1pFe3/hVBKcQTsDC9Fl wsUDzDx6fogeTrjwUQeEAlBcE9X9XbWsjL6YRuIzdgZkbZu0Gvy5ef2FOvqe78NiAAU6Y/yH62jK fPu/5UUFUqpVEvIK4EOUu+vp1IqfylJy/swZggr91u9Hkmn8Pu+VOUlMgUCfstw5SQa8/PfkEhNE yfHODKo7Wcp08Pur2tYKk+hWcSW7SUXpARCDuFGqGEAUUCkfPC/Io4tIgmgRATe7nxff3Pfxzucc FQpV+gVJCARZAE9AAuAPXwBaTWNHayM9hMG6XQEFEx4qPD4Wp7E+Y5GvsaVJ1aTo19pDbY5KUYMJ umsYRlHkS+6zl69+alofk3vOfq6hLLP84fLWrFdUej2t937K+flm7bvF6Z1ceSmTjea4pc1Tr7PU XiZ7zyRUlofPrgxet575XmoQXxm8rL+8wSe6YfGx7Klt6SkqFIJjnRzqvpG/LTuX6ViGIwHc/l+f 51+npc0QAR+g8x0IvxA9Pa6ntv+Hl6a4fZG5C/iAonM/hB6yT9cdc/j848fnjiE6UU+yvcBP6xmT G+/HVvvL6/JR/uAlEH5JlEATIAGylAL5mSn8frV+0+0eVr2B5D8QHpAAy47ARETYQdyoeA8uvU1n eeNTH3G5x/EKEI6gPbDY+1h7dufTO3bt8Pd6c/Ae3s4PiAfmcDB+wGyQH4KL+CJ8E2CEXSAuCfb7 nIgiCAKFIhDQqR8h/v09hH4n3h70FKIWf1+qv7LGAGQSswD8fx/ZPzwVKA40Bg2hmyuJTLJk5Gv6 DY0fxis4K4r+zUrC3suyWMV/iqm4WGSMyVe0MrJtNlYySRIEma2s0aPG2dKrh13gpxpnF9apUGf3 P+I8YN5WaDQQszmyiV5Z34CBNJdNiFv6djOpQAXIvwfooJ5Kl4Yxjmnb8P8o5AzngTKsDbS23D3r 5P2GYg4Xk5OjSEj+sxf9kBZnAknfY4zg586PdWGE3RQMKHBV9g3kVgTFEqQFYZpXsZYb1JzBoAB4 BbKhGAf+8FR9F18xTb0kTRBVCjBiHw7zvFhEGSACKHQRziSZZhK3lD7qtBWyKQhqGU2oW1lrb0+E rPmXRp2GfVNXb2+lr6QO32WUjUx+Gs75S5nvL+K6wm03wx6r0fd5IZ++xPKXLDaNmPUO95N5te9b 3O2u9B2PkWs8pW7oz2WTS9zps81PpVJuU1ew/NLn3T084hlOuH8ss89rm273DL7u64r1FGm826zv waVbxEZFRseBEKDuB0oc5vva0jfizNUAshEAQgZxMnUdKfjnRkiCYOgQmHh5Nsa3qF8Zy7yOPMB+ DkBAVJB8trC3vmOYnvb2gLoj+qEDOJ15R2K4x23dt6c+49T1Ee9exKqUwSEhSncTjRKS0oD4O1tm ERwOGE5hz9eXl5+nHw8vLx7+nXh3iOs8jEOsAfUd/5LhD5fdT7qaH9BPv+ocCij5jsbkdAQxA9vQ L+AineWa2vdt9lW914gELGMRkiIoiISxgpIoIiIEyABjAGgMWQgEZJgAkAojEGAKIMaGkky+/fyt FneUtmrNNDGgZsSSIG0VEY3379cE1uq80jA0yUzWSNIx54fgt1AQlHcfof7lHQUBuAfyoZP7Q5NA ZPv3oD+pIveqd3EHSi8VXg8RICGg2Ef7PRHsSe3np1YAJuQeQoD+h4g4VOAD6ENgjI/OZQH4OCCR N6Pv9OOIzgB7pzWGBOZh4k7REByX93o0RUNBRQQS3oHRNVw3B1NjK15iipps6HX+v/ScFFD8CLoX 9qKF/CpsvQihyOFgIh6Eo5e47CfQ/HZ/Kr4E6APeodhkTiIdgAVOkgEPEbBEkZQQgE8EGElfc7Az SUhS0kcRP3HDEPJVwY3AJ5nqjwVf7Q7CK+B7IKGwlgIb/x/EtV+yA/gf3EPo+R7t4AYq+Y+9BQ+Q imgCFJD3Kr2FOgy16J0X1A6oKK/HtDEIDJFSSEQZMkGSKGYZIhQSyaSIBBiEpJft6tq82sqotbNa u1vK0jYyWZJTKlQEqFJEgFCJBBC965g0yldd3d13O7V04bFFa7ZubU02aU0kuldNHbrc0GJASMAP r5HJ+gMimwBA8FKQBwHQAsCwhFiNg7KLaGABeU7inUAfenhUIVSBD5RDCHzDxQJZFAjtyUHhA6WF NPdBD+wIC/qIWN4GxRBLQGAqJ4R6GA90gsFSB2BwI/yA/zuvQzbkFdKKwJIqJyBfMUVPZReJw5ig ewnyG0+jqLt2Si5/J3/TAdl/d/TuHQobA6HDiiDgspIcjcVMREUsSUTUmTLGLTJjS0trNDFJQRHg G4DASAOYnsJpFRNCmwe3ZFGxEgbvZIKlCWJ2RRzw8wO+mKgJTIDuzVrNThhVEOTcQp29fu5cmWtV bBB0OgkkpRoKCSSgpEcqGyCibipwDgMgOlF5QF/h06APB+z2Q7CipyaSIn7RWQT+F7kEooHgEMip 2+7Qlj34UXoHmALuD1FEB7cATOY8DBEH7Oeig/NX91eAD28J7R5WSGZjZVgaczUBqlhMRZbVVjEG XArAmRqJbLC1hBLlwlJWkbAlG5CRRpAqWJCWIEwwmWiKRQSTLAscpAmWLTElwMMSrVkIVZKtbGyR gYBliMcJBoNMJSEsQQhlWkyqW5AskMAjCRLXAlmGDi2twbVRIDECWNW0aJYpMCFgxJBapCxyiUIN QjLhCYEaOSgYCRgZbVsoSEEyVZkAKTTMtO7UBN5vLMq8aKvGKxygrMxgy2UzLVkCYFjCkYMXOvOu JeO8vHXiqNbmjbs2NcyUjWkkgZEgDagsDGSxSwlkBbWJjDIsjLWWjAksMSYVilpWEBzHCBCVxEyK OBWksEYmWxyxwJERY4EyAwIJmJrMU1aIyMsq/URQQ/1lU5eNBRBU2VopZpLUVJNXbWsHjgBPlVaf p7gPwPynoFP/4u5IpwoSBdYdf+A= --Boundary-00=_5mARBfai7A4iOym Content-Type: application/x-bzip2; name="objdump-2.6.9-rc1-bk17-r8169-dbg-b.patch.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="objdump-2.6.9-rc1-bk17-r8169-dbg-b.patch.bz2" QlpoOTFBWSZTWerAF4AAG4nfgH18zn//9QQAAAC////wYG3e9F99YHbCtd9VSAoq+wArlTpFLxwo AAkAlVdc+EI957Ijhh7KjWRvt3WxHWRztpfZ7cxwejqdZ6vc5X3wBfNRDMGvtvIfXIk5mN5r3cel vXbN98+ge+R3vtDfbvcPsBb1fQADuG2xU+g6d259eXWWs650s3uDxB17bQVxB73gL208yVxaLtId RDnduFKyHOZQcRnp0T27771eZl8O7qWGUcggAAACgAOgAxSXuSmBxDcC293A8Qzx47QSPIe59vur wHxBvRNvsPp8PjIPrAcXp68wCJdUMUMwMtlq+cpQSYGmiAACJImiYmp6p6g9RkZAABqegCAoqaaq PJqeoYNAIDQYIwSm0ohE0JMm0UGgaNAAAAASaSIgEIyTSam1RptT0mhp6mgeoDQESJEyApmgyaEU eIJkNAA0ZBEiEBAk0KNTRAAADTQNA3qgiHT8QpBAVogIwIAAgVICgEUIBQQhKhILAkhKSpVBGSRR gxRAKFIoqnHefNABwRGRAkAWEUFZAQVIQBJAEhFVBhFBZFRkRVJBUI9+x0sk5EAFfNLLlCw060Yu a1o0yY9EksNk2iomrdMgQjaKt2NooF7AHJyBxhkNzEeEvWmuy7EYbmWs5tsqLDWzEFE0psG2wb6F ADKZho3JxqGMiMkUFARIApBYCkJzJGsgqyAKzR0WaiAK8NjiMhZiFphhJEmkhG0lYCyRtiMKgUaI IwbrRqmQy3ckwmRVdV3DQbYCIbSJtgBuSjQBgjqwGlJWChgwEMykspMkhQwZliNhTYVAsoirV0tp d2DdXY3GDlwrQYBpaKRqFQSgmG4tgFqFMsqQcEmIZQiEyaVYjEYoCBFzAYxSUtRbao0IQ1IzTGMB EWKqyCgLZqNs0xVCkcFwWmReCEga2Lmq4bwuuKm8VGTEsQdKDkMrYg2oNhaxKFS6hGGIkKWBkwIV gGtGEZBXZQrO6LQGCBgKEWlosBJCQNj7/X+j/mNVVatGWn550f41bMVVV3tuI0RhINlKKiKfxaVn 9ZPr/H19h433zfPPazaISSYWHiWscOWcZI1rShCFRZFJZQiBMr07zcyQkO2uOM66tGFbRUer121Y TVhyXcmBURi/4PPecsOD/SkPpfIZVnQhnXqO+pJXTZdtix1J5yKOm7oicXLRlRSDbA0+dXzHSOwJ FWCNp7fCpYDSgkf+FCCshNVlYrNtqqqamnRc5Z1258jxDxxydHe0SHdR14Ee04V3L1naZISHbXGe S5BrXtKCQzoJUISoLKC2oYOKevLOsbONyHFYudLsFVdSiJDULIvMnW6NhxmhZBXenXZUoVJNImKv Oq1jRG6Gjj5ySZRCXR3UqiqqqhTaEq6KxQLWJIrb0CN2mATg21siPCULIJF75IkWbtQTk6BQgt0I xWqK1Ja71jZBIJG41WsKltldokC3ZERWCIgTKu7KQWeqK5xn54cmRQJsg9GidgkOi6xwgpNAhzyQ IvXnEz0gyag4qqKjq9casJp2FYCOVvE5kG9b5usUcE4JHWDxNCz1CN2Mwz6B4cSQhxwoysehFWnZ SC1vTMjqTVKqhEQI6xTKQWbMHOt8nqKzwJNpwgJro2QW2eIG5PNjzVVni6nHHDNazhWExIkUlQgo QikFERErFEFIJgOFmf4LEQHdvtWYok5OpUatlYdpaM0QsiLCwaLxnFXA2vjF5JIoShIy68BESnQi s0oQXIxJrNU0T10K9CUKILq7hEJQJIIJQKkoz2pzrfOcxwgkEjsSKFkrtOnqkWgUEIjCXQkqIXCo uFCxklqJmWzjOht4mgSntbbyKFIYtzhKohK0S0A8HbYtARFxiaoNBoVEJIEBUJIaVOdb5GcZOCcE jtWB7k7pwmFSErDnBOK+x5Db4g4JEVN4QpPOu14JIcFmcuyMyS0GECfCt4eLedrotSIEcoOIpIVA yBFNiCC8xSXobDBwcyAMZYVpXJZCFTWlVgiJJJNIbzm8WcEgkaluFCTeAmydTijitRe/lMVKmRRB ZWymZKJerGvD5m+p68naxsh0dD/1VVT/8WKlSeM5hIkGIgqhSpVzAypW2cjZBI1KYthE2vxR96xD g1i4FdOnw5BI0zW8i7Z4NYkiinTocRRgm9TaKKb2bj26ZmZgoouGZjWtbxq88zTOenG+OEuavE2x Ypw0Ygp3duCcEgaBfaQr2MkZbOiCSTWBJAXNa4OXnjacThVVV5zico3Hd444nDFksM0UrEnBOCcG nAM4pQFLwhikUUQXeUAQkkkkkkklpNOil0mIEEEiu51OQRpdYGeVnglnGhUVFE0XueUmjekcdGpF YHZckhRFMwYIxVQlqXzqs4ycEgkbneCcXV71e5lnLMyqERFRAXapra56rOLiTnCHLw7rJHnetE15 y0SRURl5ktvhpLO/u1zLHQiRI7lp1rRdTWpHRNEVYovTaO09bqsiKkkkQkISDxKXbJIgUkkpBO97 zfGDiJNDMk8XUIG9jzOHQmiel7dSSSSSKySSScc8CQ1tdqqqqqqqpFJis1zLN9ZzwXSycM548eXP lwmRlbUEuiqhJcxKC7xkhoqkmYxJwSJYMriGMGLcRxg25YcabCZ2XZphv0UH00KpkOxYqi01SKqA NKVF+G0pVeF/j3+JszogCP4F0rUA8I5RTBEE/GIZEMhkNf8hCz/KhYHRBYcd55DIo/+EUu2+rOGT HVWiiwUUdpbS9XMtpmBYqPQpdIopXXnyZNoKbBSKCkGJBZIcWBCQITFSCqj9MKqxJGRRFBHeUIcI K2oqgZv9IHIgbEihKkEQjEAKMKkPsAT6YoT8pLEWCqQERYoKSKApCpCiB/mACJjD+Bff+zeGyJGO lVVVVVX/0OCJDhBGqaVVRVVabTMyZFUaLZNZaQ1Y6oYlxd7NaYVItS0NKqqqqqqqq71SjjgukhRj QYoUIoS99zJYcBxloxBtKSsbVAKcJOErJDboQoDDbjNoYmCyOMW41EFNWFDUAQgYw3kkoBk3R2N0 pBgbZsE0hsdgJLEjIwm1ZBjDJA1YAWEEgSbt9bXDJWBVQMQxg2wBUYskwYSUUYiIiKKiKIqMgIyR YxAWDiEpBQBVgKBiTEMwtBmMiiyKGK50EA5wQ/OVBVZCQFCRUygjUUCRFWoKVBEkFkEWRqCkqkAU IQWACkhBLYEKwgCgAoQBQlQUhWQFADGEqQkMSSFZIBWEhUkCLIDCqxmCVQrWtYqtrVtt6khorD+q BRURUl3cW2USMQVVG0JRWKKHCGZCxLbERUVVtpppGjK298oixdslQiJCGmSQCiAQWKRYpFBQWSAC JJWECoBEQFaiCVFZAUkUZFLgNRQkQLgFQEkUQPaKI8jrHuleVNcy8CYkiMgsWLEERRUiiyQRYRgR kRLvXLDkRHrnn6fLJRbiDmhV88BRVExljEEGRCMIhEIWyDYNL2Ga4xnppgM5uHz9u1VUJJJPOEhZ Ksz7h3hCp6SB7ZfNL7QZNfnN+XpeeVGe5lMLw+9913tVgg6pjKEbcQhkCVEoShwJ8O3wa6m+k6ch 16NMw4b1owRhtRgKuMAEgAWLGZBrWruLCNTEJA/fvORvDY2NrsbrbzOEcimEqS7jdDGBTBsEVOQM gJw3XRs+OTjh42Ds1ovrjGwBy7vR/XgEsPfrwlGNUuANGk9Hn10ecYPDEu858hrbpyuiTw00HHGr b455ON6JIc62A6SsL58breeir9c2V6vXLuONdxC3NuDXeSFvjByWTniTBuwFjDcoXbxCrTDtzxt6 Txjjr6sswk754KotdhJ0OmxWQnam8QGevKjbTRTvJ3Xh2c3I0jp3ed9jcTtp9MbrQ4ivv3nbnvL7 h5K72ru01m3ihrW8Fe+yGM7p+5zutdsDLYEBtiMjqDCJlR6OTnnng378oHpXoTyB6QOVdCegOwee 558+QMhzyVmAJkcaotQOyvRlch0Pk9C0IolbiKG6huiRTyoeETKkFTD7PrOkC7ursoq4tUlRlEbb qBUVMkkzBwYs/3gUuEgaRuTKFsGZaMKhYIWwlBGIamJA0EIVdXEClKRYVJT7hogT+2AMZIkghAYo RiJAMxx0KaikSDTF+IqOkFIxVTZAEhyhQydpiIq5RVYCxSMFUBVVVhqycMxhCsgsIsgoVkEVFBQB ZFihEUVFSSEnMiSBWA6sqELBKYiSCXFPVIhhYgMlyJFfzYj3CHQkIieUFGRKishCE8Q7rV6GRSo4 iBlES4oVfC8jr17tmfU2IVAkBcxUkQE2xoloo7ZKBA2Iv8yC/y457799aP5s57ObopCon85jhA9P OeQ0IHZE1BHYKVpF8w1EN4mWeCW8nkvuAbw0lURiQ5EpqF16vEvxQ7c0obQTe77Ip0I1CYu7G0Xb ANjJO/ibOE1ygSpDbAm2AGRkTZQKIVICk8iQ3HrDz2MjEOz4IglpAKJwlEigDHtMuEEgjUlYdd8Z 2785DlVSOZNZ88UiYGAyhATRCgFu+r15B3eQ06bRz1bC0q7bSWA8xQDUCyG493ueRMh28PK2+p5O w89GPSDybGMhEcnAcdlWS6AIgEPjAxgZAPsvAlLeWx1Mn06mccAOMdkjOPFtROtjcnJgKrzb0x6C eu66xllpkOEMEkWcwgzTnjYxFJtXHbVm2qAYgIlGi2AVZLOmcYnbBQnMWNZvAMtdDDL3kzEp5KnY iQadCqEHqJG0eVA5gZYSIIIOCC11IeGAcJIzpry4LoNq+18vXN5sPBuXtdB26yIBJ4U6cbAEhDiR OCLTgHcY6JrNwL8NtOFzDjbD4xr0Z30nmOXiZhZHeAPc8l0r3JZ12dmIF6ONhOxeKAzsZvmu7OoG ZOTtOUQlnHJadBX7vAUwPfBTij5UxsBBpRscD/Dt0CAgghShJChCfmOe9jwhtd+MGm6YQQcEDgfL SWcBUD4hpA7Kkvt1HVjk1IAIEmuEKk+3xBRFgIqDIIfMSUibj0RBzl1bhIKDdrjXHrl6NUAgE7MR xckgDCBl/6HGJHIeZxryS6ChYIR8bXChzgErkj8JzG+wG+2Ot+nc2DNwu0rxjfC4UO4JcnsTxcOy bymngE5KHe71NHgZQbHzhp2nAUGMmiYxopwYdPZdyP48b7dnvbZk8cqHUCGNNKO45YkKOEfJ9ob5 CgHBwpnwTDAQAQQT0kCpBGDIiggMIDIggMBQFAUEGMYERjFjGMgpDaFGEQZIiAoIwWGuHk3rh6Oj huYUYCesANwQ1yJhMWQpCGFCXoJ2fRpGIB6G0vn59GXIVK5LIJMcI2e7xhKIo4IHKxCduBQBjLtk vgYHiIOG2fLJ+7CMERe51LtB6vxZUrN60yigOQIwxdbuUigtSTkEbEaIKuFC8BHFAE7TDwCMkGUA ZOMGX5nEiPg5VdeomZchkyPEMDSo5Qq3WjQaSa1TEVykqopcaYqshgRiRFng3B2Cz04T5AK1iSJD nDFQqLGDXUwMTEADVAKtBBEcDhwXCYqbArgz8e0Hg4iM5EYG4DOO8f69K1eFIgbPR24AKPe5N+KW mKCaxhc5vOMa6QJzo16lYyrVShKxKA5634K4Kx2UUaQNg4SMZKVzBMQDFZ4I6uzYkEjGwqBgm8Ov GaNGtRYoQSSMZTKxcIkpjYdL4QCAQcEo6yO0eNZYqkPzBsfB8erCjumUHk9bYeGBEjGEZ4p0ceKO ODR4Cue+gsjh8cccDNsZ0FQJxTOMPgICN2UwDMiXWOSEUhp+XrCM05HEJo4wGLEAqtT8iRhDqW6M NyW8+ox1WLOedjYyba7NyjOKuohILIBj27bGSErmsMDaUx9aCbe6nOCxO/iEDY0CA5GL5rAC58uN Yyqq6q7uQ9TIYMWtxisM8KElxN1gMwOC6UUNqm89qea0QTtDjhgaUZ7aopyavedWkmEGCxFMtENT ZulCnHd26wpVycBBrkEjJgZhmCBdFkVIW+LCmBACxzltKwWxbqCZpaW4ka75wJtEkQdpmubV2QYo IsUZEZho2zDGE0i0wTrmmbQ0k3bJvVOvEvDpiymqY517iYHDqMDfBrIojIIILrmmDxz5Ke185rdE BDJS2C5DzADugw7nAv47tiBCMPdSPkdaJxW2RVQJ/Ci+JKgDxu1UDEKKsNo8+90wUbEXL4G8M1sk kIKP3SY8cMQ69r6cwMEETx+S4CXyURNm+aDdRdXW75oZE5wQdhunTZeI51sU7mSzOFLy4rDI7pyU HSKhMZSl+ZwmB7EWIBSNhmNXqZirDIIBBSFMEtTJUPQpMgXwFQje1yRJC72gM8fpCCDQZhOU11lr qYxykABd+MnNwOPOTa3g4G9omUxRA2rhmx7pTAM2tgh+jpYMTj20AC8OvY9hMRpHyRjatwORVMbV o9GCwtkOjxRe2rvVFfKuG/1oFuZiu4h3Q5SAAGCesaqoWcMg65ApQmBZrHyA2gtTjgN4pgcCBuoE 4nzTxsmcRCu+KrenJsG3GNa2LTY2MhdFEVDO2nITivPG+zQPU6DkOrYE7HGJrCqRGRZFAYEgSQYs fUTVF2JmqMRV2DBvnHvjrLoA1gkQybvIxCYeKkTMZrvs73gx4U+hvetlWlnu7Q4znWwRDjmMVVBg dAJh3CDcxk5b3GJGHPL37OZxnZdaodnsIHdHUfI8XOuuz86LwOaChQMCSBesg+TONmwCN6GLl3IM o+bDVyS22QdA2+D09ZvQdT0KCZh257c8j4IhuXhrTy4CwBRZYuNSEa1FQUFC40LMAgMcWhQa7Nt9 0LvewS/5+Cw4xz8vautjDgs6vnhphxtRfHk0YXHjwfOsjzS3X1xlDxvwN6buwUycODtNLtOZ3VLD 0AK+LDcCcurAuRh4uY4NIZwBQw48YYYZduGSJzmMSGCAYAHt2GHL2VS6PJ48Zjys0usRz3RUaeXd y8ePMYafGCkU2nCDnNM0B9ka3qFacAdpBv17QNF6b+Jy46G7PVy2cMsZH6NP6p/AR+0APJAGCQIf 40LEgjIipIVFltCUikSVoqEFgwqUkYMVECshYKJFittLSoKMGIWhWMSMViogAjWFaMlgyNsooIka WsUSMGIyRE/7SFViqLCJLKSygWDWLKW0qErCRSChFgKSQC2CxVYxUVVRVYwWCKikRFVUYIKxZEZi KEMWRJjRVCRSKKqioViKCYhgiRblCv9aWywVlMgyBiMgVYKMA05lhRhFGKsBixGDBgqskiKsxirB gwYrG4YDI4TIpAqEyQUBhkEpWFtqWqqrFXFjjFiKjFbhlpkzMoSGSYCslZZba221Vtqq2tyAkmZJ VVgkKq222rbbbS4QSWRMbAwzIZJbZEGACxQUkDAgZBMTCAoMIwMy5kqqzBYqsGCqqqqoMxixxirB mKqq3AMywuOYDMzKFixBgsiwYMGKqiyIqwYwWRxgqwWSSUABqIJaDaNSW1RaqBSoFCNkWwRsFokJ C5IttiMVGAjSkgUJAshACihXD+Z9Hl9+H76zRmXRnGtGIjFg40HXzkwVijul43cZTZmTX6JZkdt4 rmdb996RDjeLhyvP46aBN3UbvCmSaz7GaGfotsVVVXvdnNtTnm5qaMOAwUVBERCMeyq5rWGUsuss N6HO/SXYkU5vWk0xMkHmUqDnjp0JryGGGZTphrLguGLBEixZBYEohX6s1no/7UuwqCWeIoyhAil1 CTk+ZdCZerhc18r89fP4a8udj1DtvPd56DS6k9zH1K5JKqxDdCytxSmYrTRlETXPvx6318d/Ht37 X9zm/Zzf3P4Fef4AqEheLaoxJJSXXUQ7u7pBgkkkkJEbeZ1UzMzMzMzMzK0aBQpVIR973443EVFi mMruqUZBERW21oja775pFZulE4ZKf7+n+EP7xnFlT/Y0YqFgyaUVA0mOhgzEORDQOh3lwiKzXwZ1 WaUqKuk+4qBkSsx04KWpRJBzNmFkXFFCN74TWDYi2E4VWFqQqBUkrIVgRZBN8jbC4Z0mDm89nMez opiJkLhLRm1yW3q6zqavDSozMZkjJCYhDjpLqqb1lypVwd3S6tOFyiNtFF2lYoKiZc3S6Sw63Nse N6rYzW2uCkdRAlEVjFEblxiOm21gq4xSjDUJVmMyi1Go5Lq3hYHXBxQNBDibscNZA+GZ9H1fnfO/ XixWYRPstNOGirmU0zSRI5W3DJRM/uThx0orEWVktapaIJ5l/1jDOifw50cc8vHGtjo0c60VOBAd BCB1EKgZqmXcKix//kXQaFQWrksEEuruQ4qAkGDiHKJDIyEIHZcG3Dgugd9w43se7qZZl25dY7uN mQtCjVr+j3+vtPOhU+P1JrFjrPjt3zquTicPz63x7Y4ScQSIiIyeLAeuHV7b9ONoXu1NpQVF1SsO daw06ZdNEayqih+KSwUGCdfxejrnmnbXtc/y1SK882HhIaGCKuP9LST4tAQasqkpjxuE/lH75dgp H/Ij+aUi8IPvz965I8uujIkmhDBlQTC6k8QV372q1oCUZ7ENyVxiar+R2FwQ4lC4bg37HcpKTG8V I8UPDQIeMqz9ifnz8cHxxeLbuz6cM16+tbaWqabBxyHbwpIyPn9SVvGHnz7+TS5Dsy9rKPkcPVbS BIDvjMwJ3DjvxnB1CR+/5UYMOGHeProxr1WU4DF22WgVEwiUEin/FhHb9utt8Nqx9W8EQxhERSWa TcDrxxj9kzA30+MD7Dw9VZyJWu2oHvqmDp2JOmXonfj31rEXLQIm8/kmjnpaoiDMXimMUMy5GNqn LUcsqc5RJIb22BuC52trONXPaG9xNk7kCLoU+atMcy+HSnULK8bpy9t7y7SutHaOYa26eNUMXbuF 6cXZwQ2cPFqu0qi6vISm1hswd7p5KZzXWTNTd+ffVZ0daSASGXAYIygzlYRMYGcMzMzhZKQ7H+nd hcCMhERIAog+lYh9G44qpCdP5YfuDwMG/i2eV0bG+gn7JZcurXtlMJgZeV3qBlo2g8v+6O9vkmh+ DF3s9Xy9GdONzHeqc7dl3ansm8v5cjivVCJMnqxWQs4PKQLyPttQlSjvyuznWnyEE+oILsgCflP0 DttggN+VFCA6W8s7GCFBhU/ceF20sA4YNqnZ8WnVRpSMEYDCBrhn8GI6qMD9fZAV2lMLY+b6+2sW fw9FUOGHXODKvbx/QP5H8j3+JXzriIIHSC+MUHmRLj4z0j4RTujsgL5iA7+6QCyAiTG0vECoiLj3 yWAJsGpEgyAwHKlrepeOOMTfe4Ju8DuLW4toU5+39xvEwfkca7HGd829sznea6rrlLM78VgTbNS/ zXMrashogNO21qIfQih2oqHYRRDPFBYRBUqDxAADeZmd9WKD1FEdBFE2OqADzTRnDTIr1ixNc8aQ 1G+fONt9AMJ4jIgDsG7zt4NtBU2YAGorzGiG90w643weouS86h3lyHpAuC3ZMTQetGjDxNou0eiN oYoSKCIgnrzo4FdCFEszhEDw5XZAh8I2GUMIrFGABC0CxeAL8ASNIigokXDWhGoMa4TNKaEwGSYw ChkJ2VJ3gJB1KQsl7JW4dSEk1XEdaBv5vo36gHCaG8Lip4mBvThvN1sVgLoOAQNTw4s9THrIZQQX QQuSmd5cCCOBryZLDtfkIuFxQOIWjMsQqDva2JWVF6vM3mrWJUorrtcfHMRzvm5j6J2hoho5XqD3 8rdkmGUYXGhqNxJCPGG2z6p3zsoafDhnwjwOCKKCMUUUe9LePe60OmVjCxZTGIm0vjzd6T3NWF2n bnnuc9F4sOvIcLOqHAmxcIRRUdDisLukxm03hmSLtMyyF0U0k6apPhDhhbTEeLWSKbQpIB7QIQPw CxBUFVBFBWKMUFYyKKKRUARBSSSAQJCDCMEgqoxIEgqgSMQIgjGChIjIAyISLIgb865fHfv36QGd mOFOQudUVyX7p9spu0kAzvyHHw1fG86+hO9gkeb56/TmBkHfXkSR0vfl8bnpXds91wWuCO4xjAH6 DSAbDB8E+Nq1zqLMQ4ED3FCeKbxGH1xnvOdILtAtuEPz9Xrzn35Kcw8nAIllkgefHy+K6671reE4 VPBPfzKZjIV89ca5zo2IG48RXz6yZqFQncxWOscTvYrdCUEjNe9vm562NtxQDXHzhow5IaRQChqQ xBGpRsom+lp03N+I2KEgXRBoEhApJ8nok7+879rIk8jL1E6v3zkQv37VsnfAsypZ9zTZzSNvmXuL ftSpln2ueL52V0bicjz19fj+zrPmzv4sV89JM/PfNtcdKvttT69XjLfJ880NcbVo3tNv3l9tcu8f xFTG9Qt1AtHRtO7WdXt8t1026JXR766ty9M2dR0+9vhjj02oDjvBHUrAbnsBEzIrveYmt9AjYyKj HhzBtDZrCejn0YHxCY1UVRuaBsYAx5FwSnutmq3qzwypOsABCFUEm1sw0YStad3qSSRUAcKhgb23 Wllq0GvfnUOYHQp4+PXrJqMqZuZ572rja81tCcA+lYRITowhUFFVEEYKRFYzWmT3897dSdded+J+ j9MYHf9oCtQEKsCBEmQjgSxIf1biipchlsKaZkMhdFJRiJeDBdUtF0twKxhGkcKmBblsqIOZZhaR lszWS6gRKChEhSTRiONKWpaFWMixyZRUZSBkkrFg26zICTWUCgxYjMNSW01paRABmgyI4YTAoQ0Y DMBhZTWQmOjHQDXAkTFEhQhqIkMxaCuMuGkXQZGmkTIZDI0UJRI6szBJmpg4TUUzBQyRwLGGgQ0Z NQrpJmpFXSFiMuREBBUSGhiKJ/WlRIYE0ECpDYUY6TDCWjqLkghWxQsySixjEKlCn+ndFmxJo4op bRRR4yMXCbQo7ppQrNaVlEuEW46NBrVKK6pXC45GlU0aQutCYhXJoujCWMFBMyiGSiCiilMkpG2y yYhVEQMfECXKCmVHfRkNpX/UfhluYERGaIB9TEmCOYsm+86hr7kilUW25IAj9+KW4pCZiLrvbJc2 8VpTKgcG7ZZQETByFwkYEkIeFlEwH6P1q1zlOt3AkX1f8e+/tC0Pk1BzF6lzecTE6g4h+RQN+zh3 3m8OO50CQ+E+ERD8sJ9cJ+csxM79Na21FDySwKBi96gq9kDwAUJRxrXMbMuMK+r/M2sTskfFVxHF b3/pYmsZtMhotu5WMlpImE0zNy4m7QLrWG1YbYf9UPHbX11+3x9dJ3TuxTxzmeY1NWys7Wk0EA0A cEpICMgpAUIU+/rWz35s6ITruzQgsKapJcQNRzmgxD7P1t84/f42DiAaiTijyL1JD1mNV2k2g5a7 JCZD8e/1qEDrOeY0KT3HiLzGR5heqCRdYo8TWqZD35/y+/z79++evrXR34p9QLh8ACG+KDECsIuR D2hRmENFm4ZupeHNSwFR02ZVDTs1vbUqYukKg/vXjr51tl4frgOc0dkagaqi1GaheSgqMhgUwB+9 UeMCSLrRLpzNtUZvNsiXG4GYFxl4scfWe743/e+9ziOsUFzkSJcHPVLzqj4gomQ+j91u5duaMRMR 3kumqqs0GYAfrPNuon5hrctUVLDOmesb2iLFBeqpUEBSliji8D6irB5JSJAjVIbQcvmh1BmaKppq Aag96++P3jx6/H65NfqvHR58J6i5iHqISLCGVR/cyed6iA8jxJecmE46UOHgR4sxk9xuWaQUHkHD 19Pb4zz58cj2QkA7tpmjw5dILuhamQx+AbMxme0t1B0xJBo2oNazaVopCMQHEOLXnb6bx/z35OmF UFEQYIFyknKh353Oq+u9+M0dXgt1fGbofHc5K8u5F3NCk4XfCjVDxhls/uuai15fYhKht7R+z7Kr DY89+03G4aUeucn24pRrq92XLB8DGj4iGJWgsYiFYnoT0A/PFI8KEjswvtxkNIG03apU2ysPpIZw Xz289Ptzwde1lZNslSKKUOtm03lhU06QzdAji4gsqOOc+bWnuLyRKFEobEEkoxuQLkOQCwxZC6xn NpkiyKGfVKZ1TKpcwBmVB2WqP5G+cNREqcFEYmWGBJIDyA4MiPVtC3eEDaZbmZk1Em0M9UmkNobf n48G/Xn5enQA8dqcooeEMad/izmaU2ihUESBF6gOBD2V7Oc4AkB5R5Hb8nCu79wdXvcBUTj1RI49 UJld7bE1rVgYiXExZWJAq9QxAJT2G9TX46ua3rUNC7nBiLsqMwUKqgrBUIB69wKCofBfVZlfhiWz Xunr5ps4XlhyHLA2kUJseZnrE5jv09jCsWUMJA+1X5cK4gPsauv1kWuBv9eB+Z7GxpE5I/Y9ovFq 22QPykCkj6RZAKxYqwkgQf39oJJCU/no9dOXY5iAfU1Xi+ISB9tVtYbRe/zixNRQ/cGp7+qeJJqc b4sIpQNz4M5rX3ZfxvmcXAEyguUGCEJAYhSg9H2abxCiFMTUMyyCFwfkTaLpiYmdU3dfj9d96xxf GyHEMReIXLlH4mWzeNzMHFEWCoHVVIFERi4vVWKKUvLt/cXc31u9BcixMQz2sDT0TT6TjdPjTGWB rdAzdUORmss2g5SVmkhiT3TW6Xrv59ejea4gYu0qAXVDvAu8WcxLxzY4BRDZi25NnPGN5uAwOJVM 4mbma02Ya3fb19L33vXt8HGO1xU0JJbA2hBDOeqvCqwU7pf58zjAkKClb/HqGWEOvWwksIhqaNOW tmfzdmStmZlGETL2cqPDEkMQpF9WtvLd+ZmKEVKnCAAdwAiODiVD0VlZWbD+N1bZ5KhIjRUMhbwX QQETBVMQoZva2bdKvvSEwtFKhmm9/vGrNQ60LZ746mW4bQfLN4/B9tvSPbnXJ9ejD1eeVLeviJw8 Op1vSrOupPEh9rRfa5le81oxu+1pNNnkedqQvttbzMe9MitK2qquZt+65601Qykq711ORqO+01gl SOvtMiiNEOvN0rDg4BriE3VVIUiUrYnGMQSpVVUz6rg4KVNVjblcXvDQn21bYQHRZxVSpG7Lu618 jjHktvvO7MrAAeFEDOcWDKxdXFVrbfKnsGpWypxFVi4FmVgq6bt5XvhZZ5ru7IIYXRRgWVQJLeN1 rVoXlLlFY7UIgTSf0IAmCljRV8FmAjDfcsPmU22yiWKm6IcRxZrvEqWerM+5jcOAcCGKSQEdAa3Q walBVHBlDNGCeXnjNpwdmcZ6ztJpgUZICgiiSVWHVJAq+eacySQD15K5+Hg7RoIKRIfYIfjPzhYg cFQJTACEEAEiS1CszGjmO6SnO1QvL+X59UGHjy4K21fUPj6IQoiMGMntuu4OazOJLSMpuBL3LMRZ xdEqxMpd22/G7XY3cVvcFSThGcGAUuKkFe5bjTgIPVQpSSJWY+I58FCqRg6xLm/eO3QTFlscAZbI hBmDLArTmb+0l547W63Eblso5ERFWb3uzBnSlne4A08mlaCBU2QJkdHYog9MJAyVFXrQzLylz5Co Sk6lSVuiInne2BHabRSrbPWHb2+vb66nXqqnRO53jQ51izbXe+wfjMVdJgVEoZy7p10ss1p5k47K +W089hqf3Iw/IHr92r12tLnV8Tfteql15N6UrnrV2+z3PmeN5Stp2OO05Gu3t29QjXEhOx32fbzf FeOCVqPZi35nbvfVjNo2OdthxYj795CFMn110z6JTIMhROgFChD0e4vBC2tmmcdy7M6VK3RBvIyg EHmBVQSa10ZPsLeUnQwKBBYWqwCP9MAxAU+71vccRzpWi/vcL7wSyYkKdKvBAwRhAvUqwAZfVhdu Py5cmHi0saWAFkDPcqgKVVdLrWs+s7e5je1uRkYUEhni6SIQJZiygyWFVJC2nG4jsCwyWzDLPCXj 0+gnv5NbDk45A08bcQOJ7QIHDHeO8CjV1eN7tZgyXOL0e29OIHPcLB5bF0yE3JEJgGWHRPZ3ugnQ LRBDhlFMjAnyhjAYMWLAWQNkECjGKMUkOnFhjwmaREDyDOdlZKwr4Tz0zJiTIMPlNpBdgIaGELDZ kMnAhNYW0sO6ScuHA0IxlpSVO3IUmy8KzXD3gUs4jUnfdxBRQhulm6nnAmtWRTjDLgQgQ6poJzjY B346MGz5z58+LNwg8VsoCeshxxkHUgyuQM1RU7Cny1U4Us4CoQR04pvd0Corq18LYfli4fxEhxS1 JkYwJUogU/lUP3BnfBww8uPYbkIKcDtkGnzbWmuec17Xr9vsdp9d+nPmeVkFYIQIsFUFiqIhAVGT 7m9bHkc7/aHfltYdQVpUrcAXGxyAhABSqu5VrweaJFXqtEADBmRQp9Pzfk8iV7/WcILwsFOEGiAU KIgAIKxMnUI4zNebu5Pc+fdfPnLtN6jnpHuRYgxCC94z8rUuUzaHz57M/NttqjiHIJ6koFoiMAdy YucHHiyvqqjTp+TWfRZnFcAAe+eNoeRjJVX1vJQy63bMKlKGtkQeAAkghEKEIgIxIADMnUkA1nUg eOvnRj3O+dueZnmBqlihQAARRwcSSQYcrV7crCrwix75PFIb3zN/nYakDudb7dc/E65tX7Xzr7vN MlHep4KjkIwLxO6B4bHRPuTrKr+H3tOQs6z4svIjR3K8626qYplbPLhb89sd9f5vOu8njImd62na cu/GMe1rK4lWbRSERMXQa6g2RFB0FHLKceQMttDerOS1hqX3Cfivmfu/q/rx988hF6iQVHnpcPMh IXq623k5u7onDFg1iEAxgInjBA4kkkE67x+cR8GdNdDUkAm4AndnEA068rjHmMSxjNsB6kGPeClJ eeRnWFrytAEEIg1Y5AgCDJEIViQC+iVfQgX7KmXb7zzPcrK1bqrDBCPl2zRyb+x3dbSKRHshYiqK yBQ7nxmR0qGVmRQhDEFZgsGYM4hHFN4dWbhdxw+16i99evQSHu90J4SHszaBbUws0kFyNDNSVDyX ZsOfXsHO3mQ+VSOCX7yB+98eLJOEQ5CIdCEiHjVlOVxk+JWRqpQkWDes4n2EbT1mMqqJRcwPFZ0I ynrkuz8pp8gy3JwNIEBHGcady/dtQdvFEoahAiqSda5vJhu0XX9sI1FkROIgBR7OKEgWjXL96fge UvUSBAsgS6sDyl8cj73qNt7zsAOO+EB4TXyeU/G5X38PPRjd9wAzEUXgfAkTv5bEOUznL9jAUXOs kKyEnNZHe73pUZxnv2L8ufH51oSUSluP1npgN1tO239PBnf46Qfvue2ml7nfM8mm1Pkm9668NVcf fo4/WjhjPdc48apw2V1SFcrvRHBmfZ9lmuPQutw+fZzeTzZYYrC8jlRhVMBDMb1rkRjaGiS7FM4r aOqfKu9QICoJFtcrY2tznK9BTwIgEZuFw8ja9gsHGzrSkIkhJoiaRACoDEAoa0xWta812mCLEEi4 QZVGJBI8r7jDYxnNe2tcIPQrEEFPH998aHNa1vPz7/HH33XsuVGIKJ0yceT7pK9hCo4um8Yzv1t3 4E4Tb74QUSg1B5I/MTrPr23zRtVBynh5Opcd9K884u+uGfbocmqgWWKAMIALHDQ6D9GDrAfgCPgM 2Ai9rPBaJ5MlGjvOMcmwzAg9VA7qqzeudbm4V3PmZNTVjz9gRBrGRdMgWhqeUKQIYIiELX1gF9FW 8yCbuN5uJxnOl3eyWEjvrmdJVB72E/JQiZ5okw4PIJBmoF6Qjv31/dWtUkAm4DRyyBPXweQpQ9yJ XraVd0of+10REUOQJ0vY+4q7wx33GJrQRJsiRDN96l2X7z988c7+pxOj7QUSQWQdQQaM4yShPwqR oz9ntltryokKEEk2IFmUg/OS+ev8fqOLzuCKzugTsBdPEY1ticwTHcun2ut7i6mxXQPJWJir2xXr 5eIaIqKmiRkxxsfN/Oce8d/L1veZ78ss51tURnDDDD8TLzCxjDV3NlrVktGzPL1lKUz+yWd9yntc rPOo8/B1X9ldW5lFKR84m89g7MeejLyV9ddk9dM7znkKE4nJ5m2vT6WeP5yuVw7Ardmy0Zs3U+du Tzm87vbEMw8oKk3CQYMc62/nVhm6/F8uIWF0REo4CTiTjFuT7O3ZpQE2AuzAy4roxtRqOmI0Av8c 48Kmt25azq2L+Wry17LhLhWJ35ptQv3zpfnffG2mQLEYiMlCfAiCqJpDrbrvx1KuNzX3A+M4OC8W nmPJCe7A5NPKmaM+BRfjUkgaYoTKaOD1wWU+OA5yhlCbRkFkZKzMbm/juzk49E9b569HTiq312a6 hCAuMm3DRI3l4Q+EJt5rzPoRs+XEXiwIDiLIQHELgTmPX94CZ1otu1hJBJQTSEUc4Fs6xXsuYNKG qJB09wgX5YSou+ddcShsGhPx6asne/h47/O203OBUiDEG+eTNyHjzz+Id4zr8nzqoLHAyUAQlFwq IwYBxJALom8/KmOpBJ0Ka9g8kmJdK9fGs/2YkSlUsSCjXIcASh1We7WbnskoaBKixBK+P0574Ekk kypXeK0sO8llfdJjGQgVQCenPZd9rbsbTQVLq5pt466HIWWWOk5o7U8vMXtfT4XpaJK2pgyhivxv HaMp5m/JiNfBLSyDpX0me/Kfi6nozmOVFZ02viTWI4p6fLPmpZeA0c1r3ub01BvWX7ac2Jum5Wvz vTQl75A38+dgk9cHtBfhYEvSLaQEruyox+gIhkvBWkFiMkKGKbniGab9tulDUsiqBZAByuh69Ier fVMW7bnYay/NfL5I2E2DsOcSY2ErWtx0hSqHipVwIYalGlGaMLhZUSgBI8KPR7wUJHmtC8vnvxj1 6110xk/oh78YJCMiyER4tQsW1LQvswIXN/sdZMVGg5o1ilSCUBtk0ZnPwhuqXpxoHxH1Dtz1DtD6 e1lztWw4zncdyZNR52vdwaxPz1HjcwU4YJZ9G15NHN7FO0+cUZUU+cHd1633AtczXpK4JPPCCeQP h6HnbJnUyiDDSJBLKmAyAD0YsYZKV5z66Maxtq9NJCOQhHiueOy01DSAsiqAdkBCrhRvRsY9eevO x6u516ePOEh571DwkIyZIKhKKWep5zq27KOu8Y2Xr1X4v3tBuBPh+VBBgeylSrXfiaIuX43yzCJr FHgIEYB2AJTHwohZBvUtiLGVs7m72uZt1RS+QWTjnR467IqwUixRR35zPFuteda1bMSkjQMqLQUR iT+E+iJjv0++TfONtYwUPD5aEhAh5EERCCCQcTyKCQLDBDiQwXhdTSjKzyEPKPA5mplm954aJIEz ET9iB0gfHAEkg5o07cda+I9sfe4eCCSHpR+PhiDBRZGKNDH7f3SQkhc79eq35f1+Z+7FWKZCBQ2g w094MPPPt7AXv9pcxCtgLkWIwCIyDIgoEGCRG4r0/HvcfOvf18+udugDxDwMHGCSGs+eKO9a2Vdx AgMgQYKy7jJ3n3+PV5PvzW/IN3ZJ59XtzLfndRpYAOTiojOoQo8j2UoRXOXUAHQCfpUeEsHgnvKW LsV5v2GeezAucgbKIAShJQkkFEUFEZICICIqqHhJQRFFggsBijEEWCiRRBSEjGCUCIgc4km8s9lW 2dUpJ83js9mboQ3WyvuRasaxK/HekTO0rdkxuE4g/V1E13Yjc/kadnM+3XsqeBn53mmQZGjzyXxu pfOWqJy5GqnU+p+96k0SuuaEZy3AuuGtw/FpZHYhVuFiZdD0u3VteO5SErl6tZ40cxzkxoZxsPeh kvKsiffnfoQEU6+OvW057mtvfjnHR9eBIRkAiMYQUiSAqRZAikBESIRBWMQWQWBBJRET1g4knNJ1 V077YSJQkgggyzGc+xV1Poeiqqr+nqAezILJAdTSj0LU+u7UoroeefHzqgVSHyy1GXZ8+bT4lHk7 RBYBmJdjt/C++FfqzUMN94OBKwJ9xZhcMJRDIh4ocBBx7E6odvveNfOgbLbBLHKCy6KeXThqqNkH iI6GIWZpXUZAu6cMkRiKRwd47+jzqr8cOPUqPMkDhSGIXHqCSKURN44hIZiGYBjVN5oELgdxUzEJ AIRUnNFwB4j4gHmImYFp042mfAgRAPAMjGVwemQQupBsV50UgexCUANTYKqHW9Trxz7y4Zkx0S7t ZZ1lKCmQqErlQIDOvrG4Q2gbqRKnU715+uzM+6N4cAHsu2V3Zvil3pGSKGLOvvfKX1ZKChsnZPYO vBQ+cBuDdzWsKUqAPngRzgYT5l+N3fMPrRQTs9FJWHNxdESItiGKme27GGmhby8F7TNo3qIxnMRj F9vHuq6BrHHPJ3qcbyXxTCWy8Hu7mjzo72TD85c3XVyw34NnclE4rx57vw32lXPd86jjStrlbDLU 53KpqsiBficsKt3yxA5eohe5uMPRECIg5XYKZrbjsDmMVzAVIIIvTHBelKa3DtrJ6iDqOZxRCbTt azM8CBHwJREDqMHB5JGn9bda1z5KkjZFUHvnPbWtEK7N49FxaVwnkXOJLw1/bx1nNH35HAvoSO47 LeuzaDznb34ltlhQ6yFfcWN9uo/ssUF60ZzOtcO4/szoZ5p9Fs+7Ht98q8znWcwKwbuFTvewzu/u 14o0Lwb7dpTqiPZXN8akhpfmjvJWzdNm81CNq/aGXnoS6Q962yxR4fMc7pNW3swmb9vmtbvrFZpd h9H3cj3trnfXTL56VY1MeDVci/cg5TmfWZS1jl8oH3WrufbKiFTa+49wxdOaXbZ7O89WEgPcaerh bx0kNpfHOXXpWidhVIA0Wy0Po6dNvuFiZ1lrPNp17ic1J2dWzu5syq8n3Znwpn0079Dzbik9q65P m5zOouUXnZOqWFt0M9re4sTctSjedPI9DSHV5zaku1idpHCMnZyndez5VlYj2qRWYX2L7vvFM0g8 M8txZ5yvb1qaVc55PduufbBfS9hBDTq49nkayH1K42QxGFPSLI4cErl56M94H477rt8Wa3T1Ofay k32978q+J2tP3mc0NFsxtrKtF7rz3ChTvXYLZ12Aydku/jObXfPZ8i8dedSB2s5nmxQ4of2vemGL vHOPqOzjNd9mV3tMrDbnOm5v2temwlm2YaXNZ8vIfGugaFSCc+nmWZZi78rbTLC9evXq4mdJus1T XkkvrungcVjq2WxqDZX3m9KFRo3pfdgeRD3u9ZfXETNZym/RALlxx3cjftR6DVwzVpzUezvstTab TclJ02/d7Gekj1I0RE687deDyNMkmMxqrKZgaPfPEudzzNjadnmVwx2wlM13Wp7cIm+7V15EeW4Y L5QtsvC/PKJ9nfdKRoc66ZjttMtvijWdb1PbjpFTVV3aIjxVwFvdb7JTObTkdbh3u/R7cLvaxz05 2GMPCLR6G6Y31dLErrOvJ3g5zWveDLxB7mTfTXLmdqE32NMH6jDe9DyX3cK6ONtN+GdFKUH0vPI2 cwkagelZrbVzr6NumXHYWG7tkU+9vWu7zdplCqad2ZVVda1rWru7bL6d1hVVVV2ZmZmZpl3d853V VVVRVo97nPVb3tW9q1rShIZmZznOcKqta1rWta1pRzMzKqrXLrlVVcRCSec1nmua1nPKrlVyqmcz OZmkRmVRve853d3bafTusKpMy7u8IlTMzEZzuqqqqqqqqqptPp35zeubznecqqqmkd2duXfKq6pE QZh8u6QiIm971nObzeUREQad2bd3MzMszM1u9u6Ij1M2mkPc71d9jvM93GraNem9dh1nnvJ0pfDn vfHXPeqveOxTVGtt3aVY1rUVr3ZL8AznjW2etrnuGhKN5evrb+j0cLby++afLqmvLG0l232x57Rd +WT3Kz1c3x4it6K3jVqDS289ZG7fXHL3IOWhY00VqHnPavUcbi71LdaUv2dr6/ahVUTUDRv3KeY0 jNvXdX2ucUHvOLfe6nc+tc9WBAja5pWTt5g8JDNS3xLfK8TsXvNJ69Z1ua1MXF3Mvv3RS3qdTE9X nGUazR4fZtIn1d8rXFyr65D4NL133HO5v22juU4tTM9X0eOo503uSQ5eM51qmtXwmkx62mHfxmRV 6JrWjCYhVDuvaVQ4uVcsqIiUiIiK1SwsvcIJZ1JtmXBkiHrOoBiXnw1vfdNLce2m87HKJS4FZ2/v TNd3TGgkVrWh4bhsrka12pfvp0uzNx1ee0HE7YTTi7MVF5XS2UZdpGRxXRe95XdpWXYQ+qml0ii9 RnRVU816n1DVbu5tO78b48djRW4nrZ429trbe2zcbq3scO9cVbatXCCH4YHqFXx6eaSqhk9veo5v Xt1IcpARHfRLKYHu0WuFD9a0d17Ah/TmfDk2+9rO8y3mWWB3x3PU1vdwc7MO5QmZQa4OuDCpxc2N bEGQ4bUXmLV8xMQtXCRTw3YzKQDqocxC6l8i+bVb1mNdqMXzWkTnckLMci97lKw3HDpO7498MPU8 4E9vblq6M6XeuVm+Up1etYLZ985oCrsv/NP9EQBP7/wifSAAIEjSxob9eP7l14d/u0hvrE+uRwIl wtxcVsVvWHgkdwEj7R7oUhsiLM52MGRC/pJ/4jAfThvXkdyC9O64/7E04Hv1KCAOp6aXAXpe9bGQ YH25ctYFS6U22aGlFA7HXS60XPRuDk945R7KkuqN0gIzBy0xQQkO9ejJQplmvUGHYWJSQu0bwZ2j C5EW9apQdUQg/kSIx+kIHUFOZX3ASJVXjbMj8z8v5nKqq+XclQyJOddA+5zr4fVslfNnypCMz2s0 oYNNTXWxzz1mcggPShj9f2FHKDB4E5QkWH/wMHzeg4HRAaB9kYv5DqO8cgyXQc1BIwISwIsFFVWK iJB0MDqE2Q1JE/24UhwwEVWLsAyBT/oTAKEgPJHQaGBBLCApFc/OMZJLFCzQsdQCxTRDJQo1BoOw 8gMW8AeQKBOoIHcQ7Q1BVVE8EDCchpJJIRhKYoduxxEX/z5mLT27Yq5NTIX++TljhlWOpiDWUo21 637QNvuUHvEDJNPLG6ShD9XsgYX4WuojDH1YkmBUJ+wwKgOEk/Skf6vQnV5NKdnX/g4qSazJwIPc 5PpAEQIFXnkiylyEj+SoJOMa9zAmXiiW+sxBOrrDEPqbH5TlZglCCPNP3KhjEgedVgQTC+dvtmtU vQQH8qoJAPi/PY4o7tfPK0PQgcGYmbNqt5OKRVCZYQAGviuR5BN+voIrnNvX0ohrbCucTreIPniz JK948zqruOLlsVOYRFZ+vufutU2tv+A1vvfzi/rd20NHKi3uM3MDV1vs1CerO+ztX56j7e09zekT yRnMwqRe17sWa3rYSXyZ1rmd8Z7vT93cqjc439FiO9iRmN7qJDWL4l/9CNyBJe13Zl2rvgmvoTxW P0qV5eAh5e97reoiQf8Bjws4AlCR9U+YWlrUboQTFCAahBjSAj7PeTghefMVxFXYgWqAJ1AFQEAC 1/O4kUZxMKv+vX/bV/NvAqRZEEyoYwd9vKbfOtZ0JP/lAp+g7gRDmgG3yH7aR+SA+4LbjegpDCTZ /MUSKCILFBVIioj2Vg2iCCqKLAUUURkIixSMYySKMYLFIxAVQWAjKolEiIsQSKCIIsIwBIqhAZIQ rILCyNtgwJWsYqqltC2qKSygjVkPfZ+wVP/0kD9ZBFTp5Q5UB6pt1MDp5c6IeuLI5DROiJq/tA/k kgBOAeR0RUgBKYKoBPehEa+4BIQae0CD+KcpwWwsGW0x4DJRJpIpCFSTiIbkRGohgiHEGohIq8cH Gvm3PW6usXIhtYbKDbrul7kJlv+xDb/2a/T5henyfPjy+ropb9iPIxt+/ax9v7E5ul44VSncw9us AIExurAof6icsbzSaw/E6Go4WYETdK8cRyZTQMEUhlKoGZQxSXLO3ZcDOpijxWQIH8vR73KrIft2 PnKc52lRWwREZFuzgHI7Xd61fzyVDVEDvFAsA95VdZhdZa5Kcwf61RlUoSwYh5XW9NbSurWTqIiV OXBxBwN+5d7uVXTEeQOazOqRHOSvGTK+kZGMLHdjQQ9z9G5VCu/nu5etuz63efXMu3iizt9Dskz6 dU26T3vZM98ne66nTFxGUvdLr2kyb45z4suuz5XbL8k9GWv3Nqe1yNdPZ9vy70LV+z28/jkjmuX7 4fu8lVBw2tvTwIBcIBxQoJt0i9txw2ra61P+kwB6LfgBMZBQglA5wiXL5XwXH03svr4VmSTQfRRI o5HE/FjB/hviE5lEUKfsuLVnWv18MqA/yP6eADBCAlEKF4eQPtb6+9fM5y/6jSpuLgAoU0Cimvhl jOow8/DTZv88cuWhr7g/Ufmn+UWGh9XCA/VHgxVkWBGQQAgxRkEJ3oEpBEgxkBIiIwYsFAREjGMi IIRGIxgAIQQkE8If3qrFFYiP19fgP0ft8bP3DKcfxOnJPmcHHRet/YW8IGjf+pSavZqw5S6rNBSW 8BXPGdt9YxLxkWXtYnNgeN529hVNJAjEj9YLcRMUU1TZBufs3E5hDnvnG4qPX8d99Tfm9Qpa1LhQ HkZEhV8hdQkK/hlFQ+t5DQgGUKSUbVf5a1gc70+bnb4QzdMRX3vmdZ5TPiQJPjwGAkPyJIBdeML5 ve76CpSxsVQAeoHMEcCCRHJ5TtWhiazIqETYLMACSdOr2a6t+I4slEFTZEGgiICAFAYoed7PDX3I SM0CIJWZxcvX11G1oM784VrQVARQFBPO9cJ1vW8KwbydaJYBOIABtWDiQeq6Op3zvGo+W5dL/qXD ICAaQgkAgiiMFBEGIsVGLBYpFgoIqCRBQWCCCyR5sknvrfDX547utYXwRkRVAj9YCewgQXv8W1qv t3EIU6dWU5ATKsHKMb7O97Nn21hWunhXHXHVVsOpyT4ewxidIGUnl2nOpS4pWtYRrUm7/IUiqwcM Tv5WIpitFtG7llPqR7qynhyluhBaVzbtCW+h3qd3r15TS08H3spbxw97tO911OmLiMpe00JMJ7Ot 5nfbrxr3daQ1sGXO21a4pTIlkaw80/sE+wTIQfBni+KQfK6vwz9x5mdK/QCBALoifDl4eWUYlD3G TnPg+WqTYYKBNZeUALySnzNYDnOZ0YahK1rA3QbZzK5NfG4bXN7+WfyKV9Fwn+xAzkJ7vuKHGLCl KJXe2DOUnw7uHHTwy148py5TfvJz7A/aB0B9/KpAoep+maNEjIyEBJuTc/dVEQVGMEUYjBGKKRQF EkYDIevX7fCeRPx9DJqUqkRo5KWEIcYuijYQ19Oz9Z5ewSKwIDGBIIRhEYsSDZj080N3FTD/KFyE 5VwRQ8Kd6/q41W3nhleitHUs3OQ6HPH9n6icmFtQnDKlQO4CbSkYHO/POfJfrzN3uC3RXISHfNh3 j1kM8Y+gWDAfgTWDMoHmeRfa7T4/Ops+2uuGjhfAe7g96llew/ARNCH+uLJVBsV/A/VUXMCYzf+h FsVm64QKqqFNsfS6bdIREgg+KyEbC6vqE7Xb/aKCdU+X/CMHPJJQ8huIX7wjFVCDzwI5xH368Hny 1tzEyaoiqRIetGL+lfRcfL/ICZFnxZA4FCTtofMVkJQMjshaSc5HEOKkmsMQpaa0rOO6hgbBAOno RnE93XNbUVfJUFFNRe7OBJprb607y9RUVaLjqkcuqIwvQNIchLvbYHcP3bGaCpfl0rCDRdlz8Oyd 96061r+vO/XGda3ylt/Ua63fnxpXnNsksnzy3mfZ7brefL1vBH0tehy+nvYZNq+117tONUPJx+JS Oir0UPUuZmL3nrdnfs+6Nz3W+Ub94zUby/LBaI4uIK2+8X/k9zKiJ6BG/yfpLZlfuJ/F366oqQPs gCIEGEQcIYfZ6knb/cYphtZfPQAqtwicARWIJGCv1mjU+fS3vnMZEYtkBAA1CwLe8y51rUve77Ol a6J+6BGbiqvHs7vtMYrjBvc+gIK2P6BMABJxAe8nz352P1tcZ3uHLXBBH6j7oALkEhAViojAUiiq IqpIpGMBGCyAEgkCEihICMAiEgj6HzWRNHyT90v6Tg5FWMGIoIMVBUWKsEEFmWSpEFGEViKrCRJK ygjIooijD8n0euof6EUF/Zh++/O6ugC7pZ9yKHn4yas3h8Y7wpLxgp8IuXUT7Q3fck4RHNNJ+zbk O3FCbvUKZnJVQAkfgdc36efmZvfGLuFKkwi17WXcKWhdxUTbCiuB457Xp5cYbePnc/eG19/jYyH3 QWHkX5v+E1awZ9SQ2QdoLDTuhfr7/D8JmHn8T5eny+/wdIBtR+yqo/fEaTFfy+rxrYGyWVUTFFDn BQql32o6BhAKqAU+lH8VgkCT9x+Pu+eeNWcyUqE/hbhykg15+e1dbyKNREyfHODKo7asq+W95G9r WCpQqxJ7ny1JQSIkEFCNeF7wUUCq+VXIabRIJmEQTCrbFz6vfXfyfPrvk66KhSr9gqSEAgEioNAA VAHr4A6njr7Sbe+woDhMICCEz4oDw+FvYWX3HY1nj2jWJrabpW5uArVzuSlerLyL60V8nwhJOmc/ OR3OouPzqM81ZdLK695/Nzdi+qIj2r7v2V8/LN23uL05pu8Zklk75fZ1S57brefIvUz7nUelds+q DFa3nvnmnVTfH75Vb/ewqfaYW1EeRS3NNza22SxruJol/25nRjhVXYjAbElv2/u/dX/DpeawCD7D wGxF9AOfScDpn16eN7PkjNov7EFE3eqDN+RPTrt4buuOPXXWE3qKeKu8BPfGUnbhrw4enTPQ/MHe no8VB4gHdDaG/jrI+/nz569IcpR/eQ/SA9IAGHHSBERNBBzxQ8B5cDeprO88Q1L7hDUj+wBIQAi6 BBlQ4fsVHn2pa661r7+V0Hl0aHuAPqcih+QGEgHxBX4onUcBFFtAWhPl9DaQIQIASCkIIWKkOw/3 zdyD3zyh3ZhSiFnv1q/EIwAyBKygHn6/GdNSpQGuYGDZC7K1lMzJg67hv3DQ2HrgrLBtnxzlZAXs XYljFdKqaBYZEjsucpuReXmSMVWCC7vPtycm89unHMiubpxgptzZrfDOlQZ9j8jlg0lZUGYQsyew UFdM79AgTacD6/zyEqFABYi3B+qgncqXvfeXa8P7OwBe+wl1YGuI6h7yMn8CsDdm9i6FHiUf3m4G 4/hBXxoQgSTvsKZ0aeP91SpIuBsgLUOC+w8i55BMUS5AVGxyvYy03qTmKAAeAWIRQHf4PWZz85O/ nIiYNQAbIqKxEZcafnlXvkTNABJDoI5HEicoStPz2Oq1FbIAosGCwodZW25ahOdoULSl2Gd2b26t dbNWKh7p1L64dyHoriwWmIZvKrQaK1TXPVfT73OBuR7ynopNZbyvppqfe5Xne/ebnOsu9vvieVp7 y1atGez6o1nQ3vnM5lUnUpu+B+aXPenx5xDKVHqGU82Zvuea7rCx7m5rjRc2bbzTXN7xccsSIUGN jwIhQdwOk5zbj+DDuQfm60Ish4YbEQxiX7+sdcdffeTjlTojuRfe+nUk8a5jb441l3mBveRmA0Ag UKfO35mrYxumpHGHC+ES/VCBziTfzyvHv1fWu4a0h6PUATKJoFEREBIgkGApIxRkGRZAJ8THpaIn MSoVVCz13x2sa1q9Y2ugCNNCgFiiJ/QI/+ERQR+H0U+ilj9gn0+8NhISHqODJGwIMIDy8En7RFOI MRTCu0BwlwkkkhJCLFiixEUUUFFFFRIsVQRFBVFFFERGIqqqsWKqrBVWKRFRVVFiIxVVVEVVQUWK KsVVUFFWLBWCIjE/Wf2sFI3AZBYwIwVgrFgqsZFERFFVkFAUWLP1nhVRhKBkEWKrBiIMYREWCLFz F6EtARp5J9yfzkJwFA6AHZQyPoG0zAyPpxQH7yIvFU10BsFdFXY6CQCDIGBH9XejyInTnbcoATJB 2qgP2HcDhU1APBA2BGR55SgP0OsSDDpT8fM11YygH4ZcpQZbT4GaREDtJ/xniKIqRQUUEGR+Q8Qy TZkHAwVJfNUVM2zeuf4fealFD3iLmL/FFC/tU2XsRQ5HCwEQ9iUcvgdhPAe/c9FXiJvAPNQ5DETQ Q5IAqdxAIO4yhEiMUEIgntBgkVnk4BjIkiEiyJDQT8hopDvVaGGYCczxR2Kv6wdgivEdwihsEtBD T19Zar4oD5j2EPZ7zyzAClXmPmIodhFLAIKRDyVXkKbxgEngm9foDyQkJJ/D2SIiKqxEUBERUUVY jERViIoKxisRFFQVRIjBEUVVRViiogiJ4CKFgsACQRYiFI2CQkWSIkYiIMQEUBkgLBGACkIIIJJ6 ktIsEEKW20tbYFGqyKChCyMrIDBkYIMERKIUYLZSVgqwUIMQD5+5Nn6gbImwBA8lKQBwHYAsCwhF iNgzYFbQwALyngU8AD+09yQQkkQIPfCDBD1DuQIsRQIctqg7IDawUt1gQfxVAXrELG8DYIgloDAV E5I7xgPBILBUgbgcCPsA+2gG8Zs2ormCrASIqJtBeaoqdAV0Nm5UDoJ2G08DfF2btIlmJ7HDq/Cg dV7PV1DiKGgOY0aog0LFIhvNisRERZEYKLARiMSLFIMRiwSCCyBGCsFgoInwGwKBIAbxOgloqJYp sDvdiKNiJA3ekgqUJYnSKOdvAHmRhJAJArIdbjlxlKKokrMYFnPx+03Nm5eLkSBOCcAq2QlCgq0L CE3IHKCibipwDgMgOgV5QF/o6dAHk9HchuVFTaZpET0isgnqvAglFA8AhkVOj8tCWPjgFewegBch +VRAeWwErcOwoRB+TXgoPqr/FXYA8vhH1h74zAVyMkQuLYBYUhjFLaqojIlySpIYNYy0pLUhGXLk KmXEuCmNyCFrcRcrhUTCqkYkzGtqWrUJguFmIpMLcZUyMyYyrVCEq4Va0aAkmSTKMRiDcW4xMRMK tUZluJMtcyC4AxUohXMsUwjGy3MuRuZbWoqMkKNW2NjKLDJCUiMCLVhMLMa4o3KpTIiRS42GKxal FmZluGKCNYZaQVcRgxiQbYCqozJhGIGMFAxjlLMW2klGmYYyZloKRcKOJRYpWmUqiY3DGmIAsJWC yWMlyyGJcuIBJgwkjayKSYhRZSFCRbUZiTBQS1LVhJlJjDJUWWypCORiKJllawtbFy4mDWlZmFmF ihWtpYpBaKNZK5bIY4JWKz7lVBD+sVTb3SBIQkAixEkCDEhBCQCEIhQiIcdQE5qrT4PAB7x5p8AU /+LuSKcKEh1YAvAA --Boundary-00=_5mARBfai7A4iOym Content-Type: application/x-bzip2; name="objdump-2.6.9-rc1-bk17-r8169-dbg-a.patch.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="objdump-2.6.9-rc1-bk17-r8169-dbg-a.patch.bz2" QlpoOTFBWSZTWQ61LnQAHaFfgH18zn//9QQAAAC////wYHR+8PXyNAB2HwqgFUiUA+vdiREffe8X RiooAJB1d15CEdx4BnNU9H2BrW7sdwhn1ieY7mz3W4Ae8HuaJdtcHoIFCFo3tezgivtnVB7Wvu3B 1Vx1vvt0C++1N9e+BvnSvgVe+g+gId8PWve29vR7aqj6wC77LtW22ru66eQNduuNEQMcXtvdvemS TxA3a2FDia7dVyjUQ3ezvWgZDBoTtXV71kWHdwxlgcQgAAAAAAAAB9gF3is4DxDcH2N9vA+IN4vO 9Gnk4Q9z6z33w0iDz0Tu+tHTDGqD5YHCH12AFe22ZED63baMaM1wAcgmDTQgAEEURTyj00moGgAA ANT0AQFFFNU8NKGmCMjQyMjRhAlPKSEgKNKntKfqhkMh6jRhNMTTCAIUSQkZNNMkIajTQaAADQaA IkkAhpGhk0MimxTRHqNBkAaaCJEICE0EiakaYRoBoDCGgbRVQTx+wUiqgFEEWBAFACpChUpAHAgR yBSgVFwcjMCapRhgEAwUkUB+f8gqppI0AUiJEiAFCoIxAJQCRKgjEigUKhSCCUBh7+x5GZ2OACvz FmoaEnHm6u85w5Nz6FWh37gqdtezQROqDyEQ5wcCIl+gDY2A0jDMaK1Re+KmSslFQxG6zm2yoBVO zsgCmlNg20GUFHxAodJ0PDpe3FdJGgoCIAKEpSgXurBkAUFIJU8PAcZAq7WNsSmOwZhpqAsPIRsx wHFwFwHMTEKsSmwkCGEEks5w5hqbmdK6OtVcy6TgdSEQdQx1KvQGYIYkXMWwwcgoNJCTdxccHRHE 2d1B1x0Mk0wlXNwTQ3dB3N0dmTp4rjtwHVwwXIyUwLXZdANBMNxyEtIdg3BYHXlUxMzQEA1uhM0O GZFZmUWIicWeTMhEU1VKUBWPGzHk1QYNpWlYa12FUOdFbzLTrTOdsjrZq5aIPZQeg6XRB1QdDVkw VNyBk2ITDENdBMkDnDRlKujAztuGoDIDwMFEoatIiEjIGL1+T9Zyr+9v4WP5ktPlzq19HQ7113vf R2O996f289fCqqrUqqvnmeI+Gidd13VVVVVVVDQ5VzmjKqssOUbzh6ls1VVXrpqtS2kihqrXdmIq Io9Wmz6PSPtr/P/RmBB5GsQUoVe1GgVsZJhYcQCsQykkkk1rN1kaKCiN3ahCFRdDSaKEQDhUpHw5 wSCRbRGKpVCEKiqERAlLVspBaw5LuTAqIxf9Lz3nLDg/8kh9L5DKs6EM69R3YkqjIpV01puL9LRc t60iO9zdJ2NR9uD669/j25jpHYEirBG09vhUsBpQSP7lCBUJBZ2QqeTU8t2qqOPLhueT69vPjPlz 578PR77pBGUQI2wgS2MKFRaxZwSCRbRjSJkGte0oJDOglQhKgspTUMFFTXlnWNnBONyHFYudLsFV dSiJDULIvMnW6NhxmhZBXenXZUoVJNImKvOq1jRG6Gjj5ySZRCXR3UqiqqqhTaEq6KxQLWJIrb0C N2mATg21siPCULIJF75IkWbtQTk6BQgt0IxWqK1Ja71jZBIJG41WsKltldokC3ZERWCIgTKu7KQW eqK5xn54cmRQJsg9GidgkOi6xwgpNAhzIIBRPX0xn2kvEsqqKi5vrvmo8vbOkezepCSVy4N63ze8 bOCcdYPE0LB3vrBQVYsoYOrsaO7Je58I+c6+R8c8Sc+m5vH7Ld9OykFremZHUmqVVCIgR1imUgs2 YOdb5PUVngSDrOuOGBVyyhgVJVAoKlSA6posQFXqbraqfs+kfnrt9evU85nqpHIYaHZGS1Gqji8N N66dODtF/Dv8c8R6O3YtrXZPHdJ4JqxSalpXvnv8cHfO95WKOCcEjzcgSKvJGrxkgthSTq0x8J66 FehKFEF1dwiEoEkEEoFSUZ7U51vnOY4RRT778PR7Lvzfb96ntGiVw86ldO9zbcKFjJLUTMtnGdDb xNAlPa23kUKQxbnCVRCVoloB4O2xaAiLjE1QaDQqISQICoSQ0qc63yM4ycE4JHasD3J3ThMKkJWH OCcV9jyG3xBwSIqbwhSeddrwSQ4LM5dkZkloMIE+Fbw8W87XRakQI5QcRSQqBkCKbEEF5ikvQ2GD g5kAYywrSuSyEKmtKrBESSSaQ3nN4s4JBI1LcKEm8BNk6nFHFai9/KYqVMiiCytlMyUS9WNeHzN9 T15O1jZDo6H/sqqn+hUoVJ6Z2EyQZCKqFKlXYGdbX1ocIJG50F0Vbr8UfesQ4NYuBXTp8OQSNM1v Iu2eDWJIJFHjwdmiSOuPUUUddHTfLxu7ulFFabuszN3y88zjnnrvrvtLeXedOLinfO87Kd3bgnBI GgX2kK9jJGWzogkk1gSQCVZoEmYciMQSSSSTKxiSCi5CIDCKqTM4kgkUwmSlYk4JwTg04BnFKApe EMUiiiC/XkEqqqqq88fXVr2MPdu3nnmevv3+O/QntvvgZ76/I673zW3UpiooiSoTCFAdFSSFDQzB gjFVCSpery2cQRaxKijAsFd0jsHBVi7KzOWZlUIiKiAvsEl7q9LuRvoeJE0db3xwwK2WUMCpdSq2 jKhJS+ucHny7pC1ETvsu7vTaMm/nzt1uEQw3TunOcN485cHg1SzXdul1fb+XOtlioVWBRFLx03uR jVVvE8zrl+xsj0CRVnW7J36A4K0WUMCudIHLugmBBBZwTZszGIgKyITCGY1qcwhkZW1BLoqoSXMS gu8ZIaKpJmMScEiWDLhiGYMuMRxg5zhxvsTVl2b4b/hQf4/m4LtkLLFQApqkVQEaUqLv0aUEN1vt 2+BjhREEf6zcVyA956lOEIn9kh0R0SnP8hCz+uCwPSCh38Z9BoYdOT/hCl233Z45mvJYUXBRR6So vZ3ajdCFR8IuIopPPr6NzpBToFMUFMFhKYBRAXKhKqIaqkppRRAXqhDuCtoiiGH/tA4IBkg0qYQr MAGEmQnsgvxNI/lDjFDVCxFNBQtAUJkYSP/igsRsn6TPX8+tOhhm5VVVVVP+Q6OJh2gspxVVUVVW OkN2NxxVGGzOVGHLHkGuZasddXEJBTBZEOKqqqqqqqq9bEW2lchMJsCaDAaBz59OuJ2R7bQgghRG E40oZkdpnaTmYdPCDAJOrZ6g2NKW2azbIgo5iYHECQDZOtVwQ16wuizlCQ9QdBHIOi6Akwhl5gvV QMycUOoMCwwcwMzlffW1bkgSoGoa4UIZRNAGkK40TEREVREURUQJEAUTAUkjKUgVSFIZDsG2mBjs tFLQbVm/iIfaUpSkD98J2gNlFaENlyEClKQRooFClTYRyFCgVzMQAyUchEoWhFpyVHIESkApBSMw BMkKQpSkQKBaQpCgKEQpMgoXIAoANkchFNhUyAClQyBckChQaUJypnSMoKyMLIySqsyysfIU4rkn 7oTGpmKMurSpXMEQUFBrMsVXtzdkEEqxxVVRWbOPHVFx1Ukan4QwiiIoBNlUDCAEpoaaGgoKUQMs gRoUaEFyRaEMgSkAKRaU5A5IFCGwGQJQCn5yiPqflPtZ98c9zeCcCIQKCiiSiiWkpRikZmKWRBtb O+5vYj44Yc/a9RbRBwQq3dcFMidnGCCCAgYWRkTMUsRxfIZnddhllcGE2Dy9OtVUJJJOMJCxKsYb A6RKh5gh6uvFFeki4/e8+N5ttIR+LoS9V+l+e9dVTYXNzLcrdIHBB2IjMg7Ie5mdmODO7vsHG8ou zUriiJCJmxLtQCQALSxmQa1q5iwjUxCQP9u85G8NjYzttha28zhHIphKku43QGBTBsEVOcYyBwUB AkHjk43dBrvWjHWcaEOHkK6/z0CW/HrwlGNUhgdGk9Hnx67CsYPDEu859enbfPbF2JPLTQc86tvn rk43okhzrYDtKwvrzut56KvzzZXq9cpuuDXcEschbgdd5IWeMHJZOeJJimAsYflC7eIV2p8dulHN 6V9svZtmztDzo2oKEZnVmz4Kc9qbwwbXob2pMeutZobmc3Q5xZHDnSe5p+B4iJ3NiRxWfffasXCd 95W948qTjhwsdi536Hsd46evT7EqndomlGuajsb7rVAXlNGPRrk80NVzZ4OTnnng378oHpXoTyB6 QOVdCegOwee558+QMhzyVmChkfWdi8AAeCsmVyHSeT0LSAKVuKobqG6JFNVDciXqQVLno+kPGBa1 qtYoqzmVhOMObjqhsVGKuYWE0/+8DTcFDkW45obqTm6SbBqQbqOhEwcchw4CJbXLiBERi4SZHuHB B/YgSSssIQsoQyJK9h5+RjkpJDjL+sAXxCkyAPeFCPWMWv1QqB1VUhTQyVQFVVUm49oA2AyVoWlK BMgYqoKQKEopQiiophBXusCGQlzHJExJxhShNgfzSE4sotbSSv72R9hD8iiFPwkECkyVoiL7hgB+ RwwBdhDkiWihVtbXnPn2Y4czFCoyIpfBkBBxuwJYRAxvKBAxIvMgvjnpy29mzA5s02mlqKQ6ifym eRD09Z6DSIvgiagjsFAFCvmGohvEyzyS3s6L7iG8NJVEYkORMcjc9d5b6YPeXtCd4H5XrFHgbIG5 M0V4lFzWAo7XdqBBdyK34dzeGOICGSHUAHrAprLHRgGEGQhQ8EEyzhPPRbGB1PAwIVSItENQogyA EZ2F1YkEhKg1E4zq+e9rJHaEkkdyazx4pEwMBlCAmiFALd8HrVmmGYzjmZ5thaVdtpLBDiAiagee 6ORrXB5EyHp5elt4nk7Dz0Y7EPQo9Am4JnSQHRyHPgq95mBvTsaAV6Cets6Nq4ztgLLU6laUkwAQ BkkoaYZFKC0hMGocBVyyWQgb2AnuJtowVwHBwhkkjJ1CDVPlsYik2sdtWbaoBiAiUaLYBUmE0wxx XCjjYkZucA01UMMvdzMSnkqeRINOhVCCnUZkZ9gcwFQu5BBwQWioEQMAQcYwdWd5YGeKEMgUSfJR 0rq4Hg+E2jAZuRAJPSjLtEW2TGwBQQ4gUAcp0DwA6JrdwL8FhcYY1DAdaPBn9Kb7T+NkxHh6mt6M E4nUQd55LpXxJZk14MQOPUM2MDgxjSACKDradUbIDk6HE8KISzjstKwa0bKgYxGdicBM5ZUuAotc XxDRxNQoIIIUoSQoQn5js+x4Q2u/GE2gYg4IHGOS1FHS6MvONg87XJnvNnm9eNt9gIGxjUCoPz7S iKQioJSD4YcGOnpU+3bzzfagoNxtca5FcwRogEAnZkOLokDqkJzF4POaSMcUbiTydWH9sMGY5jUz zPqr0us3zrk725khrBCgueMcNoZRO4hcnwh3VnUM+KMzZIbhQeN8NrAjqjMMtN4C7jO+zBraGFYk EfYnmx8gDmcDA0QhfTQjuOWJCjhHyfePOI+nbAnco7+pmzXE7MTP0lDISIICKZCRCWCAkKAoCkgg mQZmaCZlKE7QYQsErFS0FBVJw67vWh26wOrOuejx44C+rADwtQIdMTR2HwBpwhq0YtgIQnFSYXbQ iLHdelkZEATwl+tyNfRLkKldlkEmOnZ5sYQ0go4lAOJiO3AoAvl4fJgYwPhk4Z9p6Wein04RwiL2 NS3wPKvHdoLOkhJ8EAbAwo7yucVHk753wlc7nxCYwWX2QzYGuqc6Ic80Q3oM13gxfxo6dybfB444 55IXdWlts0lhhUdglucOBxM5yNRXYyVFLWLkkiloxgwkfBlOdTGd8lfGiXu7Q2MnDFQqLGDXUwMT EADdAKtBBEcDhwXCYqbArgz57QeD5MyuRGBsQHXvPsyr+EogbPR3cAFHvc+ytph6C6xhs5h2DRrA AOYEeKNmMYwveKosSXqVYGTvjkrkrGijSBsPAxjJSDjJQGKzwR1xZuSDDz7M2mB9+c7ccFXK1rlC CTnSaWUBIlNcDzA2AUIBKwaQzMZpBiYwyMrUbG4zoGGrXYDQ3OaVQgFAUKFCAZTEC+oLsQOgJneg FBcZgd7I6IiCNbCoOoZxh8BARyymAYUt1wikZfVLa5UEnN8VENnGBDo5AZdv8eRhDyW6MNwLjPjg 4hGUdzIk6PO7xcuctnAUzFAy9euiVHbOYYGaLHqgszXFUbJVSjjwd4sj1AzB58diXjmecPR3d2au w1nMM7Gmy5xhdhvFXmhxphc4CBcGUdEpU5fanmxog3tDiTjCvhAPOgU9HLrPZszNwEBFzaEOPREd Jp373LmGi5t2CbtgkJKBnMeK5saKJGvpoYEsIaPXTqZw1g3IDrFoW2u+cI7EUdpmubANkIBCQJCI ROnDqdNkeRWGkeW8nqOS5dbi9bHOst29nJzSg9vgoQ7+rvHA78OtwRAwcA4JakCgyKpAq7TzBgyB 1amSw2FEkQ7AOcNhjgX8l2ECEDD0JHyOMInGlslVTCf00XxJUAdN2qgYhRVhvh59KYQaDS74GcM0 skkINH7lMdOGIdeV9OYASpzoOJ4eSWA4udp7XERHzPxRM6zPq680KFTgg8Gw4pjPt3YoqSQhyFKL wcm87bemFgaOdpRBVBkj3ExlOLrmEwOYixAOJ2OSPGx5WPQ4luQGA72OhsKdGm4SsUUD4OOECKCY 6CnRqRXS/BLkSsIC/H4djQoIoraL5lfqYx20ABd+MnNwOPOSmpxWBtWRkxJA2rhmx6OLwN0qAgyM hcKo6YDEpqKgBhgjg1bD7R0ZJm0ECxwHIcMHXMmGzNtshns82Y62u9qKqmwU77ExxQEMxxxWgDBX mVucnG9bMOEhEvitPr5znbwGQa4DiKYHAAcAAcdX72ed0zhQxSFzxzdcU6BNPN5zotNGjIb4ssio a04ZxXnjbJhJwCa2Kwm8oUedrqisWXIMIsi0BQUFQyz6ydsLdE6zERfn5BwZd951GkggfDoIRTJq dDEJh4qRD61mPl7bBjw5caFtzZVpZ7u0OM51sHEODzGKqg4I0Ayr3tl4v1lolaoNTfil1vHGMGIT cinFG94K5G1AuzumzwZAbQUKBgUQL1QIOcaNAEXI7p3IJbCJgl1VSQqyMKytzpdgKPAoCAYFO4Vs YOy4XU6YDQBCVvQ9Qnm9jYOBovdF2CGNrRoPBfxoS8Ug1x/L0YDfPPxfVcbGHBZ3fwdHJcoCNc8+ Pg2NLxxrOe/eth4pa38TA2MF2nIKScXLyGala+dq6RZGOZ+tD6nS26tvEgLyCajTY6EEQRCQwDtZ QQQhqIdZ1rS1pvBopQDx46DAGT4KpdHo9esx7A0usRz1EOEFZw+B34xcBY0ZKbX4woNvLRhdEZi6 VdkPO9HPXELze3HR473OdcOdu84yf/Wn/8n9oj/rUF+FAYSBP7cDGEiWKgTIoMzAcGhkywqFKSTI wQkmYDJTEohpqzMMxchokiTMTIZhJqYIAIskywlxJbMcKCIbDMmiGSYlYj/YHKmlFDEyyMsgLBnF yKpzAkwChKBpCkFDMaUpqoqaiqgoqgqISqKFiCqqJZqaWJ2KBNpYdsKoFoaKqioMmKCNg0FJNisF ZcMQAsaGijZoNGhUl2MMiyyapyaYkkkqpViqcmqSSSam/tDAhbHFTAnMNwxQHDTEicKpKVVVqsps mmKiajTM3cxwDQUxcBXMnLKpqpVqVWm3MQzdzJVcEwlWqpaqotDHUNMSsDS3DcDKgMglApoKRpDQ Q1I3FIMwMRkzM3AU1qkKaqSSoqKqqgnJpsmqScparcAzNTTLDCQDcNaYJKWkkkmrKgpYqkmSlskq kpVdzMAoEBNRTQDK1zDQBTFQMEdGXQQNQcKaDah10RlEIAcUoMBQxAQMKDLT3PO9er7c3hu5w3eu GxEUllg3vzTYpmLt2zDcdJxZuhs5+z2b316bZEHrk7KqqvlJ5Jt+t8BDNYZWbKLXF/BeCP6mDVVU xNaxls4HRuxCioIiIY4+6jznNNiy5up1wg85Hv7x1who9b7c46U2Lil6dNlzzc343dE5/ANNN2PW nN010tnBEaaEoaW38fnx38vLz0+Rb0eHmCOXPKr6fMvGhgqoGR5N+H+9Qi6yMkzdgKqocnpQoyFs V2lxDqCybVI3VY4bCJzz8u/2hS9r6tWnK1pqtacr2J6hsBlJDYajK5JJWUGtGHd3dIMEkkkhIjbz OqmZmZmZmZmZphQKY3r1J+Pi/HfWIqLimxDmCC9RCIqLMI09fG8RUOok7TO3T/oGff8DDH5SYQd8 cj+ewmoMSXlFQHI24STs9yDgXC63NGKnnY3yp5RkVXI+xUBrGTt2OGLlhUPV3Y0l5hgjvjiduHcl 0HtVSZkJkBkLkpkg0klud9extzNOmW75rqYYMbg7pPqsSuuczvm93DYnMnJVyB78jed7une90a5w lU0dnbdXrkI1CimpOKC90G96bpYercA7cfOuTZPOrLShuMBtpFTNFb1mzF1ZlOCK9OKQ4dJozk5p WsOxY7y1sKqBlgYWW4IYS+0pKLipA7V/Dr2/NqPduOfo3ThYWxbmXJ4bw3Xcap5DkVcghdLdqL+W 72xRxxRXE5MTOKRWUP1lf8Ss9If6vOHffm993SDwueRx0jEB1AIXEIgLwuGWol3Cov+sBYFJZQWj k8I863rq6PXZu6D2d2PZHNq3UTdtyz2dw5Cu7BhAIQmGyqAtJwjkIGdVMNgKFCdbxGHgbG8/m/T8 v1fo0Nj9f4o5lNzP16vNrHp6v29d/qHjjgj3SKCiIjmfETmXvp7Pv1+brQXwydJAoIvIkDznNzjx y4wjOSKH74yBQcE9v33p555Hvz8W/18sRVw88sD5TDgmKrr/V7Xj+TzsvihZZKmjSK/0H6yg4Yj9 yP5ksaIo5v9mqR5hdmZJOSFCpgWE+U4hG/k3pRuBU39EfaRjJOj+p+hOkOShcci3955OakyTElI8 UQDRIgNK0IAhj+Mc4fju7q6s/XSc3n3+vOmKeVh+X7b09YfP3Kdj7/BK5lH37byiYIfU/YeQzhVj cEfCkFVQRYi98ZwdQkfv96MGHDfNnd94Ma81lOAxdtl0XVAFaDRUfn8hHb9++Nw2rH1cwYDGERFJ ZpKLh9GLHoswEJ8auctevs/Zzn9yXcPUeg6I0URNkuQk7t+TuwH7uo0enoTPxt9p+O/3c5qLtAJ1 v/BOPliqiOS2K9RriqbumzlSnbI7ELid7CKnXVnmciHtNs9t3Z5nnUHM/R9bhJ35Zp4MKKI5y6LP x0scd26+bpT3CyedR6fVzOqDm9Oy5mzll2YzMTWKC5MzKVvZq6MkNCQ0L33uar2kovV0Dp53ua4d gjmXfWnzUZZGO+LvLHM1fvnF1reBiBGtZw4CEhc0fPbe67xHEFD3zrrrnOze+THnkav/N4SyBrgV bIp+9XDM2v9rlD9z+PGPesyXDaff2pownl2TkJ++GW3VqyymEwLeV1mBlo0g6v741+O5WTQ/Ji0y bPDRFQ+FMw6hXLhHRCPEOqfuK4KkmyBJNOilKG2DnEFyP3fUGNHDfw4rNenUYgfYoMMgC+r0IPdw oNFCgg1adHgmiFBhU/U8LtpYBwwbWXZ8WnVRpSMEYDCBrhn8mI83WCe6z3AxMwosqmeK8/OLkf4n lgaic3otUmm3+J+XwdfUr3rVUFPGC+EBHuIlo+E8o/Ep7R3lU+kIPiRwlQbe1v1gyEEMfHJYAmwa WLIDEcqWt6l444xKpSMCkgI5RFRcIiqAon+H6osHAT5+0RMZFYvTtfOF505xXfKWZ34rCm2al71x NpkNEBp22sUHoVQ6QEHgIDiICZ/KDAQURqDxERHeZmdatEHqAIGgiibHVKC+aaM4aZFesWJrnjSG o3z5xtvoBhPEZBVdg3edvBtoKmwQQNRXmNEN7ph1xvg9Rcl51DvLkPSBcVuyYmg9AgU+LNHAFHGh KPoYsWHCIgnrzsyQK6Ea18yjrvp36Q76y597Gnl5mgJe5edAfXQCSregsLJPabDEThaaaUEDKyGB XNq3Gxcb110DHeO90PDLqX1hrAmtjbd9jk4v3Bytid5AcLYYRklZxWwWutSSMEEQ4FgLNopkyVNZ IdgQXSF6d7ywEEdDWIKjk/oJDYZhhJMTLIgZOcVERm8+eC1hRm7zN5q1usFtwUCYzhjhOoeHx607 EuxK4l7/G70Lh04muRkmpkhHWGlj5ThPNQy7u3XEN1pukCQkCEZBRR+Irfxc4PHJEyMbMWI6jfn6 uuUe6uqheaPjbbk23L1cN+ykucQNEMkJ9YRyFQoClpei5FJnbB2e0daYu3UbuKZww5D5cxfeDtJm YbF2zJWjqDBQPZRAfwIIKYKgqoIoKmiaCploopagFFIKIYmEgAEJIKFVSAJiFAJgEpGkGhKWkD59 dvk+PU9zngDns49EeBb8oroX0nmx1RmAb7+BHx2tBJ2UVYhQVk3H/1IgCELCdgVV1ny2K0nS9cWf uU+4NALtAiAUIFw7gkwu+JNmQkJoAByKE7ovEgePq+q+O+eNbnAq8wPkxglErbxvx9FLCiIEQWG1 qBAEEQhDnH3bE6Akk1QINA1dwSRLk4HkIoTIIiPazwKG1463uiuLcpUXU9l2Ek6nXwc63459b+Oq JOwEC4FF7tAUOiGKEXyudtjFsGuaUBscIg4CQrFCd2q+dfDx9vSzY95104++zzf0fR2og1tHvXZi l7NNb5SYj0HaM3FYpi9xPUV0vK+XN95n7lPbtpLJPFvvy05XO5r52lCcudfIq2jXhlxoV4cz6pr5 nfdfJ2fnIrr8+ZPTmobMtuDNa+fwdDJ3yFeU08Z1qp5qNF9fVTNeVNqmfKa30HnZ40X1uv3n30kn mebD9LjkCq8o1nA5MioTCtHQPQOj0Y6O4NpHqXothK97a4EGguyNrDAlFqhcREyRQABLh2DEn5rb +caf162ZjPyF2MgjmAAcBCAWQM9XNVWCSJE0A6PGcAkDTEidaVvmExQg1REGmNrvudzt5eXbc7ng HzGRhUoKKqIIRJBhJGOVp2GO/bnppfbXfnpOJxYwN35oCuZoEEjiNoOMJ+6zdMwqN13MXDk6mmcM cOSbw4O5g4bimwZzguC8ROIGuZkEEm7mmYTLbzjmoMYFIymI8DYtosYzMCCi13ConATUyGkKyF5u oQ83AMBxcRzTgFWc5VaNgAhwOYjpo6GInDSJm0MTHDmo68NuAWXAWNphMBOMSRDFbtaFFs4mnIrg as4ciNNTWxpTCG5jhq7x0tXgVNulBq6EMU8CeGvEy5DvEKG5iYxOa1QE1MJwmKI/dhkQmg8BDITo MILkaaOYXGtUgyxKx1cKQmAgyMcj/f1C50JnBOxJJGiO9cXTOkIeo4uZJziuQrbmLavDmHNixXkR MDEvDOXOCcQtk4XDTLHBQdF1iDchBRRSNCMZyszUNREDEn6gTRAptR96GwrdNCPz5LlBISoiAezF GQHO9LShK3m0NuN/2kim+bO3DwQBH78UtwSEzEXWOt+v0d8dUd3yi4AA3OmyygImDgLhIwJIQ4WU TAeOT9Z2ytaTdtCL1446+kP4Q9TUHMagdSpvOJidQcQ8FQMtThThvxzs47jNFOEOEIQNfGkfAt43 bUKm0bso3iFRuObxZQEXNfXeuvj159fEOQg8p+Z5KvUsjaSITjqg/shQMQHAgFTp2ZFLrFK3hoJH FUYJMUh6++Db9eO+NyQZxXbDvvz0MmuAgeavBwUIkKEKUI/XeH6PadJ51ZqeqFFOlTiGuZ0hzqvz Hvfx+fR+fWude+OegO7r4BY+Ykhi1RsIgnq8fLrdepK27QZuORk7N1uvrBy578dOPHddiZbaCttB tloO4AJaJa6h/SO67GzfdGyLsgdzSFiGaMlbXYGYhtdYIZpUeCoCYAqQzwdwSIKu315L55951qbv 5VLiumb4IHuBSjLx7tXAp7A8YsGRcmQ3xSbY2srFVEDeLV0OYuoOIah5+/z878/e/XdcydQZAlUV GRPIHmnWqTzEvWLOEAU9Yd8zmuBIT1Rd2dIcfzTruBE90cRAECGXPKwr8ffd6VRDZRg0YKhKYdQr uyMYHKft8mDDnRRWqHYhLu2pUzGoNwafihaKoqoqI5EXUSfM/r89352eTsgOVAwQhKMUwqPbPJru qEHJtebGrwWBtH6IZzSamgQHKKfuj3qNM40/29kTBCL2qadQFXTIFkoibgTDRY+OPfv7B07ybVUD jmnmCRIOeqYkAlBEguqCMVRSK53jzXkfvceZ6uNlG0oGyHKPtmQEy2+O/Jt0smgYEX5r5Ok6O1vg 7vgP1emKB74ta1rNlQ7WxJZ2hGojnJnmrWYTUeCrs1cRuI5mt5TPb15li01016t993vU1oc7T74R Uzp+OZUzHOmxqEKWGZC4V5N0g7APzseFERh8UIxRAYfdcWDkzSYi4iGY+NePZrvbY36oKzS0RXfm g1inNVkNUJiLMUGcUsgXALg/Xrr3175Ojvhvug7gVAMzuJSNhSZpKGzVBqJmI6gXCQmaxdIGLoeu MfXr6285+PP5v57XxPUfUS4cQYWuKsMdUBmEkhcEvVJm9WBmOImIV+e/F+PmutkeISJcXiGH1Dpl pjVA6zm8wmKcwCs0B6374/Dvfv8mvvz5nZJIFQfMWTeqhiiiKlL79Ne8KJOoEpKGBSJQQIg6o5SD KEh1jG9Y7z8lnl9EfXLJMPyoFB/KyoeBgH1/oAgVD7LzyNy95jMOe8ef2zejtXeHuHJDqGgegEEk bjgiSGFzUMHZ2DiQHk59QDQERa4lxrXxZLiY7iLO9FrbNmaQOhlCYqpKqoCD8EABRY+sUgGTQVNJ D7qJ+NFj4/E9HDo4igY7nd4hvA+26oLiHVfnGCSTUbIiCigqRDO2RyjwVAO8eaicwoKTtdQSSlkI 8YoMftQ51SGD49mHCYm8DUN44hUDEhRiIIQHdQIEX5uMd5v8hq8rAkBQUCnBAwae0OvTzV51i71g 5mU7Zc3F5OXwe2+ff5Pv9tzmPUXqDx+Vm6TE+9R+KLTWqS4moEhy5B0ogQpUgEiBnef31sr3fnl7 AlycqMcxyKCk5aAqH0etes3nA6g5PW81F/UHMCQuYg5ifJ514/Xuer8eODmEgSCdQ5B5ZhSeb9mj NiiYei5Zpg9QNaofMVqGZjVNzyePz88fJO9iROeKOYlwMcjiN+++eYebeMk5nfRYc+rA+h9nM8rz tXLFijFLa3EWXWOe0FSCRM3KFlQAlCy3I2MG9cx3mHGA2DmZQdTkj1I5uDogS3vOse/FjMBLE3UI liAxGCgwQioAB80FcmstaxaOptVDjNDLoKxRg6/Xz9669fH1n88jE7quUQfAUDwhBlPw2pdq3j1i trTIYrBllYyOnETX2FoeRPwHowcN2z8WRjSNOPiELBYSEq1k6v7xDT6p7t43MCLq6tup3Ih+Hq60 NcVuN3Wai7qu7bOstCcGvOEKOV5p9cXt3veg+T6fNPFmKQeDT1OdprhRJyzCI1OtQyNPANV10lKh euuip2UKqCyxjV9XO6TECKFTVEtGfcJCcyyiku6dP0sOTpTCJC2IRYxUEMZ0k4+W7hOFKEhQALdl QEYwMGDM1eSwuL3x2I54cDGDkNpB43TPExgrKzFlS8uRt0vnOT4rbout0GDnWxyAEHEGYtbM5Nm2 ZcrawUuiIE0n7kAXBSpwq6AqwGZy3whh1NJvvlEsVOBUujXgkopv4l6MBgh1hUugZQQGt34QHR69 i4csQzTijij6FLB55yhwvn38AdSHYlQp+VhRC7UmyCdeKahmAb7ns4PgWgiDEh9ih9ez49B0BEgD BBGBCJaqtKxavl0jd939jcry9wOcUqQ8h5/FQKIQiQi7TG17esVMb2d/fvbfbrxrT2NcJV7usCvM eXtY+QsfLi11uzHCSE4h4iKEqo35vVO868xaxJS+FyAFHxGdjBgY77tztcUmlqsLgeBQ0IK2FLr1 i076pjG6WreTXOQzgAArN3HYWG9anm71eIq1IU6GMfsDvjAv9EhklVCBF5HDe2xgX763HKCmDldg ADyg5CSAJshUnMKoXzE9DVl5FhUVpUhVwBhDiEB7Fi2e4iOI4XM43FTJ201Y1z7jEjwnnVpPVmea ytrPgxTizBjjVqa4h1yeetdbdkprgc75PeQTOfNnm+FZ7Xcjec7zLXfUzJ86Xzly2/Wye5rm/ZHT n3ve5Gl4m+aa71zSLUT59cbWdvPU75hjgyOjrRjlPWQ/4HE6PvwquK4lcQfGrm1OhK5NxhOyUKFD JlijRiSyw77XtnlnOMw7pJlucIEsIZGUAWMpIqlVQ3xfuQvu9J6nrzMRkpkEIg2N644RI+lRIhZ5 8l77WfOeed9vGUZYzDQKKdqvSXMUYRMFLABWsZy8Pr2hhYZnRcj2jYhp2bSJpAzK7FmZWt52e+YM uc5DlrDfWq8Edg+ApYhAm2LKDRZVUkKrMIwKhYIlxJdxG56ovXfwT3sYyGxrYDScbcRk4qvaBA4Y 7wTeBRmytYzvi1mTRc4o5xcu6A10FJNSmTMUdKwGwLpNoe5nNB4Cwgg7QYUayD7QbITNMQr0hAYT NTQD47Ym3aN5NekMEHfoyXJMn0745DiSfEchK9AIOEiUuS0t0QHFlVRSdQXaWaJSMY1EZJ7+BGdF 2qc7fgwizvG5SofDIUUidZj1kXpoPNwCjrtw5yaKb500EnON0HXHRXE8309GNb1844vIQarpouq4 qHDsgIrI0QPTJGwh/C1UYUhnAVCCKhBx0FRXafzWw/ZXT+MTDuKTNBxwlSiBT+AJ+0GfBnjz6e/q cHh49h2QipyEBK+sqqvUr0tC928zV6So4uHdfmGG02SiAkoQINJEFNURCjUS+DTx1Z3FbzWI6xyg nA0uALgxFYxlJmOfmfnynfkZ2FSLK2AECszqzSN+uO3Pr4lUJSqksVUEFlWyDooIwBAir5pNHzCO tE2lequ2vr1+bFV6+fr688eA77uUzyj6kGIMEwfZYvnWjutWVEkzKsVl5GAbfXPJVFakkkkk3CIF Iw4Z7Kvaqyu7EeZJaw5KZcKagAe9QqjwsD7CbKhCrr1+fP51fx9+/f54PSePN/Cn0kjJCCxgKoxI iiSATJoiGdaKlln5x9/PW3c2m5RXBVFK2FyhQIiaKDCQEhKTFQqrjO799KLzqRUbNFaV/ZrG9u5r 3NupwrSExmZnO+GnOE6YXu1o2xTawyn573Vsg+W8z321Uc09ajvRulL0fznszIbvmtPN898DRmY5 nWX2y+9d0ZmYz8Jdc71fpfSSc53K2Kz5J9xuZmTZGsib8lnPGSsL0LoCBpm7QVI67NFqp7ZpDcBP DVfUgotW7q9mUgrdpZ6nm/mO6dHGcoxZkTRQEIECc2iQECYqqqc4j1nvrqPPNz6FW83nZ2qlAB10 AAoQO6qpA3R96zfC6jXCrYlVUkkFcABcOrgqSqqMWGu/I68zs73G2FOCurF3cFSpNRaJWljWwpOi hVACNM4AmCfEQhWJoRItJQVhAIAG0FMBPPcaHtdLdu1W4IQrfy8ao6NvR3MGYMiwjGEhKAqGhofN PB7bpEZnDXBgvIKhQrFEYplqzhXAiMiWGxOo8IbWbgIgoQBWNk7kcge88NxDdyOGHIWtbDg+s9Yo LyWhvz0OsztH7I7wKwQr6EP58+/fuobEwTME47AVQVRSvladZtc64adXrOcMJhTEoToYh7ACEVJB VV8xzD2q0L78pa2bBRabQdCur1jGS+Et3Ods8cC8gpXCcQICGcOVIBKqt+m3bvSrvr3yWqXBIwqj IQIVJYqUUhVWl9ir+ZO9dGXiMnQB7UIPuzxM1KjVVJUv4+8cdcsJIDNaIiUq7wClcrrB4t3uO2ti 0RWytgATsHcwio32tb3BjW6CtZ3CB8JRbiEZKSSoOHr41+VUdrPlxdrqFypZUDBQpxqazU2jfyGN 4veZHNXrmjt02jlejGmbtDFtePN3utuWWBYrquGGkxO7v0xm9HTJLXqPP0Iz8rec7ru/PzkdSdZv 183qW2+7veaJY7je393py3NwL9mdbjTiL49vVPN8ynNSPUXTPWQbORci+qqe2oTcDQ/E6JP0nkT5 mVsiC04YH4bFPUCAo4ZVVQCpPfMbo3LYGFFPEuvSIgDBhhyVKirMaddwpYWXu1qixUkh7V9qFJjF VKfrfk5rPz9731xcvpSF3UkqAjTe0sLLqWMb7qIXwiD0K5cqpKpa3nscex9lsbnXt7ePe9PTIpkA U8wr6+5JegRhO7jfOMm2vPgTdNkAU2TMBzNwSPXGfnPHp+oVRSIBkj4bFBFL39VKpSY0oWhAVCAE wmJACMAlx21D7sxk15NoXlNspUvO1+fHrraGdV7N5rmxQwWGAMcQgW6t3wnC5+/CdGF5VD39opfo PEjfg0E9mLKFYVx+Wlfh9X9+tKUXzArrSl186h3YCthY9OruSFVQvLX65OInSgDBiFIXCgW3CevX 3wUWorQgKq2TZRB2zPC6PMhKv8/PfzW+zvHY3o/x6VcGtI86cXWxde11ZfG8r6tKEyVbgAhmVTUs RNrw802FnDKijV4gQIiA+4YIAjCIgfhlkvrvrFt4XIpYVUrhWw7Fit+C3MS5KPvDSOBEpZmwAi9/ B2nSMfmM1rQBED9zcFZvlCDfAnAHCOC6OqLtPydTvj/iU1GwsiIAgSwJsSRGWK2o+4O848BO9Ciy Oav1+IYc4JybzYdnb1cnR4o19bbd7mz+5lveHu/nV2m+9pQnyFljtVSS4tTJ9ZTu5d3MwkfC/uUm 8w+c5aZTbe68tnut97rjCWz32c+vwy3NZiN8R/ynzux6HjBdditGMZRJlQIVDKpBvbnKa+RewpSo sgACuA6kuCo6PbbN8+RCzgyioDKwKpqs5axXPdrGyKVukMLiA+SkAy1LFpt2tp2tmedr1jmB0dbM m4nTuHRVmOa1LU8w93Ayr5oLgVKlO5CkZNgT2HhPoqsb64uqsjWPgDzejRWqo8s7ijXxIdrudW0b w31KK+vFUOTQOxw7Pvssj8dh5sYxh4gpmKLdPPR6+vXR1jnFG20514LfNFnrxubKHcBIRRDPicdt khiY6Q9kJivV8T5UfXvrw76LIGJ2SEByF2KUHsO5joFSt8suL5zDvFImyFVS0QXwLYBmQEEpTCfX 9NTSXjD/dtBhO7Xs5/PL+CPlPYhVXmg47DhFgoK97hyLL1FvbCLpQmosECCIMUcYz8msYCqrrx9+ fvOptVcnUASRK90iLAkiBC9d855epWfEBoTVVJJVVtdD3eAHsVBElqVbO8z2OrNmlanKZJBRevQJ MJSKxVjsq48nmGqi/OSokhU3yQS07d68nQyJBUFATkv3TfdWsJd+zXAGIYIKqmdEoAVHivB1Ukgn vHT575d5k0IJU+w81tohnr5FbuW9ngypmNhXUoWJh76ly04Srg71V6YZZ6hf5GNw8ZztuWNh2lsS hv5v2ot+LY5O27lm3vu4yFZ3+XbelO13Pu1547m+O+q42fc0jw0V6JVH9XbTg0vLoP782mqToge+ YOtkm8AZ6DaiK7eQJjARkV1uC+9jh2SVzK+byF5rVMRvaESpJVYQwu/i9R4hFKWRAOXhCAVR6VMu slZP1zvuljHATAzkPAxKDu0V4uPIymoUpawBwqMIGCqMS3uvfVhOnfQuznKZQkDspFIRGqGp8/eP rrj1n3vtGST/Mh53wkZAJCC4sEsWxLEvRgQua+B1kxUKD5o1ikGIUhtkwLt9wzdXvhqwPwr6DjY3 nH5RwR4xVw1+Z4HgmTUetr3cGsT33HjcwU4YJZ0bXk0c3sU7b0YAV+Nzqa+AKW4c+Urgk8XxjC9Q Lh6HXbJmvVSWoxFiwS6pgMgAzOJ8Rm+dY8EOtrDsmZtnfa47MSGaJA0vNHXOS46rSIsiAITsoEKL lG+SzYz658Xy+fXnL64On1KpydmA8pCimSSHZSFQBQlQpcUd57qnOsnUOs5A6D1X1fnXRjku/Oye QNAh77ZR62SlN7KIzhrvzegWeggNgHgAtBBRC2VG80+JgbWyw3N3tc1l1RS9YJxiNPn24uCrgpi4 oo8+t35rnPrnOU8jFGgqAUFEYk/hPkiY69Pxyb5xtvtnJgO74+COhBISIgSCEsjw0IQ0MEPBDBeF 4N6M2foQ/UesH10ZTJJsczUBsgL8LqqqtBML3Cu7+O3Q4L0KQC31ooQCgMJFjISi8V8f1qgjeD6/ XR33jXAbToTHZ+XhElVJPvv4gxx5D8a83mYFrkaTsAoJlQUIKAMSksFAJJDHOjrAs+/4c7np+Pz9 y4JtEOgAK5963Rg4AMSKBQ/tu0toZLjX4aLvmCfKU+YAQFJEBDAJc51ljl7vTTYdVvcR3WzYCB2c upKobdT75wXv53W98hEXbuwK9KMZnEbaDSogHYBPu2EwkIyKgi+35P6fHt9vf7Hv9vc+nr7D7yBT U1RLQURKhEsRVFByHAiKKSaEmiYIKSmGiaAWZKVU5yj47V93S2s1EZsp1SHJd8rbta5706mklxCd IwFFdgq11KxuvOq9h+9170v6F51b93o8u4bnJVj3xhK3ru67mZjvcpJpW96ZfSojxojNe6JtWHpz oevbczsJ7l+6uc0x3MRORPbmM7us5lXjybzO20tR2vdhs0ObwsKJBrl9FMxCmtRaffnPoTAJFa4/ B3znbnxfx5N9dxPnyhJJIhEYwipEkCooKVGhCIhgYIIkpQoUBJBAACowIJ5Uz1PGLz1uzQKgkmjT Lwj1q1pWmyjwMlx9RANhAOEICQAg+PAk4BVcVtaHp3781aGEVSQq2ta0djlBqkDtEFh4Q4cke8PD XkxnOlqeKmjcm3VPB2EpInHd9BwK5YA/JNHXLaz9UYDjB7fmLjzd+erTui2RIWTVMjWS79RsxSji LzGoJoYhWaV1GQLunDBbpVKcHnPinGvXje8dQLiaUjY2flIUDjHU+s9RR2lO3WIdTvWKByDzkTqQ pCIFoyAKA9IfPihTuBgOnPt59fX2KoQPR3wcfG382n9b/ltwkp45f1sY12tqCyC6MSajCbYByCM+ 0k+eu8LC45K2io9G3x73qszRT0g0hCsgoQpF+d1PKVkgJAmRVBkoFAa63h0ebfHPk8WW6ImgrEFc NOrXuuo0eq1jALvUedU3vWHtY4StGw6FYGx7dqyNNCu1oKmwA98CMHIxnGsYxxebulr5VSD4pjaV WtXO6CsxXyfWuWs/ZfOa5mzLPNmg3U4eVpUVtPE+vu4ir613umE3fK5vpjrx3Wk4ovg1s1cZeh6O h1ydvnPZ3c3VzFa97kTV576JhjmPClrcedHpgqN0cW+V3O5g3xM5LK17b0dYrn1hvd7nMIiAIE6h rXDPnXHv1q9h3aWMKxwc5gvL3vfB7zbB9RBrsiEIAxvWS7xiF97t9CaRBeWkcZiCcdy9bIzXO137 YXyFUmcN0gPbRrDy0mmPfXvhEmwYk6w+s5jnHXT2l1T0Tblp0e3HhM11CFO9ssXONhYZFjz8tnLN 68seaS6GqfqeYXM9ENn3t3XOvN3nonCSvr67OESlr2njRKI4zUynn7SJZotxSyvqdHrlMtSNE1mG DxzWdRPQl8Rlk7LlHh7jXMpm29mEzfd+1uuqViV0Hy3tbsdD5uc97XLsKN95xVYlI6xVjVxQgv3j DdHUcl2at78T5kvpz6Qt8jwOcidtrRUOqZXen9DXMPmszPr7riwnA+Y09ZlbxkkNpfHOYXhWibCo QBszMTUazCbjWVa9bd3vlJ6OZvjxWzGpnzxku8czQfwnbaaO1D7VhQ6szuL7vcrD89nkZ4wrixCJ 2Glq9q/FPLl0OlnfYoTqW1xm16JHYag8SMmiWzmp6UkkEg+h69rqrSxHc0isw5yDznuKZBHarWd6 Hr3HNa4Zmdrn3K3tM+7xH2Z3UCo1sPmHRlHldcbIY4Ct1RgWUy8t0cOed6j8zD3x8nWa6o5BOnjf utMV5b7zXuGPNcUnTmR02ITasyJU0W5zgUrrvaTXGcSyLmjDk3U3nl7Rduu+pAvl5n2wSOrDB/E7 qFhunS1EPeLvtws9ROwW1N5b3M57FBKi2rm9Vru4m6jD9AoQM7lu01xlZms5pW0nWrsn16mZrvtb neuuV3wuY32o9Us5nkK4uDZXfW7MFhoppe9a/KvXPI32dLqJFgr6MguXG3fUIOejzrXWzKV7Zp+b 4ttQZdqukf1795Xzokc9n2uRWcnNmhZ81Oqies25CBjfPOq471m9mgoczvnIVRXGZ81ZYafsJYuO 1vuVVUL81uOla46+ETmuUHDNevbJj2o3Inu6bNCXJ3wQnL7W5Qbe9trUXulnzaZgvlC9ZfF7ddZb O19tYnU9rqcvaSzRy+99z2rYSREdqu8REWKuAt865St+8szzPPe0bO+V52GTzPl5tXyufdL5M5v2 u1lfZrfO+Cvc+2OttA09yb4bcm86QV3sbYP1GG96DJXdQvkcbaq4M6pSmUzUVv01qUncisrM77e+ 9jPYTcDOVgtvC3tmVVVHREQKd+9ve85u0yhVNO7NDvDvrWtazerueVO63VLaqqqrszMzMzZl3d9a 1VVVVlEy7szMzNd6uquqW1UKqqyJ3nNa5rWs5ZmZlVVrl1yqquIhJPOazzXNaznlVyq5VTOZnMzS IzKo3vec7u7ttPp3WFUmZd3eESpmZiM53VVVVVVVVVU2n0785vXN5zvOVVVTSO7O0zuIiKRAiIqo pp3Zgqqrogd3Zru5mZlmZmt3t3REoOLrKnt9Oa7rprunrrRn03nkOs79xPFL4c9746571V7x3q3u W23eJVjWtcveczM7Gc5GUV9nvjA6h5HHtt27pHlf0VrlPmNSvard3Lb5W99lkX2WaEqzV3r0Iyqi dzjhy9mG7Xt9Vs+7tihXr9GtajeUDPr2Que+XVdeRyGn2V37vtbje6bjMgm967fqhYZhNSMmPb28 xtMt73M77q+9UFucX19z7k80u+b5Dd2quwfOklOkhtOu+3cXzu+1vvL9zpzz0TqYvPvTL9896bOq eYn089mRp7b3k1fquKnytmLlX5yHwYpuxG553T2iF9avjoof3o6c65spsADEEmQcSzMyW7rxkDkM cogUl3VcEjXFCkzKqHdZlVDipVyyoiJSIiIrVLCy8ImFIQkgsRFTnUAxLz0b3r2mluWs3nY5JKVM 1e495IvnJbkCsc13fhzz0Drl+Kb9td9QLZXmd3EBNZF7cVqdQc2E0VqXpHYcXKLeUbW7W9thq9Gl 9bC9y+tMyM1bn1DVbas1rx8beN7jRVXi2vbc03dt7bNyPLexHdzx7C3nLoJfhgeoVenp50lVFo/t 63xde3POiwStD2b8ud2iyTFsXcnMHT9OWBu1jth/M3u3TuZsL5U73izWZDaaVBnLzwHvcnuttcT7 MoZV2y3qJPiU37fUR8jPaGVC8umZtLGYVEZOXN1vrK8rCBnf3To8S7WnNxu8943VFXnb80Vz6ed7 tEWumzM8jcb9QDdYaSu577XtzGa94JHNwnGW9ddORUN3OX0vk6PLgW13kv9H81B+3unFARccew2z bJKm2paWLz/LOfeudwr5/lmgu5g0bkwgjgjHhbxd0mV3mNhM9REzqsFy1obIgFy2lMyF/eMP1xEf XHXPxLqYbJvPFWVXAzsrFxYMLioxXNvWQNM1CiglWLiwcifLSMGmJhzJo05DR6soHc+rl8yeCN2L U5nusGVJ9qOViJUB01BURmO+4IyVKaZsWBj3G5KTGGliLPsxwRJ9UZbXg0TCrPeunPoqHnZOlUbY bal4BcZ5AGQ2JCD1paumtC1Vhy9mZmhszMZHhjG3ANUlSh1KhJTN4sIYfjyTBk01OOaHXnrM6CI9 KGXL6ml1EwvDPLDKWP1LB7PMbhyRGgeqMX+QHA9jkMruOlCDBVaRZEJEYQSVUFwkPIHpHisf1aYq 9iCaqm6ANQw/0A0HEYQ9UfA4JBCaEoMr2/GZqtFDTwaPkAaKeBMqFHANB+4+gMW6A8A0K8BAOiB8 k5RElVUR5iGj3DxVUTFjFDp01EX9XkXWTr53YF12dQwF/tg33brcyoNXSjKtunXrgm31KDrED1TZ huv02uGd2028tg4HZlGmtdfckkyKpXOWT/BNhxEftTCZxSP9CeljKvVq/zConU4HmAspylIE/UAA RAUiyy3b3Yrfs3FEFTL1QGIBLSlaMKP7aobFj7MMTbZr3ruYzYLcWsQcqpK588ur0ac57mCzElBk v1Y0pKJnp2cEpmPcYtqD4eUyATQIMqgY/4lTzUOah1y3WAIWJ/xQAZYMUMO+g7T537cewxNLFL4y wcnpWrPFbN3edSTysN852Y6XLQnR4S9q/aWnq7acSvbjNgxpSj50NT2E/ZvPusM2mylZU982l2z8 pWs6hPbrntHo4TmI4iMmq1MKkdypjtdtc90mso00ikez3J1nrLnTue7gX4c/4tPyecSY6y5j5aeV kOcoX3IC//Qk+fe1I66lyWZaj714H9ibqSfqCzMTzp9QHtcY8xgXmf6jNC7kAnqpziVYX2+8eIEs lwcJsgAoMBnKE0I5xt61r5Dc94xZtuEqRnIkACv4AQAKn93APhDAQJJ6/DQ+qu/MeZjWyAcIZgTF +PN8tNO/DOT/aKf+HVAU4IBv5D9aR9kR6ouvP0IApovX7aIqRiKJaGqGmgqhioi+UUlmEMFUUUhR RREgEU0MEyLRMFNDMBVBSETlEZUjEUyQ0FCkNIhCC5KUmLZGTCZMg4qqlQVLimWQIy5h/F0fmFQ/ ZUPNSEicucN9D5Jpmlw5cufgy64uCSm8bTkiZv0A+ZIA8Aw3w2QBzxlIVrfzmu67zbRD1rumUcb7 7GEktVLQSRqqtO0NDCHkNApkr8+2IRALkhwkPnEqASCB845ydc3xvolfO223ABqDkhyEMqamc2qS 7X70Mv+zH4+gWNvDXZ9zqW7OR836Pz9O2QpfX83ra/krMCBSpF/6KwJNb00v5/N+8L93e+bCv5hA gxWtI5/NKcnWyKpeN730udWrU2QMEYhCyqUG17nJta+DHXS2F5+ZAdHcgqhD6jPG4RlNaIERkViq GU5c75Kc6Ig7IDgO4Vcd9dZxW9K1Nl8VABxMKGKAo4gDRV6jLfcZeKk6IiVM1dyBXarDOd+dQklC lPJbrXN++sDqktO9VZY6qOpxybPBc0y9ae14Mwyz2I3nO46vio6Jik3y/W9Twu3h1q5el3FczHGz S67xBqUzb1Z9jlRGkY5zEWm80qNHK5Y3soNRtlZ4zvmm8u+I3a10LPtcykJms85CT05DMX3fYhtY S3n8qSqiqw5M5q1oGadhAMhAKqFBMEHZzrvY7s2dQ3TBsZhSE8H8AJnQIQglA0fryYGnz6eW3ufm ufPIYBOa3UJ8SEEKwjKXr4xbfVkvgIQpIprOr3viH2tSD/Uft8AGSEBKIaELCJJ/BveVzjzL0tRV FgAUIQmnIQP1fvMyzm9TXQ3adAfgfon+EWHM+G5EfgA1YgEiwTSABDABShfCBYJEJMqQxESTSUBE QzMsQQMTEwCECQqR94P21U0VMTO3hwDlOnC86BajDiZYjxb8pn0qZoGBl0Ul9sG05SqrNBSW8BXO udb88zfOZfGvHAtZxaGbHO07eEqmhgRiR+cFuIOKKCqbIoxn+KIgqQQ1qvMIECW/F6QtmNR++1lX YVNEQGhuRvVYn38VQdEb+2LEBUAQHCshX+YsoEux4rV6ICkKQSeLhKBNu/QACAazgayvAISAv+oI FbyjObd23Fad4ZsED9tLokEEklQgSJCD6ATF4AEkg1tLfOQ1mlRVRdERO5hg5Kzdz5PffLwbQ5U9 CpEJVkkeffx5+vX3N95CcoplmJJ875Xb/tpvK9CthdEHbMYluHlfMYzzo7GL5AAHiAAYgzwOysOX lfnfUadPZgLoAAMIQShEURJQRBMU1E0lNDSUEVBDBQUkElC3xigvp9Or7uyMXt1LPWtmEMVqCbBE j0PGiEeESDHvk4s3mte8smECYXBQEpjnGsa19jSAFCGflHpvgcbbri+VJagq9loCOsNP6b1r8brP 56+0fcRqFhejaXnSa9zs9z3U6S4tn9cRnKBluj5+uIbenCqO7Ywnl7futute3lORv25KHZ5WuSc4 uojKMfZiLT2UL+nlJ3i1nQ7t/U1d95LWT3g7773L63iZ0Pmki/7BPwEqgT0Y0PD8dmF/b618375i 1vqABEGERPuwsYxJ98ERjBpjk6GwuQiXYhArsQfes0JrVrX1e10H1sOCHVX7rQ06uy/e71FvgwE/ zoH+wUE6+d13nnOpeVwbnNrO6GOOvPZ+84tlptuTxnI8/UBP7ADwHryqQKHmf+wRoWLAUIBet71S SQIgqJkiiYCaImmhoIgkiKAISU9H9U/HvH3I+2Eu8c4cy3G03eG48NRE6yuGlqfunskP07P5z4/A KFkkYgoQmJGWSHTn8H6VK1V0ecwl0x1VwIoaqbsvLHZVb9AqpvKvN0sYmIbDHDn6EMSxVVEcI1Co uxSF8KQjAzXrnj+zxtZwAEB2CoBOHyqOgQy/WA3fyqZIgT2SiYC7Q9PRJ4rMOP3w5PjFNkCek1YQ ECWWDD9ERCI7oP81gnYv+pJGZTnRsxz1/d29K4u5I0B6URWJIVZcv7Ja6pMURBm7OCdz+ecGeq1h HH+jGMBUGf0R3BIEvOddTx75q1jgIPQjMTGnverwuztmgoUsiHBCsqRCqXXEfO/YYtieHodkDome McH1TEZtJqDYllBOV9y/0/G73Gf95a6ADo9hGcwUU29OWxDu+uvOWwCdjjMCNeebau7bzau7r0qx vaN4QxhT4LPCMdiLdVzDsnl8Takp9wWnm0TIyfPA1rnVIv+rvlJ66J86t8rXPh14bJvVVDJ5kjS7 1O86t1vO1Ona/ia7ls8SXiOMdVfzgM7YvW9b3TpE+SYe9Rdcj3vafNrKd15s77qXyarq8TLFqfm1 sCqoxydHLV29T+k7MqInwDf33AJFZQN9n7v3ZXFft1P4QABEGgiRIZ1VbPTpcYGI9+Tb34LUABuC BgIjnwBGDkuKSv5mw7vAaW2LqSWAQAN2WcEnC2hGerLXO88VbZCfwgTXRdXaeuT1jWl17kZ8REwp VAv7BNABL9pwCEgdfmH379fXPb29va6rv5+PMv1n6BHzihKiqiJChoqhiSqVoZkIgEoAojAhIqBA IhIK+R7qsLjgPWHg9nuTFTMkxQQTUzQUU0UxEEFPWLkMTEjBVJVCMrk4EQlURRJ9j9B6eT+uGmmv eU+1uNqhaAFrFKfgohy85M2bQNj1S11xV8e7dTI1Megn1DZ+CTWI4Jp2V6bsB2XUJr7fxAXBEohA JCD+I+Iuf5DbNEOcuqv+IE8eW3tUBxUWsOYrSmClykzPyCfsggTPkChKDshCcgoofuf5s5bQSfx0 sdCb1ZxTNTXJG6UD+a+fwEQe79H3kV/vlNAOv8CGVP4x+Z1/T5fWfdiehLXsAWfKT/MiHLrX6stG AaAGj8LYYkc/X79pakTNB+qCKvUQ0GU5lnNc5N5c/WFs3VUA4h6cOSM575Puul81Dy2cBQqUVWCi 257tPUhaL0D1ATfRd/FYBuCXga/cGkKgIOWYPhQoO2131PzXlq2N0RfdBWARZEHwiB3AHADAvmAe GPZdhbqFlWFGRZkGiVQEEJkgOHIMrW1vmNiPl+t4wLPu47yIWGvJO+PMyma8iuWfFvM0u8cmuYM9 jw2Fwuue1Qvbb7EuulWenXX407ejmX7xL0jvaLmPVvp34bKJeqp2TrJGl1vdLnVut52iprkCM35e 8nb75Hk8mq5KtLPXj7rnP7fDL0s83pUgI+TEIgLZ1d9XzQvk+I23StL+7S3pYfxGBOV/h+v63/H8 G+ZwCD0E0Gwi+YGyeB4yaaGOHl28+zwz09kkArcL9yiA69FHj55GMdJv3YeOOvZaXdmmaSblFOCu qoSdLjrg1Jrhv89La+mvpnof8BxT0dhECbRAOjoDFKISdqozeP77hqnLv+kwgC4uoGogBZTbLDcQ 28N2G7dWu4m3w7+Y7Td9QqCCroIE/WLunkGZBCl/x9uIa5x8VFiBoJj6ihBsAPkzKH2AuSA+qCHq o80uCCLYAAoT2+DQgQgQAkFIQQsKkO4f0wdgj0nKHHAKFXrAbjhK5rGCHHAEthAbdPH0qs6lAZ4A XGML7FZymWJeaDXmGJge11X3VnT1wlXLbFcUsMV9aqZBZvYy8q2MMrNq2FjJIESSZ8b767162noP XfSq9uxiCnPLwVfrVIgz+x/nPeDeVmg0ELM0TMqtbXdBHs4OPzdhaIGZpRXaetSSE7c9Mctl3D24 a3kD0bGtEKgKklUWHkjD3PrCRmOwzFivReuG3y3S6Fv4ui/yg349ihIz5iGLjlMdxsLAEjAECEwz 9hVBJPOu5+7vnL0qmESshlgjwJtCGPMvS071C2AA0A5CKj/1govfflI3vcQx3OQscIOtIyORnuHR w2WiJGiADogfAjudiEpe1zq9mra4A+FmPgMr1uWpKJfyStp8Dig0qu5Wb40er2oSF9O6pT+mTzSy edmI1D6yL1NX8mOZl2e0XVSmTVj2fHIcUr0u/UmtW2m3Oa7zmU1K3uN8POZyt7qBmtZ1mVSeShy7 Jq931uvEHem77FFobI0lNGu+3ztTORo33Vos36beeJmOhn5eaeCCK5xkXUeD0IhTzidk8jecNur2 Y90ExGqJZCESzAiu881331HNaaj1z3qQGzslUQcBGAUh7GJDlfY1ubLaUDjcK1gFQAdFEYMD755n Hep4fS3xK3uKZCdlECsQeSTD2xbG+eyvcKQPg2ECOANAoAAhLBIQJ9sxmiUlpAH7vL4zCL706KFV Rvuvvb8778rny/r5IOwgR20FQDJAA/cAw91og93wp8KWH71Pj8RxJCQ4jcXo2AhiB9vzS/jEU+gM inBD5IBnKqZKKaaiqqGmmimIoopKKKKiGmqCIpKqqpqqoooioiYqqqppqqpKqmhioqqimpipYqqi KqqqCiqoKKpqqppqmkqioiImPzf2SUNmhCyDJDBQUVEtBFFVKUtNNP6nzqokcA1IpqpIIgmEooKW Ka3a8DmARYeg/AH7VHsGAeATqCXnwGhgBefGqI/iRRNVTPIQsgh4Ve74BomIIaDgj/8+aPqSfl72 3KEByg8iKP9h7BwqcAH2IbBGR7r5S8jMgkTKjj3t2cY0AcY1aigjWYexPImA+S/3vm0RUNBRQQSz 7DsbNsh4MFSX9Kgjps7A1/v/2nBRQ/Ii4C+VFC8lTFdqopoNyxAU7BKNHcOKPePDY+KrqJtBOShv GImQhvFQR85AIfAlgiSMCIQCfVRkZX8HgM0BQNLSR4U/vHDEOCrQwvQXuPBHFAf2gGIKBqOwVQxE sCpl6eksq+CI8h8xDo8DjgKFID3AchVDzEUsAQUiHFRTeKeYy18J5r9wPQFBA+h+mokiIqqIigIi KiiqapqiqYigqZqYiioKohiSIoqqiqaJgiI+BVDVGAChFlQzRYWBIpaYhmIgmAigJUKSJAKAH6LY NJBBmZhQUuBRSoKLgCgoWYhOYEkskkkRYQYSUY4OSVQEQUhEDv7hvOYF4piAQNSlIgFydgCwbCEW I2IbIIWhgAXlPAp6AD+I/WoWgqkCX7RDCH5h7IEWCIkN+gAmMUssFM7lgn2AQX+UUbG8DYiClojA BB8o9jADckFgqQNghcI9AHpku0ZjoIhgCgQRigKaIvcqCPighkY7BUPETzGyd5ti47EotOhu5sBx XzebkG0UO4PYcPCIOCykh8npiKkiIiliUppCJiYaKiEliaWWUGSpKSgiPqHQGCMAdCfuJagKWKbB 7dgVbUSBu9JBUwTRPmCr17niT6M0VASOSB5ZumZuhjJjRJs7Blj3+v6np6OnO2awo9h7LVYgmBi1 WBiI9KHdAFMlUzBuC8BwQQ0AAPRwcATU8nYhsVBHQwSInlFZBPRdxBKKBzETIqdfpoSx8cIIdg9A C5D8AQF34iNbBxKUQfZrvUH0EPyVxAd5w31lVQVGCqfhyTWcwawpWDc3dq2tQNTRMmjd2qiJY3F2 FzC2Z3c0d2EZNzcTU21LRTW3BCm1F2dJE0lTHEzdZpKWQzc3dq3d03SzUUzc3dq3d1ZyTcXHJ2to EdljNrbS0CFxXNJiyIrVtcTUTSWUc2tTNs2wXQHFSEJ3bFNMcbK3bcbdqZFiVNLa3W1nSkyinTYk GtpxzRLNddUbZSK2oNN3aszUtYzVcWSFzd2tNXE3dqHYcFmEsxCrbAZx0Zl2SgNm3DHdtGYjTdNl 3cwKStwtJxaMY2yUTW01pM1zMFANQFAsTLYw1JNcNQwUyRW3ZaFyDS3aE0Fm2ichwoI3Y3WFB0gk x2N3WVddhGzHEUTbJnCmx11NZhc2LNLFCZosXMFsosly3MU20jJqv6xUQT/OFT5e1BRFCQySwpER ERREIUAhCIUCqGuYCdyilPe7kA4D3J2Ap/8XckU4UJAOtS50 --Boundary-00=_5mARBfai7A4iOym-- From garzik@havoc.gtf.org Sun Sep 12 03:00:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 03:00:15 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CA09rj001233 for ; Sun, 12 Sep 2004 03:00:10 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id A9E127440; Sun, 12 Sep 2004 05:57:31 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8C9vUMb011818; Sun, 12 Sep 2004 05:57:30 -0400 Date: Sun, 12 Sep 2004 05:57:30 -0400 From: Jeff Garzik To: "David S. Miller" Cc: hadi@cyberus.ca, ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040912095730.GA11484@havoc.gtf.org> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911174535.2acbb957.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 8660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 837 Lines: 24 On Sat, Sep 11, 2004 at 05:45:35PM -0700, David S. Miller wrote: > I think Andi made the right choice for his implementation. > And frankly I don't what is worrying about the > "-1" return value, it can occur in only one spot in a very > specific controlled case and it's behavior is incredibly well > defined (if not by accurate comments then by the code itself :-) Not commenting on the overall issue, but just the return code: We already have net drivers getting the current TWO return codes wrong. Adding one more -magic number- to the mix is just plain silly. 1. Add constants 2. Add clear, unambiguous documentation describing all three return codes 3. (janitor) use constants Lacking #1 and #2 are design flaws that ignore existing problems, and create new ones. Luckily #1 and #2 are simple, human-friendly fixes. Jeff From garzik@havoc.gtf.org Sun Sep 12 03:01:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 03:01:35 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CA1Ucp001428 for ; Sun, 12 Sep 2004 03:01:30 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id EC132768D; Sun, 12 Sep 2004 06:01:14 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8CA1Ea3011937; Sun, 12 Sep 2004 06:01:14 -0400 Date: Sun, 12 Sep 2004 06:01:14 -0400 From: Jeff Garzik To: "David S. Miller" Cc: hadi@cyberus.ca, ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040912100114.GB11484@havoc.gtf.org> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040911174535.2acbb957.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 8661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 345 Lines: 14 Oh and update Documentation/networking/netdevice.txt. If people are going to screw with the TX path, at least do it right and make it non-mysterious for everyone else. See Al Viro's Documentation/filesystem/directory-locking doc for a proper way to document a locking change that potentially affects every net driver in the kernel. Jeff From ak@suse.de Sun Sep 12 03:26:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 03:26:38 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CAQVIH002398 for ; Sun, 12 Sep 2004 03:26:32 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id EB408BC3266; Sun, 12 Sep 2004 12:25:32 +0200 (CEST) Date: Sun, 12 Sep 2004 12:25:29 +0200 From: Andi Kleen To: Jeff Garzik Cc: "David S. Miller" , hadi@cyberus.ca, ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040912102529.GA27096@wotan.suse.de> References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912100114.GB11484@havoc.gtf.org> X-archive-position: 8662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1976 Lines: 54 On Sun, Sep 12, 2004 at 06:01:14AM -0400, Jeff Garzik wrote: > > Oh and update Documentation/networking/netdevice.txt. > > If people are going to screw with the TX path, at least do it right and > make it non-mysterious for everyone else. > > See Al Viro's Documentation/filesystem/directory-locking doc for a > proper way to document a locking change that potentially affects every > net driver in the kernel. No it doesn't. It only affects every driver who sets NETIF_F_LLTX. For drivers that don't set this flag there is no change at all. I wasn't aware of Documentation/netdevices.txt, but I agree it would be a good idea to update it. Patch for that attached. DaveM, please apply. -Andi --------------------------------------------------------------------- Add documentation for new NETIF_F_LLTX feature. diff -u linux-2.6.8-work/Documentation/networking/netdevices.txt-o linux-2.6.8-work/Documentation/networking/netdevices.txt --- linux-2.6.8-work/Documentation/networking/netdevices.txt-o 2004-03-21 21:12:11.000000000 +0100 +++ linux-2.6.8-work/Documentation/networking/netdevices.txt 2004-09-12 12:24:02.000000000 +0200 @@ -43,8 +43,21 @@ dev->hard_start_xmit: Synchronization: dev->xmit_lock spinlock. + When the driver sets NETIF_F_LLTX in dev->features this will be + called without holding xmit_lock. In this case the driver + has to lock by itself when needed. It is recommended to use a try lock + for this and return -1 when the spin lock fails. + The locking there should also properly protect against + set_multicast_list Context: BHs disabled Notes: netif_queue_stopped() is guaranteed false + Return codes: + 0 everything ok. + 1 Cannot transmit packet, try later + (usually a bug, means queue start/stop flow control is broken in your + driver) + -1 Locking failed, please retry quickly. Only valid when + NETIF_F_LLTX is set. dev->tx_timeout: Synchronization: dev->xmit_lock spinlock. From romieu@fr.zoreil.com Sun Sep 12 04:08:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 04:08:15 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CB89EI003610 for ; Sun, 12 Sep 2004 04:08:09 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8CB3Lvr021326; Sun, 12 Sep 2004 13:03:22 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8CB3Kt8021325; Sun, 12 Sep 2004 13:03:20 +0200 Date: Sun, 12 Sep 2004 13:03:20 +0200 From: Francois Romieu To: Andi Kleen Cc: "David S. Miller" , hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040912110320.GA21197@electric-eye.fr.zoreil.com> References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912102529.GA27096@wotan.suse.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1471 Lines: 36 Andi Kleen : [...] > I wasn't aware of Documentation/netdevices.txt, but I agree it > would be a good idea to update it. Patch for that attached. > DaveM, please apply. I have modified your patch so as to include a bit from a message of Jamal on netdev the 05/07/2004. diff -u linux-2.6.8-work/Documentation/networking/netdevices.txt-o linux-2.6.8-work/Documentation/networking/netdevices.txt --- linux-2.6.8-work/Documentation/networking/netdevices.txt-o 2004-03-21 21:12:11.000000000 +0100 +++ linux-2.6.8-work/Documentation/networking/netdevices.txt 2004-09-12 12:24:02.000000000 +0200 @@ -43,8 +43,21 @@ dev->hard_start_xmit: Synchronization: dev->xmit_lock spinlock. + When the driver sets NETIF_F_LLTX in dev->features this will be + called without holding xmit_lock. In this case the driver + has to lock by itself when needed. It is recommended to use a try lock + for this and return -1 when the spin lock fails. + The locking there should also properly protect against + set_multicast_list Context: BHs disabled Notes: netif_queue_stopped() is guaranteed false + Return codes: + o 0 everything ok. + o 1 Cannot transmit packet, try later + Usually a bug, means queue start/stop flow control is broken in + the driver. Note: the driver must NOT put the skb in its DMA ring. + o -1 Locking failed, please retry quickly. Only valid when + NETIF_F_LLTX is set. dev->tx_timeout: Synchronization: dev->xmit_lock spinlock. From romieu@fr.zoreil.com Sun Sep 12 04:08:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 04:08:09 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CB7xxM003603 for ; Sun, 12 Sep 2004 04:08:00 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8CB6Fvr021333; Sun, 12 Sep 2004 13:06:16 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8CB6FWn021332; Sun, 12 Sep 2004 13:06:15 +0200 Date: Sun, 12 Sep 2004 13:06:15 +0200 From: Francois Romieu To: sneakums@zork.net Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout Message-ID: <20040912110614.GA20942@electric-eye.fr.zoreil.com> References: <6upt4s4cro.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6upt4s4cro.fsf@zork.zork.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 590 Lines: 17 Sean Neakums : [r8169 irq delivery/Tx timeout issue] > I downed and upped the interface and it started working again. There is a gross error in the 2.6.9-rc1-mm4 version of the r8169 driver which could be related to your bug. A few patches have been posted on netdev amongst which the first should make things better (see [PATCH 2.6.9-rc1-mm4 x/4] on netdev the 10 of september 2004) Can you apply the patch below on top of 2.6.9-rc1-mm4 and report if it makes things better: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc1-mm4/r8169/r8169-130.patch -- Ueimor From jeffpc@optonline.net Sun Sep 12 08:54:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 08:54:41 -0700 (PDT) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.5.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CFsYL5019755 for ; Sun, 12 Sep 2004 08:54:35 -0700 Received: from [10.0.0.15] (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta5.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I3X00CCWQTU2M@mta5.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Sun, 12 Sep 2004 11:53:55 -0400 (EDT) Date: Sun, 12 Sep 2004 11:53:44 -0400 From: Jeff Sipek Subject: Re: [PATCH 2.6] watch64: generic variable monitoring system In-reply-to: <1094460391.1151.26.camel@jzny.localdomain> To: hadi@cyberus.ca Cc: Stephen Hemminger , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Message-id: <200409121153.52047.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200409031307.01240.jeffpc@optonline.net> <200409051219.47590.jeffpc@optonline.net> <1094460391.1151.26.camel@jzny.localdomain> X-archive-position: 8665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev Content-Length: 925 Lines: 33 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, I missed your email. On Tuesday 07 September 2004 06:18, jamal wrote: > On Sun, 2004-09-05 at 12:19, Jeff Sipek wrote: > > There was a discussion about 64-bit network statistics about a year ago > > on lkml. > > Sorry unsubscribed from lkml since summer of '94. [net related > discussions should really happen on netdev]. netdev was CC'd during this whole discussion. > > watch64 is a generic so that anyone in the kernel can use it. > > Ok - so why does this have to be in the kernel? I think it is convenient to have the 64 bit net stats reported by the kernel. Jeff. - -- My public GPG key can be found at http://shells.gnugeneration.com/~jeffpc/gpg/public-0xC7958FFE.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBRHENwFP0+seVj/4RAuzcAKCdBAooPae8pTaMEHbWmVDKAO7C5ACeLi21 cen/Ag4bH5Dm9xkQiXj+d0Q= =BrV+ -----END PGP SIGNATURE----- From garzik@havoc.gtf.org Sun Sep 12 09:16:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 09:16:27 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CGGLDt020299 for ; Sun, 12 Sep 2004 09:16:21 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id B79D6766E; Sun, 12 Sep 2004 12:16:05 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8CGG500023485; Sun, 12 Sep 2004 12:16:05 -0400 Date: Sun, 12 Sep 2004 12:16:05 -0400 From: Jeff Garzik To: Andi Kleen Cc: "David S. Miller" , hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040912161604.GA23366@havoc.gtf.org> References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912102529.GA27096@wotan.suse.de> User-Agent: Mutt/1.4.1i X-archive-position: 8666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 32 On Sun, Sep 12, 2004 at 12:25:29PM +0200, Andi Kleen wrote: > On Sun, Sep 12, 2004 at 06:01:14AM -0400, Jeff Garzik wrote: > > > > Oh and update Documentation/networking/netdevice.txt. > > > > If people are going to screw with the TX path, at least do it right and > > make it non-mysterious for everyone else. > > > > See Al Viro's Documentation/filesystem/directory-locking doc for a > > proper way to document a locking change that potentially affects every > > net driver in the kernel. > > > No it doesn't. It only affects every driver who sets NETIF_F_LLTX. > For drivers that don't set this flag there is no change at all. > Incorrect, you are changing the callsites, which -does- affect every driver. > I wasn't aware of Documentation/netdevices.txt, but I agree it > would be a good idea to update it. Patch for that attached. > DaveM, please apply. Thanks, but still need a patch for return value constants, otherwise you are compounding rather than addressing a current problem. Jeff From eric.lemoine@gmail.com Sun Sep 12 10:06:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 10:06:50 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CH6iaZ021350 for ; Sun, 12 Sep 2004 10:06:45 -0700 Received: by mproxy.gmail.com with SMTP id 77so99567rnk for ; Sun, 12 Sep 2004 10:06:27 -0700 (PDT) Received: by 10.38.73.3 with SMTP id v3mr781503rna; Sun, 12 Sep 2004 10:06:26 -0700 (PDT) Received: by 10.38.99.21 with HTTP; Sun, 12 Sep 2004 10:06:26 -0700 (PDT) Message-ID: <5cac192f040912100616feb28a@mail.gmail.com> Date: Sun, 12 Sep 2004 19:06:26 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: Andi Kleen Subject: Re: [PATCH] LLTX for tg3 Cc: davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <20040907121841.GA4398@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040907121841.GA4398@wotan.suse.de> X-archive-position: 8667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 1491 Lines: 42 > Add LLTX suppor to tg3. Locking was already safe for it, so only > trivial changes. tg3_set_rx_mode() (dev->set_multicast_list()) and tg3_start_xmit() used to synchronise thanks to dev->lock_xmit. With your LLTX patches they don't synchronise anymore (I don't think tg3_set_rx_mode() grabs tp->tx_lock) ; isn't it an issue? PS: your LLTX patch to e1000 seems to have the needed extra locking in e1000_set_multi() though. > Depends on the LLTX patch sent earlier. > > diff -u linux-2.6.8/drivers/net/tg3.c-o linux-2.6.8/drivers/net/tg3.c > --- linux-2.6.8/drivers/net/tg3.c-o 2004-09-04 13:10:46.000000000 +0000 > +++ linux-2.6.8/drivers/net/tg3.c 2004-09-07 08:17:36.000000000 +0000 > @@ -3036,7 +3036,11 @@ > * So we really do need to disable interrupts when taking > * tx_lock here. > */ > - spin_lock_irqsave(&tp->tx_lock, flags); > + local_irq_save(flags); > + if (!spin_trylock(&tp->tx_lock)) { > + local_irq_restore(flags); > + return -1; > + } > > /* This is a hard error, log it. */ > if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->nr_frags + 1))) { > @@ -8255,6 +8259,7 @@ > > if (pci_using_dac) > dev->features |= NETIF_F_HIGHDMA; > + dev->features |= NETIF_F_LLTX; > #if TG3_VLAN_TAG_USED > dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX; > dev->vlan_rx_register = tg3_vlan_rx_register; > > -- Eric From hadi@cyberus.ca Sun Sep 12 10:27:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 10:27:53 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CHRklf021878 for ; Sun, 12 Sep 2004 10:27:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C6Y8V-0003ZS-01 for netdev@oss.sgi.com; Sun, 12 Sep 2004 13:27:35 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C6Y8S-0004Hp-FX; Sun, 12 Sep 2004 13:27:32 -0400 Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: jt@hpl.hp.com, "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040911220614.GF21181@postel.suug.ch> References: <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> <20040910231726.GP20088@postel.suug.ch> <1094868070.1042.77.camel@jzny.localdomain> <20040911134409.GA21181@postel.suug.ch> <1094932793.2344.82.camel@jzny.localdomain> <20040911220614.GF21181@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095010048.2342.204.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Sep 2004 13:27:29 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2808 Lines: 68 On Sat, 2004-09-11 at 18:06, Thomas Graf wrote: > * jamal <1094932793.2344.82.camel@jzny.localdomain> 2004-09-11 15:59 > > So my suggestion is making your code the exception. > > i.e something along the lines of: > > > > addrchg = 1; > > > > if (mtu/weight/name related) > > addrchng = 0; > > if (!err & addrchang) > > call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); > > OK, however I'd prefer to invert the concept. See patch > below. This would send out the following updates: Guess it wont make difference in number of lines of code, so fine. > ififlags - NETDEV_(UP|DOWN) if IFF_UP has changed > IFLA_MAP - none > IFLA_ADDRESS|IFLA_BROADCAST - NETDEV_CHANGEADDR > IFLA_MTU - NETDEV_CHANGEMTU > IFLA_WEIGHT - none > IFLA_IFNAME - NETDEVCHANGENAME > > PATCH: > Only send NETDEV_CHANGEADDR notifies for address and broadcast changes. > Notify is also sent out if only one of the 2 changes is successful. This one is sort of grey area. Sigh. In any case, i think that this is ok for now. So patch should go in - we can revisit the whole atomicity where applicable in kernel at some later point. Dave please go ahead and apply the patch. > > > Also note, the semantics of netlink are all-or-nothing transaction. i.e > > if one of the things requested for fails then you undo the rest. We can > > probably loosely say that unles the ATOMIC flag is set you dont need to > > undo that .. something to think about (summary is you probably dont want > > to send progress update to user space unless the transaction is > > successful; you however want to report progress of where failure happens > > - as we are discussing at the moment in the error code thread). > > Agreed, I think undo should happen from user space though. In the > example of do_setlink, you can see that while it would be quite easy to > do the sanity checks before actually doing something you can't catch > all errors if you don't want to implement the name/mtu/addr change > routines yourself. Keeping in mind that those sanity checks will > probably only fail during the development of a application it doesn't > really help. That's why I implemented it this way. sure. The hard part i think is you cant force every one wanting to make changes to link parameters to go via setlink. If you could then it should be doable to not make changes until after the attributes are all known (and therefore make it easy to undo). > I'm experimenting with a commit/fallback netlink library which basically > fetches the subject of change and stores the netlink message to be used > in case of fallback. NLM_F_ATOMIC makes it even more useable but is > quite expensive. A netlink change daemon would probably solve the > problem better. Daemon seems to be the only way to do it. Lets discuss this at some later point. cheers, jamal From hadi@cyberus.ca Sun Sep 12 10:34:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 10:34:54 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CHYnRh022280 for ; Sun, 12 Sep 2004 10:34:49 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C6YFJ-0001DZ-Ue for netdev@oss.sgi.com; Sun, 12 Sep 2004 13:34:37 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C6YFF-0004p2-6Q; Sun, 12 Sep 2004 13:34:33 -0400 Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Andi Kleen , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20040912161604.GA23366@havoc.gtf.org> References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912161604.GA23366@havoc.gtf.org> Content-Type: multipart/mixed; boundary="=-jHLccdGWjrFFQhCmzeiA" Organization: jamalopolous Message-Id: <1095010469.2344.215.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Sep 2004 13:34:30 -0400 X-archive-position: 8669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3332 Lines: 127 --=-jHLccdGWjrFFQhCmzeiA Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2004-09-12 at 12:16, Jeff Garzik wrote: > > Thanks, but still need a patch for return value constants, otherwise you > are compounding rather than addressing a current problem. Something along the lines of attached patch? Francois needs to update the doc and you need someone to get the janitors enthusiastic (i just updated e1000) cheers, jamal --=-jHLccdGWjrFFQhCmzeiA Content-Disposition: attachment; filename=andi-patch Content-Type: text/plain; name=andi-patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 269-rc1-bk17/include/linux/netdevice.h 2004/09/12 16:58:13 1.1 +++ 269-rc1-bk17/include/linux/netdevice.h 2004/09/12 17:10:45 @@ -73,6 +73,11 @@ #define MAX_ADDR_LEN 32 /* Largest hardware address length */ +/* Driver transmit return codes */ +#define NETDEV_TX_OK 0 /* driver took care of packet */ +#define NETDEV_TX_BUSY 1 /* driver tx path was busy*/ +#define NETDEV_TX_LOCKED -1 /* driver tx lock was already taken */ + /* * Compute the worst case header length according to the protocols * used. --- 269-rc1-bk17/net/sched/sch_generic.c 2004/09/12 16:55:03 1.1 +++ 269-rc1-bk17/net/sched/sch_generic.c 2004/09/12 17:08:52 @@ -139,13 +139,8 @@ if (netdev_nit) dev_queue_xmit_nit(skb, dev); - /* hard_start_xmit returns: - 0 device not ready - 1 everything ok - -1 didn't get device lock (for LLTX) - */ ret = dev->hard_start_xmit(skb, dev); - if (ret == 0) { + if (ret == NETDEV_TX_OK) { if (!nolock) { dev->xmit_lock_owner = -1; spin_unlock(&dev->xmit_lock); @@ -153,10 +148,11 @@ spin_lock(&dev->queue_lock); return -1; } - if (ret == -1 && nolock) + if (ret == NETDEV_TX_LOCKED && nolock) goto collision; } + /* NETDEV_TX_BUSY - we need to requeue */ /* Release the driver */ if (!nolock) { dev->xmit_lock_owner = -1; @@ -176,7 +172,7 @@ 3. device is buggy (ppp) */ - requeue: +requeue: q->ops->requeue(skb, q); netif_schedule(dev); return 1; --- 269-rc1-bk17/drivers/net/e1000/e1000_main.c 2004/09/12 17:05:58 1.1 +++ 269-rc1-bk17/drivers/net/e1000/e1000_main.c 2004/09/12 17:07:30 @@ -1778,7 +1778,7 @@ if(unlikely(skb->len <= 0)) { dev_kfree_skb_any(skb); - return 0; + return NETDEV_TX_OK; } #ifdef NETIF_F_TSO @@ -1817,7 +1817,7 @@ if (!spin_trylock(&adapter->tx_lock)) { /* Collision - tell upper layer to requeue */ local_irq_restore(flags); - return -1; + return NETDEV_TX_LOCKED; } /* need: count + 2 desc gap to keep tail from touching @@ -1825,7 +1825,7 @@ if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { netif_stop_queue(netdev); spin_unlock_irqrestore(&adapter->tx_lock, flags); - return 1; + return NETDEV_TX_BUSY; } if(unlikely(adapter->hw.mac_type == e1000_82547)) { @@ -1833,7 +1833,7 @@ netif_stop_queue(netdev); mod_timer(&adapter->tx_fifo_stall_timer, jiffies); spin_unlock_irqrestore(&adapter->tx_lock, flags); - return 1; + return NETDEV_TX_BUSY; } } @@ -1856,7 +1856,7 @@ netdev->trans_start = jiffies; spin_unlock_irqrestore(&adapter->tx_lock, flags); - return 0; + return NETDEV_TX_OK; } /** --=-jHLccdGWjrFFQhCmzeiA-- From willy@w.ods.org Sun Sep 12 11:00:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 11:00:12 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CI04a0023417 for ; Sun, 12 Sep 2004 11:00:05 -0700 Date: Sun, 12 Sep 2004 19:59:46 +0200 From: Willy Tarreau To: Wolfpaw - Dale Corse Cc: peter@mysql.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local and REMOTE(verified) Denial of Service Attack Message-ID: <20040912175946.GA3491@alpha.home.local> References: <029201c498d8$dff156f0$0300a8c0@s> <001c01c498df$8d2cd0f0$0200a8c0@wolf> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01c498df$8d2cd0f0$0200a8c0@wolf> User-Agent: Mutt/1.4i X-archive-position: 8671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 6062 Lines: 123 Hi Dale, I've tried your code right here. The "attacker" was 10.0.3.1, and the victim 10.0.3.2. I could successfully generate 1 CLOSE_WAIT on the victim with your program. It was on port 23 and attached to inetd as fd #3. So I killed inetd, the connection was then freed, and restarted it. I changed the code slightly to be able to pass IP/ports as arguments. On the victim, I straced inetd (pid 1013), and captured all TCP traffic on port 23. attacker> ./tcpnclose2 10.0.3.2 22 10.0.3.2 23 I stopped it when it was shouting at me : socket failed.Connecting to 10.0.3.2:22 (FD: -1)... FAILED: UNKNOWN ERROR. socket failed.Connecting to 10.0.3.2:23 (FD: -1)... FAILED: UNKNOWN ERROR. Then, on the victim : victim> sudo netstat -atnp|grep -v LISTEN Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 1 0 10.0.3.2:23 10.0.3.1:34058 CLOSE_WAIT 1013/inetd victim> tcpdump -Svnr capture-victim.cap tcp port 34058 reading from file capture-victim.cap, link-type EN10MB (Ethernet) 19:05:10.360728 IP (tos 0x0, ttl 64, id 8168, offset 0, flags [DF], length: 48) 10.0.3.1.34058 > 10.0.3.2.23: S [tcp sum ok] 2882867180:2882867180(0) win 15920 19:05:10.360764 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 48) 10.0.3.2.23 > 10.0.3.1.34058: S [tcp sum ok] 2614211278:2614211278(0) ack 2882867181 win 5840 19:05:10.360863 IP (tos 0x0, ttl 64, id 8169, offset 0, flags [DF], length: 40) 10.0.3.1.34058 > 10.0.3.2.23: . [tcp sum ok] ack 2614211279 win 15920 19:06:17.668670 IP (tos 0x0, ttl 64, id 8170, offset 0, flags [DF], length: 40) 10.0.3.1.34058 > 10.0.3.2.23: F [tcp sum ok] 2882867181:2882867181(0) ack 2614211279 win 15920 19:06:17.671102 IP (tos 0x0, ttl 64, id 11127, offset 0, flags [DF], length: 40) 10.0.3.2.23 > 10.0.3.1.34058: . [tcp sum ok] ack 2882867182 win 5840 ==> We see that the victim (10.0.3.2) did not send the FIN in return. Now let's take a closer look at inetd : victim> cat /proc/net/tcp sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode 16: 0203000A:0017 0103000A:850A 08 00000000:00000001 00:00000000 00000000 0 0 6420 1 d5dac400 1500 20 0 2 -1 ==> The socket (state 8 = CLOSE_WAIT) is bound to inode 6420. victim> sudo ls -l /proc/1013/fd/|grep 6420 lrwx------ 1 root root 64 Sep 12 19:28 3 -> socket:[6420] ==> Again, it's FD #3. I restarted strace on inetd, and noticed that fd#3 was not in the select fd list anymore (remember one of the two cases I spoke about a few hours ago ?) : victim> strace -p 1013 select(22, [4 5 6 7 8 9 11 12 13 14 15 16 17 18 19 20 21], NULL, NULL, NULL Then, I took a look at the strace capture (184 MB !), to which I inserted line numbers for better readability : 1:1013 accept(10, 0, NULL) = 3 2:1013 fcntl64(10, F_SETFL, O_RDONLY) = 0 3:1013 rt_sigprocmask(SIG_BLOCK, [HUP ALRM CHLD], NULL, 8) = 0 4:1013 fork() = 1108 5:1013 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 6:1013 close(3) = 0 This was the last but one connection assigned to fd #3. As you see, it's finally closed. But a few lines later : 7:1013 select(22, [4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21], NULL, NULL, NULL) = 1 (in [10]) 8:1013 fcntl64(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 9:1013 accept(10, 0, NULL) = 3 10:1013 fcntl64(10, F_SETFL, O_RDONLY) = 0 11:1013 rt_sigprocmask(SIG_BLOCK, [HUP ALRM CHLD], NULL, 8) = 0 12:1013 gettimeofday({1095008773, 685550}, NULL) = 0 The FD gets re-used, but is never scanned anymore, so never closed either : 35:1013 select(22, [4 5 6 7 8 9 11 12 13 14 15 16 17 18 19 20 21], NULL, NULL, NULL Conclusion : ============ The problem is within inetd. In my case it could be because it was a bit old (1999), but since you have it too, it might indicate an old bug. The fact that it affects mysql too does not prove that the problem is in the kernel, and I suspect that for whatever reason, there are some race conditions in these two programs if the connection is either reused or closed very quickly. To demonstrate this, I've run your program against my reverse-proxy, haproxy, which I fortunately happen to know better than these other programs. I could not manage to get even a CLOSE_WAIT session after several attempts. All connections are closed normally, and as you'll see with this extract from strace, the polled file-descriptors are active once you kill the attacker : (...) close(593) = 0 select(684, [3 5 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683], NULL, NULL, {4, 835000}) = 81 (in [603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683], left {4, 836000}) gettimeofday({1095011266, 506966}, NULL) = 0 recv(603, "", 4096, 0x4000) = 0 recv(604, "", 4096, 0x4000) = 0 recv(605, "", 4096, 0x4000) = 0 (...) close(605) = 0 close(604) = 0 close(603) = 0 select(6, [3 5], NULL, NULL, NULL So I believe you'll have to dig into some programs because at least you found a vulnerability in both inetd and mysql :-) Regards, Willy From vkondra@mail.ru Sun Sep 12 11:04:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 11:04:15 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CI49gA023767 for ; Sun, 12 Sep 2004 11:04:10 -0700 Received: from [81.218.113.45] (port=10613 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1C6Yhh-000CE3-00; Sun, 12 Sep 2004 22:03:59 +0400 From: Vladimir Kondratiev To: greg chesson Subject: Re: generic 802.11 stack Date: Sun, 12 Sep 2004 21:03:13 +0300 User-Agent: KMail/1.7 Cc: netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409090815.40358.vkondra@mail.ru> <41408D8A.5010307@atheros.com> In-Reply-To: <41408D8A.5010307@atheros.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart39112616.aVK4lyAkZ5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409122103.21770.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 837 Lines: 29 --nextPart39112616.aVK4lyAkZ5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To inform about status: I started to work on idea of 802.11 generic stack. I start from code by Dav= e.=20 This far I fixed it to compile for 2.6 (Makefile and couple of syntax=20 errors). I am going to implement minimum functionality, at this stage I will somehow= =20 publish the project. Anyone can suggest what it the right solution for=20 hosting? Sourceforge? Something else? Vladimir --nextPart39112616.aVK4lyAkZ5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBRI9pqxdj7mhC6o0RAqddAJ93iiMtc79wdGOPLPvWa5xoR/gMdACfYcwv uEsZbZkUafYHuFByPA90VCI= =eVjj -----END PGP SIGNATURE----- --nextPart39112616.aVK4lyAkZ5-- From sneakums@zork.net Sun Sep 12 11:14:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 11:14:52 -0700 (PDT) Received: from zork.zork.net (Debian-exim@zork.zork.net [64.81.246.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CIElPg024178 for ; Sun, 12 Sep 2004 11:14:47 -0700 Received: from sneakums by zork.zork.net with local (Exim 4.34) id 1C6Yrs-0000IJ-QZ; Sun, 12 Sep 2004 11:14:29 -0700 To: Francois Romieu Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout References: <6upt4s4cro.fsf@zork.zork.net> <20040912110614.GA20942@electric-eye.fr.zoreil.com> From: Sean Neakums Mail-Followup-To: Francois Romieu , jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Date: Sun, 12 Sep 2004 19:14:28 +0100 In-Reply-To: <20040912110614.GA20942@electric-eye.fr.zoreil.com> (Francois Romieu's message of "Sun, 12 Sep 2004 13:06:15 +0200") Message-ID: <6u8ybf2w3f.fsf@zork.zork.net> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: sneakums@zork.net X-SA-Exim-Scanned: No (on zork.zork.net); SAEximRunCond expanded to false X-archive-position: 8673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sneakums@zork.net Precedence: bulk X-list: netdev Content-Length: 4543 Lines: 119 Francois Romieu writes: > Sean Neakums : > [r8169 irq delivery/Tx timeout issue] >> I downed and upped the interface and it started working again. > > There is a gross error in the 2.6.9-rc1-mm4 version of the r8169 driver > which could be related to your bug. > > A few patches have been posted on netdev amongst which the first should > make things better (see [PATCH 2.6.9-rc1-mm4 x/4] on netdev the 10 of > september 2004) > > Can you apply the patch below on top of 2.6.9-rc1-mm4 and report > if it makes things better: > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc1-mm4/r8169/r8169-130.patch Running 2.6.9-rc1-mm4 with the above patch. I'm a bit unsure of the timing, but at some point I got this either before or during the transfer I set up to get some Tx activity, a repeated wget of a 35M file. irq 10: nobody cared! [__report_bad_irq+36/144] __report_bad_irq+0x24/0x90 [note_interrupt+146/352] note_interrupt+0x92/0x160 [do_IRQ+354/416] do_IRQ+0x162/0x1a0 [common_interrupt+24/32] common_interrupt+0x18/0x20 [default_idle+0/64] default_idle+0x0/0x40 [default_idle+44/64] default_idle+0x2c/0x40 [cpu_idle+52/80] cpu_idle+0x34/0x50 [start_kernel+347/384] start_kernel+0x15b/0x180 [unknown_bootoption+0/368] unknown_bootoption+0x0/0x170 handlers: [usb_hcd_irq+0/112] (usb_hcd_irq+0x0/0x70) [usb_hcd_irq+0/112] (usb_hcd_irq+0x0/0x70) Disabling IRQ #10 I killed the transfer and started X, getting this immediately: irq 16: nobody cared! [__report_bad_irq+36/144] __report_bad_irq+0x24/0x90 [note_interrupt+146/352] note_interrupt+0x92/0x160 [do_IRQ+354/416] do_IRQ+0x162/0x1a0 [common_interrupt+24/32] common_interrupt+0x18/0x20 [default_idle+0/64] default_idle+0x0/0x40 [default_idle+44/64] default_idle+0x2c/0x40 [cpu_idle+52/80] cpu_idle+0x34/0x50 handlers: [rtl8169_interrupt+0/464] (rtl8169_interrupt+0x0/0x1d0) Disabling IRQ #16 This also happened during the originally-reported incident, which I forgot to mention. Both times, downing and then upping the interface resulted in what seemed like a solid hang, although possibly it was just X. I rebooted and started X again, and again got the above. If I boot with acpi=noirq, I don't get that message upon starting X. Here's /proc/interrupts before and after starting X, without passing acpi=noirq: CPU0 CPU1 0: 18810 52561 IO-APIC-edge timer 1: 142 8 IO-APIC-edge i8042 5: 0 0 IO-APIC-level acpi 8: 2 2 IO-APIC-edge rtc 10: 3651 3367 IO-APIC-level uhci_hcd, uhci_hcd 11: 0 0 IO-APIC-level VIA686A 14: 2 13 IO-APIC-edge ide0 16: 10 8 IO-APIC-level eth2 17: 12 7 IO-APIC-level eth1 19: 2989 2564 IO-APIC-level aic7xxx NMI: 0 0 LOC: 71037 71036 ERR: 0 MIS: 0 CPU0 CPU1 0: 42718 64701 IO-APIC-edge timer 1: 247 33 IO-APIC-edge i8042 5: 0 0 IO-APIC-level acpi 8: 2 2 IO-APIC-edge rtc 10: 4928 3367 IO-APIC-level uhci_hcd, uhci_hcd 11: 0 0 IO-APIC-level VIA686A, radeon@PCI:1:0:0 14: 2 13 IO-APIC-edge ide0 16: 10 99990 IO-APIC-level eth2 17: 30 7 IO-APIC-level eth1 19: 3927 2564 IO-APIC-level aic7xxx NMI: 0 0 LOC: 107084 107083 ERR: 0 MIS: 0 I don't know if this is significant, but with acpi=noirq, /proc/interrupts looks like this: CPU0 CPU1 0: 196902 25653 IO-APIC-edge timer 1: 64 1189 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 5: 0 0 IO-APIC-edge acpi 8: 2 2 IO-APIC-edge rtc 9: 93 4 IO-APIC-level eth1 10: 2438 4609 IO-APIC-level aic7xxx, uhci_hcd, uhci_hcd 11: 10 15775 IO-APIC-level eth2, radeon@PCI:1:0:0 12: 0 0 IO-APIC-level VIA686A 14: 10 5 IO-APIC-edge ide0 NMI: 0 0 LOC: 222226 222225 ERR: 0 MIS: 0 eth2 being the 8169. Unfortunately after tonight I won't have access to this machine until Friday evening. I'll grab the netdev patchset and try those next. From willy@w.ods.org Sun Sep 12 11:19:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 11:19:05 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CIJ09o024539 for ; Sun, 12 Sep 2004 11:19:00 -0700 Date: Sun, 12 Sep 2004 20:18:43 +0200 From: Willy Tarreau To: Wolfpaw - Dale Corse Cc: peter@mysql.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local and REMOTE(verified) Denial of Service Attack Message-ID: <20040912181843.GA3619@alpha.home.local> References: <029201c498d8$dff156f0$0300a8c0@s> <001c01c498df$8d2cd0f0$0200a8c0@wolf> <20040912175946.GA3491@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912175946.GA3491@alpha.home.local> User-Agent: Mutt/1.4i X-archive-position: 8674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 1468 Lines: 40 Hi again, Dale, I forgot to say that you don't need to fear releasing your exploit. I developped its equivalent 4 years ago to stress-test web servers and proxies, and if I launch it against victim:23, I get the exact same result within seconds : a CLOSE_WAIT socket : attacker> ./connectdata 10.0.3.2 23 200 1 ERROR: connect()=-1, nbconn=134 : Connection refused ERROR: connect()=-1, nbconn=135 : Connection refused ERROR: connect()=-1, nbconn=136 : Connection refused ERROR: connect()=-1, nbconn=137 : Connection refused The program connects 200 sockets to the same IP:port, and sends the begining of an HTTP request. victim> sudo netstat -atnp|grep -v LISTEN Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 17 0 10.0.3.2:23 10.0.3.1:38214 CLOSE_WAIT 1333/inetd It's even not necessary to send data, then even faster to block my very old inetd : attacker> ./connectdata-nb 10.0.3.2 23 200 200 connections established. Press any key so exit. This time, it sends 200 non-blocking connect() calls without any data. It takes a fraction of a second with the same result. Hopefully, it'll will help Peter and you reproduce the problem faster on mysql. Both programs have been freely available here for two years ; I didn't think they would be useful again ! http://w.ods.org/tools/connect/ Regards, Willy From alan@lxorguk.ukuu.org.uk Sun Sep 12 11:19:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 11:20:01 -0700 (PDT) Received: from localhost.localdomain (the-village.bc.nu [81.2.110.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CIJs0L024725 for ; Sun, 12 Sep 2004 11:19:55 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8CHHRTQ011889; Sun, 12 Sep 2004 18:17:28 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8CHHQCF011888; Sun, 12 Sep 2004 18:17:26 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local and REMOTE(verified) Denial of Service Attack From: Alan Cox To: Willy Tarreau Cc: Wolfpaw - Dale Corse , peter@mysql.com, Linux Kernel Mailing List , netdev@oss.sgi.com In-Reply-To: <20040912175946.GA3491@alpha.home.local> References: <029201c498d8$dff156f0$0300a8c0@s> <001c01c498df$8d2cd0f0$0200a8c0@wolf> <20040912175946.GA3491@alpha.home.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095009440.11736.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 12 Sep 2004 18:17:21 +0100 X-archive-position: 8675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 325 Lines: 10 On Sul, 2004-09-12 at 18:59, Willy Tarreau wrote: > The problem is within inetd. In my case it could be because it was a bit > old (1999), but since you have it too, Ancient inetd had several fd leak bugs fixed over time and some other problems with built in services. Not much of a suprise that a 1999 inetd has it. Alan From admin@wolfpaw.net Sun Sep 12 11:41:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 11:41:21 -0700 (PDT) Received: from priv-edtnes57.telusplanet.net (outbound01.telus.net [199.185.220.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CIf7L8025458 for ; Sun, 12 Sep 2004 11:41:07 -0700 Received: from wolf ([142.179.166.184]) by priv-edtnes57.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040912184050.SGQU714.priv-edtnes57.telusplanet.net@wolf>; Sun, 12 Sep 2004 12:40:50 -0600 From: "Wolfpaw - Dale Corse" To: Cc: , , Subject: RE: Linux 2.4.27 SECURITY BUG - TCP Local and REMOTE(verified)Denial of Service Attack Date: Sun, 12 Sep 2004 12:40:56 -0600 Message-ID: <002501c498f8$0a4ebc20$0200a8c0@wolf> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <02b201c498f6$8bb92540$0300a8c0@s> X-archive-position: 8676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: admin@wolfpaw.net Precedence: bulk X-list: netdev Content-Length: 2272 Lines: 66 Hi Alan, My inetd is not the old one, it is in Slackware 10.0.. apparently 1.79s, still works here. (the s added by The slackware group according to the readme: /* $Slackware: inetd.c 1.79s 2001/02/06 13:18:00 volkerdi Exp $ */ /* $OpenBSD: inetd.c,v 1.79 2001/01/30 08:30:57 deraadt Exp $ */ /* $NetBSD: inetd.c,v 1.11 1996/02/22 11:14:41 mycroft Exp $ */ /* It still dies pretty fast :( Willy is probably right, in that the bug is application level in this case. Can you explain though, how it is appropriate to have no timeout on CLOSE_WAIT. Lets assume (such as the case with the mysql bug), that it is created, and for some reason never addressed.. The end case being mysql reporting "Too many Connections". That would make me assume these connections are still "alive" (perhaps I am assuming wrong?) and could still cause issues with other services, if the volume of them was to get too high. It still seems prudent to me to have some kind of timeout (2 hours, or something?) to have it expuldge the connection, because obviously, it isn't going to voluntarily close. This bug also exists with Apache, the default config of SSH, and anything controlled by inetd. This is the vast majority of popular services on a regular internet server.. That is bad, no? D. > -----Original Message----- > From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] > Sent: Sunday, September 12, 2004 11:17 AM > To: Willy Tarreau > Cc: Wolfpaw - Dale Corse; peter@mysql.com; Linux Kernel > Mailing List; netdev@oss.sgi.com > Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local and > REMOTE(verified)Denial of Service Attack > > > On Sul, 2004-09-12 at 18:59, Willy Tarreau wrote: > > The problem is within inetd. In my case it could be because it was a > > bit old (1999), but since you have it too, > > Ancient inetd had several fd leak bugs fixed over time and > some other problems with built in services. Not much of a > suprise that a 1999 inetd has it. > > Alan > > > -------------------------------------------------------------- > -------------- > - > This message has been scanned for Spam and Viruses by ClamAV > and SpamAssassin > -------------------------------------------------------------- > -------------- > - > > > > > From alan@lxorguk.ukuu.org.uk Sun Sep 12 12:03:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 12:03:53 -0700 (PDT) Received: from localhost.localdomain (the-village.bc.nu [81.2.110.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CJ3lrp026113 for ; Sun, 12 Sep 2004 12:03:48 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8CI1Rnn011925; Sun, 12 Sep 2004 19:01:27 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8CI1Pmx011924; Sun, 12 Sep 2004 19:01:25 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: RE: Linux 2.4.27 SECURITY BUG - TCP Local and REMOTE(verified)Denial of Service Attack From: Alan Cox To: Wolfpaw - Dale Corse Cc: peter@mysql.com, Linux Kernel Mailing List , netdev@oss.sgi.com In-Reply-To: <002501c498f8$0a4ebc20$0200a8c0@wolf> References: <002501c498f8$0a4ebc20$0200a8c0@wolf> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095012081.11745.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 12 Sep 2004 19:01:23 +0100 X-archive-position: 8677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 1175 Lines: 26 On Sul, 2004-09-12 at 19:40, Wolfpaw - Dale Corse wrote: > This bug also exists with Apache, the default config of SSH, > and anything controlled by inetd. This is the vast majority of > popular services on a regular internet server.. That is bad, no? I'm unable to duplicate any such problems with xinetd, or with thttpd, or with apache. Apache will wait a short time then timeout connections if you've configured it right. If you can continue making millions of connections a second you can DoS the server the other end, not exactly new news. The alternative is that you have an infinite number of running services and you run out of memory instead. Thats a high level property of any protocol which allows commitment of resource without being able to do the security authentication first. Its very hard to create ones that don't however, thus most devices in life (eg your telephone) have this form or DoS attack. My sshd also doesn't show this problem and the manual page indicates it has a 120 second grace timeout for authentication. The sshd manual page says: Gives the grace time for clients to authenticate themselves (default 120 seconds). From admin@wolfpaw.net Sun Sep 12 12:18:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 12:19:01 -0700 (PDT) Received: from priv-edtnes46.telusplanet.net (defout.telus.net [199.185.220.240]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CJItKV026660 for ; Sun, 12 Sep 2004 12:18:55 -0700 Received: from wolf ([142.179.166.184]) by priv-edtnes46.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040912191840.UOZM20178.priv-edtnes46.telusplanet.net@wolf>; Sun, 12 Sep 2004 13:18:40 -0600 From: "Wolfpaw - Dale Corse" To: Cc: , , Subject: RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack Date: Sun, 12 Sep 2004 13:18:46 -0600 Message-ID: <002801c498fd$536d33f0$0200a8c0@wolf> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <02bd01c498fc$fe1954b0$0300a8c0@s> X-archive-position: 8678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: admin@wolfpaw.net Precedence: bulk X-list: netdev Content-Length: 1689 Lines: 42 > On Sul, 2004-09-12 at 19:40, Wolfpaw - Dale Corse wrote: > > This bug also exists with Apache, the default config of SSH, and > > anything controlled by inetd. This is the vast majority of popular > > services on a regular internet server.. That is bad, no? > > I'm unable to duplicate any such problems with xinetd, or > with thttpd, or with apache. Apache will wait a short time > then timeout connections if you've configured it right. If > you can continue making millions of connections a second you > can DoS the server the other end, not exactly new news. The > alternative is that you have an infinite number of running > services and you run out of memory instead. Slackware doesn't use xinetd, but rather inetd. Is inetd an old version which is no longer maintained? Apache, it didn't kill, but slowed it down quite a bit. You are correct for sure on that point though, there is nothing that can be done about connection floods. > Thats a high level property of any protocol which allows > commitment of resource without being able to do the security > authentication first. Its very hard to create ones that don't > however, thus most devices in life (eg your telephone) have > this form or DoS attack. Very true :( > My sshd also doesn't show this problem and the manual page > indicates it has a 120 second grace timeout for authentication. > > The sshd manual page says: > > Gives the grace time for clients to authenticate themselves > (default 120 seconds). Again - likely a connection flooding DoS there.. Which can't be helped Unless you use ipchains to limit the amount of connections per ip address. Thanks for the reply :) D. From admin@wolfpaw.net Sun Sep 12 12:36:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 12:36:31 -0700 (PDT) Received: from priv-edtnes28.telusplanet.net (outbound04.telus.net [199.185.220.223]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CJaOju030318 for ; Sun, 12 Sep 2004 12:36:25 -0700 Received: from wolf ([142.179.166.184]) by priv-edtnes28.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040912193609.KZRI15094.priv-edtnes28.telusplanet.net@wolf>; Sun, 12 Sep 2004 13:36:09 -0600 From: "Wolfpaw - Dale Corse" To: Cc: , , Subject: RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack Date: Sun, 12 Sep 2004 13:36:15 -0600 Message-ID: <002b01c498ff$c4619b30$0200a8c0@wolf> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <02be01c498fd$3b63a370$0300a8c0@s> X-archive-position: 8679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: admin@wolfpaw.net Precedence: bulk X-list: netdev Content-Length: 4209 Lines: 101 > On Sul, 2004-09-12 at 19:52, Wolfpaw - Dale Corse wrote: > > > > A) Why are the timeouts so long? > > > > > > So you don't get random corruption > > > > Hmm. I'll take your word for it, I'm not quite grasping it, but you > > know quite a bit more about it then I do :) I would have > thought once > > a close is sent, the data has all been received and/or sent > anyway, so > > what would corrupt? > > It has all arrived at least once. However you don't know if a > retransmitted packet took a long trip round the world and > popped out later. When that happens you need to be sure you > can tell old and new apart. The TIME_WAIT state is basically > "don't use this identical set of port/address data for long > enough to be sure any prior use has exited the internet in > its entirety. That makes sense :) > > > It _appears_ that when we close a socket (ie with > mysql_close) on the > > client side, the client side closes the FD properly (though Mysql > > socket != fd. If you close an fd and open you may get the > same fd but its a different socket. If its getting stuck > closing could you have another copy of the fd left open > somewhere or have passed it to a process you forked (thats a > classic nasty to track down error) ? The way it generally works, is the daemon opens quite a few sql connections for different reasons. It stores all of them in a linked list (a somewhat implementation of persistent connections, since the c API doesn't provide for it) Every 60 seconds, the list is scanned for "unused" sql connections, and calls mysql_close on them. The instance of the actual list entry is not deleted until the next run to give things 60 seconds to clear up. The issue we were having is this.. Mysql connection: descriptor 3 (from mysql.net.fd) Mysql connection closed (desc 3) (goes into CLOSE_WAIT now) New connection (outbound) for regular proxy on Desc 3 (this was created by a call to socket, and then connect) Now the only way to get mysql to actually CLOSE the connection, is go call close(mysql.net.fd) before destroying the structure. This would have the effect of clearing the CLOSE_WAIT entry from the netstat table, but it would also close the active connection that was made with socket/connect (they have the same FD). This is why I said they are being reused .. Our software (being the client) has requested the connection closed, and mysql hasn't closed it (unsure why.. Maybe data from the db query still sitting on the SQL side?), so it then reuses what it thinks is a clean FD, and it ends up needing to be closed AGAIN to stop the other bug.. The other bug being, if I simply leave them, in a short time, MySQL is saying "too many connections", and we can't query any data from it. This also occurs with FIFO sockets (such as /tmp/mysql.sock) wherein the connection simply sits as "ESTABLISHED". I have been unable to find any sort of "flush" command to issue to the SQL server on the socket, to tell it that I am done with whatever data it has pulled out of the DB. This is obviously an SQL bug. I assumed it an OS bug, mostly because the "socket" that used to belong to the FD is still open at least on one side, I was thinking this needs to be checked for somehow. What do you think? > > > doesn't), and then if we call connect (which it does a lot, being a > > proxy > > server) it will reuse that FD. At this point, the Mysql > side still hasn't > > closed it, and it is sitting in CLOSE_WAIT, where it > remains forever, > since > > it is in use by the client side elsewhere already. Should > connect be > > checking the "list of not connected, but state other then > CLOSED" list > > before it decides to use a particular FD? Or is this behavior > > intentional? > > Sockets are two way at the TCP layer. "close" really means > "have finished sending". When both ends have finished sending > the connection is complete but not before. Thus if Mysql > daemon says "I am done" but you have open references to the > handle then it will stay open one way still. So something needs to trigger a "flush" of the left over data on the SQL side before closing the connection - yes? Again - thank you for your input :) D. From willy@w.ods.org Sun Sep 12 12:48:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 12:48:40 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CJmZEE030797 for ; Sun, 12 Sep 2004 12:48:35 -0700 Date: Sun, 12 Sep 2004 21:48:16 +0200 From: Willy Tarreau To: Wolfpaw - Dale Corse Cc: alan@lxorguk.ukuu.org.uk, peter@mysql.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Linux 2.4.27 SECURITY BUG - TCP Local and REMOTE(verified)Denial of Service Attack Message-ID: <20040912194816.GB2780@alpha.home.local> References: <02b201c498f6$8bb92540$0300a8c0@s> <002501c498f8$0a4ebc20$0200a8c0@wolf> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c498f8$0a4ebc20$0200a8c0@wolf> User-Agent: Mutt/1.4i X-archive-position: 8680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 2553 Lines: 55 On Sun, Sep 12, 2004 at 12:40:56PM -0600, Wolfpaw - Dale Corse wrote: > It still seems prudent to me to have some kind of timeout (2 hours, > or something?) to have it expuldge the connection, because obviously, > it isn't going to voluntarily close. Dale, forgive me for insisting, but it would be criminal to do this. You think that it's sort of closed while it is not. Consider CLOSE_WAIT as ESTABLISHED. It is not because one end sends a FIN (shutdown(WRITE)) that the connection is about to end. The culprit really is the application. It is the application which trusts the other end too much. The system lets the application work as it expects it, and should never try to cut the grass below the application's feet. You must understand how it is supposed to work, basically like this : A B shutdown(WRITE) A enters FIN_WAIT1 ------- ACK + FIN ----------> select(in[fd],out[fd],) returns in[fd] B enters CLOSE_WAIT <------ ACK + data ----------- read(fd) returns 0 shutdown(SHUT_RD) Then remove fd from read list. <---- ACK + data ------------- select(NULL, out[fd],...) (...) write(fd, data)... <---- ACK + data ------------- select(NULL, out[fd],...) <---- ACK + FIN -------------- shutdown(SHUT_WRITE) or close(fd) close(fd) ------- ACK -----------------> If the system closed anything, on B side, since the select() does not check read events anymore, it would only be woken up for a write even, which could crash the application in a SIG_PIPE if the writer does not check the error condition on the socket before writing (like most applications do). So, let me insist, your proposal is not the right solution to this. The right solution is to carefully check every application and fix them, the same way you would fix them to handle time-outs on ESTABLISHED connections. > This bug also exists with Apache, the default config of SSH, > and anything controlled by inetd. This is the vast majority of > popular services on a regular internet server.. That is bad, no? You didn't wait long enough for each of them. I bet that if you wait up to 2 minutes, SSH will close, and if you wait 5 or 10 minutes, apache will close too. As to mysql, I have no idea, and inetd, we obviously both have a buggy version. I hope this clarifies a bit the situation, Willy From romieu@fr.zoreil.com Sun Sep 12 13:47:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 13:47:14 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CKl6gJ032201 for ; Sun, 12 Sep 2004 13:47:07 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8CKhKvr027459; Sun, 12 Sep 2004 22:43:20 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8CKhJIa027458; Sun, 12 Sep 2004 22:43:19 +0200 Date: Sun, 12 Sep 2004 22:43:19 +0200 From: Francois Romieu To: Sean Neakums Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout Message-ID: <20040912204319.GA27282@electric-eye.fr.zoreil.com> References: <6upt4s4cro.fsf@zork.zork.net> <20040912110614.GA20942@electric-eye.fr.zoreil.com> <6u8ybf2w3f.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6u8ybf2w3f.fsf@zork.zork.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 302 Lines: 11 Sean Neakums : [...] > Unfortunately after tonight I won't have access to this machine until > Friday evening. I'll grab the netdev patchset and try those next. via686a based multiprocessor board and acpi... Can you try vanilla 2.6.8 r8169 driver with 2.6.9-rc1-mm4 ? -- Ueimor From sneakums@zork.net Sun Sep 12 14:05:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 14:06:02 -0700 (PDT) Received: from zork.zork.net (Debian-exim@zork.zork.net [64.81.246.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CL5tmD000445 for ; Sun, 12 Sep 2004 14:05:56 -0700 Received: from sneakums by zork.zork.net with local (Exim 4.34) id 1C6bXH-0000NR-Pm; Sun, 12 Sep 2004 14:05:23 -0700 To: Francois Romieu Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout References: <6upt4s4cro.fsf@zork.zork.net> <20040912110614.GA20942@electric-eye.fr.zoreil.com> <6u8ybf2w3f.fsf@zork.zork.net> <20040912204319.GA27282@electric-eye.fr.zoreil.com> From: Sean Neakums Mail-Followup-To: Francois Romieu , jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Date: Sun, 12 Sep 2004 22:05:23 +0100 In-Reply-To: <20040912204319.GA27282@electric-eye.fr.zoreil.com> (Francois Romieu's message of "Sun, 12 Sep 2004 22:43:19 +0200") Message-ID: <6uisaj19m4.fsf@zork.zork.net> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: sneakums@zork.net X-SA-Exim-Scanned: No (on zork.zork.net); SAEximRunCond expanded to false X-archive-position: 8682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sneakums@zork.net Precedence: bulk X-list: netdev Content-Length: 807 Lines: 24 Francois Romieu writes: > Sean Neakums : > [...] >> Unfortunately after tonight I won't have access to this machine until >> Friday evening. I'll grab the netdev patchset and try those next. > > via686a based multiprocessor board and acpi... > > Can you try vanilla 2.6.8 r8169 driver with 2.6.9-rc1-mm4 ? Same result on starting X: irq 16: nobody cared! [__report_bad_irq+36/144] __report_bad_irq+0x24/0x90 [note_interrupt+146/352] note_interrupt+0x92/0x160 [do_IRQ+354/416] do_IRQ+0x162/0x1a0 [common_interrupt+24/32] common_interrupt+0x18/0x20 [default_idle+0/64] default_idle+0x0/0x40 [default_idle+44/64] default_idle+0x2c/0x40 [cpu_idle+52/80] cpu_idle+0x34/0x50 handlers: [rtl8169_interrupt+0/272] (rtl8169_interrupt+0x0/0x110) Disabling IRQ #16 From romieu@fr.zoreil.com Sun Sep 12 15:03:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 15:03:10 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CM32Tr001568 for ; Sun, 12 Sep 2004 15:03:05 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8CLxYvr028275; Sun, 12 Sep 2004 23:59:34 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8CLxX1D028274; Sun, 12 Sep 2004 23:59:33 +0200 Date: Sun, 12 Sep 2004 23:59:33 +0200 From: Francois Romieu To: Sean Neakums Cc: jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout Message-ID: <20040912215933.GB27282@electric-eye.fr.zoreil.com> References: <6upt4s4cro.fsf@zork.zork.net> <20040912110614.GA20942@electric-eye.fr.zoreil.com> <6u8ybf2w3f.fsf@zork.zork.net> <20040912204319.GA27282@electric-eye.fr.zoreil.com> <6uisaj19m4.fsf@zork.zork.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6uisaj19m4.fsf@zork.zork.net> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 552 Lines: 21 Sean Neakums : > Francois Romieu writes: > > Sean Neakums : > > [...] > >> Unfortunately after tonight I won't have access to this machine until > >> Friday evening. I'll grab the netdev patchset and try those next. > > > > via686a based multiprocessor board and acpi... > > > > Can you try vanilla 2.6.8 r8169 driver with 2.6.9-rc1-mm4 ? > > Same result on starting X: > > irq 16: nobody cared! It slightly sounds like a broken irq routing. Any taker for the hot potato ? -- Ueimor From romieu@fr.zoreil.com Sun Sep 12 16:18:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 16:19:06 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CNIwN6003266 for ; Sun, 12 Sep 2004 16:18:59 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8CNFGvr028980; Mon, 13 Sep 2004 01:15:16 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8CNFGhg028979; Mon, 13 Sep 2004 01:15:16 +0200 Date: Mon, 13 Sep 2004 01:15:16 +0200 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: r8169 - panic and a fix Message-ID: <20040912231516.GA27299@electric-eye.fr.zoreil.com> References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <200409111147.24064.sriharivijayaraghavan@yahoo.com.au> <20040911121952.GA3134@electric-eye.fr.zoreil.com> <200409121832.57233.sriharivijayaraghavan@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409121832.57233.sriharivijayaraghavan@yahoo.com.au> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1398 Lines: 40 Srihari Vijayaraghavan : [...] > Kernel BUG at r8169:1702 > invalid operand: 0000 [1] > CPU 0 > Modules linked in: r8169 af_packet ide_cd cdrom via_rhine mii crc32 floppy > radeon reiserfs dm_mod uhci_hcd ehci_hcd usbcorx > Pid: 0, comm: swapper Not tainted 2.6.9-rc1-bk17-r8169-b > RIP: 0010:[] > {:r8169:rtl8169_rx_interrupt+436} 0000000000001d70 : [...] 1f0d: b9 02 00 00 00 mov $0x2,%ecx 1f12: ba 00 06 00 00 mov $0x600,%edx 1f17: ff 54 24 08 callq *0x8(%rsp) -> pci_action(...) 1f1b: 41 81 fc fc 05 00 00 cmp $0x5fc,%r12d 1f22: 7e 0c jle 1f30 1f24: 0f 0b ud2a -> BUG_ON(pkt_size > (RX_BUF_SIZE - 4)); > RSP: 0018:ffffffff8039bc38 EFLAGS: 00010206 > RAX: 0000000000000000 RBX: 0000000000000c00 RCX: 0000000000000000 > RDX: 0000000000000600 RSI: 000000003ef4d012 RDI: 00000100023c3070 > RBP: 0000010038ee4360 R08: 0000000000000000 R09: 0000000000000000 > R10: 000001003f614e28 R11: 000001003bacdda0 R12: 0000000000000bfc ^^^ -> 3068. RX_BUF_SIZE*2 - 4 ? /me scratches head Can you #define RX_BUF_SIZE 3072 and run with r8169-dbg-b applied ? -- Ueimor From davem@davemloft.net Sun Sep 12 16:33:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 16:33:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CNXqOT006951 for ; Sun, 12 Sep 2004 16:33:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6dpQ-0001yD-00; Sun, 12 Sep 2004 16:32:16 -0700 Date: Sun, 12 Sep 2004 16:32:16 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: fix an oops in rt6_device_match() Message-Id: <20040912163216.7f49673a.davem@davemloft.net> In-Reply-To: <20040911.201029.21582458.yoshfuji@linux-ipv6.org> References: <20040911.201029.21582458.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8CNXqOT006951 X-archive-position: 8685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 475 Lines: 15 On Sat, 11 Sep 2004 20:10:29 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > This fixes panic in rt6_device_match(). > > Well, rt->rt6i_idev is always set if it is dynamically allocated. > However, when we hit ip6_null_entry here, its rt6i_idev is NULL. > This patch is minimum fix to avoid the oops for now. > > Signed-off-by: Hideaki YOSHIFUJI Ok, as long as we fix this more cleanly eventually. Thank you. From davem@davemloft.net Sun Sep 12 16:39:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 16:39:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CNdQZ7007365 for ; Sun, 12 Sep 2004 16:39:27 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6duj-0001z8-00; Sun, 12 Sep 2004 16:37:45 -0700 Date: Sun, 12 Sep 2004 16:37:44 -0700 From: "David S. Miller" To: Thomas Graf Cc: ak@suse.de, netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-Id: <20040912163744.52f95367.davem@davemloft.net> In-Reply-To: <20040911162433.GC21181@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 438 Lines: 15 On Sat, 11 Sep 2004 18:24:33 +0200 Thomas Graf wrote: > > I don't think an very specific error like > > "CFQ subsystem parameter X is FOO, can be only upto BAR" > > can be nicely put into a global error file. > > True, I would really like to have such error messages. I'd love to have them too. But I know internationalization folks are going to scream, although it will obviously be better than no messages at all. From davem@davemloft.net Sun Sep 12 16:45:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 16:45:16 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CNjB16007732 for ; Sun, 12 Sep 2004 16:45:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6e0A-0001ze-00; Sun, 12 Sep 2004 16:43:22 -0700 Date: Sun, 12 Sep 2004 16:43:22 -0700 From: "David S. Miller" To: Julian Anastasov Cc: netdev@oss.sgi.com, wensong@linux-vs.org Subject: Re: [PATCH 2.6] ipvs - v2: do not use skb_checksum_help, nf_reset Message-Id: <20040912164322.49f11328.davem@davemloft.net> In-Reply-To: References: <20040911173952.5092aa65.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 45 Lines: 4 Looks great, patch applied. Thanks Julian. From davem@davemloft.net Sun Sep 12 16:46:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 16:47:02 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8CNkv3p007951 for ; Sun, 12 Sep 2004 16:46:57 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6e21-0001zw-00; Sun, 12 Sep 2004 16:45:17 -0700 Date: Sun, 12 Sep 2004 16:45:16 -0700 From: "David S. Miller" To: Eric Lemoine Cc: ak@suse.de, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] LLTX for tg3 Message-Id: <20040912164516.6960ffe8.davem@davemloft.net> In-Reply-To: <5cac192f040912100616feb28a@mail.gmail.com> References: <20040907121841.GA4398@wotan.suse.de> <5cac192f040912100616feb28a@mail.gmail.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 524 Lines: 15 On Sun, 12 Sep 2004 19:06:26 +0200 Eric Lemoine wrote: > > Add LLTX suppor to tg3. Locking was already safe for it, so only > > trivial changes. > > tg3_set_rx_mode() (dev->set_multicast_list()) and tg3_start_xmit() > used to synchronise thanks to dev->lock_xmit. With your LLTX patches > they don't synchronise anymore (I don't think tg3_set_rx_mode() grabs > tp->tx_lock) ; isn't it an issue? You're absolutely right, I've made tg3_set_rx_mode() grab the tx_lock now too. Good spotting Eric. From davem@davemloft.net Sun Sep 12 17:05:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:05:28 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D05MU7008728 for ; Sun, 12 Sep 2004 17:05:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eJX-00021s-00; Sun, 12 Sep 2004 17:03:23 -0700 Date: Sun, 12 Sep 2004 17:03:23 -0700 From: "David S. Miller" To: Julian Anastasov Cc: laforge@netfilter.org, netdev@oss.sgi.com, rusty@rustcorp.com.au Subject: Re: [PATCH 2.6] ip_nat_ftp - manip at the right place Message-Id: <20040912170323.65eadc38.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 540 Lines: 19 On Sat, 11 Sep 2004 10:53:53 +0300 (EEST) Julian Anastasov wrote: > This is a resend/resync for v2.6.9-rc1-bk17: change the > way the ip_nat_ftp helper manipulates the packets: > > - no manips => no fixup > > - check the direction, do manip once and at the same time when the > headers are changed > > This is needed mostly for IPVS setups and I hope we do not > create troubles for other setups or FTP software. > > Signed-off-by: Julian Anastasov Harald and/or Rusty, please ACK/NACK this for me. Thanks. From davem@davemloft.net Sun Sep 12 17:06:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:06:47 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D06hJ3008929 for ; Sun, 12 Sep 2004 17:06:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eLC-000229-00; Sun, 12 Sep 2004 17:05:06 -0700 Date: Sun, 12 Sep 2004 17:05:05 -0700 From: "David S. Miller" To: Paul P Komkoff Jr Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-Id: <20040912170505.62916147.davem@davemloft.net> In-Reply-To: <20040911194108.GS28258@stingr.sgu.ru> References: <20040911194108.GS28258@stingr.sgu.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 589 Lines: 17 On Sat, 11 Sep 2004 23:41:08 +0400 Paul P Komkoff Jr wrote: > Some time ago I posted the following patch. > It indeed adds support for wccp version 1 and 2 decapsulation in > ip_gre.c. But there is an open question. > I surrounded all decapsulation stuff in if (1). > Which knob I should use instead of that 1 to make this change > acceptable into mainline kernel? What are the rules for IP_GRE in general for when to apply this transformation? Please do me a favor also, and redo your patch by putting ETH_P_WCCP into include/linux/if_ether.h where it belongs. Thanks. From jgarzik@pobox.com Sun Sep 12 17:07:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:07:26 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D07Kle009142 for ; Sun, 12 Sep 2004 17:07:21 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6eN8-0007Ao-Dc; Mon, 13 Sep 2004 01:07:06 +0100 Message-ID: <4144E49B.80400@pobox.com> Date: Sun, 12 Sep 2004 20:06:51 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Andi Kleen , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912161604.GA23366@havoc.gtf.org> <1095010469.2344.215.camel@jzny.localdomain> In-Reply-To: <1095010469.2344.215.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 285 Lines: 15 jamal wrote: > On Sun, 2004-09-12 at 12:16, Jeff Garzik wrote: > > >>Thanks, but still need a patch for return value constants, otherwise you >>are compounding rather than addressing a current problem. > > > Something along the lines of attached patch? Yep, thanks, ACK. Jeff From jgarzik@pobox.com Sun Sep 12 17:09:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:09:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D09YQh009708 for ; Sun, 12 Sep 2004 17:09:34 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6ePJ-0007CH-DW; Mon, 13 Sep 2004 01:09:21 +0100 Message-ID: <4144E524.1050306@pobox.com> Date: Sun, 12 Sep 2004 20:09:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409090815.40358.vkondra@mail.ru> <41408D8A.5010307@atheros.com> <200409122103.21770.vkondra@mail.ru> In-Reply-To: <200409122103.21770.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 537 Lines: 16 Vladimir Kondratiev wrote: > To inform about status: > I started to work on idea of 802.11 generic stack. I start from code by Dave. > This far I fixed it to compile for 2.6 (Makefile and couple of syntax > errors). > I am going to implement minimum functionality, at this stage I will somehow > publish the project. Anyone can suggest what it the right solution for > hosting? Sourceforge? Something else? I can put it into the wireless-2.6 queue, which is where I would prefer that work on a generic 802.11 stack went. Jeff From jgarzik@pobox.com Sun Sep 12 17:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:12:59 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0Cr1f010137 for ; Sun, 12 Sep 2004 17:12:53 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6eSY-0007H2-WE; Mon, 13 Sep 2004 01:12:43 +0100 Message-ID: <4144E5EF.1040008@pobox.com> Date: Sun, 12 Sep 2004 20:12:31 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 References: <20040908065152.GC27886@wotan.suse.de> <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> In-Reply-To: <20040912102529.GA27096@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 192 Lines: 10 Andi Kleen wrote: > I wasn't aware of Documentation/netdevices.txt, but I agree it > would be a good idea to update it. Patch for that attached. > DaveM, please apply. Thanks, ACK. Jeff From davem@davemloft.net Sun Sep 12 17:12:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:12:37 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0CVeE010054 for ; Sun, 12 Sep 2004 17:12:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eQg-00023N-00; Sun, 12 Sep 2004 17:10:46 -0700 Date: Sun, 12 Sep 2004 17:10:45 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: jgarzik@pobox.com, ak@suse.de, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-Id: <20040912171045.2d54c11a.davem@davemloft.net> In-Reply-To: <1095010469.2344.215.camel@jzny.localdomain> References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912161604.GA23366@havoc.gtf.org> <1095010469.2344.215.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 523 Lines: 17 On 12 Sep 2004 13:34:30 -0400 jamal wrote: > On Sun, 2004-09-12 at 12:16, Jeff Garzik wrote: > > > > > Thanks, but still need a patch for return value constants, otherwise you > > are compounding rather than addressing a current problem. > > Something along the lines of attached patch? > Francois needs to update the doc and you need someone to get the > janitors enthusiastic (i just updated e1000) Looks beautiful. I added this patch and did the tg3 bits in my local tree as well. Thanks Jamal. From davem@davemloft.net Sun Sep 12 17:15:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:15:17 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0FDhD010749 for ; Sun, 12 Sep 2004 17:15:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eT6-000244-00; Sun, 12 Sep 2004 17:13:16 -0700 Date: Sun, 12 Sep 2004 17:13:16 -0700 From: "David S. Miller" To: Francois Romieu Cc: ak@suse.de, hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-Id: <20040912171316.1fbdf8db.davem@davemloft.net> In-Reply-To: <20040912110320.GA21197@electric-eye.fr.zoreil.com> References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912110320.GA21197@electric-eye.fr.zoreil.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 492 Lines: 16 On Sun, 12 Sep 2004 13:03:20 +0200 Francois Romieu wrote: > Andi Kleen : > [...] > > I wasn't aware of Documentation/netdevices.txt, but I agree it > > would be a good idea to update it. Patch for that attached. > > DaveM, please apply. > > I have modified your patch so as to include a bit from a message > of Jamal on netdev the 05/07/2004. I've enhanced it further to make use of the macro'ized named Jamal added for these values. Thanks everyone. From davem@davemloft.net Sun Sep 12 17:21:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:21:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0LPGq011108 for ; Sun, 12 Sep 2004 17:21:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eUa-00024T-00; Sun, 12 Sep 2004 17:14:48 -0700 Date: Sun, 12 Sep 2004 17:14:48 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-Id: <20040912171448.64ce7dbe.davem@davemloft.net> In-Reply-To: <200409122103.21770.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409090815.40358.vkondra@mail.ru> <41408D8A.5010307@atheros.com> <200409122103.21770.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 516 Lines: 13 On Sun, 12 Sep 2004 21:03:13 +0300 Vladimir Kondratiev wrote: > I am going to implement minimum functionality, at this stage I will somehow > publish the project. Anyone can suggest what it the right solution for > hosting? Sourceforge? Something else? I am willing to host things for you, if you wish. I can make a directory in my personal area on ftp.kernel.org and that's where I'd put your patches. I'd also like to help review your patches, so I can perform both things at the same time. From davem@davemloft.net Sun Sep 12 17:28:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:28:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0Sm8u011497 for ; Sun, 12 Sep 2004 17:28:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eaK-00025B-00; Sun, 12 Sep 2004 17:20:44 -0700 Date: Sun, 12 Sep 2004 17:20:43 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: tgraf@suug.ch, jt@hpl.hp.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Device name changing via rtnetlink Message-Id: <20040912172043.11bc9372.davem@davemloft.net> In-Reply-To: <1095010048.2342.204.camel@jzny.localdomain> References: <20040910200644.GJ20088@postel.suug.ch> <20040910201302.GA16556@bougret.hpl.hp.com> <20040910202235.GK20088@postel.suug.ch> <20040910203203.GA17078@bougret.hpl.hp.com> <20040910204348.GL20088@postel.suug.ch> <1094857082.1041.19.camel@jzny.localdomain> <20040910231726.GP20088@postel.suug.ch> <1094868070.1042.77.camel@jzny.localdomain> <20040911134409.GA21181@postel.suug.ch> <1094932793.2344.82.camel@jzny.localdomain> <20040911220614.GF21181@postel.suug.ch> <1095010048.2342.204.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 272 Lines: 9 On 12 Sep 2004 13:27:29 -0400 jamal wrote: > In any case, i think that this is ok for now. So patch should go > in - we can revisit the whole atomicity where applicable in kernel at > some later point. > Dave please go ahead and apply the patch. Done. From davem@davemloft.net Sun Sep 12 17:47:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:47:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0lPmf012028 for ; Sun, 12 Sep 2004 17:47:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6eyW-000276-00; Sun, 12 Sep 2004 17:45:44 -0700 Date: Sun, 12 Sep 2004 17:45:44 -0700 From: "David S. Miller" To: Jeff Garzik Cc: vkondra@mail.ru, greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-Id: <20040912174544.630a0b44.davem@davemloft.net> In-Reply-To: <4144E524.1050306@pobox.com> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409090815.40358.vkondra@mail.ru> <41408D8A.5010307@atheros.com> <200409122103.21770.vkondra@mail.ru> <4144E524.1050306@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 655 Lines: 16 On Sun, 12 Sep 2004 20:09:08 -0400 Jeff Garzik wrote: > Vladimir Kondratiev wrote: > > To inform about status: > > I started to work on idea of 802.11 generic stack. I start from code by Dave. > > This far I fixed it to compile for 2.6 (Makefile and couple of syntax > > errors). > > I am going to implement minimum functionality, at this stage I will somehow > > publish the project. Anyone can suggest what it the right solution for > > hosting? Sourceforge? Something else? > > I can put it into the wireless-2.6 queue, which is where I would prefer > that work on a generic 802.11 stack went. This is fine with me as well. From yoshfuji@linux-ipv6.org Sun Sep 12 17:49:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 17:50:03 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D0nwj8012414 for ; Sun, 12 Sep 2004 17:49:58 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id AAFE933CE7; Mon, 13 Sep 2004 09:49:50 +0900 (JST) Date: Mon, 13 Sep 2004 09:49:50 +0900 (JST) Message-Id: <20040913.094950.47321151.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6: fix an oops in rt6_device_match() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040912163216.7f49673a.davem@davemloft.net> References: <20040911.201029.21582458.yoshfuji@linux-ipv6.org> <20040912163216.7f49673a.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 550 Lines: 14 In article <20040912163216.7f49673a.davem@davemloft.net> (at Sun, 12 Sep 2004 16:32:16 -0700), "David S. Miller" says: > > Well, rt->rt6i_idev is always set if it is dynamically allocated. > > However, when we hit ip6_null_entry here, its rt6i_idev is NULL. > > This patch is minimum fix to avoid the oops for now. > > > > Signed-off-by: Hideaki YOSHIFUJI > > Ok, as long as we fix this more cleanly eventually. Thanks. I'll revisit when we introduce more users (per-interface stats.). --yoshfuji From fernando@gont.com.ar Sun Sep 12 18:26:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 18:26:10 -0700 (PDT) Received: from libertad.frh.utn.edu.ar ([170.210.17.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D1PxTX013518 for ; Sun, 12 Sep 2004 18:26:01 -0700 Received: from fernando.gont.com.ar ([200.68.210.61]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id XAA28049 for ; Sun, 12 Sep 2004 23:03:09 -0400 Message-Id: <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Sep 2004 22:40:04 -0300 To: netdev@oss.sgi.com From: Fernando Gont Subject: ICMP attacks against TCP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fernando@gont.com.ar Precedence: bulk X-list: netdev Content-Length: 1375 Lines: 34 Folks, I'm the author of an IETF Internet Draft that discusses the use of ICMP to perform a number of attacks against TCP and other similar protocols. The draft can be found at: http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-01.txt The draft proposes some work-arounds that eliminate or minimize the impact of these attacks. For example, one of the proposed work-arounds is to check the TCP sequence number that is included in the payload of ICMP error messages. While this check has been implemented in a number of TCP/IP stack implementations (including Linux), it has never been officially documented. There are some other work-arounds (for example, ignoring ICMP Source Quench messages) are not implemented in Linux, though. I'd appreciate any comments on the draft. Both for those work-arounds implemented by Linux, and for those that aren't. Thus, I'd be able to address your comments in the next revision of the draft, and will also sum-up your feedback and post it to the relevant IETF mailing list (that of the TCPM WG mailing-list). In case there's consensus that the proposed fixes are the right way to go, it will probably help to move the draft forward, and thus maybe the proposed work-arounds will be adopted by other TCP/IP stack implementations. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From andy.grover@gmail.com Sun Sep 12 19:52:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 19:53:00 -0700 (PDT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.248]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D2qt71015372 for ; Sun, 12 Sep 2004 19:52:56 -0700 Received: by mproxy.gmail.com with SMTP id w41so28100cwb for ; Sun, 12 Sep 2004 19:52:43 -0700 (PDT) Received: by 10.11.116.68 with SMTP id o68mr19886cwc; Sun, 12 Sep 2004 19:52:43 -0700 (PDT) Received: by 10.11.99.70 with HTTP; Sun, 12 Sep 2004 19:52:43 -0700 (PDT) Message-ID: Date: Sun, 12 Sep 2004 19:52:43 -0700 From: Andrew Grover Reply-To: Andrew Grover To: hadi@cyberus.ca Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Cc: Jeff Garzik , Andi Kleen , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <1095010469.2344.215.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912161604.GA23366@havoc.gtf.org> <1095010469.2344.215.camel@jzny.localdomain> X-archive-position: 8701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.grover@gmail.com Precedence: bulk X-list: netdev Content-Length: 797 Lines: 20 On 12 Sep 2004 13:34:30 -0400, jamal wrote: > On Sun, 2004-09-12 at 12:16, Jeff Garzik wrote: > > Thanks, but still need a patch for return value constants, otherwise you > > are compounding rather than addressing a current problem. > > Something along the lines of attached patch? > Francois needs to update the doc and you need someone to get the > janitors enthusiastic (i just updated e1000) +#define NETDEV_TX_OK 0 /* driver took care of packet */ +#define NETDEV_TX_BUSY 1 /* driver tx path was busy*/ +#define NETDEV_TX_LOCKED -1 /* driver tx lock was already taken */ Why is TX_LOCKED -1 instead of, say, 2? (The actual values are now irrelevant, right? Non sequential consts makes one think their value is still important in some way. Maybe it's just me.) -- Andy From tj@home-tj.org Sun Sep 12 22:03:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 22:03:17 -0700 (PDT) Received: from hemosu.com ([211.58.254.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D538Jm021081 for ; Sun, 12 Sep 2004 22:03:09 -0700 Received: (qmail 23204 invoked by uid 666); 13 Sep 2004 13:50:36 +0900 Received: from unknown (HELO atj.dyndns.org) (61.34.11.212) by 0 (qmail 1.03 + ejcp v14) with SMTP; 13 Sep 2004 13:50:36 +0900 Received: from tj by atj.dyndns.org with local (Exim 4.34) id 1C6izP-0008W5-FE for netdev@oss.sgi.com; Mon, 13 Sep 2004 14:02:55 +0900 Date: Mon, 13 Sep 2004 14:02:55 +0900 To: netdev@oss.sgi.com Subject: [PATCHES] via-velocity fixes Message-ID: <20040913050255.GA32549@home-tj.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i From: Tejun Heo X-archive-position: 8702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tj@home-tj.org Precedence: bulk X-list: netdev Content-Length: 14796 Lines: 469 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've encountered some problems (packet loss, duplicate truncated packets, hang) w/ recent rd ring related updates to via-veolcity. I'm attaching 8 patches to fix the problem and some other bugs. I'm attaching the following 8 patches. Detailed description is at the head of each patch file. 00velocity_nics.patch : velocity_nics management fix 01velocity_xmit_lock.patch : unused xmit_lock removed 02velocity_give_rx_desc.patch : give_rx_desc removed 03velocity_rd_ring.patch : rd ring fix (it was the offending bug) 04velocity_init.patch : init related bug fix 05velocity_cpu_to_le32.patch : removes cpu_to_le32(OWNED_BY_NIC) 06velocity_init_td_ring.patch : init_td_ring index calculation fix 07velocity_comment.patch : comment fixes Thanks. -- tejun --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="00velocity_nics.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 12:47:24+09:00 tj@cl.aratech.co.kr # velocity_nics wasn't managed properly. Fixed. # # drivers/net/via-velocity.c # 2004/09/13 12:47:12+09:00 tj@cl.aratech.co.kr +5 -2 # velocity_nics wasn't managed properly. Fixed. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:48:15 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:48:15 +09:00 @@ -359,6 +359,8 @@ pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); free_netdev(dev); + + velocity_nics--; } /** @@ -695,7 +697,7 @@ struct mac_regs * regs; int ret = -ENOMEM; - if (velocity_nics++ >= MAX_UNITS) { + if (velocity_nics >= MAX_UNITS) { printk(KERN_NOTICE VELOCITY_NAME ": already found %d NICs.\n", velocity_nics); return -ENODEV; @@ -762,7 +764,7 @@ dev->dev_addr[i] = readb(®s->PAR[i]); - velocity_get_options(&vptr->options, velocity_nics - 1, dev->name); + velocity_get_options(&vptr->options, velocity_nics, dev->name); /* * Mask out the options cannot be set to the chip @@ -817,6 +819,7 @@ spin_unlock_irqrestore(&velocity_dev_list_lock, flags); } #endif + velocity_nics++; out: return ret; --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="01velocity_xmit_lock.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 12:49:36+09:00 tj@cl.aratech.co.kr # removed unused velocity_info.xmit_lock # # drivers/net/via-velocity.h # 2004/09/13 12:49:25+09:00 tj@cl.aratech.co.kr +0 -1 # removed unused velocity_info.xmit_lock # # drivers/net/via-velocity.c # 2004/09/13 12:49:25+09:00 tj@cl.aratech.co.kr +0 -3 # removed unused velocity_info.xmit_lock # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:48:34 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:48:34 +09:00 @@ -872,10 +872,7 @@ vptr->io_size = info->io_size; vptr->num_txq = info->txqueue; vptr->multicast_limit = MCAM_SIZE; - spin_lock_init(&vptr->lock); - spin_lock_init(&vptr->xmit_lock); - INIT_LIST_HEAD(&vptr->list); } diff -Nru a/drivers/net/via-velocity.h b/drivers/net/via-velocity.h --- a/drivers/net/via-velocity.h 2004-09-13 13:48:34 +09:00 +++ b/drivers/net/via-velocity.h 2004-09-13 13:48:34 +09:00 @@ -1792,7 +1792,6 @@ u8 mCAMmask[(MCAM_SIZE / 8)]; spinlock_t lock; - spinlock_t xmit_lock; int wol_opts; u8 wol_passwd[6]; --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="02velocity_give_rx_desc.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 12:55:57+09:00 tj@cl.aratech.co.kr # In velocity_give_rx_desc(), there should be a wmb() between resetting # the first four bytes of rdesc0 and setting owner. As resetting the # first four bytes isn't necessary, I just removed the function and # directly set owner. Another rationale for removing the function: # The function doesn't handle synchronization. We should do wmb() # before calling the function. So, I think using bare assignment # makes the fact more explicit. # # drivers/net/via-velocity.c # 2004/09/13 12:55:46+09:00 tj@cl.aratech.co.kr +2 -8 # In velocity_give_rx_desc(), there should be a wmb() between resetting # the first four bytes of rdesc0 and setting owner. As resetting the # first four bytes isn't necessary, I just removed the function and # directly set owner. Another rationale for removing the function: # The function doesn't handle synchronization. We should do wmb() # before calling the function. So, I think using bare assignment # makes the fact more explicit. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:49:01 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:49:01 +09:00 @@ -492,12 +492,6 @@ } } -static inline void velocity_give_rx_desc(struct rx_desc *rd) -{ - *(u32 *)&rd->rdesc0 = 0; - rd->rdesc0.owner = cpu_to_le32(OWNED_BY_NIC); -} - /** * velocity_rx_reset - handle a receive reset * @vptr: velocity we are resetting @@ -518,7 +512,7 @@ * Init state, all RD entries belong to the NIC */ for (i = 0; i < vptr->options.numrx; ++i) - velocity_give_rx_desc(vptr->rd_ring + i); + vptr->rd_ring[i].rdesc0.owner = OWNED_BY_NIC; writew(vptr->options.numrx, ®s->RBRDU); writel(vptr->rd_pool_dma, ®s->RDBaseLo); @@ -1028,7 +1022,7 @@ dirty = vptr->rd_dirty - unusable + 1; for (avail = vptr->rd_filled & 0xfffc; avail; avail--) { dirty = (dirty > 0) ? dirty - 1 : vptr->options.numrx - 1; - velocity_give_rx_desc(vptr->rd_ring + dirty); + vptr->rd_ring[dirty].rdesc0.owner = OWNED_BY_NIC; } writew(vptr->rd_filled & 0xfffc, ®s->RBRDU); --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="03velocity_rd_ring.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 13:26:10+09:00 tj@cl.aratech.co.kr # via-velocity receive ring related bugs fixed. # # drivers/net/via-velocity.c # 2004/09/13 13:25:54+09:00 tj@cl.aratech.co.kr +10 -7 # There were several receive ring related bugs. # # In velocity_give_many_rx_descs(), index calculation was incorrect. # This and bugs in velocity_rx_srv() described in the following # paragraph caused packet loss, truncation and infinite error # interrupt generation. # # In velocity_rx_srv(), velocity_rx_refill() could be called without # any dirty slot. With proper timing, This can result in refilling # yet unreceived packets and pushing dirty pointer ahead of the current # pointer. And vptr->rd_curr which is used by velocity_rx_refill() # was updated after calling velocity_rx_refill() thus screwing # receive descriptor ring. Also, between checking owner and reading # the packet, rmb() is missing. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:49:15 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:49:15 +09:00 @@ -1018,8 +1018,8 @@ wmb(); - unusable = vptr->rd_filled | 0x0003; - dirty = vptr->rd_dirty - unusable + 1; + unusable = vptr->rd_filled & 0x0003; + dirty = vptr->rd_dirty - unusable; for (avail = vptr->rd_filled & 0xfffc; avail; avail--) { dirty = (dirty > 0) ? dirty - 1 : vptr->options.numrx - 1; vptr->rd_ring[dirty].rdesc0.owner = OWNED_BY_NIC; @@ -1232,15 +1232,17 @@ int rd_curr = vptr->rd_curr; int works = 0; - while (1) { + do { struct rx_desc *rd = vptr->rd_ring + rd_curr; - if (!vptr->rd_info[rd_curr].skb || (works++ > 15)) + if (!vptr->rd_info[rd_curr].skb) break; if (rd->rdesc0.owner == OWNED_BY_NIC) break; + rmb(); + /* * Don't drop CE or RL error frame although RXOK is off */ @@ -1263,14 +1265,15 @@ rd_curr++; if (rd_curr >= vptr->options.numrx) rd_curr = 0; - } + } while (++works <= 15); - if (velocity_rx_refill(vptr) < 0) { + vptr->rd_curr = rd_curr; + + if (works > 0 && velocity_rx_refill(vptr) < 0) { VELOCITY_PRT(MSG_LEVEL_ERR, KERN_ERR "%s: rx buf allocation failure\n", vptr->dev->name); } - vptr->rd_curr = rd_curr; VAR_USED(stats); return works; } --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="04velocity_init.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 13:27:53+09:00 tj@cl.aratech.co.kr # via-velocity init related bug fixes. # # drivers/net/via-velocity.c # 2004/09/13 13:27:36+09:00 tj@cl.aratech.co.kr +5 -4 # In velocity_init_registers(), init_cam_filter() clears mCAMmask # which might have been set by set_multi() (not sure if this can ever # occur). Modified to invoke init_cam_filter() first. Also, # clear_isr() is called twice. Removed the first invocation. # # In velocity_founc1(), there was a unneeded assignment from vptr to # dev->priv. Removed. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:49:37 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:49:37 +09:00 @@ -592,6 +592,11 @@ BYTE_REG_BITS_SET(CFGB_OFSET, (CFGB_CRANDOM | CFGB_CAP | CFGB_MBA | CFGB_BAKOPT), ®s->CFGB); /* + * Init CAM filter + */ + velocity_init_cam_filter(vptr); + + /* * Set packet filter: Receive directed and broadcast address */ velocity_set_multi(vptr->dev); @@ -615,8 +620,6 @@ mac_tx_queue_run(regs, i); } - velocity_init_cam_filter(vptr); - init_flow_control_register(vptr); writel(CR0_STOP, ®s->CR0Clr); @@ -624,7 +627,6 @@ mii_status = velocity_get_opt_media_mode(vptr); netif_stop_queue(vptr->dev); - mac_clear_isr(regs); mii_init(vptr, mii_status); @@ -723,7 +725,6 @@ vptr->dev = dev; - dev->priv = vptr; dev->irq = pdev->irq; ret = pci_enable_device(pdev); --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="05velocity_cpu_to_le32.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 13:31:48+09:00 tj@cl.aratech.co.kr # via-velocity minor fix. # # drivers/net/via-velocity.c # 2004/09/13 13:31:37+09:00 tj@cl.aratech.co.kr +1 -1 # Removed cpu_to_le32 call on OWNED_BY_NIC. This will produce # 0x01000000 on big endian machines while rdesc0.owner still evaluates # to 0x00000000 or 0x00000001. BTW, unless we reorder bit fields on # big endian machines or use u32's and cpu_to_le32'd bit mask macros, # current code won't work on big endian machines. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:51:04 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:51:04 +09:00 @@ -1038,7 +1038,7 @@ struct rx_desc *rd = vptr->rd_ring + dirty; /* Fine for an all zero Rx desc at init time as well */ - if (rd->rdesc0.owner == cpu_to_le32(OWNED_BY_NIC)) + if (rd->rdesc0.owner == OWNED_BY_NIC) break; if (!vptr->rd_info[dirty].skb) { --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="06velocity_init_td_ring.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 13:33:21+09:00 tj@cl.aratech.co.kr # via-velocity another init bug fixed. # # drivers/net/via-velocity.c # 2004/09/13 13:33:10+09:00 tj@cl.aratech.co.kr +4 -2 # Buffer offset calculation was incorrect in velocity_init_td_ring(). # This didn't cause any trouble because we only use the first td ring. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:51:26 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:51:26 +09:00 @@ -1156,8 +1156,10 @@ for (i = 0; i < vptr->options.numtx; i++, curr += sizeof(struct tx_desc)) { td = &(vptr->td_rings[j][i]); td_info = &(vptr->td_infos[j][i]); - td_info->buf = vptr->tx_bufs + (i + j) * PKT_BUF_SZ; - td_info->buf_dma = vptr->tx_bufs_dma + (i + j) * PKT_BUF_SZ; + td_info->buf = vptr->tx_bufs + + (j * vptr->options.numtx + i) * PKT_BUF_SZ; + td_info->buf_dma = vptr->tx_bufs_dma + + (j * vptr->options.numtx + i) * PKT_BUF_SZ; } vptr->td_tail[j] = vptr->td_curr[j] = vptr->td_used[j] = 0; } --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="07velocity_comment.patch" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 13:37:46+09:00 tj@cl.aratech.co.kr # via-velocity comment fixes. # # drivers/net/via-velocity.h # 2004/09/13 13:37:35+09:00 tj@cl.aratech.co.kr +3 -3 # Comment fixes. # # drivers/net/via-velocity.c # 2004/09/13 13:37:35+09:00 tj@cl.aratech.co.kr +3 -3 # Comment fixes. # diff -Nru a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c --- a/drivers/net/via-velocity.c 2004-09-13 13:51:42 +09:00 +++ b/drivers/net/via-velocity.c 2004-09-13 13:51:42 +09:00 @@ -464,7 +464,7 @@ { struct mac_regs * regs = vptr->mac_regs; - /* T urn on MCFG_PQEN, turn off MCFG_RTGOPT */ + /* Turn on MCFG_PQEN, turn off MCFG_RTGOPT */ WORD_REG_BITS_SET(MCFG_PQEN, MCFG_RTGOPT, ®s->MCFG); WORD_REG_BITS_ON(MCFG_VIDFR, ®s->MCFG); @@ -587,7 +587,7 @@ writeb(WOLCFG_SAM | WOLCFG_SAB, ®s->WOLCFGSet); /* - * Bback off algorithm use original IEEE standard + * Back off algorithm use original IEEE standard */ BYTE_REG_BITS_SET(CFGB_OFSET, (CFGB_CRANDOM | CFGB_CAP | CFGB_MBA | CFGB_BAKOPT), ®s->CFGB); @@ -1091,7 +1091,7 @@ } /** - * velocity_free_rd_ring - set up receive ring + * velocity_free_rd_ring - free receive ring * @vptr: velocity to clean up * * Free the receive buffers for each ring slot and any diff -Nru a/drivers/net/via-velocity.h b/drivers/net/via-velocity.h --- a/drivers/net/via-velocity.h 2004-09-13 13:51:42 +09:00 +++ b/drivers/net/via-velocity.h 2004-09-13 13:51:42 +09:00 @@ -1319,7 +1319,7 @@ /* disable CAMEN */ writeb(0, ®s->CAMADDR); - /* Select CAM mask */ + /* Select mar */ BYTE_REG_BITS_SET(CAMCR_PS_MAR, CAMCR_PS1 | CAMCR_PS0, ®s->CAMCR); } @@ -1360,7 +1360,7 @@ writeb(0, ®s->CAMADDR); - /* Select CAM mask */ + /* Select mar */ BYTE_REG_BITS_SET(CAMCR_PS_MAR, CAMCR_PS1 | CAMCR_PS0, ®s->CAMCR); } @@ -1401,7 +1401,7 @@ writeb(0, ®s->CAMADDR); - /* Select CAM mask */ + /* Select mar */ BYTE_REG_BITS_SET(CAMCR_PS_MAR, CAMCR_PS1 | CAMCR_PS0, ®s->CAMCR); } --h31gzZEtNLTqOjlF-- From i@stingr.net Sun Sep 12 22:17:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 22:17:25 -0700 (PDT) Received: from stingr.net (stingr.net [212.193.32.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D5HHC7021601 for ; Sun, 12 Sep 2004 22:17:20 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by stingr.net (Postfix) with ESMTP id 36AD3407B; Mon, 13 Sep 2004 09:17:07 +0400 (MSD) Received: from stingr.net ([127.0.0.1]) by localhost (stingr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02332-01-3; Mon, 13 Sep 2004 09:17:06 +0400 (MSD) Received: by stingr.net (Postfix, from userid 1000) id 343CC42B9; Mon, 13 Sep 2004 09:17:06 +0400 (MSD) Date: Mon, 13 Sep 2004 09:17:06 +0400 From: Paul P Komkoff Jr To: "David S. Miller" Cc: Paul P Komkoff Jr , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-ID: <20040913051706.GB26337@stingr.sgu.ru> Mail-Followup-To: "David S. Miller" , Paul P Komkoff Jr , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040912170505.62916147.davem@davemloft.net> User-Agent: Agent Darien Fawkes X-Mailer: Intel Ultra ATA Storage Driver X-RealName: Stingray Greatest Jr Organization: Department of Fish & Wildlife X-Virus-Scanned: by amavisd-new at stingr.net X-archive-position: 8703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: i@stingr.net Precedence: bulk X-list: netdev Content-Length: 2670 Lines: 64 Replying to David S. Miller: > What are the rules for IP_GRE in general for when > to apply this transformation? As you can see, I am applying it unconditionally when fits. For most cases, this will be OK. There can be situations when this is not wanted (for example, when debugging something), so in general, tuning knob will be useful, but I just don't know where to add it, maybe tunnel->parms.i_flags ... > Please do me a favor also, and redo your patch by putting > ETH_P_WCCP into include/linux/if_ether.h where it belongs. Done. > Thanks. diff -urN /usr/src/linux-2.6.8-1.521/include/linux/if_ether.h linux-2.6.8-1.521wccp/include/linux/if_ether.h --- /usr/src/linux-2.6.8-1.521/include/linux/if_ether.h 2004-08-14 09:37:15.000000000 +0400 +++ linux-2.6.8-1.521wccp/include/linux/if_ether.h 2004-09-13 08:51:02.707155288 +0400 @@ -59,6 +59,8 @@ #define ETH_P_8021Q 0x8100 /* 802.1Q VLAN Extended Header */ #define ETH_P_IPX 0x8137 /* IPX over DIX */ #define ETH_P_IPV6 0x86DD /* IPv6 over bluebook */ +#define ETH_P_WCCP 0x883E /* Web-cache coordination protocol + * defined in draft-wilson-wrec-wccp-v2-00.txt */ #define ETH_P_PPP_DISC 0x8863 /* PPPoE discovery messages */ #define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */ #define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */ diff -urN /usr/src/linux-2.6.8-1.521/net/ipv4/ip_gre.c linux-2.6.8-1.521wccp/net/ipv4/ip_gre.c --- /usr/src/linux-2.6.8-1.521/net/ipv4/ip_gre.c 2004-08-14 09:37:37.000000000 +0400 +++ linux-2.6.8-1.521wccp/net/ipv4/ip_gre.c 2004-09-13 09:02:33.293170256 +0400 @@ -605,13 +605,25 @@ if ((tunnel = ipgre_tunnel_lookup(iph->saddr, iph->daddr, key)) != NULL) { secpath_reset(skb); + skb->protocol = *(u16*)(h + 2); + /* WCCP version 1 and 2 protocol decoding. + * - Change protocol to IP + * - When dealing with WCCPv2, Skip extra 4 bytes in GRE header + */ + if (1) { + if ((flags == 0) && (skb->protocol == __constant_htons(ETH_P_WCCP))) { + skb->protocol = __constant_htons(ETH_P_IP); + if ((*(h + offset) & 0xF0) != 0x40) + offset += 4; + } + } + skb->mac.raw = skb->nh.raw; skb->nh.raw = __pskb_pull(skb, offset); memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); if (skb->ip_summed == CHECKSUM_HW) skb->csum = csum_sub(skb->csum, csum_partial(skb->mac.raw, skb->nh.raw-skb->mac.raw, 0)); - skb->protocol = *(u16*)(h + 2); skb->pkt_type = PACKET_HOST; #ifdef CONFIG_NET_IPGRE_BROADCAST if (MULTICAST(iph->daddr)) { -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From vkondra@mail.ru Sun Sep 12 22:39:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 22:39:55 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D5dm7I022459 for ; Sun, 12 Sep 2004 22:39:49 -0700 Received: from [81.218.113.45] (port=27908 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C6jYu-000AXJ-00; Mon, 13 Sep 2004 09:39:38 +0400 From: Vladimir Kondratiev To: "David S. Miller" Subject: Re: generic 802.11 stack Date: Mon, 13 Sep 2004 08:39:08 +0300 User-Agent: KMail/1.7 Cc: greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409122103.21770.vkondra@mail.ru> <20040912171448.64ce7dbe.davem@davemloft.net> In-Reply-To: <20040912171448.64ce7dbe.davem@davemloft.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1490864.NcpDN8EAu7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409130839.15988.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1216 Lines: 42 --nextPart1490864.NcpDN8EAu7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dave, Thanks, I'll post patches to you. Jeff: what would you say? I think it is great if it will went through Dave= =20 with his review. Vladimir. On Monday 13 September 2004 03:14, David S. Miller wrote: DS> On Sun, 12 Sep 2004 21:03:13 +0300 DS> Vladimir Kondratiev wrote: DS> DS> > I am going to implement minimum functionality, at this stage I will somehow DS> > publish the project. Anyone can suggest what it the right solution for DS> > hosting? Sourceforge? Something else? DS> DS> I am willing to host things for you, if you wish. DS> I can make a directory in my personal area on ftp.kernel.org DS> and that's where I'd put your patches. DS> DS> I'd also like to help review your patches, so I can perform DS> both things at the same time. --nextPart1490864.NcpDN8EAu7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBRTKDqxdj7mhC6o0RAve4AJ99B2hZ5QzHKR3gSByex4s5nc0jWQCeP+Iz 0ggXVgrJnLTWP1ALJc5VM8c= =YIFX -----END PGP SIGNATURE----- --nextPart1490864.NcpDN8EAu7-- From jgarzik@pobox.com Sun Sep 12 22:51:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 22:51:12 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D5p5O0022878 for ; Sun, 12 Sep 2004 22:51:06 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6jjo-0007eh-4Z; Mon, 13 Sep 2004 06:50:52 +0100 Message-ID: <4145352F.4040807@pobox.com> Date: Mon, 13 Sep 2004 01:50:39 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: "David S. Miller" , greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409122103.21770.vkondra@mail.ru> <20040912171448.64ce7dbe.davem@davemloft.net> <200409130839.15988.vkondra@mail.ru> In-Reply-To: <200409130839.15988.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 440 Lines: 17 Vladimir Kondratiev wrote: > Dave, > Thanks, I'll post patches to you. > > Jeff: what would you say? I think it is great if it will went through Dave > with his review. You are the one doing the work. Which would you prefer? :) You could always send patches to netdev@oss.sgi.com and CC jgarzik@pobox.com and davem@davemloft.net. DaveM could review, and I could apply to wireless-2.6, then post a snapshot on kernel.org. Jeff From jgarzik@pobox.com Sun Sep 12 23:03:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 23:03:59 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D63sAw023533 for ; Sun, 12 Sep 2004 23:03:54 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6jwC-00080r-Sb; Mon, 13 Sep 2004 07:03:41 +0100 Message-ID: <41453830.9060708@pobox.com> Date: Mon, 13 Sep 2004 02:03:28 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tejun Heo CC: netdev@oss.sgi.com Subject: Re: [PATCHES] via-velocity fixes References: <20040913050255.GA32549@home-tj.org> In-Reply-To: <20040913050255.GA32549@home-tj.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 837 Lines: 22 Tejun Heo wrote: > Hello, I've encountered some problems (packet loss, duplicate > truncated packets, hang) w/ recent rd ring related updates to > via-veolcity. I'm attaching 8 patches to fix the problem and some > other bugs. I'm attaching the following 8 patches. Detailed > description is at the head of each patch file. > > 00velocity_nics.patch : velocity_nics management fix > 01velocity_xmit_lock.patch : unused xmit_lock removed > 02velocity_give_rx_desc.patch : give_rx_desc removed > 03velocity_rd_ring.patch : rd ring fix (it was the offending bug) > 04velocity_init.patch : init related bug fix > 05velocity_cpu_to_le32.patch : removes cpu_to_le32(OWNED_BY_NIC) > 06velocity_init_td_ring.patch : init_td_ring index calculation fix > 07velocity_comment.patch : comment fixes I'm reviewing these now, thanks. Jeff From ak@suse.de Sun Sep 12 23:28:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 12 Sep 2004 23:28:18 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D6SCCc024211 for ; Sun, 12 Sep 2004 23:28:13 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D95F3BD21CB; Mon, 13 Sep 2004 08:26:17 +0200 (CEST) Date: Mon, 13 Sep 2004 08:26:13 +0200 From: Andi Kleen To: "David S. Miller" Cc: Thomas Graf , ak@suse.de, netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040913062613.GA12185@wotan.suse.de> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <20040912163744.52f95367.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912163744.52f95367.davem@davemloft.net> X-archive-position: 8707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 938 Lines: 28 On Sun, Sep 12, 2004 at 04:37:44PM -0700, David S. Miller wrote: > On Sat, 11 Sep 2004 18:24:33 +0200 > Thomas Graf wrote: > > > > I don't think an very specific error like > > > "CFQ subsystem parameter X is FOO, can be only upto BAR" > > > can be nicely put into a global error file. > > > > True, I would really like to have such error messages. > > I'd love to have them too. > > But I know internationalization folks are going to > scream, although it will obviously be better than > no messages at all. I actually don't think it will be a big issue for them. They already translate messages by mapping text to other text. The same thing could be done for kernel messages, by just marking them in the kernel somehow that they can be automatically extracted from the source and then later mapping them to the translations in user space. But I wouldn't do it until someone actually complains about it. -Andi From ak@suse.de Mon Sep 13 00:03:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 00:03:12 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8D734oU025178 for ; Mon, 13 Sep 2004 00:03:07 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id BB9E8BCEC6F; Mon, 13 Sep 2004 09:00:00 +0200 (CEST) Date: Mon, 13 Sep 2004 08:59:58 +0200 From: Andi Kleen To: Jeff Garzik Cc: Andi Kleen , "David S. Miller" , hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 Message-ID: <20040913065958.GC12185@wotan.suse.de> References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912161604.GA23366@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040912161604.GA23366@havoc.gtf.org> X-archive-position: 8708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 343 Lines: 11 On Sun, Sep 12, 2004 at 12:16:05PM -0400, Jeff Garzik wrote: > Incorrect, you are changing the callsites, which -does- affect every > driver. Please read the code before making such claims. The new return code is _only_ checked when NETIF_F_LLTX is set. A driver that doesn't set this new flag won't ever recognize any difference. -Andi From elueck@de.ibm.com Mon Sep 13 03:36:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 03:36:49 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DAafiB002325 for ; Mon, 13 Sep 2004 03:36:42 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8DAaQLi097192; Mon, 13 Sep 2004 10:36:26 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8DAaPEs106078; Mon, 13 Sep 2004 12:36:25 +0200 Message-ID: <4145782A.4040107@de.ibm.com> Date: Mon, 13 Sep 2004 12:36:26 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [RFC][PATCH 1/2] ip routing - split of ip_route_[in|out]put_slow Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 18323 Lines: 623 We propose the following patch for splitting up ip_route_[in|out]put_slow in inlined functions for two reasons: * improve overall comprehensibility (up to now these functions are very large) * allow for an easier application of a further patch (please: refer to the subsequent patch for multipath support with routing cache support) Regards, Einar diff -ruN linux-2.6.8.1/net/ipv4/route.c linux-2.6.8.1.split/net/ipv4/route.c --- linux-2.6.8.1/net/ipv4/route.c 2004-09-09 20:47:02.000000000 +0200 +++ linux-2.6.8.1.split/net/ipv4/route.c 2004-09-09 20:56:35.000000000 +0200 @@ -104,6 +104,9 @@ #include #endif +#define RT_FL_TOS(oldflp) \ + ((u32)(oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK))) + #define IP_MAX_MTU 0xFFF0 #define RT_GC_TIMEOUT (300*HZ) @@ -143,6 +146,7 @@ static void ipv4_link_failure(struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu); static int rt_garbage_collect(void); +static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); static struct dst_ops ipv4_dst_ops = { @@ -1528,6 +1532,168 @@ return -EINVAL; } + +static inline void ip_handle_martian_source(struct net_device *dev, + struct in_device *in_dev, + struct sk_buff *skb, + u32 daddr, + u32 saddr) { + RT_CACHE_STAT_INC(in_martian_src); +#ifdef CONFIG_IP_ROUTE_VERBOSE + if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { + /* + * RFC1812 recommendation, if source is martian, + * the only hint is MAC header. + */ + printk(KERN_WARNING "martian source %u.%u.%u.%u from " + "%u.%u.%u.%u, on dev %s\n", + NIPQUAD(daddr), NIPQUAD(saddr), dev->name); + if (dev->hard_header_len) { + int i; + unsigned char *p = skb->mac.raw; + printk(KERN_WARNING "ll header: "); + for (i = 0; i < dev->hard_header_len; i++, p++) { + printk("%02x", *p); + if (i < (dev->hard_header_len - 1)) + printk(":"); + } + printk("\n"); + } + } +#endif +} + +static inline int __mkroute_input(struct sk_buff *skb, + struct fib_result* res, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos, + struct rtable **result) +{ + + struct rtable *rth; + int err; + struct in_device *out_dev; + unsigned flags = 0; + u32 spec_dst, itag; + + /* get a working reference to the output device */ + out_dev = in_dev_get(FIB_RES_DEV(*res)); + if (out_dev == NULL) { + if (net_ratelimit()) + printk(KERN_CRIT "Bug in ip_route_input" \ + "_slow(). Please, report\n"); + return -EINVAL; + } + + + err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(*res), + in_dev->dev, &spec_dst, &itag); + if (err < 0) { + ip_handle_martian_source(in_dev->dev, in_dev, skb, daddr, + saddr); + + err = -EINVAL; + goto cleanup; + } + + if (err) + flags |= RTCF_DIRECTSRC; + + if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && + (IN_DEV_SHARED_MEDIA(out_dev) || + inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) + flags |= RTCF_DOREDIRECT; + + if (skb->protocol != htons(ETH_P_IP)) { + /* Not IP (i.e. ARP). Do not create route, if it is + * invalid for proxy arp. DNAT routes are always valid. + */ + if (out_dev == in_dev && !(flags & RTCF_DNAT)) { + err = -EINVAL; + goto cleanup; + } + } + + + rth = dst_alloc(&ipv4_dst_ops); + if (!rth) { + err = -ENOBUFS; + goto cleanup; + } + + rth->u.dst.flags= DST_HOST; + if (in_dev->cnf.no_policy) + rth->u.dst.flags |= DST_NOPOLICY; + if (in_dev->cnf.no_xfrm) + rth->u.dst.flags |= DST_NOXFRM; + rth->fl.fl4_dst = daddr; + rth->rt_dst = daddr; + rth->fl.fl4_tos = tos; +#ifdef CONFIG_IP_ROUTE_FWMARK + rth->fl.fl4_fwmark= skb->nfmark; +#endif + rth->fl.fl4_src = saddr; + rth->rt_src = saddr; + rth->rt_gateway = daddr; + rth->rt_iif = + rth->fl.iif = in_dev->dev->ifindex; + rth->u.dst.dev = (out_dev)->dev; + dev_hold(rth->u.dst.dev); + rth->idev = in_dev_get(rth->u.dst.dev); + rth->fl.oif = 0; + rth->rt_spec_dst= spec_dst; + + rth->u.dst.input = ip_forward; + rth->u.dst.output = ip_output; + + rt_set_nexthop(rth, res, itag); + + rth->rt_flags = flags; + + *result = rth; + err = 0; + cleanup: + /* release the working reference to the output device */ + in_dev_put(out_dev); + return err; +} + +static inline int ip_mkroute_input_def(struct sk_buff *skb, + struct fib_result* res, + const struct flowi *fl, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos) +{ + struct rtable* rth; + int err; + unsigned hash; + +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (res->fi->fib_nhs > 1 && fl->oif == 0) + fib_select_multipath(fl, res); +#endif + + /* create a routing cache entry */ + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, &rth ); + if ( err ) + return err; + atomic_set(&rth->u.dst.__refcnt, 1); + + /* put it into the cache */ + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); + return rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); +} + +static inline int ip_mkroute_input(struct sk_buff *skb, + struct fib_result* res, + const struct flowi *fl, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos) +{ + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); +} + + /* * NOTE. We drop all the packets that has local source * addresses, because every properly looped back packet @@ -1539,11 +1705,10 @@ */ static int ip_route_input_slow(struct sk_buff *skb, u32 daddr, u32 saddr, - u8 tos, struct net_device *dev) + u8 tos, struct net_device *dev) { struct fib_result res; struct in_device *in_dev = in_dev_get(dev); - struct in_device *out_dev = NULL; struct flowi fl = { .nl_u = { .ip4_u = { .daddr = daddr, .saddr = saddr, @@ -1567,8 +1732,6 @@ if (!in_dev) goto out; - hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); - /* Check for the most weird martians, which can be not detected by fib_lookup. */ @@ -1621,79 +1784,14 @@ if (res.type != RTN_UNICAST) goto martian_destination; -#ifdef CONFIG_IP_ROUTE_MULTIPATH - if (res.fi->fib_nhs > 1 && fl.oif == 0) - fib_select_multipath(&fl, &res); -#endif - out_dev = in_dev_get(FIB_RES_DEV(res)); - if (out_dev == NULL) { - if (net_ratelimit()) - printk(KERN_CRIT "Bug in ip_route_input_slow(). " - "Please, report\n"); - goto e_inval; - } - - err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(res), dev, - &spec_dst, &itag); - if (err < 0) - goto martian_source; - - if (err) - flags |= RTCF_DIRECTSRC; - - if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && - (IN_DEV_SHARED_MEDIA(out_dev) || - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) - flags |= RTCF_DOREDIRECT; - - if (skb->protocol != htons(ETH_P_IP)) { - /* Not IP (i.e. ARP). Do not create route, if it is - * invalid for proxy arp. DNAT routes are always valid. - */ - if (out_dev == in_dev && !(flags & RTCF_DNAT)) - goto e_inval; - } - - rth = dst_alloc(&ipv4_dst_ops); - if (!rth) + err = ip_mkroute_input(skb, &res, &fl, in_dev, daddr, saddr, tos); + if ( err == -ENOBUFS ) goto e_nobufs; - - atomic_set(&rth->u.dst.__refcnt, 1); - rth->u.dst.flags= DST_HOST; - if (in_dev->cnf.no_policy) - rth->u.dst.flags |= DST_NOPOLICY; - if (in_dev->cnf.no_xfrm) - rth->u.dst.flags |= DST_NOXFRM; - rth->fl.fl4_dst = daddr; - rth->rt_dst = daddr; - rth->fl.fl4_tos = tos; -#ifdef CONFIG_IP_ROUTE_FWMARK - rth->fl.fl4_fwmark= skb->nfmark; -#endif - rth->fl.fl4_src = saddr; - rth->rt_src = saddr; - rth->rt_gateway = daddr; - rth->rt_iif = - rth->fl.iif = dev->ifindex; - rth->u.dst.dev = out_dev->dev; - dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); - rth->fl.oif = 0; - rth->rt_spec_dst= spec_dst; - - rth->u.dst.input = ip_forward; - rth->u.dst.output = ip_output; - - rt_set_nexthop(rth, &res, itag); - - rth->rt_flags = flags; - -intern: - err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + if ( err == -EINVAL ) + goto e_inval; + done: in_dev_put(in_dev); - if (out_dev) - in_dev_put(out_dev); if (free_res) fib_res_put(&res); out: return err; @@ -1753,7 +1851,9 @@ rth->rt_flags &= ~RTCF_LOCAL; } rth->rt_type = res.type; - goto intern; + hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + goto done; no_route: RT_CACHE_STAT_INC(in_no_route); @@ -1875,13 +1975,166 @@ return ip_route_input_slow(skb, daddr, saddr, tos, dev); } +static inline int __mkroute_output(struct rtable **result, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + struct rtable *rth; + struct in_device *in_dev; + u32 tos = RT_FL_TOS(oldflp); + int err = 0; + + if (LOOPBACK(fl->fl4_src) && !(dev_out->flags&IFF_LOOPBACK)) + return -EINVAL; + + if (fl->fl4_dst == 0xFFFFFFFF) + res->type = RTN_BROADCAST; + else if (MULTICAST(fl->fl4_dst)) + res->type = RTN_MULTICAST; + else if (BADCLASS(fl->fl4_dst) || ZERONET(fl->fl4_dst)) + return -EINVAL; + + if (dev_out->flags & IFF_LOOPBACK) + flags |= RTCF_LOCAL; + + /* get work reference to inet device */ + in_dev = in_dev_get(dev_out); + if (!in_dev) + return -EINVAL; + + if (res->type == RTN_BROADCAST) { + flags |= RTCF_BROADCAST | RTCF_LOCAL; + if (res->fi) { + fib_info_put(res->fi); + res->fi = NULL; + } + } else if (res->type == RTN_MULTICAST) { + flags |= RTCF_MULTICAST|RTCF_LOCAL; + if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src, + oldflp->proto)) + flags &= ~RTCF_LOCAL; + /* If multicast route do not exist use + default one, but do not gateway in this case. + Yes, it is hack. + */ + if (res->fi && res->prefixlen < 4) { + fib_info_put(res->fi); + res->fi = NULL; + } + } + + + rth = dst_alloc(&ipv4_dst_ops); + if (!rth) { + err = -ENOBUFS; + goto cleanup; + } + + rth->u.dst.flags= DST_HOST; + if (in_dev->cnf.no_xfrm) + rth->u.dst.flags |= DST_NOXFRM; + if (in_dev->cnf.no_policy) + rth->u.dst.flags |= DST_NOPOLICY; + + rth->fl.fl4_dst = oldflp->fl4_dst; + rth->fl.fl4_tos = tos; + rth->fl.fl4_src = oldflp->fl4_src; + rth->fl.oif = oldflp->oif; +#ifdef CONFIG_IP_ROUTE_FWMARK + rth->fl.fl4_fwmark= oldflp->fl4_fwmark; +#endif + rth->rt_dst = fl->fl4_dst; + rth->rt_src = fl->fl4_src; + rth->rt_iif = oldflp->oif ? : dev_out->ifindex; + /* get references to the devices that are to be hold by the routing + cache entry */ + rth->u.dst.dev = dev_out; + dev_hold(dev_out); + rth->idev = in_dev_get(dev_out); + rth->rt_gateway = fl->fl4_dst; + rth->rt_spec_dst= fl->fl4_src; + + rth->u.dst.output=ip_output; + + RT_CACHE_STAT_INC(out_slow_tot); + + if (flags & RTCF_LOCAL) { + rth->u.dst.input = ip_local_deliver; + rth->rt_spec_dst = fl->fl4_dst; + } + if (flags & (RTCF_BROADCAST | RTCF_MULTICAST)) { + rth->rt_spec_dst = fl->fl4_src; + if (flags & RTCF_LOCAL && + !(dev_out->flags & IFF_LOOPBACK)) { + rth->u.dst.output = ip_mc_output; + RT_CACHE_STAT_INC(out_slow_mc); + } +#ifdef CONFIG_IP_MROUTE + if (res->type == RTN_MULTICAST) { + if (IN_DEV_MFORWARD(in_dev) && + !LOCAL_MCAST(oldflp->fl4_dst)) { + rth->u.dst.input = ip_mr_input; + rth->u.dst.output = ip_mc_output; + } + } +#endif + } + + rt_set_nexthop(rth, res, 0); + + rth->rt_flags = flags; + + *result = rth; + cleanup: + /* release work reference to inet device */ + in_dev_put(in_dev); + + return err; +} + +static inline int ip_mkroute_output_def(struct rtable **rp, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + struct rtable *rth; + int err = __mkroute_output(&rth, res, fl, oldflp, dev_out, flags); + unsigned hash; + if ( err == 0 ) { + u32 tos = RT_FL_TOS(oldflp); + + atomic_set(&rth->u.dst.__refcnt, 1); + + hash = rt_hash_code(oldflp->fl4_dst, + oldflp->fl4_src ^ (oldflp->oif << 5), tos); + err = rt_intern_hash(hash, rth, rp); + } + + return err; +} + +static inline int ip_mkroute_output(struct rtable** rp, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); +} + /* * Major route resolver routine. */ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp) { - u32 tos = oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK); + u32 tos = RT_FL_TOS(oldflp); struct flowi fl = { .nl_u = { .ip4_u = { .daddr = oldflp->fl4_dst, .saddr = oldflp->fl4_src, @@ -1897,10 +2150,7 @@ .oif = oldflp->oif }; struct fib_result res; unsigned flags = 0; - struct rtable *rth; struct net_device *dev_out = NULL; - struct in_device *in_dev = NULL; - unsigned hash; int free_res = 0; int err; @@ -2060,116 +2310,13 @@ fl.oif = dev_out->ifindex; make_route: - if (LOOPBACK(fl.fl4_src) && !(dev_out->flags&IFF_LOOPBACK)) - goto e_inval; - - if (fl.fl4_dst == 0xFFFFFFFF) - res.type = RTN_BROADCAST; - else if (MULTICAST(fl.fl4_dst)) - res.type = RTN_MULTICAST; - else if (BADCLASS(fl.fl4_dst) || ZERONET(fl.fl4_dst)) - goto e_inval; - - if (dev_out->flags & IFF_LOOPBACK) - flags |= RTCF_LOCAL; - - in_dev = in_dev_get(dev_out); - if (!in_dev) - goto e_inval; - - if (res.type == RTN_BROADCAST) { - flags |= RTCF_BROADCAST | RTCF_LOCAL; - if (res.fi) { - fib_info_put(res.fi); - res.fi = NULL; - } - } else if (res.type == RTN_MULTICAST) { - flags |= RTCF_MULTICAST|RTCF_LOCAL; - if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src, oldflp->proto)) - flags &= ~RTCF_LOCAL; - /* If multicast route do not exist use - default one, but do not gateway in this case. - Yes, it is hack. - */ - if (res.fi && res.prefixlen < 4) { - fib_info_put(res.fi); - res.fi = NULL; - } - } - - rth = dst_alloc(&ipv4_dst_ops); - if (!rth) - goto e_nobufs; + err = ip_mkroute_output(rp, &res, &fl, oldflp, dev_out, flags); - atomic_set(&rth->u.dst.__refcnt, 1); - rth->u.dst.flags= DST_HOST; - if (in_dev->cnf.no_xfrm) - rth->u.dst.flags |= DST_NOXFRM; - if (in_dev->cnf.no_policy) - rth->u.dst.flags |= DST_NOPOLICY; - rth->fl.fl4_dst = oldflp->fl4_dst; - rth->fl.fl4_tos = tos; - rth->fl.fl4_src = oldflp->fl4_src; - rth->fl.oif = oldflp->oif; -#ifdef CONFIG_IP_ROUTE_FWMARK - rth->fl.fl4_fwmark= oldflp->fl4_fwmark; -#endif - rth->rt_dst = fl.fl4_dst; - rth->rt_src = fl.fl4_src; - rth->rt_iif = oldflp->oif ? : dev_out->ifindex; - rth->u.dst.dev = dev_out; - dev_hold(dev_out); - rth->idev = in_dev_get(dev_out); - rth->rt_gateway = fl.fl4_dst; - rth->rt_spec_dst= fl.fl4_src; - - rth->u.dst.output=ip_output; - - RT_CACHE_STAT_INC(out_slow_tot); - - if (flags & RTCF_LOCAL) { - rth->u.dst.input = ip_local_deliver; - rth->rt_spec_dst = fl.fl4_dst; - } - if (flags & (RTCF_BROADCAST | RTCF_MULTICAST)) { - rth->rt_spec_dst = fl.fl4_src; - if (flags & RTCF_LOCAL && !(dev_out->flags & IFF_LOOPBACK)) { - rth->u.dst.output = ip_mc_output; - RT_CACHE_STAT_INC(out_slow_mc); - } -#ifdef CONFIG_IP_MROUTE - if (res.type == RTN_MULTICAST) { - if (IN_DEV_MFORWARD(in_dev) && - !LOCAL_MCAST(oldflp->fl4_dst)) { - rth->u.dst.input = ip_mr_input; - rth->u.dst.output = ip_mc_output; - } - } -#endif - } - - rt_set_nexthop(rth, &res, 0); - - - rth->rt_flags = flags; - - hash = rt_hash_code(oldflp->fl4_dst, oldflp->fl4_src ^ (oldflp->oif << 5), tos); - err = rt_intern_hash(hash, rth, rp); -done: if (free_res) fib_res_put(&res); if (dev_out) dev_put(dev_out); - if (in_dev) - in_dev_put(in_dev); out: return err; - -e_inval: - err = -EINVAL; - goto done; -e_nobufs: - err = -ENOBUFS; - goto done; } int __ip_route_output_key(struct rtable **rp, const struct flowi *flp) From elueck@de.ibm.com Mon Sep 13 03:37:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 03:37:19 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DAbADL002348 for ; Mon, 13 Sep 2004 03:37:11 -0700 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8DAauLi145406; Mon, 13 Sep 2004 10:36:56 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8DAatmk218144; Mon, 13 Sep 2004 12:36:55 +0200 Message-ID: <41457848.6040808@de.ibm.com> Date: Mon, 13 Sep 2004 12:36:56 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 26451 Lines: 802 We propose the following patch as an approach towards solving some problems with the current multipath implementation: Up to now the routing cache allows for only one route to be cached for a certain search key. Due to the fact that multipath configuration information is only stored in the fib database, a mulitpath/load balancing decision is only made in case a corresponding route is not yet cached. Therefore, NIC load balancing only works if the corresponding routes are not cached. In the scenarios, that are relevant to us (high amount of outgoing connection requests), this is hardly ever the case. The basic idea of the proposed patch is to utilize a new flag at the "struct dst_entry" flags field to indicate that further routes having the same key follow in the routing cache chain. Consequently, at cache lookup time we recognize this flag and may apply different load balancing policies to the available routes having the same key. The Garbage Collection is modified in a way that ensures that all routes having the same target are removed together from the cache. The primary reason for our approach is to keep the overall routing cache entry size constant. Furthermore, we want to separate load balancing state from the overall routing cache state as good as possible keeping all routes in the same place. Last but not least, we want to keep changes to the overall routing code/behaviour at a minimum. At this point, we are not yet interested in a discussion about appropriate balancing policies and implementations as we only implemented them naively for testing purposes. Instead, we would be very happy about any opinions about this basic idea. We think there are at least the following arguments: Pros: - Routing logic is only modified for the load balancing case - Separation of balancing policy logic from routing logic (a routing policy finds all the relevant routes in the cache and may manage its state in his own module => allows for a rich set of different balancing policies that may gather relevant information in any way they like) - Routing cache layout/size is not affected Cons: - there is less space for other routes in the cache - depending on the balancing policy implementation further delay is introduced for multipath routes - weight configuration via ip route may have to be changed (up to now we are not sure which configuration approach may fit best) Our tests show that the experimental policies we implemented (round robin and random) work fine and introduce of course some delay. Anyway, the implementations are naive and not yet relevant. Regards Einar diff -ruN linux-2.6.8.1.split/include/net/dst.h linux-2.6.8.1.multipath_cached/include/net/dst.h --- linux-2.6.8.1.split/include/net/dst.h 2004-09-10 10:24:40.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/include/net/dst.h 2004-09-10 10:34:35.000000000 +0200 @@ -48,6 +48,7 @@ #define DST_NOXFRM 2 #define DST_NOPOLICY 4 #define DST_NOHASH 8 +#define DST_BALANCED 0x10 unsigned long lastuse; unsigned long expires; diff -ruN linux-2.6.8.1.split/include/net/flow.h linux-2.6.8.1.multipath_cached/include/net/flow.h --- linux-2.6.8.1.split/include/net/flow.h 2004-09-10 10:24:40.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/include/net/flow.h 2004-09-10 10:34:35.000000000 +0200 @@ -51,6 +51,9 @@ __u8 proto; __u8 flags; +#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) +#define FLOWI_FLAG_MULTIPATHOLDROUTE 0x01 +#endif union { struct { __u16 sport; diff -ruN linux-2.6.8.1.split/include/net/route.h linux-2.6.8.1.multipath_cached/include/net/route.h --- linux-2.6.8.1.split/include/net/route.h 2004-09-10 10:24:40.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/include/net/route.h 2004-09-10 10:34:35.000000000 +0200 @@ -179,6 +179,9 @@ memcpy(&fl, &(*rp)->fl, sizeof(fl)); fl.fl_ip_sport = sport; fl.fl_ip_dport = dport; +#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) + fl.flags |= FLOWI_FLAG_MULTIPATHOLDROUTE; +#endif ip_rt_put(*rp); *rp = NULL; return ip_route_output_flow(rp, &fl, sk, 0); @@ -197,4 +200,41 @@ return rt->peer; } + +#ifdef CONFIG_IP_ROUTE_MULTIPATH_RR +extern void __multipath_remove(struct rtable *rt); +static inline void multipath_remove(struct rtable *rt) { + if ( rt->u.dst.flags & DST_BALANCED ) { + __multipath_remove( rt ); + } +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_RR */ +static inline void multipath_remove(struct rtable *rt) {} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_RR */ + + +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED +extern void __multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp); +static inline int multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp) { + if ( rth->u.dst.flags & DST_BALANCED ) { + __multipath_selectroute( flp, rth, rp ); + return 1; + } + else { + return 0; + } +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ +static inline int multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp) { + return 0; +} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ + + #endif /* _ROUTE_H */ diff -ruN linux-2.6.8.1.split/net/ipv4/Kconfig linux-2.6.8.1.multipath_cached/net/ipv4/Kconfig --- linux-2.6.8.1.split/net/ipv4/Kconfig 2004-09-10 10:25:08.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/net/ipv4/Kconfig 2004-09-10 10:34:35.000000000 +0200 @@ -94,6 +94,41 @@ equal "cost" and chooses one of them in a non-deterministic fashion if a matching packet arrives. +config IP_ROUTE_MULTIPATH_CACHED + bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" + depends on: IP_ROUTE_MULTIPATH + help + Normally, equal cost multipath routing is not supported by the + routing cache. If you say Y here, alternative routes are cached + in the routing cache and on cache lookup route is chosen in + Round Robin fashon. + + If unsure, say N. + +# +# multipath policy configuration +# +choice + prompt "Multipath policy" + depends on IP_ROUTE_MULTIPATH_CACHED + default IP_ROUTE_MULTIPATH_RR + +config IP_ROUTE_MULTIPATH_RR + bool "round robin (EXPERIMENTAL)" + help + Mulitpath routes are chosen according to Round Robin + +config IP_ROUTE_MULTIPATH_RANDOM + bool "random multipath (EXPERIMENTAL)" + help + Multipath routes are chosen in a random fashion (naive + implementation) + +endchoice +# +# END OF multipath policy configuration +# + config IP_ROUTE_TOS bool "IP: use TOS value as routing key" depends on IP_ADVANCED_ROUTER diff -ruN linux-2.6.8.1.split/net/ipv4/Makefile linux-2.6.8.1.multipath_cached/net/ipv4/Makefile --- linux-2.6.8.1.split/net/ipv4/Makefile 2004-09-10 10:25:08.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/net/ipv4/Makefile 2004-09-10 10:34:35.000000000 +0200 @@ -21,6 +21,8 @@ obj-$(CONFIG_INET_IPCOMP) += ipcomp.o obj-$(CONFIG_INET_TUNNEL) += xfrm4_tunnel.o obj-$(CONFIG_IP_PNP) += ipconfig.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RR) += multipath_rr.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RANDOM) += multipath_random.o obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_random.c linux-2.6.8.1.multipath_cached/net/ipv4/multipath_random.c --- linux-2.6.8.1.split/net/ipv4/multipath_random.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath_cached/net/ipv4/multipath_random.c 2004-09-10 10:34:35.000000000 +0200 @@ -0,0 +1,110 @@ +/* + * Random policy for multipath. + * + * + * Version: $Id: multipath.c,v 1.1.2.1 2004/09/02 20:01:27 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RTprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_MAX_CANDIDATES 40 + + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, + struct rtable **rp) { + struct rtable *rt; + struct rtable *candidate[MULTIPATH_MAX_CANDIDATES]; + struct rtable *decision; + unsigned char candidate_count = 0; + /* FIXME: remove debug code */ + RTprint( KERN_DEBUG"%s called\n", __FUNCTION__ ); + + /* collect all candidate */ + for (rt = rcu_dereference(first); rt; + rt = rcu_dereference(rt->u.rt_next)) { + if ( ( rt->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&rt->fl, flp) ) { + candidate[candidate_count] = rt; + ++candidate_count; + } + if ( candidate_count >= MULTIPATH_MAX_CANDIDATES ) { + break; + } + } + + /* choose a random candidate */ + decision = candidate[0]; + if ( candidate_count > 1 ) { + unsigned char i; + unsigned char candidate_no = net_random() % candidate_count; + decision = candidate[candidate_no]; + + /* make sure all candidates stay in cache */ + for ( i = 0; i < candidate_count; ++i ) { + candidate[i]->u.dst.lastuse = jiffies; + } + } + + /* refcounting and contention reduction */ + dst_hold(&decision->u.dst); + decision->u.dst.__use++; + RT_CACHE_STAT_INC(in_hit); + *rp = decision; +} + + + diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_rr.c linux-2.6.8.1.multipath_cached/net/ipv4/multipath_rr.c --- linux-2.6.8.1.split/net/ipv4/multipath_rr.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath_cached/net/ipv4/multipath_rr.c 2004-09-10 10:34:35.000000000 +0200 @@ -0,0 +1,202 @@ +/* + * Round robin policy for multipath. + * + * + * Version: $Id: multipath.c,v 1.1.2.1 2004/09/02 20:01:27 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct rt_cache_candidate +{ + struct rtable *candidate; + struct rt_cache_candidate *next; +}; + +#define RTprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_MAX_CANDIDATES 40 + +static spinlock_t multipath_state_lock = SPIN_LOCK_UNLOCKED; +static struct rt_cache_candidate *multipath_state = NULL; +static int multipath_state_entrycount = 0;/* FIXME remove: is just for debug purposes */ + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +void __multipath_remove(struct rtable* rt) { + struct rt_cache_candidate *candidate; + struct rt_cache_candidate *previous = NULL; + + /* DEBUG STUFF */ + if ( !( rt->u.dst.flags & DST_BALANCED ) ) { + /* FIXME: remove debug code */ + RTprint( KERN_DEBUG"%s: unexpected argument\n", + __FUNCTION__ ); + return; + } + + spin_lock_bh(&multipath_state_lock); + + for ( candidate = multipath_state; candidate != NULL; + candidate = candidate->next ) { + if ( multipath_comparekeys(&candidate->candidate->fl, + &rt->fl) ) { + if ( candidate == multipath_state ) { + multipath_state = multipath_state->next; + } + else { + previous->next = candidate->next; + } + --multipath_state_entrycount; + kfree( candidate ); + RTprint( KERN_DEBUG"%s: removed entry. Entry " \ + "count: %d\n", __FUNCTION__, + multipath_state_entrycount ); + break; + } + + previous = candidate; + } + + spin_unlock_bh(&multipath_state_lock); +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, struct rtable **rp) +{ + struct rt_cache_candidate *cand; + struct rtable *nh, *result; + int found_old = 0; + + spin_lock_bh(&multipath_state_lock); + + /* determine entry with candidate returned last time */ + for ( cand = multipath_state; cand != NULL; cand = cand->next ) { + if ( multipath_comparekeys(&cand->candidate->fl, flp) ) { + + RTprint( KERN_CRIT"%s: determined candidate " \ + "returned last time\n", + __FUNCTION__ ); + break; + } + } + + + /* 1. make sure all alt. nexthops have the same GC related data */ + /* 2. determine the new candidate to be returned */ + result = NULL; + for (nh = rcu_dereference(first); nh; + nh = rcu_dereference(nh->u.rt_next)) { + if ( ( nh->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&nh->fl, flp ) ) { + nh->u.dst.lastuse = jiffies; + nh->u.dst.__use++; + RTprint( KERN_CRIT"%s: found balanced entry\n", + __FUNCTION__ ); + + /* determine candidate to be returned */ + if ( !(flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) ) { + if ( found_old && !result ) { + result = nh; + } + else if ( cand != NULL && + nh == cand->candidate ) { + found_old = 1; + } + } + } + } + + /* if no previous alternative exists utilize first */ + if ( result == NULL ) { + RTprint( KERN_CRIT"%s: reach end of"\ + " chain. Start again.\n", + __FUNCTION__ ); + + result = first; + } + else { + RTprint( KERN_CRIT"%s: found new " \ + "candidate\n", + __FUNCTION__ ); + } + + + /* if necessary and possible utilize the old alternative */ + if ( ( flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) != 0 && + cand != NULL ) { + RTprint( KERN_CRIT"%s: holding route \n", + __FUNCTION__ ); + result = cand->candidate; + } + + + /* store candidate to return in state */ + if ( cand == NULL ) { + /* create new state entry if necessary */ + cand = (struct rt_cachec_andidate*) + kmalloc( sizeof(struct rt_cache_candidate), + GFP_KERNEL ); + cand->next = multipath_state; + multipath_state = cand; + ++multipath_state_entrycount; + RTprint( KERN_CRIT"%s: entrycount: %d\n", + __FUNCTION__, multipath_state_entrycount ); + } + cand->candidate = result; + + spin_unlock_bh(&multipath_state_lock); + + *rp = result; +} + + diff -ruN linux-2.6.8.1.split/net/ipv4/route.c linux-2.6.8.1.multipath_cached/net/ipv4/route.c --- linux-2.6.8.1.split/net/ipv4/route.c 2004-09-10 10:31:21.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/net/ipv4/route.c 2004-09-10 11:14:03.000000000 +0200 @@ -539,8 +539,28 @@ } /* Cleanup aged off entries. */ +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + /* remove all related balanced entries if necessary */ + if ( rth->u.dst.flags & DST_BALANCED ) { + struct rtable* first = rth; + *rthp = rth->u.rt_next; + while ( (*rthp)->u.dst.flags & DST_BALANCED && + compare_keys(&(*rthp)->fl, + &first->fl)) { + rth = (*rthp); + *rthp = rth->u.rt_next; + rt_free( rth ); + } + rt_free(first); + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ *rthp = rth->u.rt_next; rt_free(rth); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } spin_unlock(&rt_hash_table[i].lock); @@ -706,8 +726,28 @@ rthp = &rth->u.rt_next; continue; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + /* remove all related balanced entries if necessary */ + if ( rth->u.dst.flags & DST_BALANCED ) { + struct rtable* first = rth; + *rthp = rth->u.rt_next; + while ( (*rthp)->u.dst.flags & DST_BALANCED && + compare_keys(&(*rthp)->fl, + &first->fl)) { + rth = (*rthp); + *rthp = rth->u.rt_next; + rt_free( rth ); + } + rt_free(first); + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ *rthp = rth->u.rt_next; rt_free(rth); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ goal--; } spin_unlock_bh(&rt_hash_table[k].lock); @@ -789,7 +829,12 @@ spin_lock_bh(&rt_hash_table[hash].lock); while ((rth = *rthp) != NULL) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if (!(rth->u.dst.flags & DST_BALANCED) && + compare_keys(&rth->fl, &rt->fl)) { +#else if (compare_keys(&rth->fl, &rt->fl)) { +#endif /* Put it first */ *rthp = rth->u.rt_next; /* @@ -1621,7 +1666,18 @@ goto cleanup; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if ( res->fi->fib_nhs > 1 ) + RTprint( KERN_DEBUG"%s: balanced entry created: %d\n", + __FUNCTION__, + rth ); +#endif + rth->u.dst.flags= DST_HOST; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if ( res->fi->fib_nhs > 1 ) + rth->u.dst.flags |= DST_BALANCED; +#endif if (in_dev->cnf.no_policy) rth->u.dst.flags |= DST_NOPOLICY; if (in_dev->cnf.no_xfrm) @@ -1690,7 +1746,54 @@ struct in_device *in_dev, u32 daddr, u32 saddr, u32 tos) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + struct rtable* rth; + unsigned char hop, hopcount, lasthop; + int err = -EINVAL; + unsigned hash; + hopcount = res->fi->fib_nhs; + lasthop = hopcount - 1; + + /* distinguish between multipath and singlepath */ + if ( hopcount < 2 ) + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, + saddr, tos); + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", __FUNCTION__, + hopcount); + + /* add all alternatives to the routing cache */ + for ( hop = 0; hop < hopcount; ++hop ) { + res->nh_sel = hop; + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", + __FUNCTION__, hopcount); + + /* create a routing cache entry */ + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, + &rth ); + if ( err ) + return err; + + + /* put it into the cache */ + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + if ( err ) + return err; + + + /* only for the last hop the reference count is handled + outside */ + RTprint( KERN_DEBUG"%s: balanced entry created: %d\n", + __FUNCTION__, rth ); + if ( hop == lasthop ) + atomic_set(&(skb->dst->__refcnt), 1); + } + return err; +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); +#endif } @@ -1929,6 +2032,17 @@ rth->fl.fl4_fwmark == skb->nfmark && #endif rth->fl.fl4_tos == tos) { + /* check if the route is a multipath route and if so + select one of the alternatives */ + if ( multipath_selectroute( + &rth->fl, rth, + (struct rtable**)&skb->dst) ) { + dst_hold(skb->dst); + rcu_read_unlock(); + + return 0; + } + rth->u.dst.lastuse = jiffies; dst_hold(&rth->u.dst); rth->u.dst.__use++; @@ -2034,6 +2148,10 @@ } rth->u.dst.flags= DST_HOST; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if (res->fi->fib_nhs > 1) + rth->u.dst.flags |= DST_BALANCED; +#endif if (in_dev->cnf.no_xfrm) rth->u.dst.flags |= DST_NOXFRM; if (in_dev->cnf.no_policy) @@ -2125,7 +2243,71 @@ struct net_device *dev_out, unsigned flags) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + u32 tos = RT_FL_TOS(oldflp); + unsigned char hop; + unsigned hash; + int err = -EINVAL; + unsigned char hopcount = res->fi->fib_nhs; + struct rtable* rth; + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d, fl->oif: %d)\n", + __FUNCTION__, hopcount, fl->oif); + + if (res->fi->fib_nhs > 1) { + for ( hop = 0; hop < hopcount; ++hop ) { + struct net_device *dev2nexthop; + RTprint( KERN_DEBUG"%s: hop %d of %d\n", __FUNCTION__, + hop, hopcount ); + + res->nh_sel = hop; + + /* hold a work reference to the output device */ + dev2nexthop = FIB_RES_DEV(*res); + dev_hold(dev2nexthop); + + /** FIXME remove debug code */ + RTprint( KERN_DEBUG"%s: balanced entry created: %d " \ + " (GW: %u)\n", + __FUNCTION__, + rth, + FIB_RES_GW(*res) ); + + err = __mkroute_output(&rth, res, fl, oldflp, + dev2nexthop, flags); + if ( err != 0 ) { + goto cleanup; + } + + RTprint( KERN_DEBUG"%s: created successfully %d\n", + __FUNCTION__, hop ); + + hash = rt_hash_code(oldflp->fl4_dst, + oldflp->fl4_src ^ + (oldflp->oif << 5), tos); + err = rt_intern_hash(hash, rth, rp); + RTprint( KERN_DEBUG"%s: hashed %d\n", + __FUNCTION__, hop ); + + cleanup: + /* release work reference to output device */ + dev_put(dev2nexthop); + + if ( err != 0 ) { + return err; + } + } + RTprint( KERN_DEBUG"%s: exited loop\n", __FUNCTION__ ); + atomic_set(&(*rp)->u.dst.__refcnt, 1); + return err; + } + else { + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, + flags); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } /* @@ -2338,6 +2520,16 @@ #endif !((rth->fl.fl4_tos ^ flp->fl4_tos) & (IPTOS_RT_MASK | RTO_ONLINK))) { + + /* check for multipath routes and choose one if + necessary */ + if (multipath_selectroute(flp, rth, rp)) { + dst_hold(&(*rp)->u.dst); + RT_CACHE_STAT_INC(out_hit); + rcu_read_unlock_bh(); + return 0; + } + rth->u.dst.lastuse = jiffies; dst_hold(&rth->u.dst); rth->u.dst.__use++; From herbert@gondor.apana.org.au Mon Sep 13 04:20:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 04:20:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DBKCLB007129 for ; Mon, 13 Sep 2004 04:20:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C6osB-0006sr-00; Mon, 13 Sep 2004 21:19:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C6os3-0006os-00; Mon, 13 Sep 2004 21:19:43 +1000 Date: Mon, 13 Sep 2004 21:19:43 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPv6] Add option to copy DSCP in decap in ip6_tunnel Message-ID: <20040913111943.GA26179@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2586 Lines: 81 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Here is a patch that allows the copying of the DSCP during decapsulation for ip6_tunnel. I've made it a separate option from the one that determines the copying during encapsulation since the DSCP processing may be asymmetric. It also means that we preserve compatibility should anyone be relying on the current behaviour. inet_ecn.h might appear to be an odd place for ipv6_copy_dscp, but I couldn't put it in dsfield.h since I want to use ipv6_get_dsfield in inet_ecn.h later on. The other alternative would be to define INET_ECN_MASK in dsfield.h. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/ip6_tunnel.h 1.1 vs edited ===== --- 1.1/include/linux/ip6_tunnel.h 2003-06-10 00:56:43 +10:00 +++ edited/include/linux/ip6_tunnel.h 2004-09-13 16:30:44 +10:00 @@ -16,6 +16,8 @@ #define IP6_TNL_F_USE_ORIG_FLOWLABEL 0x4 /* being used for Mobile IPv6 */ #define IP6_TNL_F_MIP6_DEV 0x8 +/* copy DSCP from the outer packet */ +#define IP6_TNL_F_RCV_DSCP_COPY 0x10 struct ip6_tnl_parm { char name[IFNAMSIZ]; /* name of tunnel device */ ===== include/net/inet_ecn.h 1.7 vs edited ===== --- 1.7/include/net/inet_ecn.h 2004-09-09 14:16:21 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-13 15:55:17 +10:00 @@ -2,6 +2,7 @@ #define _INET_ECN_H_ #include +#include enum { INET_ECN_NOT_ECT = 0, @@ -91,6 +92,12 @@ static inline void IP6_ECN_clear(struct ipv6hdr *iph) { *(u32*)iph &= ~htonl(INET_ECN_MASK << 20); +} + +static inline void ipv6_copy_dscp(struct ipv6hdr *outer, struct ipv6hdr *inner) +{ + u32 dscp = ipv6_get_dsfield(outer) & ~INET_ECN_MASK; + ipv6_change_dsfield(inner, INET_ECN_MASK, dscp); } #endif ===== net/ipv6/ip6_tunnel.c 1.24 vs edited ===== --- 1.24/net/ipv6/ip6_tunnel.c 2004-09-09 14:21:46 +10:00 +++ edited/net/ipv6/ip6_tunnel.c 2004-09-13 16:30:11 +10:00 @@ -542,6 +542,8 @@ skb->dev = t->dev; dst_release(skb->dst); skb->dst = NULL; + if (t->parms.flags & IP6_TNL_F_RCV_DSCP_COPY) + ipv6_copy_dscp(ipv6h, skb->nh.ipv6h); ip6ip6_ecn_decapsulate(ipv6h, skb); t->stat.rx_packets++; t->stat.rx_bytes += skb->len; --bp/iNruPH9dso1Pn-- From jchapman@katalix.com Mon Sep 13 04:19:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 04:19:37 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DBJSgn007059 for ; Mon, 13 Sep 2004 04:19:28 -0700 Message-Id: <200409131119.i8DBJSgn007059@oss.sgi.com> Received: from jchapman.plus.com ([212.56.89.216] helo=quickie) by s14.s14avahost.net with esmtp (Exim 4.42) id 1C6oqq-0002gr-5S; Mon, 13 Sep 2004 06:18:29 -0500 From: "J Chapman" To: "'Herbert Xu'" , "'David S. Miller'" Cc: , , , , Subject: RE: single process pppd for all PPP sessions? [Was [IPCOMP] Use per-cpu buffers] Date: Mon, 13 Sep 2004 12:18:39 +0100 Organization: Katalix Systems MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040910111047.GA29330@gondor.apana.org.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSXJyCe9VjjxABuSBej5IYV8ee9zACRCR/g X-PopBeforeSMTPSenders: ahruschka@katalix.com,careers@katalix.com,info@katalix.com,jcarlson@katalix.com,jchapman@katalix.com,katalixc,lists@katalix.com,support@katalix.com,webmaster@katalix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 8711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 709 Lines: 24 Re: anyone think of doing a single process PPP daemon managing all PPP sessions? Yes, although nothing started yet. Still working on OpenL2TP... http://openl2tp.sf.net/ -James > -----Original Message----- > From: Herbert Xu [mailto:herbert@gondor.apana.org.au] > Sent: 10 September 2004 12:11 > To: David S. Miller > Cc: kuznet@ms2.inr.ac.ru; jmorris@redhat.com; netdev@oss.sgi.com; linux-ppp@vger.kernel.org; paulus@samba.org > Subject: Re: [IPCOMP] Use per-cpu buffers > [snip] > On a totally orthogonal topic, has any body thought of doing a PPP > daemon like the IPsec daemons? That is, have one process that manages > all PPP sessions. This could be useful for large L2TP servers and > alike. > From alan@lxorguk.ukuu.org.uk Mon Sep 13 04:52:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 04:52:54 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DBqlgj008126 for ; Mon, 13 Sep 2004 04:52:47 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8DAo6Gm014380; Mon, 13 Sep 2004 11:50:07 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8DAnDlP014376; Mon, 13 Sep 2004 11:49:13 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: RE: Linux 2.4.27 SECURITY BUG - TCP Local andREMOTE(verified)Denial of Service Attack From: Alan Cox To: Wolfpaw - Dale Corse Cc: peter@mysql.com, netdev@oss.sgi.com, kaukasoi@elektroni.ee.tut.fi In-Reply-To: <002b01c498ff$c4619b30$0200a8c0@wolf> References: <002b01c498ff$c4619b30$0200a8c0@wolf> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095072549.14359.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 11:49:10 +0100 X-archive-position: 8713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 1227 Lines: 26 On Sul, 2004-09-12 at 20:36, Wolfpaw - Dale Corse wrote: > Mysql connection: descriptor 3 (from mysql.net.fd) > Mysql connection closed (desc 3) (goes into CLOSE_WAIT now) > New connection (outbound) for regular proxy on Desc 3 > (this was created by a call to socket, and then connect) fd != socket. Thats really important to realise. What you get on fd 3 from the new connection isn't the same as you had before. The one you closed has been handed off to the kernel to clean up as and when everyone who has a copy has finished using it. Thats why I asked about fork() - because you can end up giving handles by mistake to other processes you create which don't close them > The other bug being, if I simply leave them, in a short time, MySQL > is saying "too many connections", and we can't query any data from > it. This also occurs with FIFO sockets (such as /tmp/mysql.sock) > wherein the connection simply sits as "ESTABLISHED". I'd say your code is buggy then > So something needs to trigger a "flush" of the left over data > on the SQL side before closing the connection - yes? That will occur anyway for you. I think you need to find out where the other copies of the same fd went and how mysql manages them From yoshfuji@linux-ipv6.org Mon Sep 13 04:55:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 04:55:19 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DBtEJe008510 for ; Mon, 13 Sep 2004 04:55:14 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 364B133CE7; Mon, 13 Sep 2004 20:55:05 +0900 (JST) Date: Mon, 13 Sep 2004 20:55:04 +0900 (JST) Message-Id: <20040913.205504.46820949.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au, davem@davemloft.net Cc: netdev@oss.sgi.com Subject: Re: [IPv6] Add option to copy DSCP in decap in ip6_tunnel From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040913111943.GA26179@gondor.apana.org.au> References: <20040913111943.GA26179@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 499 Lines: 11 In article <20040913111943.GA26179@gondor.apana.org.au> (at Mon, 13 Sep 2004 21:19:43 +1000), Herbert Xu says: > Here is a patch that allows the copying of the DSCP during decapsulation > for ip6_tunnel. I've made it a separate option from the one that > determines the copying during encapsulation since the DSCP processing > may be asymmetric. It also means that we preserve compatibility should > anyone be relying on the current behaviour. I agree. --yoshfuji From alan@lxorguk.ukuu.org.uk Mon Sep 13 05:00:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 05:00:23 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DC0FCc008915 for ; Mon, 13 Sep 2004 05:00:15 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8DAvfhV014392; Mon, 13 Sep 2004 11:57:41 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8DAuftM014391; Mon, 13 Sep 2004 11:56:41 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: [PATCH] BSD Jail LSM (2/3) From: Alan Cox To: "Serge E. Hallyn" Cc: Chris Wright , Linux Kernel Mailing List , akpm@osdl.org, netdev@oss.sgi.com In-Reply-To: <20040912233342.GA12097@escher.cs.wm.edu> References: <1094847705.2188.94.camel@serge.austin.ibm.com> <1094847787.2188.101.camel@serge.austin.ibm.com> <1094844708.18107.5.camel@localhost.localdomain> <20040912233342.GA12097@escher.cs.wm.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095072996.14355.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 11:56:39 +0100 X-archive-position: 8715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 401 Lines: 11 On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote: > Right now one must choose between either an ipv4 or ipv6 interface. > Is typical ipv6 usage such that it would be preferable to be able to > specify one of each? Its normal to have both yes. A more interesting question is whether all of the "which socket for which use" stuff could be addressed by netfilter chains run at bind/connect time ? From alan@lxorguk.ukuu.org.uk Mon Sep 13 05:41:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 05:41:54 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DCfmNw009885 for ; Mon, 13 Sep 2004 05:41:49 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8DBdNUM014493; Mon, 13 Sep 2004 12:39:23 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8DBc183014492; Mon, 13 Sep 2004 12:38:01 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout From: Alan Cox To: Francois Romieu Cc: Sean Neakums , jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <20040912215933.GB27282@electric-eye.fr.zoreil.com> References: <6upt4s4cro.fsf@zork.zork.net> <20040912110614.GA20942@electric-eye.fr.zoreil.com> <6u8ybf2w3f.fsf@zork.zork.net> <20040912204319.GA27282@electric-eye.fr.zoreil.com> <6uisaj19m4.fsf@zork.zork.net> <20040912215933.GB27282@electric-eye.fr.zoreil.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095075479.14374.47.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 12:38:01 +0100 X-archive-position: 8716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 425 Lines: 14 On Sul, 2004-09-12 at 22:59, Francois Romieu wrote: > > Same result on starting X: > > > > irq 16: nobody cared! > > It slightly sounds like a broken irq routing. > > Any taker for the hot potato ? Try booting the -mm kernel with "irqpoll" as a boot option and see if it survives but struggles. At least I think mm4 has the irqpoll hack in. If so then you can work back and try and see whether things like acpi=off work From hfvogt@arcor.de Mon Sep 13 05:43:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 05:44:06 -0700 (PDT) Received: from achilles.nass-vogt.home (pD9E75C6D.dip0.t-ipconnect.de [217.231.92.109]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DChqo2010141 for ; Mon, 13 Sep 2004 05:43:52 -0700 Received: by achilles.nass-vogt.home (Postfix, from userid 1000) id AA97D3D1; Mon, 13 Sep 2004 14:43:34 +0200 (CEST) From: Hans-Frieder Vogt Reply-To: hfvogt@arcor.de To: Francois Romieu Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Date: Mon, 13 Sep 2004 14:43:34 +0200 User-Agent: KMail/1.7 References: <200409130035.50823.hfvogt@arcor.de> <20040912232604.GC27282@electric-eye.fr.zoreil.com> In-Reply-To: <20040912232604.GC27282@electric-eye.fr.zoreil.com> Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_2XZRBrdXpkiYhgb" Message-Id: <200409131443.34374.hfvogt@arcor.de> X-archive-position: 8717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hfvogt@arcor.de Precedence: bulk X-list: netdev Content-Length: 48394 Lines: 1859 --Boundary-00=_2XZRBrdXpkiYhgb Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Am Montag, 13. September 2004 01:26 schrieben Sie: > Hans-Frieder Vogt : > [2.6.9-rc1-bk11 r8169 freeze on amd64] > > > Until somebody comes up with a proper solution for this problem, I > > suggest as a work-around to introduce a parameter so that the DAC can be > > simply unselected if necessary, as outlined in the patch below. > > > > Thanks for any suggestions as to what the problem might be. > > Remove the workaround, apply the attached patch and watch the oops. > Francois, thanks for your quick response. I applied the patch to an otherwise clean 2.6.9-rc1-bk17, but no change to previous behaviour: no oops (BUG_ON not triggered)! System boots up as normal, but just after I log in on the console the system freezes, i.e., keyboard does not react any more and the system is not accessible via network. The time from the moment I log in to the time when the system freezes varies, but is in the order of 5s. There is no difference whether NAPI is enabled or not. My .config and the boot messages are attached to this e-mail. Hans-Frieder > If it happens in rtl8169_rx_interrupt(), you may notice that R12 is set to > 0xbfc. R12 is pkt_len in rtl8169_rx_interrupt. This value is twice too > high. I have not figured why so far and I'll go to bed. > > Please Cc: netdev and jgarzik@pobox.com on followup. > > -- > Ueimor -- -- Hans-Frieder Vogt e-mail: hfvogt (at) arcor (dot) de --Boundary-00=_2XZRBrdXpkiYhgb Content-Type: text/plain; charset="iso-8859-15"; name="config-2.6.9-rc1-bk17" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config-2.6.9-rc1-bk17" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.9-rc1-bk17-amd64 # Mon Sep 13 13:40:33 2004 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # # Power management options # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_PROC_INTF is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_TABLE=y # # CPUFreq processor drivers # CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_ACPI_CPUFREQ is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_IA32_EMULATION=y # CONFIG_IA32_AOUT is not set CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_UID16=y # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_IDE_TASKFILE_IO is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_IVB=y CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=m # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set # CONFIG_SCSI_ATA_PIIX is not set # CONFIG_SCSI_SATA_NV is not set CONFIG_SCSI_SATA_PROMISE=y # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set CONFIG_SCSI_SATA_VIA=y # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=256 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set CONFIG_INET_TUNNEL=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m CONFIG_IPV6_TUNNEL=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m # CONFIG_IP_NF_CT_ACCT is not set CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_RAW=m # CONFIG_IP_NF_TARGET_NOTRACK is not set CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # IPv6: Netfilter Configuration # CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_IP6_NF_RAW=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set CONFIG_NET_CLS_ROUTE=y # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # # CONFIG_DONGLE is not set # # Old SIR device drivers # CONFIG_IRPORT_SIR=m # # Old Serial dongle support # # CONFIG_DONGLE_OLD is not set # # FIR device drivers # CONFIG_USB_IRDA=m # CONFIG_SIGMATEL_FIR is not set # CONFIG_VLSI_FIR is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_VELOCITY is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_R8169=m CONFIG_R8169_NAPI=y # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_AMD64=y # CONFIG_AGP_INTEL_MCH is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set CONFIG_HANGCHECK_TIMER=y # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set CONFIG_I2C_ISA=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set CONFIG_I2C_VIAPRO=m # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set CONFIG_SENSORS_W83627HF=m # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5246A is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported Frontend Modules # # CONFIG_DVB_TWINHAN_DST is not set # CONFIG_DVB_STV0299 is not set CONFIG_DVB_SP887X=m CONFIG_DVB_SP887X_FIRMWARE_FILE="/usr/lib/hotplug/firmware/sc_main.mc" # CONFIG_DVB_ALPS_TDLB7 is not set # CONFIG_DVB_ALPS_TDMB7 is not set # CONFIG_DVB_ATMEL_AT76C651 is not set # CONFIG_DVB_CX24110 is not set # CONFIG_DVB_GRUNDIG_29504_491 is not set # CONFIG_DVB_GRUNDIG_29504_401 is not set # CONFIG_DVB_MT312 is not set # CONFIG_DVB_VES1820 is not set # CONFIG_DVB_VES1X93 is not set # CONFIG_DVB_TDA1004X is not set # CONFIG_DVB_NXT6000 is not set # # Supported SAA7146 based PCI Adapters # # CONFIG_DVB_AV7110 is not set # CONFIG_DVB_BUDGET is not set # CONFIG_DVB_BUDGET_CI is not set # CONFIG_DVB_BUDGET_AV is not set # # Supported USB Adapters # # CONFIG_DVB_TTUSB_BUDGET is not set CONFIG_DVB_TTUSB_DEC=m # # Supported FlexCopII (B2C2) Adapters # # CONFIG_DVB_B2C2_SKYSTAR is not set # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # CONFIG_FB=y # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON_OLD is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_BIT32_EMUL=m CONFIG_SND_RTCTIMER=m CONFIG_SND_VERBOSE_PRINTK=y # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m # CONFIG_SND_DUMMY is not set CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # CONFIG_USB_AUDIO=m # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_RW_DETECT=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # Firmware Drivers # # CONFIG_EDD is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y # CONFIG_REISERFS_FS_SECURITY is not set CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_SECURITY is not set CONFIG_XFS_POSIX_ACL=y # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS_XATTR=y # CONFIG_DEVPTS_FS_SECURITY is not set CONFIG_TMPFS=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # # CONFIG_NFS_FS is not set # CONFIG_NFSD is not set # CONFIG_EXPORTFS is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_INFO is not set # CONFIG_FRAME_POINTER is not set # CONFIG_CHECKING is not set # CONFIG_INIT_DEBUG is not set # CONFIG_SCHEDSTATS is not set # CONFIG_IOMMU_DEBUG is not set # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WHIRLPOOL=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m --Boundary-00=_2XZRBrdXpkiYhgb Content-Type: text/plain; charset="iso-8859-15"; name="boot.msg-napi" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot.msg-napi" root=/dev/sda2 apic vga=792 resume=/dev/sda1 console=tty0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 2000.089 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1026304k/1048512k available (2218k kernel code, 21412k reserved, 1013k data, 144k init) Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 08 tbxface-0117 [02] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:..................................................................................................................................................... Table [DSDT](id F004) - 520 Objects with 48 Devices 149 Methods 26 Regions ACPI Namespace successfully loaded at root ffffffff804486e0 evxfevnt-0093 [03] acpi_enable : Transition to ACPI mode successful Using local APIC NMI watchdog using perfctr0 ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. Detected 12.500 MHz APIC timer. NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040715 evgpeblk-0980 [07] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs at 0000000000000820 on int 0x9 evgpeblk-0989 [07] ev_create_gpe_block : Found 6 Wake, Enabled 0 Runtime GPEs in this block Completing Region/Field/Buffer/Package initialization:........................................................................................... Initialized 26/26 Regions 9/9 Fields 44/44 Buffers 12/24 Packages (529 nodes) Executing all Device _STA and_INI methods:................................................... 51 Devices found containing: 51 _STA, 1 _INI methods ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Power Resource [URP1] (off) ACPI: Power Resource [URP2] (off) ACPI: Power Resource [FDDP] (off) ACPI: Power Resource [LPTP] (off) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. SCSI subsystem initialized PCI: Using ACPI for IRQ routing IOAPIC[0]: Set PCI routing entry (2-19 -> 0xa9 -> IRQ 19 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 19 (level, low) -> IRQ 19 ACPI: PCI interrupt 0000:00:08.1[A] -> GSI 19 (level, low) -> IRQ 19 IOAPIC[0]: Set PCI routing entry (2-16 -> 0xb1 -> IRQ 16 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16 IOAPIC[0]: Set PCI routing entry (2-20 -> 0xb9 -> IRQ 20 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 20 ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20 IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc1 -> IRQ 21 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 21 ACPI: PCI interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 21 IOAPIC[0]: Set PCI routing entry (2-22 -> 0xc9 -> IRQ 22 Mode:1 Active:1) ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 22 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16 number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 .... register #01: 00178003 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0003 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 001 01 0 0 0 0 0 1 1 39 02 001 01 0 0 0 0 0 1 1 31 03 001 01 0 0 0 0 0 1 1 41 04 001 01 0 0 0 0 0 1 1 49 05 001 01 0 0 0 0 0 1 1 51 06 001 01 0 0 0 0 0 1 1 59 07 001 01 0 0 0 0 0 1 1 61 08 001 01 0 0 0 0 0 1 1 69 09 001 01 0 1 0 1 0 1 1 71 0a 001 01 0 0 0 0 0 1 1 79 0b 001 01 0 0 0 0 0 1 1 81 0c 001 01 0 0 0 0 0 1 1 89 0d 001 01 0 0 0 0 0 1 1 91 0e 001 01 0 0 0 0 0 1 1 99 0f 001 01 0 0 0 0 0 1 1 A1 10 001 01 1 1 0 1 0 1 1 B1 11 000 00 1 0 0 0 0 0 0 00 12 000 00 1 0 0 0 0 0 0 00 13 001 01 1 1 0 1 0 1 1 A9 14 001 01 1 1 0 1 0 1 1 B9 15 001 01 1 1 0 1 0 1 1 C1 16 001 01 1 1 0 1 0 1 1 C9 17 041 01 1 0 0 0 0 0 2 DA IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ19 -> 0:19 IRQ20 -> 0:20 IRQ21 -> 0:21 IRQ22 -> 0:22 .................................... done. agpgart: Detected AGP bridge 0 agpgart: Maximum main memory to use for agp memory: 941M agpgart: AGP aperture is 128M @ 0xd0000000 PCI-DMA: Disabling IOMMU. IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $ Total HugeTLB memory allocated, 0 SGI XFS with ACLs, large block/inode numbers, no debug enabled Initializing Cryptographic API PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 5 PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 5 PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 5 PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 5 vesafb: framebuffer at 0xc0000000, mapped to 0xffffff0000100000, size 6144k vesafb: mode is 1024x768x32, linelength=4096, pages=1 vesafb: scrolling: redraw vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Processor [CPU1] (supports C1) Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones Hangcheck: starting hangcheck timer 0.5.0 (tick is 180 seconds, margin is 60 seconds). Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:0f.1 ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: ATAPI DVD DUAL 8X4X12, ATAPI CD/DVD-ROM drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... Probing IDE interface ide1... Probing IDE interface ide2... ide2: Wait for ready failed before probe ! Probing IDE interface ide3... ide3: Wait for ready failed before probe ! Probing IDE interface ide4... ide4: Wait for ready failed before probe ! Probing IDE interface ide5... ide5: Wait for ready failed before probe ! libata version 1.02 loaded. sata_via version 0.20 ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 20 sata_via(0000:00:0f.0): routed to hard irq line 10 ata1: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xDC00 irq 20 ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 20 ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003 88:203f ata1: dev 0 ATA, max UDMA/100, 312581808 sectors: lba48 ata1: dev 0 configured for UDMA/100 scsi0 : sata_via ata2: no device found (phy stat 00000000) scsi1 : sata_via Vendor: ATA Model: WDC WD1600JD-00F Rev: 02.0 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 NET: Registered protocol family 2 IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET: Registered protocol family 1 powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09b) acpi_utils-0071 [65] acpi_extract_package : Invalid 'package' argument acpi_processor-1008 [64] acpi_processor_get_per: Invalid _PSS data powernow-k8: 0 : fid 0x0 (800 MHz), vid 0xa (1300 mV) powernow-k8: 1 : fid 0xa (1800 MHz), vid 0x6 (1400 mV) powernow-k8: 2 : fid 0xc (2000 MHz), vid 0x2 (1500 mV) powernow-k8: cpu_init done, current fid 0xc, vid 0x2 Resume Machine: resuming from /dev/sda1 Resuming from device unknown-block(8,1) Resume Machine: This is normal swap space ACPI: (supports S0 S3 S4 S5) ACPI wakeup devices: PCI0 UAR1 USB1 USB2 USB3 USB4 EHCI USBD AC9 MC9 ILAN SLPB VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 144k freed Adding 2112508k swap on /dev/sda1. Priority:-1 extents:1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A IOAPIC[0]: Set PCI routing entry (2-4 -> 0x49 -> IRQ 4 Mode:0 Active:0) hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 inserting floppy driver for 2.6.9-rc1-bk17-amd64 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 lp: driver loaded but no devices found i2c /dev entries driver Linux video capture interface: v1.00 bttv: driver version 0.9.15 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 19 (level, low) -> IRQ 19 bttv0: Bt878 (rev 17) at 0000:00:08.0, irq: 19, latency: 32, mmio: 0xcddfe000 bttv0: detected: AverMedia AverTV DVB-T [card=124], PCI subsystem ID is 1461:0761 bttv0: using: AverMedia AverTV DVB-T 761 [card=124,autodetected] bttv0: gpio: en=00000000, out=00000000 in=009c008d [init] bttv0: using tuner=-1 bttv0: registered device video0 bttv0: registered device vbi0 bttv0: PLL: 28636363 => 35468950 .. ok bttv0: add subdevice "remote0" bttv0: add subdevice "dvb0" XFS mounting filesystem sda5 Ending clean XFS mount for filesystem: sda5 XFS mounting filesystem sda6 Ending clean XFS mount for filesystem: sda6 XFS mounting filesystem sda7 Ending clean XFS mount for filesystem: sda7 XFS mounting filesystem sda8 Ending clean XFS mount for filesystem: sda8 XFS mounting filesystem sda9 Ending clean XFS mount for filesystem: sda9 XFS mounting filesystem sda10 Ending clean XFS mount for filesystem: sda10 bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). ACPI: PCI interrupt 0000:00:08.1[A] -> GSI 19 (level, low) -> IRQ 19 bt878(0): Bt878 (rev 17) at 00:08.1, irq: 19, latency: 32, memory: 0xcddff000 r8169 Gigabit Ethernet driver 1.2 loaded ACPI: PCI interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 16 r8169: NAPI enabled eth0: Identified chip type is 'RTL8169s/8110s'. eth0: RTL8169 at 0xffffff0000014f00, 00:0c:76:5c:f1:f6, IRQ 16 usbcore: registered new driver usbfs usbcore: registered new driver hub USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller uhci_hcd 0000:00:10.0: irq 21, io base 000000000000c400 uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) uhci_hcd 0000:00:10.1: irq 21, io base 000000000000c800 uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#3) uhci_hcd 0000:00:10.2: irq 21, io base 000000000000cc00 uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:10.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#4) uhci_hcd 0000:00:10.3: irq 21, io base 000000000000d000 uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected usb 2-2: new low speed USB device using address 2 usbcore: registered new driver hiddev ACPI: PCI interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 21 ehci_hcd 0000:00:10.4: VIA Technologies, Inc. USB 2.0 ehci_hcd 0000:00:10.4: irq 21, pci mem ffffff0000016d00 ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5 ehci_hcd 0000:00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10 drivers/usb/input/hid-core.c: ctrl urb status -84 received input: USB HID v1.00 Mouse [Logitech Inc. iFeel MouseMan] on usb-0000:00:10.1-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver hub 5-0:1.0: USB hub found hub 5-0:1.0: 8 ports detected usb 2-2: USB disconnect, address 2 ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 22 PCI: Setting latency timer of device 0000:00:11.5 to 64 usb 2-2: new low speed USB device using address 3 drivers/usb/input/hid-core.c: ctrl urb status -2 received drivers/usb/input/hid-core.c: timeout initializing reports input: USB HID v1.00 Mouse [Logitech Inc. iFeel MouseMan] on usb-0000:00:10.1-2 Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. r8169: eth0: link up ttyS1: LSR safety check engaged! ttyS1: LSR safety check engaged! NET: Registered protocol family 10 Disabled Privacy Extensions on device ffffffff803ec680(lo) IPv6 over IPv4 tunneling driver --Boundary-00=_2XZRBrdXpkiYhgb-- From sneakums@zork.net Mon Sep 13 05:48:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 05:49:00 -0700 (PDT) Received: from zork.zork.net (Debian-exim@zork.zork.net [64.81.246.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DCmu73010609 for ; Mon, 13 Sep 2004 05:48:56 -0700 Received: from sneakums by zork.zork.net with local (Exim 4.34) id 1C6qG3-0003kM-Qt; Mon, 13 Sep 2004 05:48:35 -0700 To: Alan Cox Cc: Francois Romieu , jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: 2.6.9-rc1-mm4: r8169: irq 16: nobody cared!/TX Timeout References: <6upt4s4cro.fsf@zork.zork.net> <20040912110614.GA20942@electric-eye.fr.zoreil.com> <6u8ybf2w3f.fsf@zork.zork.net> <20040912204319.GA27282@electric-eye.fr.zoreil.com> <6uisaj19m4.fsf@zork.zork.net> <20040912215933.GB27282@electric-eye.fr.zoreil.com> <1095075479.14374.47.camel@localhost.localdomain> From: Sean Neakums Mail-Followup-To: Alan Cox , Francois Romieu , jgarzik@pobox.com, akpm@osdl.org, netdev@oss.sgi.com, Linux Kernel Mailing List Date: Mon, 13 Sep 2004 13:48:35 +0100 In-Reply-To: <1095075479.14374.47.camel@localhost.localdomain> (Alan Cox's message of "Mon, 13 Sep 2004 12:38:01 +0100") Message-ID: <6uoekaxrks.fsf@zork.zork.net> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: sneakums@zork.net X-SA-Exim-Scanned: No (on zork.zork.net); SAEximRunCond expanded to false X-archive-position: 8718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sneakums@zork.net Precedence: bulk X-list: netdev Content-Length: 581 Lines: 18 Alan Cox writes: > On Sul, 2004-09-12 at 22:59, Francois Romieu wrote: >> > Same result on starting X: >> > >> > irq 16: nobody cared! >> >> It slightly sounds like a broken irq routing. >> >> Any taker for the hot potato ? > > Try booting the -mm kernel with "irqpoll" as a boot option and see if it > survives but struggles. At least I think mm4 has the irqpoll hack in. If > so then you can work back and try and see whether things like acpi=off > work Not sure if you caught the earlier context or if this is relevant, but acpi=noirq does work. From sriharivijayaraghavan@yahoo.com.au Mon Sep 13 07:09:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 07:09:40 -0700 (PDT) Received: from smtp200.mail.sc5.yahoo.com (smtp200.mail.sc5.yahoo.com [216.136.130.125]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8DE9ZHs015769 for ; Mon, 13 Sep 2004 07:09:35 -0700 Received: from unknown (HELO ?192.168.0.2?) (sriharivijayaraghavan@150.101.153.12 with plain) by smtp200.mail.sc5.yahoo.com with SMTP; 13 Sep 2004 14:09:22 -0000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: r8169 - panic and a fix Date: Tue, 14 Sep 2004 00:16:00 +1000 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <200409121832.57233.sriharivijayaraghavan@yahoo.com.au> <20040912231516.GA27299@electric-eye.fr.zoreil.com> In-Reply-To: <20040912231516.GA27299@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409140016.01028.sriharivijayaraghavan@yahoo.com.au> X-archive-position: 8719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sriharivijayaraghavan@yahoo.com.au Precedence: bulk X-list: netdev Content-Length: 408 Lines: 13 On Mon, 13 Sep 2004 09:15 am, Francois Romieu wrote: > Srihari Vijayaraghavan : > ... > Can you #define RX_BUF_SIZE 3072 and run with r8169-dbg-b applied ? > That does not help. It hangs on a first ping from a remote machine. There is no OOPS or BUG or panic and it simply hard locks. No sysrq either. (Pressing the power switch was the only option.) Thank you. Hari. From yoshfuji@linux-ipv6.org Mon Sep 13 07:17:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 07:17:52 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DEHeji016273 for ; Mon, 13 Sep 2004 07:17:40 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 3DD1B33CE7; Mon, 13 Sep 2004 23:17:33 +0900 (JST) Date: Mon, 13 Sep 2004 23:17:32 +0900 (JST) Message-Id: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, vnuorval@tcs.hut.fi Subject: [BK PATCH] [IPV6] Merge Specification Conformity Improvements From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 41383 Lines: 1291 Hello. Here're the changesets which improve conformity to the IPv6 specifications / standards. Please pull from All changesets are product of USAGI/WIDE Project, and signed-off-by: Hideaki YOSHIFUJI . Plus, special thanks to Ville Nuorvala in GO/Core Project; credit is given in chagneset log. We will make other couple of changesets for merging our efforts by now. Thank you! HEADLINES --------- ChangeSet@1.1868, 2004-09-13 15:50:00+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: save number of arguments for neigh_update() by flags. ChangeSet@1.1869, 2004-09-13 15:50:56+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: suspect REACHABLE entry if new lladdr is different. ChangeSet@1.1870, 2004-09-13 15:51:20+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: keep original state if new state is STALE and lladdr is unchanged ChangeSet@1.1871, 2004-09-13 15:52:13+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: merge two flags for neigh_update() into one. ChangeSet@1.1872, 2004-09-13 15:54:11+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: update IsRouter flag appropriately. ChangeSet@1.1873, 2004-09-13 15:54:32+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: use time_after() and its friends. ChangeSet@1.1874, 2004-09-13 15:56:10+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: update entry appripriately when receiving NS. ChangeSet@1.1875, 2004-09-13 15:56:55+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: improve neighbour state machine. ChangeSet@1.1876, 2004-09-13 15:57:40+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Fix message validation against Redirects. ChangeSet@1.1877, 2004-09-13 15:59:11+09:00, yoshfuji@linux-ipv6.org [IPV6] don't use expired default routes. ChangeSet@1.1878, 2004-09-13 16:02:20+09:00, yoshfuji@linux-ipv6.org [IPV6] ensure to aging default routes. ChangeSet@1.1879, 2004-09-13 16:04:16+09:00, yoshfuji@linux-ipv6.org [IPV6] purge routes via non-router neighbour but gateway. DIFFSTATS --------- include/net/ip6_route.h | 1 include/net/neighbour.h | 5 - net/core/neighbour.c | 221 ++++++++++++++++++++++++++---------------------- net/ipv6/ip6_fib.c | 12 ++ net/ipv6/ndisc.c | 56 ++++++------ net/ipv6/route.c | 54 +++++++---- 6 files changed, 199 insertions(+), 150 deletions(-) CHANGESETS ---------- ChangeSet@1.1868, 2004-09-13 15:50:00+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: save number of arguments for neigh_update() by flags. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-13 16:32:27 +09:00 +++ b/include/net/neighbour.h 2004-09-13 16:32:27 +09:00 @@ -179,6 +179,10 @@ struct pneigh_entry *phash_buckets[PNEIGH_HASHMASK+1]; }; +/* flags for neigh_update() */ +#define NEIGH_UPDATE_F_OVERRIDE 0x00000001 +#define NEIGH_UPDATE_F_ADMIN 0x80000000 + extern void neigh_table_init(struct neigh_table *tbl); extern int neigh_table_clear(struct neigh_table *tbl); extern struct neighbour * neigh_lookup(struct neigh_table *tbl, @@ -189,7 +193,8 @@ struct net_device *dev); extern void neigh_destroy(struct neighbour *neigh); extern int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb); -extern int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, int override, int arp); +extern int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, + u32 flags); extern void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev); extern int neigh_ifdown(struct neigh_table *tbl, struct net_device *dev); extern int neigh_resolve_output(struct sk_buff *skb); diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c 2004-09-13 16:32:27 +09:00 +++ b/net/atm/clip.c 2004-09-13 16:32:27 +09:00 @@ -110,7 +110,8 @@ goto out; entry->expires = jiffies-1; /* force resolution or expiration */ - error = neigh_update(entry->neigh,NULL,NUD_NONE,0,0); + error = neigh_update(entry->neigh, NULL, NUD_NONE, + NEIGH_UPDATE_F_ADMIN); if (error) printk(KERN_CRIT "unlink_clip_vcc: " "neigh_update failed with %d\n",error); @@ -570,7 +571,8 @@ } link_vcc(clip_vcc,entry); } - error = neigh_update(neigh,llc_oui,NUD_PERMANENT,1,0); + error = neigh_update(neigh, llc_oui, NUD_PERMANENT, + NEIGH_UPDATE_F_OVERRIDE|NEIGH_UPDATE_F_ADMIN); neigh_release(neigh); return error; } diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:27 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:27 +09:00 @@ -800,14 +800,16 @@ /* Generic update routine. -- lladdr is new lladdr or NULL, if it is not supplied. -- new is new state. - -- override == 1 allows to override existing lladdr, if it is different. - -- arp == 0 means that the change is administrative. + -- flags + NEIGH_UPDATE_F_OVERRIDE allows to override existing lladdr, + if it is different. + NEIGH_UPDATE_F_ADMIN means that the change is administrative. Caller MUST hold reference count on the entry. */ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new, - int override, int arp) + u32 flags) { u8 old; int err; @@ -822,7 +824,8 @@ old = neigh->nud_state; err = -EPERM; - if (arp && (old & (NUD_NOARP | NUD_PERMANENT))) + if (!(flags & NEIGH_UPDATE_F_ADMIN) && + (old & (NUD_NOARP | NUD_PERMANENT))) goto out; if (!(new & NUD_VALID)) { @@ -850,7 +853,7 @@ if (old & NUD_VALID) { if (!memcmp(lladdr, neigh->ha, dev->addr_len)) lladdr = neigh->ha; - else if (!override) + else if (!(flags & NEIGH_UPDATE_F_OVERRIDE)) goto out; } } else { @@ -928,7 +931,8 @@ struct neighbour *neigh = __neigh_lookup(tbl, saddr, dev, lladdr || !dev->addr_len); if (neigh) - neigh_update(neigh, lladdr, NUD_STALE, 1, 1); + neigh_update(neigh, lladdr, NUD_STALE, + NEIGH_UPDATE_F_OVERRIDE); return neigh; } @@ -1274,7 +1278,9 @@ n = neigh_lookup(tbl, RTA_DATA(nda[NDA_DST - 1]), dev); if (n) { - err = neigh_update(n, NULL, NUD_FAILED, 1, 0); + err = neigh_update(n, NULL, NUD_FAILED, + NEIGH_UPDATE_F_OVERRIDE| + NEIGH_UPDATE_F_ADMIN); neigh_release(n); } goto out_dev_put; @@ -1347,7 +1353,8 @@ RTA_DATA(nda[NDA_LLADDR - 1]) : NULL, ndm->ndm_state, - override, 0); + (override ? NEIGH_UPDATE_F_OVERRIDE : 0) | + NEIGH_UPDATE_F_ADMIN); } if (n) neigh_release(n); diff -Nru a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c 2004-09-13 16:32:27 +09:00 +++ b/net/ipv4/arp.c 2004-09-13 16:32:27 +09:00 @@ -914,7 +914,7 @@ if (arp->ar_op != htons(ARPOP_REPLY) || skb->pkt_type != PACKET_HOST) state = NUD_STALE; - neigh_update(n, sha, state, override, 1); + neigh_update(n, sha, state, override ? NEIGH_UPDATE_F_OVERRIDE : 0); neigh_release(n); } @@ -1021,7 +1021,9 @@ if (r->arp_flags & ATF_PERM) state = NUD_PERMANENT; err = neigh_update(neigh, (r->arp_flags&ATF_COM) ? - r->arp_ha.sa_data : NULL, state, 1, 0); + r->arp_ha.sa_data : NULL, state, + NEIGH_UPDATE_F_OVERRIDE| + NEIGH_UPDATE_F_ADMIN); neigh_release(neigh); } return err; @@ -1101,7 +1103,9 @@ neigh = neigh_lookup(&arp_tbl, &ip, dev); if (neigh) { if (neigh->nud_state&~NUD_NOARP) - err = neigh_update(neigh, NULL, NUD_FAILED, 1, 0); + err = neigh_update(neigh, NULL, NUD_FAILED, + NEIGH_UPDATE_F_OVERRIDE| + NEIGH_UPDATE_F_ADMIN); neigh_release(neigh); } return err; diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:27 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:27 +09:00 @@ -911,7 +911,7 @@ neigh_update(neigh, lladdr, msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, - msg->icmph.icmp6_override, 1); + msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0); neigh_release(neigh); } } @@ -1079,7 +1079,7 @@ goto out; } } - neigh_update(neigh, lladdr, NUD_STALE, 1, 1); + neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_OVERRIDE); } if (ndopts.nd_opts_pi) { @@ -1204,7 +1204,7 @@ neigh = __neigh_lookup(&nd_tbl, target, skb->dev, 1); if (neigh) { - neigh_update(neigh, lladdr, NUD_STALE, 1, 1); + neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_OVERRIDE); if (neigh->nud_state&NUD_VALID) rt6_redirect(dest, &skb->nh.ipv6h->saddr, neigh, on_link); else ChangeSet@1.1869, 2004-09-13 15:50:56+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: suspect REACHABLE entry if new lladdr is different. When we receive NA without Override flag, if it comes with different lladdr from one in our REACHABLE entry, set the state to STALE. (RFC2461 7.2.5) Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-13 16:32:31 +09:00 +++ b/include/net/neighbour.h 2004-09-13 16:32:31 +09:00 @@ -181,6 +181,7 @@ /* flags for neigh_update() */ #define NEIGH_UPDATE_F_OVERRIDE 0x00000001 +#define NEIGH_UPDATE_F_SUSPECT_CONNECTED 0x00000002 #define NEIGH_UPDATE_F_ADMIN 0x80000000 extern void neigh_table_init(struct neigh_table *tbl); diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:31 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:31 +09:00 @@ -803,6 +803,9 @@ -- flags NEIGH_UPDATE_F_OVERRIDE allows to override existing lladdr, if it is different. + NEIGH_UPDATE_F_SUSPECT_CONNECTED will suspect existing "connected" + lladdr instead of overriding it + if it is different. NEIGH_UPDATE_F_ADMIN means that the change is administrative. Caller MUST hold reference count on the entry. @@ -850,12 +853,9 @@ - compare new & old - if they are different, check override flag */ - if (old & NUD_VALID) { - if (!memcmp(lladdr, neigh->ha, dev->addr_len)) - lladdr = neigh->ha; - else if (!(flags & NEIGH_UPDATE_F_OVERRIDE)) - goto out; - } + if ((old & NUD_VALID) && + !memcmp(lladdr, neigh->ha, dev->addr_len)) + lladdr = neigh->ha; } else { /* No address is supplied; if we know something, use it, otherwise discard the request. @@ -876,9 +876,20 @@ do not change entry state, if new one is STALE. */ err = 0; - if ((old & NUD_VALID) && lladdr == neigh->ha && - (new == old || (new == NUD_STALE && (old & NUD_CONNECTED)))) - goto out; + if (old & NUD_VALID) { + if (lladdr != neigh->ha && !(flags & NEIGH_UPDATE_F_OVERRIDE)) { + if ((flags & NEIGH_UPDATE_F_SUSPECT_CONNECTED) && + (old & NUD_CONNECTED)) { + lladdr = neigh->ha; + new = NUD_STALE; + } else + goto out; + } else { + if (lladdr == neigh->ha && + new == NUD_STALE && (old & NUD_CONNECTED)) + new = old; + } + } neigh_del_timer(neigh); neigh->nud_state = new; diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:31 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:31 +09:00 @@ -911,7 +911,8 @@ neigh_update(neigh, lladdr, msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, - msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0); + NEIGH_UPDATE_F_SUSPECT_CONNECTED| + (msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0)); neigh_release(neigh); } } ChangeSet@1.1870, 2004-09-13 15:51:20+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: keep original state if new state is STALE and lladdr is unchanged Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-13 16:32:34 +09:00 +++ b/include/net/neighbour.h 2004-09-13 16:32:34 +09:00 @@ -182,6 +182,7 @@ /* flags for neigh_update() */ #define NEIGH_UPDATE_F_OVERRIDE 0x00000001 #define NEIGH_UPDATE_F_SUSPECT_CONNECTED 0x00000002 +#define NEIGH_UPDATE_F_RETAIN_STATE 0x00000004 #define NEIGH_UPDATE_F_ADMIN 0x80000000 extern void neigh_table_init(struct neigh_table *tbl); diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:34 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:34 +09:00 @@ -806,6 +806,8 @@ NEIGH_UPDATE_F_SUSPECT_CONNECTED will suspect existing "connected" lladdr instead of overriding it if it is different. + NEIGH_UPDATE_F_RETAIN_STATE allows to retain current state + if lladdr is unchanged. NEIGH_UPDATE_F_ADMIN means that the change is administrative. Caller MUST hold reference count on the entry. @@ -885,8 +887,9 @@ } else goto out; } else { - if (lladdr == neigh->ha && - new == NUD_STALE && (old & NUD_CONNECTED)) + if (lladdr == neigh->ha && new == NUD_STALE && + ((flags & NEIGH_UPDATE_F_RETAIN_STATE) || + (old & NUD_CONNECTED))) new = old; } } diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:34 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:34 +09:00 @@ -912,6 +912,7 @@ neigh_update(neigh, lladdr, msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, NEIGH_UPDATE_F_SUSPECT_CONNECTED| + NEIGH_UPDATE_F_RETAIN_STATE| (msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0)); neigh_release(neigh); } @@ -1080,7 +1081,9 @@ goto out; } } - neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_OVERRIDE); + neigh_update(neigh, lladdr, NUD_STALE, + NEIGH_UPDATE_F_RETAIN_STATE| + NEIGH_UPDATE_F_OVERRIDE); } if (ndopts.nd_opts_pi) { @@ -1205,7 +1208,9 @@ neigh = __neigh_lookup(&nd_tbl, target, skb->dev, 1); if (neigh) { - neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_OVERRIDE); + neigh_update(neigh, lladdr, NUD_STALE, + NEIGH_UPDATE_F_RETAIN_STATE| + NEIGH_UPDATE_F_OVERRIDE); if (neigh->nud_state&NUD_VALID) rt6_redirect(dest, &skb->nh.ipv6h->saddr, neigh, on_link); else ChangeSet@1.1871, 2004-09-13 15:52:13+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: merge two flags for neigh_update() into one. This is because SUSPECT_CONNECTED can be effective only if OVERRIDE is unset, and used only if RETAIN_STATE is set. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-13 16:32:37 +09:00 +++ b/include/net/neighbour.h 2004-09-13 16:32:37 +09:00 @@ -181,8 +181,7 @@ /* flags for neigh_update() */ #define NEIGH_UPDATE_F_OVERRIDE 0x00000001 -#define NEIGH_UPDATE_F_SUSPECT_CONNECTED 0x00000002 -#define NEIGH_UPDATE_F_RETAIN_STATE 0x00000004 +#define NEIGH_UPDATE_F_WEAK_OVERRIDE 0x00000002 #define NEIGH_UPDATE_F_ADMIN 0x80000000 extern void neigh_table_init(struct neigh_table *tbl); diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:37 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:37 +09:00 @@ -803,10 +803,10 @@ -- flags NEIGH_UPDATE_F_OVERRIDE allows to override existing lladdr, if it is different. - NEIGH_UPDATE_F_SUSPECT_CONNECTED will suspect existing "connected" + NEIGH_UPDATE_F_WEAK_OVERRIDE will suspect existing "connected" lladdr instead of overriding it if it is different. - NEIGH_UPDATE_F_RETAIN_STATE allows to retain current state + It also allows to retain current state if lladdr is unchanged. NEIGH_UPDATE_F_ADMIN means that the change is administrative. @@ -880,7 +880,7 @@ err = 0; if (old & NUD_VALID) { if (lladdr != neigh->ha && !(flags & NEIGH_UPDATE_F_OVERRIDE)) { - if ((flags & NEIGH_UPDATE_F_SUSPECT_CONNECTED) && + if ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) && (old & NUD_CONNECTED)) { lladdr = neigh->ha; new = NUD_STALE; @@ -888,8 +888,9 @@ goto out; } else { if (lladdr == neigh->ha && new == NUD_STALE && - ((flags & NEIGH_UPDATE_F_RETAIN_STATE) || - (old & NUD_CONNECTED))) + ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) || + (old & NUD_CONNECTED)) + ) new = old; } } diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:37 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:37 +09:00 @@ -911,8 +911,7 @@ neigh_update(neigh, lladdr, msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, - NEIGH_UPDATE_F_SUSPECT_CONNECTED| - NEIGH_UPDATE_F_RETAIN_STATE| + NEIGH_UPDATE_F_WEAK_OVERRIDE| (msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0)); neigh_release(neigh); } @@ -1082,7 +1081,7 @@ } } neigh_update(neigh, lladdr, NUD_STALE, - NEIGH_UPDATE_F_RETAIN_STATE| + NEIGH_UPDATE_F_WEAK_OVERRIDE| NEIGH_UPDATE_F_OVERRIDE); } @@ -1209,7 +1208,7 @@ neigh = __neigh_lookup(&nd_tbl, target, skb->dev, 1); if (neigh) { neigh_update(neigh, lladdr, NUD_STALE, - NEIGH_UPDATE_F_RETAIN_STATE| + NEIGH_UPDATE_F_WEAK_OVERRIDE| NEIGH_UPDATE_F_OVERRIDE); if (neigh->nud_state&NUD_VALID) rt6_redirect(dest, &skb->nh.ipv6h->saddr, neigh, on_link); ChangeSet@1.1872, 2004-09-13 15:54:11+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: update IsRouter flag appropriately. Update IsRouter (NTF_ROUTER) flag approrpriately. Specifically, - we should not update it blindly; if Override Flag is unset and lladdr is differnt, we should NOT. - we should set it when we have received RA. - we should set it when we have received Redirect whose target is off-link. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-13 16:32:40 +09:00 +++ b/include/net/neighbour.h 2004-09-13 16:32:40 +09:00 @@ -182,6 +182,8 @@ /* flags for neigh_update() */ #define NEIGH_UPDATE_F_OVERRIDE 0x00000001 #define NEIGH_UPDATE_F_WEAK_OVERRIDE 0x00000002 +#define NEIGH_UPDATE_F_OVERRIDE_ISROUTER 0x00000004 +#define NEIGH_UPDATE_F_ISROUTER 0x40000000 #define NEIGH_UPDATE_F_ADMIN 0x80000000 extern void neigh_table_init(struct neigh_table *tbl); diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:40 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:40 +09:00 @@ -810,6 +810,11 @@ if lladdr is unchanged. NEIGH_UPDATE_F_ADMIN means that the change is administrative. + NEIGH_UPDATE_F_OVERRIDE_ISROUTER allows to override existing + NTF_ROUTER flag. + NEIGH_UPDATE_F_ISROUTER indicates if the neighbour is known as + a router. + Caller MUST hold reference count on the entry. */ @@ -822,6 +827,7 @@ int notify = 0; #endif struct net_device *dev; + int update_isrouter = 0; write_lock_bh(&neigh->lock); @@ -878,8 +884,10 @@ do not change entry state, if new one is STALE. */ err = 0; + update_isrouter = flags & NEIGH_UPDATE_F_OVERRIDE_ISROUTER; if (old & NUD_VALID) { if (lladdr != neigh->ha && !(flags & NEIGH_UPDATE_F_OVERRIDE)) { + update_isrouter = 0; if ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) && (old & NUD_CONNECTED)) { lladdr = neigh->ha; @@ -931,6 +939,11 @@ skb_queue_purge(&neigh->arp_queue); } out: + if (update_isrouter) { + neigh->flags = (flags & NEIGH_UPDATE_F_ISROUTER) ? + (neigh->flags | NTF_ROUTER) : + (neigh->flags & ~NTF_ROUTER); + } write_unlock_bh(&neigh->lock); #ifdef CONFIG_ARPD if (notify && neigh->parms->app_probes) diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:40 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:40 +09:00 @@ -894,25 +894,25 @@ neigh = neigh_lookup(&nd_tbl, &msg->target, dev); if (neigh) { - if (neigh->flags & NTF_ROUTER) { - if (msg->icmph.icmp6_router == 0) { - /* - * Change: router to host - */ - struct rt6_info *rt; - rt = rt6_get_dflt_router(saddr, dev); - if (rt) - ip6_del_rt(rt, NULL, NULL); - } - } else { - if (msg->icmph.icmp6_router) - neigh->flags |= NTF_ROUTER; - } + u8 old_flags = neigh->flags; neigh_update(neigh, lladdr, msg->icmph.icmp6_solicited ? NUD_REACHABLE : NUD_STALE, NEIGH_UPDATE_F_WEAK_OVERRIDE| - (msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0)); + (msg->icmph.icmp6_override ? NEIGH_UPDATE_F_OVERRIDE : 0)| + NEIGH_UPDATE_F_OVERRIDE_ISROUTER| + (msg->icmph.icmp6_router ? NEIGH_UPDATE_F_ISROUTER : 0)); + + if ((old_flags & ~neigh->flags) & NTF_ROUTER) { + /* + * Change: router to host + */ + struct rt6_info *rt; + rt = rt6_get_dflt_router(saddr, dev); + if (rt) + ip6_del_rt(rt, NULL, NULL); + } + neigh_release(neigh); } } @@ -1082,7 +1082,9 @@ } neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_WEAK_OVERRIDE| - NEIGH_UPDATE_F_OVERRIDE); + NEIGH_UPDATE_F_OVERRIDE| + NEIGH_UPDATE_F_OVERRIDE_ISROUTER| + NEIGH_UPDATE_F_ISROUTER); } if (ndopts.nd_opts_pi) { @@ -1209,7 +1211,10 @@ if (neigh) { neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_WEAK_OVERRIDE| - NEIGH_UPDATE_F_OVERRIDE); + NEIGH_UPDATE_F_OVERRIDE| + (on_link ? 0 : (NEIGH_UPDATE_F_OVERRIDE_ISROUTER| + NEIGH_UPDATE_F_ISROUTER)) + ); if (neigh->nud_state&NUD_VALID) rt6_redirect(dest, &skb->nh.ipv6h->saddr, neigh, on_link); else ChangeSet@1.1873, 2004-09-13 15:54:32+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: use time_after() and its friends. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:43 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:43 +09:00 @@ -133,7 +133,7 @@ if (atomic_read(&n->refcnt) == 1 && !(n->nud_state & NUD_PERMANENT) && (n->nud_state != NUD_INCOMPLETE || - jiffies - n->used > n->parms->retrans_time)) { + time_after(jiffies, n->used + n->parms->retrans_time))) { *np = n->next; n->dead = 1; shrunk = 1; @@ -255,7 +255,7 @@ if (tbl->entries > tbl->gc_thresh3 || (tbl->entries > tbl->gc_thresh2 && - now - tbl->last_flush > 5 * HZ)) { + time_after(now, tbl->last_flush + 5 * HZ))) { if (!neigh_forced_gc(tbl) && tbl->entries > tbl->gc_thresh3) goto out; @@ -563,12 +563,12 @@ if (state & (NUD_NOARP | NUD_PERMANENT)) return; if (state & NUD_REACHABLE) { - if (now - n->confirmed > n->parms->reachable_time) { + if (time_after(now, n->confirmed + n->parms->reachable_time)) { n->nud_state = NUD_STALE; neigh_suspect(n); } } else if (state & NUD_VALID) { - if (now - n->confirmed < n->parms->reachable_time) { + if (time_before(now, n->confirmed + n->parms->reachable_time)) { neigh_del_timer(n); n->nud_state = NUD_REACHABLE; neigh_connect(n); @@ -589,7 +589,7 @@ * periodically recompute ReachableTime from random function */ - if (now - tbl->last_rand > 300 * HZ) { + if (time_after(now, tbl->last_rand + 300 * HZ)) { struct neigh_parms *p; tbl->last_rand = now; for (p = &tbl->parms; p; p = p->next) @@ -612,12 +612,12 @@ goto next_elt; } - if ((long)(n->used - n->confirmed) < 0) + if (time_before(n->used, n->confirmed)) n->used = n->confirmed; if (atomic_read(&n->refcnt) == 1 && (state == NUD_FAILED || - now - n->used > n->parms->gc_staletime)) { + time_after(now, n->used + n->parms->gc_staletime))) { *np = n->next; n->dead = 1; write_unlock(&n->lock); @@ -626,7 +626,7 @@ } if (n->nud_state & NUD_REACHABLE && - now - n->confirmed > n->parms->reachable_time) { + time_after(now, n->confirmed + n->parms->reachable_time)) { n->nud_state = NUD_STALE; neigh_suspect(n); } @@ -671,7 +671,7 @@ } if ((state & NUD_VALID) && - now - neigh->confirmed < neigh->parms->reachable_time) { + time_before(now, neigh->confirmed + neigh->parms->reachable_time)) { neigh->nud_state = NUD_REACHABLE; NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); neigh_connect(neigh); @@ -1126,26 +1126,25 @@ struct sk_buff *skb) { unsigned long now = jiffies; - long sched_next = net_random() % p->proxy_delay; + unsigned long sched_next = now + (net_random() % p->proxy_delay); if (tbl->proxy_queue.qlen > p->proxy_qlen) { kfree_skb(skb); return; } skb->stamp.tv_sec = LOCALLY_ENQUEUED; - skb->stamp.tv_usec = now + sched_next; + skb->stamp.tv_usec = sched_next; spin_lock(&tbl->proxy_queue.lock); if (del_timer(&tbl->proxy_timer)) { - long tval = tbl->proxy_timer.expires - now; - if (tval < sched_next) - sched_next = tval; + if (time_before(tbl->proxy_timer.expires, sched_next)) + sched_next = tbl->proxy_timer.expires; } dst_release(skb->dst); skb->dst = NULL; dev_hold(skb->dev); __skb_queue_tail(&tbl->proxy_queue, skb); - mod_timer(&tbl->proxy_timer, now + sched_next); + mod_timer(&tbl->proxy_timer, sched_next); spin_unlock(&tbl->proxy_queue.lock); } ChangeSet@1.1874, 2004-09-13 15:56:10+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: update entry appripriately when receiving NS. Update neighbour entry appropriately by passing correct flags when receiving NS. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:46 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:46 +09:00 @@ -810,8 +810,11 @@ * update / create cache entry * for the source address */ - neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev); - + neigh = __neigh_lookup(&nd_tbl, saddr, dev, lladdr || !dev->addr_len); + if (neigh) + neigh_update(neigh, lladdr, NUD_STALE, + NEIGH_UPDATE_F_WEAK_OVERRIDE| + NEIGH_UPDATE_F_OVERRIDE); if (neigh || !dev->hard_header) { ndisc_send_na(dev, neigh, saddr, &msg->target, idev->cnf.forwarding, ChangeSet@1.1875, 2004-09-13 15:56:55+09:00, yoshfuji@linux-ipv6.org [NET] NEIGHBOUR: improve neighbour state machine. This centralizes neighbour state transition by timer into neigh_timer_handler(), and kill neigh_sync(). This improves timing accuracy of state transition. neigh_timer_handler() for each entry is now reponsible for state transition of the entry, and neigh_periodic_timer() is just for garbage collection. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-13 16:32:50 +09:00 +++ b/include/net/neighbour.h 2004-09-13 16:32:50 +09:00 @@ -51,7 +51,7 @@ #include #include -#define NUD_IN_TIMER (NUD_INCOMPLETE|NUD_DELAY|NUD_PROBE) +#define NUD_IN_TIMER (NUD_INCOMPLETE|NUD_REACHABLE|NUD_DELAY|NUD_PROBE) #define NUD_VALID (NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STALE|NUD_DELAY) #define NUD_CONNECTED (NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE) diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-13 16:32:50 +09:00 +++ b/net/core/neighbour.c 2004-09-13 16:32:50 +09:00 @@ -542,40 +542,6 @@ hh->hh_output = neigh->ops->hh_output; } -/* - Transitions NUD_STALE <-> NUD_REACHABLE do not occur - when fast path is built: we have no timers associated with - these states, we do not have time to check state when sending. - neigh_periodic_timer check periodically neigh->confirmed - time and moves NUD_REACHABLE -> NUD_STALE. - - If a routine wants to know TRUE entry state, it calls - neigh_sync before checking state. - - Called with write_locked neigh. - */ - -static void neigh_sync(struct neighbour *n) -{ - unsigned long now = jiffies; - u8 state = n->nud_state; - - if (state & (NUD_NOARP | NUD_PERMANENT)) - return; - if (state & NUD_REACHABLE) { - if (time_after(now, n->confirmed + n->parms->reachable_time)) { - n->nud_state = NUD_STALE; - neigh_suspect(n); - } - } else if (state & NUD_VALID) { - if (time_before(now, n->confirmed + n->parms->reachable_time)) { - neigh_del_timer(n); - n->nud_state = NUD_REACHABLE; - neigh_connect(n); - } - } -} - static void neigh_periodic_timer(unsigned long arg) { struct neigh_table *tbl = (struct neigh_table *)arg; @@ -624,12 +590,6 @@ neigh_release(n); continue; } - - if (n->nud_state & NUD_REACHABLE && - time_after(now, n->confirmed + n->parms->reachable_time)) { - n->nud_state = NUD_STALE; - neigh_suspect(n); - } write_unlock(&n->lock); next_elt: @@ -654,7 +614,7 @@ static void neigh_timer_handler(unsigned long arg) { - unsigned long now = jiffies; + unsigned long now, next; struct neighbour *neigh = (struct neighbour *)arg; unsigned state; int notify = 0; @@ -662,6 +622,8 @@ write_lock(&neigh->lock); state = neigh->nud_state; + now = jiffies; + next = now + HZ; if (!(state & NUD_IN_TIMER)) { #ifndef CONFIG_SMP @@ -670,20 +632,42 @@ goto out; } - if ((state & NUD_VALID) && - time_before(now, neigh->confirmed + neigh->parms->reachable_time)) { - neigh->nud_state = NUD_REACHABLE; - NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); - neigh_connect(neigh); - goto out; - } - if (state == NUD_DELAY) { - NEIGH_PRINTK2("neigh %p is probed.\n", neigh); - neigh->nud_state = NUD_PROBE; - atomic_set(&neigh->probes, 0); + if (state & NUD_REACHABLE) { + if (time_before_eq(now, + neigh->confirmed + neigh->parms->reachable_time)) { + NEIGH_PRINTK2("neigh %p is still alive.\n", neigh); + next = neigh->confirmed + neigh->parms->reachable_time; + } else if (time_before_eq(now, + neigh->used + neigh->parms->delay_probe_time)) { + NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); + neigh->nud_state = NUD_DELAY; + neigh_suspect(neigh); + next = now + neigh->parms->delay_probe_time; + } else { + NEIGH_PRINTK2("neigh %p is suspected.\n", neigh); + neigh->nud_state = NUD_STALE; + neigh_suspect(neigh); + } + } else if (state & NUD_DELAY) { + if (time_before_eq(now, + neigh->confirmed + neigh->parms->delay_probe_time)) { + NEIGH_PRINTK2("neigh %p is now reachable.\n", neigh); + neigh->nud_state = NUD_REACHABLE; + neigh_connect(neigh); + next = neigh->confirmed + neigh->parms->reachable_time; + } else { + NEIGH_PRINTK2("neigh %p is probed.\n", neigh); + neigh->nud_state = NUD_PROBE; + atomic_set(&neigh->probes, 0); + next = now + neigh->parms->retrans_time; + } + } else { + /* NUD_PROBE|NUD_INCOMPLETE */ + next = now + neigh->parms->retrans_time; } - if (atomic_read(&neigh->probes) >= neigh_max_probes(neigh)) { + if ((neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) && + atomic_read(&neigh->probes) >= neigh_max_probes(neigh)) { struct sk_buff *skb; neigh->nud_state = NUD_FAILED; @@ -703,19 +687,24 @@ write_lock(&neigh->lock); } skb_queue_purge(&neigh->arp_queue); - goto out; } - neigh->timer.expires = now + neigh->parms->retrans_time; - add_timer(&neigh->timer); - write_unlock(&neigh->lock); - - neigh->ops->solicit(neigh, skb_peek(&neigh->arp_queue)); - atomic_inc(&neigh->probes); - return; - + if (neigh->nud_state & NUD_IN_TIMER) { + neigh_hold(neigh); + if (time_before(next, jiffies + HZ/2)) + next = jiffies + HZ/2; + neigh->timer.expires = next; + add_timer(&neigh->timer); + } + if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) { + write_unlock(&neigh->lock); + neigh->ops->solicit(neigh, skb_peek(&neigh->arp_queue)); + atomic_inc(&neigh->probes); + } else { out: - write_unlock(&neigh->lock); + write_unlock(&neigh->lock); + } + #ifdef CONFIG_ARPD if (notify && neigh->parms->app_probes) neigh_app_notify(neigh); @@ -726,6 +715,7 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb) { int rc; + unsigned long now; write_lock_bh(&neigh->lock); @@ -733,18 +723,15 @@ if (neigh->nud_state & (NUD_CONNECTED | NUD_DELAY | NUD_PROBE)) goto out_unlock_bh; + now = jiffies; + if (!(neigh->nud_state & (NUD_STALE | NUD_INCOMPLETE))) { if (neigh->parms->mcast_probes + neigh->parms->app_probes) { atomic_set(&neigh->probes, neigh->parms->ucast_probes); neigh->nud_state = NUD_INCOMPLETE; neigh_hold(neigh); - neigh->timer.expires = jiffies + - neigh->parms->retrans_time; + neigh->timer.expires = now + 1; add_timer(&neigh->timer); - write_unlock_bh(&neigh->lock); - neigh->ops->solicit(neigh, skb); - atomic_inc(&neigh->probes); - write_lock_bh(&neigh->lock); } else { neigh->nud_state = NUD_FAILED; write_unlock_bh(&neigh->lock); @@ -753,6 +740,12 @@ kfree_skb(skb); return 1; } + } else if (neigh->nud_state & NUD_STALE) { + NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); + neigh_hold(neigh); + neigh->nud_state = NUD_DELAY; + neigh->timer.expires = jiffies + neigh->parms->delay_probe_time; + add_timer(&neigh->timer); } if (neigh->nud_state == NUD_INCOMPLETE) { @@ -767,13 +760,6 @@ __skb_queue_tail(&neigh->arp_queue, skb); } rc = 1; - } else if (neigh->nud_state == NUD_STALE) { - NEIGH_PRINTK2("neigh %p is delayed.\n", neigh); - neigh_hold(neigh); - neigh->nud_state = NUD_DELAY; - neigh->timer.expires = jiffies + neigh->parms->delay_probe_time; - add_timer(&neigh->timer); - rc = 0; } out_unlock_bh: write_unlock_bh(&neigh->lock); @@ -874,8 +860,6 @@ lladdr = neigh->ha; } - neigh_sync(neigh); - old = neigh->nud_state; if (new & NUD_CONNECTED) neigh->confirmed = jiffies; neigh->updated = jiffies; @@ -903,8 +887,18 @@ } } - neigh_del_timer(neigh); - neigh->nud_state = new; + if (new != old) { + neigh_del_timer(neigh); + if (new & NUD_IN_TIMER) { + neigh_hold(neigh); + neigh->timer.expires = jiffies + + ((new & NUD_REACHABLE) ? + neigh->parms->reachable_time : 0); + add_timer(&neigh->timer); + } + neigh->nud_state = new; + } + if (lladdr != neigh->ha) { memcpy(&neigh->ha, lladdr, dev->addr_len); neigh_update_hhs(neigh); ChangeSet@1.1876, 2004-09-13 15:57:40+09:00, yoshfuji@linux-ipv6.org [IPV6] NDISC: Fix message validation against Redirects. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/ip6_route.h b/include/net/ip6_route.h --- a/include/net/ip6_route.h 2004-09-13 16:32:53 +09:00 +++ b/include/net/ip6_route.h 2004-09-13 16:32:53 +09:00 @@ -92,6 +92,7 @@ extern void rt6_redirect(struct in6_addr *dest, struct in6_addr *saddr, struct neighbour *neigh, + u8 *lladdr, int on_link); extern void rt6_pmtu_discovery(struct in6_addr *daddr, diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-13 16:32:53 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-13 16:32:53 +09:00 @@ -1204,24 +1204,11 @@ return; } } - /* passed validation tests */ - - /* - We install redirect only if nexthop state is valid. - */ neigh = __neigh_lookup(&nd_tbl, target, skb->dev, 1); if (neigh) { - neigh_update(neigh, lladdr, NUD_STALE, - NEIGH_UPDATE_F_WEAK_OVERRIDE| - NEIGH_UPDATE_F_OVERRIDE| - (on_link ? 0 : (NEIGH_UPDATE_F_OVERRIDE_ISROUTER| - NEIGH_UPDATE_F_ISROUTER)) - ); - if (neigh->nud_state&NUD_VALID) - rt6_redirect(dest, &skb->nh.ipv6h->saddr, neigh, on_link); - else - __neigh_event_send(neigh, NULL); + rt6_redirect(dest, &skb->nh.ipv6h->saddr, neigh, lladdr, + on_link); neigh_release(neigh); } in6_dev_put(in6_dev); diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2004-09-13 16:32:53 +09:00 +++ b/net/ipv6/route.c 2004-09-13 16:32:53 +09:00 @@ -1007,7 +1007,7 @@ * Handle redirects */ void rt6_redirect(struct in6_addr *dest, struct in6_addr *saddr, - struct neighbour *neigh, int on_link) + struct neighbour *neigh, u8 *lladdr, int on_link) { struct rt6_info *rt, *nrt; @@ -1020,22 +1020,13 @@ if (neigh->dev != rt->rt6i_dev) goto out; - /* Redirect received -> path was valid. - Look, redirects are sent only in response to data packets, - so that this nexthop apparently is reachable. --ANK - */ - dst_confirm(&rt->u.dst); - - /* Duplicate redirect: silently ignore. */ - if (neigh == rt->u.dst.neighbour) - goto out; - - /* Current route is on-link; redirect is always invalid. - - Seems, previous statement is not true. It could - be node, which looks for us as on-link (f.e. proxy ndisc) - But then router serving it might decide, that we should - know truth 8)8) --ANK (980726). + /* + * Current route is on-link; redirect is always invalid. + * + * Seems, previous statement is not true. It could + * be node, which looks for us as on-link (f.e. proxy ndisc) + * But then router serving it might decide, that we should + * know truth 8)8) --ANK (980726). */ if (!(rt->rt6i_flags&RTF_GATEWAY)) goto out; @@ -1047,7 +1038,6 @@ * is a bit fuzzy and one might need to check all default * routers. */ - if (ipv6_addr_cmp(saddr, &rt->rt6i_gateway)) { if (rt->rt6i_flags & RTF_DEFAULT) { struct rt6_info *rt1; @@ -1075,6 +1065,24 @@ /* * We have finally decided to accept it. */ + + neigh_update(neigh, lladdr, NUD_STALE, + NEIGH_UPDATE_F_WEAK_OVERRIDE| + NEIGH_UPDATE_F_OVERRIDE| + (on_link ? 0 : (NEIGH_UPDATE_F_OVERRIDE_ISROUTER| + NEIGH_UPDATE_F_ISROUTER)) + ); + + /* + * Redirect received -> path was valid. + * Look, redirects are sent only in response to data packets, + * so that this nexthop apparently is reachable. --ANK + */ + dst_confirm(&rt->u.dst); + + /* Duplicate redirect: silently ignore. */ + if (neigh == rt->u.dst.neighbour) + goto out; nrt = ip6_rt_copy(rt); if (nrt == NULL) ChangeSet@1.1877, 2004-09-13 15:59:11+09:00, yoshfuji@linux-ipv6.org [IPV6] don't use expired default routes. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2004-09-13 16:32:56 +09:00 +++ b/net/ipv6/route.c 2004-09-13 16:32:56 +09:00 @@ -227,6 +227,10 @@ sprt->rt6i_dev->ifindex == oif)) m += 8; + if (sprt->rt6i_expires && + time_after(jiffies, sprt->rt6i_expires)) + continue; + if (sprt == rt6_dflt_pointer) m += 4; ChangeSet@1.1878, 2004-09-13 16:02:20+09:00, yoshfuji@linux-ipv6.org [IPV6] ensure to aging default routes. This patch is product of corraboration with Ville Nuorvala . Signed-off-by: Hideaki YOSHIFUJi diff -Nru a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c --- a/net/ipv6/ip6_fib.c 2004-09-13 16:32:59 +09:00 +++ b/net/ipv6/ip6_fib.c 2004-09-13 16:32:59 +09:00 @@ -49,6 +49,9 @@ struct rt6_statistics rt6_stats; +extern struct rt6_info *rt6_dflt_pointer; +extern spinlock_t rt6_dflt_lock; + static kmem_cache_t * fib6_node_kmem; enum fib_walk_state_t @@ -1184,6 +1187,10 @@ if (rt->rt6i_flags&RTF_EXPIRES && rt->rt6i_expires) { if (time_after(now, rt->rt6i_expires)) { RT6_TRACE("expiring %p\n", rt); + spin_lock_bh(&rt6_dflt_lock); + if (rt == rt6_dflt_pointer) + rt6_dflt_pointer = NULL; + spin_unlock_bh(&rt6_dflt_lock); return -1; } gc_args.more++; diff -Nru a/net/ipv6/route.c b/net/ipv6/route.c --- a/net/ipv6/route.c 2004-09-13 16:32:59 +09:00 +++ b/net/ipv6/route.c 2004-09-13 16:32:59 +09:00 @@ -208,8 +208,8 @@ /* * pointer to the last default router chosen. BH is disabled locally. */ -static struct rt6_info *rt6_dflt_pointer; -static spinlock_t rt6_dflt_lock = SPIN_LOCK_UNLOCKED; +struct rt6_info *rt6_dflt_pointer; +spinlock_t rt6_dflt_lock = SPIN_LOCK_UNLOCKED; /* Default Router Selection (RFC 2461 6.3.6) */ static struct rt6_info *rt6_best_dflt(struct rt6_info *rt, int oif) @@ -227,7 +227,7 @@ sprt->rt6i_dev->ifindex == oif)) m += 8; - if (sprt->rt6i_expires && + if ((sprt->rt6i_flags & RTF_EXPIRES) && time_after(jiffies, sprt->rt6i_expires)) continue; @@ -1265,7 +1265,7 @@ rtmsg.rtmsg_type = RTMSG_NEWROUTE; ipv6_addr_copy(&rtmsg.rtmsg_gateway, gwaddr); rtmsg.rtmsg_metric = 1024; - rtmsg.rtmsg_flags = RTF_GATEWAY | RTF_ADDRCONF | RTF_DEFAULT | RTF_UP; + rtmsg.rtmsg_flags = RTF_GATEWAY | RTF_ADDRCONF | RTF_DEFAULT | RTF_UP | RTF_EXPIRES; rtmsg.rtmsg_ifindex = dev->ifindex; ChangeSet@1.1879, 2004-09-13 16:04:16+09:00, yoshfuji@linux-ipv6.org [IPV6] purge routes via non-router neighbour but gateway. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c --- a/net/ipv6/ip6_fib.c 2004-09-13 16:33:02 +09:00 +++ b/net/ipv6/ip6_fib.c 2004-09-13 16:33:02 +09:00 @@ -1199,6 +1199,11 @@ time_after_eq(now, rt->u.dst.lastuse + gc_args.timeout)) { RT6_TRACE("aging clone %p\n", rt); return -1; + } else if ((rt->rt6i_flags & RTF_GATEWAY) && + (!(rt->rt6i_nexthop->flags & NTF_ROUTER))) { + RT6_TRACE("purging route %p via non-router but gateway\n", + rt); + return -1; } gc_args.more++; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pekkas@netcore.fi Mon Sep 13 07:29:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 07:29:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DETol3016731 for ; Mon, 13 Sep 2004 07:29:51 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8DETKi22830; Mon, 13 Sep 2004 17:29:20 +0300 Date: Mon, 13 Sep 2004 17:29:20 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@davemloft.net, , Subject: Re: [BK PATCH] [IPV6] Merge Specification Conformity Improvements In-Reply-To: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 8721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1093 Lines: 33 Thanks for doing these; I hope you guys will have energy for the other spec fixes to come :) One thing I noted when reading the comment: On Mon, 13 Sep 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > + /* > + * Redirect received -> path was valid. > + * Look, redirects are sent only in response to data packets, > + * so that this nexthop apparently is reachable. --ANK > + */ > + dst_confirm(&rt->u.dst); > + > + /* Duplicate redirect: silently ignore. */ > + if (neigh == rt->u.dst.neighbour) > + goto out; The above applies for "valid" redirects, which have been received based on the traffic sent. However, if someone would be forging redirects, the comment would no longer hold. I don't know the implications in this case: whether the code needs to have different assumptions wrt. source of redirects, or whether this is just a wording issue in the comment above. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From yoshfuji@linux-ipv6.org Mon Sep 13 08:02:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 08:02:19 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DF2CS5018257 for ; Mon, 13 Sep 2004 08:02:13 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D655C33CE7; Tue, 14 Sep 2004 00:02:05 +0900 (JST) Date: Tue, 14 Sep 2004 00:01:58 +0900 (JST) Message-Id: <20040914.000158.76078150.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: davem@davemloft.net, netdev@oss.sgi.com, vnuorval@tcs.hut.fi, yoshfuji@linux-ipv6.org Subject: Re: [BK PATCH] [IPV6] Merge Specification Conformity Improvements From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 763 Lines: 21 In article (at Mon, 13 Sep 2004 17:29:20 +0300 (EEST)), Pekka Savola says: > However, if someone would be forging redirects, the comment would no > longer hold. > > I don't know the implications in this case: whether the code needs to > have different assumptions wrt. source of redirects, or whether this > is just a wording issue in the comment above. I think we're protected (at least) as the standards says. eg. - off-link attacks - redirect from non-router for the destination etc. I'm not sure if we have other things we can do against this issue. I think other on-link issues (including "forging" issues) will be solved by SEND (SEcuring Neighbor Discovery). --yoshfuji From hallyn@CS.WM.EDU Mon Sep 13 08:09:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 08:09:58 -0700 (PDT) Received: from zimbo.cs.wm.edu (zimbo.cs.wm.edu [128.239.2.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DF9qK3018659 for ; Mon, 13 Sep 2004 08:09:53 -0700 Received: from escher.CS.WM.EDU (escher [128.239.26.27]) by zimbo.cs.wm.edu (8.12.8/8.12.8) with ESMTP id i8DF8q6T000673; Mon, 13 Sep 2004 11:08:52 -0400 Received: by escher.CS.WM.EDU (Postfix, from userid 1121) id C2EE6BBA44; Mon, 13 Sep 2004 11:08:51 -0400 (EDT) Date: Mon, 13 Sep 2004 11:08:51 -0400 To: Alan Cox Cc: Chris Wright , Linux Kernel Mailing List , akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] BSD Jail LSM (2/3) Message-ID: <20040913150851.GA15000@escher.cs.wm.edu> References: <1094847705.2188.94.camel@serge.austin.ibm.com> <1094847787.2188.101.camel@serge.austin.ibm.com> <1094844708.18107.5.camel@localhost.localdomain> <20040912233342.GA12097@escher.cs.wm.edu> <1095072996.14355.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095072996.14355.12.camel@localhost.localdomain> User-Agent: Mutt/1.5.6i From: hallyn@CS.WM.EDU (Serge E. Hallyn) X-archive-position: 8723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hallyn@CS.WM.EDU Precedence: bulk X-list: netdev Content-Length: 556 Lines: 16 Quoting Alan Cox (alan@lxorguk.ukuu.org.uk): > On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote: > > Right now one must choose between either an ipv4 or ipv6 interface. > > Is typical ipv6 usage such that it would be preferable to be able to > > specify one of each? > > Its normal to have both yes. > > A more interesting question is whether all of the "which socket for > which use" stuff could be addressed by netfilter chains run at > bind/connect time ? You mean to add two new netfilter hooks? Would these then replace the LSM hooks? -serge From jgarzik@pobox.com Mon Sep 13 09:10:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 09:10:35 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DGATMS024285 for ; Mon, 13 Sep 2004 09:10:30 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6tPF-00026D-G0; Mon, 13 Sep 2004 17:10:17 +0100 Message-ID: <4145C65B.4050703@pobox.com> Date: Mon, 13 Sep 2004 12:10:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] NETIF_F_LLTX for devices 2 References: <20040908072408.GI27886@wotan.suse.de> <1094629677.1089.155.camel@jzny.localdomain> <20040908134713.1bcd46d3.davem@davemloft.net> <1094823215.1121.129.camel@jzny.localdomain> <20040911142116.GL4431@wotan.suse.de> <1094933731.2343.109.camel@jzny.localdomain> <20040911174535.2acbb957.davem@davemloft.net> <20040912100114.GB11484@havoc.gtf.org> <20040912102529.GA27096@wotan.suse.de> <20040912161604.GA23366@havoc.gtf.org> <20040913065958.GC12185@wotan.suse.de> In-Reply-To: <20040913065958.GC12185@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 719 Lines: 26 Andi Kleen wrote: > On Sun, Sep 12, 2004 at 12:16:05PM -0400, Jeff Garzik wrote: > >>Incorrect, you are changing the callsites, which -does- affect every >>driver. > > > Please read the code before making such claims. > > The new return code is _only_ checked when NETIF_F_LLTX is set. > A driver that doesn't set this new flag won't ever recognize > any difference. I read the code :) The basic premise is that one should be _really_ conservative when touching the core RX and TX paths. Regardless of how safe _you_ feel the code is, it is very new, under-analyzed, and untried. The NAPI-related bug recently fixed in tg3 is an example of the unintended consequences of using this new feature. Jeff From greearb@candelatech.com Mon Sep 13 09:36:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 09:36:09 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DGa0qA025009 for ; Mon, 13 Sep 2004 09:36:00 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8DGbjLH003307; Mon, 13 Sep 2004 09:37:50 -0700 Message-ID: <4145CC53.8080405@candelatech.com> Date: Mon, 13 Sep 2004 09:35:31 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick CC: davem@redhat.com, linux.nics@intel.com, "'netdev@oss.sgi.com'" Subject: Re: Hard freeze (linux 2.6.7) or OOPS (linux 2.6.8.1) with e1000 + vlan, possible bug References: <20040913141059.GJ21600@nohope.patoche.org> In-Reply-To: <20040913141059.GJ21600@nohope.patoche.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 10161 Lines: 205 Patrick wrote: > Hello, > > I'm contacting you both because I believe there may be a problem in > the e1000 driver for linux, the vlan module or both. There were some recent locking changes, which included a bug, in the VLAN code. This was fixed late last week, but I don't know if the fix is in the version that you are running. The 2.6.8.1 oops looks like it could be the bug introduced recently, but I don't think that bug exists at all in 2.6.7. I'm cc'ing netdev as well, maybe someone else has some better ideas. To trouble-shoot, any chance you could try with a different NIC (maybe broadcom running the tg3 driver)? Can you reproduce if you do not use SAMBA? > > I have a box with an Intel Xeon 2.40 GHz with on-board Intel gigabit > connections (two) and an additionnal 2 gigabit ports PCI card. > So I'm using 3 of those 4 gigabit ports with the e1000 driver, and > some vlans. > e1000 and 8021q are compiled as modules (loaded at boot with /etc/modules, 8021q listed before e1000). > Kernel output: > Linux version 2.6.8.1 (root@zatras) (gcc version 3.3.4 (Debian 1:3.3.4-4)) #1 SMP Mon Sep 13 10:31:31 CEST 2004 > [..] > 511MB LOWMEM available. > [..] > 802.1Q VLAN Support v1.8 Ben Greear > All bugs added by David S. Miller > [..] > Intel(R) PRO/1000 Network Driver - version 5.2.52-k4 > Copyright (c) 1999-2004 Intel Corporation. > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection > e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection > e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection > [..] > e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex > e1000: eth3: e1000_watchdog: NIC Link is Up 10 Mbps Half Duplex > [..] > e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex > > > The eth2 nic has currently 3 vlans. > > > Here is what is happening: > - with kernels 2.6.6 or 2.6.7 : 2 or 3 times per day, the box freeze > completely (keyboard unresponsive), nothing printed on console or in > log files. Does not seem to be related to network traffic (very low) > or anything else. > > - with kernel 2.6.8.1 : I have an OOPS right at boot and many > problems just after, so it may be an idea of the problem with > previous kernels > > Here is the relevant log: > Sep 13 12:30:02 whitestar kernel: e08390f5 > Sep 13 12:30:02 whitestar kernel: SMP > Sep 13 12:30:02 whitestar kernel: Modules linked in: af_packet md5 ipv6 8250 serial_core ipt_multiport ipt_MASQUERADE ipt_REJECT ipt_state ipt_limit ipt_LOG ip_nat_irc ip_nat_ftp iptable_nat iptable_mangle iptable_filter ip_conntrack_irc ip_conntrack_ftp ip_conntrack ip_tables dm_mod p4_clockmod speedstep_lib w83627hf_wdt w83627hf i2c_sensor i2c_isa i2c_core e1000 8021q > Sep 13 12:30:02 whitestar kernel: CPU: 0 > Sep 13 12:30:02 whitestar kernel: EIP: 0060:[__crc_scm_detach_fds+103817/677563] Not tainted > Sep 13 12:30:02 whitestar kernel: EFLAGS: 00010212 (2.6.8.1) > Sep 13 12:30:02 whitestar kernel: EIP is at e1000_shift_out_mdi_bits+0x22/0x8c [e1000] > Sep 13 12:30:02 whitestar kernel: eax: fffffffc ebx: 00000001 ecx: 0000001f edx: 00000000 > Sep 13 12:30:02 whitestar kernel: esi: de70bc10 edi: dca05e6c ebp: ffffffff esp: dca05e64 > Sep 13 12:30:02 whitestar kernel: ds: 007b es: 007b ss: 0068 > Sep 13 12:30:02 whitestar kernel: Process snmpd (pid: 1025, threadinfo=dca04000 task=dc9f1390) > Sep 13 12:30:02 whitestar kernel: Stack: 00000000 c0374000 0000000a 00001820 de70bc10 dca05ee2 dca05f30 e0839301 > Sep 13 12:30:02 whitestar kernel: de70bc10 ffffffff 00000020 dca05ecc de70ba20 dca05edc e0836a0c de70bc10 > Sep 13 12:30:02 whitestar kernel: 00000000 dca05ee2 dca05ecc de903005 dca05edc e0814688 de70b800 dca05ecc > Sep 13 12:30:02 whitestar kernel: Call Trace: > Sep 13 12:30:02 whitestar kernel: [__crc_scm_detach_fds+104341/677563] e1000_read_phy_reg_ex+0x92/0xb3 [e1000] > Sep 13 12:30:02 whitestar kernel: [__crc_scm_detach_fds+93856/677563] e1000_mii_ioctl+0x1c8/0x1ca [e1000] > Sep 13 12:30:02 whitestar kernel: [__crc_journal_load+4760390/4806698] vlan_dev_ioctl+0xb5/0xe9 [8021q] > Sep 13 12:30:02 whitestar kernel: [dev_ifsioc+851/957] dev_ifsioc+0x353/0x3bd > Sep 13 12:30:02 whitestar kernel: [dev_ioctl+355/618] dev_ioctl+0x163/0x26a > Sep 13 12:30:02 whitestar kernel: [inet_ioctl+142/158] inet_ioctl+0x8e/0x9e > Sep 13 12:30:02 whitestar kernel: [sock_ioctl+238/641] sock_ioctl+0xee/0x281 > Sep 13 12:30:02 whitestar kernel: [sys_ioctl+273/605] sys_ioctl+0x111/0x25d > Sep 13 12:30:02 whitestar kernel: [syscall_call+7/11] syscall_call+0x7/0xb > Sep 13 12:30:02 whitestar kernel: Code: 8b 02 d3 e3 0d 00 00 00 03 85 db 89 44 24 08 74 47 85 eb 74 > > > ksymoops says: > Error (regular_file): read_ksyms stat /proc/ksyms failed > ksymoops: No such file or directory > No modules in ksyms, skipping objects > No ksyms, skipping lsmod > Sep 13 12:30:02 whitestar kernel: e08390f5 > Sep 13 12:30:02 whitestar kernel: CPU: 0 > Sep 13 12:30:02 whitestar kernel: EIP: 0060:[__crc_scm_detach_fds+103817/677563] Not tainted > Sep 13 12:30:02 whitestar kernel: EFLAGS: 00010212 (2.6.8.1) > Sep 13 12:30:02 whitestar kernel: eax: fffffffc ebx: 00000001 ecx: 0000001f edx: 00000000 > Sep 13 12:30:02 whitestar kernel: esi: de70bc10 edi: dca05e6c ebp: ffffffff esp: dca05e64 > Sep 13 12:30:02 whitestar kernel: ds: 007b es: 007b ss: 0068 > Sep 13 12:30:02 whitestar kernel: Stack: 00000000 c0374000 0000000a 00001820 de70bc10 dca05ee2 dca05f30 e0839301 > Sep 13 12:30:02 whitestar kernel: de70bc10 ffffffff 00000020 dca05ecc de70ba20 dca05edc e0836a0c de70bc10 > Sep 13 12:30:02 whitestar kernel: 00000000 dca05ee2 dca05ecc de903005 dca05edc e0814688 de70b800 dca05ecc > Sep 13 12:30:02 whitestar kernel: Call Trace: > Warning (Oops_read): Code line not seen, dumping what data is available > > > >>>eax; fffffffc <__kernel_rt_sigreturn+1bbc/????> >>>esi; de70bc10 <__crc_cap_inode_removexattr+6c19a/188f0f> >>>edi; dca05e6c <__crc_wait_on_sync_kiocb+1c4c11/294abb> >>>ebp; ffffffff <__kernel_rt_sigreturn+1bbf/????> >>>esp; dca05e64 <__crc_wait_on_sync_kiocb+1c4c09/294abb> > > > Sep 13 12:30:02 whitestar kernel: Code: 8b 02 d3 e3 0d 00 00 00 03 85 db 89 44 24 08 74 47 85 eb 74 > Using defaults from ksymoops -t elf32-i386 -a i386 > > > Code; 00000000 Before first symbol > 00000000 <_EIP>: > Code; 00000000 Before first symbol > 0: 8b 02 mov (%edx),%eax > Code; 00000002 Before first symbol > 2: d3 e3 shl %cl,%ebx > Code; 00000004 Before first symbol > 4: 0d 00 00 00 03 or $0x3000000,%eax > Code; 00000009 Before first symbol > 9: 85 db test %ebx,%ebx > Code; 0000000b Before first symbol > b: 89 44 24 08 mov %eax,0x8(%esp,1) > Code; 0000000f Before first symbol > f: 74 47 je 58 <_EIP+0x58> > Code; 00000011 Before first symbol > 11: 85 eb test %ebp,%ebx > Code; 00000013 Before first symbol > 13: 74 00 je 15 <_EIP+0x15> > > > 1 warning and 1 error issued. Results may not be reliable. > > > > I've tried with and without HyperThreading enabled in Bios, and nosmp > flag at boot, but I have the same results in both cases. > I've also tried with boot options: noapic nolapic noacpi > without change. > > This message comes exactly 5 minutes after boot (probably due to snmp/mrtg generating network traffic). > After what I encounter problems: ifconfig hangs for example > (when running correctly with other kernel), here is the end of the strace: > > uname({sys="Linux", node="whitestar", ...}) = 0 > access("/proc/net", R_OK) = 0 > access("/proc/net/unix", R_OK) = 0 > socket(PF_FILE, SOCK_DGRAM, 0) = 3 > socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 > access("/proc/net/if_inet6", R_OK) = 0 > socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5 > access("/proc/net/ax25", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/net/nr", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/net/rose", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/net/ipx", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/net/appletalk", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/sys/net/econet", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/sys/net/ash", R_OK) = -1 ENOENT (No such file or directory) > access("/proc/net/x25", R_OK) = -1 ENOENT (No such file or directory) > open("/proc/net/dev", O_RDONLY) = 6 > fstat64(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 > read(6, "Inter-| Receive "..., 1024) = 1024 > read(6, "44 0 0 0 0 0 "..., 1024) = 292 > read(6, "", 1024) = 0 > close(6) = 0 > munmap(0x40018000, 4096) = 0 > ioctl(4, SIOCGIFCONF, { > > > and sits there indefinitely. > > Samba process (nmbd) is then in uninterruptible sleep (according to > ps), when it runs correctly under previous versions of kernel. > When I try to shutdown, it hangs when trying to deconfigure all network interfaces. > > > When I try to stress test with multiple ping -f/crashme/bonnie++ in parallel, the box has no problem, > and do not freeze. > > > Can you please let me know if you believe this to be a kernel bug and > in which part exactly, and/or what I can do to alleviate the problem > ? > The box is used in production as a firewall and was running correctly > until I started to use vlans (3 currently) and samba. > > Thanks for your help in advance, and do not hesitate to let me know > if I have forgotten to include needed information. > > Regards. > Patrick Mevzek. > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ravinandan.arakali@s2io.com Mon Sep 13 10:04:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 10:04:48 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DH4WxE026085 for ; Mon, 13 Sep 2004 10:04:33 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8DH4Fje021961; Mon, 13 Sep 2004 13:04:15 -0400 (EDT) Received: from rarakali ([10.16.16.160]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id i8DH45qG028437; Mon, 13 Sep 2004 13:04:05 -0400 (EDT) Reply-To: From: "Ravinandan Arakali" To: "'Jeff Garzik'" Cc: , , , Subject: RE: Patch submission for S2io Xframe driver to 2.6 kernel Date: Mon, 13 Sep 2004 10:09:53 -0700 Message-ID: <002201c499b4$7c7b60c0$a010100a@S2IOtech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01C49979.D01C88C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <413116FF.7000701@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@s2io.com Precedence: bulk X-list: netdev Content-Length: 209449 Lines: 6193 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C49979.D01C88C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jeff, Attached is the patch with the first round comments incorporated. In addition, this patch contains Some fixes related to 32-bit systems. Few fixes related to Rx path in NAPI. Thanks to all for the comments. Pls review this patch as well and come back with your comments. Regards, Ravi -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Saturday, August 28, 2004 4:37 PM To: ravinandan.arakali@s2io.com Cc: netdev@oss.sgi.com; leonid.grossman@s2io.com; raghavendra.koushik@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel is there a follow-up patch addressing the comments ? ------=_NextPart_000_0023_01C49979.D01C88C0 Content-Type: application/octet-stream; name="s2io_submit2_1_patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="s2io_submit2_1_patch" diff -urN vanilla_linux-2.6.7/drivers/net/Kconfig = linux-2.6.7/drivers/net/Kconfig=0A= --- vanilla_linux-2.6.7/drivers/net/Kconfig 2004-06-15 = 22:19:52.000000000 -0700=0A= +++ linux-2.6.7/drivers/net/Kconfig 2004-09-08 12:54:13.000000000 -0700=0A= @@ -2160,7 +2160,16 @@=0A= config S2IO_NAPI=0A= bool "Use Rx Polling (NAPI) (EXPERIMENTAL)"=0A= depends on S2IO && EXPERIMENTAL=0A= -=0A= +config 2BUFF_MODE=0A= + bool "Use 2 Buffer Mode on Rx side."=0A= + depends on S2IO=0A= + ---help---=0A= + On enabling the 2 buffer mode, the received frame will be=0A= + split into 2 parts before being DMA'ed to the hosts memory.=0A= + The parts are the ethernet header and ethernet payload. =0A= + This is useful on systems where DMA'ing to to unaligned =0A= + physical memory loactions comes with a heavy price.=0A= + If not sure please say N.=0A= endmenu=0A= =0A= source "drivers/net/tokenring/Kconfig"=0A= diff -urN vanilla_linux-2.6.7/drivers/net/s2io-regs.h = linux-2.6.7/drivers/net/s2io-regs.h=0A= --- vanilla_linux-2.6.7/drivers/net/s2io-regs.h 2004-06-15 = 22:19:22.000000000 -0700=0A= +++ linux-2.6.7/drivers/net/s2io-regs.h 2004-09-08 12:55:02.000000000 = -0700=0A= @@ -289,6 +289,8 @@=0A= u64 tda_err_alarm;=0A= =0A= u64 pcc_err_reg;=0A= +#define PCC_FB_ECC_DB_ERR vBIT(0xFF, 16, 8)=0A= +=0A= u64 pcc_err_mask;=0A= u64 pcc_err_alarm;=0A= =0A= @@ -512,6 +514,7 @@=0A= #define RX_PA_CFG_IGNORE_FRM_ERR BIT(1)=0A= #define RX_PA_CFG_IGNORE_SNAP_OUI BIT(2)=0A= #define RX_PA_CFG_IGNORE_LLC_CTRL BIT(3)=0A= +#define RX_PA_CFG_IGNORE_L2_ERR BIT(6)=0A= =0A= u8 unused12[0x700 - 0x1D8];=0A= =0A= diff -urN vanilla_linux-2.6.7/drivers/net/s2io.c = linux-2.6.7/drivers/net/s2io.c=0A= --- vanilla_linux-2.6.7/drivers/net/s2io.c 2004-06-15 22:19:37.000000000 = -0700=0A= +++ linux-2.6.7/drivers/net/s2io.c 2004-09-10 13:16:58.000000000 -0700=0A= @@ -61,6 +61,7 @@=0A= #include=0A= #include=0A= #include=0A= +#include=0A= #include=0A= =0A= /* local include */=0A= @@ -69,7 +70,16 @@=0A= =0A= /* S2io Driver name & version. */=0A= static char s2io_driver_name[] =3D "s2io";=0A= -static char s2io_driver_version[] =3D "Version 1.0";=0A= +static char s2iO_driver_version[] =3D "Version 1.1";=0A= +=0A= +/* =0A= + * Cards with following subsystem_id have a link state indication=0A= + * problem, 600B, 600C, 600D, 640B, 640C and 640D.=0A= + * macro below identifies these cards given the subsystem_id.=0A= + */=0A= +#define CARDS_WITH_FAULTY_LINK_INDICATORS(subid) \=0A= + (((subid >=3D 0x600B) && (subid <=3D 0x600D)) || \=0A= + ((subid >=3D 0x640B) && (subid <=3D 0x640D))) ? 1 : 0=0A= =0A= #define LINK_IS_UP(val64) (!(val64 & (ADAPTER_STATUS_RMAC_REMOTE_FAULT = | \=0A= ADAPTER_STATUS_RMAC_LOCAL_FAULT)))=0A= @@ -80,10 +90,11 @@=0A= static inline int rx_buffer_level(nic_t * sp, int rxb_size, int ring)=0A= {=0A= int level =3D 0;=0A= - if ((sp->pkt_cnt[ring] - rxb_size) > 128) {=0A= + if ((sp->pkt_cnt[ring] - rxb_size) > 16) {=0A= level =3D LOW;=0A= - if (rxb_size < sp->pkt_cnt[ring] / 8)=0A= + if ((sp->pkt_cnt[ring] - rxb_size) < MAX_RXDS_PER_BLOCK) {=0A= level =3D PANIC;=0A= + }=0A= }=0A= =0A= return level;=0A= @@ -99,45 +110,45 @@=0A= };=0A= =0A= static char ethtool_stats_keys[][ETH_GSTRING_LEN] =3D {=0A= - "tmac_frms",=0A= - "tmac_data_octets",=0A= - "tmac_drop_frms",=0A= - "tmac_mcst_frms",=0A= - "tmac_bcst_frms",=0A= - "tmac_pause_ctrl_frms",=0A= - "tmac_any_err_frms",=0A= - "tmac_vld_ip_octets",=0A= - "tmac_vld_ip",=0A= - "tmac_drop_ip",=0A= - "tmac_icmp",=0A= - "tmac_rst_tcp",=0A= - "tmac_tcp",=0A= - "tmac_udp",=0A= - "rmac_vld_frms",=0A= - "rmac_data_octets",=0A= - "rmac_fcs_err_frms",=0A= - "rmac_drop_frms",=0A= - "rmac_vld_mcst_frms",=0A= - "rmac_vld_bcst_frms",=0A= - "rmac_in_rng_len_err_frms",=0A= - "rmac_long_frms",=0A= - "rmac_pause_ctrl_frms",=0A= - "rmac_discarded_frms",=0A= - "rmac_usized_frms",=0A= - "rmac_osized_frms",=0A= - "rmac_frag_frms",=0A= - "rmac_jabber_frms",=0A= - "rmac_ip",=0A= - "rmac_ip_octets",=0A= - "rmac_hdr_err_ip",=0A= - "rmac_drop_ip",=0A= - "rmac_icmp",=0A= - "rmac_tcp",=0A= - "rmac_udp",=0A= - "rmac_err_drp_udp",=0A= - "rmac_pause_cnt",=0A= - "rmac_accepted_ip",=0A= - "rmac_err_tcp",=0A= + {"tmac_frms"},=0A= + {"tmac_data_octets"},=0A= + {"tmac_drop_frms"},=0A= + {"tmac_mcst_frms"},=0A= + {"tmac_bcst_frms"},=0A= + {"tmac_pause_ctrl_frms"},=0A= + {"tmac_any_err_frms"},=0A= + {"tmac_vld_ip_octets"},=0A= + {"tmac_vld_ip"},=0A= + {"tmac_drop_ip"},=0A= + {"tmac_icmp"},=0A= + {"tmac_rst_tcp"},=0A= + {"tmac_tcp"},=0A= + {"tmac_udp"},=0A= + {"rmac_vld_frms"},=0A= + {"rmac_data_octets"},=0A= + {"rmac_fcs_err_frms"},=0A= + {"rmac_drop_frms"},=0A= + {"rmac_vld_mcst_frms"},=0A= + {"rmac_vld_bcst_frms"},=0A= + {"rmac_in_rng_len_err_frms"},=0A= + {"rmac_long_frms"},=0A= + {"rmac_pause_ctrl_frms"},=0A= + {"rmac_discarded_frms"},=0A= + {"rmac_usized_frms"},=0A= + {"rmac_osized_frms"},=0A= + {"rmac_frag_frms"},=0A= + {"rmac_jabber_frms"},=0A= + {"rmac_ip"},=0A= + {"rmac_ip_octets"},=0A= + {"rmac_hdr_err_ip"},=0A= + {"rmac_drop_ip"},=0A= + {"rmac_icmp"},=0A= + {"rmac_tcp"},=0A= + {"rmac_udp"},=0A= + {"rmac_err_drp_udp"},=0A= + {"rmac_pause_cnt"},=0A= + {"rmac_accepted_ip"},=0A= + {"rmac_err_tcp"},=0A= };=0A= =0A= #define S2IO_STAT_LEN sizeof(ethtool_stats_keys)/ ETH_GSTRING_LEN=0A= @@ -147,7 +158,8 @@=0A= #define S2IO_STRINGS_LEN S2IO_TEST_LEN * ETH_GSTRING_LEN=0A= =0A= =0A= -/* Constants to be programmed into the Xena's registers to configure=0A= +/* =0A= + * Constants to be programmed into the Xena's registers to configure=0A= * the XAUI.=0A= */=0A= =0A= @@ -188,7 +200,9 @@=0A= END_SIGN=0A= };=0A= =0A= -/* Constants for Fixing the MacAddress problem seen mostly on=0A= +=0A= +/* =0A= + * Constants for Fixing the MacAddress problem seen mostly on=0A= * Alpha machines.=0A= */=0A= static u64 fix_mac[] =3D {=0A= @@ -209,16 +223,67 @@=0A= END_SIGN=0A= };=0A= =0A= -=0A= /* Module Loadable parameters. */=0A= -static u32 ring_num;=0A= static u32 frame_len[MAX_RX_RINGS];=0A= -static u32 ring_len[MAX_RX_RINGS];=0A= -static u32 fifo_num;=0A= -static u32 fifo_len[MAX_TX_FIFOS];=0A= static u32 rx_prio;=0A= static u32 tx_prio;=0A= -static u8 latency_timer =3D 0;=0A= +=0A= +static unsigned int lso_enable =3D 1;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= +static unsigned int indicate_max_pkts =3D 0;=0A= +#endif=0A= +static unsigned int cksum_offload_enable =3D 1;=0A= +static unsigned int TxFifoNum =3D 1;=0A= +static unsigned int TxFIFOLen_0 =3D DEFAULT_FIFO_LEN;=0A= +static unsigned int TxFIFOLen_1 =3D 0;=0A= +static unsigned int TxFIFOLen_2 =3D 0;=0A= +static unsigned int TxFIFOLen_3 =3D 0;=0A= +static unsigned int TxFIFOLen_4 =3D 0;=0A= +static unsigned int TxFIFOLen_5 =3D 0;=0A= +static unsigned int TxFIFOLen_6 =3D 0;=0A= +static unsigned int TxFIFOLen_7 =3D 0;=0A= +static unsigned int MaxTxDs =3D MAX_SKB_FRAGS;=0A= +static unsigned int RxRingNum =3D 1;=0A= +static unsigned int RxRingSz_0 =3D SMALL_BLK_CNT;=0A= +static unsigned int RxRingSz_1 =3D 0;=0A= +static unsigned int RxRingSz_2 =3D 0;=0A= +static unsigned int RxRingSz_3 =3D 0;=0A= +static unsigned int RxRingSz_4 =3D 0;=0A= +static unsigned int RxRingSz_5 =3D 0;=0A= +static unsigned int RxRingSz_6 =3D 0;=0A= +static unsigned int RxRingSz_7 =3D 0;=0A= +static unsigned int Stats_refresh_time =3D 4;=0A= +static unsigned int rmac_pause_time =3D 65535;=0A= +static unsigned int mc_pause_threshold_q0q3 =3D 187;=0A= +static unsigned int mc_pause_threshold_q4q7 =3D 187;=0A= +static unsigned int shared_splits =3D 0;=0A= +#if defined(__ia64__)=0A= +static unsigned int max_splits_trans =3D XENA_THREE_SPLIT_TRANSACTION;=0A= +#else=0A= +static unsigned int max_splits_trans =3D XENA_TWO_SPLIT_TRANSACTION;=0A= +#endif=0A= +static unsigned int tmac_util_period =3D 5;=0A= +static unsigned int rmac_util_period =3D 5;=0A= +static unsigned int tx_timer_val =3D 0xFFF;=0A= +static unsigned int tx_utilz_periodic =3D 1;=0A= +static unsigned int rx_timer_val =3D 0xFFF;=0A= +static unsigned int rx_utilz_periodic =3D 1;=0A= +static unsigned int tx_urange_a =3D 0xA;=0A= +static unsigned int tx_ufc_a =3D 0x10;=0A= +static unsigned int tx_urange_b =3D 0x10;=0A= +static unsigned int tx_ufc_b =3D 0x20;=0A= +static unsigned int tx_urange_c =3D 0x30;=0A= +static unsigned int tx_ufc_c =3D 0x40;=0A= +static unsigned int tx_ufc_d =3D 0x80;=0A= +static unsigned int rx_urange_a =3D 0xA;=0A= +static unsigned int rx_ufc_a =3D 0x1;=0A= +static unsigned int rx_urange_b =3D 0x10;=0A= +static unsigned int rx_ufc_b =3D 0x2;=0A= +static unsigned int rx_urange_c =3D 0x30;=0A= +static unsigned int rx_ufc_c =3D 0x40;=0A= +static unsigned int rx_ufc_d =3D 0x80;=0A= +static u8 latency_timer =3D 0xf8;=0A= +static u8 max_read_byte_cnt =3D 2;=0A= =0A= /* =0A= * S2IO device table.=0A= @@ -235,30 +300,36 @@=0A= MODULE_DEVICE_TABLE(pci, s2io_tbl);=0A= =0A= static struct pci_driver s2io_driver =3D {=0A= - name:"S2IO",=0A= - id_table:s2io_tbl,=0A= - probe:s2io_init_nic,=0A= - remove:__devexit_p(s2io_rem_nic),=0A= + name:"S2IO",=0A= + id_table:s2io_tbl,=0A= + probe:s2io_init_nic,=0A= + remove:__devexit_p(s2io_rem_nic),=0A= };=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * Device private variable.=0A= - * Return Value: =0A= - * SUCCESS on success and an appropriate -ve value on failure.=0A= - * Description: =0A= - * The function allocates the all memory areas shared =0A= - * between the NIC and the driver. This includes Tx descriptors, =0A= - * Rx descriptors and the statistics block.=0A= +/* A simplifier macro used both by init and free shared_mem Fns(). */=0A= +#define container_index(len, per_each) ((len+per_each - 1) / per_each)=0A= +=0A= +/**=0A= + * init_shared_mem - Allocation and Initialization of Memory=0A= + * @nic: Device private variable.=0A= + * Description: The function allocates the all memory areas shared =0A= + * between the NIC and the driver. This includes Tx descriptors, =0A= + * Rx descriptors and the statistics block.=0A= */=0A= -static int initSharedMem(struct s2io_nic *nic)=0A= +=0A= +static int init_shared_mem(struct s2io_nic *nic)=0A= {=0A= u32 size;=0A= void *tmp_v_addr, *tmp_v_addr_next;=0A= dma_addr_t tmp_p_addr, tmp_p_addr_next;=0A= RxD_block_t *pre_rxd_blk =3D NULL;=0A= int i, j, blk_cnt;=0A= + int lst_size, lst_per_page;=0A= struct net_device *dev =3D nic->dev;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + u64 tmp;=0A= + buffAdd_t *ba;=0A= +#endif=0A= =0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= @@ -270,7 +341,7 @@=0A= /* Allocation and initialization of TXDLs in FIOFs */=0A= size =3D 0;=0A= for (i =3D 0; i < config->TxFIFONum; i++) {=0A= - size +=3D config->TxCfg[i].FifoLen;=0A= + size +=3D config->tx_cfg[i].FifoLen;=0A= }=0A= if (size > MAX_AVAILABLE_TXDS) {=0A= DBG_PRINT(ERR_DBG, "%s: Total number of Tx FIFOs ",=0A= @@ -279,55 +350,71 @@=0A= DBG_PRINT(ERR_DBG, "that can be used\n");=0A= return FAILURE;=0A= }=0A= - size *=3D (sizeof(TxD_t) * config->MaxTxDs);=0A= =0A= - mac_control->txd_list_mem =3D pci_alloc_consistent=0A= - (nic->pdev, size, &mac_control->txd_list_mem_phy);=0A= - if (!mac_control->txd_list_mem) {=0A= - return -ENOMEM;=0A= - }=0A= - mac_control->txd_list_mem_sz =3D size;=0A= -=0A= - tmp_v_addr =3D mac_control->txd_list_mem;=0A= - tmp_p_addr =3D mac_control->txd_list_mem_phy;=0A= - memset(tmp_v_addr, 0, size);=0A= -=0A= - DBG_PRINT(INIT_DBG, "%s:List Mem PHY: 0x%llx\n", dev->name,=0A= - (unsigned long long) tmp_p_addr);=0A= + lst_size =3D (sizeof(TxD_t) * config->MaxTxDs);=0A= + lst_per_page =3D PAGE_SIZE / lst_size;=0A= =0A= for (i =3D 0; i < config->TxFIFONum; i++) {=0A= - mac_control->txdl_start_phy[i] =3D tmp_p_addr;=0A= - mac_control->txdl_start[i] =3D (TxD_t *) tmp_v_addr;=0A= + int fifo_len =3D config->tx_cfg[i].FifoLen;=0A= + int list_holder_size =3D fifo_len * sizeof(list_info_hold_t);=0A= + nic->list_info[i] =3D kmalloc(list_holder_size, GFP_KERNEL);=0A= + if (!nic->list_info[i]) {=0A= + DBG_PRINT(ERR_DBG,=0A= + "Malloc failed for list_info\n");=0A= + return -ENOMEM;=0A= + }=0A= + memset(nic->list_info[i], 0, list_holder_size);=0A= + }=0A= + for (i =3D 0; i < config->TxFIFONum; i++) {=0A= + int page_num =3D container_index(config->tx_cfg[i].FifoLen,=0A= + lst_per_page);=0A= mac_control->tx_curr_put_info[i].offset =3D 0;=0A= mac_control->tx_curr_put_info[i].fifo_len =3D=0A= - config->TxCfg[i].FifoLen - 1;=0A= + config->tx_cfg[i].FifoLen - 1;=0A= mac_control->tx_curr_get_info[i].offset =3D 0;=0A= mac_control->tx_curr_get_info[i].fifo_len =3D=0A= - config->TxCfg[i].FifoLen - 1;=0A= -=0A= - tmp_p_addr +=3D=0A= - (config->TxCfg[i].FifoLen * (sizeof(TxD_t)) *=0A= - config->MaxTxDs);=0A= - tmp_v_addr +=3D=0A= - (config->TxCfg[i].FifoLen * (sizeof(TxD_t)) *=0A= - config->MaxTxDs);=0A= + config->tx_cfg[i].FifoLen - 1;=0A= + for (j =3D 0; j < page_num; j++) {=0A= + int k =3D 0;=0A= + dma_addr_t tmp_p;=0A= + void *tmp_v;=0A= + tmp_v =3D pci_alloc_consistent(nic->pdev,=0A= + PAGE_SIZE, &tmp_p);=0A= + if (!tmp_v) {=0A= + DBG_PRINT(ERR_DBG,=0A= + "pci_alloc_consistent ");=0A= + DBG_PRINT(ERR_DBG, "failed for TxDL\n");=0A= + return -ENOMEM;=0A= + }=0A= + while (k < lst_per_page) {=0A= + int l =3D (j * lst_per_page) + k;=0A= + if (l =3D=3D config->tx_cfg[i].FifoLen)=0A= + goto end_txd_alloc;=0A= + nic->list_info[i][l].list_virt_addr =3D=0A= + tmp_v + (k * lst_size);=0A= + nic->list_info[i][l].list_phy_addr =3D=0A= + tmp_p + (k * lst_size);=0A= + k++;=0A= + }=0A= + }=0A= }=0A= + end_txd_alloc:=0A= =0A= /* Allocation and initialization of RXDs in Rings */=0A= size =3D 0;=0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= - if (config->RxCfg[i].NumRxd % (MAX_RXDS_PER_BLOCK + 1)) {=0A= + if (config->rx_cfg[i].NumRxd % (MAX_RXDS_PER_BLOCK + 1)) {=0A= DBG_PRINT(ERR_DBG, "%s: RxD count of ", dev->name);=0A= DBG_PRINT(ERR_DBG, "Ring%d is not a multiple of ",=0A= i);=0A= DBG_PRINT(ERR_DBG, "RxDs per Block");=0A= return FAILURE;=0A= }=0A= - size +=3D config->RxCfg[i].NumRxd;=0A= + size +=3D config->rx_cfg[i].NumRxd;=0A= nic->block_count[i] =3D=0A= - config->RxCfg[i].NumRxd / (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[i].NumRxd / (MAX_RXDS_PER_BLOCK + 1);=0A= nic->pkt_cnt[i] =3D=0A= - config->RxCfg[i].NumRxd - nic->block_count[i];=0A= + config->rx_cfg[i].NumRxd - nic->block_count[i];=0A= }=0A= size =3D (size * (sizeof(RxD_t)));=0A= mac_control->rxd_ring_mem_sz =3D size;=0A= @@ -336,20 +423,25 @@=0A= mac_control->rx_curr_get_info[i].block_index =3D 0;=0A= mac_control->rx_curr_get_info[i].offset =3D 0;=0A= mac_control->rx_curr_get_info[i].ring_len =3D=0A= - config->RxCfg[i].NumRxd - 1;=0A= + config->rx_cfg[i].NumRxd - 1;=0A= mac_control->rx_curr_put_info[i].block_index =3D 0;=0A= mac_control->rx_curr_put_info[i].offset =3D 0;=0A= mac_control->rx_curr_put_info[i].ring_len =3D=0A= - config->RxCfg[i].NumRxd - 1;=0A= + config->rx_cfg[i].NumRxd - 1;=0A= blk_cnt =3D=0A= - config->RxCfg[i].NumRxd / (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[i].NumRxd / (MAX_RXDS_PER_BLOCK + 1);=0A= /* Allocating all the Rx blocks */=0A= for (j =3D 0; j < blk_cnt; j++) {=0A= +#ifndef CONFIG_2BUFF_MODE=0A= size =3D (MAX_RXDS_PER_BLOCK + 1) * (sizeof(RxD_t));=0A= +#else=0A= + size =3D SIZE_OF_BLOCK;=0A= +#endif=0A= tmp_v_addr =3D pci_alloc_consistent(nic->pdev, size,=0A= &tmp_p_addr);=0A= if (tmp_v_addr =3D=3D NULL) {=0A= - /* In case of failure, freeSharedMem() =0A= + /*=0A= + * In case of failure, free_shared_mem() =0A= * is called, which should free any =0A= * memory that was alloced till the =0A= * failure happened.=0A= @@ -377,20 +469,68 @@=0A= pre_rxd_blk->reserved_1 =3D END_OF_BLOCK; /* last RxD =0A= * marker.=0A= */=0A= +#ifndef CONFIG_2BUFF_MODE=0A= pre_rxd_blk->reserved_2_pNext_RxD_block =3D=0A= (unsigned long) tmp_v_addr_next;=0A= +#endif=0A= pre_rxd_blk->pNext_RxD_Blk_physical =3D=0A= (u64) tmp_p_addr_next;=0A= }=0A= }=0A= =0A= +#ifdef CONFIG_2BUFF_MODE=0A= + /* =0A= + * Allocation of Storages for buffer addresses in 2BUFF mode=0A= + * and the buffers as well.=0A= + */=0A= + for (i =3D 0; i < config->RxRingNum; i++) {=0A= + blk_cnt =3D=0A= + config->rx_cfg[i].NumRxd / (MAX_RXDS_PER_BLOCK + 1);=0A= + nic->ba[i] =3D kmalloc((sizeof(buffAdd_t *) * blk_cnt),=0A= + GFP_KERNEL);=0A= + if (!nic->ba[i])=0A= + return -ENOMEM;=0A= + for (j =3D 0; j < blk_cnt; j++) {=0A= + int k =3D 0;=0A= + nic->ba[i][j] =3D kmalloc((sizeof(buffAdd_t) *=0A= + (MAX_RXDS_PER_BLOCK + 1)),=0A= + GFP_KERNEL);=0A= + if (!nic->ba[i][j])=0A= + return -ENOMEM;=0A= + while (k !=3D MAX_RXDS_PER_BLOCK) {=0A= + ba =3D &nic->ba[i][j][k];=0A= +=0A= + ba->ba_0_org =3D (void *) kmalloc=0A= + (BUF0_LEN + ALIGN_SIZE, GFP_ATOMIC);=0A= + if (!ba->ba_0_org)=0A= + return -ENOMEM;=0A= + tmp =3D (u64) ba->ba_0_org;=0A= + tmp +=3D ALIGN_SIZE;=0A= + tmp &=3D ~((u64) ALIGN_SIZE);=0A= + ba->ba_0 =3D (void *) tmp;=0A= +=0A= + ba->ba_1_org =3D (void *) kmalloc=0A= + (BUF1_LEN + ALIGN_SIZE, GFP_ATOMIC);=0A= + if (!ba->ba_1_org)=0A= + return -ENOMEM;=0A= + tmp =3D (u64) ba->ba_1_org;=0A= + tmp +=3D ALIGN_SIZE;=0A= + tmp &=3D ~((u64) ALIGN_SIZE);=0A= + ba->ba_1 =3D (void *) tmp;=0A= + k++;=0A= + }=0A= + }=0A= + }=0A= +#endif=0A= +=0A= /* Allocation and initialization of Statistics block */=0A= size =3D sizeof(StatInfo_t);=0A= mac_control->stats_mem =3D pci_alloc_consistent=0A= (nic->pdev, size, &mac_control->stats_mem_phy);=0A= =0A= if (!mac_control->stats_mem) {=0A= - /* In case of failure, freeSharedMem() is called, which =0A= + /* =0A= + * In case of failure, free_shared_mem() is called, which =0A= * should free any memory that was alloced till the =0A= * failure happened.=0A= */=0A= @@ -399,8 +539,12 @@=0A= mac_control->stats_mem_sz =3D size;=0A= =0A= tmp_v_addr =3D mac_control->stats_mem;=0A= - mac_control->StatsInfo =3D (StatInfo_t *) tmp_v_addr;=0A= + mac_control->stats_info =3D (StatInfo_t *) tmp_v_addr;=0A= memset(tmp_v_addr, 0, size);=0A= +#ifdef SNMP_SUPPORT=0A= + nic->nMemorySize =3D mac_control->txd_list_mem_sz +=0A= + mac_control->stats_mem_sz + mac_control->rxd_ring_mem_sz;=0A= +#endif=0A= =0A= DBG_PRINT(INIT_DBG, "%s:Ring Mem PHY: 0x%llx\n", dev->name,=0A= (unsigned long long) tmp_p_addr);=0A= @@ -408,22 +552,21 @@=0A= return SUCCESS;=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * Device peivate variable.=0A= - * Return Value: =0A= - * NONE=0A= - * Description: =0A= - * This function is to free all memory locations allocated by=0A= - * the initSharedMem() function and return it to the kernel.=0A= +/** =0A= + * free_shared_mem - Free the allocated Memory =0A= + * @nic: Device private variable.=0A= + * Description: This function is to free all memory locations allocated = by=0A= + * the init_shared_mem() function and return it to the kernel.=0A= */=0A= -static void freeSharedMem(struct s2io_nic *nic)=0A= +=0A= +static void free_shared_mem(struct s2io_nic *nic)=0A= {=0A= int i, j, blk_cnt, size;=0A= void *tmp_v_addr;=0A= dma_addr_t tmp_p_addr;=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= + int lst_size, lst_per_page;=0A= =0A= =0A= if (!nic)=0A= @@ -432,14 +575,30 @@=0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= =0A= - if (mac_control->txd_list_mem) {=0A= - pci_free_consistent(nic->pdev,=0A= - mac_control->txd_list_mem_sz,=0A= - mac_control->txd_list_mem,=0A= - mac_control->txd_list_mem_phy);=0A= + lst_size =3D (sizeof(TxD_t) * config->MaxTxDs);=0A= + lst_per_page =3D PAGE_SIZE / lst_size;=0A= +=0A= + for (i =3D 0; i < config->TxFIFONum; i++) {=0A= + int page_num =3D container_index(config->tx_cfg[i].FifoLen,=0A= + lst_per_page);=0A= + for (j =3D 0; j < page_num; j++) {=0A= + int mem_blks =3D (j * lst_per_page);=0A= + if (!nic->list_info[i][mem_blks].list_virt_addr)=0A= + break;=0A= + pci_free_consistent(nic->pdev, PAGE_SIZE,=0A= + nic->list_info[i][mem_blks].=0A= + list_virt_addr,=0A= + nic->list_info[i][mem_blks].=0A= + list_phy_addr);=0A= + }=0A= + kfree(nic->list_info[i]);=0A= }=0A= =0A= +#ifndef CONFIG_2BUFF_MODE=0A= size =3D (MAX_RXDS_PER_BLOCK + 1) * (sizeof(RxD_t));=0A= +#else=0A= + size =3D SIZE_OF_BLOCK;=0A= +#endif=0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= blk_cnt =3D nic->block_count[i];=0A= for (j =3D 0; j < blk_cnt; j++) {=0A= @@ -452,6 +611,28 @@=0A= }=0A= }=0A= =0A= +#ifdef CONFIG_2BUFF_MODE=0A= + /* Freeing buffer storage addresses in 2BUFF mode. */=0A= + for (i =3D 0; i < config->RxRingNum; i++) {=0A= + blk_cnt =3D=0A= + config->rx_cfg[i].NumRxd / (MAX_RXDS_PER_BLOCK + 1);=0A= + for (j =3D 0; j < blk_cnt; j++) {=0A= + int k =3D 0;=0A= + if (!nic->ba[i][j])=0A= + continue;=0A= + while (k !=3D MAX_RXDS_PER_BLOCK) {=0A= + buffAdd_t *ba =3D &nic->ba[i][j][k];=0A= + kfree(ba->ba_0_org);=0A= + kfree(ba->ba_1_org);=0A= + k++;=0A= + }=0A= + kfree(nic->ba[i][j]);=0A= + }=0A= + if (nic->ba[i])=0A= + kfree(nic->ba[i]);=0A= + }=0A= +#endif=0A= +=0A= if (mac_control->stats_mem) {=0A= pci_free_consistent(nic->pdev,=0A= mac_control->stats_mem_sz,=0A= @@ -460,16 +641,16 @@=0A= }=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * device peivate variable=0A= - * Return Value: =0A= - * SUCCESS on success and '-1' on failure (endian settings incorrect).=0A= - * Description: =0A= - * The function sequentially configures every block =0A= +/** =0A= + * init_nic - Initialization of hardware =0A= + * @nic: device peivate variable=0A= + * Description: The function sequentially configures every block =0A= * of the H/W from their reset values. =0A= + * Returns: SUCCESS on success and =0A= + * '-1' on failure (endian settings incorrect).=0A= */=0A= -static int initNic(struct s2io_nic *nic)=0A= +=0A= +static int init_nic(struct s2io_nic *nic)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= struct net_device *dev =3D nic->dev;=0A= @@ -485,11 +666,13 @@=0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= =0A= - /* Set proper endian settings and verify the same by =0A= - * reading the PIF Feed-back register.=0A= + /* =0A= + * Set proper endian settings and verify the same by =0A= + * reading the PIF Feed-back register.=0A= */=0A= #ifdef __BIG_ENDIAN=0A= - /* The device by default set to a big endian format, so =0A= + /*=0A= + * The device by default set to a big endian format, so =0A= * a big endian driver need not set anything.=0A= */=0A= writeq(0xffffffffffffffffULL, &bar0->swapper_ctrl);=0A= @@ -510,7 +693,8 @@=0A= SWAPPER_CTRL_STATS_FE | SWAPPER_CTRL_STATS_SE);=0A= writeq(val64, &bar0->swapper_ctrl);=0A= #else=0A= - /* Initially we enable all bits to make it accessible by =0A= + /* =0A= + * Initially we enable all bits to make it accessible by =0A= * the driver, then we selectively enable only those bits =0A= * that we want to set.=0A= */=0A= @@ -537,8 +721,9 @@=0A= writeq(val64, &bar0->swapper_ctrl);=0A= #endif=0A= =0A= - /* Verifying if endian settings are accurate by reading =0A= - * a feedback register.=0A= + /* =0A= + * Verifying if endian settings are accurate by =0A= + * reading a feedback register.=0A= */=0A= val64 =3D readq(&bar0->pif_rd_swapper_fb);=0A= if (val64 !=3D 0x0123456789ABCDEFULL) {=0A= @@ -559,10 +744,13 @@=0A= schedule_timeout(HZ / 2);=0A= =0A= /* Enable Receiving broadcasts */=0A= + add =3D (void *) &bar0->mac_cfg;=0A= val64 =3D readq(&bar0->mac_cfg);=0A= val64 |=3D MAC_RMAC_BCAST_ENABLE;=0A= writeq(RMAC_CFG_KEY(0x4C0D), &bar0->rmac_cfg_key);=0A= - writeq(val64, &bar0->mac_cfg);=0A= + writel((u32) val64, add);=0A= + writeq(RMAC_CFG_KEY(0x4C0D), &bar0->rmac_cfg_key);=0A= + writel((u32) (val64 >> 32), (add + 4));=0A= =0A= /* Read registers in all blocks */=0A= val64 =3D readq(&bar0->mac_int_mask);=0A= @@ -573,8 +761,9 @@=0A= val64 =3D dev->mtu;=0A= writeq(vBIT(val64, 2, 14), &bar0->rmac_max_pyld_len);=0A= =0A= - /* Configuring the XAUI Interface of Xena. =0A= - *****************************************=0A= + /* =0A= + * Configuring the XAUI Interface of Xena. =0A= + * ***************************************=0A= * To Configure the Xena's XAUI, one has to write a series =0A= * of 64 bit values into two registers in a particular =0A= * sequence. Hence a macro 'SWITCH_SIGN' has been defined =0A= @@ -593,8 +782,8 @@=0A= dtx_cnt++;=0A= goto mdio_cfg;=0A= }=0A= - writeq(default_dtx_cfg[dtx_cnt],=0A= - &bar0->dtx_control);=0A= + SPECIAL_REG_WRITE(default_dtx_cfg[dtx_cnt],=0A= + &bar0->dtx_control, UF);=0A= val64 =3D readq(&bar0->dtx_control);=0A= dtx_cnt++;=0A= }=0A= @@ -604,8 +793,8 @@=0A= mdio_cnt++;=0A= goto dtx_cfg;=0A= }=0A= - writeq(default_mdio_cfg[mdio_cnt],=0A= - &bar0->mdio_control);=0A= + SPECIAL_REG_WRITE(default_mdio_cfg[mdio_cnt],=0A= + &bar0->mdio_control, UF);=0A= val64 =3D readq(&bar0->mdio_control);=0A= mdio_cnt++;=0A= }=0A= @@ -627,8 +816,8 @@=0A= =0A= for (i =3D 0, j =3D 0; i < config->TxFIFONum; i++) {=0A= val64 |=3D=0A= - vBIT(config->TxCfg[i].FifoLen - 1, ((i * 32) + 19),=0A= - 13) | vBIT(config->TxCfg[i].FifoPriority,=0A= + vBIT(config->tx_cfg[i].FifoLen - 1, ((i * 32) + 19),=0A= + 13) | vBIT(config->tx_cfg[i].FifoPriority,=0A= ((i * 32) + 5), 3);=0A= =0A= if (i =3D=3D (config->TxFIFONum - 1)) {=0A= @@ -677,12 +866,13 @@=0A= val64 =3D 0;=0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= val64 |=3D=0A= - vBIT(config->RxCfg[i].RingPriority, (5 + (i * 8)), 3);=0A= + vBIT(config->rx_cfg[i].RingPriority, (5 + (i * 8)), 3);=0A= }=0A= writeq(val64, &bar0->rx_queue_priority);=0A= =0A= - /* Allocating equal share of memory to all the configured =0A= - * Rings.=0A= + /* =0A= + * Allocating equal share of memory to all the =0A= + * configured Rings.=0A= */=0A= val64 =3D 0;=0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= @@ -724,7 +914,8 @@=0A= }=0A= writeq(val64, &bar0->rx_queue_cfg);=0A= =0A= - /* Initializing the Tx round robin registers to 0.=0A= + /* =0A= + * Initializing the Tx round robin registers to 0.=0A= * Filling Tx and Rx round robin registers as per the =0A= * number of FIFOs and Rings is still TODO.=0A= */=0A= @@ -734,9 +925,11 @@=0A= writeq(0, &bar0->tx_w_round_robin_3);=0A= writeq(0, &bar0->tx_w_round_robin_4);=0A= =0A= - /* Disable Rx steering. Hard coding all packets be steered to=0A= + /* =0A= + * TODO=0A= + * Disable Rx steering. Hard coding all packets be steered to=0A= * Queue 0 for now. =0A= - * TODO*/=0A= + */=0A= if (rx_prio) {=0A= u64 def =3D 0x8000000000000000ULL, tmp;=0A= for (i =3D 0; i < MAX_RX_RINGS; i++) {=0A= @@ -760,34 +953,43 @@=0A= =0A= /* Enable statistics */=0A= writeq(mac_control->stats_mem_phy, &bar0->stat_addr);=0A= - val64 =3D SET_UPDT_PERIOD(8) | STAT_CFG_STAT_RO | STAT_CFG_STAT_EN;=0A= + val64 =3D SET_UPDT_PERIOD(Stats_refresh_time) |=0A= + STAT_CFG_STAT_RO | STAT_CFG_STAT_EN;=0A= writeq(val64, &bar0->stat_cfg);=0A= =0A= - /* Initializing the sampling rate for the device to calculate the=0A= + /* =0A= + * Initializing the sampling rate for the device to calculate the=0A= * bandwidth utilization.=0A= */=0A= - val64 =3D MAC_TX_LINK_UTIL_VAL(0x5) | MAC_RX_LINK_UTIL_VAL(0x5);=0A= + val64 =3D MAC_TX_LINK_UTIL_VAL(tmac_util_period) |=0A= + MAC_RX_LINK_UTIL_VAL(rmac_util_period);=0A= writeq(val64, &bar0->mac_link_util);=0A= =0A= =0A= - /* Initializing the Transmit and Receive Traffic Interrupt =0A= + /* =0A= + * Initializing the Transmit and Receive Traffic Interrupt =0A= * Scheme.=0A= */=0A= /* TTI Initialization */=0A= - val64 =3D TTI_DATA1_MEM_TX_TIMER_VAL(0xFFF) |=0A= - TTI_DATA1_MEM_TX_URNG_A(0xA) | TTI_DATA1_MEM_TX_URNG_B(0x10) |=0A= - TTI_DATA1_MEM_TX_URNG_C(0x30) | TTI_DATA1_MEM_TX_TIMER_AC_EN;=0A= + val64 =3D TTI_DATA1_MEM_TX_TIMER_VAL(tx_timer_val) |=0A= + TTI_DATA1_MEM_TX_URNG_A(tx_urange_a) |=0A= + TTI_DATA1_MEM_TX_URNG_B(tx_urange_b) |=0A= + TTI_DATA1_MEM_TX_URNG_C(tx_urange_c);=0A= + if (tx_utilz_periodic)=0A= + val64 |=3D TTI_DATA1_MEM_TX_TIMER_AC_EN;=0A= writeq(val64, &bar0->tti_data1_mem);=0A= =0A= - val64 =3D=0A= - TTI_DATA2_MEM_TX_UFC_A(0x10) | TTI_DATA2_MEM_TX_UFC_B(0x20) |=0A= - TTI_DATA2_MEM_TX_UFC_C(0x40) | TTI_DATA2_MEM_TX_UFC_D(0x80);=0A= + val64 =3D TTI_DATA2_MEM_TX_UFC_A(tx_ufc_a) |=0A= + TTI_DATA2_MEM_TX_UFC_B(tx_ufc_b) |=0A= + TTI_DATA2_MEM_TX_UFC_C(tx_ufc_c) |=0A= + TTI_DATA2_MEM_TX_UFC_D(tx_ufc_d);=0A= writeq(val64, &bar0->tti_data2_mem);=0A= =0A= val64 =3D TTI_CMD_MEM_WE | TTI_CMD_MEM_STROBE_NEW_CMD;=0A= writeq(val64, &bar0->tti_command_mem);=0A= =0A= - /* Once the operation completes, the Strobe bit of the command=0A= + /* =0A= + * Once the operation completes, the Strobe bit of the command=0A= * register will be reset. We poll for this particular condition=0A= * We wait for a maximum of 500ms for the operation to complete,=0A= * if it's not complete by then we return error.=0A= @@ -809,19 +1011,26 @@=0A= }=0A= =0A= /* RTI Initialization */=0A= - val64 =3D RTI_DATA1_MEM_RX_TIMER_VAL(0xFFF) |=0A= - RTI_DATA1_MEM_RX_URNG_A(0xA) | RTI_DATA1_MEM_RX_URNG_B(0x10) |=0A= - RTI_DATA1_MEM_RX_URNG_C(0x30) | RTI_DATA1_MEM_RX_TIMER_AC_EN;=0A= + val64 =3D RTI_DATA1_MEM_RX_TIMER_VAL(rx_timer_val) |=0A= + RTI_DATA1_MEM_RX_URNG_A(rx_urange_a) |=0A= + RTI_DATA1_MEM_RX_URNG_B(rx_urange_b) |=0A= + RTI_DATA1_MEM_RX_URNG_C(rx_urange_c);=0A= + if (rx_utilz_periodic)=0A= + val64 |=3D RTI_DATA1_MEM_RX_TIMER_AC_EN;=0A= +=0A= writeq(val64, &bar0->rti_data1_mem);=0A= =0A= - val64 =3D RTI_DATA2_MEM_RX_UFC_A(0x1) | RTI_DATA2_MEM_RX_UFC_B(0x2) |=0A= - RTI_DATA2_MEM_RX_UFC_C(0x40) | RTI_DATA2_MEM_RX_UFC_D(0x80);=0A= + val64 =3D RTI_DATA2_MEM_RX_UFC_A(rx_ufc_a) |=0A= + RTI_DATA2_MEM_RX_UFC_B(rx_ufc_b) |=0A= + RTI_DATA2_MEM_RX_UFC_C(rx_ufc_c) |=0A= + RTI_DATA2_MEM_RX_UFC_D(rx_ufc_d);=0A= writeq(val64, &bar0->rti_data2_mem);=0A= =0A= val64 =3D RTI_CMD_MEM_WE | RTI_CMD_MEM_STROBE_NEW_CMD;=0A= writeq(val64, &bar0->rti_command_mem);=0A= =0A= - /* Once the operation completes, the Strobe bit of the command=0A= + /* =0A= + * Once the operation completes, the Strobe bit of the command=0A= * register will be reset. We poll for this particular condition=0A= * We wait for a maximum of 500ms for the operation to complete,=0A= * if it's not complete by then we return error.=0A= @@ -842,7 +1051,8 @@=0A= schedule_timeout(HZ / 20);=0A= }=0A= =0A= - /* Initializing proper values as Pause threshold into all =0A= + /* =0A= + * Initializing proper values as Pause threshold into all =0A= * the 8 Queues on Rx side.=0A= */=0A= writeq(0xffbbffbbffbbffbbULL, &bar0->mc_pause_thresh_q0q3);=0A= @@ -858,22 +1068,62 @@=0A= writel((u32) (val64 >> 32), (add + 4));=0A= val64 =3D readq(&bar0->mac_cfg);=0A= =0A= + /* =0A= + * Set the time value to be inserted in the pause frame =0A= + * generated by xena.=0A= + */=0A= + val64 =3D readq(&bar0->rmac_pause_cfg);=0A= + val64 &=3D ~(RMAC_PAUSE_HG_PTIME(0xffff));=0A= + val64 |=3D RMAC_PAUSE_HG_PTIME(nic->mac_control.rmac_pause_time);=0A= + writeq(val64, &bar0->rmac_pause_cfg);=0A= +=0A= + /* =0A= + * Set the Threshold Limit for Generating the pause frame=0A= + * If the amount of data in any Queue exceeds ratio of=0A= + * (mac_control.mc_pause_threshold_q0q3 or q4q7)/256=0A= + * pause frame is generated=0A= + */=0A= + val64 =3D 0;=0A= + for (i =3D 0; i < 4; i++) {=0A= + val64 |=3D=0A= + (((u64) 0xFF00 | nic->mac_control.=0A= + mc_pause_threshold_q0q3)=0A= + << (i * 2 * 8));=0A= + }=0A= + writeq(val64, &bar0->mc_pause_thresh_q0q3);=0A= +=0A= + val64 =3D 0;=0A= + for (i =3D 0; i < 4; i++) {=0A= + val64 |=3D=0A= + (((u64) 0xFF00 | nic->mac_control.=0A= + mc_pause_threshold_q4q7)=0A= + << (i * 2 * 8));=0A= + }=0A= + writeq(val64, &bar0->mc_pause_thresh_q4q7);=0A= +=0A= + /* =0A= + * TxDMA will stop Read request if the number of read split has =0A= + * exceeded the limit pointed by shared_splits=0A= + */=0A= + val64 =3D readq(&bar0->pic_control);=0A= + val64 |=3D PIC_CNTL_SHARED_SPLITS(shared_splits);=0A= + writeq(val64, &bar0->pic_control);=0A= +=0A= return SUCCESS;=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * device private variable,=0A= - * A mask indicating which Intr block must be modified and,=0A= - * A flag indicating whether to enable or disable the Intrs.=0A= - * Return Value: =0A= - * NONE.=0A= - * Description: =0A= - * This function will either disable or enable the interrupts =0A= +/** =0A= + * en_dis_able_nic_intrs - Enable or Disable the interrupts =0A= + * @nic: device private variable,=0A= + * @mask: A mask indicating which Intr block must be modified and,=0A= + * @flag: A flag indicating whether to enable or disable the Intrs.=0A= + * Description: This function will either disable or enable the = interrupts=0A= * depending on the flag argument. The mask argument can be used to =0A= * enable/disable any Intr block. =0A= + * Return Value: NONE.=0A= */=0A= -static void en_dis_able_NicIntrs(struct s2io_nic *nic, u16 mask, int = flag)=0A= +=0A= +static void en_dis_able_nic_intrs(struct s2io_nic *nic, u16 mask, int = flag)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= register u64 val64 =3D 0, temp64 =3D 0;=0A= @@ -887,15 +1137,20 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* Disabled all PCIX, Flash, MDIO, IIC and GPIO=0A= - * interrupts for now. =0A= - * TODO */=0A= + /* =0A= + * Disabled all PCIX, Flash, MDIO, IIC and GPIO=0A= + * interrupts for now. =0A= + * TODO =0A= + */=0A= writeq(DISABLE_ALL_INTRS, &bar0->pic_int_mask);=0A= - /* No MSI Support is available presently, so TTI and=0A= + /* =0A= + * No MSI Support is available presently, so TTI and=0A= * RTI interrupts are also disabled.=0A= */=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable PIC Intrs in the general intr mask register =0A= + /* =0A= + * Disable PIC Intrs in the general =0A= + * intr mask register =0A= */=0A= writeq(DISABLE_ALL_INTRS, &bar0->pic_int_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= @@ -907,24 +1162,34 @@=0A= /* DMA Interrupts */=0A= /* Enabling/Disabling Tx DMA interrupts */=0A= if (mask & TX_DMA_INTR) {=0A= - /* Enable TxDMA Intrs in the general intr mask register */=0A= + /* Enable TxDMA Intrs in the general intr mask register */=0A= val64 =3D TXDMA_INT_M;=0A= if (flag =3D=3D ENABLE_INTRS) {=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* Disable all interrupts other than PFC interrupt in =0A= - * DMA level.=0A= + /* =0A= + * Keep all interrupts other than PFC interrupt =0A= + * and PCC interrupt disabled in DMA level.=0A= */=0A= - val64 =3D DISABLE_ALL_INTRS & (~TXDMA_PFC_INT_M);=0A= + val64 =3D DISABLE_ALL_INTRS & ~(TXDMA_PFC_INT_M |=0A= + TXDMA_PCC_INT_M);=0A= writeq(val64, &bar0->txdma_int_mask);=0A= - /* Enable only the MISC error 1 interrupt in PFC block =0A= + /* =0A= + * Enable only the MISC error 1 interrupt in PFC block =0A= */=0A= val64 =3D DISABLE_ALL_INTRS & (~PFC_MISC_ERR_1);=0A= writeq(val64, &bar0->pfc_err_mask);=0A= + /* =0A= + * Enable only the FB_ECC error interrupt in PCC block =0A= + */=0A= + val64 =3D DISABLE_ALL_INTRS & (~PCC_FB_ECC_ERR);=0A= + writeq(val64, &bar0->pcc_err_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable TxDMA Intrs in the general intr mask =0A= - * register */=0A= + /* =0A= + * Disable TxDMA Intrs in the general intr mask =0A= + * register =0A= + */=0A= writeq(DISABLE_ALL_INTRS, &bar0->txdma_int_mask);=0A= writeq(DISABLE_ALL_INTRS, &bar0->pfc_err_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= @@ -941,12 +1206,16 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* All RxDMA block interrupts are disabled for now =0A= - * TODO */=0A= + /* =0A= + * All RxDMA block interrupts are disabled for now =0A= + * TODO =0A= + */=0A= writeq(DISABLE_ALL_INTRS, &bar0->rxdma_int_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable RxDMA Intrs in the general intr mask =0A= - * register */=0A= + /* =0A= + * Disable RxDMA Intrs in the general intr mask =0A= + * register =0A= + */=0A= writeq(DISABLE_ALL_INTRS, &bar0->rxdma_int_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= val64 |=3D temp64;=0A= @@ -962,9 +1231,11 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* All MAC block error interrupts are disabled for now =0A= + /* =0A= + * All MAC block error interrupts are disabled for now =0A= * except the link status change interrupt.=0A= - * TODO*/=0A= + * TODO=0A= + */=0A= val64 =3D MAC_INT_STATUS_RMAC_INT;=0A= temp64 =3D readq(&bar0->mac_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= @@ -974,7 +1245,8 @@=0A= val64 &=3D ~((u64) RMAC_LINK_STATE_CHANGE_INT);=0A= writeq(val64, &bar0->mac_rmac_err_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable MAC Intrs in the general intr mask register =0A= + /* =0A= + * Disable MAC Intrs in the general intr mask register =0A= */=0A= writeq(DISABLE_ALL_INTRS, &bar0->mac_int_mask);=0A= writeq(DISABLE_ALL_INTRS,=0A= @@ -993,11 +1265,14 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* All XGXS block error interrupts are disabled for now=0A= - * TODO */=0A= + /* =0A= + * All XGXS block error interrupts are disabled for now=0A= + * TODO =0A= + */=0A= writeq(DISABLE_ALL_INTRS, &bar0->xgxs_int_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable MC Intrs in the general intr mask register =0A= + /* =0A= + * Disable MC Intrs in the general intr mask register =0A= */=0A= writeq(DISABLE_ALL_INTRS, &bar0->xgxs_int_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= @@ -1013,11 +1288,14 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* All MC block error interrupts are disabled for now=0A= - * TODO */=0A= + /* =0A= + * All MC block error interrupts are disabled for now=0A= + * TODO =0A= + */=0A= writeq(DISABLE_ALL_INTRS, &bar0->mc_int_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable MC Intrs in the general intr mask register=0A= + /*=0A= + * Disable MC Intrs in the general intr mask register=0A= */=0A= writeq(DISABLE_ALL_INTRS, &bar0->mc_int_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= @@ -1034,15 +1312,15 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - /* Enable all the Tx side interrupts */=0A= - writeq(0x0, &bar0->tx_traffic_mask); /* '0' Enables =0A= - * all 64 TX =0A= - * interrupt =0A= - * levels.=0A= - */=0A= + /* =0A= + * Enable all the Tx side interrupts=0A= + * writing 0 Enables all 64 TX interrupt levels =0A= + */=0A= + writeq(0x0, &bar0->tx_traffic_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable Tx Traffic Intrs in the general intr mask =0A= - * register.=0A= + /* =0A= + * Disable Tx Traffic Intrs in the general intr mask =0A= + * register.=0A= */=0A= writeq(DISABLE_ALL_INTRS, &bar0->tx_traffic_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= @@ -1058,14 +1336,12 @@=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= temp64 &=3D ~((u64) val64);=0A= writeq(temp64, &bar0->general_int_mask);=0A= - writeq(0x0, &bar0->rx_traffic_mask); /* '0' Enables =0A= - * all 8 RX =0A= - * interrupt =0A= - * levels.=0A= - */=0A= + /* writing 0 Enables all 8 RX interrupt levels */=0A= + writeq(0x0, &bar0->rx_traffic_mask);=0A= } else if (flag =3D=3D DISABLE_INTRS) {=0A= - /* Disable Rx Traffic Intrs in the general intr mask =0A= - * register.=0A= + /* =0A= + * Disable Rx Traffic Intrs in the general intr mask =0A= + * register.=0A= */=0A= writeq(DISABLE_ALL_INTRS, &bar0->rx_traffic_mask);=0A= temp64 =3D readq(&bar0->general_int_mask);=0A= @@ -1075,17 +1351,19 @@=0A= }=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * val64 - Value read from adapter status register.=0A= - * flag - indicates if the adapter enable bit was ever written once = before.=0A= - * Return Value: =0A= - * void.=0A= - * Description: =0A= - * Returns whether the H/W is ready to go or not. Depending on = whether =0A= - * adapter enable bit was written or not the comparison differs and = the =0A= - * calling function passes the input argument flag to indicate this.=0A= +/** =0A= + * verify_xena_quiescence - Checks whether the H/W is ready =0A= + * @val64 : Value read from adapter status register.=0A= + * @flag : indicates if the adapter enable bit was ever written once=0A= + * before.=0A= + * Description: Returns whether the H/W is ready to go or not. = Depending=0A= + * on whether adapter enable bit was written or not the comparison =0A= + * differs and the calling function passes the input argument flag to=0A= + * indicate this.=0A= + * Return: 1 If xena is quiescence =0A= + * 0 If Xena is not quiescence=0A= */=0A= +=0A= static int verify_xena_quiescence(u64 val64, int flag)=0A= {=0A= int ret =3D 0;=0A= @@ -1122,11 +1400,15 @@=0A= return ret;=0A= }=0A= =0A= -/* =0A= +/**=0A= + * fix_mac_address - Fix for Mac addr problem on Alpha platforms=0A= + * @sp: Pointer to device specifc structure=0A= + * Description : =0A= * New procedure to clear mac address reading problems on Alpha = platforms=0A= *=0A= */=0A= -void FixMacAddress(nic_t * sp)=0A= +=0A= +void fix_mac_address(nic_t * sp)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= u64 val64;=0A= @@ -1138,19 +1420,20 @@=0A= }=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * device private variable.=0A= - * Return Value: =0A= - * SUCCESS on success and -1 on failure.=0A= +/**=0A= + * start_nic - Turns the device on =0A= + * @nic : device private variable.=0A= * Description: =0A= - * This function actually turns the device on. Before this =0A= - * function is called, all Registers are configured from their reset = states =0A= + * This function actually turns the device on. Before this function = is =0A= + * called,all Registers are configured from their reset states =0A= * and shared memory is allocated but the NIC is still quiescent. On =0A= * calling this function, the device interrupts are cleared and the = NIC is=0A= * literally switched on by writing into the adapter control register.=0A= + * Return Value: =0A= + * SUCCESS on success and -1 on failure.=0A= */=0A= -static int startNic(struct s2io_nic *nic)=0A= +=0A= +static int start_nic(struct s2io_nic *nic)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= struct net_device *dev =3D nic->dev;=0A= @@ -1169,17 +1452,29 @@=0A= &bar0->prc_rxd0_n[i]);=0A= =0A= val64 =3D readq(&bar0->prc_ctrl_n[i]);=0A= +#ifndef CONFIG_2BUFF_MODE=0A= val64 |=3D PRC_CTRL_RC_ENABLED;=0A= +#else=0A= + val64 |=3D PRC_CTRL_RC_ENABLED | PRC_CTRL_RING_MODE_3;=0A= +#endif=0A= writeq(val64, &bar0->prc_ctrl_n[i]);=0A= }=0A= =0A= - /* Enabling MC-RLDRAM. After enabling the device, we timeout=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + /* Enabling 2 buffer mode by writing into Rx_pa_cfg reg. */=0A= + val64 =3D readq(&bar0->rx_pa_cfg);=0A= + val64 |=3D RX_PA_CFG_IGNORE_L2_ERR;=0A= + writeq(val64, &bar0->rx_pa_cfg);=0A= +#endif=0A= +=0A= + /* =0A= + * Enabling MC-RLDRAM. After enabling the device, we timeout=0A= * for around 100ms, which is approximately the time required=0A= * for the device to be ready for operation.=0A= */=0A= val64 =3D readq(&bar0->mc_rldram_mrs);=0A= val64 |=3D MC_RLDRAM_QUEUE_SIZE_ENABLE | MC_RLDRAM_MRS_ENABLE;=0A= - writeq(val64, &bar0->mc_rldram_mrs);=0A= + SPECIAL_REG_WRITE(val64, &bar0->mc_rldram_mrs, UF);=0A= val64 =3D readq(&bar0->mc_rldram_mrs);=0A= =0A= set_current_state(TASK_UNINTERRUPTIBLE);=0A= @@ -1190,14 +1485,16 @@=0A= val64 &=3D ~ADAPTER_ECC_EN;=0A= writeq(val64, &bar0->adapter_control);=0A= =0A= - /* Clearing any possible Link state change interrupts that =0A= + /* =0A= + * Clearing any possible Link state change interrupts that =0A= * could have popped up just before Enabling the card.=0A= */=0A= val64 =3D readq(&bar0->mac_rmac_err_reg);=0A= if (val64)=0A= writeq(val64, &bar0->mac_rmac_err_reg);=0A= =0A= - /* Verify if the device is ready to be enabled, if so enable =0A= + /* =0A= + * Verify if the device is ready to be enabled, if so enable =0A= * it.=0A= */=0A= val64 =3D readq(&bar0->adapter_status);=0A= @@ -1211,9 +1508,10 @@=0A= /* Enable select interrupts */=0A= interruptible =3D TX_TRAFFIC_INTR | RX_TRAFFIC_INTR | TX_MAC_INTR |=0A= RX_MAC_INTR;=0A= - en_dis_able_NicIntrs(nic, interruptible, ENABLE_INTRS);=0A= + en_dis_able_nic_intrs(nic, interruptible, ENABLE_INTRS);=0A= =0A= - /* With some switches, link might be already up at this point.=0A= + /* =0A= + * With some switches, link might be already up at this point.=0A= * Because of this weird behavior, when we enable laser, =0A= * we may not get link. We need to handle this. We cannot =0A= * figure out which switch is misbehaving. So we are forced to =0A= @@ -1240,82 +1538,74 @@=0A= * force link down. Since link is already up, we will get=0A= * link state change interrupt after this reset=0A= */=0A= - writeq(0x8007051500000000ULL, &bar0->dtx_control);=0A= + SPECIAL_REG_WRITE(0x80010515001E0000ULL, &bar0->dtx_control, UF);=0A= val64 =3D readq(&bar0->dtx_control);=0A= - writeq(0x80070515000000E0ULL, &bar0->dtx_control);=0A= + udelay(50);=0A= + SPECIAL_REG_WRITE(0x80010515001E00E0ULL, &bar0->dtx_control, UF);=0A= val64 =3D readq(&bar0->dtx_control);=0A= - writeq(0x80070515001F00E4ULL, &bar0->dtx_control);=0A= + udelay(50);=0A= + SPECIAL_REG_WRITE(0x80070515001F00E4ULL, &bar0->dtx_control, UF);=0A= val64 =3D readq(&bar0->dtx_control);=0A= + udelay(50);=0A= =0A= return SUCCESS;=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * nic - device private variable.=0A= - * Return Value: =0A= - * void.=0A= +/** =0A= + * free_tx_buffers - Free all queued Tx buffers =0A= + * @nic : device private variable.=0A= * Description: =0A= - * Free all queued Tx buffers.=0A= - */=0A= -void freeTxBuffers(struct s2io_nic *nic)=0A= + * Free all queued Tx buffers.=0A= + * Return Value: void =0A= +*/=0A= +=0A= +void free_tx_buffers(struct s2io_nic *nic)=0A= {=0A= struct net_device *dev =3D nic->dev;=0A= struct sk_buff *skb;=0A= TxD_t *txdp;=0A= int i, j;=0A= -#if DEBUG_ON=0A= - int cnt =3D 0;=0A= -#endif=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= + int cnt =3D 0;=0A= =0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= =0A= for (i =3D 0; i < config->TxFIFONum; i++) {=0A= - for (j =3D 0; j < config->TxCfg[i].FifoLen - 1; j++) {=0A= - txdp =3D mac_control->txdl_start[i] +=0A= - (config->MaxTxDs * j);=0A= -=0A= - if (!(txdp->Control_1 & TXD_LIST_OWN_XENA)) {=0A= - /* If owned by host, ignore */=0A= - continue;=0A= - }=0A= + for (j =3D 0; j < config->tx_cfg[i].FifoLen - 1; j++) {=0A= + txdp =3D (TxD_t *) nic->list_info[i][j].=0A= + list_virt_addr;=0A= skb =3D=0A= (struct sk_buff *) ((unsigned long) txdp->=0A= Host_Control);=0A= if (skb =3D=3D NULL) {=0A= - DBG_PRINT(ERR_DBG, "%s: NULL skb ",=0A= - dev->name);=0A= - DBG_PRINT(ERR_DBG, "in Tx Int\n");=0A= - return;=0A= + memset(txdp, 0, sizeof(TxD_t));=0A= + continue;=0A= }=0A= -#if DEBUG_ON=0A= - cnt++;=0A= -#endif=0A= dev_kfree_skb(skb);=0A= memset(txdp, 0, sizeof(TxD_t));=0A= + cnt++;=0A= }=0A= -#if DEBUG_ON=0A= DBG_PRINT(INTR_DBG,=0A= "%s:forcibly freeing %d skbs on FIFO%d\n",=0A= dev->name, cnt, i);=0A= -#endif=0A= + mac_control->tx_curr_get_info[i].offset =3D 0;=0A= + mac_control->tx_curr_put_info[i].offset =3D 0;=0A= }=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * nic - device private variable.=0A= - * Return Value: =0A= +/** =0A= + * stop_nic - To stop the nic =0A= + * @nic ; device private variable.=0A= + * Description: =0A= + * This function does exactly the opposite of what the start_nic() =0A= + * function does. This function is called to stop the device.=0A= + * Return Value:=0A= * void.=0A= - * Description: =0A= - * This function does exactly the opposite of what the startNic() =0A= - * function does. This function is called to stop =0A= - * the device.=0A= */=0A= -static void stopNic(struct s2io_nic *nic)=0A= +=0A= +static void stop_nic(struct s2io_nic *nic)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= register u64 val64 =3D 0;=0A= @@ -1326,12 +1616,12 @@=0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= =0A= -/* Disable all interrupts */=0A= + /* Disable all interrupts */=0A= interruptible =3D TX_TRAFFIC_INTR | RX_TRAFFIC_INTR | TX_MAC_INTR |=0A= RX_MAC_INTR;=0A= - en_dis_able_NicIntrs(nic, interruptible, DISABLE_INTRS);=0A= + en_dis_able_nic_intrs(nic, interruptible, DISABLE_INTRS);=0A= =0A= -/* Disable PRCs */=0A= + /* Disable PRCs */=0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= val64 =3D readq(&bar0->prc_ctrl_n[i]);=0A= val64 &=3D ~((u64) PRC_CTRL_RC_ENABLED);=0A= @@ -1339,11 +1629,10 @@=0A= }=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * device private variable=0A= - * Return Value: =0A= - * SUCCESS on success or an appropriate -ve value on failure.=0A= +/** =0A= + * fill_rx_buffers - Allocates the Rx side skbs =0A= + * @nic: device private variable=0A= + * @ring_no: ring number =0A= * Description: =0A= * The function allocates Rx side skbs and puts the physical=0A= * address of these buffers into the RxD buffer pointers, so that the = NIC=0A= @@ -1354,9 +1643,13 @@=0A= * 3. Five buffer modes.=0A= * Each mode defines how many fragments the received frame will be = split =0A= * up into by the NIC. The frame is split into L3 header, L4 Header, =0A= - * L4 payload in three buffer mode and in 5 buffer mode, L4 payload = itself =0A= - * is split into 3 fragments. As of now only single buffer mode is = supported.=0A= + * L4 payload in three buffer mode and in 5 buffer mode, L4 payload = itself=0A= + * is split into 3 fragments. As of now only single buffer mode is=0A= + * supported.=0A= + * Return Value:=0A= + * SUCCESS on success or an appropriate -ve value on failure.=0A= */=0A= +=0A= int fill_rx_buffers(struct s2io_nic *nic, int ring_no)=0A= {=0A= struct net_device *dev =3D nic->dev;=0A= @@ -1369,6 +1662,16 @@=0A= atomic_read(&nic->rx_bufs_left[ring_no]);=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + RxD_t *rxdpnext;=0A= + int nextblk;=0A= + u64 tmp;=0A= + buffAdd_t *ba;=0A= + dma_addr_t rxdpphys;=0A= +#endif=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + unsigned long flags;=0A= +#endif=0A= =0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= @@ -1390,8 +1693,13 @@=0A= block_index;=0A= off =3D mac_control->rx_curr_put_info[ring_no].offset;=0A= off1 =3D mac_control->rx_curr_get_info[ring_no].offset;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= offset =3D block_no * (MAX_RXDS_PER_BLOCK + 1) + off;=0A= offset1 =3D block_no1 * (MAX_RXDS_PER_BLOCK + 1) + off1;=0A= +#else=0A= + offset =3D block_no * (MAX_RXDS_PER_BLOCK) + off;=0A= + offset1 =3D block_no1 * (MAX_RXDS_PER_BLOCK) + off1;=0A= +#endif=0A= =0A= rxdp =3D nic->rx_blocks[ring_no][block_no].=0A= block_virt_addr + off;=0A= @@ -1400,7 +1708,7 @@=0A= DBG_PRINT(INTR_DBG, " info equated\n");=0A= goto end;=0A= }=0A= -=0A= +#ifndef CONFIG_2BUFF_MODE=0A= if (rxdp->Control_1 =3D=3D END_OF_BLOCK) {=0A= mac_control->rx_curr_put_info[ring_no].=0A= block_index++;=0A= @@ -1412,25 +1720,85 @@=0A= off %=3D (MAX_RXDS_PER_BLOCK + 1);=0A= mac_control->rx_curr_put_info[ring_no].offset =3D=0A= off;=0A= - /*rxdp =3D nic->rx_blocks[ring_no][block_no].=0A= - block_virt_addr + off; */=0A= rxdp =3D (RxD_t *) ((unsigned long) rxdp->Control_2);=0A= DBG_PRINT(INTR_DBG, "%s: Next block at: %p\n",=0A= dev->name, rxdp);=0A= }=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock_irqsave(&nic->put_lock, flags);=0A= + nic->put_pos =3D (block_no * (MAX_RXDS_PER_BLOCK + 1)) + off;=0A= + spin_unlock_irqrestore(&nic->put_lock, flags);=0A= +#endif=0A= +#else=0A= + if (rxdp->Host_Control =3D=3D END_OF_BLOCK) {=0A= + mac_control->rx_curr_put_info[ring_no].=0A= + block_index++;=0A= + mac_control->rx_curr_put_info[ring_no].=0A= + block_index %=3D nic->block_count[ring_no];=0A= + block_no =3D mac_control->rx_curr_put_info=0A= + [ring_no].block_index;=0A= + off =3D 0;=0A= + DBG_PRINT(INTR_DBG, "%s: block%d at: 0x%llx\n",=0A= + dev->name, block_no,=0A= + (unsigned long long) rxdp->Control_1);=0A= + mac_control->rx_curr_put_info[ring_no].offset =3D=0A= + off;=0A= + rxdp =3D nic->rx_blocks[ring_no][block_no].=0A= + block_virt_addr;=0A= + }=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock_irqsave(&nic->put_lock, flags);=0A= + nic->put_pos =3D (block_no * (MAX_RXDS_PER_BLOCK + 1)) + off;=0A= + spin_unlock_irqrestore(&nic->put_lock, flags);=0A= +#endif=0A= +#endif=0A= =0A= - if (rxdp->Control_1 & RXD_OWN_XENA) {=0A= +#ifndef CONFIG_2BUFF_MODE=0A= + if (rxdp->Control_1 & RXD_OWN_XENA)=0A= +#else=0A= + if (rxdp->Control_2 & BIT(0))=0A= +#endif=0A= + {=0A= mac_control->rx_curr_put_info[ring_no].=0A= offset =3D off;=0A= goto end;=0A= }=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + /* =0A= + * RxDs Spanning cache lines will be replenished only =0A= + * if the succeeding RxD is also owned by Host. It =0A= + * will always be the ((8*i)+3) and ((8*i)+6) =0A= + * descriptors for the 48 byte descriptor. The offending =0A= + * decsriptor is of-course the 3rd descriptor.=0A= + */=0A= + rxdpphys =3D nic->rx_blocks[ring_no][block_no].=0A= + block_dma_addr + (off * sizeof(RxD_t));=0A= + if (((u64) (rxdpphys)) % 128 > 80) {=0A= + rxdpnext =3D nic->rx_blocks[ring_no][block_no].=0A= + block_virt_addr + (off + 1);=0A= + if (rxdpnext->Host_Control =3D=3D END_OF_BLOCK) {=0A= + nextblk =3D (block_no + 1) %=0A= + (nic->block_count[ring_no]);=0A= + rxdpnext =3D nic->rx_blocks[ring_no]=0A= + [nextblk].block_virt_addr;=0A= + }=0A= + if (rxdpnext->Control_2 & BIT(0))=0A= + goto end;=0A= + }=0A= +#endif=0A= =0A= +#ifndef CONFIG_2BUFF_MODE=0A= skb =3D dev_alloc_skb(size + HEADER_ALIGN_LAYER_3);=0A= +#else=0A= + skb =3D dev_alloc_skb(dev->mtu + ALIGN_SIZE +=0A= + /*BUF0_LEN + */ 22);=0A= +#endif=0A= if (!skb) {=0A= DBG_PRINT(ERR_DBG, "%s: Out of ", dev->name);=0A= DBG_PRINT(ERR_DBG, "memory to allocate SKBs\n");=0A= return -ENOMEM;=0A= }=0A= +#ifndef CONFIG_2BUFF_MODE=0A= skb_reserve(skb, HEADER_ALIGN_LAYER_3);=0A= memset(rxdp, 0, sizeof(RxD_t));=0A= rxdp->Buffer0_ptr =3D pci_map_single=0A= @@ -1442,6 +1810,33 @@=0A= off++;=0A= off %=3D (MAX_RXDS_PER_BLOCK + 1);=0A= mac_control->rx_curr_put_info[ring_no].offset =3D off;=0A= +#else=0A= + ba =3D &nic->ba[ring_no][block_no][off];=0A= + tmp =3D (u64) skb->data;=0A= + tmp +=3D ALIGN_SIZE;=0A= + tmp &=3D ~ALIGN_SIZE;=0A= + skb->data =3D (void *) tmp;=0A= +=0A= + memset(rxdp, 0, sizeof(RxD_t));=0A= + rxdp->Buffer2_ptr =3D pci_map_single=0A= + (nic->pdev, skb->data, dev->mtu + 22,=0A= + PCI_DMA_FROMDEVICE);=0A= + rxdp->Buffer0_ptr =3D=0A= + pci_map_single(nic->pdev, ba->ba_0, BUF0_LEN,=0A= + PCI_DMA_FROMDEVICE);=0A= + rxdp->Buffer1_ptr =3D=0A= + pci_map_single(nic->pdev, ba->ba_1, BUF1_LEN,=0A= + PCI_DMA_FROMDEVICE);=0A= +=0A= + rxdp->Control_2 =3D SET_BUFFER2_SIZE(dev->mtu + 22);=0A= + rxdp->Control_2 |=3D SET_BUFFER0_SIZE(BUF0_LEN);=0A= + rxdp->Control_2 |=3D SET_BUFFER1_SIZE(1); /* dummy. */=0A= + rxdp->Control_2 |=3D BIT(0); /* Set Buffer_Empty bit. */=0A= + rxdp->Host_Control =3D (u64) ((unsigned long) (skb));=0A= + rxdp->Control_1 |=3D RXD_OWN_XENA;=0A= + off++;=0A= + mac_control->rx_curr_put_info[ring_no].offset =3D off;=0A= +#endif=0A= atomic_inc(&nic->rx_bufs_left[ring_no]);=0A= alloc_tab++;=0A= }=0A= @@ -1450,15 +1845,16 @@=0A= return SUCCESS;=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * device private variable.=0A= - * Return Value: =0A= - * NONE.=0A= +/**=0A= + * free_rx_buffers - Frees all Rx buffers =0A= + * @sp: device private variable.=0A= * Description: =0A= * This function will free all Rx buffers allocated by host.=0A= + * Return Value:=0A= + * NONE.=0A= */=0A= -static void freeRxBuffers(struct s2io_nic *sp)=0A= +=0A= +static void free_rx_buffers(struct s2io_nic *sp)=0A= {=0A= struct net_device *dev =3D sp->dev;=0A= int i, j, blk =3D 0, off, buf_cnt =3D 0;=0A= @@ -1466,15 +1862,19 @@=0A= struct sk_buff *skb;=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + buffAdd_t *ba;=0A= +#endif=0A= =0A= mac_control =3D &sp->mac_control;=0A= config =3D &sp->config;=0A= =0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= - for (j =3D 0, blk =3D 0; j < config->RxCfg[i].NumRxd; j++) {=0A= + for (j =3D 0, blk =3D 0; j < config->rx_cfg[i].NumRxd; j++) {=0A= off =3D j % (MAX_RXDS_PER_BLOCK + 1);=0A= rxdp =3D sp->rx_blocks[i][blk].block_virt_addr + off;=0A= =0A= +#ifndef CONFIG_2BUFF_MODE=0A= if (rxdp->Control_1 =3D=3D END_OF_BLOCK) {=0A= rxdp =3D=0A= (RxD_t *) ((unsigned long) rxdp->=0A= @@ -1482,11 +1882,23 @@=0A= j++;=0A= blk++;=0A= }=0A= +#else=0A= + if (rxdp->Host_Control =3D=3D END_OF_BLOCK) {=0A= + blk++;=0A= + continue;=0A= + }=0A= +#endif=0A= +=0A= + if (!(rxdp->Control_1 & RXD_OWN_XENA)) {=0A= + memset(rxdp, 0, sizeof(RxD_t));=0A= + continue;=0A= + }=0A= =0A= skb =3D=0A= (struct sk_buff *) ((unsigned long) rxdp->=0A= Host_Control);=0A= if (skb) {=0A= +#ifndef CONFIG_2BUFF_MODE=0A= pci_unmap_single(sp->pdev, (dma_addr_t)=0A= rxdp->Buffer0_ptr,=0A= dev->mtu +=0A= @@ -1494,6 +1906,21 @@=0A= + HEADER_802_2_SIZE +=0A= HEADER_SNAP_SIZE,=0A= PCI_DMA_FROMDEVICE);=0A= +#else=0A= + ba =3D &sp->ba[i][blk][off];=0A= + pci_unmap_single(sp->pdev, (dma_addr_t)=0A= + rxdp->Buffer0_ptr,=0A= + BUF0_LEN,=0A= + PCI_DMA_FROMDEVICE);=0A= + pci_unmap_single(sp->pdev, (dma_addr_t)=0A= + rxdp->Buffer1_ptr,=0A= + BUF1_LEN,=0A= + PCI_DMA_FROMDEVICE);=0A= + pci_unmap_single(sp->pdev, (dma_addr_t)=0A= + rxdp->Buffer2_ptr,=0A= + dev->mtu + 22,=0A= + PCI_DMA_FROMDEVICE);=0A= +#endif=0A= dev_kfree_skb(skb);=0A= atomic_dec(&sp->rx_bufs_left[i]);=0A= buf_cnt++;=0A= @@ -1510,18 +1937,19 @@=0A= }=0A= }=0A= =0A= -/*=0A= - * Input Argument: =0A= - * dev - pointer to the device structure.=0A= - * budget - The number of packets that were budgeted to be processed = during=0A= - * one pass through the 'Poll" function.=0A= - * Return value:=0A= - * 0 on success and 1 if there are No Rx packets to be processed.=0A= - * Description:=0A= - * Comes into picture only if NAPI support has been incorporated. It = does=0A= - * the same thing that rxIntrHandler does, but not in a interrupt = context=0A= - * also It will process only a given number of packets.=0A= +/**=0A= + * s2io_poll - Rx interrupt handler for NAPI support=0A= + * @dev : pointer to the device structure.=0A= + * @budget : The number of packets that were budgeted to be processed =0A= + * during one pass through the 'Poll" function.=0A= + * Description:=0A= + * Comes into picture only if NAPI support has been incorporated. It = does=0A= + * the same thing that rx_intr_handler does, but not in a interrupt = context=0A= + * also It will process only a given number of packets.=0A= + * Return value:=0A= + * 0 on success and 1 if there are No Rx packets to be processed.=0A= */=0A= +=0A= #ifdef CONFIG_S2IO_NAPI=0A= static int s2io_poll(struct net_device *dev, int *budget)=0A= {=0A= @@ -1529,13 +1957,18 @@=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= int pkts_to_process =3D *budget, pkt_cnt =3D 0;=0A= register u64 val64 =3D 0;=0A= - rx_curr_get_info_t offset_info;=0A= - int i, block_no;=0A= + rx_curr_get_info_t get_info, put_info;=0A= + int i, get_block, put_block, get_offset, put_offset, ring_bufs;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= u16 val16, cksum;=0A= +#endif=0A= struct sk_buff *skb;=0A= RxD_t *rxdp;=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + buffAdd_t *ba;=0A= +#endif=0A= =0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= @@ -1547,29 +1980,47 @@=0A= writeq(val64, &bar0->rx_traffic_int);=0A= =0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= - if (--pkts_to_process < 0) {=0A= - goto no_rx;=0A= - }=0A= - offset_info =3D mac_control->rx_curr_get_info[i];=0A= - block_no =3D offset_info.block_index;=0A= - rxdp =3D nic->rx_blocks[i][block_no].block_virt_addr +=0A= - offset_info.offset;=0A= - while (!(rxdp->Control_1 & RXD_OWN_XENA)) {=0A= + get_info =3D mac_control->rx_curr_get_info[i];=0A= + get_block =3D get_info.block_index;=0A= + put_info =3D mac_control->rx_curr_put_info[i];=0A= + put_block =3D put_info.block_index;=0A= + ring_bufs =3D config->rx_cfg[i].NumRxd;=0A= + rxdp =3D nic->rx_blocks[i][get_block].block_virt_addr +=0A= + get_info.offset;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= + get_offset =3D (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock(&nic->put_lock);=0A= + put_offset =3D nic->put_pos;=0A= + spin_unlock(&nic->put_lock);=0A= +#else=0A= + put_offset =3D (put_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + put_info.offset;=0A= +#endif=0A= + while ((!(rxdp->Control_1 & RXD_OWN_XENA)) &&=0A= + (((get_offset + 1) % ring_bufs) !=3D put_offset)) {=0A= + if (--pkts_to_process < 0) {=0A= + goto no_rx;=0A= + }=0A= if (rxdp->Control_1 =3D=3D END_OF_BLOCK) {=0A= rxdp =3D=0A= (RxD_t *) ((unsigned long) rxdp->=0A= Control_2);=0A= - offset_info.offset++;=0A= - offset_info.offset %=3D=0A= + get_info.offset++;=0A= + get_info.offset %=3D=0A= (MAX_RXDS_PER_BLOCK + 1);=0A= - block_no++;=0A= - block_no %=3D nic->block_count[i];=0A= + get_block++;=0A= + get_block %=3D nic->block_count[i];=0A= mac_control->rx_curr_get_info[i].=0A= - offset =3D offset_info.offset;=0A= + offset =3D get_info.offset;=0A= mac_control->rx_curr_get_info[i].=0A= - block_index =3D block_no;=0A= + block_index =3D get_block;=0A= continue;=0A= }=0A= + get_offset =3D=0A= + (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= skb =3D=0A= (struct sk_buff *) ((unsigned long) rxdp->=0A= Host_Control);=0A= @@ -1577,7 +2028,7 @@=0A= DBG_PRINT(ERR_DBG, "%s: The skb is ",=0A= dev->name);=0A= DBG_PRINT(ERR_DBG, "Null in Rx Intr\n");=0A= - return 0;=0A= + goto no_rx;=0A= }=0A= val64 =3D RXD_GET_BUFFER0_SIZE(rxdp->Control_2);=0A= val16 =3D (u16) (val64 >> 48);=0A= @@ -1589,97 +2040,192 @@=0A= HEADER_802_2_SIZE +=0A= HEADER_SNAP_SIZE,=0A= PCI_DMA_FROMDEVICE);=0A= - rxOsmHandler(nic, val16, rxdp, i);=0A= + rx_osm_handler(nic, val16, rxdp, i);=0A= pkt_cnt++;=0A= - offset_info.offset++;=0A= - offset_info.offset %=3D (MAX_RXDS_PER_BLOCK + 1);=0A= + get_info.offset++;=0A= + get_info.offset %=3D (MAX_RXDS_PER_BLOCK + 1);=0A= rxdp =3D=0A= - nic->rx_blocks[i][block_no].block_virt_addr +=0A= - offset_info.offset;=0A= + nic->rx_blocks[i][get_block].block_virt_addr +=0A= + get_info.offset;=0A= mac_control->rx_curr_get_info[i].offset =3D=0A= - offset_info.offset;=0A= + get_info.offset;=0A= }=0A= - }=0A= - if (!pkt_cnt)=0A= - pkt_cnt =3D 1;=0A= -=0A= - for (i =3D 0; i < config->RxRingNum; i++)=0A= - fill_rx_buffers(nic, i);=0A= +#else=0A= + get_offset =3D (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock(&nic->put_lock);=0A= + put_offset =3D nic->put_pos;=0A= + spin_unlock(&nic->put_lock);=0A= +#else=0A= + put_offset =3D (put_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + put_info.offset;=0A= +#endif=0A= + while (((!(rxdp->Control_1 & RXD_OWN_XENA)) &&=0A= + !(rxdp->Control_2 & BIT(0))) &&=0A= + (((get_offset + 1) % ring_bufs) !=3D put_offset)) {=0A= + if (--pkts_to_process < 0) {=0A= + goto no_rx;=0A= + }=0A= + skb =3D (struct sk_buff *) ((unsigned long)=0A= + rxdp->Host_Control);=0A= + if (skb =3D=3D NULL) {=0A= + DBG_PRINT(ERR_DBG, "%s: The skb is ",=0A= + dev->name);=0A= + DBG_PRINT(ERR_DBG, "Null in Rx Intr\n");=0A= + goto no_rx;=0A= + }=0A= +=0A= + pci_unmap_single(nic->pdev, (dma_addr_t)=0A= + rxdp->Buffer0_ptr,=0A= + BUF0_LEN, PCI_DMA_FROMDEVICE);=0A= + pci_unmap_single(nic->pdev, (dma_addr_t)=0A= + rxdp->Buffer1_ptr,=0A= + BUF1_LEN, PCI_DMA_FROMDEVICE);=0A= + pci_unmap_single(nic->pdev, (dma_addr_t)=0A= + rxdp->Buffer2_ptr,=0A= + dev->mtu + 22,=0A= + PCI_DMA_FROMDEVICE);=0A= + ba =3D &nic->ba[i][get_block][get_info.offset];=0A= +=0A= + rx_osm_handler(nic, rxdp, i, ba);=0A= +=0A= + get_info.offset++;=0A= + mac_control->rx_curr_get_info[i].offset =3D=0A= + get_info.offset;=0A= + rxdp =3D=0A= + nic->rx_blocks[i][get_block].block_virt_addr +=0A= + get_info.offset;=0A= +=0A= + if (get_info.offset &&=0A= + (!(get_info.offset % MAX_RXDS_PER_BLOCK))) {=0A= + get_info.offset =3D 0;=0A= + mac_control->rx_curr_get_info[i].=0A= + offset =3D get_info.offset;=0A= + get_block++;=0A= + get_block %=3D nic->block_count[i];=0A= + mac_control->rx_curr_get_info[i].=0A= + block_index =3D get_block;=0A= + rxdp =3D=0A= + nic->rx_blocks[i][get_block].=0A= + block_virt_addr;=0A= + }=0A= + get_offset =3D=0A= + (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= + pkt_cnt++;=0A= + }=0A= +#endif=0A= + }=0A= + if (!pkt_cnt)=0A= + pkt_cnt =3D 1;=0A= =0A= dev->quota -=3D pkt_cnt;=0A= *budget -=3D pkt_cnt;=0A= netif_rx_complete(dev);=0A= =0A= -/* Re enable the Rx interrupts. */=0A= - en_dis_able_NicIntrs(nic, RX_TRAFFIC_INTR, ENABLE_INTRS);=0A= + for (i =3D 0; i < config->RxRingNum; i++) {=0A= + if (fill_rx_buffers(nic, i) =3D=3D -ENOMEM) {=0A= + DBG_PRINT(ERR_DBG, "%s:Out of memory", dev->name);=0A= + DBG_PRINT(ERR_DBG, " in Rx Poll!!\n");=0A= + break;=0A= + }=0A= + }=0A= + /* Re enable the Rx interrupts. */=0A= + en_dis_able_nic_intrs(nic, RX_TRAFFIC_INTR, ENABLE_INTRS);=0A= return 0;=0A= =0A= no_rx:=0A= - for (i =3D 0; i < config->RxRingNum; i++)=0A= - fill_rx_buffers(nic, i);=0A= dev->quota -=3D pkt_cnt;=0A= *budget -=3D pkt_cnt;=0A= +=0A= + for (i =3D 0; i < config->RxRingNum; i++) {=0A= + if (fill_rx_buffers(nic, i) =3D=3D -ENOMEM) {=0A= + DBG_PRINT(ERR_DBG, "%s:Out of memory", dev->name);=0A= + DBG_PRINT(ERR_DBG, " in Rx Poll!!\n");=0A= + break;=0A= + }=0A= + }=0A= return 1;=0A= }=0A= #else=0A= -/* =0A= - * Input Arguments: =0A= - * device private variable.=0A= - * Return Value: =0A= - * NONE.=0A= +/** =0A= + * rx_intr_handler - Rx interrupt handler=0A= + * @nic: device private variable.=0A= * Description: =0A= - * If the interrupt is because of a received frame or if the =0A= - * receive ring contains fresh as yet un-processed frames, this = function is=0A= + * If the interrupt is because of a received frame or if the =0A= + * receive ring contains fresh as yet un-processed frames,this = function is=0A= * called. It picks out the RxD at which place the last Rx processing = had =0A= * stopped and sends the skb to the OSM's Rx handler and then = increments =0A= * the offset.=0A= + * Return Value:=0A= + * NONE.=0A= */=0A= -static void rxIntrHandler(struct s2io_nic *nic)=0A= +=0A= +static void rx_intr_handler(struct s2io_nic *nic)=0A= {=0A= struct net_device *dev =3D (struct net_device *) nic->dev;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= - rx_curr_get_info_t offset_info;=0A= + rx_curr_get_info_t get_info, put_info;=0A= RxD_t *rxdp;=0A= struct sk_buff *skb;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= u16 val16, cksum;=0A= +#endif=0A= register u64 val64 =3D 0;=0A= - int i, block_no;=0A= + int get_block, get_offset, put_block, put_offset, ring_bufs;=0A= + int i, pkt_cnt =3D 0;=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + buffAdd_t *ba;=0A= +#endif=0A= =0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= =0A= -#if DEBUG_ON=0A= - nic->rxint_cnt++;=0A= -#endif=0A= -=0A= -/* rx_traffic_int reg is an R1 register, hence we read and write back =0A= - * the samevalue in the register to clear it.=0A= - */=0A= + /* =0A= + * rx_traffic_int reg is an R1 register, hence we read and write back =0A= + * the samevalue in the register to clear it.=0A= + */=0A= val64 =3D readq(&bar0->rx_traffic_int);=0A= writeq(val64, &bar0->rx_traffic_int);=0A= =0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= - offset_info =3D mac_control->rx_curr_get_info[i];=0A= - block_no =3D offset_info.block_index;=0A= - rxdp =3D nic->rx_blocks[i][block_no].block_virt_addr +=0A= - offset_info.offset;=0A= - while (!(rxdp->Control_1 & RXD_OWN_XENA)) {=0A= + get_info =3D mac_control->rx_curr_get_info[i];=0A= + get_block =3D get_info.block_index;=0A= + put_info =3D mac_control->rx_curr_put_info[i];=0A= + put_block =3D put_info.block_index;=0A= + ring_bufs =3D config->rx_cfg[i].NumRxd;=0A= + rxdp =3D nic->rx_blocks[i][get_block].block_virt_addr +=0A= + get_info.offset;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= + get_offset =3D (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock(&nic->put_lock);=0A= + put_offset =3D nic->put_pos;=0A= + spin_unlock(&nic->put_lock);=0A= +#endif=0A= + while ((!(rxdp->Control_1 & RXD_OWN_XENA)) &&=0A= + (((get_offset + 1) % ring_bufs) !=3D put_offset)) {=0A= if (rxdp->Control_1 =3D=3D END_OF_BLOCK) {=0A= rxdp =3D (RxD_t *) ((unsigned long)=0A= rxdp->Control_2);=0A= - offset_info.offset++;=0A= - offset_info.offset %=3D=0A= + get_info.offset++;=0A= + get_info.offset %=3D=0A= (MAX_RXDS_PER_BLOCK + 1);=0A= - block_no++;=0A= - block_no %=3D nic->block_count[i];=0A= + get_block++;=0A= + get_block %=3D nic->block_count[i];=0A= mac_control->rx_curr_get_info[i].=0A= - offset =3D offset_info.offset;=0A= + offset =3D get_info.offset;=0A= mac_control->rx_curr_get_info[i].=0A= - block_index =3D block_no;=0A= + block_index =3D get_block;=0A= continue;=0A= }=0A= + get_offset =3D=0A= + (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= skb =3D (struct sk_buff *) ((unsigned long)=0A= rxdp->Host_Control);=0A= if (skb =3D=3D NULL) {=0A= @@ -1698,35 +2244,104 @@=0A= HEADER_802_2_SIZE +=0A= HEADER_SNAP_SIZE,=0A= PCI_DMA_FROMDEVICE);=0A= - rxOsmHandler(nic, val16, rxdp, i);=0A= - offset_info.offset++;=0A= - offset_info.offset %=3D (MAX_RXDS_PER_BLOCK + 1);=0A= + rx_osm_handler(nic, val16, rxdp, i);=0A= + get_info.offset++;=0A= + get_info.offset %=3D (MAX_RXDS_PER_BLOCK + 1);=0A= rxdp =3D=0A= - nic->rx_blocks[i][block_no].block_virt_addr +=0A= - offset_info.offset;=0A= + nic->rx_blocks[i][get_block].block_virt_addr +=0A= + get_info.offset;=0A= + mac_control->rx_curr_get_info[i].offset =3D=0A= + get_info.offset;=0A= + pkt_cnt++;=0A= + if ((indicate_max_pkts)=0A= + && (pkt_cnt > indicate_max_pkts))=0A= + break;=0A= + }=0A= +#else=0A= + get_offset =3D (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock(&nic->put_lock);=0A= + put_offset =3D nic->put_pos;=0A= + spin_unlock(&nic->put_lock);=0A= +#endif=0A= + while (((!(rxdp->Control_1 & RXD_OWN_XENA)) &&=0A= + !(rxdp->Control_2 & BIT(0))) &&=0A= + (((get_offset + 1) % ring_bufs) !=3D put_offset)) {=0A= + skb =3D (struct sk_buff *) ((unsigned long)=0A= + rxdp->Host_Control);=0A= + if (skb =3D=3D NULL) {=0A= + DBG_PRINT(ERR_DBG, "%s: The skb is ",=0A= + dev->name);=0A= + DBG_PRINT(ERR_DBG, "Null in Rx Intr\n");=0A= + return;=0A= + }=0A= +=0A= + pci_unmap_single(nic->pdev, (dma_addr_t)=0A= + rxdp->Buffer0_ptr,=0A= + BUF0_LEN, PCI_DMA_FROMDEVICE);=0A= + pci_unmap_single(nic->pdev, (dma_addr_t)=0A= + rxdp->Buffer1_ptr,=0A= + BUF1_LEN, PCI_DMA_FROMDEVICE);=0A= + pci_unmap_single(nic->pdev, (dma_addr_t)=0A= + rxdp->Buffer2_ptr,=0A= + dev->mtu + 22,=0A= + PCI_DMA_FROMDEVICE);=0A= + ba =3D &nic->ba[i][get_block][get_info.offset];=0A= +=0A= + rx_osm_handler(nic, rxdp, i, ba);=0A= +=0A= + get_info.offset++;=0A= mac_control->rx_curr_get_info[i].offset =3D=0A= - offset_info.offset;=0A= + get_info.offset;=0A= + rxdp =3D=0A= + nic->rx_blocks[i][get_block].block_virt_addr +=0A= + get_info.offset;=0A= +=0A= + if (get_info.offset &&=0A= + (!(get_info.offset % MAX_RXDS_PER_BLOCK))) {=0A= + get_info.offset =3D 0;=0A= + mac_control->rx_curr_get_info[i].=0A= + offset =3D get_info.offset;=0A= + get_block++;=0A= + get_block %=3D nic->block_count[i];=0A= + mac_control->rx_curr_get_info[i].=0A= + block_index =3D get_block;=0A= + rxdp =3D=0A= + nic->rx_blocks[i][get_block].=0A= + block_virt_addr;=0A= + }=0A= + get_offset =3D=0A= + (get_block * (MAX_RXDS_PER_BLOCK + 1)) +=0A= + get_info.offset;=0A= + pkt_cnt++;=0A= + if ((indicate_max_pkts)=0A= + && (pkt_cnt > indicate_max_pkts))=0A= + break;=0A= }=0A= +#endif=0A= + if ((indicate_max_pkts) && (pkt_cnt > indicate_max_pkts))=0A= + break;=0A= }=0A= }=0A= #endif=0A= -=0A= -/* =0A= - * Input Arguments: =0A= - * device private variable=0A= - * Return Value: =0A= - * NONE=0A= +/** =0A= + * tx_intr_handler - Transmit interrupt handler=0A= + * @nic : device private variable=0A= * Description: =0A= * If an interrupt was raised to indicate DMA complete of the =0A= - * Tx packet, this function is called. It identifies the last TxD = whose buffer=0A= - * was freed and frees all skbs whose data have already DMA'ed into = the NICs=0A= - * internal memory.=0A= + * Tx packet, this function is called. It identifies the last TxD =0A= + * whose buffer was freed and frees all skbs whose data have already =0A= + * DMA'ed into the NICs internal memory.=0A= + * Return Value:=0A= + * NONE=0A= */=0A= -static void txIntrHandler(struct s2io_nic *nic)=0A= +=0A= +static void tx_intr_handler(struct s2io_nic *nic)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= struct net_device *dev =3D (struct net_device *) nic->dev;=0A= - tx_curr_get_info_t offset_info, offset_info1;=0A= + tx_curr_get_info_t get_info, put_info;=0A= struct sk_buff *skb;=0A= TxD_t *txdlp;=0A= register u64 val64 =3D 0;=0A= @@ -1734,27 +2349,24 @@=0A= u16 j, frg_cnt;=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= -#if DEBUG_ON=0A= - int cnt =3D 0;=0A= - nic->txint_cnt++;=0A= -#endif=0A= =0A= mac_control =3D &nic->mac_control;=0A= config =3D &nic->config;=0A= =0A= - /* tx_traffic_int reg is an R1 register, hence we read and write =0A= + /* =0A= + * tx_traffic_int reg is an R1 register, hence we read and write =0A= * back the samevalue in the register to clear it.=0A= */=0A= val64 =3D readq(&bar0->tx_traffic_int);=0A= writeq(val64, &bar0->tx_traffic_int);=0A= =0A= for (i =3D 0; i < config->TxFIFONum; i++) {=0A= - offset_info =3D mac_control->tx_curr_get_info[i];=0A= - offset_info1 =3D mac_control->tx_curr_put_info[i];=0A= - txdlp =3D mac_control->txdl_start[i] +=0A= - (config->MaxTxDs * offset_info.offset);=0A= + get_info =3D mac_control->tx_curr_get_info[i];=0A= + put_info =3D mac_control->tx_curr_put_info[i];=0A= + txdlp =3D (TxD_t *) nic->list_info[i][get_info.offset].=0A= + list_virt_addr;=0A= while ((!(txdlp->Control_1 & TXD_LIST_OWN_XENA)) &&=0A= - (offset_info.offset !=3D offset_info1.offset) &&=0A= + (get_info.offset !=3D put_info.offset) &&=0A= (txdlp->Host_Control)) {=0A= /* Check for TxD errors */=0A= if (txdlp->Control_1 & TXD_T_CODE) {=0A= @@ -1802,23 +2414,15 @@=0A= /* Updating the statistics block */=0A= nic->stats.tx_packets++;=0A= nic->stats.tx_bytes +=3D skb->len;=0A= -#if DEBUG_ON=0A= - nic->txpkt_bytes +=3D skb->len;=0A= - cnt++;=0A= -#endif=0A= dev_kfree_skb_irq(skb);=0A= =0A= - offset_info.offset++;=0A= - offset_info.offset %=3D offset_info.fifo_len + 1;=0A= - txdlp =3D mac_control->txdl_start[i] +=0A= - (config->MaxTxDs * offset_info.offset);=0A= + get_info.offset++;=0A= + get_info.offset %=3D get_info.fifo_len + 1;=0A= + txdlp =3D (TxD_t *) nic->list_info[i]=0A= + [get_info.offset].list_virt_addr;=0A= mac_control->tx_curr_get_info[i].offset =3D=0A= - offset_info.offset;=0A= + get_info.offset;=0A= }=0A= -#if DEBUG_ON=0A= - DBG_PRINT(INTR_DBG, "%s: freed %d Tx Pkts\n", dev->name,=0A= - cnt);=0A= -#endif=0A= }=0A= =0A= spin_lock(&nic->tx_lock);=0A= @@ -1827,67 +2431,78 @@=0A= spin_unlock(&nic->tx_lock);=0A= }=0A= =0A= -/* =0A= - * Input Arguments: =0A= - * device private variable=0A= - * Return Value: =0A= +/** =0A= + * alarm_intr_handler - Alarm Interrrupt handler=0A= + * @nic: device private variable=0A= + * Description: If the interrupt was neither because of Rx packet or = Tx =0A= + * complete, this function is called. If the interrupt was to indicate=0A= + * a loss of link, the OSM link status handler is invoked for any = other =0A= + * alarm interrupt the block that raised the interrupt is displayed =0A= + * and a H/W reset is issued.=0A= + * Return Value:=0A= * NONE=0A= - * Description: =0A= - * If the interrupt was neither because of Rx packet or Tx =0A= - * complete, this function is called. If the interrupt was to indicate = a loss=0A= - * of link, the OSM link status handler is invoked for any other alarm =0A= - * interrupt the block that raised the interrupt is displayed and a = H/W reset =0A= - * is issued.=0A= - */=0A= -static void alarmIntrHandler(struct s2io_nic *nic)=0A= +*/=0A= +=0A= +static void alarm_intr_handler(struct s2io_nic *nic)=0A= {=0A= struct net_device *dev =3D (struct net_device *) nic->dev;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= register u64 val64 =3D 0, err_reg =3D 0;=0A= =0A= -=0A= /* Handling link status change error Intr */=0A= err_reg =3D readq(&bar0->mac_rmac_err_reg);=0A= + writeq(err_reg, &bar0->mac_rmac_err_reg);=0A= if (err_reg & RMAC_LINK_STATE_CHANGE_INT) {=0A= schedule_work(&nic->set_link_task);=0A= }=0A= =0A= - /* Handling SERR errors by stopping device Xmit queue and forcing =0A= - * a H/W reset.=0A= - */=0A= + /* In case of a serious error, the device will be Reset. */=0A= val64 =3D readq(&bar0->serr_source);=0A= if (val64 & SERR_SOURCE_ANY) {=0A= DBG_PRINT(ERR_DBG, "%s: Device indicates ", dev->name);=0A= DBG_PRINT(ERR_DBG, "serious error!!\n");=0A= - netif_stop_queue(dev);=0A= + schedule_work(&nic->rst_timer_task);=0A= + }=0A= +=0A= + /*=0A= + * Also as mentioned in the latest Errata sheets if the PCC_FB_ECC=0A= + * Error occurs, the adapter will be recycled by disabling the=0A= + * adapter enable bit and enabling it again after the device =0A= + * becomes Quiescent.=0A= + */=0A= + val64 =3D readq(&bar0->pcc_err_reg);=0A= + writeq(val64, &bar0->pcc_err_reg);=0A= + if (val64 & PCC_FB_ECC_DB_ERR) {=0A= + u64 ac =3D readq(&bar0->adapter_control);=0A= + ac &=3D ~(ADAPTER_CNTL_EN);=0A= + writeq(ac, &bar0->adapter_control);=0A= + ac =3D readq(&bar0->adapter_control);=0A= + schedule_work(&nic->set_link_task);=0A= }=0A= -/* Other type of interrupts are not being handled now, TODO*/=0A= +=0A= + /* Other type of interrupts are not being handled now, TODO */=0A= }=0A= =0A= -/*=0A= - * Input Argument: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= +/** =0A= + * wait_for_cmd_complete - waits for a command to complete.=0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * Description: Function that waits for a command to Write into RMAC =0A= + * ADDR DATA registers to be completed and returns either success or =0A= + * error depending on whether the command was complete or not. =0A= * Return value:=0A= * SUCCESS on success and FAILURE on failure.=0A= - * Description:=0A= - * Function that waits for a command to Write into RMAC ADDR DATA = registers =0A= - * to be completed and returns either success or error depending on = whether =0A= - * the command was complete or not. =0A= */=0A= -int waitForCmdComplete(nic_t * sp)=0A= +=0A= +int wait_for_cmd_complete(nic_t * sp)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= int ret =3D FAILURE, cnt =3D 0;=0A= u64 val64;=0A= =0A= while (TRUE) {=0A= - val64 =3D=0A= - RMAC_ADDR_CMD_MEM_RD | RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD=0A= - | RMAC_ADDR_CMD_MEM_OFFSET(0);=0A= - writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= val64 =3D readq(&bar0->rmac_addr_cmd_mem);=0A= - if (!val64) {=0A= + if (!(val64 & RMAC_ADDR_CMD_MEM_STROBE_CMD_EXECUTING)) {=0A= ret =3D SUCCESS;=0A= break;=0A= }=0A= @@ -1900,17 +2515,16 @@=0A= return ret;=0A= }=0A= =0A= -/*=0A= - * Input Argument: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= +/** =0A= + * s2io_reset - Resets the card. =0A= + * @sp : private member of the device structure.=0A= + * Description: Function to Reset the card. This function then also=0A= + * restores the previously saved PCI configuration space registers as =0A= + * the card reset also resets the Configration space.=0A= * Return value:=0A= - * void.=0A= - * Description:=0A= - * Function to Reset the card. This function then also restores the = previously=0A= - * saved PCI configuration space registers as the card reset also = resets the=0A= - * Configration space.=0A= + * void.=0A= */=0A= +=0A= void s2io_reset(nic_t * sp)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= @@ -1920,7 +2534,8 @@=0A= val64 =3D SW_RESET_ALL;=0A= writeq(val64, &bar0->sw_reset);=0A= =0A= - /* At this stage, if the PCI write is indeed completed, the =0A= + /* =0A= + * At this stage, if the PCI write is indeed completed, the =0A= * card is reset and so is the PCI Config space of the device. =0A= * So a read cannot be issued at this stage on any of the =0A= * registers to ensure the write into "sw_reset" register=0A= @@ -1928,18 +2543,16 @@=0A= * Question: Is there any system call that will explicitly force=0A= * all the write commands still pending on the bus to be pushed=0A= * through?=0A= - * As of now I'am just giving a 250ms delay and hoping that the=0A= + * As of now I'am just giving a 100ms delay and hoping that the=0A= * PCI write to sw_reset register is done by this time.=0A= */=0A= - set_current_state(TASK_UNINTERRUPTIBLE);=0A= - schedule_timeout(HZ / 4);=0A= + mdelay(100);=0A= =0A= /* Restore the PCI state saved during initializarion. */=0A= pci_restore_state(sp->pdev, sp->config_space);=0A= s2io_init_pci(sp);=0A= =0A= - set_current_state(TASK_UNINTERRUPTIBLE);=0A= - schedule_timeout(HZ / 4);=0A= + mdelay(100);=0A= =0A= /* SXE-002: Configure link and activity LED to turn it off */=0A= subid =3D sp->pdev->subsystem_device;=0A= @@ -1954,29 +2567,31 @@=0A= sp->device_enabled_once =3D FALSE;=0A= }=0A= =0A= -/*=0A= - * Input Argument: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= +/**=0A= + * s2io_set_swapper - to set the swapper controle on the card =0A= + * @sp : private member of the device structure, =0A= + * pointer to the s2io_nic structure.=0A= + * Description: Function to set the swapper control on the card =0A= + * correctly depending on the 'endianness' of the system.=0A= * Return value:=0A= * SUCCESS on success and FAILURE on failure.=0A= - * Description:=0A= - * Function to set the swapper control on the card correctly depending = on the=0A= - * 'endianness' of the system.=0A= */=0A= +=0A= int s2io_set_swapper(nic_t * sp)=0A= {=0A= struct net_device *dev =3D sp->dev;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= u64 val64;=0A= =0A= -/* Set proper endian settings and verify the same by reading the PIF =0A= - * Feed-back register.=0A= - */=0A= + /* =0A= + * Set proper endian settings and verify the same by reading=0A= + * the PIF Feed-back register.=0A= + */=0A= #ifdef __BIG_ENDIAN=0A= -/* The device by default set to a big endian format, so a big endian =0A= - * driver need not set anything.=0A= - */=0A= + /* =0A= + * The device by default set to a big endian format, so a =0A= + * big endian driver need not set anything.=0A= + */=0A= writeq(0xffffffffffffffffULL, &bar0->swapper_ctrl);=0A= val64 =3D (SWAPPER_CTRL_PIF_R_FE |=0A= SWAPPER_CTRL_PIF_R_SE |=0A= @@ -1995,9 +2610,11 @@=0A= SWAPPER_CTRL_STATS_FE | SWAPPER_CTRL_STATS_SE);=0A= writeq(val64, &bar0->swapper_ctrl);=0A= #else=0A= -/* Initially we enable all bits to make it accessible by the driver,=0A= - * then we selectively enable only those bits that we want to set.=0A= - */=0A= + /* =0A= + * Initially we enable all bits to make it accessible by the=0A= + * driver, then we selectively enable only those bits that =0A= + * we want to set.=0A= + */=0A= writeq(0xffffffffffffffffULL, &bar0->swapper_ctrl);=0A= val64 =3D (SWAPPER_CTRL_PIF_R_FE |=0A= SWAPPER_CTRL_PIF_R_SE |=0A= @@ -2021,9 +2638,10 @@=0A= writeq(val64, &bar0->swapper_ctrl);=0A= #endif=0A= =0A= -/* Verifying if endian settings are accurate by reading a feedback=0A= - * register.=0A= - */=0A= + /* =0A= + * Verifying if endian settings are accurate by reading a =0A= + * feedback register.=0A= + */=0A= val64 =3D readq(&bar0->pif_rd_swapper_fb);=0A= if (val64 !=3D 0x0123456789ABCDEFULL) {=0A= /* Endian settings are incorrect, calls for another dekko. */=0A= @@ -2041,17 +2659,18 @@=0A= * Functions defined below concern the OS part of the driver *=0A= * ********************************************************* */=0A= =0A= -/*=0A= - * Input Argument: =0A= - * dev - pointer to the device structure.=0A= - * Return value:=0A= - * '0' on success and an appropriate (-)ve integer as defined in = errno.h=0A= - * file on failure.=0A= +/** =0A= + * s2io-open - open entry point of the driver=0A= + * @dev : pointer to the device structure.=0A= * Description:=0A= * This function is the open entry point of the driver. It mainly = calls a=0A= * function to allocate Rx buffers and inserts them into the buffer=0A= * descriptors and then enables the Rx part of the NIC. =0A= + * Return value:=0A= + * 0 on success and an appropriate (-)ve integer as defined in errno.h=0A= + * file on failure.=0A= */=0A= +=0A= int s2io_open(struct net_device *dev)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= @@ -2060,18 +2679,21 @@=0A= struct config_param *config;=0A= =0A= =0A= -/* Make sure you have link off by default every time Nic is = initialized*/=0A= + /* =0A= + * Make sure you have link off by default every time =0A= + * Nic is initialized=0A= + */=0A= netif_carrier_off(dev);=0A= sp->last_link_state =3D LINK_DOWN;=0A= =0A= -/* Initialize the H/W I/O registers */=0A= - if (initNic(sp) !=3D 0) {=0A= + /* Initialize the H/W I/O registers */=0A= + if (init_nic(sp) !=3D 0) {=0A= DBG_PRINT(ERR_DBG, "%s: H/W initialization failed\n",=0A= dev->name);=0A= return -ENODEV;=0A= }=0A= =0A= -/* After proper initialization of H/W, register ISR */=0A= + /* After proper initialization of H/W, register ISR */=0A= err =3D=0A= request_irq((int) sp->irq, s2io_isr, SA_SHIRQ, sp->name, dev);=0A= if (err) {=0A= @@ -2087,12 +2709,13 @@=0A= }=0A= =0A= =0A= -/* Setting its receive mode */=0A= + /* Setting its receive mode */=0A= s2io_set_multicast(dev);=0A= =0A= -/* Initializing the Rx buffers. For now we are considering only 1 Rx = ring=0A= - * and initializing buffers into 1016 RxDs or 8 Rx blocks=0A= - */=0A= + /* =0A= + * Initializing the Rx buffers. For now we are considering only 1 =0A= + * Rx ring and initializing buffers into 1016 RxDs or 8 Rx blocks=0A= + */=0A= mac_control =3D &sp->mac_control;=0A= config =3D &sp->config;=0A= =0A= @@ -2102,23 +2725,23 @@=0A= dev->name);=0A= s2io_reset(sp);=0A= free_irq(dev->irq, dev);=0A= - freeRxBuffers(sp);=0A= + free_rx_buffers(sp);=0A= return -ENOMEM;=0A= }=0A= DBG_PRINT(INFO_DBG, "Buf in ring:%d is %d:\n", i,=0A= atomic_read(&sp->rx_bufs_left[i]));=0A= }=0A= =0A= -/* Enable tasklet for the device */=0A= + /* Enable tasklet for the device */=0A= tasklet_init(&sp->task, s2io_tasklet, (unsigned long) dev);=0A= =0A= -/* Enable Rx Traffic and interrupts on the NIC */=0A= - if (startNic(sp)) {=0A= + /* Enable Rx Traffic and interrupts on the NIC */=0A= + if (start_nic(sp)) {=0A= DBG_PRINT(ERR_DBG, "%s: Starting NIC failed\n", dev->name);=0A= tasklet_kill(&sp->task);=0A= s2io_reset(sp);=0A= free_irq(dev->irq, dev);=0A= - freeRxBuffers(sp);=0A= + free_rx_buffers(sp);=0A= return -ENODEV;=0A= }=0A= =0A= @@ -2128,41 +2751,55 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - device pointer.=0A= - * Return value:=0A= - * '0' on success and an appropriate (-)ve integer as defined in = errno.h=0A= - * file on failure.=0A= +/**=0A= + * s2io_close -close entry point of the driver=0A= + * @dev : device pointer.=0A= * Description:=0A= * This is the stop entry point of the driver. It needs to undo exactly=0A= - * whatever was done by the open entry point, thus it's usually = referred to=0A= - * as the close function. Among other things this function mainly = stops the=0A= + * whatever was done by the open entry point,thus it's usually = referred to=0A= + * as the close function.Among other things this function mainly stops = the=0A= * Rx side of the NIC and frees all the Rx buffers in the Rx rings.=0A= + * Return value:=0A= + * 0 on success and an appropriate (-)ve integer as defined in errno.h=0A= + * file on failure.=0A= */=0A= +=0A= int s2io_close(struct net_device *dev)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= register u64 val64 =3D 0;=0A= u16 cnt =3D 0;=0A= + unsigned long flags;=0A= =0A= - spin_lock(&sp->isr_lock);=0A= + spin_lock_irqsave(&sp->tx_lock, flags);=0A= netif_stop_queue(dev);=0A= =0A= -/* disable Tx and Rx traffic on the NIC */=0A= - stopNic(sp);=0A= + /* disable Tx and Rx traffic on the NIC */=0A= + stop_nic(sp);=0A= =0A= - spin_unlock(&sp->isr_lock);=0A= -=0A= -/* If the device tasklet is running, wait till its done before killing = it */=0A= + /* =0A= + * If the device tasklet is running, wait till its done =0A= + * before killing it =0A= + */=0A= while (atomic_read(&(sp->tasklet_status))) {=0A= set_current_state(TASK_UNINTERRUPTIBLE);=0A= schedule_timeout(HZ / 10);=0A= }=0A= tasklet_kill(&sp->task);=0A= =0A= -/* Check if the device is Quiescent and then Reset the NIC */=0A= + /* Free the Registered IRQ */=0A= + free_irq(dev->irq, dev);=0A= +=0A= + /* Flush all scheduled tasks */=0A= + if (sp->task_flag =3D=3D 1) {=0A= + DBG_PRINT(INFO_DBG, "%s: Calling close from a task\n",=0A= + dev->name);=0A= + } else {=0A= + flush_scheduled_work();=0A= + }=0A= +=0A= + /* Check if the device is Quiescent and then Reset the NIC */=0A= do {=0A= val64 =3D readq(&bar0->adapter_status);=0A= if (verify_xena_quiescence(val64, sp->device_enabled_once)) {=0A= @@ -2182,36 +2819,35 @@=0A= } while (1);=0A= s2io_reset(sp);=0A= =0A= -/* Free the Registered IRQ */=0A= - free_irq(dev->irq, dev);=0A= -=0A= -/* Free all Tx Buffers waiting for transmission */=0A= - freeTxBuffers(sp);=0A= + /* Free all Tx Buffers waiting for transmission */=0A= + free_tx_buffers(sp);=0A= =0A= -/* Free all Rx buffers allocated by host */=0A= - freeRxBuffers(sp);=0A= + /* Free all Rx buffers allocated by host */=0A= + free_rx_buffers(sp);=0A= =0A= sp->device_close_flag =3D TRUE; /* Device is shut down. */=0A= + spin_unlock_irqrestore(&sp->tx_lock, flags);=0A= =0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * skb - the socket buffer containing the Tx data.=0A= - * dev - device pointer.=0A= - * Return value:=0A= - * '0' on success & 1 on failure. =0A= - * NOTE: when device cant queue the pkt, just the trans_start variable = will=0A= - * not be upadted.=0A= - * Description:=0A= +/**=0A= + * s2io_xmit - Tx entry point of te driver=0A= + * @skb : the socket buffer containing the Tx data.=0A= + * @dev : device pointer.=0A= + * Description :=0A= * This function is the Tx entry point of the driver. S2IO NIC supports=0A= * certain protocol assist features on Tx side, namely CSO, S/G, LSO.=0A= + * NOTE: when device cant queue the pkt,just the trans_start variable = will=0A= + * not be upadted.=0A= + * Return value:=0A= + * 0 on success & 1 on failure.=0A= */=0A= +=0A= int s2io_xmit(struct sk_buff *skb, struct net_device *dev)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= - u16 off, txd_len, frg_cnt, frg_len, i, queue, off1, queue_len;=0A= + u16 frg_cnt, frg_len, i, queue, queue_len, put_off, get_off;=0A= register u64 val64;=0A= TxD_t *txdp;=0A= TxFIFO_element_t *tx_fifo;=0A= @@ -2221,6 +2857,7 @@=0A= #endif=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= + XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= =0A= mac_control =3D &sp->mac_control;=0A= config =3D &sp->config;=0A= @@ -2228,6 +2865,14 @@=0A= DBG_PRINT(TX_DBG, "%s: In S2IO Tx routine\n", dev->name);=0A= =0A= spin_lock_irqsave(&sp->tx_lock, flags);=0A= + if ((netif_queue_stopped(dev)) || (!netif_carrier_ok(dev))) {=0A= + DBG_PRINT(ERR_DBG, "%s:s2io_xmit: Tx Queue stopped\n",=0A= + dev->name);=0A= + dev_kfree_skb(skb);=0A= + spin_unlock_irqrestore(&sp->tx_lock, flags);=0A= + return 0;=0A= + }=0A= +=0A= queue =3D 0;=0A= /* Multi FIFO Tx is disabled for now. */=0A= if (!queue && tx_prio) {=0A= @@ -2236,21 +2881,19 @@=0A= }=0A= =0A= =0A= - off =3D (u16) mac_control->tx_curr_put_info[queue].offset;=0A= - off1 =3D (u16) mac_control->tx_curr_get_info[queue].offset;=0A= - txd_len =3D mac_control->txdl_len;=0A= - txdp =3D mac_control->txdl_start[queue] + (config->MaxTxDs * off);=0A= + put_off =3D (u16) mac_control->tx_curr_put_info[queue].offset;=0A= + get_off =3D (u16) mac_control->tx_curr_get_info[queue].offset;=0A= + txdp =3D (TxD_t *) sp->list_info[queue][put_off].list_virt_addr;=0A= =0A= queue_len =3D mac_control->tx_curr_put_info[queue].fifo_len + 1;=0A= /* Avoid "put" pointer going beyond "get" pointer */=0A= - if (txdp->Host_Control || (((off + 1) % queue_len) =3D=3D off1)) {=0A= + if (txdp->Host_Control || (((put_off + 1) % queue_len) =3D=3D = get_off)) {=0A= DBG_PRINT(ERR_DBG, "Error in xmit, No free TXDs.\n");=0A= netif_stop_queue(dev);=0A= dev_kfree_skb(skb);=0A= spin_unlock_irqrestore(&sp->tx_lock, flags);=0A= return 0;=0A= }=0A= -=0A= #ifdef NETIF_F_TSO=0A= mss =3D skb_shinfo(skb)->tso_size;=0A= if (mss) {=0A= @@ -2289,8 +2932,7 @@=0A= txdp->Control_1 |=3D TXD_GATHER_CODE_LAST;=0A= =0A= tx_fifo =3D mac_control->tx_FIFO_start[queue];=0A= - val64 =3D (mac_control->txdl_start_phy[queue] +=0A= - (sizeof(TxD_t) * txd_len * off));=0A= + val64 =3D sp->list_info[queue][put_off].list_phy_addr;=0A= writeq(val64, &tx_fifo->TxDL_Pointer);=0A= =0A= val64 =3D (TX_FIFO_LAST_TXD_NUM(frg_cnt) | TX_FIFO_FIRST_LIST |=0A= @@ -2301,15 +2943,18 @@=0A= #endif=0A= writeq(val64, &tx_fifo->List_Control);=0A= =0A= - off++;=0A= - off %=3D mac_control->tx_curr_put_info[queue].fifo_len + 1;=0A= - mac_control->tx_curr_put_info[queue].offset =3D off;=0A= + /* Perform a PCI read to flush previous writes */=0A= + val64 =3D readq(&bar0->general_int_status);=0A= +=0A= + put_off++;=0A= + put_off %=3D mac_control->tx_curr_put_info[queue].fifo_len + 1;=0A= + mac_control->tx_curr_put_info[queue].offset =3D put_off;=0A= =0A= /* Avoid "put" pointer going beyond "get" pointer */=0A= - if (((off + 1) % queue_len) =3D=3D off1) {=0A= - DBG_PRINT(TX_DBG, =0A= - "No free TxDs for xmit, Put: 0x%x Get:0x%x\n",=0A= - off, off1);=0A= + if (((put_off + 1) % queue_len) =3D=3D get_off) {=0A= + DBG_PRINT(TX_DBG,=0A= + "No free TxDs for xmit, Put: 0x%x Get:0x%x\n",=0A= + put_off, get_off);=0A= netif_stop_queue(dev);=0A= }=0A= =0A= @@ -2319,36 +2964,37 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * irq: the irq of the device.=0A= - * dev_id: a void pointer to the dev structure of the NIC.=0A= - * ptregs: pointer to the registers pushed on the stack.=0A= +/**=0A= + * s2io_isr - ISR handler of the device .=0A= + * @irq: the irq of the device.=0A= + * @dev_id: a void pointer to the dev structure of the NIC.=0A= + * @pt_regs: pointer to the registers pushed on the stack.=0A= + * Description: This function is the ISR handler of the device. It =0A= + * identifies the reason for the interrupt and calls the relevant =0A= + * service routines. As a contongency measure, this ISR allocates the =0A= + * recv buffers, if their numbers are below the panic value which is=0A= + * presently set to 25% of the original number of rcv buffers = allocated.=0A= * Return value:=0A= - * void.=0A= - * Description:=0A= - * This function is the ISR handler of the device. It identifies the = reason =0A= - * for the interrupt and calls the relevant service routines.=0A= - * As a contongency measure, this ISR allocates the recv buffers, if = their =0A= - * numbers are below the panic value which is presently set to 25% of = the=0A= - * original number of rcv buffers allocated.=0A= + * IRQ_HANDLED: will be returned if IRQ was handled by this routine =0A= + * IRQ_NONE: will be returned if interrupt is not from our device=0A= */=0A= -=0A= static irqreturn_t s2io_isr(int irq, void *dev_id, struct pt_regs *regs)=0A= {=0A= struct net_device *dev =3D (struct net_device *) dev_id;=0A= nic_t *sp =3D dev->priv;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= - u64 reason =3D 0, general_mask =3D 0;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + int i, ret;=0A= +#endif=0A= + u64 reason =3D 0;=0A= mac_info_t *mac_control;=0A= struct config_param *config;=0A= =0A= mac_control =3D &sp->mac_control;=0A= config =3D &sp->config;=0A= =0A= - spin_lock(&sp->isr_lock);=0A= -=0A= - /* Identify the cause for interrupt and call the appropriate=0A= + /* =0A= + * Identify the cause for interrupt and call the appropriate=0A= * interrupt handler. Causes for the interrupt could be;=0A= * 1. Rx of packet.=0A= * 2. Tx complete.=0A= @@ -2359,69 +3005,53 @@=0A= =0A= if (!reason) {=0A= /* The interrupt was not raised by Xena. */=0A= - spin_unlock(&sp->isr_lock);=0A= return IRQ_NONE;=0A= }=0A= - /* Mask the interrupts on the NIC */=0A= - general_mask =3D readq(&bar0->general_int_mask);=0A= - writeq(0xFFFFFFFFFFFFFFFFULL, &bar0->general_int_mask);=0A= -=0A= -#if DEBUG_ON=0A= - sp->int_cnt++;=0A= -#endif=0A= =0A= /* If Intr is because of Tx Traffic */=0A= if (reason & GEN_INTR_TXTRAFFIC) {=0A= - txIntrHandler(sp);=0A= + tx_intr_handler(sp);=0A= }=0A= =0A= /* If Intr is because of an error */=0A= if (reason & (GEN_ERROR_INTR))=0A= - alarmIntrHandler(sp);=0A= + alarm_intr_handler(sp);=0A= =0A= #ifdef CONFIG_S2IO_NAPI=0A= if (reason & GEN_INTR_RXTRAFFIC) {=0A= if (netif_rx_schedule_prep(dev)) {=0A= - en_dis_able_NicIntrs(sp, RX_TRAFFIC_INTR,=0A= - DISABLE_INTRS);=0A= - /* We retake the snap shot of the general interrupt =0A= - * register.=0A= - */=0A= - general_mask =3D readq(&bar0->general_int_mask);=0A= + en_dis_able_nic_intrs(sp, RX_TRAFFIC_INTR,=0A= + DISABLE_INTRS);=0A= __netif_rx_schedule(dev);=0A= }=0A= }=0A= #else=0A= /* If Intr is because of Rx Traffic */=0A= if (reason & GEN_INTR_RXTRAFFIC) {=0A= - rxIntrHandler(sp);=0A= + rx_intr_handler(sp);=0A= }=0A= #endif=0A= =0A= -/* If the Rx buffer count is below the panic threshold then reallocate = the=0A= - * buffers from the interrupt handler itself, else schedule a tasklet = to =0A= - * reallocate the buffers.=0A= - */=0A= -#if 1=0A= - {=0A= - int i;=0A= -=0A= + /* =0A= + * If the Rx buffer count is below the panic threshold then =0A= + * reallocate the buffers from the interrupt handler itself, =0A= + * else schedule a tasklet to reallocate the buffers.=0A= + */=0A= +#ifndef CONFIG_S2IO_NAPI=0A= for (i =3D 0; i < config->RxRingNum; i++) {=0A= int rxb_size =3D atomic_read(&sp->rx_bufs_left[i]);=0A= int level =3D rx_buffer_level(sp, rxb_size, i);=0A= =0A= if ((level =3D=3D PANIC) && (!TASKLET_IN_USE)) {=0A= - int ret;=0A= -=0A= - DBG_PRINT(ERR_DBG, "%s: Rx BD hit ", dev->name);=0A= - DBG_PRINT(ERR_DBG, "PANIC levels\n");=0A= + DBG_PRINT(INTR_DBG, "%s: Rx BD hit ", dev->name);=0A= + DBG_PRINT(INTR_DBG, "PANIC levels\n");=0A= if ((ret =3D fill_rx_buffers(sp, i)) =3D=3D -ENOMEM) {=0A= DBG_PRINT(ERR_DBG, "%s:Out of memory",=0A= dev->name);=0A= DBG_PRINT(ERR_DBG, " in ISR!!\n");=0A= - writeq(general_mask,=0A= - &bar0->general_int_mask);=0A= - spin_unlock(&sp->isr_lock);=0A= + clear_bit(0,=0A= + (unsigned long *) (&sp->=0A= + tasklet_status));=0A= return IRQ_HANDLED;=0A= }=0A= clear_bit(0,=0A= @@ -2432,28 +3062,21 @@=0A= }=0A= =0A= }=0A= -=0A= - }=0A= -#else=0A= - tasklet_schedule(&sp->task);=0A= #endif=0A= =0A= - /* Unmask all the previously enabled interrupts on the NIC */=0A= - writeq(general_mask, &bar0->general_int_mask);=0A= -=0A= - spin_unlock(&sp->isr_lock);=0A= return IRQ_HANDLED;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - pointer to the device structure.=0A= - * Return value:=0A= - * pointer to the updated net_device_stats structure.=0A= +/**=0A= + * s2io_get_stats - Updates the device statistics structure. =0A= + * @dev : pointer to the device structure.=0A= * Description:=0A= * This function updates the device statistics structure in the = s2io_nic =0A= * structure and returns a pointer to the same.=0A= + * Return value:=0A= + * pointer to the updated net_device_stats structure.=0A= */=0A= +=0A= struct net_device_stats *s2io_get_stats(struct net_device *dev)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= @@ -2463,27 +3086,28 @@=0A= mac_control =3D &sp->mac_control;=0A= config =3D &sp->config;=0A= =0A= - sp->stats.tx_errors =3D mac_control->StatsInfo->tmac_any_err_frms;=0A= - sp->stats.rx_errors =3D mac_control->StatsInfo->rmac_drop_frms;=0A= - sp->stats.multicast =3D mac_control->StatsInfo->rmac_vld_mcst_frms;=0A= + sp->stats.tx_errors =3D mac_control->stats_info->tmac_any_err_frms;=0A= + sp->stats.rx_errors =3D mac_control->stats_info->rmac_drop_frms;=0A= + sp->stats.multicast =3D mac_control->stats_info->rmac_vld_mcst_frms;=0A= sp->stats.rx_length_errors =3D=0A= - mac_control->StatsInfo->rmac_long_frms;=0A= + mac_control->stats_info->rmac_long_frms;=0A= =0A= return (&sp->stats);=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - pointer to the device structure=0A= - * Return value:=0A= - * void.=0A= +/**=0A= + * s2io_set_multicast - entry point for multicast address = enable/disable.=0A= + * @dev : pointer to the device structure=0A= * Description:=0A= * This function is a driver entry point which gets called by the = kernel =0A= * whenever multicast addresses must be enabled/disabled. This also = gets =0A= * called to set/reset promiscuous mode. Depending on the deivce flag, = we=0A= * determine, if multicast address must be enabled or if promiscuous = mode=0A= * is to be disabled etc.=0A= + * Return value:=0A= + * void.=0A= */=0A= +=0A= static void s2io_set_multicast(struct net_device *dev)=0A= {=0A= int i, j, prev_cnt;=0A= @@ -2506,7 +3130,7 @@=0A= RMAC_ADDR_CMD_MEM_OFFSET(MAC_MC_ALL_MC_ADDR_OFFSET);=0A= writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= /* Wait till command completes */=0A= - waitForCmdComplete(sp);=0A= + wait_for_cmd_complete(sp);=0A= =0A= sp->m_cast_flg =3D 1;=0A= sp->all_multi_pos =3D MAC_MC_ALL_MC_ADDR_OFFSET;=0A= @@ -2519,7 +3143,7 @@=0A= RMAC_ADDR_CMD_MEM_OFFSET(sp->all_multi_pos);=0A= writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= /* Wait till command completes */=0A= - waitForCmdComplete(sp);=0A= + wait_for_cmd_complete(sp);=0A= =0A= sp->m_cast_flg =3D 0;=0A= sp->all_multi_pos =3D 0;=0A= @@ -2582,7 +3206,7 @@=0A= writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= =0A= /* Wait for command completes */=0A= - if (waitForCmdComplete(sp)) {=0A= + if (wait_for_cmd_complete(sp)) {=0A= DBG_PRINT(ERR_DBG, "%s: Adding ",=0A= dev->name);=0A= DBG_PRINT(ERR_DBG, "Multicasts failed\n");=0A= @@ -2609,7 +3233,7 @@=0A= writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= =0A= /* Wait for command completes */=0A= - if (waitForCmdComplete(sp)) {=0A= + if (wait_for_cmd_complete(sp)) {=0A= DBG_PRINT(ERR_DBG, "%s: Adding ",=0A= dev->name);=0A= DBG_PRINT(ERR_DBG, "Multicasts failed\n");=0A= @@ -2619,17 +3243,16 @@=0A= }=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - pointer to the device structure.=0A= - * new_mac - a uchar pointer to the new mac address which is to be set.=0A= - * Return value:=0A= - * SUCCESS on success and an appropriate (-)ve integer as defined in = errno.h=0A= - * file on failure.=0A= - * Description:=0A= - * This procedure will program the Xframe to receive frames with new=0A= - * Mac Address=0A= +/**=0A= + * s2io_set_mac_addr - Programs the Xframe mac address =0A= + * @dev : pointer to the device structure.=0A= + * @addr: a uchar pointer to the new mac address which is to be set.=0A= + * Description : This procedure will program the Xframe to receive =0A= + * frames with new Mac Address=0A= + * Return value: SUCCESS on success and an appropriate (-)ve integer =0A= + * as defined in errno.h file on failure.=0A= */=0A= +=0A= int s2io_set_mac_addr(struct net_device *dev, u8 * addr)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= @@ -2655,7 +3278,7 @@=0A= RMAC_ADDR_CMD_MEM_OFFSET(0);=0A= writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= /* Wait till command completes */=0A= - if (waitForCmdComplete(sp)) {=0A= + if (wait_for_cmd_complete(sp)) {=0A= DBG_PRINT(ERR_DBG, "%s: set_mac_addr failed\n", dev->name);=0A= return FAILURE;=0A= }=0A= @@ -2663,18 +3286,18 @@=0A= return SUCCESS;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * info - pointer to the structure with parameters given by ethtool to = set=0A= - * link information.=0A= - * Return value:=0A= - * 0 on success.=0A= +/**=0A= + * s2io_ethtool_sset - Sets different link parameters. =0A= + * @sp : private member of the device structure, which is a pointer to = the * s2io_nic structure.=0A= + * @info: pointer to the structure with parameters given by ethtool to = set=0A= + * link information.=0A= * Description:=0A= - * The function sets different link parameters provided by the user = onto =0A= - * the NIC.=0A= - */=0A= + * The function sets different link parameters provided by the user = onto =0A= + * the NIC.=0A= + * Return value:=0A= + * 0 on success.=0A= +*/=0A= +=0A= static int s2io_ethtool_sset(struct net_device *dev,=0A= struct ethtool_cmd *info)=0A= {=0A= @@ -2690,17 +3313,18 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * info - pointer to the structure with parameters given by ethtool to = return=0A= - * link information.=0A= - * Return value:=0A= - * void=0A= +/**=0A= + * s2io_ethtol_gset - Return link specific information. =0A= + * @sp : private member of the device structure, pointer to the=0A= + * s2io_nic structure.=0A= + * @info : pointer to the structure with parameters given by ethtool=0A= + * to return link information.=0A= * Description:=0A= - * Returns link specefic information like speed, duplex etc.. to = ethtool.=0A= + * Returns link specefic information like speed, duplex etc.. to = ethtool.=0A= + * Return value :=0A= + * return 0 on success.=0A= */=0A= +=0A= int s2io_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= @@ -2721,17 +3345,18 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * info - pointer to the structure with parameters given by ethtool to = return=0A= - * driver information.=0A= +/**=0A= + * s2io_ethtool_gdrvinfo - Returns driver specific information. =0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @info : pointer to the structure with parameters given by ethtool to=0A= + * return driver information.=0A= + * Description:=0A= + * Returns driver specefic information like name, version etc.. to = ethtool.=0A= * Return value:=0A= * void=0A= - * Description:=0A= - * Returns driver specefic information like name, version etc.. to = ethtool.=0A= */=0A= +=0A= static void s2io_ethtool_gdrvinfo(struct net_device *dev,=0A= struct ethtool_drvinfo *info)=0A= {=0A= @@ -2748,19 +3373,20 @@=0A= info->n_stats =3D S2IO_STAT_LEN;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * regs - pointer to the structure with parameters given by ethtool = for =0A= +/**=0A= + * s2io_ethtool_gregs - dumps the entire space of Xfame into te buffer.=0A= + * @sp: private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @regs : pointer to the structure with parameters given by ethtool = for =0A= * dumping the registers.=0A= - * reg_space - The input argumnet into which all the registers are = dumped.=0A= - * Return value:=0A= - * void=0A= - * Description:=0A= - * Dumps the entire register space of xFrame NIC into the user given = buffer =0A= - * area.=0A= - */=0A= + * @reg_space: The input argumnet into which all the registers are = dumped.=0A= + * Description:=0A= + * Dumps the entire register space of xFrame NIC into the user given=0A= + * buffer area.=0A= + * Return value :=0A= + * void .=0A= +*/=0A= +=0A= static void s2io_ethtool_gregs(struct net_device *dev,=0A= struct ethtool_regs *regs, void *space)=0A= {=0A= @@ -2778,17 +3404,15 @@=0A= }=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * data - address of the private member of the device structure, which =0A= +/**=0A= + * s2io_phy_id - timer function that alternates adapter LED.=0A= + * @data : address of the private member of the device structure, = which =0A= * is a pointer to the s2io_nic structure, provided as an u32.=0A= - * Return value:=0A= - * void=0A= - * Description:=0A= - * This is actually the timer function that alternates the adapter LED = bit=0A= - * of the adapter control bit to set/reset every time on invocation.=0A= - * The timer is set for 1/2 a second, hence tha NIC blinks once every = second.=0A= - */=0A= + * Description: This is actually the timer function that alternates the =0A= + * adapter LED bit of the adapter control bit to set/reset every time = on =0A= + * invocation. The timer is set for 1/2 a second, hence tha NIC blinks =0A= + * once every second.=0A= +*/=0A= static void s2io_phy_id(unsigned long data)=0A= {=0A= nic_t *sp =3D (nic_t *) data;=0A= @@ -2810,28 +3434,30 @@=0A= mod_timer(&sp->id_timer, jiffies + HZ / 2);=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * id - pointer to the structure with identification parameters given = by =0A= - * ethtool.=0A= +/**=0A= + * s2io_ethtool_idnic - To physically ientify the nic on the system.=0A= + * @sp : private member of the device structure, which is a pointer to = the=0A= + * s2io_nic structure.=0A= + * @id : pointer to the structure with identification parameters given = by =0A= + * ethtool.=0A= + * Description: Used to physically identify the NIC on the system.=0A= + * The Link LED will blink for a time specified by the user for =0A= + * identification.=0A= + * NOTE: The Link has to be Up to be able to blink the LED. Hence =0A= + * identification is possible only if it's link is up.=0A= * Return value:=0A= - * int , returns '0' on success=0A= - * Description:=0A= - * Used to physically identify the NIC on the system. The Link LED = will blink=0A= - * for a time specified by the user for identification.=0A= - * NOTE: The Link has to be Up to be able to blink the LED. Hence =0A= - * identification is possible only if it's link is up.=0A= + * int , returns 0 on success=0A= */=0A= +=0A= static int s2io_ethtool_idnic(struct net_device *dev, u32 data)=0A= {=0A= - u64 val64 =3D 0;=0A= + u64 val64 =3D 0, last_gpio_ctrl_val;=0A= nic_t *sp =3D dev->priv;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= u16 subid;=0A= =0A= subid =3D sp->pdev->subsystem_device;=0A= + last_gpio_ctrl_val =3D readq(&bar0->gpio_control);=0A= if ((subid & 0xFF) < 0x07) {=0A= val64 =3D readq(&bar0->adapter_control);=0A= if (!(val64 & ADAPTER_CNTL_EN)) {=0A= @@ -2853,18 +3479,22 @@=0A= schedule_timeout(MAX_SCHEDULE_TIMEOUT);=0A= del_timer_sync(&sp->id_timer);=0A= =0A= + if (CARDS_WITH_FAULTY_LINK_INDICATORS(subid)) {=0A= + writeq(last_gpio_ctrl_val, &bar0->gpio_control);=0A= + last_gpio_ctrl_val =3D readq(&bar0->gpio_control);=0A= + }=0A= +=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * ep - pointer to the structure with pause parameters given by = ethtool.=0A= +/**=0A= + * s2io_ethtool_getpause_data -Pause frame frame generation and = reception.=0A= + * @sp : private member of the device structure, which is a pointer to = the * s2io_nic structure.=0A= + * @ep : pointer to the structure with pause parameters given by = ethtool.=0A= + * Description:=0A= + * Returns the Pause frame generation and reception capability of the = NIC.=0A= * Return value:=0A= * void=0A= - * Description:=0A= - * Returns the Pause frame generation and reception capability of the = NIC.=0A= */=0A= static void s2io_ethtool_getpause_data(struct net_device *dev,=0A= struct ethtool_pauseparam *ep)=0A= @@ -2881,17 +3511,18 @@=0A= ep->autoneg =3D FALSE;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * ep - pointer to the structure with pause parameters given by ethtool.=0A= - * Return value:=0A= - * int, returns '0' on Success=0A= +/**=0A= + * s2io_ethtool-setpause_data - set/reset pause frame generation.=0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @ep : pointer to the structure with pause parameters given by = ethtool.=0A= * Description:=0A= - * It can be used to set or reset Pause frame generation or reception = support =0A= - * of the NIC.=0A= + * It can be used to set or reset Pause frame generation or reception=0A= + * support of the NIC.=0A= + * Return value:=0A= + * int, returns 0 on Success=0A= */=0A= +=0A= int s2io_ethtool_setpause_data(struct net_device *dev,=0A= struct ethtool_pauseparam *ep)=0A= {=0A= @@ -2912,35 +3543,40 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * off - offset at which the data must be written=0A= - * Return value:=0A= - * -1 on failure and the value read from the Eeprom if successful.=0A= +/**=0A= + * read_eeprom - reads 4 bytes of data from user given offset.=0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @off : offset at which the data must be written=0A= + * @data : Its an output parameter where the data read at the given=0A= + * offset is stored.=0A= * Description:=0A= - * Will read 4 bytes of data from the user given offset and return the =0A= - * read data.=0A= + * Will read 4 bytes of data from the user given offset and return the =0A= + * read data.=0A= * NOTE: Will allow to read only part of the EEPROM visible through the=0A= - * I2C bus.=0A= + * I2C bus.=0A= + * Return value:=0A= + * -1 on failure and 0 on success.=0A= */=0A= +=0A= #define S2IO_DEV_ID 5=0A= -static u32 readEeprom(nic_t * sp, int off)=0A= +static int read_eeprom(nic_t * sp, int off, u32 * data)=0A= {=0A= - u32 data =3D -1, exit_cnt =3D 0;=0A= + int ret =3D -1;=0A= + u32 exit_cnt =3D 0;=0A= u64 val64;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= =0A= val64 =3D I2C_CONTROL_DEV_ID(S2IO_DEV_ID) | I2C_CONTROL_ADDR(off) |=0A= I2C_CONTROL_BYTE_CNT(0x3) | I2C_CONTROL_READ |=0A= I2C_CONTROL_CNTL_START;=0A= - writeq(val64, &bar0->i2c_control);=0A= + SPECIAL_REG_WRITE(val64, &bar0->i2c_control, LF);=0A= =0A= while (exit_cnt < 5) {=0A= val64 =3D readq(&bar0->i2c_control);=0A= if (I2C_CONTROL_CNTL_END(val64)) {=0A= - data =3D I2C_CONTROL_GET_DATA(val64);=0A= + *data =3D I2C_CONTROL_GET_DATA(val64);=0A= + ret =3D 0;=0A= break;=0A= }=0A= set_current_state(TASK_UNINTERRUPTIBLE);=0A= @@ -2948,24 +3584,25 @@=0A= exit_cnt++;=0A= }=0A= =0A= - return data;=0A= + return ret;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * off - offset at which the data must be written=0A= - * data - The data that is to be written=0A= - * cnt - Number of bytes of the data that are actually to be written = into =0A= +/**=0A= + * write_eeprom - actually writes the relevant part of the data value.=0A= + * @sp : private member of the device structure, which is a pointer to = the=0A= + * s2io_nic structure.=0A= + * @off : offset at which the data must be written=0A= + * @data : The data that is to be written=0A= + * @cnt : Number of bytes of the data that are actually to be written = into =0A= * the Eeprom. (max of 3)=0A= - * Return value:=0A= - * '0' on success, -1 on failure.=0A= * Description:=0A= * Actually writes the relevant part of the data value into the Eeprom=0A= * through the I2C bus.=0A= + * Return value:=0A= + * 0 on success, -1 on failure.=0A= */=0A= -static int writeEeprom(nic_t * sp, int off, u32 data, int cnt)=0A= +=0A= +static int write_eeprom(nic_t * sp, int off, u32 data, int cnt)=0A= {=0A= int exit_cnt =3D 0, ret =3D -1;=0A= u64 val64;=0A= @@ -2974,7 +3611,7 @@=0A= val64 =3D I2C_CONTROL_DEV_ID(S2IO_DEV_ID) | I2C_CONTROL_ADDR(off) |=0A= I2C_CONTROL_BYTE_CNT(cnt) | I2C_CONTROL_SET_DATA(data) |=0A= I2C_CONTROL_CNTL_START;=0A= - writeq(val64, &bar0->i2c_control);=0A= + SPECIAL_REG_WRITE(val64, &bar0->i2c_control, LF);=0A= =0A= while (exit_cnt < 5) {=0A= val64 =3D readq(&bar0->i2c_control);=0A= @@ -2991,39 +3628,19 @@=0A= return ret;=0A= }=0A= =0A= -/* =0A= - * A helper function used to invert the 4 byte u32 data field=0A= - * byte by byte. This will be used by the Read Eeprom function=0A= - * for display purposes.=0A= - */=0A= -u32 inv(u32 data)=0A= -{=0A= - static u32 ret =3D 0;=0A= -=0A= - if (data) {=0A= - u8 c =3D data;=0A= - ret =3D ((ret << 8) + c);=0A= - data >>=3D 8;=0A= - inv(data);=0A= - }=0A= -=0A= - return ret;=0A= -}=0A= -=0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * eeprom - pointer to the user level structure provided by ethtool, =0A= - * containing all relevant information.=0A= - * data_buf - user defined value to be written into Eeprom.=0A= - * Return value:=0A= - * int '0' on success=0A= - * Description:=0A= - * Reads the values stored in the Eeprom at given offset for a given = length.=0A= - * Stores these values int the input argument data buffer 'data_buf' = and=0A= - * returns these to the caller (ethtool.)=0A= +/**=0A= + * s2io_ethtool_geeprom - reads the value stored in the Eeprom.=0A= + * @sp : private member of the device structure, which is a pointer to = the * s2io_nic structure.=0A= + * @eeprom : pointer to the user level structure provided by ethtool, =0A= + * containing all relevant information.=0A= + * @data_buf : user defined value to be written into Eeprom.=0A= + * Description: Reads the values stored in the Eeprom at given offset=0A= + * for a given length. Stores these values int the input argument data=0A= + * buffer 'data_buf' and returns these to the caller (ethtool.)=0A= + * Return value:=0A= + * int 0 on success=0A= */=0A= +=0A= int s2io_ethtool_geeprom(struct net_device *dev,=0A= struct ethtool_eeprom *eeprom, u8 * data_buf)=0A= {=0A= @@ -3036,30 +3653,30 @@=0A= eeprom->len =3D XENA_EEPROM_SPACE - eeprom->offset;=0A= =0A= for (i =3D 0; i < eeprom->len; i +=3D 4) {=0A= - data =3D readEeprom(sp, eeprom->offset + i);=0A= - if (data < 0) {=0A= + if (read_eeprom(sp, (eeprom->offset + i), &data)) {=0A= DBG_PRINT(ERR_DBG, "Read of EEPROM failed\n");=0A= return -EFAULT;=0A= }=0A= - valid =3D inv(data);=0A= + valid =3D INV(data);=0A= memcpy((data_buf + i), &valid, 4);=0A= }=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * eeprom - pointer to the user level structure provided by ethtool, =0A= - * containing all relevant information.=0A= - * data_buf - user defined value to be written into Eeprom.=0A= - * Return value:=0A= - * '0' on success, -EFAULT on failure.=0A= - * Description:=0A= +/**=0A= + * s2io_ethtool_seeprom - tries to write the user provided value in = Eeprom=0A= + * @sp : private member of the device structure, which is a pointer to = the=0A= + * s2io_nic structure.=0A= + * @eeprom : pointer to the user level structure provided by ethtool, =0A= + * containing all relevant information.=0A= + * @data_buf ; user defined value to be written into Eeprom.=0A= + * Description:=0A= * Tries to write the user provided value in the Eeprom, at the offset=0A= * given by the user.=0A= + * Return value:=0A= + * 0 on success, -EFAULT on failure.=0A= */=0A= +=0A= static int s2io_ethtool_seeprom(struct net_device *dev,=0A= struct ethtool_eeprom *eeprom,=0A= u8 * data_buf)=0A= @@ -3083,7 +3700,7 @@=0A= } else=0A= valid =3D data;=0A= =0A= - if (writeEeprom(sp, (eeprom->offset + cnt), valid, 0)) {=0A= + if (write_eeprom(sp, (eeprom->offset + cnt), valid, 0)) {=0A= DBG_PRINT(ERR_DBG,=0A= "ETHTOOL_WRITE_EEPROM Err: Cannot ");=0A= DBG_PRINT(ERR_DBG,=0A= @@ -3097,19 +3714,20 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * data - variable that returns the result of each of the test = conducted by =0A= - * the driver.=0A= - * Return value:=0A= - * '0' on success.=0A= +/**=0A= + * s2io_register_test - reads and writes into all clock domains. =0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @data : variable that returns the result of each of the test = conducted b=0A= + * by the driver.=0A= * Description:=0A= - * Read and write into all clock domains. The NIC has 3 clock domains,=0A= - * see that registers in all the three regions are accessible.=0A= + * Read and write into all clock domains. The NIC has 3 clock domains,=0A= + * see that registers in all the three regions are accessible.=0A= + * Return value:=0A= + * 0 on success.=0A= */=0A= -static int s2io_registerTest(nic_t * sp, uint64_t * data)=0A= +=0A= +static int s2io_register_test(nic_t * sp, uint64_t * data)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= u64 val64 =3D 0;=0A= @@ -3159,88 +3777,91 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * data - variable that returns the result of each of the test = conducted by =0A= - * the driver.=0A= - * Return value:=0A= - * '0' on success.=0A= +/**=0A= + * s2io_eeprom_test - to verify that EEprom in the xena can be = programmed. =0A= + * @sp : private member of the device structure, which is a pointer to = the=0A= + * s2io_nic structure.=0A= + * @data:variable that returns the result of each of the test conducted = by=0A= + * the driver.=0A= * Description:=0A= - * Verify that EEPROM in the xena can be programmed using I2C_CONTROL =0A= - * register.=0A= + * Verify that EEPROM in the xena can be programmed using I2C_CONTROL =0A= + * register.=0A= + * Return value:=0A= + * 0 on success.=0A= */=0A= -static int s2io_eepromTest(nic_t * sp, uint64_t * data)=0A= +=0A= +static int s2io_eeprom_test(nic_t * sp, uint64_t * data)=0A= {=0A= - int fail =3D 0, ret_data;=0A= + int fail =3D 0;=0A= + u32 ret_data;=0A= =0A= /* Test Write Error at offset 0 */=0A= - if (!writeEeprom(sp, 0, 0, 3))=0A= + if (!write_eeprom(sp, 0, 0, 3))=0A= fail =3D 1;=0A= =0A= /* Test Write at offset 4f0 */=0A= - if (writeEeprom(sp, 0x4F0, 0x01234567, 3))=0A= + if (write_eeprom(sp, 0x4F0, 0x01234567, 3))=0A= fail =3D 1;=0A= - if ((ret_data =3D readEeprom(sp, 0x4f0)) < 0)=0A= + if (read_eeprom(sp, 0x4F0, &ret_data))=0A= fail =3D 1;=0A= =0A= if (ret_data !=3D 0x01234567)=0A= fail =3D 1;=0A= =0A= /* Reset the EEPROM data go FFFF */=0A= - writeEeprom(sp, 0x4F0, 0xFFFFFFFF, 3);=0A= + write_eeprom(sp, 0x4F0, 0xFFFFFFFF, 3);=0A= =0A= /* Test Write Request Error at offset 0x7c */=0A= - if (!writeEeprom(sp, 0x07C, 0, 3))=0A= + if (!write_eeprom(sp, 0x07C, 0, 3))=0A= fail =3D 1;=0A= =0A= /* Test Write Request at offset 0x7fc */=0A= - if (writeEeprom(sp, 0x7FC, 0x01234567, 3))=0A= + if (write_eeprom(sp, 0x7FC, 0x01234567, 3))=0A= fail =3D 1;=0A= - if ((ret_data =3D readEeprom(sp, 0x7FC)) < 0)=0A= + if (read_eeprom(sp, 0x7FC, &ret_data))=0A= fail =3D 1;=0A= =0A= if (ret_data !=3D 0x01234567)=0A= fail =3D 1;=0A= =0A= /* Reset the EEPROM data go FFFF */=0A= - writeEeprom(sp, 0x7FC, 0xFFFFFFFF, 3);=0A= + write_eeprom(sp, 0x7FC, 0xFFFFFFFF, 3);=0A= =0A= /* Test Write Error at offset 0x80 */=0A= - if (!writeEeprom(sp, 0x080, 0, 3))=0A= + if (!write_eeprom(sp, 0x080, 0, 3))=0A= fail =3D 1;=0A= =0A= /* Test Write Error at offset 0xfc */=0A= - if (!writeEeprom(sp, 0x0FC, 0, 3))=0A= + if (!write_eeprom(sp, 0x0FC, 0, 3))=0A= fail =3D 1;=0A= =0A= /* Test Write Error at offset 0x100 */=0A= - if (!writeEeprom(sp, 0x100, 0, 3))=0A= + if (!write_eeprom(sp, 0x100, 0, 3))=0A= fail =3D 1;=0A= =0A= /* Test Write Error at offset 4ec */=0A= - if (!writeEeprom(sp, 0x4EC, 0, 3))=0A= + if (!write_eeprom(sp, 0x4EC, 0, 3))=0A= fail =3D 1;=0A= =0A= *data =3D fail;=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * data - variable that returns the result of each of the test = conducted by =0A= - * the driver.=0A= - * Return value:=0A= - * '0' on success and -1 on failure.=0A= +/**=0A= + * s2io_bist_test - invokes the MemBist test of the card .=0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @data:variable that returns the result of each of the test conducted = by =0A= + * the driver.=0A= * Description:=0A= - * This invokes the MemBist test of the card. We give around=0A= - * 2 secs time for the Test to complete. If it's still not complete=0A= - * within this peiod, we consider that the test failed. =0A= + * This invokes the MemBist test of the card. We give around=0A= + * 2 secs time for the Test to complete. If it's still not complete=0A= + * within this peiod, we consider that the test failed. =0A= + * Return value:=0A= + * 0 on success and -1 on failure.=0A= */=0A= -static int s2io_bistTest(nic_t * sp, uint64_t * data)=0A= +=0A= +static int s2io_bist_test(nic_t * sp, uint64_t * data)=0A= {=0A= u8 bist =3D 0;=0A= int cnt =3D 0, ret =3D -1;=0A= @@ -3264,19 +3885,20 @@=0A= return ret;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * data - variable that returns the result of each of the test = conducted by =0A= - * the driver.=0A= - * Return value:=0A= - * '0' on success.=0A= +/**=0A= + * s2io-link_test - verifies the link state of the nic =0A= + * @sp ; private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @data: variable that returns the result of each of the test = conducted by=0A= + * the driver.=0A= * Description:=0A= - * The function verifies the link state of the NIC and updates the = input =0A= - * argument 'data' appropriately.=0A= + * The function verifies the link state of the NIC and updates the = input =0A= + * argument 'data' appropriately.=0A= + * Return value:=0A= + * 0 on success.=0A= */=0A= -static int s2io_linkTest(nic_t * sp, uint64_t * data)=0A= +=0A= +static int s2io_link_test(nic_t * sp, uint64_t * data)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= u64 val64;=0A= @@ -3288,19 +3910,20 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * data - variable that returns the result of each of the test = conducted by =0A= - * the driver.=0A= - * Return value:=0A= - * '0' on success.=0A= +/**=0A= + * s2io_rldram_test - offline test for access to the RldRam chip on the = NIC =0A= + * @sp - private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * @data - variable that returns the result of each of the test =0A= + * conducted by the driver.=0A= * Description:=0A= * This is one of the offline test that tests the read and write =0A= * access to the RldRam chip on the NIC.=0A= + * Return value:=0A= + * 0 on success.=0A= */=0A= -static int s2io_rldramTest(nic_t * sp, uint64_t * data)=0A= +=0A= +static int s2io_rldram_test(nic_t * sp, uint64_t * data)=0A= {=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= u64 val64;=0A= @@ -3316,10 +3939,10 @@=0A= =0A= val64 =3D readq(&bar0->mc_rldram_mrs);=0A= val64 |=3D MC_RLDRAM_QUEUE_SIZE_ENABLE;=0A= - writeq(val64, &bar0->mc_rldram_mrs);=0A= + SPECIAL_REG_WRITE(val64, &bar0->mc_rldram_mrs, UF);=0A= =0A= val64 |=3D MC_RLDRAM_MRS_ENABLE;=0A= - writeq(val64, &bar0->mc_rldram_mrs);=0A= + SPECIAL_REG_WRITE(val64, &bar0->mc_rldram_mrs, UF);=0A= =0A= while (iteration < 2) {=0A= val64 =3D 0x55555555aaaa0000ULL;=0A= @@ -3395,20 +4018,21 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * ethtest - pointer to a ethtool command specific structure that will = be=0A= - * returned to the user.=0A= - * data - variable that returns the result of each of the test = conducted by =0A= - * the driver.=0A= - * Return value:=0A= - * SUCCESS on success and an appropriate -1 on failure.=0A= +/**=0A= + * s2io_ethtool_test - conducts 6 tsets to determine the health of = card.=0A= + * @sp : private member of the device structure, which is a pointer to = the=0A= + * s2io_nic structure.=0A= + * @ethtest : pointer to a ethtool command specific structure that = will be=0A= + * returned to the user.=0A= + * @data : variable that returns the result of each of the test =0A= + * conducted by the driver.=0A= * Description:=0A= * This function conducts 6 tests ( 4 offline and 2 online) to = determine=0A= - * the health of the card.=0A= + * the health of the card.=0A= + * Return value:=0A= + * void=0A= */=0A= +=0A= static void s2io_ethtool_test(struct net_device *dev,=0A= struct ethtool_test *ethtest,=0A= uint64_t * data)=0A= @@ -3424,22 +4048,22 @@=0A= } else=0A= s2io_set_swapper(sp);=0A= =0A= - if (s2io_registerTest(sp, &data[0]))=0A= + if (s2io_register_test(sp, &data[0]))=0A= ethtest->flags |=3D ETH_TEST_FL_FAILED;=0A= =0A= s2io_reset(sp);=0A= s2io_set_swapper(sp);=0A= =0A= - if (s2io_rldramTest(sp, &data[3]))=0A= + if (s2io_rldram_test(sp, &data[3]))=0A= ethtest->flags |=3D ETH_TEST_FL_FAILED;=0A= =0A= s2io_reset(sp);=0A= s2io_set_swapper(sp);=0A= =0A= - if (s2io_eepromTest(sp, &data[1]))=0A= + if (s2io_eeprom_test(sp, &data[1]))=0A= ethtest->flags |=3D ETH_TEST_FL_FAILED;=0A= =0A= - if (s2io_bistTest(sp, &data[4]))=0A= + if (s2io_bist_test(sp, &data[4]))=0A= ethtest->flags |=3D ETH_TEST_FL_FAILED;=0A= =0A= if (orig_state)=0A= @@ -3459,7 +4083,7 @@=0A= data[4] =3D -1;=0A= }=0A= =0A= - if (s2io_linkTest(sp, &data[2]))=0A= + if (s2io_link_test(sp, &data[2]))=0A= ethtest->flags |=3D ETH_TEST_FL_FAILED;=0A= =0A= data[0] =3D 0;=0A= @@ -3475,7 +4099,7 @@=0A= {=0A= int i =3D 0;=0A= nic_t *sp =3D dev->priv;=0A= - StatInfo_t *stat_info =3D sp->mac_control.StatsInfo;=0A= + StatInfo_t *stat_info =3D sp->mac_control.stats_info;=0A= =0A= tmp_stats[i++] =3D stat_info->tmac_frms;=0A= tmp_stats[i++] =3D stat_info->tmac_data_octets;=0A= @@ -3567,6 +4191,17 @@=0A= return (S2IO_STAT_LEN);=0A= }=0A= =0A= +int s2io_ethtool_op_set_tx_csum(struct net_device *dev, u32 data)=0A= +{=0A= + if (data)=0A= + dev->features |=3D NETIF_F_IP_CSUM;=0A= + else=0A= + dev->features &=3D ~NETIF_F_IP_CSUM;=0A= +=0A= + return 0;=0A= +}=0A= +=0A= +=0A= static struct ethtool_ops netdev_ethtool_ops =3D {=0A= .get_settings =3D s2io_ethtool_gset,=0A= .set_settings =3D s2io_ethtool_sset,=0A= @@ -3582,7 +4217,7 @@=0A= .get_rx_csum =3D s2io_ethtool_get_rx_csum,=0A= .set_rx_csum =3D s2io_ethtool_set_rx_csum,=0A= .get_tx_csum =3D ethtool_op_get_tx_csum,=0A= - .set_tx_csum =3D ethtool_op_set_tx_csum,=0A= + .set_tx_csum =3D s2io_ethtool_op_set_tx_csum,=0A= .get_sg =3D ethtool_op_get_sg,=0A= .set_sg =3D ethtool_op_set_sg,=0A= #ifdef NETIF_F_TSO=0A= @@ -3597,36 +4232,37 @@=0A= .get_ethtool_stats =3D s2io_get_ethtool_stats=0A= };=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - Device pointer.=0A= - * ifr - An IOCTL specefic structure, that can contain a pointer to=0A= - * a proprietary structure used to pass information to the driver.=0A= - * cmd - This is used to distinguish between the different commands = that=0A= - * can be passed to the IOCTL functions.=0A= - * Return value:=0A= - * '0' on success and an appropriate (-)ve integer as defined in = errno.h=0A= - * file on failure.=0A= +/**=0A= + * s2io_ioctl - Entry point for the Ioctl =0A= + * @dev : Device pointer.=0A= + * @ifr : An IOCTL specefic structure, that can contain a pointer to=0A= + * a proprietary structure used to pass information to the driver.=0A= + * @cmd : This is used to distinguish between the different commands = that=0A= + * can be passed to the IOCTL functions.=0A= * Description:=0A= * This function has support for ethtool, adding multiple MAC = addresses on =0A= * the NIC and some DBG commands for the util tool.=0A= + * Return value:=0A= + * Currently the IOCTL supports no operations, hence by default this=0A= + * function returns OP NOT SUPPORTED value.=0A= */=0A= +=0A= int s2io_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)=0A= {=0A= return -EOPNOTSUPP;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - device pointer.=0A= - * new_mtu - the new MTU size for the device.=0A= +/**=0A= + * s2io_change_mtu - entry point to change MTU size for the device.=0A= + * @dev : device pointer.=0A= + * @new_mtu : the new MTU size for the device.=0A= + * Description: A driver entry point to change MTU size for the = device.=0A= + * Before changing the MTU the device must be stopped.=0A= * Return value:=0A= - * '0' on success and an appropriate (-)ve integer as defined in = errno.h=0A= + * 0 on success and an appropriate (-)ve integer as defined in errno.h=0A= * file on failure.=0A= - * Description:=0A= - * A driver entry point to change MTU size for the device. Before = changing=0A= - * the MTU the device must be stopped.=0A= */=0A= +=0A= int s2io_change_mtu(struct net_device *dev, int new_mtu)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= @@ -3645,7 +4281,7 @@=0A= return -EPERM;=0A= }=0A= =0A= -/* Set the new MTU into the PYLD register of the NIC */=0A= + /* Set the new MTU into the PYLD register of the NIC */=0A= val64 =3D new_mtu;=0A= writeq(vBIT(val64, 2, 14), &bar0->rmac_max_pyld_len);=0A= =0A= @@ -3654,18 +4290,19 @@=0A= return 0;=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev_adr - address of the device structure in dma_addr_t format.=0A= - * Return value:=0A= - * void.=0A= +/**=0A= + * s2io_tasklet - Bottom half of the ISR.=0A= + * @dev_adr : address of the device structure in dma_addr_t format.=0A= * Description:=0A= * This is the tasklet or the bottom half of the ISR. This is=0A= * an extension of the ISR which is scheduled by the scheduler to be = run =0A= * when the load on the CPU is low. All low priority tasks of the ISR = can=0A= * be pushed into the tasklet. For now the tasklet is used only to =0A= * replenish the Rx buffers in the Rx buffer descriptors.=0A= + * Return value:=0A= + * void.=0A= */=0A= +=0A= static void s2io_tasklet(unsigned long dev_addr)=0A= {=0A= struct net_device *dev =3D (struct net_device *) dev_addr;=0A= @@ -3684,31 +4321,35 @@=0A= DBG_PRINT(ERR_DBG, "%s: Out of ",=0A= dev->name);=0A= DBG_PRINT(ERR_DBG, "memory in tasklet\n");=0A= - return;=0A= + break;=0A= } else if (ret =3D=3D -EFILL) {=0A= DBG_PRINT(ERR_DBG,=0A= "%s: Rx Ring %d is full\n",=0A= dev->name, i);=0A= - return;=0A= + break;=0A= }=0A= }=0A= clear_bit(0, (unsigned long *) (&sp->tasklet_status));=0A= }=0A= }=0A= =0A= -=0A= -/*=0A= - * Description:=0A= - * =0A= +/**=0A= + * s2io_set_link - Set the LInk status=0A= + * @data: long pointer to device private structue=0A= + * Description: Sets the link status for the adapter=0A= */=0A= +=0A= static void s2io_set_link(unsigned long data)=0A= {=0A= nic_t *nic =3D (nic_t *) data;=0A= struct net_device *dev =3D nic->dev;=0A= XENA_dev_config_t *bar0 =3D (XENA_dev_config_t *) nic->bar0;=0A= - register u64 val64, err_reg;=0A= + register u64 val64;=0A= + u16 subid;=0A= =0A= - /* Allow a small delay for the NICs self initiated =0A= + subid =3D nic->pdev->subsystem_device;=0A= + /* =0A= + * Allow a small delay for the NICs self initiated =0A= * cleanup to complete.=0A= */=0A= set_current_state(TASK_UNINTERRUPTIBLE);=0A= @@ -3716,16 +4357,19 @@=0A= =0A= val64 =3D readq(&bar0->adapter_status);=0A= if (verify_xena_quiescence(val64, nic->device_enabled_once)) {=0A= - /* Acknowledge interrupt and clear the R1 register */=0A= - err_reg =3D readq(&bar0->mac_rmac_err_reg);=0A= - writeq(err_reg, &bar0->mac_rmac_err_reg);=0A= -=0A= if (LINK_IS_UP(val64)) {=0A= val64 =3D readq(&bar0->adapter_control);=0A= val64 |=3D ADAPTER_CNTL_EN;=0A= writeq(val64, &bar0->adapter_control);=0A= - val64 |=3D ADAPTER_LED_ON;=0A= - writeq(val64, &bar0->adapter_control);=0A= + if (CARDS_WITH_FAULTY_LINK_INDICATORS(subid)) {=0A= + val64 =3D readq(&bar0->gpio_control);=0A= + val64 |=3D GPIO_CTRL_GPIO_0;=0A= + writeq(val64, &bar0->gpio_control);=0A= + val64 =3D readq(&bar0->gpio_control);=0A= + } else {=0A= + val64 |=3D ADAPTER_LED_ON;=0A= + writeq(val64, &bar0->adapter_control);=0A= + }=0A= val64 =3D readq(&bar0->adapter_status);=0A= if (!LINK_IS_UP(val64)) {=0A= DBG_PRINT(ERR_DBG, "%s:", dev->name);=0A= @@ -3739,6 +4383,12 @@=0A= }=0A= s2io_link(nic, LINK_UP);=0A= } else {=0A= + if (CARDS_WITH_FAULTY_LINK_INDICATORS(subid)) {=0A= + val64 =3D readq(&bar0->gpio_control);=0A= + val64 &=3D ~GPIO_CTRL_GPIO_0;=0A= + writeq(val64, &bar0->gpio_control);=0A= + val64 =3D readq(&bar0->gpio_control);=0A= + }=0A= s2io_link(nic, LINK_DOWN);=0A= }=0A= } else { /* NIC is not Quiescent. */=0A= @@ -3748,37 +4398,43 @@=0A= }=0A= }=0A= =0A= -/*=0A= +/** =0A= + * s2io_restart_nic - Resets the NIC.=0A= + * @data : long pointer to the device private structure=0A= * Description:=0A= * This function is scheduled to be run by the s2io_tx_watchdog=0A= * function after 0.5 secs to reset the NIC. The idea is to reduce =0A= * the run time of the watch dog routine which is run holding a=0A= * spin lock.=0A= */=0A= +=0A= static void s2io_restart_nic(unsigned long data)=0A= {=0A= struct net_device *dev =3D (struct net_device *) data;=0A= nic_t *sp =3D dev->priv;=0A= =0A= + sp->task_flag =3D 1;=0A= s2io_close(dev);=0A= + sp->task_flag =3D 0;=0A= sp->device_close_flag =3D TRUE;=0A= s2io_open(dev);=0A= DBG_PRINT(ERR_DBG,=0A= "%s: was reset by Tx watchdog timer.\n", dev->name);=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * dev - device pointer.=0A= - * Return value:=0A= - * void=0A= +/** =0A= + * s2io_tx_watchdog - Watchdog for transmit side. =0A= + * @dev : Pointer to net device structure=0A= * Description:=0A= * This function is triggered if the Tx Queue is stopped=0A= * for a pre-defined amount of time when the Interface is still up.=0A= * If the Interface is jammed in such a situation, the hardware is=0A= * reset (by s2io_close) and restarted again (by s2io_open) to=0A= * overcome any problem that might have been caused in the hardware.=0A= + * Return value:=0A= + * void=0A= */=0A= +=0A= static void s2io_tx_watchdog(struct net_device *dev)=0A= {=0A= nic_t *sp =3D dev->priv;=0A= @@ -3788,36 +4444,45 @@=0A= }=0A= }=0A= =0A= -/*=0A= - * Input Argument/s: =0A= - * sp - private member of the device structure, which is a pointer to = the =0A= - * s2io_nic structure.=0A= - * skb - the socket buffer pointer.=0A= - * len - length of the packet=0A= - * cksum - FCS checksum of the frame.=0A= - * ring_no - the ring from which this RxD was extracted.=0A= - * Return value:=0A= - * SUCCESS on success and -1 on failure.=0A= - * Description: =0A= - * This function is called by the Tx interrupt serivce routine to = perform =0A= +/**=0A= + * rx_osm_handler - To perform some OS related operations on SKB.=0A= + * @sp: private member of the device structure,pointer to s2io_nic = structure.=0A= + * @skb : the socket buffer pointer.=0A= + * @len : length of the packet=0A= + * @cksum : FCS checksum of the frame.=0A= + * @ring_no : the ring from which this RxD was extracted.=0A= + * Description: =0A= + * This function is called by the Tx interrupt serivce routine to = perform=0A= * some OS related operations on the SKB before passing it to the = upper=0A= * layers. It mainly checks if the checksum is OK, if so adds it to = the=0A= * SKBs cksum variable, increments the Rx packet count and passes the = SKB=0A= * to the upper layer. If the checksum is wrong, it increments the Rx=0A= * packet error count, frees the SKB and returns error.=0A= + * Return value:=0A= + * SUCCESS on success and -1 on failure.=0A= */=0A= -static int rxOsmHandler(nic_t * sp, u16 len, RxD_t * rxdp, int ring_no)=0A= +#ifndef CONFIG_2BUFF_MODE=0A= +static int rx_osm_handler(nic_t * sp, u16 len, RxD_t * rxdp, int = ring_no)=0A= +#else=0A= +static int rx_osm_handler(nic_t * sp, RxD_t * rxdp, int ring_no,=0A= + buffAdd_t * ba)=0A= +#endif=0A= {=0A= struct net_device *dev =3D (struct net_device *) sp->dev;=0A= struct sk_buff *skb =3D=0A= (struct sk_buff *) ((unsigned long) rxdp->Host_Control);=0A= u16 l3_csum, l4_csum;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + int buf0_len, buf2_len;=0A= + struct ethhdr *eth =3D (struct ethhdr *) ba->ba_0;=0A= +#endif=0A= =0A= l3_csum =3D RXD_GET_L3_CKSUM(rxdp->Control_1);=0A= if ((rxdp->Control_1 & TCP_OR_UDP_FRAME) && (sp->rx_csum)) {=0A= l4_csum =3D RXD_GET_L4_CKSUM(rxdp->Control_1);=0A= if ((l3_csum =3D=3D L3_CKSUM_OK) && (l4_csum =3D=3D L4_CKSUM_OK)) {=0A= - /* NIC verifies if the Checksum of the received=0A= + /* =0A= + * NIC verifies if the Checksum of the received=0A= * frame is Ok or not and accordingly returns=0A= * a flag in the RxD.=0A= */=0A= @@ -3833,9 +4498,37 @@=0A= skb->ip_summed =3D CHECKSUM_NONE;=0A= }=0A= =0A= + if (rxdp->Control_1 & RXD_T_CODE) {=0A= + unsigned long long err =3D rxdp->Control_1 & RXD_T_CODE;=0A= + DBG_PRINT(ERR_DBG, "%s: Rx error Value: 0x%llx\n",=0A= + dev->name, err);=0A= + }=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + buf0_len =3D RXD_GET_BUFFER0_SIZE(rxdp->Control_2);=0A= + buf2_len =3D RXD_GET_BUFFER2_SIZE(rxdp->Control_2);=0A= +#endif=0A= +=0A= skb->dev =3D dev;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= skb_put(skb, len);=0A= skb->protocol =3D eth_type_trans(skb, dev);=0A= +#else=0A= + skb_put(skb, buf2_len);=0A= + /* =0A= + * Reproducing eth_type_trans functionality and running=0A= + * on the ethernet header 'eth' stripped and given to us=0A= + * by the hardware in 2Buff mode.=0A= + */=0A= + if (*eth->h_dest & 1) {=0A= + if (!memcmp(eth->h_dest, dev->broadcast, ETH_ALEN))=0A= + skb->pkt_type =3D PACKET_BROADCAST;=0A= + else=0A= + skb->pkt_type =3D PACKET_MULTICAST;=0A= + } else if (memcmp(eth->h_dest, dev->dev_addr, ETH_ALEN)) {=0A= + skb->pkt_type =3D PACKET_OTHERHOST;=0A= + }=0A= + skb->protocol =3D eth->h_proto;=0A= +#endif=0A= =0A= #ifdef CONFIG_S2IO_NAPI=0A= netif_receive_skb(skb);=0A= @@ -3844,20 +4537,20 @@=0A= #endif=0A= =0A= dev->last_rx =3D jiffies;=0A= -#if DEBUG_ON=0A= - sp->rxpkt_cnt++;=0A= -#endif=0A= sp->rx_pkt_count++;=0A= sp->stats.rx_packets++;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= sp->stats.rx_bytes +=3D len;=0A= - sp->rxpkt_bytes +=3D len;=0A= +#else=0A= + sp->stats.rx_bytes +=3D buf0_len + buf2_len;=0A= +#endif=0A= =0A= atomic_dec(&sp->rx_bufs_left[ring_no]);=0A= rxdp->Host_Control =3D 0;=0A= return SUCCESS;=0A= }=0A= =0A= -int check_for_txSpace(nic_t * sp)=0A= +int check_for_tx_space(nic_t * sp)=0A= {=0A= u32 put_off, get_off, queue_len;=0A= int ret =3D TRUE, i;=0A= @@ -3876,18 +4569,19 @@=0A= return ret;=0A= }=0A= =0A= -/*=0A= -* Input Argument/s: =0A= -* sp - private member of the device structure, which is a pointer to = the =0A= -* s2io_nic structure.=0A= -* link - inidicates whether link is UP/DOWN.=0A= -* Return value:=0A= -* void.=0A= -* Description:=0A= -* This function stops/starts the Tx queue depending on whether the = link=0A= -* status of the NIC is is down or up. This is called by the Alarm = interrupt =0A= -* handler whenever a link change interrupt comes up. =0A= -*/=0A= +/**=0A= + * s2io_link - stops/starts the Tx queue.=0A= + * @sp : private member of the device structure, which is a pointer to = the=0A= + * s2io_nic structure.=0A= + * @link : inidicates whether link is UP/DOWN.=0A= + * Description:=0A= + * This function stops/starts the Tx queue depending on whether the = link=0A= + * status of the NIC is is down or up. This is called by the Alarm =0A= + * interrupt handler whenever a link change interrupt comes up. =0A= + * Return value:=0A= + * void.=0A= + */=0A= +=0A= void s2io_link(nic_t * sp, int link)=0A= {=0A= struct net_device *dev =3D (struct net_device *) sp->dev;=0A= @@ -3896,29 +4590,23 @@=0A= if (link =3D=3D LINK_DOWN) {=0A= DBG_PRINT(ERR_DBG, "%s: Link down\n", dev->name);=0A= netif_carrier_off(dev);=0A= - netif_stop_queue(dev);=0A= } else {=0A= DBG_PRINT(ERR_DBG, "%s: Link Up\n", dev->name);=0A= netif_carrier_on(dev);=0A= - if (check_for_txSpace(sp) =3D=3D TRUE) {=0A= - /* Don't wake the queue, if we know there=0A= - * are no free TxDs available.=0A= - */=0A= - netif_wake_queue(dev);=0A= - }=0A= }=0A= }=0A= sp->last_link_state =3D link;=0A= }=0A= =0A= -/*=0A= -* Input Argument/s: =0A= -* pdev - structure containing the PCI related information of the = device.=0A= -* Return value:=0A= -* returns the revision ID of the device.=0A= -* Description:=0A= -* Function to identify the Revision ID of xena.=0A= -*/=0A= +/**=0A= + * get_xena_rev_id - to identify revision ID of xena. =0A= + * @pdev : PCI Dev structure=0A= + * Description:=0A= + * Function to identify the Revision ID of xena.=0A= + * Return value:=0A= + * returns the revision ID of the device.=0A= + */=0A= +=0A= int get_xena_rev_id(struct pci_dev *pdev)=0A= {=0A= u8 id =3D 0;=0A= @@ -3927,21 +4615,22 @@=0A= return id;=0A= }=0A= =0A= -/*=0A= -* Input Argument/s: =0A= -* sp - private member of the device structure, which is a pointer to = the =0A= -* s2io_nic structure.=0A= -* Return value:=0A= -* void=0A= -* Description:=0A= -* This function initializes a few of the PCI and PCI-X configuration = registers=0A= -* with recommended values.=0A= -*/=0A= +/**=0A= + * s2io_init_pci -Initialization of PCI and PCI-X configuration = registers . =0A= + * @sp : private member of the device structure, which is a pointer to = the =0A= + * s2io_nic structure.=0A= + * Description:=0A= + * This function initializes a few of the PCI and PCI-X configuration = registers=0A= + * with recommended values.=0A= + * Return value:=0A= + * void=0A= + */=0A= +=0A= static void s2io_init_pci(nic_t * sp)=0A= {=0A= u16 pci_cmd =3D 0;=0A= =0A= -/* Enable Data Parity Error Recovery in PCI-X command register. */=0A= + /* Enable Data Parity Error Recovery in PCI-X command register. */=0A= pci_read_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= &(sp->pcix_cmd));=0A= pci_write_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= @@ -3949,13 +4638,13 @@=0A= pci_read_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= &(sp->pcix_cmd));=0A= =0A= -/* Set the PErr Response bit in PCI command register. */=0A= + /* Set the PErr Response bit in PCI command register. */=0A= pci_read_config_word(sp->pdev, PCI_COMMAND, &pci_cmd);=0A= pci_write_config_word(sp->pdev, PCI_COMMAND,=0A= (pci_cmd | PCI_COMMAND_PARITY));=0A= pci_read_config_word(sp->pdev, PCI_COMMAND, &pci_cmd);=0A= =0A= -/* Set user specified value in Latency Timer */=0A= + /* Set user specified value in Latency Timer */=0A= if (latency_timer) {=0A= pci_write_config_byte(sp->pdev, PCI_LATENCY_TIMER,=0A= latency_timer);=0A= @@ -3963,49 +4652,97 @@=0A= &latency_timer);=0A= }=0A= =0A= -/* Set MMRB count to 4096 in PCI-X Command register. */=0A= + /* Set MMRB count to 4096 in PCI-X Command register. */=0A= + sp->pcix_cmd &=3D 0xFFF3;=0A= pci_write_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= - (sp->pcix_cmd | 0x0C));=0A= + (sp->pcix_cmd | (max_read_byte_cnt << 2)));=0A= pci_read_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= &(sp->pcix_cmd));=0A= =0A= -/* Setting Maximum outstanding splits to two for now. */=0A= - sp->pcix_cmd &=3D 0xFF1F;=0A= + /* Setting Maximum outstanding splits based on system type. */=0A= + sp->pcix_cmd &=3D 0xFF8F;=0A= =0A= - sp->pcix_cmd |=3D=0A= - XENA_MAX_OUTSTANDING_SPLITS(XENA_TWO_SPLIT_TRANSACTION);=0A= + sp->pcix_cmd |=3D XENA_MAX_OUTSTANDING_SPLITS(max_splits_trans);=0A= + pci_write_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= + sp->pcix_cmd);=0A= + pci_read_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= + &(sp->pcix_cmd));=0A= + /* Forcibly disabling relaxed ordering capability of the card. */=0A= + sp->pcix_cmd &=3D 0xfffd;=0A= pci_write_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= sp->pcix_cmd);=0A= pci_read_config_word(sp->pdev, PCIX_COMMAND_REGISTER,=0A= &(sp->pcix_cmd));=0A= -=0A= }=0A= =0A= MODULE_AUTHOR("Raghavendra Koushik ");=0A= MODULE_LICENSE("GPL");=0A= -MODULE_PARM(ring_num, "1-" __MODULE_STRING(1) "i");=0A= -MODULE_PARM(frame_len, "1-" __MODULE_STRING(8) "i");=0A= -MODULE_PARM(ring_len, "1-" __MODULE_STRING(8) "i");=0A= -MODULE_PARM(fifo_num, "1-" __MODULE_STRING(1) "i");=0A= -MODULE_PARM(fifo_len, "1-" __MODULE_STRING(8) "i");=0A= -MODULE_PARM(rx_prio, "1-" __MODULE_STRING(1) "i");=0A= -MODULE_PARM(tx_prio, "1-" __MODULE_STRING(1) "i");=0A= -MODULE_PARM(latency_timer, "1-" __MODULE_STRING(1) "i");=0A= -=0A= -/*=0A= -* Input Argument/s: =0A= -* pdev - structure containing the PCI related information of the = device.=0A= -* pre - the List of PCI devices supported by the driver listed in = s2io_tbl.=0A= -* Return value:=0A= -* returns '0' on success and negative on failure.=0A= -* Description:=0A= -* The function initializes an adapter identified by the pci_dec = structure.=0A= -* All OS related initialization including memory and device structure = and =0A= -* initlaization of the device private variable is done. Also the = swapper =0A= -* control register is initialized to enable read and write into the = I/O =0A= -* registers of the device.=0A= -* =0A= -*/=0A= +MODULE_PARM(lso_enable, "i");=0A= +#ifndef CONFIG_S2IO_NAPI=0A= +MODULE_PARM(indicate_max_pkts, "i");=0A= +#endif=0A= +MODULE_PARM(cksum_offload_enable, "i");=0A= +MODULE_PARM(TxFifoNum, "i");=0A= +MODULE_PARM(TxFIFOLen_0, "i");=0A= +MODULE_PARM(TxFIFOLen_1, "i");=0A= +MODULE_PARM(TxFIFOLen_2, "i");=0A= +MODULE_PARM(TxFIFOLen_3, "i");=0A= +MODULE_PARM(TxFIFOLen_4, "i");=0A= +MODULE_PARM(TxFIFOLen_5, "i");=0A= +MODULE_PARM(TxFIFOLen_6, "i");=0A= +MODULE_PARM(TxFIFOLen_7, "i");=0A= +MODULE_PARM(MaxTxDs, "i");=0A= +MODULE_PARM(RxRingNum, "i");=0A= +MODULE_PARM(RxRingSz_0, "i");=0A= +MODULE_PARM(RxRingSz_1, "i");=0A= +MODULE_PARM(RxRingSz_2, "i");=0A= +MODULE_PARM(RxRingSz_3, "i");=0A= +MODULE_PARM(RxRingSz_4, "i");=0A= +MODULE_PARM(RxRingSz_5, "i");=0A= +MODULE_PARM(RxRingSz_6, "i");=0A= +MODULE_PARM(RxRingSz_7, "i");=0A= +MODULE_PARM(Stats_refresh_time, "i");=0A= +MODULE_PARM(rmac_pause_time, "i");=0A= +MODULE_PARM(mc_pause_threshold_q0q3, "i");=0A= +MODULE_PARM(mc_pause_threshold_q4q7, "i");=0A= +MODULE_PARM(shared_splits, "i");=0A= +MODULE_PARM(max_splits_trans, "i");=0A= +MODULE_PARM(tmac_util_period, "i");=0A= +MODULE_PARM(rmac_util_period, "i");=0A= +MODULE_PARM(tx_timer_val, "i");=0A= +MODULE_PARM(tx_utilz_periodic, "i");=0A= +MODULE_PARM(rx_timer_val, "i");=0A= +MODULE_PARM(rx_utilz_periodic, "i");=0A= +MODULE_PARM(tx_urange_a, "i");=0A= +MODULE_PARM(tx_ufc_a, "i");=0A= +MODULE_PARM(tx_urange_b, "i");=0A= +MODULE_PARM(tx_ufc_b, "i");=0A= +MODULE_PARM(tx_urange_c, "i");=0A= +MODULE_PARM(tx_ufc_c, "i");=0A= +MODULE_PARM(tx_ufc_d, "i");=0A= +MODULE_PARM(rx_urange_a, "i");=0A= +MODULE_PARM(rx_ufc_a, "i");=0A= +MODULE_PARM(rx_urange_b, "i");=0A= +MODULE_PARM(rx_ufc_b, "i");=0A= +MODULE_PARM(rx_urange_c, "i");=0A= +MODULE_PARM(rx_ufc_c, "i");=0A= +MODULE_PARM(rx_ufc_d, "i");=0A= +MODULE_PARM(latency_timer, "i");=0A= +MODULE_PARM(max_read_byte_cnt, "i");=0A= +/**=0A= + * s2io_init_nic - Initialization of the adapter . =0A= + * @pdev : structure containing the PCI related information of the = device.=0A= + * @pre: List of PCI devices supported by the driver listed in = s2io_tbl.=0A= + * Description:=0A= + * The function initializes an adapter identified by the pci_dec = structure.=0A= + * All OS related initialization including memory and device structure = and =0A= + * initlaization of the device private variable is done. Also the = swapper =0A= + * control register is initialized to enable read and write into the = I/O =0A= + * registers of the device.=0A= + * Return value:=0A= + * returns 0 on success and negative on failure.=0A= + */=0A= +=0A= static int __devinit=0A= s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)=0A= {=0A= @@ -4031,6 +4768,7 @@=0A= if (!pci_set_dma_mask(pdev, 0xffffffffffffffffULL)) {=0A= DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 64bit DMA\n");=0A= dma_flag =3D TRUE;=0A= +=0A= if (pci_set_consistent_dma_mask=0A= (pdev, 0xffffffffffffffffULL)) {=0A= DBG_PRINT(ERR_DBG,=0A= @@ -4080,7 +4818,8 @@=0A= /* Initialize some PCI/PCI-X fields of the NIC. */=0A= s2io_init_pci(sp);=0A= =0A= - /* Setting the device configuration parameters.=0A= + /* =0A= + * Setting the device configuration parameters.=0A= * Most of these parameters can be specified by the user during =0A= * module insertion as they are module loadable parameters. If =0A= * these parameters are not not specified during load time, they =0A= @@ -4090,69 +4829,63 @@=0A= config =3D &sp->config;=0A= =0A= /* Tx side parameters. */=0A= - config->TxFIFONum =3D fifo_num ? fifo_num : 1;=0A= -=0A= - if (!fifo_len[0] && (fifo_num > 1)) {=0A= - printk(KERN_ERR "Fifo Lens not specified for all FIFOs\n");=0A= - goto init_failed;=0A= - }=0A= -=0A= - if (fifo_len[0]) {=0A= - int cnt;=0A= -=0A= - for (cnt =3D 0; fifo_len[cnt]; cnt++);=0A= - if (fifo_num) {=0A= - if (cnt < fifo_num) {=0A= - printk(KERN_ERR=0A= - "Fifo Lens not specified for ");=0A= - printk(KERN_ERR "all FIFOs\n");=0A= - goto init_failed;=0A= - }=0A= - }=0A= - for (cnt =3D 0; cnt < config->TxFIFONum; cnt++) {=0A= - config->TxCfg[cnt].FifoLen =3D fifo_len[cnt];=0A= - config->TxCfg[cnt].FifoPriority =3D cnt;=0A= - }=0A= - } else {=0A= - config->TxCfg[0].FifoLen =3D DEFAULT_FIFO_LEN;=0A= - config->TxCfg[0].FifoPriority =3D 0;=0A= - }=0A= + config->TxFIFONum =3D TxFifoNum;=0A= + config->tx_cfg[0].FifoLen =3D TxFIFOLen_0;=0A= + config->tx_cfg[0].FifoPriority =3D 0;=0A= + config->tx_cfg[1].FifoLen =3D TxFIFOLen_1;=0A= + config->tx_cfg[1].FifoPriority =3D 1;=0A= + config->tx_cfg[2].FifoLen =3D TxFIFOLen_2;=0A= + config->tx_cfg[2].FifoPriority =3D 2;=0A= + config->tx_cfg[3].FifoLen =3D TxFIFOLen_3;=0A= + config->tx_cfg[3].FifoPriority =3D 3;=0A= + config->tx_cfg[4].FifoLen =3D TxFIFOLen_4;=0A= + config->tx_cfg[4].FifoPriority =3D 4;=0A= + config->tx_cfg[5].FifoLen =3D TxFIFOLen_5;=0A= + config->tx_cfg[5].FifoPriority =3D 5;=0A= + config->tx_cfg[6].FifoLen =3D TxFIFOLen_6;=0A= + config->tx_cfg[6].FifoPriority =3D 6;=0A= + config->tx_cfg[7].FifoLen =3D TxFIFOLen_7;=0A= + config->tx_cfg[7].FifoPriority =3D 7;=0A= =0A= config->TxIntrType =3D TXD_INT_TYPE_UTILZ;=0A= for (i =3D 0; i < config->TxFIFONum; i++) {=0A= - if (config->TxCfg[i].FifoLen < 65) {=0A= + config->tx_cfg[i].fNoSnoop =3D=0A= + (NO_SNOOP_TXD | NO_SNOOP_TXD_BUFFER);=0A= + if (config->tx_cfg[i].FifoLen < 65) {=0A= config->TxIntrType =3D TXD_INT_TYPE_PER_LIST;=0A= break;=0A= }=0A= }=0A= -=0A= - config->TxCfg[0].fNoSnoop =3D (NO_SNOOP_TXD | NO_SNOOP_TXD_BUFFER);=0A= config->MaxTxDs =3D MAX_SKB_FRAGS;=0A= config->TxFlow =3D TRUE;=0A= =0A= /* Rx side parameters. */=0A= - config->RxRingNum =3D ring_num ? ring_num : 1;=0A= -=0A= - if (ring_len[0]) {=0A= - int cnt;=0A= - for (cnt =3D 0; cnt < config->RxRingNum; cnt++) {=0A= - config->RxCfg[cnt].NumRxd =3D ring_len[cnt];=0A= - config->RxCfg[cnt].RingPriority =3D cnt;=0A= - }=0A= - } else {=0A= - int id;=0A= - if ((id =3D get_xena_rev_id(pdev)) =3D=3D 1) {=0A= - config->RxCfg[0].NumRxd =3D LARGE_RXD_CNT;=0A= -=0A= - } else {=0A= - config->RxCfg[0].NumRxd =3D SMALL_RXD_CNT;=0A= - }=0A= - config->RxCfg[0].RingPriority =3D 0;=0A= + config->RxRingNum =3D RxRingNum;=0A= + config->rx_cfg[0].NumRxd =3D RxRingSz_0 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[0].RingPriority =3D 0;=0A= + config->rx_cfg[1].NumRxd =3D RxRingSz_1 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[1].RingPriority =3D 1;=0A= + config->rx_cfg[2].NumRxd =3D RxRingSz_2 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[2].RingPriority =3D 2;=0A= + config->rx_cfg[3].NumRxd =3D RxRingSz_3 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[3].RingPriority =3D 3;=0A= + config->rx_cfg[4].NumRxd =3D RxRingSz_4 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[4].RingPriority =3D 4;=0A= + config->rx_cfg[5].NumRxd =3D RxRingSz_5 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[5].RingPriority =3D 5;=0A= + config->rx_cfg[6].NumRxd =3D RxRingSz_6 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[6].RingPriority =3D 6;=0A= + config->rx_cfg[7].NumRxd =3D RxRingSz_7 * (MAX_RXDS_PER_BLOCK + 1);=0A= + config->rx_cfg[7].RingPriority =3D 7;=0A= +=0A= + for (i =3D 0; i < RxRingNum; i++) {=0A= + config->rx_cfg[i].RingOrg =3D RING_ORG_BUFF1;=0A= + config->rx_cfg[i].RxdThresh =3D DEFAULT_RXD_THRESHOLD;=0A= + config->rx_cfg[i].fNoSnoop =3D=0A= + (NO_SNOOP_RXD | NO_SNOOP_RXD_BUFFER);=0A= + config->rx_cfg[i].RxD_BackOff_Interval =3D TBD;=0A= }=0A= - config->RxCfg[0].RingOrg =3D RING_ORG_BUFF1;=0A= - config->RxCfg[0].RxdThresh =3D DEFAULT_RXD_THRESHOLD;=0A= - config->RxCfg[0].fNoSnoop =3D (NO_SNOOP_RXD | NO_SNOOP_RXD_BUFFER);=0A= - config->RxCfg[0].RxD_BackOff_Interval =3D TBD;=0A= +=0A= config->RxFlow =3D TRUE;=0A= =0A= /* Miscellaneous parameters. */=0A= @@ -4162,14 +4895,17 @@=0A= =0A= /* Setting Mac Control parameters */=0A= mac_control->txdl_len =3D MAX_SKB_FRAGS;=0A= - mac_control->rmac_pause_time =3D 0;=0A= + mac_control->rmac_pause_time =3D rmac_pause_time;=0A= + mac_control->mc_pause_threshold_q0q3 =3D mc_pause_threshold_q0q3;=0A= + mac_control->mc_pause_threshold_q4q7 =3D mc_pause_threshold_q4q7;=0A= +=0A= =0A= /* Initialize Ring buffer parameters. */=0A= for (i =3D 0; i < config->RxRingNum; i++)=0A= atomic_set(&sp->rx_bufs_left[i], 0);=0A= =0A= /* initialize the shared memory used by the NIC and the host */=0A= - if (initSharedMem(sp)) {=0A= + if (init_shared_mem(sp)) {=0A= DBG_PRINT(ERR_DBG, "%s: Memory allocation failed\n",=0A= dev->name);=0A= goto mem_alloc_failed;=0A= @@ -4208,22 +4944,26 @@=0A= dev->set_multicast_list =3D &s2io_set_multicast;=0A= dev->do_ioctl =3D &s2io_ioctl;=0A= dev->change_mtu =3D &s2io_change_mtu;=0A= +#ifdef SET_ETHTOOL_OPS=0A= SET_ETHTOOL_OPS(dev, &netdev_ethtool_ops);=0A= -=0A= +#endif=0A= /*=0A= * will use eth_mac_addr() for dev->set_mac_address=0A= * mac address will be set every time dev->open() is called=0A= */=0A= #ifdef CONFIG_S2IO_NAPI=0A= dev->poll =3D s2io_poll;=0A= - dev->weight =3D 128; /* For now. */=0A= + dev->weight =3D 90; /* For now. */=0A= #endif=0A= =0A= - dev->features |=3D NETIF_F_SG | NETIF_F_IP_CSUM;=0A= + dev->features |=3D NETIF_F_SG;=0A= + if (cksum_offload_enable)=0A= + dev->features |=3D NETIF_F_IP_CSUM;=0A= if (sp->high_dma_flag =3D=3D TRUE)=0A= dev->features |=3D NETIF_F_HIGHDMA;=0A= #ifdef NETIF_F_TSO=0A= - dev->features |=3D NETIF_F_TSO;=0A= + if (lso_enable)=0A= + dev->features |=3D NETIF_F_TSO;=0A= #endif=0A= =0A= dev->tx_timeout =3D &s2io_tx_watchdog;=0A= @@ -4233,11 +4973,6 @@=0A= INIT_WORK(&sp->set_link_task,=0A= (void (*)(void *)) s2io_set_link, sp);=0A= =0A= - if (register_netdev(dev)) {=0A= - DBG_PRINT(ERR_DBG, "Device registration failed\n");=0A= - goto register_failed;=0A= - }=0A= -=0A= pci_save_state(sp->pdev, sp->config_space);=0A= =0A= /* Setting swapper control on the NIC, for proper reset operation */=0A= @@ -4248,10 +4983,11 @@=0A= }=0A= =0A= /* Fix for all "FFs" MAC address problems observed on Alpha platforms = */=0A= - FixMacAddress(sp);=0A= + fix_mac_address(sp);=0A= s2io_reset(sp);=0A= =0A= - /* Setting swapper control on the NIC, so the MAC address can be read.=0A= + /*=0A= + * Setting swapper control on the NIC, so the MAC address can be read.=0A= */=0A= if (s2io_set_swapper(sp)) {=0A= DBG_PRINT(ERR_DBG,=0A= @@ -4260,50 +4996,54 @@=0A= goto set_swap_failed;=0A= }=0A= =0A= - /* MAC address initialization.=0A= - * For now only one mac address will be read and used.=0A= + /* =0A= + * MAC address initialization.=0A= + * For now only one mac address will be read and used.=0A= */=0A= bar0 =3D (XENA_dev_config_t *) sp->bar0;=0A= val64 =3D RMAC_ADDR_CMD_MEM_RD | RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |=0A= RMAC_ADDR_CMD_MEM_OFFSET(0 + MAC_MAC_ADDR_START_OFFSET);=0A= writeq(val64, &bar0->rmac_addr_cmd_mem);=0A= - waitForCmdComplete(sp);=0A= + wait_for_cmd_complete(sp);=0A= =0A= tmp64 =3D readq(&bar0->rmac_addr_data0_mem);=0A= mac_down =3D (u32) tmp64;=0A= mac_up =3D (u32) (tmp64 >> 32);=0A= =0A= - memset(sp->defMacAddr[0].mac_addr, 0, sizeof(ETH_ALEN));=0A= + memset(sp->def_mac_addr[0].mac_addr, 0, sizeof(ETH_ALEN));=0A= =0A= - sp->defMacAddr[0].mac_addr[3] =3D (u8) (mac_up);=0A= - sp->defMacAddr[0].mac_addr[2] =3D (u8) (mac_up >> 8);=0A= - sp->defMacAddr[0].mac_addr[1] =3D (u8) (mac_up >> 16);=0A= - sp->defMacAddr[0].mac_addr[0] =3D (u8) (mac_up >> 24);=0A= - sp->defMacAddr[0].mac_addr[5] =3D (u8) (mac_down >> 16);=0A= - sp->defMacAddr[0].mac_addr[4] =3D (u8) (mac_down >> 24);=0A= + sp->def_mac_addr[0].mac_addr[3] =3D (u8) (mac_up);=0A= + sp->def_mac_addr[0].mac_addr[2] =3D (u8) (mac_up >> 8);=0A= + sp->def_mac_addr[0].mac_addr[1] =3D (u8) (mac_up >> 16);=0A= + sp->def_mac_addr[0].mac_addr[0] =3D (u8) (mac_up >> 24);=0A= + sp->def_mac_addr[0].mac_addr[5] =3D (u8) (mac_down >> 16);=0A= + sp->def_mac_addr[0].mac_addr[4] =3D (u8) (mac_down >> 24);=0A= =0A= DBG_PRINT(INIT_DBG,=0A= "DEFAULT MAC ADDR:0x%02x-%02x-%02x-%02x-%02x-%02x\n",=0A= - sp->defMacAddr[0].mac_addr[0],=0A= - sp->defMacAddr[0].mac_addr[1],=0A= - sp->defMacAddr[0].mac_addr[2],=0A= - sp->defMacAddr[0].mac_addr[3],=0A= - sp->defMacAddr[0].mac_addr[4],=0A= - sp->defMacAddr[0].mac_addr[5]);=0A= + sp->def_mac_addr[0].mac_addr[0],=0A= + sp->def_mac_addr[0].mac_addr[1],=0A= + sp->def_mac_addr[0].mac_addr[2],=0A= + sp->def_mac_addr[0].mac_addr[3],=0A= + sp->def_mac_addr[0].mac_addr[4],=0A= + sp->def_mac_addr[0].mac_addr[5]);=0A= =0A= /* Set the factory defined MAC address initially */=0A= dev->addr_len =3D ETH_ALEN;=0A= - memcpy(dev->dev_addr, sp->defMacAddr, ETH_ALEN);=0A= + memcpy(dev->dev_addr, sp->def_mac_addr, ETH_ALEN);=0A= =0A= /* Initialize the tasklet status flag */=0A= atomic_set(&(sp->tasklet_status), 0);=0A= =0A= =0A= /* Initialize spinlocks */=0A= - spin_lock_init(&sp->isr_lock);=0A= spin_lock_init(&sp->tx_lock);=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spin_lock_init(&sp->put_lock);=0A= +#endif=0A= =0A= - /* SXE-002: Configure link and activity LED to init state =0A= + /* =0A= + * SXE-002: Configure link and activity LED to init state =0A= * on driver load. =0A= */=0A= subid =3D sp->pdev->subsystem_device;=0A= @@ -4316,27 +5056,47 @@=0A= val64 =3D readq(&bar0->gpio_control);=0A= }=0A= =0A= - /* Make Link state as off at this point, when the Link change =0A= + sp->rx_csum =3D 1; /* Rx chksum verify enabled by default */=0A= +=0A= +#ifdef SNMP_SUPPORT=0A= + if (!s2io_bdsnmp_init(dev))=0A= + DBG_PRINT(INIT_DBG,=0A= + "Error Creating Proc directory for SNMP\n");=0A= +=0A= + sp->nLinkStatus =3D 1;=0A= +#ifdef NETIF_F_TSO=0A= + sp->nFeature =3D 1;=0A= +#endif=0A= + memcpy(sp->cVersion, s2io_driver_version + 8, 20);=0A= + memcpy(sp->cName, s2io_driver_name, 20);=0A= + struct timeval tm;=0A= + do_gettimeofday(&tm);=0A= + sp->lDate =3D tm.tv_sec;=0A= +#endif=0A= +=0A= + if (register_netdev(dev)) {=0A= + DBG_PRINT(ERR_DBG, "Device registration failed\n");=0A= + goto register_failed;=0A= + }=0A= +=0A= + /* =0A= + * Make Link state as off at this point, when the Link change =0A= * interrupt comes the state will be automatically changed to =0A= * the right state.=0A= */=0A= netif_carrier_off(dev);=0A= sp->last_link_state =3D LINK_DOWN;=0A= =0A= - sp->rx_csum =3D 1; /* Rx chksum verify enabled by default */=0A= -=0A= return 0;=0A= =0A= - set_swap_failed:=0A= - unregister_netdev(dev);=0A= register_failed:=0A= + set_swap_failed:=0A= iounmap(sp->bar1);=0A= bar1_remap_failed:=0A= iounmap(sp->bar0);=0A= bar0_remap_failed:=0A= mem_alloc_failed:=0A= - freeSharedMem(sp);=0A= - init_failed:=0A= + free_shared_mem(sp);=0A= pci_disable_device(pdev);=0A= pci_release_regions(pdev);=0A= pci_set_drvdata(pdev, NULL);=0A= @@ -4345,16 +5105,15 @@=0A= return -ENODEV;=0A= }=0A= =0A= -/*=0A= -* Input Argument/s: =0A= -* pdev - structure containing the PCI related information of the = device.=0A= -* Return value:=0A= -* void=0A= -* Description:=0A= -* This function is called by the Pci subsystem to release a PCI device =0A= -* and free up all resource held up by the device. This could be in = response =0A= -* to a Hot plug event or when the driver is to be removed from memory.=0A= -*/=0A= +/**=0A= + * s2io_rem_nic - Free the PCI device =0A= + * @pdev: structure containing the PCI related information of the = device.=0A= + * Description: This function is called by the Pci subsystem to release = a =0A= + * PCI device and free up all resource held up by the device. This could=0A= + * be in response to a Hot plug event or when the driver is to be = removed =0A= + * from memory.=0A= + */=0A= +=0A= static void __devexit s2io_rem_nic(struct pci_dev *pdev)=0A= {=0A= struct net_device *dev =3D=0A= @@ -4365,24 +5124,41 @@=0A= DBG_PRINT(ERR_DBG, "Driver Data is NULL!!\n");=0A= return;=0A= }=0A= +=0A= sp =3D dev->priv;=0A= - freeSharedMem(sp);=0A= + unregister_netdev(dev);=0A= +=0A= + free_shared_mem(sp);=0A= iounmap(sp->bar0);=0A= iounmap(sp->bar1);=0A= pci_disable_device(pdev);=0A= pci_release_regions(pdev);=0A= pci_set_drvdata(pdev, NULL);=0A= -=0A= - unregister_netdev(dev);=0A= +#ifdef SNMP_SUPPORT=0A= + s2io_bdsnmp_rem(dev);=0A= +#endif=0A= =0A= free_netdev(dev);=0A= }=0A= =0A= +/**=0A= + * s2io_starter - Entry point for the driver=0A= + * Description: This function is the entry point for the driver. It = verifies=0A= + * the module loadable parameters and initializes PCI configuration = space.=0A= + */=0A= +=0A= int __init s2io_starter(void)=0A= {=0A= + if (verify_load_parm())=0A= + return -ENODEV;=0A= return pci_module_init(&s2io_driver);=0A= }=0A= =0A= +/**=0A= + * s2io_closer - Cleanup routine for the driver =0A= + * Description: This function is the cleanup routine for the driver. It = unregist * ers the driver.=0A= + */=0A= +=0A= void s2io_closer(void)=0A= {=0A= pci_unregister_driver(&s2io_driver);=0A= @@ -4391,3 +5167,571 @@=0A= =0A= module_init(s2io_starter);=0A= module_exit(s2io_closer);=0A= +/**=0A= + * verify_load_parm - verifies the module loadable parameters=0A= + * Descriptions: Verifies the module loadable paramters and initializes = the=0A= + * Tx Fifo, Rx Ring and other paramters.=0A= + */=0A= +=0A= +int verify_load_parm()=0A= +{=0A= + int fail =3D 0;=0A= + if (!((lso_enable =3D=3D 0) || (lso_enable =3D=3D 1))) {=0A= + printk("lso_enable can be either '1' or '0'\n");=0A= + fail =3D 1;=0A= + }=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + if ((indicate_max_pkts > (0xFFFFFFFF))) {=0A= + printk=0A= + ("indicate_max_pkts can take value greater than zero but less = than 2power(32)\n");=0A= + fail =3D 1;=0A= + }=0A= +#endif=0A= + if (!((cksum_offload_enable =3D=3D 0) || (cksum_offload_enable =3D=3D = 1))) {=0A= + printk("cksum_offload_enable can be only '0' or '1' \n");=0A= + fail =3D 1;=0A= + }=0A= + if ((TxFifoNum =3D=3D 0) || (TxFifoNum > 8)) {=0A= + printk("TxFifoNum can take value from 1 to 8\n");=0A= + fail =3D 1;=0A= + }=0A= + switch (TxFifoNum) {=0A= + case 8:=0A= + if ((TxFIFOLen_7 =3D=3D 0) || TxFIFOLen_7 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_7 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 7:=0A= + if ((TxFIFOLen_6 =3D=3D 0) || TxFIFOLen_6 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_6 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 6:=0A= + if ((TxFIFOLen_5 =3D=3D 0) || TxFIFOLen_5 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_5 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 5:=0A= + if ((TxFIFOLen_4 =3D=3D 0) || TxFIFOLen_4 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_4 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 4:=0A= + if ((TxFIFOLen_3 =3D=3D 0) || TxFIFOLen_3 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_3 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 3:=0A= + if ((TxFIFOLen_2 =3D=3D 0) || TxFIFOLen_2 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_2 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 2:=0A= + if ((TxFIFOLen_1 =3D=3D 0) || TxFIFOLen_1 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_1 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + case 1:=0A= + if ((TxFIFOLen_0 =3D=3D 0) || TxFIFOLen_0 > 8192) {=0A= + printk=0A= + ("TxFIFOLen_0 can take value from 1 to 8192\n");=0A= + fail =3D 1;=0A= + }=0A= + }=0A= + if ((MaxTxDs > 32) || (MaxTxDs < 1)) {=0A= + printk("MaxTxDs can take falue from 1 to 32\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((RxRingNum > 8) || (RxRingNum < 1)) {=0A= + printk("RxRingNum can take falue from 1 to 8\n");=0A= + fail =3D 1;=0A= + }=0A= + switch (RxRingNum) {=0A= + case 8:=0A= + if (RxRingSz_7 < 1) {=0A= + printk=0A= + ("RxRingSz_7 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 7:=0A= + if (RxRingSz_6 < 1) {=0A= + printk=0A= + ("RxRingSz_6 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 6:=0A= + if (RxRingSz_5 < 1) {=0A= + printk=0A= + ("RxRingSz_5 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 5:=0A= + if (RxRingSz_4 < 1) {=0A= + printk=0A= + ("RxRingSz_4 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 4:=0A= + if (RxRingSz_3 < 1) {=0A= + printk=0A= + ("RxRingSz_3 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 3:=0A= + if (RxRingSz_2 < 1) {=0A= + printk=0A= + ("RxRingSz_2 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 2:=0A= + if (RxRingSz_1 < 1) {=0A= + printk=0A= + ("RxRingSz_1 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + case 1:=0A= + if (RxRingSz_0 < 1) {=0A= + printk=0A= + ("RxRingSz_0 can take value greater than 0\n");=0A= + fail =3D 1;=0A= + }=0A= + }=0A= + if ((Stats_refresh_time < 1)) {=0A= + printk=0A= + ("Stats_refresh_time cannot be less than 1 second \n");=0A= + fail =3D 1;=0A= + }=0A= + if (((rmac_pause_time < 0x10) && (rmac_pause_time !=3D 0)) ||=0A= + (rmac_pause_time > 0xFFFF)) {=0A= + printk=0A= + ("rmac_pause_time can take value from 16 to 65535\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((max_splits_trans < 0) || (max_splits_trans > 7)) {=0A= + printk("max_splits_trans can take value from 0 to 7\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((mc_pause_threshold_q0q3 > 0xFE)) {=0A= + printk("mc_pause_threshold_q0q3 cannot exceed 254\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((mc_pause_threshold_q4q7 > 0xFE)) {=0A= + printk("mc_pause_threshold_q4q7 cannot exceed 254\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((latency_timer)=0A= + && ((latency_timer < 8) || (latency_timer > 255))) {=0A= + printk("latency_timer can take value from 8 to 255\n");=0A= + fail =3D 1;=0A= + }=0A= + if (max_read_byte_cnt > 3) {=0A= + printk("max_read_byte_cnt can take value from 0 to 3\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((shared_splits > 31)) {=0A= + printk("shared_splits cannot exceed 31\n");=0A= + fail =3D 1;=0A= + }=0A= + if (rmac_util_period > 0xF) {=0A= + printk("rmac_util_period cannot exceed 15\n");=0A= + fail =3D 1;=0A= + }=0A= + if (tmac_util_period > 0xF) {=0A= + printk("tmac_util_period cannot exceed 15\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((tx_utilz_periodic > 1) || (rx_utilz_periodic > 1)) {=0A= + printk=0A= + ("tx_utilz_periodic & rx_utilz_periodic can be either "=0A= + "'0' or '1'\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((tx_urange_a > 127) || (tx_urange_b > 127)=0A= + || (tx_urange_c > 127)) {=0A= + printk=0A= + ("tx_urange_a, tx_urange_b & tx_urange_c can take value "=0A= + "from 0 to 127\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((rx_urange_a > 127) || (rx_urange_b > 127)=0A= + || (rx_urange_c > 127)) {=0A= + printk=0A= + ("rx_urange_a, rx_urange_b & rx_urange_c can take value "=0A= + "from 0 to 127\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((tx_ufc_a > 0xffff) || (tx_ufc_b > 0xffff) ||=0A= + (tx_ufc_c > 0xffff) || (tx_ufc_d > 0xffff)) {=0A= + printk=0A= + (" tx_ufc_a, tx_ufc_b, tx_ufc_c, tx_ufc_d can take value"=0A= + "from 0 to 65535(0xFFFF)\n");=0A= + fail =3D 1;=0A= + }=0A= + if ((rx_ufc_a > 0xffff) || (rx_ufc_b > 0xffff) ||=0A= + (rx_ufc_c > 0xffff) || (rx_ufc_d > 0xffff)) {=0A= + printk=0A= + (" rx_ufc_a, rx_ufc_b, rx_ufc_c, rx_ufc_d can take value"=0A= + "from 0 to 65535(0xFFFF)\n");=0A= + fail =3D 1;=0A= + }=0A= + return fail;=0A= +}=0A= +=0A= +#ifdef SNMP_SUPPORT=0A= +/**=0A= + * fnBaseDrv - Get the driver information=0A= + * @pBaseDrv -Pointer to Base driver structure which contains the = offset =0A= + * and length of each of the field.=0A= + * Description=0A= + * This function copies the driver specific information from the dev = structure=0A= + * to the pBaseDrv stucture. It calculates the number of physical = adapters by=0A= + * parsing the dev_base global variable maintained by the kernel. This =0A= + * variable has to read locked before accesing.This function is called = by=0A= + * fnBaseReadProc function.=0A= + *=0A= + */=0A= +=0A= +static void fnBaseDrv(struct stBaseDrv *pBaseDrv, struct net_device = *dev)=0A= +{=0A= +=0A= + struct pci_dev *pdev =3D NULL;=0A= + struct net_device *ndev;=0A= + int nCount =3D 0;=0A= + nic_t *sp =3D (nic_t *) dev->priv;=0A= +=0A= + strncpy(pBaseDrv->m_cName, sp->cName, 20);=0A= + strncpy(pBaseDrv->m_cVersion, sp->cVersion, 20);=0A= + pBaseDrv->m_nStatus =3D sp->nLinkStatus;=0A= + pBaseDrv->m_nFeature =3D sp->nFeature;=0A= + pBaseDrv->m_nMemorySize =3D sp->nMemorySize;=0A= + sprintf(pBaseDrv->m_cDate, "%ld", sp->lDate);=0A= + /* =0A= + * Find all the ethernet devices on the system using =0A= + * pci_find_class. Get the private data which will be the =0A= + * net_device structure assigned by the driver.=0A= + */=0A= + while ((pdev =3D=0A= + pci_find_class((PCI_CLASS_NETWORK_ETHERNET << 8), pdev))) {=0A= + ndev =3D (struct net_device *) pci_get_drvdata(pdev);=0A= + if (ndev =3D=3D NULL)=0A= + break;=0A= + memcpy(pBaseDrv->m_stPhyAdap[nCount].m_cName, ndev->name,=0A= + 20);=0A= + pBaseDrv->m_stPhyAdap[nCount].m_nIndex =3D ndev->ifindex;=0A= + nCount++;=0A= + }=0A= + pBaseDrv->m_nPhyCnt =3D nCount;=0A= +}=0A= +=0A= +/* =0A= + * fnBaseReadProc - Read entry point for the proc file =0A= + * @page - Buffer pointer where the data is written=0A= + * @start- Pointer to buffer ptr . It is used if the data is more than = a page=0A= + * @off- the offset to the page where data is written=0A= + * @count - number of bytes to write=0A= + * @eof - to indicate end of file=0A= + * @data - pointer to device structure.=0A= + *=0A= + * Description - =0A= + * This function gets Base driver specific information from the = fnBaseDrv =0A= + * function and writes into the BDInfo file. This function is called = whenever =0A= + * the user reads the file. The length of data written cannot exceed = 4kb. =0A= + * If it exceeds then use the start pointer to write multiple pages=0A= + * Return - the length of the string written to proc file=0A= + */=0A= +static int fnBaseReadProc(char *page, char **start, off_t off, int = count,=0A= + int *eof, void *data)=0A= +{=0A= + struct stBaseDrv *pBaseDrv;=0A= + int nLength =3D 0;=0A= + int nCount =3D 0;=0A= + struct net_device *dev =3D (struct net_device *) data;=0A= + int nIndex =3D 0;=0A= +=0A= + pBaseDrv =3D kmalloc(sizeof(struct stBaseDrv), GFP_KERNEL);=0A= + if (pBaseDrv =3D=3D NULL) {=0A= + printk("Error allocating memory\n");=0A= + return -ENOMEM;=0A= + }=0A= + fnBaseDrv(pBaseDrv, dev);=0A= + sprintf(page + nLength, "%-30s%-20s\n", "Base Driver Name",=0A= + pBaseDrv->m_cName);=0A= + nLength +=3D 51;=0A= + if (pBaseDrv->m_nStatus =3D=3D 1)=0A= + sprintf(page + nLength, "%-30s%-20s\n", "Load Status",=0A= + "Loaded");=0A= + else=0A= + sprintf(page + nLength, "%-30s%-20s\n", "Load Status",=0A= + "UnLoaded");=0A= + nLength +=3D 51;=0A= + sprintf(page + nLength, "%-30s%-20s\n", "Base Driver Version",=0A= + pBaseDrv->m_cVersion);=0A= + nLength +=3D 51;=0A= +=0A= + sprintf(page + nLength, "%-30s%-20d\n", "Feature Supported",=0A= + pBaseDrv->m_nFeature);=0A= + nLength +=3D 51;=0A= +=0A= + sprintf(page + nLength, "%-30s%-20d\n",=0A= + "Base Driver Memrory in Bytes", pBaseDrv->m_nMemorySize);=0A= + nLength +=3D 51;=0A= +=0A= + sprintf(page + nLength, "%-30s%-20s\n", "Base Driver Date",=0A= + pBaseDrv->m_cDate);=0A= + nLength +=3D 51;=0A= +=0A= + sprintf(page + nLength, "%-30s%-20d\n", "No of Phy Adapter",=0A= + pBaseDrv->m_nPhyCnt);=0A= + nLength +=3D 51;=0A= + sprintf(page + nLength, "%-20s%-20s\n\n", "Phy Adapter Index",=0A= + "Phy Adapter Name");=0A= + nLength +=3D 42;=0A= +=0A= + for (nIndex =3D 0, nCount =3D pBaseDrv->m_nPhyCnt; nCount !=3D 0;=0A= + nCount--, nIndex++) {=0A= + sprintf(page + nLength, "%-20d%-20s\n",=0A= + pBaseDrv->m_stPhyAdap[nIndex].m_nIndex,=0A= + pBaseDrv->m_stPhyAdap[nIndex].m_cName);=0A= + nLength +=3D 41;=0A= + }=0A= +=0A= + *eof =3D 1;=0A= + kfree(pBaseDrv);=0A= + return nLength;=0A= +}=0A= +=0A= +/* =0A= + * fnPhyAdapReadProc - Read entry point for the proc file =0A= + * @page - Buffer pointer where the data is written=0A= + * @start- Pointer to buffer ptr . It is used if the data is more than = a page=0A= + * @off- the offset to the page where data is written=0A= + * @count - number of bytes to write=0A= + * @eof - to indicate end of file=0A= + * @data - pointer to device structure.=0A= + *=0A= + * Description - =0A= + * This function gets physical adapter information. This function is = called=0A= + * whenever the use* r reads the file. The length of data written cannot=0A= + * exceed 4kb. If it exceeds then use the start pointer to write = multiple page =0A= + *=0A= + * Return - the length of the string written to proc file=0A= + */=0A= +static int fnPhyAdapReadProc(char *page, char **start, off_t off,=0A= + int count, int *eof, void *data)=0A= +{=0A= +=0A= + struct stPhyData *pPhyData;=0A= + pPhyData =3D kmalloc(sizeof(struct stPhyData), GFP_KERNEL);=0A= + if (pPhyData =3D=3D NULL) {=0A= + printk("Error allocating memory\n");=0A= + return -ENOMEM;=0A= + }=0A= +=0A= + struct net_device *pNetDev;=0A= + struct net_device_stats *pNetStat;=0A= + int nLength =3D 0;=0A= + unsigned char cMAC[20];=0A= +=0A= + /* Print the header in the PhyAdap proc file */=0A= + sprintf(page + nLength,=0A= + = "%-10s%-22s%-10s%-10s%-22s%-22s%-10s%-10s%-10s%-10s%-10s%-10s%-10s%-10s%-= 10s%-10s%-10s%-10s%-10s%-10s\n",=0A= + "Index", "Description", "Mode", "Type", "Speed", "MAC",=0A= + "Status", "Slot", "Bus", "IRQ", "Colis", "Multi",=0A= + "RxBytes", "RxDrop", "RxError", "RxPacket", "TRxBytes",=0A= + "TRxDrop", "TxError", "TxPacket");=0A= +=0A= + /* 237 is the lenght of the above string copied in the page */=0A= + nLength +=3D 237;=0A= +=0A= + struct pci_dev *pdev =3D NULL;=0A= + /* =0A= + * pci_find_class will return to the pointer to the pdev structure=0A= + * for all the network devices using PCI_CLASS_NETWORK_ETHERNET.=0A= + * The third argument is pointer to previous pdev structure.Initailly=0A= + * it has to be null=0A= + */=0A= + while ((pdev =3D=0A= + pci_find_class((PCI_CLASS_NETWORK_ETHERNET << 8), pdev))) {=0A= + /* Private data will point to the netdevice structure */=0A= + pNetDev =3D (struct net_device *) pci_get_drvdata(pdev);=0A= + if (pNetDev =3D=3D NULL)=0A= + continue;=0A= + if (pNetDev->addr_len !=3D 0) {=0A= + pNetStat =3D pNetDev->get_stats(pNetDev);=0A= + pPhyData->m_nIndex =3D pNetDev->ifindex;=0A= + memcpy(pPhyData->m_cDesc, pNetDev->name, 20);=0A= + pPhyData->m_nMode =3D 0;=0A= + pPhyData->m_nType =3D 0;=0A= + switch (pPhyData->m_nType) {=0A= + /* case IFT_ETHER:=0A= + memcpy(pPhyData->m_cSpeed,"10000000",20);=0A= + break;=0A= +=0A= + case 9:=0A= + memcpy(pPhyData->m_cSpeed,"4000000",20);=0A= + break; */=0A= + default:=0A= + memcpy(pPhyData->m_cSpeed, "10000000", 20);=0A= + break;=0A= + }=0A= + memcpy(pPhyData->m_cPMAC, pNetDev->dev_addr,=0A= + ETH_ALEN);=0A= + memcpy(pPhyData->m_cCMAC, pNetDev->dev_addr,=0A= + ETH_ALEN);=0A= + pPhyData->m_nLinkStatus =3D=0A= + test_bit(__LINK_STATE_START, &pNetDev->state);=0A= + pPhyData->m_nPCISlot =3D PCI_SLOT(pdev->devfn);=0A= + pPhyData->m_nPCIBus =3D pdev->bus->number;=0A= + pPhyData->m_nIRQ =3D pNetDev->irq;=0A= + pPhyData->m_nCollision =3D pNetStat->collisions;=0A= + pPhyData->m_nMulticast =3D pNetStat->multicast;=0A= +=0A= + pPhyData->m_nRxBytes =3D pNetStat->rx_bytes;=0A= + pPhyData->m_nRxDropped =3D pNetStat->rx_dropped;=0A= + pPhyData->m_nRxErrors =3D pNetStat->rx_errors;=0A= + pPhyData->m_nRxPackets =3D pNetStat->rx_packets;=0A= +=0A= + pPhyData->m_nTxBytes =3D pNetStat->tx_bytes;=0A= + pPhyData->m_nTxDropped =3D pNetStat->tx_dropped;=0A= + pPhyData->m_nTxErrors =3D pNetStat->tx_errors;=0A= + pPhyData->m_nTxPackets =3D pNetStat->tx_packets;=0A= +=0A= + sprintf(cMAC, "%02x:%02x:%02x:%02x:%02x:%02x",=0A= + pPhyData->m_cPMAC[0], pPhyData->m_cPMAC[1],=0A= + pPhyData->m_cPMAC[2], pPhyData->m_cPMAC[3],=0A= + pPhyData->m_cPMAC[4],=0A= + pPhyData->m_cPMAC[5]);=0A= +=0A= + sprintf(page + nLength,=0A= + = "%-10d%-22s%-10d%-10d%-22s%-22s%-10d%-10d%-10d%-10d%-10d%-10d%-10d%-10d%-= 10d%-10d%-10d%-10d%-10d%-10d\n",=0A= + pPhyData->m_nIndex, pPhyData->m_cDesc,=0A= + pPhyData->m_nMode, pPhyData->m_nType,=0A= + pPhyData->m_cSpeed, cMAC,=0A= + pPhyData->m_nLinkStatus,=0A= + pPhyData->m_nPCISlot, pPhyData->m_nPCIBus,=0A= + pPhyData->m_nIRQ, pPhyData->m_nCollision,=0A= + pPhyData->m_nMulticast,=0A= + pPhyData->m_nRxBytes,=0A= + pPhyData->m_nRxDropped,=0A= + pPhyData->m_nRxErrors,=0A= + pPhyData->m_nRxPackets,=0A= + pPhyData->m_nTxBytes,=0A= + pPhyData->m_nTxDropped,=0A= + pPhyData->m_nTxErrors,=0A= + pPhyData->m_nTxPackets);=0A= + nLength +=3D 237;=0A= + }=0A= + }=0A= +=0A= + *eof =3D 1;=0A= +=0A= + kfree(pPhyData);=0A= + return nLength;=0A= +}=0A= +=0A= +/* =0A= + * s2io_bdsnmp_init - Entry point to create proc file=0A= + * @dev- Pointer to net device structure passed by the driver.=0A= + * Return =0A= + * Success If creates all the files=0A= + * ERROR_PROC_ENTRY /ERROR_PROC_DIR Error If could not create all the = files=0A= + * Description=0A= + * This functon is called when the driver is loaded. It creates the S2IO=0A= + * proc file system in the /proc/net/ directory. This directory is used = to =0A= + * store the info about the base driver afm driver, lacp, vlan and = nplus.=0A= + * It checks if S2IO directory already exists else creates it and = creates =0A= + * the files BDInfo files and assiciates read function to each of the = files.=0A= + */=0A= +=0A= +int s2io_bdsnmp_init(struct net_device *dev)=0A= +{=0A= + struct proc_dir_entry *S2ioDir;=0A= + struct proc_dir_entry *BaseDrv;=0A= + struct proc_dir_entry *PhyAdap;=0A= + int nLength =3D 0;=0A= +=0A= + nLength =3D strlen(S2IODIRNAME);=0A= + /* IF the directory already exists then just return */=0A= + for (S2ioDir =3D proc_net->subdir; S2ioDir !=3D NULL;=0A= + S2ioDir =3D S2ioDir->next) {=0A= + if ((S2ioDir->namelen =3D=3D nLength)=0A= + && (!memcmp(S2ioDir->name, S2IODIRNAME, nLength)))=0A= + break;=0A= + }=0A= + if (S2ioDir =3D=3D NULL)=0A= + /* Create the s2io directory */=0A= + if (!=0A= + (S2ioDir =3D=0A= + create_proc_entry(S2IODIRNAME, S_IFDIR, proc_net))) {=0A= + DBG_PRINT(INIT_DBG,=0A= + "Error Creating Proc directory for SNMP\n");=0A= + return ERROR_PROC_DIR;=0A= + }=0A= + /* =0A= + * Create the BDInfo file to store driver info and associate =0A= + * read funtion.=0A= + */=0A= + if (!=0A= + (BaseDrv =3D=0A= + create_proc_read_entry(BDFILENAME, S_IFREG | S_IRUSR, S2ioDir,=0A= + fnBaseReadProc, (void *) dev))) {=0A= + DBG_PRINT(INIT_DBG,=0A= + "Error Creating Proc File for Base Drvr\n");=0A= + return ERROR_PROC_ENTRY;=0A= + }=0A= + if (!=0A= + (PhyAdap =3D=0A= + create_proc_read_entry(PADAPFILENAME, S_IFREG | S_IRUSR,=0A= + S2ioDir, fnPhyAdapReadProc,=0A= + (void *) dev))) {=0A= + DBG_PRINT(INIT_DBG,=0A= + "Error Creating Proc File for Phys Adap\n");=0A= + return ERROR_PROC_ENTRY;=0A= + }=0A= +=0A= +=0A= + return SUCCESS;=0A= +}=0A= +=0A= +/**=0A= + * s2io_bdsnmp_rem : Removes the proc file entry=0A= + * @dev - pointer to netdevice structre=0A= + * Return - void=0A= + * Description=0A= + * This functon is called when the driver is Unloaded. It checks if the =0A= + * S2IO directoy exists and deletes the files in the reverse order of =0A= + * creation.=0A= + */=0A= +=0A= +void s2io_bdsnmp_rem(struct net_device *dev)=0A= +{=0A= + int nLength =3D 0;=0A= + struct proc_dir_entry *S2ioDir;=0A= + nLength =3D strlen(S2IODIRNAME);=0A= + /* =0A= + * Check if the S2IO directory exists or not and then delete =0A= + * all the files in the S2IO Directory =0A= + */=0A= + for (S2ioDir =3D proc_net->subdir; S2ioDir !=3D NULL;=0A= + S2ioDir =3D S2ioDir->next) {=0A= + if ((S2ioDir->namelen =3D=3D nLength)=0A= + && (!memcmp(S2ioDir->name, S2IODIRNAME, nLength)))=0A= +=0A= + break;=0A= + }=0A= + if (S2ioDir =3D=3D NULL)=0A= + return;=0A= + remove_proc_entry(BDFILENAME, S2ioDir);=0A= + remove_proc_entry(PADAPFILENAME, S2ioDir);=0A= + if (S2ioDir->subdir =3D=3D NULL) {=0A= + remove_proc_entry(S2IODIRNAME, proc_net);=0A= + }=0A= +}=0A= +#endif=0A= diff -urN vanilla_linux-2.6.7/drivers/net/s2io.h = linux-2.6.7/drivers/net/s2io.h=0A= --- vanilla_linux-2.6.7/drivers/net/s2io.h 2004-06-15 22:19:09.000000000 = -0700=0A= +++ linux-2.6.7/drivers/net/s2io.h 2004-09-08 12:55:02.000000000 -0700=0A= @@ -16,6 +16,7 @@=0A= #define TBD 0=0A= #define BIT(loc) (0x8000000000000000ULL >> (loc))=0A= #define vBIT(val, loc, sz) (((u64)val) << (64-loc-sz))=0A= +#define INV(d) ((d&0xff)<<24) | (((d>>8)&0xff)<<16) | = (((d>>16)&0xff)<<8)| ((d>>24)&0xff)=0A= =0A= #ifndef BOOL=0A= #define BOOL int=0A= @@ -49,11 +50,13 @@=0A= #define ALIGN_SIZE 127=0A= #define PCIX_COMMAND_REGISTER 0x62=0A= =0A= +#ifndef SET_ETHTOOL_OPS=0A= +#define SUPPORTED_10000baseT_Full (1 << 12)=0A= +#endif=0A= +=0A= /*=0A= * Debug related variables.=0A= */=0A= -#define DEBUG_ON TRUE=0A= -=0A= /* different debug levels. */=0A= #define ERR_DBG 0=0A= #define INIT_DBG 1=0A= @@ -375,7 +378,7 @@=0A= u32 TxFIFONum; /*Number of Tx FIFOs */=0A= #define MAX_TX_FIFOS 8=0A= =0A= - tx_fifo_config_t TxCfg[MAX_TX_FIFOS]; /*Per-Tx FIFO config */=0A= + tx_fifo_config_t tx_cfg[MAX_TX_FIFOS]; /*Per-Tx FIFO config */=0A= u32 MaxTxDs; /*Max no. of Tx buffer descriptor per TxDL */=0A= BOOL TxVLANEnable; /*TRUE: Insert VLAN ID, FALSE: Don't insert */=0A= #define TX_REQ_TIMEOUT_DEFAULT 0x0=0A= @@ -403,7 +406,7 @@=0A= #define MAX_RX_RINGS 8=0A= #define MAX_RX_BLOCKS_PER_RING 150=0A= =0A= - rx_ring_config_t RxCfg[MAX_RX_RINGS]; /*Per-Rx Ring config */=0A= + rx_ring_config_t rx_cfg[MAX_RX_RINGS]; /*Per-Rx Ring config */=0A= BOOL RxVLANEnable; /*TRUE: Strip off VLAN tag from the frame,=0A= FALSE: Don't strip off VLAN tag */=0A= =0A= @@ -492,6 +495,12 @@=0A= u64 Host_Control; /* reserved for host */=0A= } TxD_t;=0A= =0A= +/* Structure to hold the phy and virt addr of every TxDL. */=0A= +typedef struct list_info_hold {=0A= + dma_addr_t list_phy_addr;=0A= + void *list_virt_addr;=0A= +} list_info_hold_t;=0A= +=0A= /* Rx descriptor structure */=0A= typedef struct _RxD_t {=0A= u64 Host_Control; /* reserved for host */=0A= @@ -508,36 +517,80 @@=0A= #define RXD_GET_L4_CKSUM(val) ((u16)(val) & 0xFFFF)=0A= =0A= u64 Control_2;=0A= +#ifndef CONFIG_2BUFF_MODE=0A= #define MASK_BUFFER0_SIZE vBIT(0xFFFF,0,16)=0A= #define SET_BUFFER0_SIZE(val) vBIT(val,0,16)=0A= +#else=0A= +#define MASK_BUFFER0_SIZE vBIT(0xFF,0,16)=0A= +#define MASK_BUFFER1_SIZE vBIT(0xFFFF,16,16)=0A= +#define MASK_BUFFER2_SIZE vBIT(0xFFFF,32,16)=0A= +#define SET_BUFFER0_SIZE(val) vBIT(val,8,8)=0A= +#define SET_BUFFER1_SIZE(val) vBIT(val,16,16)=0A= +#define SET_BUFFER2_SIZE(val) vBIT(val,32,16)=0A= +#endif=0A= +=0A= #define MASK_VLAN_TAG vBIT(0xFFFF,48,16)=0A= #define SET_VLAN_TAG(val) vBIT(val,48,16)=0A= #define SET_NUM_TAG(val) vBIT(val,16,32)=0A= =0A= +#ifndef CONFIG_2BUFF_MODE=0A= #define RXD_GET_BUFFER0_SIZE(Control_2) (u64)((Control_2 & = vBIT(0xFFFF,0,16)))=0A= -/* =0A= -#define TXD_GET_BUFFER1_SIZE(Control_2) (u16)((Control_2 & = MASK_BUFFER1_SIZE) >> (63-31)) =0A= -#define TXD_GET_BUFFER2_SIZE(Control_2) (u16)((Control_2 & = MASK_BUFFER2_SIZE) >> (63-47)) =0A= -*/=0A= +#else=0A= +#define RXD_GET_BUFFER0_SIZE(Control_2) (u8)((Control_2 & = MASK_BUFFER0_SIZE) \=0A= + >> 48)=0A= +#define RXD_GET_BUFFER1_SIZE(Control_2) (u16)((Control_2 & = MASK_BUFFER1_SIZE) \=0A= + >> 32)=0A= +#define RXD_GET_BUFFER2_SIZE(Control_2) (u16)((Control_2 & = MASK_BUFFER2_SIZE) \=0A= + >> 16)=0A= +#define BUF0_LEN 40=0A= +#define BUF1_LEN 1=0A= +#endif=0A= +=0A= u64 Buffer0_ptr;=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + u64 Buffer1_ptr;=0A= + u64 Buffer2_ptr;=0A= +#endif=0A= } RxD_t;=0A= =0A= -=0A= /* Structure that represents the Rx descriptor block which contains =0A= * 128 Rx descriptors.=0A= */=0A= +#ifndef CONFIG_2BUFF_MODE=0A= typedef struct _RxD_block {=0A= #define MAX_RXDS_PER_BLOCK 127=0A= RxD_t rxd[MAX_RXDS_PER_BLOCK];=0A= =0A= u64 reserved_0;=0A= #define END_OF_BLOCK 0xFEFFFFFFFFFFFFFFULL=0A= - u64 reserved_1; /* 0xFEFFFFFFFFFFFFFF to mark last Rxd in this blk */=0A= - u64 reserved_2_pNext_RxD_block; /*@ Logical ptr to next */=0A= - u64 pNext_RxD_Blk_physical; /* Buff0_ptr.=0A= - In a 32 bit arch the upper 32 bits =0A= - should be 0 */=0A= + u64 reserved_1; /* 0xFEFFFFFFFFFFFFFF to mark last =0A= + * Rxd in this blk */=0A= + u64 reserved_2_pNext_RxD_block; /* Logical ptr to next */=0A= + u64 pNext_RxD_Blk_physical; /* Buff0_ptr.In a 32 bit arch=0A= + * the upper 32 bits should =0A= + * be 0 */=0A= +} RxD_block_t;=0A= +#else=0A= +typedef struct _RxD_block {=0A= +#define MAX_RXDS_PER_BLOCK 85=0A= + RxD_t rxd[MAX_RXDS_PER_BLOCK];=0A= +=0A= +#define END_OF_BLOCK 0xFEFFFFFFFFFFFFFFULL=0A= + u64 reserved_1; /* 0xFEFFFFFFFFFFFFFF to mark last Rxd =0A= + * in this blk */=0A= + u64 pNext_RxD_Blk_physical; /* Phy ponter to next blk. */=0A= } RxD_block_t;=0A= +#define SIZE_OF_BLOCK 4096=0A= +=0A= +/* Structure to hold virtual addresses of Buf0 and Buf1 in =0A= + * 2buf mode. */=0A= +typedef struct bufAdd {=0A= + void *ba_0_org;=0A= + void *ba_1_org;=0A= + void *ba_0;=0A= + void *ba_1;=0A= +} buffAdd_t;=0A= +#endif=0A= =0A= /* Structure which stores all the MAC control parameters */=0A= =0A= @@ -570,8 +623,6 @@=0A= typedef struct mac_info {=0A= /* rx side stuff */=0A= u32 rxd_ring_mem_sz;=0A= - RxD_t *RxRing[MAX_RX_RINGS]; /* Logical Rx ring pointers */=0A= - dma_addr_t RxRing_Phy[MAX_RX_RINGS];=0A= =0A= /* Put pointer info which indictes which RxD has to be replenished =0A= * with a new buffer.=0A= @@ -584,6 +635,9 @@=0A= rx_curr_get_info_t rx_curr_get_info[MAX_RX_RINGS];=0A= =0A= u16 rmac_pause_time;=0A= + u16 mc_pause_threshold_q0q3;=0A= + u16 mc_pause_threshold_q4q7;=0A= +=0A= =0A= /* this will be used in receive function, this decides which ring would=0A= be processed first. eg: ring with priority value 0 (highest) should=0A= @@ -618,7 +672,7 @@=0A= void *stats_mem; /* orignal pointer to allocated mem */=0A= dma_addr_t stats_mem_phy; /* Physical address of the stat block */=0A= u32 stats_mem_sz;=0A= - StatInfo_t *StatsInfo; /* Logical address of the stat block */=0A= + StatInfo_t *stats_info; /* Logical address of the stat block */=0A= } mac_info_t;=0A= =0A= /* structure representing the user defined MAC addresses */=0A= @@ -633,13 +687,20 @@=0A= dma_addr_t block_dma_addr;=0A= } rx_block_info_t;=0A= =0A= +/* Default Tunable parameters of the NIC. */=0A= +#define DEFAULT_FIFO_LEN 4096=0A= +#define SMALL_RXD_CNT 30 * (MAX_RXDS_PER_BLOCK+1)=0A= +#define LARGE_RXD_CNT 100 * (MAX_RXDS_PER_BLOCK+1)=0A= +#define SMALL_BLK_CNT 30=0A= +#define LARGE_BLK_CNT 100=0A= +=0A= /* Structure representing one instance of the NIC */=0A= typedef struct s2io_nic {=0A= #define MAX_MAC_SUPPORTED 16=0A= #define MAX_SUPPORTED_MULTICASTS MAX_MAC_SUPPORTED=0A= =0A= - macaddr_t defMacAddr[MAX_MAC_SUPPORTED];=0A= - macaddr_t preMacAddr[MAX_MAC_SUPPORTED];=0A= + macaddr_t def_mac_addr[MAX_MAC_SUPPORTED];=0A= + macaddr_t pre_mac_addr[MAX_MAC_SUPPORTED];=0A= =0A= struct net_device_stats stats;=0A= caddr_t bar0;=0A= @@ -672,8 +733,10 @@=0A= u32 irq;=0A= atomic_t rx_bufs_left[MAX_RX_RINGS];=0A= =0A= - spinlock_t isr_lock;=0A= spinlock_t tx_lock;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + spinlock_t put_lock;=0A= +#endif=0A= =0A= #define PROMISC 1=0A= #define ALL_MULTI 2=0A= @@ -692,23 +755,22 @@=0A= u16 tx_err_count;=0A= u16 rx_err_count;=0A= =0A= -#if DEBUG_ON=0A= - u64 rxpkt_bytes;=0A= - u64 txpkt_bytes;=0A= - int int_cnt;=0A= - int rxint_cnt;=0A= - int txint_cnt;=0A= - u64 rxpkt_cnt;=0A= +#ifndef CONFIG_S2IO_NAPI=0A= + /* Index to the absolute position of the put pointer of Rx ring. */=0A= + int put_pos;=0A= #endif=0A= =0A= - /* Place holders for the virtual and physical addresses of =0A= + /*=0A= + * Place holders for the virtual and physical addresses of =0A= * all the Rx Blocks=0A= */=0A= - struct rx_block_info=0A= - rx_blocks[MAX_RX_RINGS][MAX_RX_BLOCKS_PER_RING];=0A= + rx_block_info_t rx_blocks[MAX_RX_RINGS][MAX_RX_BLOCKS_PER_RING];=0A= int block_count[MAX_RX_RINGS];=0A= int pkt_cnt[MAX_RX_RINGS];=0A= =0A= + /* Place holder of all the TX List's Phy and Virt addresses. */=0A= + list_info_hold_t *list_info[MAX_TX_FIFOS];=0A= +=0A= /* Id timer, used to blink NIC to physically identify NIC. */=0A= struct timer_list id_timer;=0A= =0A= @@ -738,24 +800,34 @@=0A= u16 last_link_state;=0A= #define LINK_DOWN 1=0A= #define LINK_UP 2=0A= +=0A= +#ifdef CONFIG_2BUFF_MODE=0A= + /* Buffer Address store. */=0A= + buffAdd_t **ba[MAX_RX_RINGS];=0A= +#endif=0A= + int task_flag;=0A= +#ifdef SNMP_SUPPORT=0A= + char cName[20];=0A= + int nMemorySize;=0A= + int nLinkStatus;=0A= + int nFeature;=0A= + char cVersion[20];=0A= + long lDate;=0A= +#endif=0A= +=0A= } nic_t;=0A= =0A= #define RESET_ERROR 1;=0A= #define CMD_ERROR 2;=0A= =0A= -/* Default Tunable parameters of the NIC. */=0A= -#define DEFAULT_FIFO_LEN 4096=0A= -#define SMALL_RXD_CNT 40 * (MAX_RXDS_PER_BLOCK+1)=0A= -#define LARGE_RXD_CNT 100 * (MAX_RXDS_PER_BLOCK+1)=0A= -=0A= /* OS related system calls */=0A= #ifndef readq=0A= static inline u64 readq(void *addr)=0A= {=0A= u64 ret =3D 0;=0A= ret =3D readl(addr + 4);=0A= - ret <<=3D 32;=0A= - ret |=3D readl(addr);=0A= + (u64) ret <<=3D 32;=0A= + (u64) ret |=3D readl(addr);=0A= =0A= return ret;=0A= }=0A= @@ -767,6 +839,25 @@=0A= writel((u32) (val), addr);=0A= writel((u32) (val >> 32), (addr + 4));=0A= }=0A= +=0A= +/* In 32 bit modes, some registers have to be written in a =0A= + * particular order to expect correct hardware operation. The=0A= + * macro SPECIAL_REG_WRITE is used to perform such ordered =0A= + * writes. Defines UF (Upper First) and LF (Lower First) will =0A= + * be used to specify the required write order.=0A= + */=0A= +#define UF 1=0A= +#define LF 2=0A= +#define SPECIAL_REG_WRITE(val, addr, order) \=0A= + if (order =3D=3D LF) { \=0A= + writel((u32) (val), addr); \=0A= + writel((u32) (val >> 32), (addr + 4)); \=0A= + } else { \=0A= + writel((u32) (val >> 32), (addr + 4)); \=0A= + writel((u32) (val), addr); \=0A= + }=0A= +#else=0A= +#define SPECIAL_REG_WRITE(val, addr, dummy) writeq(val, addr)=0A= #endif=0A= =0A= /* Interrupt related values of Xena */=0A= @@ -817,30 +908,41 @@=0A= =0A= /* DMA level Inressupts */=0A= #define TXDMA_PFC_INT_M BIT(0)=0A= - /* PFC block interrupts */=0A= +#define TXDMA_PCC_INT_M BIT(2)=0A= +=0A= +/* PFC block interrupts */=0A= #define PFC_MISC_ERR_1 BIT(0) /* Interrupt to indicate FIFO full */=0A= =0A= +/* PCC block interrupts. */=0A= +#define PCC_FB_ECC_ERR vBIT(0xff, 16, 8) /* Interrupt to indicate=0A= + PCC_FB_ECC Error. */=0A= +=0A= /*=0A= * Prototype declaration.=0A= */=0A= static int __devinit s2io_init_nic(struct pci_dev *pdev,=0A= const struct pci_device_id *pre);=0A= static void __devexit s2io_rem_nic(struct pci_dev *pdev);=0A= -static int initSharedMem(struct s2io_nic *sp);=0A= -static void freeSharedMem(struct s2io_nic *sp);=0A= -static int initNic(struct s2io_nic *nic);=0A= +static int init_shared_mem(struct s2io_nic *sp);=0A= +static void free_shared_mem(struct s2io_nic *sp);=0A= +static int init_nic(struct s2io_nic *nic);=0A= #ifndef CONFIG_S2IO_NAPI=0A= -static void rxIntrHandler(struct s2io_nic *sp);=0A= +static void rx_intr_handler(struct s2io_nic *sp);=0A= #endif=0A= -static void txIntrHandler(struct s2io_nic *sp);=0A= -static void alarmIntrHandler(struct s2io_nic *sp);=0A= +static void tx_intr_handler(struct s2io_nic *sp);=0A= +static void alarm_intr_handler(struct s2io_nic *sp);=0A= =0A= static int s2io_starter(void);=0A= void s2io_closer(void);=0A= static void s2io_tx_watchdog(struct net_device *dev);=0A= static void s2io_tasklet(unsigned long dev_addr);=0A= static void s2io_set_multicast(struct net_device *dev);=0A= -static int rxOsmHandler(nic_t * sp, u16 len, RxD_t * rxdp, int ring_no);=0A= +#ifndef CONFIG_2BUFF_MODE=0A= +static int rx_osm_handler(nic_t * sp, u16 len, RxD_t * rxdp, int = ring_no);=0A= +#else=0A= +static int rx_osm_handler(nic_t * sp, RxD_t * rxdp, int ring_no,=0A= + buffAdd_t * ba);=0A= +#endif=0A= void s2io_link(nic_t * sp, int link);=0A= void s2io_reset(nic_t * sp);=0A= #ifdef CONFIG_S2IO_NAPI=0A= @@ -850,6 +952,70 @@=0A= int s2io_set_mac_addr(struct net_device *dev, u8 * addr);=0A= static irqreturn_t s2io_isr(int irq, void *dev_id, struct pt_regs = *regs);=0A= static int verify_xena_quiescence(u64 val64, int flag);=0A= +int verify_load_parm(void);=0A= +#ifdef SET_ETHTOOL_OPS=0A= static struct ethtool_ops netdev_ethtool_ops;=0A= +#endif=0A= +static void s2io_set_link(unsigned long data);=0A= +=0A= +#ifdef SNMP_SUPPORT=0A= +=0A= +#define S2IODIRNAME "S2IO"=0A= +#define BDFILENAME "BDInfo"=0A= +#define PADAPFILENAME "PhyAdap"=0A= +#define ERROR_PROC_DIR -20=0A= +#define ERROR_PROC_ENTRY -21=0A= +=0A= +struct stDrvData {=0A= + struct stBaseDrv *pBaseDrv;=0A= +};=0A= +=0A= +struct stPhyAdap {=0A= + int m_nIndex;=0A= + char m_cName[20];=0A= +};=0A= +struct stBaseDrv {=0A= + char m_cName[21];=0A= + int m_nStatus;=0A= + char m_cVersion[21];=0A= + int m_nFeature;=0A= + int m_nMemorySize;=0A= + char m_cDate[21];=0A= + int m_nPhyCnt;=0A= + char m_cPhyIndex[21];=0A= + struct stPhyAdap m_stPhyAdap[5];=0A= +};=0A= +=0A= +struct stPhyData {=0A= + int m_nIndex;=0A= + unsigned char m_cDesc[20];=0A= + int m_nMode;=0A= + int m_nType;=0A= + char m_cSpeed[20];=0A= + unsigned char m_cPMAC[20];=0A= + unsigned char m_cCMAC[20];=0A= + int m_nLinkStatus;=0A= + int m_nPCISlot;=0A= + int m_nPCIBus;=0A= + int m_nIRQ;=0A= + int m_nCollision;=0A= + int m_nMulticast;=0A= +=0A= + int m_nRxBytes;=0A= + int m_nRxDropped;=0A= + int m_nRxErrors;=0A= + int m_nRxPackets;=0A= + int m_nTxBytes;=0A= + int m_nTxDropped;=0A= + int m_nTxErrors;=0A= + int m_nTxPackets;=0A= +=0A= +=0A= +};=0A= +=0A= +static int s2io_bdsnmp_init(struct net_device *dev);=0A= +static void s2io_bdsnmp_rem(struct net_device *dev);=0A= +#endif=0A= +=0A= =0A= #endif /* _S2IO_H */=0A= ------=_NextPart_000_0023_01C49979.D01C88C0-- From speattle@yahoo.com Mon Sep 13 10:48:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 10:49:04 -0700 (PDT) Received: from web90003.mail.scd.yahoo.com (web90003.mail.scd.yahoo.com [66.218.94.61]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8DHmx1a027534 for ; Mon, 13 Sep 2004 10:48:59 -0700 Message-ID: <20040913174842.96183.qmail@web90003.mail.scd.yahoo.com> Received: from [216.145.61.65] by web90003.mail.scd.yahoo.com via HTTP; Mon, 13 Sep 2004 10:48:39 PDT Date: Mon, 13 Sep 2004 10:48:39 -0700 (PDT) From: S P Subject: [PATCH] linux 2.6.x.x - include/net/neighbour.h spell-check To: davem@davemloft.net Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: speattle@yahoo.com Precedence: bulk X-list: netdev Content-Length: 726 Lines: 34 Hi, in linux 2.6.x.x kernel's include/net/neighbour.h 'Neighbour' and 'Neighbor' are used interchangeably. neighbour is british variation of neighbor, so i'd say neighbor is more appropriate. but then the header's named neighbour. just cleaning up some in-line documentations while reading through. I hope my reporting format is correct! Thanks in advance. diff neighbour.h ../linus-2.6/include/net/neighbou 17c17 < * Neighbour Cache Entry Flags --- > * Neighbor Cache Entry Flags 24c24 < * Neighbour Cache Entry States. --- > * Neighbor Cache Entry States. _______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool From ak@muc.de Mon Sep 13 11:11:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 11:11:22 -0700 (PDT) Received: from zero.aec.at (Jonathan_Fomry@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DIBEQd028877 for ; Mon, 13 Sep 2004 11:11:15 -0700 Received: from averell.firstfloor.org.muc.de (Martha_Braymance@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i8DIB0g31769; Mon, 13 Sep 2004 20:11:01 +0200 To: davem@redhat.com cc: netdev@oss.sgi.com, arjanv@redhat.com Subject: [PATCH] Fix locking bug in lltx path From: Andi Kleen Date: Mon, 13 Sep 2004 20:11:00 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 942 Lines: 35 Thanks to Arjan's spinlock debug kernel for finding it. This fixes a silly missing spin lock in the relock path. For some reason it seems to still work when you don't have spinlock debugging enabled. Please apply. -Andi -------------------------------------------------------------------- Fix missing spin lock in lltx path. Thanks to Arjan's spinlock debug kernel for finding it. Signed-off-by: Andi Kleen diff -u linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X linux-2.6.9rc1-bk19/net/sched/sch_generic.c --- linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X 2004-09-13 08:51:46.000000000 +0200 +++ linux-2.6.9rc1-bk19/net/sched/sch_generic.c 2004-09-13 19:22:50.000000000 +0200 @@ -153,8 +153,10 @@ spin_lock(&dev->queue_lock); return -1; } - if (ret == -1 && nolock) + if (ret == -1 && nolock) { + spin_lock(&dev->queue_lock); goto collision; + } } /* Release the driver */ From greearb@candelatech.com Mon Sep 13 11:14:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 11:14:39 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DIEYdg029211 for ; Mon, 13 Sep 2004 11:14:34 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8DIGbLH004532; Mon, 13 Sep 2004 11:16:37 -0700 Message-ID: <4145E37E.40706@candelatech.com> Date: Mon, 13 Sep 2004 11:14:22 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lewis Adam-CAL022 CC: netdev@oss.sgi.com Subject: Re: hard_start_xmit and Linux bridging References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1628 Lines: 55 Lewis Adam-CAL022 wrote: > Hi Ben, > > >>-----Original Message----- >>From: Ben Greear [mailto:greearb@candelatech.com] >>Sent: Thursday, September 09, 2004 6:30 PM >>To: Lewis Adam-CAL022 >>Cc: netdev@oss.sgi.com >>Subject: Re: hard_start_xmit and Linux bridging >> >>I added some ioctls to allow one to turn on the ability to >>receive the CRC, but I don't know of any drivers that include >>it by default. > > > Right, this is what I would have expected since no other driver account for it. > > >>What driver/hardware is your eth0 device? > > > It is a custom board but a Xilinx PCORE and using a Montavista driver. Based on what you said above, it seems that I might want to pursue this with them. > > >>How are you determining the size, by the skb->len ? > > > Exactly. And not only does it include the FCS/CRC, but in the case of an ARP, there are an extra 14 trailing 0's. I thought this was a bridging issue, now I'm thinking it's a xilinx/mvista issue. > > >>Does tcpdump/ethereal show the extra 4 bytes if you sniff >>eth0 w/out bridging? > > > Yeah. And in the case of ARP it is even weirder, and extra 18 bytes, mostly zeros. So case in point, it sounds like this is not proper operation? I want to confirm before I bring it up with Xilinx and Montavista. Sounds to me like they are not zeroing out the padded bytes, and that they are also counting the padded bytes (and CRC) as valid data in the driver. My vote is definately an ethernet driver bug (or bugs). Ben > > Thanks! > Adam > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@redhat.com Mon Sep 13 12:20:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 12:21:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DJKtDj001223 for ; Mon, 13 Sep 2004 12:20:56 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8DJKeBX024637; Mon, 13 Sep 2004 15:20:40 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8DJKer01518; Mon, 13 Sep 2004 15:20:40 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8DJKY0c019482; Mon, 13 Sep 2004 15:20:35 -0400 Date: Mon, 13 Sep 2004 12:18:59 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com, arjanv@redhat.com Subject: Re: [PATCH] Fix locking bug in lltx path Message-Id: <20040913121859.44fbf949.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 405 Lines: 15 On Mon, 13 Sep 2004 20:11:00 +0200 Andi Kleen wrote: > Thanks to Arjan's spinlock debug kernel for finding it. > > This fixes a silly missing spin lock in the relock path. For some > reason it seems to still work when you don't have spinlock debugging > enabled. > > Please apply. Good catch, but I'll need to fix this up to use the new macros defined in linux/netdevice.h Thanks again. From ak@suse.de Mon Sep 13 12:27:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 12:27:14 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DJR79F001638 for ; Mon, 13 Sep 2004 12:27:08 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0A333BDF02F; Mon, 13 Sep 2004 21:26:52 +0200 (CEST) Date: Mon, 13 Sep 2004 21:26:49 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , netdev@oss.sgi.com, arjanv@redhat.com Subject: Re: [PATCH] Fix locking bug in lltx path Message-ID: <20040913192649.GA26975@wotan.suse.de> References: <20040913121859.44fbf949.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040913121859.44fbf949.davem@redhat.com> X-archive-position: 8731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 696 Lines: 23 On Mon, Sep 13, 2004 at 12:18:59PM -0700, David S. Miller wrote: > On Mon, 13 Sep 2004 20:11:00 +0200 > Andi Kleen wrote: > > > Thanks to Arjan's spinlock debug kernel for finding it. > > > > This fixes a silly missing spin lock in the relock path. For some > > reason it seems to still work when you don't have spinlock debugging > > enabled. > > > > Please apply. > > Good catch, but I'll need to fix this up to use the new macros > defined in linux/netdevice.h Ok, do you want me to send a new patch with that? I don't think the new macros are in -bk* snapshots yet, and getting it otherwise is difficult for me. It's probably fastest if you just apply it by hand. -Andi From davem@davemloft.net Mon Sep 13 12:35:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 12:35:08 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DJZ2pc002047 for ; Mon, 13 Sep 2004 12:35:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6wZY-0003aB-00; Mon, 13 Sep 2004 12:33:08 -0700 Date: Mon, 13 Sep 2004 12:33:08 -0700 From: "David S. Miller" To: Andi Kleen Cc: tgraf@suug.ch, ak@suse.de, netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-Id: <20040913123308.00686fb2.davem@davemloft.net> In-Reply-To: <20040913062613.GA12185@wotan.suse.de> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <20040912163744.52f95367.davem@davemloft.net> <20040913062613.GA12185@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 529 Lines: 14 On Mon, 13 Sep 2004 08:26:13 +0200 Andi Kleen wrote: > I actually don't think it will be a big issue for them. > They already translate messages by mapping text to other > text. The same thing could be done for kernel messages, > by just marking them in the kernel somehow that they > can be automatically extracted from the source and then > later mapping them to the translations in user space. I understand, but I'm specifically talking about this "synchronization" issue. Anyways, I think strings are fine. From jgarzik@pobox.com Mon Sep 13 12:40:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 12:40:23 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DJeIpw002431 for ; Mon, 13 Sep 2004 12:40:19 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C6wgH-0000AD-T4; Mon, 13 Sep 2004 20:40:06 +0100 Message-ID: <4145F789.7010502@pobox.com> Date: Mon, 13 Sep 2004 15:39:53 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: davem@redhat.com, netdev@oss.sgi.com, arjanv@redhat.com Subject: Re: [PATCH] Fix locking bug in lltx path References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1030 Lines: 38 Andi Kleen wrote: > Thanks to Arjan's spinlock debug kernel for finding it. > > This fixes a silly missing spin lock in the relock path. For some > reason it seems to still work when you don't have spinlock debugging > enabled. > > Please apply. > > -Andi > > -------------------------------------------------------------------- > > Fix missing spin lock in lltx path. > > Thanks to Arjan's spinlock debug kernel for finding it. > > Signed-off-by: Andi Kleen > > diff -u linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X linux-2.6.9rc1-bk19/net/sched/sch_generic.c > --- linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X 2004-09-13 08:51:46.000000000 +0200 > +++ linux-2.6.9rc1-bk19/net/sched/sch_generic.c 2004-09-13 19:22:50.000000000 +0200 > @@ -153,8 +153,10 @@ > spin_lock(&dev->queue_lock); > return -1; > } > - if (ret == -1 && nolock) > + if (ret == -1 && nolock) { > + spin_lock(&dev->queue_lock); > goto collision; > + } please use the fancy new constants :) Jeff From davem@redhat.com Mon Sep 13 13:04:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 13:04:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DK4goH003033 for ; Mon, 13 Sep 2004 13:04:43 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8DK4Rc3005009; Mon, 13 Sep 2004 16:04:27 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8DK4Qr17105; Mon, 13 Sep 2004 16:04:26 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8DK4Jx4010832; Mon, 13 Sep 2004 16:04:20 -0400 Date: Mon, 13 Sep 2004 13:02:44 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@muc.de, netdev@oss.sgi.com, arjanv@redhat.com Subject: Re: [PATCH] Fix locking bug in lltx path Message-Id: <20040913130244.20a92a93.davem@redhat.com> In-Reply-To: <20040913192649.GA26975@wotan.suse.de> References: <20040913121859.44fbf949.davem@redhat.com> <20040913192649.GA26975@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 781 Lines: 26 On Mon, 13 Sep 2004 21:26:49 +0200 Andi Kleen wrote: > On Mon, Sep 13, 2004 at 12:18:59PM -0700, David S. Miller wrote: > > On Mon, 13 Sep 2004 20:11:00 +0200 > > Andi Kleen wrote: > > > > > Thanks to Arjan's spinlock debug kernel for finding it. > > > > > > This fixes a silly missing spin lock in the relock path. For some > > > reason it seems to still work when you don't have spinlock debugging > > > enabled. > > > > > > Please apply. > > > > Good catch, but I'll need to fix this up to use the new macros > > defined in linux/netdevice.h > > Ok, do you want me to send a new patch with that? I'll take care of it. > I don't think the new macros are in -bk* snapshots yet, > and getting it otherwise is difficult for me. It's in 2.6.9-rc2 From davem@davemloft.net Mon Sep 13 13:23:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 13:23:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DKNUT5003595 for ; Mon, 13 Sep 2004 13:23:30 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6xJx-0003hE-00; Mon, 13 Sep 2004 13:21:05 -0700 Date: Mon, 13 Sep 2004 13:21:05 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [IPv6] Add option to copy DSCP in decap in ip6_tunnel Message-Id: <20040913132105.02730b01.davem@davemloft.net> In-Reply-To: <20040913.205504.46820949.yoshfuji@linux-ipv6.org> References: <20040913111943.GA26179@gondor.apana.org.au> <20040913.205504.46820949.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8DKNUT5003595 X-archive-position: 8735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 657 Lines: 15 On Mon, 13 Sep 2004 20:55:04 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article <20040913111943.GA26179@gondor.apana.org.au> (at Mon, 13 Sep 2004 21:19:43 +1000), Herbert Xu says: > > > Here is a patch that allows the copying of the DSCP during decapsulation > > for ip6_tunnel. I've made it a separate option from the one that > > determines the copying during encapsulation since the DSCP processing > > may be asymmetric. It also means that we preserve compatibility should > > anyone be relying on the current behaviour. > > I agree. Me too, patch applied. Thanks Herbert. From tgraf@suug.ch Mon Sep 13 13:36:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 13:36:55 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DKambJ004045 for ; Mon, 13 Sep 2004 13:36:49 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 0BAD981; Mon, 13 Sep 2004 22:36:14 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 2B0401C0E8; Mon, 13 Sep 2004 22:36:57 +0200 (CEST) Date: Mon, 13 Sep 2004 22:36:57 +0200 From: Thomas Graf To: jamal Cc: Sam Leffler , Andi Kleen , netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-ID: <20040913203657.GF23686@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <3A0D075D-0423-11D9-BBE1-000A95AD0668@errno.com> <1094937035.2344.189.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094937035.2344.189.camel@jzny.localdomain> X-archive-position: 8736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2785 Lines: 73 * jamal <1094937035.2344.189.camel@jzny.localdomain> 2004-09-11 17:10 > On Sat, 2004-09-11 at 14:48, Sam Leffler wrote: > just reuse skb->cb[] and intepret it in rtnetlink in the case of > failures. Good idea, however it means to change a lot of APIs used by modules to provide the skb or a pointer to the error string buffer. I still think it would be best to transport the error code via the return value in order to not change any static APIs, but I guess that 32bit is not enough to store errno and the id your propose below. > I think we need to identify errors by IDs - dont think we can avoid > that. The IDs could be the T in TLV; their scope is per socket level (eg > at rtnetlink); This means there are 16 bits space per socket type. > The next level to addressing is at each submodule level eg qdisc, > ipv4route, etc. Assuming we have 8 bits there that leaves upto 8 bits > per submodule for different error types. 256 error codes per submodule > liek a qdisc sounds very reasonable to me. We could reserve the last > entry for future extensions. Example: > > socket: rtnetlink > submodule: qdisc (module 1) > error id: Q_NASTYTHING which is 0x10 > qdisc_errors[Q_NASTYTHING] is "something really nasty just happened" Sounds reasonable to me. > BTW, there was someone from IBM a while back who was talking about > having drivers send error messages via netlink; someone needs to look at > the ideas they have maybe we can borrow something. http://lwn.net/Articles/39164/ I read trough the patch and what they basically provide is a way to send data to a netlink socket. The data can be collected via an own netlink socket by subscribing to it or use the user space daemon. They provide stuff like: int evl_printf(const char *facility, int event_type, int severity, const char *fmt, ...) usage could be something like: evl_printf("qdisc", Q_NASTYTHING, ... We could use it this way: - Leave the existing error system as it is - Make the netlink users send out error messages on their own. pid and sequence number of the original netlink message could be provided. - User space applications could fetch error messages from that socket and assign them to their own actions by sequence number and pid. Pros: - Almost no changes to the APIs - Easy to implement - No problem with distribution of error codes - Very easy to implement formatted error strings. Cons: - More work for user space - How does user space know if there will be an extended error? If unknown, how long to wait? - Should we allow sending of errors to this socket while no netlink message is being processed? Idea: Make user space applications poll on the socket and just print the errors async. This would allow netlink users to use it for more than just error handling. From davem@davemloft.net Mon Sep 13 13:51:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 13:51:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DKpKPl012304 for ; Mon, 13 Sep 2004 13:51:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6xlN-00041d-00; Mon, 13 Sep 2004 13:49:25 -0700 Date: Mon, 13 Sep 2004 13:49:25 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, vnuorval@tcs.hut.fi Subject: Re: [BK PATCH] [IPV6] Merge Specification Conformity Improvements Message-Id: <20040913134925.6e63c3bc.davem@davemloft.net> In-Reply-To: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> References: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8DKpKPl012304 X-archive-position: 8737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 452 Lines: 15 On Mon, 13 Sep 2004 23:17:32 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Here're the changesets which improve conformity to > the IPv6 specifications / standards. > > Please pull from > I am pulling this, thank you. There are at least two issues I wish to discuss and that will show up in a follow mail later today after I read these changes some more. From sri@us.ibm.com Mon Sep 13 14:19:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 14:20:02 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DLJoFA029221 for ; Mon, 13 Sep 2004 14:19:57 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8DLHhaV761358; Mon, 13 Sep 2004 17:17:43 -0400 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8DLItbn086976; Mon, 13 Sep 2004 17:18:56 -0400 Date: Mon, 13 Sep 2004 14:17:41 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: Arnaldo Carvalho de Melo cc: "David S.Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [PATCH][NET] generalise per socket slab cache use In-Reply-To: <200409110023.34342.acme@conectiva.com.br> Message-ID: References: <200409110023.34342.acme@conectiva.com.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 928 Lines: 33 Arnaldo, looks good, but i have a few comments. It is great that SCTP now has its own slabcaches. > +struct ipv6_sk_offset raw_sock_offset = { > + .offset = offsetof(struct udp6_sock, inet6), > +}; I think there is a typo here. udp6_sock should be raw6_sock > - printk(KERN_CRIT "%s: Can't create protocol sock SLAB " > - "caches!\n", __FUNCTION__); You have removed the above critical messages. Is this by intent or a mistake. I am not clear on why we need this new structure ipv6_sk_offset. > +struct ipv6_sk_offset { > + int offset; > +}; > + Instead of adding the new field void *af_specific to struct proto, is it not sufficient to add int pinet6_offset; and assign it as follows for each v6 sock type .pinet6_offset = offsetof(struct struct tcp6_sock, inet6) In inet6_sk_generic(), you can directly use sk->sk_prot->pinet6_offset. Thanks Sridhar From acme@conectiva.com.br Mon Sep 13 14:51:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 14:51:27 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DLpEZY029918 for ; Mon, 13 Sep 2004 14:51:14 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id D1BED47439; Mon, 13 Sep 2004 18:51:01 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 99D7B4742E for ; Mon, 13 Sep 2004 18:51:01 -0300 (BRT) Received: (qmail 23284 invoked by uid 0); 13 Sep 2004 22:48:51 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 13 Sep 2004 22:48:51 -0000 Received: from [192.168.0.2] (brinquedo [192.168.0.2]) by oops.ghostprotocols.net (Postfix) with ESMTP id 484321462B; Mon, 13 Sep 2004 18:53:22 -0300 (BRT) From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. To: Sridhar Samudrala Subject: Re: [PATCH][NET] generalise per socket slab cache use Date: Mon, 13 Sep 2004 18:51:08 -0300 User-Agent: KMail/1.7 Cc: "David S.Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com References: <200409110023.34342.acme@conectiva.com.br> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409131851.10705.acme@conectiva.com.br> X-Bogosity: No, tests=bogofilter, spamicity=0.499275, version=0.16.3 X-archive-position: 8739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 1269 Lines: 44 Em Seg 13 Set 2004 18:17, Sridhar Samudrala escreveu: > Arnaldo, > > looks good, but i have a few comments. It is great that SCTP now has its > own slabcaches. > > > +struct ipv6_sk_offset raw_sock_offset = { > > + .offset = offsetof(struct udp6_sock, inet6), > > +}; > > I think there is a typo here. udp6_sock should be raw6_sock Good spotting! I'll fix this one > > - printk(KERN_CRIT "%s: Can't create protocol sock SLAB " > > - "caches!\n", __FUNCTION__); > > You have removed the above critical messages. Is this by intent or a > mistake. Humm, I'll put it on the sk_alloc_slab callers > > I am not clear on why we need this new structure ipv6_sk_offset. > > > +struct ipv6_sk_offset { > > + int offset; > > +}; > > + > > Instead of adding the new field void *af_specific to struct proto, is it > not sufficient to add > int pinet6_offset; > > and assign it as follows for each v6 sock type > .pinet6_offset = offsetof(struct struct tcp6_sock, inet6) > > In inet6_sk_generic(), you can directly use sk->sk_prot->pinet6_offset. I thought about it, but idea was to not introduce any family specific stuff in struct proto, I don't plan to have LLC over IPv6, for instance :) > Thanks > Sridhar From speattle@yahoo.com Mon Sep 13 14:59:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:00:04 -0700 (PDT) Received: from web90010.mail.scd.yahoo.com (web90010.mail.scd.yahoo.com [66.218.94.68]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8DLxxEJ030571 for ; Mon, 13 Sep 2004 14:59:59 -0700 Message-ID: <20040913215944.33830.qmail@web90010.mail.scd.yahoo.com> Received: from [216.145.61.65] by web90010.mail.scd.yahoo.com via HTTP; Mon, 13 Sep 2004 14:59:44 PDT Date: Mon, 13 Sep 2004 14:59:44 -0700 (PDT) From: S P Subject: [PATCH] linux 2.6.x.x net/sched/sch_api.c -- more comment reviews To: davem@davemloft.net Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: speattle@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2691 Lines: 102 OK, I used 'diff -Nru' this time. Sorry about last time. Ignorance~~~ :) Tense in the doc goes back and forth, making it a little difficult to understand. I hope I understood the documentation w/ small changes I'm submitting. - S.P. diff -Nru ../linus-2.6/net/sched/sch_api.c sch_api.c --- ../linus-2.6/net/sched/sch_api.c 2004-09-02 14:47:49.000000000 -0700 +++ sch_api.c 2004-09-13 14:53:30.726090760 -0700 @@ -78,7 +78,7 @@ checks and part of work, which is common to all qdiscs and to provide rtnetlink notifications. - All real intelligent work is done inside qdisc modules. + All real intelligent work is done inside each qdisc modules. @@ -87,29 +87,29 @@ ---dequeue dequeue usually returns a skb to send. It is allowed to return NULL, - but it does not mean that queue is empty, it just means that - discipline does not want to send anything this time. + but it does not mean the queue is empty; it means that + the discipline does not want to send anything this time. Queue is really empty if q->q.qlen == 0. - For complicated disciplines with multiple queues q->q is not - real packet queue, but however q->q.qlen must be valid. + For complicated disciplines with multiple queues, q->q is not + real packet queue whereas q->q.qlen must be valid. ---enqueue - enqueue returns 0, if packet was enqueued successfully. - If packet (this one or another one) was dropped, it returns - not zero error code. + enqueue returns 0, if packet enqueues successfully. + If packet (this one or another one) is dropped, it returns + non-zero error code. NET_XMIT_DROP - this packet dropped - Expected action: do not backoff, but wait until queue will clear. - NET_XMIT_CN - probably this packet enqueued, but another one dropped. - Expected action: backoff or ignore - NET_XMIT_POLICED - dropped by police. - Expected action: backoff or error to real-time apps. + Expected action: do not back-off, but wait until queue clears. + NET_XMIT_CN - probably this packet is enqueued, but another packet isdropped. + Expected action: back-off or ignore + NET_XMIT_POLICED - packet is dropped by police. + Expected action: back-off or error to real-time apps. Auxiliary routines: ---requeue - requeues once dequeued packet. It is used for non-standard or + requeues once packet is dequeued. It is used for non-standard or just buggy devices, which can defer output even if dev->tbusy=0. ---reset __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From romieu@fr.zoreil.com Mon Sep 13 15:03:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:03:17 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DM3Bgs031133 for ; Mon, 13 Sep 2004 15:03:11 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8DM2Avr013447; Tue, 14 Sep 2004 00:02:10 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8DM2AxR013446; Tue, 14 Sep 2004 00:02:10 +0200 Date: Tue, 14 Sep 2004 00:02:09 +0200 From: Francois Romieu To: Hans-Frieder Vogt Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040913220209.GA13175@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <20040912232604.GC27282@electric-eye.fr.zoreil.com> <200409131443.34374.hfvogt@arcor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409131443.34374.hfvogt@arcor.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 787 Lines: 24 Hans-Frieder Vogt : [...] > no oops (BUG_ON not triggered)! System boots up as normal, but just after I ... > log in on the console the system freezes, i.e., keyboard does not react any > more and the system is not accessible via network. - do the keyboard leds or the magic sysrq answer (I assume you boot without X) ? - does it make a difference if you boot with the network cable unpluged (i.e. fine until pluged then dead when first packet comes in) ? > The time from the moment I log in to the time when the system freezes varies, > but is in the order of 5s. First packet probably. Can you verify this point ? > There is no difference whether NAPI is enabled or not. I will welcome lspci -vx + gcc version + objdump -S of the r8169 module. -- Ueimor From serue@us.ibm.com Mon Sep 13 15:13:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:13:32 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DMDH3K031649 for ; Mon, 13 Sep 2004 15:13:24 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8DMCkqH232746; Mon, 13 Sep 2004 18:12:46 -0400 Received: from serge (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8DMDxbm064400; Mon, 13 Sep 2004 18:13:59 -0400 Subject: Re: [PATCH] BSD Jail LSM From: Serge Hallyn To: Alan Cox Cc: Chris Wright , Linux Kernel Mailing List , akpm@osdl.org, netdev@oss.sgi.com In-Reply-To: <1095072996.14355.12.camel@localhost.localdomain> References: <1094847705.2188.94.camel@serge.austin.ibm.com> <1094847787.2188.101.camel@serge.austin.ibm.com> <1094844708.18107.5.camel@localhost.localdomain> <20040912233342.GA12097@escher.cs.wm.edu> <1095072996.14355.12.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-avt0hE8IGefh4FxIYlf0" Message-Id: <1095117605.2350.11.camel@serge.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 13 Sep 2004 18:20:05 -0500 X-archive-position: 8742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: serue@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 40414 Lines: 1582 --=-avt0hE8IGefh4FxIYlf0 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2004-09-13 at 05:56, Alan Cox wrote: > On Llu, 2004-09-13 at 00:33, Serge E. Hallyn wrote: > > Right now one must choose between either an ipv4 or ipv6 interface. > > Is typical ipv6 usage such that it would be preferable to be able to > > specify one of each? > > Its normal to have both yes. The attached version supports simultaneous ipv4 and ipv6 addresses. (Though only one of each) Signed-off-by: Serge Hallyn --=-avt0hE8IGefh4FxIYlf0 Content-Disposition: attachment; filename=jail.diff Content-Type: text/x-patch; name=jail.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -Nru -p1 /home/hallyn/kernels/linux-2.6.8.1/security/bsdjail.c linux-2.6.8.1/security/bsdjail.c --- /home/hallyn/kernels/linux-2.6.8.1/security/bsdjail.c 1969-12-31 18:00:00.000000000 -0600 +++ linux-2.6.8.1/security/bsdjail.c 2004-09-13 18:00:09.475302344 -0500 @@ -0,0 +1,1528 @@ +/* + * File: linux/security/bsdjail.c + * Author: Serge Hallyn (serue@us.ibm.com) + * Date: Sep 12, 2004 + * + * (See Documentation/bsdjail.txt for more information) + * + * Copyright (C) 2004 International Business Machines + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int jail_debug = 0; +MODULE_PARM(jail_debug, "i"); +MODULE_PARM_DESC(jail_debug, "Print bsd jail debugging messages.\n"); + +#define DBG 0 +#define WARN 1 +#define bsdj_debug(how, fmt, arg... ) \ + do { \ + if ( how || jail_debug ) \ + printk(KERN_NOTICE "%s: %s: " fmt, \ + MY_NAME, __FUNCTION__, \ + ## arg ); \ + } while ( 0 ) + +#define MY_NAME "bsdjail" + +/* flag to keep track of how we were registered */ +static int secondary = 0; + +/* + * The task structure holding jail information. + * Taskp->security points to one of these (or is null). + * There is exactly one jail_struct for each jail. If >1 process + * are in the same jail, they share the same jail_struct. + */ +struct jail_struct { + struct kref kref; + + /* these are set on writes to /proc//attr/exec */ + char *root_pathname; /* char * containing path to use as jail / */ + char *ip4_addr_name; /* char * containing ip4 addr to use for jail */ + char *ip6_addr_name; /* char * containing ip6 addr to use for jail */ + + /* these are set when a jail becomes active */ + __u32 addr4; /* internal form of ip4_addr_name */ + struct in6_addr addr6; /* internal form of ip6_addr_name */ + + struct dentry *dentry; /* dentry of fs root */ + struct vfsmount *mnt; /* vfsmnt of fs root */ + + /* Resource limits. 0 = no limit */ + int max_nrtask; /* maximum number of tasks within this jail. */ + int cur_nrtask; /* current number of tasks within this jail. */ + long maxtimeslice; /* max timeslice in ms for procs in this jail */ + long nice; /* nice level for processes in this jail */ + long max_data, max_memlock; /* equivalent to RLIMIT_{DATA,MEMLOCK} */ +/* values for the jail_flags field */ +#define IN_USE 1 /* if 0, task is setting up jail, not yet in it */ +#define GOT_IPV4 2 +#define GOT_IPV6 4 /* if 0, ipv4, else ipv6 */ + char jail_flags; +}; + +#define in_use(x) (x->jail_flags & IN_USE) +#define set_in_use(x) (x->jail_flags |= IN_USE) + +#define got_network(x) (x->jail_flags & (GOT_IPV4 | GOT_IPV6)) +#define got_ipv4(x) (x->jail_flags & (GOT_IPV4)) +#define got_ipv6(x) (x->jail_flags & (GOT_IPV6)) +#define set_ipv4(x) (x->jail_flags |= GOT_IPV4) +#define set_ipv6(x) (x->jail_flags |= GOT_IPV6) +#define unset_got_ipv4(x) (x->jail_flags &= ~GOT_IPV4) +#define unset_got_ipv6(x) (x->jail_flags &= ~GOT_IPV6) + +/* + * structs, defines, and functions to cope with stacking + */ + +#define get_task_security(task) (task->security) +#define get_inode_security(inode) (inode->i_security) +#define get_sock_security(sock) (sock->sk_security) +#define get_file_security(file) (file->f_security) +#define get_ipc_security(ipc) (ipc->security) + +#define jail_of(proc) (get_task_security(proc)) + +/* + * disable_jail: A jail which was in use, but has no references + * left, is disabled - we free up the mountpoint and dentry, and + * give up our reference on the module. + * + * don't need to put namespace, it will be done automatically + * when the last process in jail is put. + * DO need to put the dentry and vfsmount + */ +static void +disable_jail(struct jail_struct *tsec) +{ + dput(tsec->dentry); + mntput(tsec->mnt); + module_put(THIS_MODULE); +} + + +static void free_jail(struct jail_struct *tsec) +{ + if (!tsec) + return; + + if (tsec->root_pathname) + kfree(tsec->root_pathname); + if (tsec->ip4_addr_name) + kfree(tsec->ip4_addr_name); + if (tsec->ip6_addr_name) + kfree(tsec->ip6_addr_name); + kfree(tsec); +} + +#define set_task_security(task,data) task->security = data +#define set_inode_security(inode,data) inode->i_security = data +#define set_sock_security(sock,data) sock->sk_security = data +#define set_file_security(file,data) file->f_security = data +#define set_ipc_security(ipc,data) ipc.security = data + +/* + * jail_task_free_security: this is the callback hooked into LSM. + * If there was no task->security field for bsdjail, do nothing. + * If there was, but it was never put into use, free the jail. + * If there was, and the jail is in use, then decrement the usage + * count, and disable and free the jail if the usage count hits 0. + */ +static void jail_task_free_security(struct task_struct *task) +{ + struct jail_struct *tsec; + + tsec = get_task_security(task); + + if (!tsec) + return; + + if (!in_use(tsec)) { + /* + * someone did 'echo -n x > /proc//attr/exec' but + * then forked before execing. Nuke the old info. + */ + free_jail(tsec); + set_task_security(task,NULL); + return; + } + tsec->cur_nrtask--; + /* If this was the last process in the jail, delete the jail */ + kref_put(&tsec->kref); +} + +static struct jail_struct * +alloc_task_security(struct task_struct *tsk) +{ + struct jail_struct *tsec; + tsec = kmalloc(sizeof(struct jail_struct), GFP_KERNEL); + if (!tsec) + return ERR_PTR(-ENOMEM); + memset(tsec, 0, sizeof(struct jail_struct)); + set_task_security(tsk, tsec); + return tsec; +} + +static inline int +in_jail(struct task_struct *t) +{ + struct jail_struct *tsec = jail_of(t); + + if (tsec && in_use(tsec)) + return 1; + + return 0; +} + +/* + * If a network address was passed into /proc//attr/exec, + * then process in its jail will only be allowed to bind/listen + * to that address. + */ +static void +setup_netaddress(struct jail_struct *tsec) +{ + unsigned int a,b,c,d, i; + unsigned int x[8]; + + unset_got_ipv4(tsec); + tsec->addr4 = 0; + unset_got_ipv6(tsec); + ipv6_addr_set(&tsec->addr6, 0, 0, 0, 0); + + if (tsec->ip4_addr_name) { + if (sscanf(tsec->ip4_addr_name,"%u.%u.%u.%u",&a,&b,&c,&d)!=4) + return; + if (a>255 || b>255 || c>255 || d>255) + return; + tsec->addr4 = htonl((a<<24)|(b<<16)|(c<<8)|d); + set_ipv4(tsec); + bsdj_debug(DBG, "Network (ipv4) set up (%s)\n", + tsec->ip4_addr_name); + } + + if (tsec->ip6_addr_name) { + if (sscanf(tsec->ip6_addr_name,"%x:%x:%x:%x:%x:%x:%x:%x", + &x[0], &x[1], &x[2], &x[3], &x[4], &x[5], &x[6], + &x[7]) != 8) { + printk(KERN_INFO "%s: bad ipv6 addr %s\n", __FUNCTION__, + tsec->ip6_addr_name); + return; + } + for (i=0; i<8; i++) { + if (x[i] > 65535) { + printk("%s: %x > 65535 at %d\n", __FUNCTION__, x[i], i); + return; + } + tsec->addr6.in6_u.u6_addr16[i] = htons(x[i]); + } + set_ipv6(tsec); + bsdj_debug(DBG, "Network (ipv6) set up (%s)\n", + tsec->ip6_addr_name); + } +} + +/* release_jail: + * Callback for kref_put to use for releasing a jail when its + * last user exits. + */ +static void release_jail(struct kref *kref) +{ + struct jail_struct *tsec; + + tsec = container_of(kref,struct jail_struct,kref); + disable_jail(tsec); + free_jail(tsec); +} + +/* + * enable_jail: + * Called when a process is placed into a new jail to handle the + * actual creation of the jail. + * Creates namespace + * Sets process root+pwd + * Stores the requested ip address + * Registers a unique pseudo-proc filesystem for this jail + */ +static int enable_jail(struct task_struct *tsk) +{ + struct nameidata nd; + struct jail_struct *tsec; + int retval = -EFAULT; + + tsec = jail_of(tsk); + if (!tsec || !tsec->root_pathname) + goto out; + + /* + * USE_JAIL_NAMESPACE: could be useful, so that future mounts outside + * the jail don't affect the jail. But it's not necessary, and + * requires exporting copy_namespace from fs/namespace.c + * + * Actually, it would also be useful for truly hiding + * information about mounts which do not exist in this jail. +#define USE_JAIL_NAMESPACE + */ +#ifdef USE_JAIL_NAMESPACE + bsdj_debug(DBG, "bsdjail: copying namespace.\n"); + retval = -EPERM; + if (copy_namespace(CLONE_NEWNS, tsk)) + goto out; + bsdj_debug(DBG, "bsdjail: copied namespace.\n"); +#endif + + /* find our new root directory */ + bsdj_debug(DBG, "bsdjail: looking up %s\n", tsec->root_pathname); + retval = path_lookup(tsec->root_pathname, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &nd); + if (retval) + goto out; + + bsdj_debug(DBG, "bsdjail: got %s, setting root to it\n", tsec->root_pathname); + + /* and set the fsroot to it */ + set_fs_root(tsk->fs, nd.mnt, nd.dentry); + set_fs_pwd(tsk->fs, nd.mnt, nd.dentry); + + bsdj_debug(DBG, "bsdjail: root has been set. Have fun.\n"); + + /* set up networking */ + if (tsec->ip4_addr_name || tsec->ip6_addr_name) + setup_netaddress(tsec); + + tsec->cur_nrtask = 1; + if (tsec->nice) + set_user_nice(current, tsec->nice); + if (tsec->max_data) { + current->rlim[RLIMIT_DATA].rlim_cur = tsec->max_data; + current->rlim[RLIMIT_DATA].rlim_max = tsec->max_data; + } + if (tsec->max_memlock) { + current->rlim[RLIMIT_MEMLOCK].rlim_cur = tsec->max_memlock; + current->rlim[RLIMIT_MEMLOCK].rlim_max = tsec->max_memlock; + } + if (tsec->maxtimeslice) { + current->rlim[RLIMIT_CPU].rlim_cur = tsec->maxtimeslice; + current->rlim[RLIMIT_CPU].rlim_max = tsec->maxtimeslice; + } + /* success and end */ + tsec->mnt = mntget(nd.mnt); + tsec->dentry = dget(nd.dentry); + path_release(&nd); + kref_init(&tsec->kref, release_jail); + set_in_use(tsec); + + /* won't let ourselves be removed until this jail goes away */ + try_module_get(THIS_MODULE); + + return 0; + +out: + return retval; +} + +/* + * LSM /proc//attr hooks. + * You may write into /proc//attr/exec: + * root /some/path + * ip 2.2.2.2 + * These values will be used on the next exec() to set up your jail + * (assuming you're not already in a jail) + */ +static int +jail_setprocattr(struct task_struct *p, char *name, void *value, size_t size) +{ + struct jail_struct *tsec = jail_of(current); + long val; + int start, len; + + if (tsec && in_use(tsec)) + return -EINVAL; /* let them guess why */ + + if (p != current || strcmp(name, "exec")) + return -EPERM; + + if (strncmp(value, "root ", 5)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + if (tsec->root_pathname) + kfree(tsec->root_pathname); + start = 5; + len = size-start; + tsec->root_pathname = kmalloc(len+1, GFP_KERNEL); + if (!tsec->root_pathname) + return -ENOMEM; + strncpy(tsec->root_pathname, value+start, len); + tsec->root_pathname[len] = '\0'; + } else if (strncmp(value, "ip ", 3)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + if (tsec->ip4_addr_name) + kfree(tsec->ip4_addr_name); + start = 3; + len = size-start; + tsec->ip4_addr_name = kmalloc(len+1, GFP_KERNEL); + if (!tsec->ip4_addr_name) + return -ENOMEM; + strncpy(tsec->ip4_addr_name, value+start, len); + tsec->ip4_addr_name[len] = '\0'; + } else if (strncmp(value, "ip6 ", 4) == 0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + if (tsec->ip6_addr_name) + kfree(tsec->ip6_addr_name); + start = 4; + len = size-start; + tsec->ip6_addr_name = kmalloc(len+1, GFP_KERNEL); + if (!tsec->ip6_addr_name) + return -ENOMEM; + strncpy(tsec->ip6_addr_name, value+start, len); + tsec->ip6_addr_name[len] = '\0'; + + /* the next two are equivalent */ + } else if (strncmp(value, "slice ", 6)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + val = simple_strtoul(value+6, NULL, 0); + tsec->maxtimeslice = val; + } else if (strncmp(value, "timeslice ", 10)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + val = simple_strtoul(value+10, NULL, 0); + tsec->maxtimeslice = val; + } else if (strncmp(value, "nrtask ", 7)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + val = (int) simple_strtol(value+7, NULL, 0); + if (val < 1) + return -EINVAL; + tsec->max_nrtask = val; + } else if (strncmp(value, "memlock ", 8)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + val = simple_strtoul(value+8, NULL, 0); + tsec->max_memlock = val; + } else if (strncmp(value, "data ", 5)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + val = simple_strtoul(value+5, NULL, 0); + tsec->max_data = val; + } else if (strncmp(value, "nice ", 5)==0) { + if (!tsec) + tsec = alloc_task_security(current); + if (IS_ERR(tsec)) + return -ENOMEM; + + val = simple_strtoul(value+5, NULL, 0); + tsec->nice = val; + } else + return -EINVAL; + + return size; +} + +static int print_jail_net_info(struct jail_struct *j, char *buf, int maxcnt) +{ + int len = 0; + + if (j->ip4_addr_name) + len += snprintf(buf, maxcnt, "%s\n", j->ip4_addr_name); + if (j->ip6_addr_name) + len += snprintf(buf, maxcnt-len, "%s\n", j->ip6_addr_name); + + return snprintf(buf, maxcnt, "No network information\n"); +} + +/* + * LSM /proc//attr read hook. + * + * /proc/$$/attr/current output: + * If the reading process, say process 1001, is in a jail, then + * cat /proc/999/attr/current + * will print networking information. + * If the reading process, say process 1001, is not in a jail, then + * cat /proc/999/attr/current + * will return + * root: (root of jail) + * ip: (ip address of jail) + * if 999 is in a jail, or + * -EINVAL + * if 999 is not in a jail. + * + * /proc/$$/attr/exec output: + * A process in a jail gets -EINVAL for /proc/$$/attr/exec. + * A process not in a jail gets hints on starting a jail. + */ +static int +jail_getprocattr(struct task_struct *p, char *name, void *value, size_t size) +{ + struct jail_struct *tsec; + int err = 0; + + if (in_jail(current)) { + if (strcmp(name, "current")==0) { + /* provide network info */ + err = print_jail_net_info(jail_of(current), value, + size); + return err; + } + return -EINVAL; /* let them guess why */ + } + + if (strcmp(name, "exec") == 0) { + /* Print usage some help */ + err = snprintf(value, size, + "Valid keywords:\n" + "root \n" + "ip \n" + "ip6 \n" + "nrtask \n" + "nice \n" + "slice \n" + "data \n" + "memlock \n"); + return err; + } + + if (strcmp(name, "current")) + return -EPERM; + + tsec = jail_of(p); + if (!tsec || !in_use(tsec)) { + err = snprintf(value, size, "Not Jailed\n"); + } else { + err = snprintf(value, size, + "Root: %s\nIPv4: %s\nIPv6: %s\n" + "max_nrtask %d current nrtask %d max_timeslice %lu " + "nice %lu\n" + "max_memlock %lu max_data %lu\n", + tsec->root_pathname, + tsec->ip4_addr_name ? tsec->ip4_addr_name : "(none)", + tsec->ip6_addr_name ? tsec->ip6_addr_name : "(none)", + tsec->max_nrtask, tsec->cur_nrtask, tsec->maxtimeslice, + tsec->nice, tsec->max_data, tsec->max_memlock); + } + + return err; +} + +/* + * Forbid a process in a jail from sending a signal to a process in another + * (or no) jail through file sigio. + * + * We consider the process which set the fowner to be the one sending the + * signal, rather than the one writing to the file. Therefore we store the + * jail of a process during jail_file_set_fowner, then check that against + * the jail of the process receiving the signal. + */ +static int +jail_file_send_sigiotask(struct task_struct *tsk, struct fown_struct *fown, + int fd, int reason) +{ + struct file *file; + struct jail_struct *tsec, *fsec; + + if (!in_jail(current)) + return 0; + + file = (struct file *)((long)fown - offsetof(struct file,f_owner)); + tsec = jail_of(tsk); + fsec = get_file_security(file); + + if (fsec != tsec) + return -EPERM; + + return 0; +} + +static int +jail_file_set_fowner(struct file *file) +{ + struct jail_struct *tsec; + + tsec = jail_of(current); + set_file_security(file, tsec); + if (tsec) + kref_get(&tsec->kref); + + return 0; +} + +static void free_ipc_security(struct kern_ipc_perm *ipc) +{ + struct jail_struct *tsec; + + tsec = get_ipc_security(ipc); + if (!tsec) + return; + kref_put(&tsec->kref); + set_ipc_security((*ipc), NULL); +} + +static void free_file_security(struct file *file) +{ + struct jail_struct *tsec; + + tsec = get_file_security(file); + if (!tsec) + return; + kref_put(&tsec->kref); + set_file_security(file, NULL); +} + +static void free_inode_security(struct inode *inode) +{ + struct jail_struct *tsec; + + tsec = get_inode_security(inode); + if (!tsec) + return; + kref_put(&tsec->kref); + set_inode_security(inode, NULL); +} + +/* + * LSM ptrace hook: + * process in jail may not ptrace process not in the same jail + */ +static int +jail_ptrace (struct task_struct *tracer, struct task_struct *tracee) +{ + struct jail_struct *tsec = jail_of(tracer); + + if (tsec && in_use(tsec)) { + if (tsec == jail_of(tracee)) + return 0; + return -EPERM; + } + return 0; +} + +/* + * process in jail may only use one (aliased) ip address. If they try to + * attach to 127.0.0.1, that is remapped to their own address. If some + * other address (and not their own), deny permission + */ +static int jail_socket_unix_bind(struct socket *sock, struct sockaddr *address, + int addrlen); + +#define loopbackaddr htonl((127 << 24) | 1) + +static inline int jail_inet4_bind(struct socket *sock, struct sockaddr *address, + int addrlen, struct jail_struct *tsec) +{ + struct sockaddr_in *inaddr; + __u32 sin_addr, jailaddr; + + if (!got_ipv4(tsec)) + return -EPERM; + + inaddr = (struct sockaddr_in *)address; + sin_addr = inaddr->sin_addr.s_addr; + jailaddr = tsec->addr4; + + if (sin_addr == jailaddr) + return 0; + + if (sin_addr == loopbackaddr || !sin_addr) { + bsdj_debug(DBG, "Got a loopback or 0 address\n"); + sin_addr = jailaddr; + bsdj_debug(DBG, "Converted to: %u.%u.%u.%u\n", + NIPQUAD(sin_addr)); + return 0; + } + + return -EPERM; +} + +static inline int +jail_inet6_bind(struct socket *sock, struct sockaddr *address, int addrlen, + struct jail_struct *tsec) +{ + struct sockaddr_in6 *inaddr6; + struct in6_addr *sin6_addr, *jailaddr; + + if (!got_ipv6(tsec)) + return -EPERM; + + inaddr6 = (struct sockaddr_in6 *)address; + sin6_addr = &inaddr6->sin6_addr; + jailaddr = &tsec->addr6; + + if (ipv6_addr_cmp(jailaddr, sin6_addr)==0) + return 0; + + if (ipv6_addr_cmp(sin6_addr, &in6addr_loopback)==0) { + ipv6_addr_copy(sin6_addr, jailaddr); + return 0; + } + + printk(KERN_NOTICE "%s: DENYING\n", __FUNCTION__); + printk(KERN_NOTICE "%s: a %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x " + "j %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x\n", + __FUNCTION__, + NIP6(*sin6_addr), + NIP6(*jailaddr)); + + return -EPERM; +} + +static int +jail_socket_bind(struct socket *sock, struct sockaddr *address, int addrlen) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + + if (sock->sk->sk_family == AF_UNIX) + return jail_socket_unix_bind(sock, address, addrlen); + + if (!got_network(tsec)) + /* If we want to be strict, we could just + * deny net access when lacking a pseudo ip. + * For now we just allow it. */ + return 0; + + switch(address->sa_family) { + case AF_INET: + return jail_inet4_bind(sock, address, addrlen, tsec); + + case AF_INET6: + return jail_inet6_bind(sock, address, addrlen, tsec); + + default: + return 0; + } +} + +/* + * If locked in an ipv6 jail, don't let them use ipv4, and vice versa + */ +static int +jail_socket_create(int family, int type, int protocol, int kern) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec) || kern || !got_network(tsec)) + return 0; + + switch(family) { + case AF_INET: + if (got_ipv4(tsec)) + return 0; + return -EPERM; + case AF_INET6: + if (got_ipv6(tsec)) + return 0; + return -EPERM; + default: + return 0; + }; + + return 0; +} + +static void +jail_socket_post_create(struct socket *sock, int family, int type, + int protocol, int kern) +{ + struct inet_opt *inet; + struct ipv6_pinfo *inet6; + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec) || kern || !got_network(tsec)) + return; + + switch(family) { + case AF_INET: + inet = inet_sk(sock->sk); + inet->saddr = tsec->addr4; + break; + case AF_INET6: + inet6 = inet6_sk(sock->sk); + ipv6_addr_copy(&inet6->saddr, &tsec->addr6); + break; + default: + break; + }; + + return; +} + +static int +jail_socket_listen(struct socket *sock, int backlog) +{ + struct inet_opt *inet; + struct ipv6_pinfo *inet6; + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec) || !got_network(tsec)) + return 0; + + switch (sock->sk->sk_family) { + case AF_INET: + inet = inet_sk(sock->sk); + if (inet->saddr == tsec->addr4) + return 0; + return -EPERM; + + case AF_INET6: + inet6 = inet6_sk(sock->sk); + if (ipv6_addr_cmp(&inet6->saddr, &tsec->addr6)==0) + return 0; + return -EPERM; + + default: + return 0; + + } +} + +static void free_sock_security(struct sock *sk) +{ + struct jail_struct *tsec; + + tsec = get_sock_security(sk); + if (!tsec) + return; + kref_put(&tsec->kref); + set_sock_security(sk, NULL); +} + +/* + * The next three (socket) hooks prevent a process in a jail from sending + * data to a abstract unix domain socket which was bound outside the jail. + */ +static int +jail_socket_unix_bind(struct socket *sock, struct sockaddr *address, + int addrlen) +{ + struct sockaddr_un *sunaddr; + struct jail_struct *tsec; + + if (sock->sk->sk_family != AF_UNIX) + return 0; + + sunaddr = (struct sockaddr_un *)address; + if (sunaddr->sun_path[0] != 0) + return 0; + + tsec = jail_of(current); + set_sock_security(sock->sk, tsec); + if (tsec) + kref_get(&tsec->kref); + return 0; +} + +/* + * Note - we deny sends both from unjailed to jailed, and from jailed + * to unjailed. As well as, of course between different jails. + */ +static int +jail_socket_unix_may_send(struct socket *sock, struct socket *other) +{ + struct jail_struct *tsec, *ssec; + + tsec = jail_of(current); /* jail of sending process */ + ssec = get_sock_security(other->sk); /* jail of receiver */ + + if (tsec != ssec) + return -EPERM; + + return 0; +} + +static int +jail_socket_unix_stream_connect(struct socket *sock, + struct socket *other, struct sock *newsk) +{ + struct jail_struct *tsec, *ssec; + + tsec = jail_of(current); /* jail of sending process */ + ssec = get_sock_security(other->sk); /* jail of receiver */ + + if (tsec != ssec) + return -EPERM; + + return 0; +} + +static int +jail_mount(char * dev_name, struct nameidata *nd, char * type, + unsigned long flags, void * data) +{ + if (in_jail(current)) + return -EPERM; + + return 0; +} + +static int +jail_umount(struct vfsmount *mnt, int flags) +{ + if (in_jail(current)) + return -EPERM; + + return 0; +} + +/* + * process in jail may not: + * use nice + * change network config + * load/unload modules + */ +static int +jail_capable (struct task_struct *tsk, int cap) +{ + if (in_jail(tsk)) { + if (cap == CAP_SYS_NICE) + return -EPERM; + if (cap == CAP_NET_ADMIN) + return -EPERM; + if (cap == CAP_SYS_MODULE) + return -EPERM; + if (cap == CAP_SYS_RAWIO) + return -EPERM; + } + + if (cap_is_fs_cap (cap) ? tsk->fsuid == 0 : tsk->euid == 0) + return 0; + return -EPERM; +} + +/* + * jail_security_task_create: + * + * If the current process is ina a jail, and that jail is about to exceed a + * maximum number of processes, then refuse to fork. If the maximum number + * of jails is listed as 0, then there is no limit for this jail, and we allow + * all forks. + */ +static inline int +jail_security_task_create (unsigned long clone_flags) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + + if (tsec->max_nrtask && tsec->cur_nrtask >= tsec->max_nrtask) + return -EPERM; + return 0; +} + +/* + * The child of a process in a jail belongs in the same jail + */ +static int +jail_task_alloc_security(struct task_struct *tsk) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + + set_task_security(tsk, tsec); + kref_get(&tsec->kref); + tsec->cur_nrtask++; + if (tsec->maxtimeslice) { + tsk->rlim[RLIMIT_CPU].rlim_max = tsec->maxtimeslice; + tsk->rlim[RLIMIT_CPU].rlim_cur = tsec->maxtimeslice; + } + if (tsec->max_data) { + tsk->rlim[RLIMIT_CPU].rlim_max = tsec->max_data; + tsk->rlim[RLIMIT_CPU].rlim_cur = tsec->max_data; + } + if (tsec->max_memlock) { + tsk->rlim[RLIMIT_CPU].rlim_max = tsec->max_memlock; + tsk->rlim[RLIMIT_CPU].rlim_cur = tsec->max_memlock; + } + if (tsec->nice) + set_user_nice(current, tsec->nice); + + return 0; +} + +static int +jail_bprm_alloc_security(struct linux_binprm *bprm) +{ + struct jail_struct *tsec; + int ret; + + tsec = jail_of(current); + if (!tsec) + return 0; + + if (in_use(tsec)) + return 0; + + if (tsec->root_pathname) { + ret = enable_jail(current); + if (ret) { + /* if we failed, nix out the root/ip requests */ + jail_task_free_security(current); + return ret; + } + } + return 0; +} + +/* + * Process in jail may not create devices + * Thanks to Brad Spender for pointing out fifos should be allowed. + */ +/* TODO: We may want to allow /dev/log, at least... */ +static int +jail_inode_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev) +{ + if (!in_jail(current)) + return 0; + + if (S_ISFIFO(mode)) + return 0; + + return -EPERM; +} + +/* yanked from fs/proc/base.c */ +static unsigned name_to_int(struct dentry *dentry) +{ + const char *name = dentry->d_name.name; + int len = dentry->d_name.len; + unsigned n = 0; + + if (len > 1 && *name == '0') + goto out; + while (len-- > 0) { + unsigned c = *name++ - '0'; + if (c > 9) + goto out; + if (n >= (~0U-9)/10) + goto out; + n *= 10; + n += c; + } + return n; +out: + return ~0U; +} + +/* + * jail_proc_inode_permission: + * called only when current is in a jail, and is trying to reach + * /proc/. We check whether is in the same jail as + * current. If not, permission is denied. + * + * NOTE: On the one hand, the task_to_inode(inode)->i_security + * approach seems cleaner, but on the other, this prevents us + * from unloading bsdjail for awhile... + */ +static int +jail_proc_inode_permission(struct inode *inode, int mask, + struct nameidata *nd) +{ + struct jail_struct *tsec = jail_of(current); + struct dentry *dentry = nd->dentry; + unsigned pid; + + pid = name_to_int(dentry); + if (pid == ~0U) { + struct qstr *dname = &dentry->d_name; + if (strcmp(dname->name, "scsi")==0 || + strcmp(dname->name, "sys")==0 || + strcmp(dname->name, "ide")==0) + return -EPERM; + return 0; + } + + if (dentry->d_parent != dentry->d_sb->s_root) + return 0; + if (get_inode_security(inode) != tsec) + return -ENOENT; + + return 0; +} + +/* + * Here is our attempt to prevent chroot escapes. + */ +static int +is_jailroot_parent(struct dentry *candidate, struct dentry *root, + struct vfsmount *rootmnt) +{ + if (candidate == root) + return 0; + + /* simple case: fs->root/.. == candidate */ + if (root->d_parent == candidate) + return 1; + + /* + * now more complicated: if fs->root is a mounted directory, + * then chdir(..) out of fs->root, at follow_dotdot, will follow + * the fs->root mount point. So we must check the parent dir of + * the fs->root mount point. + */ + if (rootmnt->mnt_root == root && rootmnt->mnt_mountpoint!=root) { + root = rootmnt->mnt_mountpoint; + rootmnt = rootmnt->mnt_parent; + return is_jailroot_parent(candidate, root, rootmnt); + } + + return 0; +} + +/* + * A process in a jail may not see that /proc/ exists for + * process not in its jail + * Unfortunately we can't pretend that pid for the starting process + * is 1, as vserver does. + */ +static int jail_task_lookup(struct task_struct *p) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec) + return 0; + if (tsec == jail_of(p)) + return 0; + return -EPERM; +} +/* + * security_task_to_inode: + * Set inode->security = task's jail. + */ +static void jail_task_to_inode(struct task_struct *p, struct inode *inode) +{ + struct jail_struct *tsec = jail_of(p); + + if (!tsec || !in_use(tsec)) + return; + if (get_inode_security(inode)) + return; + kref_get(&tsec->kref); + set_inode_security(inode, tsec); +} + +/* + * inode_permission: + * If we are trying to look into certain /proc files from in a jail, we + * may deny permission. + * If we are trying to cd(..), but the cwd is the root of our jail, then + * permission is denied. + */ +static int +jail_inode_permission(struct inode *inode, int mask, + struct nameidata *nd) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + + if (!nd) + return 0; + + if (nd->dentry && + strcmp(nd->dentry->d_sb->s_type->name, "proc")==0) { + return jail_proc_inode_permission(inode, mask, nd); + + } + + if (!(mask&MAY_EXEC)) + return 0; + if (!inode || !S_ISDIR(inode->i_mode)) + return 0; + + if (is_jailroot_parent(nd->dentry, tsec->dentry, tsec->mnt)) { + bsdj_debug(WARN,"Attempt to chdir(..) out of jail!\n" + "(%s is a subdir of %s)\n", + tsec->dentry->d_name.name, + nd->dentry->d_name.name); + return -EPERM; + } + + return 0; +} + +/* + * A function which returns -ENOENT if dentry is the dentry for + * a /proc/ directory. It returns 0 otherwise. + */ +static inline int +generic_procpid_check(struct dentry *dentry) +{ + struct jail_struct *jail = jail_of(current); + unsigned pid = name_to_int(dentry); + + if (!jail || !in_use(jail)) + return 0; + if (pid == ~0U) + return 0; + if (strcmp(dentry->d_sb->s_type->name, "proc")!=0) + return 0; + if (dentry->d_parent != dentry->d_sb->s_root) + return 0; + if (get_inode_security(dentry->d_inode) != jail) + return -ENOENT; + return 0; +} + +/* + * We want getattr to fail on /proc/ to prevent leakage through, for + * instance, ls -d. + */ +static int +jail_inode_getattr(struct vfsmount *mnt, struct dentry *dentry) +{ + return generic_procpid_check(dentry); +} + +/* This probably is not necessary - /proc does not support xattrs? */ +static int +jail_inode_getxattr(struct dentry *dentry, char *name) +{ + return generic_procpid_check(dentry); +} + +/* process in jail may not send signal to process not in the same jail */ +static int +jail_task_kill(struct task_struct *p, struct siginfo *info, int sig) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + + if (tsec == jail_of(p)) + return 0; + + if (sig==SIGCHLD) + return 0; + + return -EPERM; +} + +/* + * LSM hooks to limit jailed process' abilities to muck with resource + * limits + */ +static int jail_task_setrlimit (unsigned int resource, struct rlimit *new_rlim) +{ + if (!in_jail(current)) + return 0; + + return -EPERM; +} + +static int jail_task_setscheduler (struct task_struct *p, int policy, + struct sched_param *lp) +{ + if (!in_jail(current)) + return 0; + + return -EPERM; +} + +/* + * LSM hooks to limit IPC access. + */ + +static inline int +basic_ipc_security_check(struct kern_ipc_perm *p, struct task_struct *target) +{ + struct jail_struct *tsec = jail_of(target); + + if (!tsec || !in_use(tsec)) + return 0; + + if (get_ipc_security(p) != tsec) + return -EPERM; + + return 0; +} + +static int +jail_ipc_permission(struct kern_ipc_perm *ipcp, short flag) +{ + return basic_ipc_security_check(ipcp, current); +} + +static int +jail_shm_alloc_security (struct shmid_kernel *shp) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + set_ipc_security(shp->shm_perm, tsec); + kref_get(&tsec->kref); + return 0; +} + +static void +jail_shm_free_security (struct shmid_kernel *shp) +{ + free_ipc_security(&shp->shm_perm); +} + +static int +jail_shm_associate (struct shmid_kernel *shp, int shmflg) +{ + return basic_ipc_security_check(&shp->shm_perm, current); +} + +static int +jail_shm_shmctl(struct shmid_kernel *shp, int cmd) +{ + if (cmd == IPC_INFO || cmd == SHM_INFO) + return 0; + + return basic_ipc_security_check(&shp->shm_perm, current); +} + +static int +jail_shm_shmat(struct shmid_kernel *shp, char *shmaddr, int shmflg) +{ + return basic_ipc_security_check(&shp->shm_perm, current); +} + +static int +jail_msg_queue_alloc(struct msg_queue *msq) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + set_ipc_security(msq->q_perm, tsec); + kref_get(&tsec->kref); + return 0; +} + +static void +jail_msg_queue_free(struct msg_queue *msq) +{ + free_ipc_security(&msq->q_perm); +} + +static int jail_msg_queue_associate(struct msg_queue *msq, int flag) +{ + return basic_ipc_security_check(&msq->q_perm, current); +} + +static int +jail_msg_queue_msgctl(struct msg_queue *msq, int cmd) +{ + if (cmd == IPC_INFO || cmd == MSG_INFO) + return 0; + + return basic_ipc_security_check(&msq->q_perm, current); +} + +static int +jail_msg_queue_msgsnd(struct msg_queue *msq, struct msg_msg *msg, int msqflg) +{ + return basic_ipc_security_check(&msq->q_perm, current); +} + +static int +jail_msg_queue_msgrcv(struct msg_queue *msq, struct msg_msg *msg, + struct task_struct *target, long type, int mode) + +{ + return basic_ipc_security_check(&msq->q_perm, target); +} + +static int +jail_sem_alloc_security(struct sem_array *sma) +{ + struct jail_struct *tsec = jail_of(current); + + if (!tsec || !in_use(tsec)) + return 0; + set_ipc_security(sma->sem_perm, tsec); + kref_get(&tsec->kref); + return 0; +} + +static void +jail_sem_free_security(struct sem_array *sma) +{ + free_ipc_security(&sma->sem_perm); +} + +static int +jail_sem_associate(struct sem_array *sma, int semflg) +{ + return basic_ipc_security_check(&sma->sem_perm, current); +} + +static int +jail_sem_semctl(struct sem_array *sma, int cmd) +{ + if (cmd == IPC_INFO || cmd == SEM_INFO) + return 0; + return basic_ipc_security_check(&sma->sem_perm, current); +} + +static int +jail_sem_semop(struct sem_array *sma, struct sembuf *sops, unsigned nsops, + int alter) +{ + return basic_ipc_security_check(&sma->sem_perm, current); +} + +static struct security_operations bsdjail_security_ops = { + .ptrace = jail_ptrace, + .capable = jail_capable, + + .task_kill = jail_task_kill, + .task_alloc_security = jail_task_alloc_security, + .task_free_security = jail_task_free_security, + .bprm_alloc_security = jail_bprm_alloc_security, + .task_create = jail_security_task_create, + .task_to_inode = jail_task_to_inode, + .task_lookup = jail_task_lookup, + + .task_setrlimit = jail_task_setrlimit, + .task_setscheduler = jail_task_setscheduler, + + .setprocattr = jail_setprocattr, + .getprocattr = jail_getprocattr, + + .file_set_fowner = jail_file_set_fowner, + .file_send_sigiotask = jail_file_send_sigiotask, + .file_free_security = free_file_security, + + .socket_bind = jail_socket_bind, + .socket_listen = jail_socket_listen, + .socket_create = jail_socket_create, + .socket_post_create = jail_socket_post_create, + .unix_stream_connect = jail_socket_unix_stream_connect, + .unix_may_send = jail_socket_unix_may_send, + .sk_free_security = free_sock_security, + + .inode_mknod = jail_inode_mknod, + .inode_permission = jail_inode_permission, + .inode_free_security = free_inode_security, + .inode_getattr = jail_inode_getattr, + .inode_getxattr = jail_inode_getxattr, + .sb_mount = jail_mount, + .sb_umount = jail_umount, + + .ipc_permission = jail_ipc_permission, + .shm_alloc_security = jail_shm_alloc_security, + .shm_free_security = jail_shm_free_security, + .shm_associate = jail_shm_associate, + .shm_shmctl = jail_shm_shmctl, + .shm_shmat = jail_shm_shmat, + + .msg_queue_alloc_security = jail_msg_queue_alloc, + .msg_queue_free_security = jail_msg_queue_free, + .msg_queue_associate = jail_msg_queue_associate, + .msg_queue_msgctl = jail_msg_queue_msgctl, + .msg_queue_msgsnd = jail_msg_queue_msgsnd, + .msg_queue_msgrcv = jail_msg_queue_msgrcv, + + .sem_alloc_security = jail_sem_alloc_security, + .sem_free_security = jail_sem_free_security, + .sem_associate = jail_sem_associate, + .sem_semctl = jail_sem_semctl, + .sem_semop = jail_sem_semop, +}; + +static int __init bsdjail_init (void) +{ + int rc = 0; + + if (register_security (&bsdjail_security_ops)) { + printk (KERN_INFO + "Failure registering BSD Jail module with the kernel\n"); + + rc = mod_reg_security(MY_NAME, &bsdjail_security_ops); + if (rc < 0) { + printk (KERN_INFO "Failure registering BSD Jail " + " module with primary security module.\n"); + return -EINVAL; + } + secondary = 1; + } + printk (KERN_INFO "BSD Jail module initialized.\n"); + + return 0; +} + +static void __exit bsdjail_exit (void) +{ + if (secondary) { + if (mod_unreg_security (MY_NAME, &bsdjail_security_ops)) + printk (KERN_INFO "Failure unregistering BSD Jail " + " module with primary module.\n"); + } else { + if (unregister_security (&bsdjail_security_ops)) { + printk (KERN_INFO "Failure unregistering BSD Jail " + "module with the kernel\n"); + } + } + + printk (KERN_INFO "BSD Jail module removed\n"); +} + +security_initcall (bsdjail_init); +module_exit (bsdjail_exit); + +MODULE_DESCRIPTION("BSD Jail LSM."); +MODULE_LICENSE("GPL"); diff -Nru -p1 /home/hallyn/kernels/linux-2.6.8.1/security/Kconfig linux-2.6.8.1/security/Kconfig --- /home/hallyn/kernels/linux-2.6.8.1/security/Kconfig 2004-08-14 05:55:47.000000000 -0500 +++ linux-2.6.8.1/security/Kconfig 2004-09-13 11:49:28.000000000 -0500 @@ -48,2 +48,13 @@ source security/selinux/Kconfig +config SECURITY_BSDJAIL + tristate "BSD Jail LSM" + depends on SECURITY + select SECURITY_NETWORK + help + Provides BSD Jail compartmentalization functionality. + See Documentation/bsdjail.txt for more information and + usage instructions. + + If you are unsure how to answer this question, answer N. + endmenu diff -Nru -p1 /home/hallyn/kernels/linux-2.6.8.1/security/Makefile linux-2.6.8.1/security/Makefile --- /home/hallyn/kernels/linux-2.6.8.1/security/Makefile 2004-08-14 05:55:48.000000000 -0500 +++ linux-2.6.8.1/security/Makefile 2004-09-13 11:49:28.000000000 -0500 @@ -17 +17,2 @@ obj-$(CONFIG_SECURITY_CAPABILITIES) += c obj-$(CONFIG_SECURITY_ROOTPLUG) += commoncap.o root_plug.o +obj-$(CONFIG_SECURITY_BSDJAIL) += bsdjail.o --=-avt0hE8IGefh4FxIYlf0-- From davem@davemloft.net Mon Sep 13 15:33:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:33:46 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DMXfvZ032488 for ; Mon, 13 Sep 2004 15:33:41 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6zMQ-00049N-00; Mon, 13 Sep 2004 15:31:46 -0700 Date: Mon, 13 Sep 2004 15:31:46 -0700 From: "David S. Miller" To: S P Cc: netdev@oss.sgi.com Subject: Re: [PATCH] linux 2.6.x.x net/sched/sch_api.c -- more comment reviews Message-Id: <20040913153146.161128d0.davem@davemloft.net> In-Reply-To: <20040913215944.33830.qmail@web90010.mail.scd.yahoo.com> References: <20040913215944.33830.qmail@web90010.mail.scd.yahoo.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1400 Lines: 48 On Mon, 13 Sep 2004 14:59:44 -0700 (PDT) S P wrote: Your email client linewraps the patches and also transforms tabs into spaces making your patches un-applyable. Please fix for future submissions, thanks. Now, onto the patch itself. I think we're adding more tense errors than we're removing. For example: > - All real intelligent work is done inside qdisc > modules. > + All real intelligent work is done inside each > qdisc modules. 'each' indicates singularity, yes "modules" is still plural. I would change it instead to: All the real intelligent work is done inside the qdisc modules. > - but it does not mean that queue is empty, it just > means that > - discipline does not want to send anything this > time. > + but it does not mean the queue is empty; it means > that > + the discipline does not want to send anything this > time. This one looks fine. > - For complicated disciplines with multiple queues > q->q is not > - real packet queue, but however q->q.qlen must be > valid. > + For complicated disciplines with multiple queues, > q->q is not > + real packet queue whereas q->q.qlen must be valid. Looks fine, we're missing an articles here. So maybe the final version of this verse is: For complicated disciplines with multiple queues, q->q is not a real packet queue whereas q->q.qlen must be valid. The rest looks fine. From ravinandan.arakali@s2io.com Mon Sep 13 15:40:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:40:33 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DMeQu8000434 for ; Mon, 13 Sep 2004 15:40:29 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8DMeAje024203; Mon, 13 Sep 2004 18:40:10 -0400 (EDT) Received: from rarakali ([10.16.16.160]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id i8DMe7qG026059; Mon, 13 Sep 2004 18:40:07 -0400 (EDT) Reply-To: From: "Ravinandan Arakali" To: "'Jeff Garzik'" Cc: , , , Subject: RE: Patch submission for S2io Xframe driver to 2.6 kernel Date: Mon, 13 Sep 2004 15:45:55 -0700 Message-ID: <003c01c499e3$6e910440$a010100a@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@s2io.com Precedence: bulk X-list: netdev Content-Length: 1575 Lines: 52 Hi Jeff, From the time we generated the patch to the latest kernel version(2.6.8.1), there seems to be a one line change(see change below) in s2io.c(done by one of the community developers). So, our patch may not apply cleanly. If you want us to regenerate the patch, we'll do it but the patch itself is still valid. Following is the change done in the latest 2.6.8.1 kernel: 1428c1428 < skb = dev_alloc_skb(size + HEADER_ALIGN_LAYER_3); --- > skb = dev_alloc_skb(size + NET_IP_ALIGN); 1434c1434 < skb_reserve(skb, HEADER_ALIGN_LAYER_3); --- > skb_reserve(skb, NET_IP_ALIGN); Thanks, Ravi -----Original Message----- From: Ravinandan Arakali [mailto:ravinandan.arakali@s2io.com] Sent: Monday, September 13, 2004 10:10 AM To: 'Jeff Garzik' Cc: 'netdev@oss.sgi.com'; 'leonid.grossman@s2io.com'; 'raghavendra.koushik@s2io.com'; 'rapuru.sriram@s2io.com' Subject: RE: Patch submission for S2io Xframe driver to 2.6 kernel Hi Jeff, Attached is the patch with the first round comments incorporated. In addition, this patch contains Some fixes related to 32-bit systems. Few fixes related to Rx path in NAPI. Thanks to all for the comments. Pls review this patch as well and come back with your comments. Regards, Ravi -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Saturday, August 28, 2004 4:37 PM To: ravinandan.arakali@s2io.com Cc: netdev@oss.sgi.com; leonid.grossman@s2io.com; raghavendra.koushik@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel is there a follow-up patch addressing the comments ? From davem@davemloft.net Mon Sep 13 15:57:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:57:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DMv2hM001093 for ; Mon, 13 Sep 2004 15:57:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6zj1-0004FS-00; Mon, 13 Sep 2004 15:55:07 -0700 Date: Mon, 13 Sep 2004 15:55:06 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, vnuorval@tcs.hut.fi Subject: Re: [BK PATCH] [IPV6] Merge Specification Conformity Improvements Message-Id: <20040913155506.4c99d4c8.davem@davemloft.net> In-Reply-To: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> References: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1282 Lines: 32 Ok, here are comments :-) 1) wrt. net/core/neighbour.c changes to use time_after() and similar interfaces. Here is why I didn't do that previously. I showed this to Alexey some time ago and he made me aware of some "black magic" in this area. Here is what he told me: ------------------------------------------------------------- BTW while I remember... Long time ago (when no such macros even existed) I definitely used some funny technique. Namely, when you definitely know that some timestamp is growing, now - ts_prev > timeo is always right thing and time_after(now, ts_prev+timeo) is not. Unfortunately, I do not remember where exactly. It is sick approach, of course, but it allowed not to switch to timeval to stamp long living objects. So, if you will notice such place, it would be better to make it to use timeval rather than to time_* macros. ------------------------------------------------------------- 2) rt6_dflt_{pointer,lock} Maybe it would be better to export a function that operates on these objects rather than the objects themselves. That way we could keep them and their implementation static to ip6_fib.c These are minor issues though, and as I stated I pulled your changes in already. Thanks. From davem@davemloft.net Mon Sep 13 15:59:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 15:59:32 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DMxSjR001327 for ; Mon, 13 Sep 2004 15:59:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6zjn-0004Fi-00; Mon, 13 Sep 2004 15:55:55 -0700 Date: Mon, 13 Sep 2004 15:55:55 -0700 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: sri@us.ibm.com, davem@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH][NET] generalise per socket slab cache use Message-Id: <20040913155555.680efdbc.davem@davemloft.net> In-Reply-To: <200409131851.10705.acme@conectiva.com.br> References: <200409110023.34342.acme@conectiva.com.br> <200409131851.10705.acme@conectiva.com.br> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 255 Lines: 9 On Mon, 13 Sep 2004 18:51:08 -0300 Arnaldo Carvalho de Melo wrote: > > I think there is a typo here. udp6_sock should be raw6_sock > > Good spotting! I'll fix this one Let me know when the fixed version is available, thanks. :) From davem@davemloft.net Mon Sep 13 16:03:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:03:34 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DN3Tsb001793 for ; Mon, 13 Sep 2004 16:03:30 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6zpF-0004GS-00; Mon, 13 Sep 2004 16:01:33 -0700 Date: Mon, 13 Sep 2004 16:01:33 -0700 From: "David S. Miller" To: Fernando Gont Cc: netdev@oss.sgi.com Subject: Re: ICMP attacks against TCP Message-Id: <20040913160133.69185327.davem@davemloft.net> In-Reply-To: <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> References: <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1329 Lines: 40 On Sun, 12 Sep 2004 22:40:04 -0300 Fernando Gont wrote: > There are some other work-arounds (for example, ignoring ICMP Source Quench > messages) are not implemented in Linux, though. I have no problem changing Linux to ignore these ICMP Source Quench messages, I completely agree with the draft. I've made the change in both my 2.4.x and 2.6.x trees as follows: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 15:43:14-07:00 davem@nuts.davemloft.net # [TCP]: Just silently ignore ICMP Source Quench messages. # # Recommended by draft-gont-tcpm-icmp-attacks-01.txt # # Signed-off-by: David S. Miller # # net/ipv4/tcp_ipv4.c # 2004/09/13 15:42:33-07:00 davem@nuts.davemloft.net +1 -5 # [TCP]: Just silently ignore ICMP Source Quench messages. # diff -Nru a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c 2004-09-13 15:44:01 -07:00 +++ b/net/ipv4/tcp_ipv4.c 2004-09-13 15:44:01 -07:00 @@ -1033,11 +1033,7 @@ switch (type) { case ICMP_SOURCE_QUENCH: - /* This is deprecated, but if someone generated it, - * we have no reasons to ignore it. - */ - if (!sock_owned_by_user(sk)) - tcp_enter_cwr(tp); + /* Just silently ignore these. */ goto out; case ICMP_PARAMETERPROB: err = EPROTO; From davem@davemloft.net Mon Sep 13 16:04:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:04:37 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DN4W0u001896 for ; Mon, 13 Sep 2004 16:04:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C6zqH-0004Gy-00; Mon, 13 Sep 2004 16:02:37 -0700 Date: Mon, 13 Sep 2004 16:02:37 -0700 From: "David S. Miller" To: Fernando Gont Cc: netdev@oss.sgi.com Subject: Re: ICMP attacks against TCP Message-Id: <20040913160237.1fe92c98.davem@davemloft.net> In-Reply-To: <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> References: <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 330 Lines: 8 On Sun, 12 Sep 2004 22:40:04 -0300 Fernando Gont wrote: > I'd appreciate any comments on the draft. Both for those work-arounds > implemented by Linux, and for those that aren't. Besides the Source Quench issue, which I just made comply with your draft, which recommendations are still missing in Linux? From davem@davemloft.net Mon Sep 13 16:21:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:21:16 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNLAqj005914 for ; Mon, 13 Sep 2004 16:21:11 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C706K-0004Ii-00; Mon, 13 Sep 2004 16:19:12 -0700 Date: Mon, 13 Sep 2004 16:19:12 -0700 From: "David S. Miller" To: Paul P Komkoff Jr Cc: i@stingr.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-Id: <20040913161912.7dcc809f.davem@davemloft.net> In-Reply-To: <20040913051706.GB26337@stingr.sgu.ru> References: <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> <20040913051706.GB26337@stingr.sgu.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 666 Lines: 19 On Mon, 13 Sep 2004 09:17:06 +0400 Paul P Komkoff Jr wrote: > Replying to David S. Miller: > > What are the rules for IP_GRE in general for when > > to apply this transformation? > > As you can see, I am applying it unconditionally when fits. For most > cases, this will be OK. > There can be situations when this is not wanted (for example, when > debugging something), so in general, tuning knob will be useful, but > I just don't know where to add it, maybe tunnel->parms.i_flags ... I don't think adding such a knob is necessary, but yes i_flags would be the place to do it. I will apply your patch with the "if(1)" simply removed. Thanks. From davem@davemloft.net Mon Sep 13 16:23:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:23:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNNqQX006129 for ; Mon, 13 Sep 2004 16:23:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C708w-0004JI-00; Mon, 13 Sep 2004 16:21:54 -0700 Date: Mon, 13 Sep 2004 16:21:53 -0700 From: "David S. Miller" To: Jeff Garzik Cc: vkondra@mail.ru, greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-Id: <20040913162153.33ff37ec.davem@davemloft.net> In-Reply-To: <4145352F.4040807@pobox.com> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409122103.21770.vkondra@mail.ru> <20040912171448.64ce7dbe.davem@davemloft.net> <200409130839.15988.vkondra@mail.ru> <4145352F.4040807@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 363 Lines: 10 On Mon, 13 Sep 2004 01:50:39 -0400 Jeff Garzik wrote: > You are the one doing the work. Which would you prefer? :) > > You could always send patches to netdev@oss.sgi.com and CC > jgarzik@pobox.com and davem@davemloft.net. DaveM could review, and I > could apply to wireless-2.6, then post a snapshot on kernel.org. That works for me. From davem@davemloft.net Mon Sep 13 16:25:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:25:27 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNPLeP006441 for ; Mon, 13 Sep 2004 16:25:21 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C70AM-0004KL-00; Mon, 13 Sep 2004 16:23:22 -0700 Date: Mon, 13 Sep 2004 16:23:22 -0700 From: "David S. Miller" To: lkml@einar-lueck.de Cc: elueck@de.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 1/2] ip routing - split of ip_route_[in|out]put_slow Message-Id: <20040913162322.51c18535.davem@davemloft.net> In-Reply-To: <4145782A.4040107@de.ibm.com> References: <4145782A.4040107@de.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 176 Lines: 6 Please resubmit your patches without clobbering the patch contents with your email client, for one thing it turns tabs into spaces. Probably best to use attachments. Thanks. From davem@davemloft.net Mon Sep 13 16:29:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:29:24 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNTITN006914 for ; Mon, 13 Sep 2004 16:29:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C70EH-0004Kq-00; Mon, 13 Sep 2004 16:27:25 -0700 Date: Mon, 13 Sep 2004 16:27:24 -0700 From: "David S. Miller" To: S P Cc: netdev@oss.sgi.com Subject: Re: [PATCH] linux 2.6.x.x - include/net/neighbour.h spell-check Message-Id: <20040913162724.7a6f2213.davem@davemloft.net> In-Reply-To: <20040913174842.96183.qmail@web90003.mail.scd.yahoo.com> References: <20040913174842.96183.qmail@web90003.mail.scd.yahoo.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 525 Lines: 15 On Mon, 13 Sep 2004 10:48:39 -0700 (PDT) S P wrote: > in linux 2.6.x.x kernel's include/net/neighbour.h > 'Neighbour' and 'Neighbor' are used interchangeably. > > neighbour is british variation of neighbor, so i'd say > neighbor is more appropriate. but then the header's > named neighbour. Does anyone remember what happened on linux-kernel when the similar case of American English "color" vs. British English "colour" was being debated? In any event, whatever we decide we should do tree-wide. From davem@davemloft.net Mon Sep 13 16:30:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:30:18 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNUDtj006958 for ; Mon, 13 Sep 2004 16:30:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C70F1-0004L2-00; Mon, 13 Sep 2004 16:28:11 -0700 Date: Mon, 13 Sep 2004 16:28:11 -0700 From: "David S. Miller" To: Thomas Graf Cc: hadi@cyberus.ca, sam@errno.com, ak@suse.de, netdev@oss.sgi.com Subject: Re: [RFC] Extend netlink error codes Message-Id: <20040913162811.1b0a45c8.davem@davemloft.net> In-Reply-To: <20040913203657.GF23686@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <3A0D075D-0423-11D9-BBE1-000A95AD0668@errno.com> <1094937035.2344.189.camel@jzny.localdomain> <20040913203657.GF23686@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 435 Lines: 11 On Mon, 13 Sep 2004 22:36:57 +0200 Thomas Graf wrote: > > BTW, there was someone from IBM a while back who was talking about > > having drivers send error messages via netlink; someone needs to look at > > the ideas they have maybe we can borrow something. > > http://lwn.net/Articles/39164/ I think since the inclusion of IBM's work is iffy at best, we should architect our facility without assuming it's presence. From shemminger@osdl.org Mon Sep 13 16:30:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:30:53 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNUljl007135 for ; Mon, 13 Sep 2004 16:30:47 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8DNU1v02762; Mon, 13 Sep 2004 16:30:02 -0700 Date: Mon, 13 Sep 2004 16:30:01 -0700 From: Stephen Hemminger To: Florian Schirmer Cc: Pekka Pietikainen , jgarzik@pobox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Fix for b44 warnings. Message-Id: <20040913163001.7fa560c6@dell_ss3.pdx.osdl.net> In-Reply-To: <200408292218.00756.jolt@tuxbox.org> References: <200408292218.00756.jolt@tuxbox.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 15001 Lines: 517 B44 driver was using unsigned long as an io memory address. Recent changes caused this to be a warning. This patch fixes that and makes the readl/writel wrapper into inline's instead of macros with magic variable side effect (yuck). diff -Nru a/drivers/net/b44.c b/drivers/net/b44.c --- a/drivers/net/b44.c 2004-09-13 15:33:00 -07:00 +++ b/drivers/net/b44.c 2004-09-13 15:33:00 -07:00 @@ -98,13 +98,24 @@ static void b44_init_rings(struct b44 *); static void b44_init_hw(struct b44 *); +static inline unsigned long br32(const struct b44 *bp, unsigned long reg) +{ + return readl(bp->regs + reg); +} + +static inline void bw32(const struct b44 *bp, + unsigned long reg, unsigned long val) +{ + writel(val, bp->regs + reg); +} + static int b44_wait_bit(struct b44 *bp, unsigned long reg, u32 bit, unsigned long timeout, const int clear) { unsigned long i; for (i = 0; i < timeout; i++) { - u32 val = br32(reg); + u32 val = br32(bp, reg); if (clear && !(val & bit)) break; @@ -168,7 +179,7 @@ static u32 ssb_get_core_rev(struct b44 *bp) { - return (br32(B44_SBIDHIGH) & SBIDHIGH_RC_MASK); + return (br32(bp, B44_SBIDHIGH) & SBIDHIGH_RC_MASK); } static u32 ssb_pci_setup(struct b44 *bp, u32 cores) @@ -180,13 +191,13 @@ ssb_get_addr(bp, SBID_REG_PCI, 0)); pci_rev = ssb_get_core_rev(bp); - val = br32(B44_SBINTVEC); + val = br32(bp, B44_SBINTVEC); val |= cores; - bw32(B44_SBINTVEC, val); + bw32(bp, B44_SBINTVEC, val); - val = br32(SSB_PCI_TRANS_2); + val = br32(bp, SSB_PCI_TRANS_2); val |= SSB_PCI_PREF | SSB_PCI_BURST; - bw32(SSB_PCI_TRANS_2, val); + bw32(bp, SSB_PCI_TRANS_2, val); pci_write_config_dword(bp->pdev, SSB_BAR0_WIN, bar_orig); @@ -195,18 +206,18 @@ static void ssb_core_disable(struct b44 *bp) { - if (br32(B44_SBTMSLOW) & SBTMSLOW_RESET) + if (br32(bp, B44_SBTMSLOW) & SBTMSLOW_RESET) return; - bw32(B44_SBTMSLOW, (SBTMSLOW_REJECT | SBTMSLOW_CLOCK)); + bw32(bp, B44_SBTMSLOW, (SBTMSLOW_REJECT | SBTMSLOW_CLOCK)); b44_wait_bit(bp, B44_SBTMSLOW, SBTMSLOW_REJECT, 100000, 0); b44_wait_bit(bp, B44_SBTMSHIGH, SBTMSHIGH_BUSY, 100000, 1); - bw32(B44_SBTMSLOW, (SBTMSLOW_FGC | SBTMSLOW_CLOCK | + bw32(bp, B44_SBTMSLOW, (SBTMSLOW_FGC | SBTMSLOW_CLOCK | SBTMSLOW_REJECT | SBTMSLOW_RESET)); - br32(B44_SBTMSLOW); + br32(bp, B44_SBTMSLOW); udelay(1); - bw32(B44_SBTMSLOW, (SBTMSLOW_REJECT | SBTMSLOW_RESET)); - br32(B44_SBTMSLOW); + bw32(bp, B44_SBTMSLOW, (SBTMSLOW_REJECT | SBTMSLOW_RESET)); + br32(bp, B44_SBTMSLOW); udelay(1); } @@ -215,31 +226,31 @@ u32 val; ssb_core_disable(bp); - bw32(B44_SBTMSLOW, (SBTMSLOW_RESET | SBTMSLOW_CLOCK | SBTMSLOW_FGC)); - br32(B44_SBTMSLOW); + bw32(bp, B44_SBTMSLOW, (SBTMSLOW_RESET | SBTMSLOW_CLOCK | SBTMSLOW_FGC)); + br32(bp, B44_SBTMSLOW); udelay(1); /* Clear SERR if set, this is a hw bug workaround. */ - if (br32(B44_SBTMSHIGH) & SBTMSHIGH_SERR) - bw32(B44_SBTMSHIGH, 0); + if (br32(bp, B44_SBTMSHIGH) & SBTMSHIGH_SERR) + bw32(bp, B44_SBTMSHIGH, 0); - val = br32(B44_SBIMSTATE); + val = br32(bp, B44_SBIMSTATE); if (val & (SBIMSTATE_IBE | SBIMSTATE_TO)) - bw32(B44_SBIMSTATE, val & ~(SBIMSTATE_IBE | SBIMSTATE_TO)); + bw32(bp, B44_SBIMSTATE, val & ~(SBIMSTATE_IBE | SBIMSTATE_TO)); - bw32(B44_SBTMSLOW, (SBTMSLOW_CLOCK | SBTMSLOW_FGC)); - br32(B44_SBTMSLOW); + bw32(bp, B44_SBTMSLOW, (SBTMSLOW_CLOCK | SBTMSLOW_FGC)); + br32(bp, B44_SBTMSLOW); udelay(1); - bw32(B44_SBTMSLOW, (SBTMSLOW_CLOCK)); - br32(B44_SBTMSLOW); + bw32(bp, B44_SBTMSLOW, (SBTMSLOW_CLOCK)); + br32(bp, B44_SBTMSLOW); udelay(1); } static int ssb_core_unit(struct b44 *bp) { #if 0 - u32 val = br32(B44_SBADMATCH0); + u32 val = br32(bp, B44_SBADMATCH0); u32 base; type = val & SBADMATCH0_TYPE_MASK; @@ -263,7 +274,7 @@ static int ssb_is_core_up(struct b44 *bp) { - return ((br32(B44_SBTMSLOW) & (SBTMSLOW_RESET | SBTMSLOW_REJECT | SBTMSLOW_CLOCK)) + return ((br32(bp, B44_SBTMSLOW) & (SBTMSLOW_RESET | SBTMSLOW_REJECT | SBTMSLOW_CLOCK)) == SBTMSLOW_CLOCK); } @@ -275,19 +286,19 @@ val |= ((u32) data[3]) << 16; val |= ((u32) data[4]) << 8; val |= ((u32) data[5]) << 0; - bw32(B44_CAM_DATA_LO, val); + bw32(bp, B44_CAM_DATA_LO, val); val = (CAM_DATA_HI_VALID | (((u32) data[0]) << 8) | (((u32) data[1]) << 0)); - bw32(B44_CAM_DATA_HI, val); - bw32(B44_CAM_CTRL, (CAM_CTRL_WRITE | + bw32(bp, B44_CAM_DATA_HI, val); + bw32(bp, B44_CAM_CTRL, (CAM_CTRL_WRITE | (index << CAM_CTRL_INDEX_SHIFT))); b44_wait_bit(bp, B44_CAM_CTRL, CAM_CTRL_BUSY, 100, 1); } static inline void __b44_disable_ints(struct b44 *bp) { - bw32(B44_IMASK, 0); + bw32(bp, B44_IMASK, 0); } static void b44_disable_ints(struct b44 *bp) @@ -295,34 +306,34 @@ __b44_disable_ints(bp); /* Flush posted writes. */ - br32(B44_IMASK); + br32(bp, B44_IMASK); } static void b44_enable_ints(struct b44 *bp) { - bw32(B44_IMASK, bp->imask); + bw32(bp, B44_IMASK, bp->imask); } static int b44_readphy(struct b44 *bp, int reg, u32 *val) { int err; - bw32(B44_EMAC_ISTAT, EMAC_INT_MII); - bw32(B44_MDIO_DATA, (MDIO_DATA_SB_START | + bw32(bp, B44_EMAC_ISTAT, EMAC_INT_MII); + bw32(bp, B44_MDIO_DATA, (MDIO_DATA_SB_START | (MDIO_OP_READ << MDIO_DATA_OP_SHIFT) | (bp->phy_addr << MDIO_DATA_PMD_SHIFT) | (reg << MDIO_DATA_RA_SHIFT) | (MDIO_TA_VALID << MDIO_DATA_TA_SHIFT))); err = b44_wait_bit(bp, B44_EMAC_ISTAT, EMAC_INT_MII, 100, 0); - *val = br32(B44_MDIO_DATA) & MDIO_DATA_DATA; + *val = br32(bp, B44_MDIO_DATA) & MDIO_DATA_DATA; return err; } static int b44_writephy(struct b44 *bp, int reg, u32 val) { - bw32(B44_EMAC_ISTAT, EMAC_INT_MII); - bw32(B44_MDIO_DATA, (MDIO_DATA_SB_START | + bw32(bp, B44_EMAC_ISTAT, EMAC_INT_MII); + bw32(bp, B44_MDIO_DATA, (MDIO_DATA_SB_START | (MDIO_OP_WRITE << MDIO_DATA_OP_SHIFT) | (bp->phy_addr << MDIO_DATA_PMD_SHIFT) | (reg << MDIO_DATA_RA_SHIFT) | @@ -382,20 +393,20 @@ bp->flags &= ~(B44_FLAG_TX_PAUSE | B44_FLAG_RX_PAUSE); bp->flags |= pause_flags; - val = br32(B44_RXCONFIG); + val = br32(bp, B44_RXCONFIG); if (pause_flags & B44_FLAG_RX_PAUSE) val |= RXCONFIG_FLOW; else val &= ~RXCONFIG_FLOW; - bw32(B44_RXCONFIG, val); + bw32(bp, B44_RXCONFIG, val); - val = br32(B44_MAC_FLOW); + val = br32(bp, B44_MAC_FLOW); if (pause_flags & B44_FLAG_TX_PAUSE) val |= (MAC_FLOW_PAUSE_ENAB | (0xc0 & MAC_FLOW_RX_HI_WATER)); else val &= ~MAC_FLOW_PAUSE_ENAB; - bw32(B44_MAC_FLOW, val); + bw32(bp, B44_MAC_FLOW, val); } static void b44_set_flow_ctrl(struct b44 *bp, u32 local, u32 remote) @@ -491,11 +502,11 @@ val = &bp->hw_stats.tx_good_octets; for (reg = B44_TX_GOOD_O; reg <= B44_TX_PAUSE; reg += 4UL) { - *val++ += br32(reg); + *val++ += br32(bp, reg); } val = &bp->hw_stats.rx_good_octets; for (reg = B44_RX_GOOD_O; reg <= B44_RX_NPAUSE; reg += 4UL) { - *val++ += br32(reg); + *val++ += br32(bp, reg); } } @@ -535,14 +546,14 @@ if (!netif_carrier_ok(bp->dev) && (bmsr & BMSR_LSTATUS)) { - u32 val = br32(B44_TX_CTRL); + u32 val = br32(bp, B44_TX_CTRL); u32 local_adv, remote_adv; if (bp->flags & B44_FLAG_FULL_DUPLEX) val |= TX_CTRL_DUPLEX; else val &= ~TX_CTRL_DUPLEX; - bw32(B44_TX_CTRL, val); + bw32(bp, B44_TX_CTRL, val); if (!(bp->flags & B44_FLAG_FORCE_LINK) && !b44_readphy(bp, MII_ADVERTISE, &local_adv) && @@ -587,7 +598,7 @@ { u32 cur, cons; - cur = br32(B44_DMATX_STAT) & DMATX_STAT_CDMASK; + cur = br32(bp, B44_DMATX_STAT) & DMATX_STAT_CDMASK; cur /= sizeof(struct dma_desc); /* XXX needs updating when NETIF_F_SG is supported */ @@ -611,7 +622,7 @@ TX_BUFFS_AVAIL(bp) > B44_TX_WAKEUP_THRESH) netif_wake_queue(bp->dev); - bw32(B44_GPTIMER, 0); + bw32(bp, B44_GPTIMER, 0); } /* Works like this. This chip writes a 'struct rx_header" 30 bytes @@ -708,7 +719,7 @@ u32 cons, prod; received = 0; - prod = br32(B44_DMARX_STAT) & DMARX_STAT_CDMASK; + prod = br32(bp, B44_DMARX_STAT) & DMARX_STAT_CDMASK; prod /= sizeof(struct dma_desc); cons = bp->rx_cons; @@ -787,7 +798,7 @@ } bp->rx_cons = cons; - bw32(B44_DMARX_PTR, cons * sizeof(struct dma_desc)); + bw32(bp, B44_DMARX_PTR, cons * sizeof(struct dma_desc)); return received; } @@ -851,8 +862,8 @@ spin_lock_irqsave(&bp->lock, flags); - istat = br32(B44_ISTAT); - imask = br32(B44_IMASK); + istat = br32(bp, B44_ISTAT); + imask = br32(bp, B44_IMASK); /* ??? What the fuck is the purpose of the interrupt mask * ??? register if we have to mask it out by hand anyways? @@ -872,8 +883,8 @@ dev->name); } - bw32(B44_ISTAT, istat); - br32(B44_ISTAT); + bw32(bp, B44_ISTAT, istat); + br32(bp, B44_ISTAT); } spin_unlock_irqrestore(&bp->lock, flags); return IRQ_RETVAL(handled); @@ -937,11 +948,11 @@ wmb(); - bw32(B44_DMATX_PTR, entry * sizeof(struct dma_desc)); + bw32(bp, B44_DMATX_PTR, entry * sizeof(struct dma_desc)); if (bp->flags & B44_FLAG_BUGGY_TXPTR) - bw32(B44_DMATX_PTR, entry * sizeof(struct dma_desc)); + bw32(bp, B44_DMATX_PTR, entry * sizeof(struct dma_desc)); if (bp->flags & B44_FLAG_REORDER_BUG) - br32(B44_DMATX_PTR); + br32(bp, B44_DMATX_PTR); if (TX_BUFFS_AVAIL(bp) < 1) netif_stop_queue(dev); @@ -1109,27 +1120,27 @@ { unsigned long reg; - bw32(B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ); + bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ); for (reg = B44_TX_GOOD_O; reg <= B44_TX_PAUSE; reg += 4UL) - br32(reg); + br32(bp, reg); for (reg = B44_RX_GOOD_O; reg <= B44_RX_NPAUSE; reg += 4UL) - br32(reg); + br32(bp, reg); } /* bp->lock is held. */ static void b44_chip_reset(struct b44 *bp) { if (ssb_is_core_up(bp)) { - bw32(B44_RCV_LAZY, 0); - bw32(B44_ENET_CTRL, ENET_CTRL_DISABLE); + bw32(bp, B44_RCV_LAZY, 0); + bw32(bp, B44_ENET_CTRL, ENET_CTRL_DISABLE); b44_wait_bit(bp, B44_ENET_CTRL, ENET_CTRL_DISABLE, 100, 1); - bw32(B44_DMATX_CTRL, 0); + bw32(bp, B44_DMATX_CTRL, 0); bp->tx_prod = bp->tx_cons = 0; - if (br32(B44_DMARX_STAT) & DMARX_STAT_EMASK) { + if (br32(bp, B44_DMARX_STAT) & DMARX_STAT_EMASK) { b44_wait_bit(bp, B44_DMARX_STAT, DMARX_STAT_SIDLE, 100, 0); } - bw32(B44_DMARX_CTRL, 0); + bw32(bp, B44_DMARX_CTRL, 0); bp->rx_prod = bp->rx_cons = 0; } else { ssb_pci_setup(bp, (bp->core_unit == 0 ? @@ -1142,20 +1153,20 @@ b44_clear_stats(bp); /* Make PHY accessible. */ - bw32(B44_MDIO_CTRL, (MDIO_CTRL_PREAMBLE | + bw32(bp, B44_MDIO_CTRL, (MDIO_CTRL_PREAMBLE | (0x0d & MDIO_CTRL_MAXF_MASK))); - br32(B44_MDIO_CTRL); + br32(bp, B44_MDIO_CTRL); - if (!(br32(B44_DEVCTRL) & DEVCTRL_IPP)) { - bw32(B44_ENET_CTRL, ENET_CTRL_EPSEL); - br32(B44_ENET_CTRL); + if (!(br32(bp, B44_DEVCTRL) & DEVCTRL_IPP)) { + bw32(bp, B44_ENET_CTRL, ENET_CTRL_EPSEL); + br32(bp, B44_ENET_CTRL); bp->flags &= ~B44_FLAG_INTERNAL_PHY; } else { - u32 val = br32(B44_DEVCTRL); + u32 val = br32(bp, B44_DEVCTRL); if (val & DEVCTRL_EPR) { - bw32(B44_DEVCTRL, (val & ~DEVCTRL_EPR)); - br32(B44_DEVCTRL); + bw32(bp, B44_DEVCTRL, (val & ~DEVCTRL_EPR)); + br32(bp, B44_DEVCTRL); udelay(100); } bp->flags |= B44_FLAG_INTERNAL_PHY; @@ -1172,13 +1183,13 @@ /* bp->lock is held. */ static void __b44_set_mac_addr(struct b44 *bp) { - bw32(B44_CAM_CTRL, 0); + bw32(bp, B44_CAM_CTRL, 0); if (!(bp->dev->flags & IFF_PROMISC)) { u32 val; __b44_cam_write(bp, bp->dev->dev_addr, 0); - val = br32(B44_CAM_CTRL); - bw32(B44_CAM_CTRL, val | CAM_CTRL_ENABLE); + val = br32(bp, B44_CAM_CTRL); + bw32(bp, B44_CAM_CTRL, val | CAM_CTRL_ENABLE); } } @@ -1212,30 +1223,30 @@ b44_setup_phy(bp); /* Enable CRC32, set proper LED modes and power on PHY */ - bw32(B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL); - bw32(B44_RCV_LAZY, (1 << RCV_LAZY_FC_SHIFT)); + bw32(bp, B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL); + bw32(bp, B44_RCV_LAZY, (1 << RCV_LAZY_FC_SHIFT)); /* This sets the MAC address too. */ __b44_set_rx_mode(bp->dev); /* MTU + eth header + possible VLAN tag + struct rx_header */ - bw32(B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8 + RX_HEADER_LEN); - bw32(B44_TXMAXLEN, bp->dev->mtu + ETH_HLEN + 8 + RX_HEADER_LEN); + bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8 + RX_HEADER_LEN); + bw32(bp, B44_TXMAXLEN, bp->dev->mtu + ETH_HLEN + 8 + RX_HEADER_LEN); - bw32(B44_TX_WMARK, 56); /* XXX magic */ - bw32(B44_DMATX_CTRL, DMATX_CTRL_ENABLE); - bw32(B44_DMATX_ADDR, bp->tx_ring_dma + bp->dma_offset); - bw32(B44_DMARX_CTRL, (DMARX_CTRL_ENABLE | + bw32(bp, B44_TX_WMARK, 56); /* XXX magic */ + bw32(bp, B44_DMATX_CTRL, DMATX_CTRL_ENABLE); + bw32(bp, B44_DMATX_ADDR, bp->tx_ring_dma + bp->dma_offset); + bw32(bp, B44_DMARX_CTRL, (DMARX_CTRL_ENABLE | (bp->rx_offset << DMARX_CTRL_ROSHIFT))); - bw32(B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset); + bw32(bp, B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset); - bw32(B44_DMARX_PTR, bp->rx_pending); + bw32(bp, B44_DMARX_PTR, bp->rx_pending); bp->rx_prod = bp->rx_pending; - bw32(B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ); + bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ); - val = br32(B44_ENET_CTRL); - bw32(B44_ENET_CTRL, (val | ENET_CTRL_ENABLE)); + val = br32(bp, B44_ENET_CTRL); + bw32(bp, B44_ENET_CTRL, (val | ENET_CTRL_ENABLE)); } static int b44_open(struct net_device *dev) @@ -1372,11 +1383,11 @@ int i=0; unsigned char zero[6] = {0,0,0,0,0,0}; - val = br32(B44_RXCONFIG); + val = br32(bp, B44_RXCONFIG); val &= ~(RXCONFIG_PROMISC | RXCONFIG_ALLMULTI); if (dev->flags & IFF_PROMISC) { val |= RXCONFIG_PROMISC; - bw32(B44_RXCONFIG, val); + bw32(bp, B44_RXCONFIG, val); } else { __b44_set_mac_addr(bp); @@ -1388,9 +1399,9 @@ for(;i<64;i++) { __b44_cam_write(bp, zero, i); } - bw32(B44_RXCONFIG, val); - val = br32(B44_CAM_CTRL); - bw32(B44_CAM_CTRL, val | CAM_CTRL_ENABLE); + bw32(bp, B44_RXCONFIG, val); + val = br32(bp, B44_CAM_CTRL); + bw32(bp, B44_CAM_CTRL, val | CAM_CTRL_ENABLE); } } @@ -1760,7 +1771,7 @@ spin_lock_init(&bp->lock); - bp->regs = (unsigned long) ioremap(b44reg_base, b44reg_len); + bp->regs = ioremap(b44reg_base, b44reg_len); if (bp->regs == 0UL) { printk(KERN_ERR PFX "Cannot map device registers, " "aborting.\n"); diff -Nru a/drivers/net/b44.h b/drivers/net/b44.h --- a/drivers/net/b44.h 2004-09-13 15:33:00 -07:00 +++ b/drivers/net/b44.h 2004-09-13 15:33:00 -07:00 @@ -395,9 +395,6 @@ #define SSB_PCI_MASK1 0xfc000000 #define SSB_PCI_MASK2 0xc0000000 -#define br32(REG) readl(bp->regs + (REG)) -#define bw32(REG,VAL) writel((VAL), bp->regs + (REG)) - /* 4400 PHY registers */ #define B44_MII_AUXCTRL 24 /* Auxiliary Control */ #define MII_AUXCTRL_DUPLEX 0x0001 /* Full Duplex */ @@ -530,7 +527,7 @@ struct net_device_stats stats; struct b44_hw_stats hw_stats; - unsigned long regs; + volatile void __iomem *regs; struct pci_dev *pdev; struct net_device *dev; From hfvogt@arcor.de Mon Sep 13 16:31:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:31:41 -0700 (PDT) Received: from achilles.nass-vogt.home (pD9E75C6D.dip0.t-ipconnect.de [217.231.92.109]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNVSvJ007326 for ; Mon, 13 Sep 2004 16:31:29 -0700 Received: by achilles.nass-vogt.home (Postfix, from userid 1000) id 3F8F5412; Tue, 14 Sep 2004 01:31:12 +0200 (CEST) From: Hans-Frieder Vogt Reply-To: hfvogt@arcor.de To: Francois Romieu Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Date: Tue, 14 Sep 2004 01:31:11 +0200 User-Agent: KMail/1.7 Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com References: <200409130035.50823.hfvogt@arcor.de> <200409131443.34374.hfvogt@arcor.de> <20040913220209.GA13175@electric-eye.fr.zoreil.com> In-Reply-To: <20040913220209.GA13175@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_/2iRBaeD8M2PAeQ" Message-Id: <200409140131.11927.hfvogt@arcor.de> X-archive-position: 8755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hfvogt@arcor.de Precedence: bulk X-list: netdev Content-Length: 46637 Lines: 728 --Boundary-00=_/2iRBaeD8M2PAeQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Am Dienstag, 14. September 2004 00:02 schrieb Francois Romieu: > Hans-Frieder Vogt : > [...] > > > no oops (BUG_ON not triggered)! System boots up as normal, but just after > > I > > ... > > > log in on the console the system freezes, i.e., keyboard does not react > > any more and the system is not accessible via network. > > - do the keyboard leds or the magic sysrq answer (I assume you boot without X) ? (To be able to exclude any side effect of X, I have booted without X and I have also removed all graphics driver related modules) When the system freezes, the keyboard is completely dead, the LEDs do not react any more and also the sysrq keys do not work. > - does it make a difference if you boot with the network cable > unpluged (i.e. fine until pluged then dead when first packet comes in) ? > YES!! With the network cable unplugged, the system does not freeze! Every 10 seconds, I get now the message: r8169: eth0: PHY reset until link up but otherwise everything seems fine. > > The time from the moment I log in to the time when the system freezes > > varies, but is in the order of 5s. > > First packet probably. Can you verify this point ? > I think the test with the network cable unplugged supports this assumption. With network cable unplugged, /proc/interrupts shows 0 interrupts for the network card, so probably the first interrupt leads to the system freeze. > > There is no difference whether NAPI is enabled or not. > > I will welcome lspci -vx + gcc version + objdump -S of the r8169 module. > lspci -vx and objdump -S output (gzipped) are attached, gcc version is 3.4.2 (Debian 3.4.2-2), but no visible difference with 3.4.1. > -- > Ueimor Thanks for your help, Francois. I will put a few printks into the interrupt routine and hope to be able to tell you more tomorrow, Hans-Frieder -- -- Hans-Frieder Vogt e-mail: hfvogt (at) arcor (dot) de --Boundary-00=_/2iRBaeD8M2PAeQ Content-Type: text/plain; charset="iso-8859-1"; name="lspci-vx.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lspci-vx.out" 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) Subsystem: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge Flags: bus master, 66MHz, medium devsel, latency 8 Memory at d0000000 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.0 Capabilities: [c0] #08 [0060] Capabilities: [68] Power Management version 2 Capabilities: [58] #08 [8001] 00: 06 11 88 31 06 00 30 22 01 00 00 06 00 08 00 00 10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 88 31 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: cde00000-cfefffff Prefetchable memory behind bridge: bdd00000-cdcfffff Capabilities: [80] Power Management version 2 00: 06 11 88 b1 07 01 30 02 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 22 20: e0 cd e0 cf d0 bd c0 cd 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0e 00 0000:00:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: Avermedia Technologies Inc: Unknown device 0761 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at cddfe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00: 9e 10 6e 03 06 00 90 02 11 00 00 04 00 20 80 00 10: 08 e0 df cd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 61 14 61 07 30: 00 00 00 00 44 00 00 00 00 00 00 00 0c 01 10 28 0000:00:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: Avermedia Technologies Inc: Unknown device 0761 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at cddff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 00: 9e 10 78 08 06 00 90 02 11 00 80 04 00 20 80 00 10: 08 f0 df cd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 61 14 61 07 30: 00 00 00 00 44 00 00 00 00 00 00 00 0c 01 04 ff 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Micro-Star International Co., Ltd.: Unknown device 702c Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at d400 [size=256] Memory at cfffbf00 (32-bit, non-prefetchable) [size=256] Expansion ROM at 40000000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00: ec 10 69 81 17 00 b0 02 10 00 00 02 10 40 00 00 10: 01 d4 00 00 00 bf ff cf 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 2c 70 30: 00 00 00 40 dc 00 00 00 00 00 00 00 0b 01 20 40 0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: Micro-Star International Co., Ltd. MSI Neo K8T FIS2R mainboard Flags: bus master, medium devsel, latency 32, IRQ 20 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=16] I/O ports at d800 [size=256] Capabilities: [c0] Power Management version 2 00: 06 11 49 31 07 00 90 02 80 00 04 01 00 20 80 00 10: 01 ec 00 00 01 e8 00 00 01 e4 00 00 01 e0 00 00 20: 01 dc 00 00 01 d8 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 c0 00 00 00 00 00 00 00 0a 02 00 00 0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7020 Flags: bus master, medium devsel, latency 32, IRQ 20 I/O ports at fc00 [size=16] Capabilities: [c0] Power Management version 2 00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 fc 00 00 00 00 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00 0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7020 Flags: bus master, medium devsel, latency 32, IRQ 21 I/O ports at c400 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 81 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 c4 00 00 00 00 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 01 00 00 0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7020 Flags: bus master, medium devsel, latency 32, IRQ 21 I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 81 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 c8 00 00 00 00 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 01 00 00 0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7020 Flags: bus master, medium devsel, latency 32, IRQ 21 I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 81 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 cc 00 00 00 00 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 02 00 00 0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7020 Flags: bus master, medium devsel, latency 32, IRQ 21 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 81 00 03 0c 08 20 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 02 00 00 0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7020 Flags: bus master, medium devsel, latency 32, IRQ 21 Memory at cfffbd00 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 00: 06 11 04 31 17 00 10 02 86 20 03 0c 10 20 80 00 10: 00 bd ff cf 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 20 70 30: 00 00 00 00 80 00 00 00 00 00 00 00 05 03 00 00 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] Subsystem: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 27 32 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 27 32 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) Subsystem: Micro-Star International Co., Ltd.: Unknown device 0080 Flags: medium devsel, IRQ 22 I/O ports at c000 [size=256] Capabilities: [c0] Power Management version 2 00: 06 11 59 30 01 00 10 02 60 00 01 04 00 00 00 00 10: 01 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 80 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 05 03 00 00 0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge Flags: fast devsel Capabilities: [80] #08 [2101] 00: 22 10 00 11 00 00 10 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge Flags: fast devsel 00: 22 10 01 11 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge Flags: fast devsel 00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge Flags: fast devsel 00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000:01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1) (prog-if 00 [VGA]) Subsystem: Hercules: Unknown device 0020 Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 16 Memory at ce000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (32-bit, prefetchable) [size=128M] Expansion ROM at cfef0000 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 00: de 10 10 01 07 00 b0 02 a1 00 00 03 00 f8 00 00 10: 00 00 00 ce 08 00 00 c0 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 81 16 20 00 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 05 01 --Boundary-00=_/2iRBaeD8M2PAeQ Content-Type: application/x-gzip; name="r8169-dump.out.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="r8169-dump.out.gz" H4sICE0mRkECA3I4MTY5LWR1bXAub3V0AKRd6Y7dtpL+7TyFgDsB5s44sbhTxuD+mvdoSCTldHJ6 cZ9O0neefliiSJHaTvG4YbQDh8W1WOtX1E9fLo/Dl6cX++fFXb/QX+Wv3S9vhvwy/EHUL/2TlfzL H+7t2V2+2LfHv9zb9cuze//yponsfv3j5WsDP+PjxTXjy9tT/964yyj5Lx9a/iL5Tz/97+O1v17d 03D5d/MyNldn3h9fnptf393H+9effmpXP83/vJrHhz+fn/rXh+vj87eL+9fXn5rw0379xLtGd82o m/zn09PLX/D3z2/28fPPbzq2Z769brRtuGpUm7W/uH7q70O1/wlE//RU/UckU18/MdKMY7P6+fTx 8jYN42AY/ysSdH4c22jRmLYkeHfX92leOp+WmabVjg0XxUo+Gb+OZ9fAXD7DtGYC4tftusbvTfoz E/z+9PodGojtrv13+0HEv2IP4usnKZvtzyfbv/dExmYS10zhmumvn7p2r9nzyyv8Hdt1uO56XLMB 18wgJ2dx3Tlcs/HWqKv7QOf7YJ/6h+u/n818uA/+pj1Y99ejWW4HbQO3s8aZhuZsdf1zgL//o/2g wIfX10jB77ofVAeyrhF+IN60enMNh4/P7Yf+Txjrn5HKTrfKDse3ylPBr0gwhmHE+iYut2q67ema MJrdK3t8r9IIzLO7367RXy1WjmCeXucdY35KJhF0ceVyWjlptyt/9SsnbbF05pmDm4mMT2TbDSMU yMod4yyRTaPR7WiEeTJajsZ1lJKWH0lJ2AZCI8GQxKo4ILjCRhMWCfx6fGtjN0cZCfyWwVFGRhOe NZVoWrEh+N0fCzRQt9jcizOmojgT/qSd3hOIpr9cvtf35wWaHmB+qy7jgmCHH1/9LXD9R5z7Pxph MaPYNIq/AVsdkTO0A/506aIJfwOUP/etIvrdBb3TIiag2jgBSaZz86rk8Nw8+2b8LhMHOnrAGZ5x gZ8igUwE7oiAgQiKd1amG2XHA4Kh0IUyKE9/WgdXcLl9cNUjByoSyQ5kVhJXuYBQ83KGo4u73Nn8 Qqkhke1f3OXO5tdKJwFueCnAe2t3BbjmNwwDv6+3GUR2kUE0ThNrnCbWOE2skZpY4zSxxmliPeJG 7dp7GKcTd3Fp19/Fb914F7/1vJbfeq9aDNvbtDf3/n3ZtB7HRz2Oj3ocH/VIPupxfNTj+KivtegG L7Of7OPLw99vj++L9TZ4PhNir5/XP6+/zaZFbAtynDROgmVUqKv+OR7cOHpBnsTsoKKYHe2Z57QM 4Y/GTEOQlUtz/e0yD0HaYgi/rYKdLyBej8HvbetF/mZ7PwVTEDysj7xz43dnGBrrF6pKQTfP309H 2TY3H42YNsm4ZYd0m4/hSfR8JsVQQ2ZGt/tmdHEpzDhpVaUa2R5oVW8+eTE7m9IzmfU2zDCC2e1t Ak52l8SJFqrNXU2rblg+1uTs5aU7NVG6W4PiaIu7HxZ3PyxSzrp2MsG85X6wi/MGDrMVFslYpU3l PFuobs3VwRS9ToEMtdpAnsxEp6YjE5PL1MrdI5PaCp2fmPO77q+p2fo91jPY7PfEtu7G6Y5sPTkW JzeGndjxr9JOlP7VCDsx7lmDv3+bj2Q1GEuW5Kgy1dHuq47ikoz+VolhVzoENsikw+h3TNjztqlf i9NII45bx0ppTtq4R2+ut1GY+3/120MawY9lYVTepKWVwpy0eup9MECR/pRsOM4/k5lgI6GrFOqE ELRWIoTW6RgCQSmkxiAQmaoXsgRCS3V6g0Akp1ouE8pu3FziDayFU0Au639FWn2P6CN0qBN9BCIw XvS13ZHoI2w1R7bMcbxrjlNIhkNIZlAgTwqy//v70vzcfxQsCiEZN+yK5xCSIXw1R57myHS9eCbM osUzYeOtQ/ZrLSfH4+Q4rxPPhMsgntsj8XzCURACQkpbwju0tCW8n44T3Pv2MB5gcwbgNkhCc9x7 koR8vCXLV8JXeOH79n6BPMTD+/Do9+Hq3h9e3bP1Xm4SxmK2LBQ4VQesy2OUc5m58DeairXxWMrl zH5c6HA+EhEoH4mIHtdswDXD+UhEWFx3DtesVqvK7GA/nh6PTla2daY6kTxkduRxDBoinYv+g3iW v/GdKPRsfuNLAyCSDXXmEZFjZDa9kiwls+WMpjiO0RQq90OUxDVTuGa43A9RuFugcLdA4W6BQt4C hbsFCncLVO0t0Cvxdnl8/uPh5Y/E/vo+waZXgq2lW16jW7mmkXINF0MkuBgiwcUQCTKGSHAxRIKL IRJde6LdWq6tjxSijWAsyelUzcpeGi5wpGZ7pB2fElkuO8ztkRYECneYnUZtRIc78w535t2AO8zO 4LrDnXmHO/Ou9sz7XSPFPffDgmzwje66yr2/yq3ds1F2Y1wLnZ68qePhJtdhGTOSDTiu6XEHgwvE ElwgltQGYsmwb2SsTmaKyyKdVIjLVpkXA0su83DqMqcRgj3CK+2RYajLshEI0HpmMmZhqR3G+vxz /9tMYGqXbhjeRTE8SEUFjvx6+smLdDa1V1NazPFmdOUuzWmxVQw+kuHY1uDY1uDY1tSyrc3Y1vzm zB9BiVzf+/c/r4ltbQXbWlLJhZYndlJnCIPETlZlhnru22eGOgSeFoPYgg4wR/Mfv0dRAzFtPTac F7m5mY2+5+m5mQDizGO/17G5PGbKxflNkaIJSbzWdy8gG+dvV1rjt+tXSMdlyBjivFwNkjj+Qz9F F/wl8jP06nkJ1T0+m8s0vTH7cS0Hidt/xNmO7UTfSYhHtUMWHJzv+3+1H8OE0bkmKT3KyrjQqCeY AeuOYAaUsROegwxyjEKTsQ9XtW8Ua1gLOzf3Nby/Xebo2WcIJUOwaFmnvwWk25vzdRia7ZxpS+oW SVs2LbIdDhdJ2vNF8hj9pq2oE6cUIrangSPqtfjp4AlF4lti5AptHa4ZLj1DyWygTIe6b6DEI813 nfhd7/XaKs2OKRim/SW2F+GUjlmR3jglkU6JqMpTAoDh+SmR8QaLjGlw5L5G0J6fpDubZNSblAaT wSj4k081C3K2+apoP2nmnZuSNHN5U6i5tQ2+u3NxQOI2MBLCuewonEu5PO9LydQXi6JFDmvRcj0U LRSiwlWihfWVooWZgG7TR+i2mkW6Sqbl5NZp4QeHkLPXNmpHmXql+32jTCnEg7uj2LFX0pHLAWFY q0wpgPxyZUoFD8pUb5SpdQhlSqdQau0sADNXzAIwcZ7eq3Smy1kkSVjOgukwi5xlAPYGclGfyEWd yUUIKIJc7A/lolLnp9zHLDaVNgtOFsbYEpwsjDEK4DmkrU4VvQFJq5ipUtUzHSpmalDeLMVFASku Ckhro4A0jwJ+8/6pffvr8Xl8iZY+1aEoYugaRYElvXBmEoy5POvVceUtoI5JRphWANnsIrnfY69T IRTQxRVDbA661I30/0waSeF/ev7Ls6acC9oqLjvp74hUS30D7UjoUgBJ/LfgMvhZSt+rgLlKB/+R z5JPHQrpFPW/4RpGJCrtwgXw3cqlzyArwdYME5Rzz1mf1DHie/X9KSk7lYNVaS+mefoNoy72CZGR AGDlbtEwhfztvI7hucVNId4xE8mmNXtE2hOZgmhImt+PRHZHMhCDIeVYQ/K9hPTe44Hv5clWo0H0 VsH8vGgPK2Y0yr5ZeTIKuwWA8tWQYwQzagXH17KVyeFJpd7UCVAjY3mBckWgaSkvkPNIuUYzfYDx Txq1JTkgIrv1hZC2aS+NPNCafWFFWXZLSlm9e+3AwoxpVt8GdeVth2vW45rhoqMUh/aiOLQXxaG9 qK2Vbi6TbhB9u746ZyFOmuSbq0zyUQc3RDTbWpNk8L4RYj9PvyMJKJq20XwdwEom3/Xx8hl+RYJ+ SmsDw/UnFRBvpE1D2IjR1SNgKHYv0VJsE8XzGEJfHW8MWVmv7h1U/88mzmlUlYb+GPhSk2bsG6eX Ipi8/MX5vU0SE1BU82za/dlEi4VFB53csKKjhGfgoPtjAyeTlNKiDIF3sD3aRioVDCN3ZBgxog44 LK8AYW03HejoNgcaYSD+LIfYeDb4uyODHzuoC1xEFjsSoChjnrYxC5ArLRq8ZO9VtebIq2KUHY+f IIOMBLaHRbv9RSeOZ+Ac+zUTfrhm1h6PmbxyBnV3Yc0m81o8bRZZZillsayZzuzRHbEHtP2ceCRS qeB/usOd4icnJdNJUZQIZ7THNRtwzXBJTUYtrjuHa4aLXPjjTlFjdxY1jjqXgf9eI58YE3WhDsZu RS4YJyenHaMWDHxqAFgOTU/OAZY9yfWIZ6aIj7JHBcqT6lnWyPs6pAiD2juE18J4pSZmYvf6QmIs qmImclXM9lUxK2Yr+B2lokzcVWbJhLunXpItRW4h8EF3qjMhrkTLSUodTYBRHiNSgTZyhxzSQNP8 2M78RAxgLQMpCL3qhocNVDsDmYunUiWR3/hh8mDWVyFDsWb5OAZAnPoaVaZcNGt6hTBrItaPaRHo bDOszKHkGxR0ItKZuOv2oFbVheJWFnddj6kkUR1iFnMp0oXiUjnhmNE5VgaQCtjx7mTHu3zHO1M7 sVBosr39RdZ+gZCyPsQGRV+3kj5grY24NU685ROcwBsxrCFjkXItIOwQDCNjMT8X6EI22x7T2QkA n8abfGByZrf4WxeNNSh9AmPNHRouRh1JPoiOJhtg6EJB0TDhbHK/dLFciMux5Aw8ZyCxM85qj4RO 0Iy0NhNsO6YPLZZxPJluHzMQzASgHlwWBpubYoeZdd9PN+XvSGFuVGkzy06G1smuhNQ3aLRhAxZf li2LjbJznsAer7o9W3UyL8Gxz1edLMVs1ZIXywYv/jR8zxw9Gbujaew+Mog+ZhBdrBucW7Dk3Y+u 29FQ2q2P7+xU2p0MD/CSA8JjDRnLWHMBeDC3sBOBjU3+4tpZzHYWfN52Ss6v5jU9yOC2ggTS3Vvj qVxFYSKOdMIyDuMG6bGWPMNY0Klp9Srq1MxSfHodomm5VqpQmBTWY8/Xk4YZo7bqJrKUwS/W034M U6aCiHkg3spI14+Qr9ije53odElnw/71N/YvOvS8rVSOHIp8auwKTkLBYseb0ezqoF0sDgc3EWbV 3+DntBLiKldCSZ2+5jRgr+A9kpqV0KF2YlCA1MN8CD2aGAlaI61+9q3Q8CsOvpVfjJJ1i2H9HdXw nI33VMNzzuscRs7veq6B87uea+CTNzSRHfgNi8swuQGRTCSyfS9gcQAyw5eL3FFk+45i4XtxgfMU eW11Bpd7Kik6ibwoyiD7TiIpJip5BD2bbgvvGy6Tg7NECrlUCQ5I9+GAthBysi/dyT0n9HXthHI5 xuxFj/FQEtcqGUcj02j7GfxiKNXXAfC4sitnrT1w1gpPkms6xfvCXueyIm30FOZepIQOgIBONOIY fibmur9Ikzw0c4Itzmr+uB7vwRZx8NMqsEUcUpBwUw9z6NzsMTZEhqKZxTvYEDlVhnbLhvgpTGMO 85igmLtiUwCDDmOTHxk7SVEmdsNh6ZGit+tj7P8fDe/lfs884j54nxJ1wzAl+NyG1d2U4JtOYNFU /YwkIJB28zxIY5guf0BEhQx9pAHf7TRGx4duf74iPlPDB1Q0lg89rtmAa4aLxvLB4rpzuGa4aCyH BzKqKjO5YZGdDuTUVo8bVerxc+0fBaIxK618qv2TVo6o5AD+2Fd4pR6xAqfwLKrSjVuFa6ZxzTrc QeKywNzimNYimRaXBea4LDCvzQLzTRbYvb8/Pn9LcHbu8HB27kgl2JzDmyAIsDl3sg5szif4922w OXd34OP4uMLH8ZH/ENicR+y2nLAvbq/4zEW4xmKNzTlhb42JLfgFrLEEfMlsMgGvXoSxvAtC6N5Y hCayqD1EG3wwcVj/cmCcRvKhLoIqWluHiBTwYAYCESnAj649cQGvWeQnLuCt0x9ARAp6R5GDoKsi BwFZzx9FRApIJ1YgIgW8LAGJf3NkUQl+IFRyo0qwW+aIYN1hN8kiEQxlkQjW45oNuGY44S6YxXXn cM1wFonf/rpYnuC0Eu0pwN9Hoj0Fx1W8Co5S54LjDpzjDpwPyD01uO5wB85xB16bSRZ5JvkbXJkM ziVEm4MJbyYME3fAE60BwOjllGyXCGQGYPTCf43NFFMURE50Y/HML9DNkV5ICo8FlaSRimQvAJVU MBYhJZmcJKFob5TxBtmXlKEMzDQvz2SxdU/29xJbX0FIBYQo5rU5SDjszRLwnK6gUiy8AtWv0y2f rr+9xXtm8/mp8E6yo8UgZZSdFARdeFi53xAsyYKSwEw5blHaArmwsJDjjiZBpKqsGhPa67txU0Ua WPk9EsS2LNbU8/Zo0bwteg95UzgOfWxdzBZDWgS8l4ARTLgHEwTuwQSBfDBB4B5MELgHE0Ttgwmi W4uSHI8i4tustukUIkSXuK1LfiwKi2kSnctkkBvLCMwsg9y4EUGAM5+FCT27pivuhkdU59E08Pje aKbd8NMQKvU0LRJOhQwK6SZbGmBQWu4NMNqehdPazAIbQtloaw8tsDyxnk4vR0CK6ZnRtEayv0ay WSNUm9+zRghg+DXyszXyfI2mu1F3I6zYXyOP314Q8KCoFyTgU5XRyk8vb5eUad0scbxviRAE6bvl GaHFoM3s6EJsQcThfI1O7q9RxAiimMqw0xr57hr5Zo3uTlZ1IQoLiDlydIxkyV0LN58iP17heLDC CKcQrjhFvbtCvV3hGOLFFBUvtskxgxru8xmPZn/GMj73KqCsO804v9Y5323lx5zk9p65IGdP0JjC hpFternG0P0kjr1kZyjbUBlMzq4iya6ibG+VBkvS7m+Jjt6ebNVdhpaEMIAbdsP3wZ6R7GDsfhkb 5zdJUucIS3LLEZb0YG5dmhvh5b5Inl3EvxNqZr0tU8H0sIsJR28LQbk0EvcZFon7DItEVmdLOp8F P9MX2VnQm2dxe0Po6izafnsW/eYocMhziUOeSyTyXOKQ5xKHPJdI5LmEUFENLkBCrGicBBNpz2SN jecI6IhTJJxkB+K3j+JXMlXnNEk262FxyDw5ej0fdCBpUH9wQ1Y1t4sdybcGoO4QPpRrDFryWfrL 2oOUHPfyoOSolwcll7hmCtcM9/KgxEVwJC6CIznuYnHkxcJFcCQugiNrIzhSrGqO1/kYKSqL8qTg d7lqUuDeAZIivAPU8iKVmaVm8ii9BMgLIi8jActSGx+XEzwli49LCO/8QF5GQpgHUBgUnjY+RGHo 3ICU8Oinp2E7+xESF8V+TK913s5ayOm1ztr9gAL1Yj8AhvIDWQsJL1HWz2JczaIjP561kJ2qM9a6 7paM7w+uXl5EJ6Ea/jRrgeumr1WkPa2rVpKALMFoih4n23uNa4bLtUvc92ck7vszEvn9GYl79lDi nj2Utc8eyvzZwwnb+fAtPH747WF4fE8Sfqj9mqAc7qn1klNVRbf3/vrqW3KRB5e3DGuKw6Rp76lv kkbcU1Mm4Q2DbY3SpkwpId/lBJLpbn88IaJPpUnQ8pGflp9FmJ20oa6JdhCXR1cDSRvs2HG4EctP B2TD2g29kWRPOt7eej9J5gGoLc9CRFGm6bq6b9xJCEJZBsVLmyRC+ChGQJ+m5UGlRbuLsU/fLiow 9hIqLaDGYzj0kkdyY3k8GfgQ+vIGfqp2WA5x8+0Pl0tuN9Rui522ZUc3vL1k27IMAC+Yk71Tn92d 9amPJCHW5CliLYI/JOBbZiT90dtY08cFbSJQd6DV5XjXFwYVPHhQDz5XgGiBGjg6n+b+51+m+re4 dao19wDWFSGV33tT00MDHTw/OXb4h1QV7ku9CvelXoX8Uq/ChYgULkSkar/Uq/Io2+vb4/P7w1Nv HuBr2Y8vz1GtquIjvXxfrfLiDCAe5E/au01Qq7X3bdIPszwJnniEJkz5ISD0+poZyApiOVBnH6BO dDcVQwvcumI8FugnSNxC8n3JkuuSaigtccXCyDyiQ1P0IhuZbDS6gijE0gkX5VzIwVxK/a7AIS8m w102GbqfdWs3Cl9BVcfSiZDlZOjBZMqScgVf3SgmI8ayH9bu91NWjCuAIRT9SL3q52A+rJyPXPlM Ch6CY7tf55ltgQ22Qalb764qfXZxcrCWUiIJsPYUIZSYWnWRQumZPZcJrzg0OZgKitq9QTKSI4PE b8T5nEVU2Kr4qCvfF7rlhde46JrSqOia0hLXTOGa4aJrCvcVCIUDNSgcqEEhQQ0KB2pQOFCDqgU1 qG7D8K+//XujKSK4gYCm0Jmzn4fYCsbpVN2LLKqrfBpWdSZG8cQkR1J5d/ai22J4JBkA7xAM3RLz 24tK599ZVxA2GM1+fM5mB9mr/y/tzXZ2t5Es0evqp9hAo4Dqg0JBEudCo6/6PRIcM3en03b53z7p Pk9/GKIYIiVSIj8beZH/t8V5imHFijkicqF1+ciJ5u0u6kfOrJ88cuYCkhWAdAgEbgBtrqf61//v 29ePX74Oljr/9Z9l1gVhrs/j1nqYb8+jrZ5H0GOrt5HfK+H359HaqhI3KVMcvHz39/T6DtZddxcL qnCqfJRlV0K4vKd+KXsPcQHVS8ruldzpV8TB6Z7/Uh+9pOFiAxUA3sdKaF/MoHVngio7E3RZiWxj IqGSqjNyWYtK5LLVI2KdNWJLXckFiy4BW39WIrsjYnVn1q3szJrIdaPC4ZaOsOuWWzSBXIdeGzmm l8gxvUQO6iVyTC+RY3qJHHRdS1A05kQ1mb3XXVFNbuHh5QJEQYbLyI2WotpD9JbG1uUHoprcc1o+ iWpyW176vGCfA4Yz0vrFLazb5YsryZh5W5Ih4UoSOfbZmHlbjkUbyLFoAzkYbSDHog3kWLSBJJPC lSyjPmChf3z/h/8tC1WSzlq1JaUfBI9Lqj4KHpdsmQ0el4zWFuqWYZvcXnbJ1IX1rGHYprenWTI/ F6ou+fpJqLrknwVaS+4yrxhM/EMo88ErdtjGpKAf8ZhJIBwHqkBfxT/Xou0RAo1EcBJg6EsAulld s4/ki1aR1i6Ol1XAywr0tQEXtvzEWSqvzlIJztI/4cKWu2oyQYIilc7MA7zv804x6bj2exK1icQN Ur/BtaTprIPAddA08yIZf+Lm6g2QCKfoP3MRldCEuucQkCWouGxWMWx27NIey8QmwSU5creP+SSl HpRRzDK5KyBfWtoVb+mQzl2xOxhndgU4GKNI0VqeQ6Twor08mLlAGjdHXSotncsDI614gQBIa9u9 lBmiJu0kA6G0AU9lf/55Pf+OfURbIV2n+wq77+ycP0i6xHa13IiSsoC3v3nFJPvtbZLftwIQp4Vm kOLXj/Ki9p9c1P56UYf1T2FrJLjMpnuxh4AXvVDL8uexNWrhU9gataR4lI33bvP3V1UtepYUQy3+ A1IMtZJPSDHUKmvP34uTkeRi7kJV9ewwPKiq1LZNOgzVzpH2lFdBbaa9Bt7kNRjDKKvNjn029rSp MYyyGsQoK7JMb6TDmza5kYj6aCMR/9FGouSjjUTl7EaiY8l51BhQVo0BZdUsUFaVQNnvP3//8Zdf fsbUsWpX5tZvTDSxq+m5YfnbLX3LH77Ns8kS/S1jD9/mBds9kRO4IsVSIgRGHyrPmwjAufdeVN/i PgWA7iCDi2KucH2USWAqBpdqvwCHHKBJdg7ZZyljPcOe/3ssaO4rGK+jFa8jnjg2Fna91VD1STUX dZbewaLOLTsFlcCMq4J2mMC/vt9M0WqnlmOgFF8zm2RR9prZRIED9FGYVZo1O8sYdtbMybIK8L0z biUlLzgC2jGq13ZsJS9AAiXdpZ6OKbs2qitFL/Uo/iL2KdXeNRR3jUrW8MuuiRu59ljcts7ramhk /Tn7CwHGJux2U9Pzrxkhwdab10jrj6bKXLLhKUM+WjrwhtX1vKVuULZ9qAQeKnscqpuud56OnXgQ t92uc6knpsLfDqbCXCBRia9doKLy7U6qs5Nq8jC5SYy2cm86i3Ki2UmZVRYF/jcAGdJ3kCGtmra7 9MfDaT6rpT/Xei/31Looge/sXQoMeHTX8s/xogFvV/BXUtKDKM/mdEEF6hZ18GCYfeMqeTP4qZ1c easkmUPhOv4KS95BEh2rpNKWftsZH8h6VJXLiaqWt+zAKrjmtCFIN34wZ+RQYTKXgAanYXys1m60 v97aa+vy0uo9w5PapzwZcOhtymmxtlkL14ueOzN6XefOjAZt7HEF9Cqbg7M5F5wGzSzu/U11936Z h7WoggSOdQwJs3rMU6gHPYV6W+aOjoZUTMa/BxniAm5vG1xv7Q3u8gbX2+QG11uY3DTgy0tG+ZLZ o9jgZuuIii6/+poc3LdRPWIVy0Sxw3GDn/NDl3wwhKsj9WutKp0L7DG4pgCKs1wDlM+r8k42pKnI rqmUUYb4WyniUYWzWOztgdas/fatS3784hd5nNrdkCzHONdzoFl30EzmcortGJJGuXKCcp8P+GTc N951JAIAvZ8NAe0TPPBdb7IWbfls3bKApjnNnZXJdtYapLy9YHrPDrSnLQyhfWlFbXEX7pnLRfyc xKPFcYkv3Utckvb4SE7uoQHQCeEMoue90MJ25shiHeyzORIJf7bdEl1kxfBY0LNAyO5AIWvqHdzs az4iqIzrnfppgbiEa26ME5O//fu/ur/l7/lLPkCtOmcDAzu0lJP3FfjoYB26KVO08p1GM1Bfq+NA EthzIjRje0Qop0ZBZLxoisBJxdQ6tFtFKhV94BTHhwq8S1PvOXgCjYFT/ybAelcKOZq9XXJad0an 8+hAs4qCAAQjb21BgLTXhXhcF30+XvxphvAFMXzyDQev2PNITWf3cOwlUFhPvcl2mRQ6bXLQrl1q Iu06vZTYS0s/kzrtpNlDu0mzh3Zv3KPaqc7oMvGoBmQkqFzLn9htB6tzFFziSCXfbQEmj/SfaJ0F sMU+T/RQY7RPQQ8puiH/Jouti6cv/u+uO+J/5bT7MLmTw5u+q0Nb313RR6f3dEAzOzmol2yoZulc gwavwWCKVFXSF9P+y2//PKMZbtNulmQCWvOcmyUZhKGaXaQL9BDOr0xPa6ClHmqWZEHbzpoOoiPe e1QM6QhAPgtABoiOjK/Wvmc9CIUUbNbJ8D6zvrnAzdqRRGyWRMyeZ2hi5c3q5+4wA+qVUN9W0tgq X4NTum1zd5GBfLUzd5HZ3hgFDFk6vcz6vQGfFzj/1v5d1FGBPcc6Ju04hsjXjrtOxx026vbZclt/ tqqMMiYnNHro5S6HYi93bmP7GJqxsuIaNPRNEjG0I4mELImYnFt2VD0wFPH9lj0ZRLO+ZMDDBddg N7eiEe1dE9W13Es2u7fZ7N4GN1WUBoN5v5BMeXKB/eV5DTjrOHrw5PIUQWttlRBw7kzwIRyv4Wbs szEcr+FurDo/9tmYMcpAslu7iyBE1CF+BVfqHmAhStyK2fPdmoPQrxdiBOkJz+UVQ0EDRozNvhib fTE4+2Js9sXY7IvB2ZdI4giWiEuq4cT9uM+7+bVE6hjw381wORrJX+wQRrXtrRvNBlcDCrOJfbWA 2O2suBbGFl4vI1M6hwbZSE4ce26PXb9+PP2KdvpIcx/Bs3j31lbShamEBfA8Rj28kcbz//w1L1G7 UYIXqpK76zF5JHw7tIgm/AIwu1UOPqNC4V6MqtLxsyZlnbQTHB5ro1VtoAuXoeT5Z1/W1g4VktjB ynNoDMsdlGWVRpVV2maVOxW6rWoDjbS0Y+ef0SGdKgwd72ioJ8+acvLKCl0CxFF2IxOvDcOXg+UI sqbVq1mg2e/xlsbpwr1k3JH0ZH2RWC0Wd4mSIs9LSpRam7+EPRaoKOfJTj1cbp/bNZA3XjFIn/Lv rltXiAhtMX5DskXjxy5pP3ZJ+8FL2o9d0n7skvaDl3Q4I8q3JxIu3A4hMUgsXUKeG8OyAf5hYHO5 30PI5mIrGQt8mKTZxhludm1Dp9Ctvg4dOncdkqUa4GoBepft5gI5zxW2fE5I0lBf45GzNG4XOifv 25NoOF0gtrxADpMKEMXb6gKxywGkDefVYcGZWVW13auCq9duVVXrEYC8lVUZvE5s3Su8TuxyAyba rQzRtFv5FFjaCaGONVVPgQU+kjLgOv/sL6OTnYmqXgFL2H2iQBM8ki3ziiul4tw62FLQmmJBl6t6 oO89gJfD6qoH9ODYWIse0PIRsu1HiOcenFWBFrXw29QwWnfMdfaQq/cQM/epYZdZdo09BO+Zq/cQ ZzeskeWldOHayw9R1K5e/p1KhN3GKMilY7LTsXr5hb537JCYz6p0p6p6HSW9VyVFOcb2OkJsnKvX EfgiysTYx88qGSi5OgE1tSDZ5F2z4CWZoVGzwC0JHrX6wqkM3efpxmvYgq8kXvWNnCh41bs/qgLb PtHE3C6k46o/76Io8mOpMnLdjjEv2rEoJzvIvGjHmBftWJSTHYxyshDlBFFmoafs2A60jSC2zZoT iU+e3ny8sw3PWfkWcts9kJXvlk/Xggg9tRGOxKlkT91bJbbAjbDlZs5CyW3pQ8/CbE371SfIA2SP 9B/Q6tOrfxmfRfty6EY70fIRB7ifMRUX1k1M2ArtzVpMfSxrAoNLAiBX2fOtS+ijuL4dYsYXbrFc jZwcn0s23zjfvXafmWqOavySQS+dd/d8csvryp9e4PXJ7mexgM/GiSsR5WGcwKQUuOQQDUWad+ix Q693aCAvuVBsaPt1iM5+HRuQpcqrx/yjOLKghs0SFrxGQrUJD76OeWr3UHnsYfLyLN28DW5pw0CI IVhHmDNtuB1AqNq24r3jbutcgy5fg245cxa/xRK6P05UtVt0Zzgaa9YZdmpYHXJwAkUWefMSu3Wd s147kMtnrNduTZHQDYfT958vm8OtbyCtgTneJsGTDhSCQ+72p/xe3Xo77+8uwuOt506CwhSBRDs8 vjUC3W2h5hOgHR7fGnDuSCJhXbsx1+/QZEcmQRaOvIEs3p3zLgdqDTcKGR2eG30FojrK5wKDHX0d Ke2MNOBIqZ9LGOrYZLy/YynpMFxb8gzNKCwOK+l4ORV6OR2T+Q6i7Q147r3Ct+ZyTJP5puUJNr/j zRMULXvYHKeX1pa24fDSGqQcOAz5y1MSpzrk1oHPR9KnGdU/nWZ8B0pdvNJp17XtTNtETnk2kTuB F2hcFlZElV9MrYZVYeVOyNrWmn+2ZXXyobqKO8IB5K9RnRRFdfyhd3XQu5O+WZ3ayuoeelczWzil 2tW5ojrx0LuaEsFp2qxOH6r9Hv59cq7URv4lIVLq/oEqhGLy8RuoLPHGJV2cqPOdICqV8dTO0M82 hzHNAZrw2eawvFmd1Z9tDrc2q3Pss83hbLM6v3y2ObxoV2d2sSDwvlgAfPNoM3VjxnE3Zhx3g8Zx F5aP7stDZudRv77jM77iA3aw6VssIJNUxvtSGc4EGLoBYuuveT8KlC0rpw7k83R7r/SWMBQ1nb3/ /76WSpVf1k8eJ7+TkEtwMi1rW4Tb0+/uEtzZcC4MFGwe3EW3g/6TPxalfdDRju+X8FG/1/N+WI7s mh1+yYo1zq/N+8Gvn/ViK3uxPvRirXuxtXuxfdaLgox7ufEvljyOdScONu78l/2obboWbYul2/Z+ 1Zxt05Ja02fOtNm2fTn7y8Ps140z1px99lkvWNkL8dCLyxTwdi/4Z73gZS/Iw04k9SYQ7V6Iz3oh Dvd+wlpnRVrUvnghdkDqUtHPeOC0XkXdCynRvsQqIFVBVZEMTKS6C+Vn52jHbCiQNrZeFu/djbTV U3jmlJ5rDQ8cG3ivcGwaCQTY0owY24mPj7Cxs5OaoY8kCnlbLRP880TC7SLeVooFHmzsyUaYf0DF lLvaJF3zDlbCis+G7Ln32RskeqbsVC6vyMS4uevGTG5M2Pc1ycqst2+4P287Ufoi4/488C3P6Kbe ijlcsT9SU29dtlYf2no+0xx7eZ2g592XJ8i9TpDrTJDECXKTQF/v5GujrtOow0bdZKP+daS+M1Kk 6vOefbQLAdLy0nToNB2w6TBnUvFgMPfqG9FnmEwNVx2wkPjAszANJ+AiiYAwfUiSpj7jAS0kYuAG zcJyWCbxw2FROSYwRf7LOwpC3jmMwlqSiYds9113TFbJ73RkjUqZgXF0YcVdoJa26fqPBc0/DkvZ OWNsgPCEx10TtrZpn7ls2g8b+WghNlk/ZeR+mZD7Uxa2SarEQJC2w7Cdx/0qDxzkOSs5orpyObzs 4su3ypbXcJUZLHQu3I713923UR+T/ptVRXPJlGZVpiT/TR2xueHAh+S/RFkJr2EuRyUSK5FYia8q OQUa/xQmnirJqmpgZHKrMvHJVgUJGLrGe3JTpuf/XpocA/ADw7Ne04ld370rD3HY5WacTVf38ZhQ 12jNFq219sDRWk2WHMRStmabrdl7a0KUrfXHVnMfB4CSn62ZZmvm3hrQLmFrS39s9dAkLxvTzcZ0 ozG3N9bIt1s2VrWkJplsgnqL7AuqHdnHaY7sC5+J5eFMdKLkI3/3Ya7P5TTy4+nlkUb6iDjfcjld g5fk0gYvyXqnmPUGXgrmAhuTDayXBkCb3Oq6kiFAr2VdF9yYpPe6IDBUVmCvYA91sogLDVYiwW0X QlmmagnWXNrmDVzesoc1Sl4177Yc1YghksGxS22yVdtu3Jb1ATnNq0VtF8ygbGDNxFFbBTcLHk3J Amvz6lKbbWlldF+zCnEWjrQidD31shAukDrp77U5z/e++bq2hKqL29Z5rO2CqlONjblSqEyVWzNO ZfIx0P19zr9dULGqsTUFYEfVVteVnkEhcD+tyxUWqxpbU6clULSqbUXPkT5ru2w21dhsLiywBIpX tR3g2DhIF3Jt22WzKdmqbd+6Sta12bx1i9oum03p1vZQALpUuqqNpM2mGG6P+Ntls6nWZtNp3mxV G8UcNkHn2uhls6nGZjPHKvi6NoRwGlwFetlseukeBF3vNkavByH+dtltemsdhH0VdL3fmMdV8Lk2 ftlvmvYOgq63G5f3g8Av2003tpsxUFe92UTabMYUB0FcNptuIajTEuh6swm82cJZ22Wzad09CLre bJLfD4K8bDZtuwdB15tNLfeDoC6bTfvuQdD1ZlP6fhDUZbOZxmYzIbk76812uk8N1qZTLHpUmAL/ GMMXq7FTr2QskKLUnO22O4DhWxeD9KmKPGH4TBJbFpfLGWQk3TohxvHjukiC8cVnyYsLz1ZyF62r bjuGJTO5v4DllAQOQgmzXNjuUitR6EvqdC6WJGsZTnR4bjuF1420De5bo9/pzw7NKBbge7jJGp4K FFQIsYSZwt/EAkntj4qQD81t0ErUuy4QsWX0Idv0epbCtXA0EK4Fo2FPo2HlaLybHE1IVjdj5kYD Ttw4mniiOev1jDMrytGAzAOjkU+jkeVoQpgbzbokNUarqdGsICxN8YHFIkc+R9XXsGwR6RcL2LT+ 5mH0ppiuFaQuiJyiDwVoMVvryidna01IsigaBtacLV7iw+/Z0vP0gSFsqqcbmewpcN3DS/wWRWby 5B0cG/HG6myEViDIupKEr05o/pU3ofwVtjoWidfjtk/fEuquVUnFT2U7FlGT81UAE8fmC5zESxOM nTbnBYwdCyRcPJdzBwe8yka+jwSHTpMtw/kXKzkOnc5eAQA83Jp2+MxbV9nhY4HkzFf3Avank/4+ fsfLvUHB+tbYGwmwsVVbhKXNyJa5yQVOjDGoevx22+GBnvbggbBWbVLnILFBmnLHvr22eKeB63zq TuOzN4WYvSlEWiWYN9EGCxWX+O503zn5gPtNN0N99OmYiAXcvpKb/5M3ZqZtH349IHRuaqbl7B0j Z+8YlcDPq/6Tc6F4ZtSCO5Q2IVu0entBxRAcrG23zW58fpLam93i6VJ2iogoFvCTouWqZzevPsjw 2dxFoc0Hjv51NYn/RS6n3fLkzTdnNO5uvMzAhlhMpNhHVikvVWtJfyljH2Mxl5B58hZSdC7zWhYA aIAITRbsrEC4tldWypCnxm4fsATHYvwDluBYTO8XKF2eDt1SnmvI8gXn2j2UcOUufCUyjJ+ozqyo PCtOfbSELqUkazAV4IOE3wK3PDBNuB7jwLotbe+2NEvupycfbWwvJ4+2T5rJ6+2K+wOc/R8cncNb P4cBicUweND78WthOzKDLe6WTeUawRX34xnBFQvyzsJwrJpng86ZyFpfLcLXRNaxmEvsYIN0hVm6 2SBxNTBVpba2en1MgbesbIsbkBaexUi/GKmL2bJYgQq+LC6rjI/btl7mhHfmhNfFZLoX1ZXmueQF Lq6MDVSbs3uy373KArmRpSym+pOh6mKsLKbP2OOiGMSAMV0X05fJsEfCzmIyOMT1s8oWuYHicjbn +730dTFeFgv9YqEuVk4lL1l0zmLQSV5vYwiGKgfHt87geL0fWbkfeX9j8XpjsXI/ctYdHGdVMV5O ZexulePMnA5FXu9HfjnaoBLuTG/F4IDdLRasNxgENJ3t6f7o6p0iyrPNTX90pi5WzaWtc7GV5HW8 3mDCXobnu8OrtxhELWGDYukOT9R7BRC1Z7G1X2yti5WTKbb6pjT5poRy9RYDPz747hpIxaTexE/a QpOiWWjaFMUIjbUToWELMstYQGAQhQWpogFsWP4taca78QQvdlWAbqBnOxd8Io/sXIXwMJifjgI6 BRkCVvliEv/yP0DM+FeHn7IpREQscPAUqz6qtFLRNp3iANUtpg8641NAX/70YMLdXhCrDuv2KVbe 9wCo69bhEFcc5QGzTKG/YgExOWevTOdD3UTuAXyBr/GU+eUt27bI38aySHIUQxgJu0HiYjGQFe11 w933HK4dyPgvS+HaIfBK6jxGYK8gsmWkymQJ5qeyTf9ClTDSpqu4zHjT2MHLqQFV41iImvPrXAh6 pRqLpWQiHfG9WESY83ZfhcS+6rJp0iTHbDTtP0D/rhtoGSmJLyApXUNN1xCRRVx103qBrC9bj/Xl 0j+PoxJ1W8WoHO7sL+xf8hMj3ozoW//2xFf1uxqq1dtaU7jduwixdmlU7N4WjOpsp7yfzig6K5t8 IXswM96VZFdNcMpVd8orWZQsSfdlAig5WnoQ5YVKGW/dv3z96jP1dCyuPtEmyeI/iO9eCegsw/Hd 8XP6Ql2+kq2t1yuX9Xqy8g/QxLHYXPqF2JO59AuxwKvVYmB0k0TrscAIpVX8zI59NpTdOH7nx6oL Y9Xl7MbrTgBYsqWc13aVoDUWiVcTa6ZB/zVVjSjK+G088Mw9f4v1Hvlqbf/bA2UZvzXpW/fwLcnf uvStf/iW5m9D+jY8fMuOb3dl8jWxcfxuG1qxA4D1+hkd+4yNrT/lY9WJsc/k2GdqsHN6rLqxg0jt YKturLqxgziZiHolJXvNbz5ekb5IRQ3/jJxUtsa9F5xU1XllyJZ2JAhf2uF9FXY9FsPgGh6e0ne6 70Ve8VgMMw900qXvuKeqJTAllERAS4cISNaleG4omI77Y8+HjXfRHom75wnV7IlVMVnd8aoRy5yb hQjy+hoJ2VpjIMTNMioRmCnP2Gw/Ii38eUprerZepDVdiVxe+yJZpy+E5b5INodlI1K+N+t6zaJE Jd1ks+p9tKo3WoqjVWxywdX7aFVvtBRHu1PAqCOi1/Yj720ZC7WSJgNM/BlDuDrH8EoOHIvYHPHQ OYZ4AsvjYVYs1b5dzoulvCYMR3XxEr5TyB3VNQaJpkeeWzP2GpgxscwMimVm7DUws6+BLVWO36PC 8bPDp8CWT8HSfgqqKbRIQaVEM94uh9qlOz3rXwTAlinYjvQ471OxWkexPttMzPYYepPi9FBhcBhg KfVj6E0qh2ofxHdo2WIuP1nrt0IpcsnuIWTX7kGZvE3/bvbIh9Yf4WQarKhkKfwX5sdvRTaFPD25 GJAjqJau8WVMS9fwc2nNYoEUU77Y7thImUztHBsROLbPVh1ogGZWIRykuuzznoYtrwLX+yos5yp8 /XRenZdVCOKzYiBH2qZO8/vX38J/5Sthz+QdWoF1UZf4L7yC09cUbBZBt2q1P30/LxoKvEB85/WS O+/nxg7IK75Of/36z+PuzGtCFwyUyT8kKkq5gLHCL6e5A3BMP+1rW6b18wst2T1Wup4+qvUbsbXz t4hyIzZRueZihyNtBTKxpZ0TCFMCFcV02okrJDpu70Rqr5yxsVhCAzYOTU3EcBZIYbnxWpT8jCsr lOGDm0Ie0a9HMYCPppmg9mbgKPYRrSdjSylsSGN/xH30X5f9AYq66mnScdPllSWf7A9y3R/k2B/y tj+cH9kfEGE03QsqLr2gB5BkZ8CpeoHrXveCyJuljIICBveRfLiP5HkfUba+3UdvrwJlrxrAexVz 5LKxgC4Eqgde8SwMUAiNGpCnKJsUWSor6W9//MXGx/63LLNQniDQjDcvz8oYQwF1mugBuqn2dg3v LMBS5eyhcpK/RVD+NaP4CconOyifuFxEp+rpQ/Vb/tZi9bRX/bZXv2H1caLvXa+qz7YyCkopI8/f 5p1x8HJCBHR4JEROUt9ZTuYdRUx9WdvEILJfa2VUDgX3dzw7XPXPjhf33QHon/yYU+CcOlLL+zNd UyX9hSUD5c8ZkZiInPFmzHzSXlKpLNlSmYy+Df/cieX6fuYdiwVMAjG/MclnoZSqZD5Y7vsM35Sd qAYHotDTGCWvJ7tLSW4Ri4mcIrIbv+X+KIeuNFrz2cOEmcqYT3eYaoq44t3InCrMiOo0oChpxQMR ZLWPfvl/f/Y5FyXOsRav16e2zV1Ebd5FGtm4SNs6hCFwZ7MhvTaiShRSTcieJsR9r94XSGM2CFuk 4PKGt8X1z4flzZHxDI6jJlHMQ+TbpZv4NOdu5hJhFDpA7ZRbiYJC+fJWWtMeTw7Co5a/rvZ7Hehi KmN4rraT6qoCagG5HoAnEMN2WBdd9sCaIrceSSRqJR1ZLJx8fUZ+0w6I8+OJSP+nRHRqV/6vPKug NaYii8nPbAajJl402eVFk1VH9tQLKR6B9uIR8IHxGuMRWE1iUvp6CisN9X4qWclKwwGIjl3aUQ/n QtR4h6JXQeUoUkiGUAA3MYqUVubSc/1XlJYgkm/QJcVA0Rp0SbGdhHXMJcUWMuySYgsbdkkxiB4c kNPYMuR7YYsa+0yPfWaGzGNssWPVubHP/Nhnk5IrW2vJNXz/6acsuLK1NLbRtrGNlgI2A587Ud/c 2kXhJJx4FhXYih4NZitWo8refaE0isVM7d8hHf8Oqfw7DLKZg2n9gabQFTSFsQBmvha9NA8ru6Z5 iMVEnR1i62SH2C7FLAr/7lH4z2fqmk5i63iRtnr2CHrHDtRMoxiAbcmlmMqpMmzHN5FAjBhWxAgS AgjaccMlsrN6Hmhi1Up4mcV2lmn5w9alEqlWfModu4THHw8z3+6bHe7UNYdHMIrkVZa0UTeAIkPh htFTcLfwwqCqUXoCUuKVBNaUpQDPDhbf/BfP4uxVbEZxds/TeBZXOSOE4ZcRHxEhfGXNES/Z88NA 1U2pY+J02xIKjaL3cu1/FnMZRzI72+HRSmIuPhiggZqd/u1BlVgKqBYDpdKEPcK/L3yvS6GvsF35 21PGQq7fPmUc9gpISJKX9FEtOJyk+ZESybcapS/NaqXtEBSy0lb5Vplc0FlMO85iVzuLmXzF+jCp WussMtKHSZX31lUexr2lSwAyk3h0G4jlYmnxJgfCYrHjzXtyMQu21UmfFRimkP9drU9qsP2j2oUK /X5yuSVkTsX8mZwER6hCDe169uLhhtQU5cOlSvtbSpRb2ZCWBUz0qQSOaNfkHKzWJWNBQUxCy72o Q16tzswdjMp5+o5iBl9fsVYej8v9TC7F9KxCzAx2EHIztzj6k6jvZdWSRfjdQp9dujjbFjMzSVmb frAlm2gLSwrs+Gat+SKk/MkGkawp2NzpuDMDexZ3EfjtZmwqzK+FRcH3LQr4OHg2lfU3Fnh16TPv WgfYZX8+8y6rQssu9+AO+Zdffss37555G3ZHwnEcJfcsz/gSBpbfFdpDx6BiWNShU5Ys1cVJvz+H weYRbCl3etaSWypy2TrfdaE8An7kXP5QW+agY1y0Zb74DyaFryRlyzP9SXmTivjKRpO4xW+Tdk7u ABbUAEwlJHLwdHn1beO3EMbM2hxFu1YPEazD1zHkJwf5fzOHqlEJlodCgzJloQTwDSEEHWn+FOSL A8g3VWNLtju2ZLuDS/jma3DJMxFxVgU4Qe7Ojkx/ivPFw8GJxGID8bMZB8qJm6LmjgXwse3oeaeK V9hWOKWFh4e2jTGVBsoBjjlgOuB0yCbAx+CYfAyOyQfhmHwMjsnH4Jh8Fo7JSzjm7z//Q//6lx9/ /OXr7yYbBjhbhr1CnJ0erZ6OsCcnOgvgwxXUkxacn0YOfsNBxxDPCVJuRoBKUCoL2DnAEeeYw2nh PSt84rjGw8FPyvLtQf+oIUN816X0iURoMjjZQgjjO3/0LiUr2bH2q7s3mUM8aeKZuPoVTgMnMVWJ pIpTcc3HvAsr+haNx7PfzUGZV+Dt2Y6dc2Vx4VENUh3B2pZaDZfJFOG2F4sRjgSCWmcYf7iUc64i Lt/SpMZju7YPMLiL1vxoqjPtETnYjpvgS1n6ELgqsh7Fv1QGcCb5vOuEOAUSvZQV5FQwoy58DlGn g2ZvrvmwKZvrwXdDj70beuzd0GPvhh58N/TYu6HH3g09+26U7EQ/LigIbpZhoALf8+xMARW4YeNP 0p6PZ4f5a7HvfHVDB6gCHXCW88NoBX4qvM+2XCwAbsjRVyxH5g4/SpCfB1DWYs8d24drOVl6Ubn1 V4b2lR96MidgZm2Gsh9rg1eiOyG4drfN5hkvnp0l+fj2YoeRFIub8sJwFn3+pmckrR5wl+xSpB/p K1Zz37elr5X7M1/K9mRRxCEfyvdCIJLey5Zt0J9Ig7MYevCFe8Un4IMQzmgN/gTeR8khJKwWkzeN C1+QrgiYq5BJlCAvwAFTixLBDwMHxLK8AQfEEpoLxzLvggD2UgAOmBfgAL5vYpGjwAEBSvo4cEDs mSZpC5R3bkTR3ogCxxPmwkPE+paFYqDRNXmzwi6hVEpYVP//64yBRRe9WA266FnPRZ9vbrF6dNE/ igD5GhbbhvR2DqwzTXk0lK+DALiq8MBie5v7w+Ee77XmNGxZXhKbnBNVBLjzBkUVAcDYQQ+92C0E Y2KNOOhXRzz0gmxDIpAgQ1GbgtCxz9jYZ3xIBBJEjFUnxz5Tg63qserM2Gd2sFU3Vp0f+2xS3BO0 jNP5oX/78Zc//vH9Rxb4BJ1FD4hs7ZkDAwiqPvG2C4qhOso/hup8VRhRwdgn3nOxg5WnffWCTcqR gm+fQCMEF58gHQQ/IQv80bpDcwE0BEr+GOhU20iEQFfVu/X77J4wKKb0LB5O3sQUsWv9BOD35PLM ngzUJFQlaJm+inbiLhK9y9m9XfffExfoUNlkLgaZHG+cnzMZyhfQdC0yRRGA2ArRTLh50FgJ2zzP AFTOngChWNmwbTds64YTbe67mSqLpwLwtoK0GbfSYy3KPAdVV1FmF2BngOVQV+IcZK1OesrZrn4N YRBa9tqV2C6mirLiyXGOIlrmmmU3jq4Txfy9KuAnr4Q90daOjNkKf2gpecqS97Ua2KpQmDbJtWPc dTEvK1ksvhl7ocYiSYUZc/MIu+Rjle6yioTwcGoUPo3cWXvGYJInHIGpcATCHs56BfjPjvrFSvnV hjl8inAkU+4u7cvl3w4Nb09sX15LbjKGUrgDUiS/+fUCKfo6tkr3mljPe8KdyR7NkyJbBbOKk5zW sMcFqBAZwus5K7DY1Wy6K8y6t2Kk5AgWPqB9en2yT9t6awQyZ24WQGc7Yz0WwcxZj0UIb5ecjDus vcCWHusrl9OkM3BU8jRK0JiphonXFigsbpagQ1I7zEHJT/zv8ngu5boVliAJnm30h69v/vBkWVqx qmS/6L/XxRWBp0OusxtHgmcaiIaKhD0mnacjbcSRYmyp89RISMImm0Da2u9gsYBIlpWl76PHYYBn Wq5nLtgUBFB3ip6dOttIYYUkPIQVkoLZT5L1kxtVkmSDiTPt1rv7yCNRJM7WQY2UMHVt6Sth6s5b MpcMNYPZIwEEdhAUFbuzl0Xhn7ZjevdsaqTCGEmKSLWFtXPTZv7oWCjX+d+hYPd5XvLzLGnA88Cr AP/LeRBHTNhRDAI3wUR2F5ExLNpVLiDJ1CdCtQRNJm0DujQFskzljiVAlSFp71zotg9pM26f5d4Q 5KwTDEIrbvLjAYuVnvTmU5M8n0fo4xEt789o+Vao/DmfEKZI1EOnD03AV8m9JOg3z/DJoU7vjtTc acGrTv/20Gk/R84gAcU6I1hIyM8haItlbGp8oGddF4VcFoXcxyf17Pjs7Pj8vukY+XObDkInB4gW JDhvZWglZz6IFq6gegmq2wDZglT8wzuq5Puph8ccDs/taO5X2GMWV6TeikuN9i81Wl9qGhN3kfYg ko0mjaQchO4OguMgtHsVoczWq0ZsuRqTfBOisYSJC+G2hADXHeBDkKCoefNt013M39BeNEOubmn0 2Gdm7LMx26cc0yzlmGYpBzVLaZec5uPF7VXLjQBjHnR7SaBPfnZ7SSe6ynp22kh7sFm4N88X7i63 jHq+JCik454vCRjpZ8/XiP1BOjGHaJbAefxyUIfaDej/Io/+L3zMT0V2Bu0ovfwEaCoBdT3DmyF9 +ASZKgP9BJkqg/oEmSqD/wSZqhYyiRhVg8GmaizYVI0Fm6qxYFM1GGyqxoJN1ViwqRoLNlWzwaZq rfIT/fC//fb7r+gwUuvhqxQPEJ68zOs2zKmiVjqMPFIrH4YRKbAhDMKB1Io+qsCe/CRnAYskxaz2 k5z7mPClLAI5QAcRRGqjhXOOtZ1zrDomW7KYXITCb63cR5VcqDbfWHS4YXN+ArX5Oky04VFLYUiV c0eBH/qkcO/7XAitiwm0XY14oLKRQYEbFZOcXLGOhWq11c3RMsZT0TPeuecF3AO1ai+gGsOXKzp2 C9Axgkc1hi9XdEx4UgyR0Wzg2cF5ZywT6AMtn7/E5CYCfX/j5FM70pseyUXDci/2ryk0lbpcAIOX Qs4J1uBxSEwOWIhTFJq2ttCU86Wog33pOajP1bXrUZFMQa6gRV3x1t/K/LSuFAIUPzjC1gdj3noK cUqsOdiYmDMJZqngulLrKU861VnpUUJcDtF6P0Tr/RCJMquNEiHviNgbyMVgyuQ4+44wdLuJ4Ury jzagTNbFbYWcpi1vcJKvinXbM3/uduKw9OzEsNRn11TyOEcNYV2ay3fwlBQl0qsW91KyRLbWj+7M JtTkImgcip0rx4J21Vu3bNGICM1GRKga0Qvm1rgf133s6VL2JcGk0jS7KBd52V2HijCyu7Quuru1 52Sr5+TIA7RuXd1E2U7DBts1n91shtXZVZ4l46zWKIMRrt4/6UFfWOAwWOyJuZp4T1cIZvZv3v79 Lz99//nvoBH9+P0rj/LI/Jlml63N2WVrNbug+KZlNfS0+pSza+XSnl0iFmzYotZNe1o3vR/3ne4o ywetlKOHfFDjgpTje2tqTMfHxQRgsmxewLXH5uye34MRG93DYMRT2zuLeXCCsSM5Zp0dvWA0qq6K nUk3T8RquxOxVoQayhuEDfDO4pXY0WrxlmyIUGGtk09VSu2RNacxzJB2jvZVsPPucQ3+Z+vzWxBO UpKOYH1czhmToAKCrBV7itiusdl6OVMPy67vr3AS6YUjaHx5cvOfBRLl62pvb8Dp5k/O3MPNb7Ck 263VzvSt1eaPqkDIbv5gL4iQr7y0a29pMyJW73HBYufJ2stvWEt53R5eRGwbwMGiuOzuN65mrKMy IGO9Xl3N3vB8d+arUM/m2dGHojScyUdv5s3opEnnylu3fOXpI0dNwlxXzAxocyIVP5sGuG25GKyx GOy2GOTIvUb7i0F7vSVnb23RW97sLa97C+BQYIJA6jqZe3si7OS1s/R8TUQbx2QX0u7sFrJZW9Oy s6LZWVF3FhQXr+Auul65OUJ9pN2MG03wqe2OIfm3I/b0QPGgsUPvqoze3egUIqK6LEP7sx9vIVl6 qzUvI+40P8P+suehGfZX+x40v9Ala64/y4WsRW8/cdxPAncH8i/cdgepMxprcKDOoIC0OMCXDmKZ SujWiekJ9X8Y0HJS+Wlha1wqW9oOqjpvs5aIjKDvTKS4kifhqxBPREWsuvMy94+Dzj2Al3QF1tE5 FckoZZBWS4lF0i0skiuxSBpUmJmEoFolJ/nSdyJr3ZFITteIBjVohntF717LKb4brV/jbkZ6Cqyw cVtFhXu7uDEzAAJ9sXFHlodM94xuymPlHgP5aC+QbysD+bRZa+PV0jFeVbYrDV5L4ZopJ/6aDAem 9yBu54NowPwYazHXPKHnJvYIBcEdBk7HKb4xbV/z6Wjbk04MSicZSjp8duyJGiZPqGG87mySohrG 8nwUzEY7s7pS7CdKUUa+U2fhtJ4RnZBcuC9C14xb2plaTX7Rd3Mxf6ZZFc/8Wbl/fpajS3ucf0Y6 TFj71iYVakd7vP0BEr90aa1CXSwg8a0xHTYs9/3fT3BcLqZrsBq7u8TYPd2mDohxMwOrlU+C2fWX /X6wz/dDbsgs6OSw2yP0HQvYD4I6zLq+HVGz8s7WXzKntLkyjzYebnN/uM0R2ih3Mxq+CLJPccVy SVA9AJWxdlEZhnZulg2pjsxGJ29tc5KRTtzaZiyFp9nc2Gd+7LMxT4IhyycyrCGXZBuGJMEaIuPv gnVVTy1dH8XpUuchOyumnwhqhqoPwr8NeHNmxBkDjDxz4oxhCV3M7lil48j9P7fJZqakxban47Bw p7BgS2HaAOBT+GYGpyNM1/S0hw21B3P4ZBrxQ7+7HRP13/7lP/7jP/LHkLqpuTNjN78MyKBf//lv IFLESXf7/8UsOAZ8KEuz8L8Z7f4H7lex1Ibe54sbVxZodFLiMtWzRKqTnR8Xaw96Yy3OGhSrK84a I1Jk+rr2ZQnVm3aM+TCHV2Zs2kEnsU2cY6ydnCcdgJtxZ8e7g199L5lIgfPsq9V/y6XGHJxGjl1L cvBaUguGB3TdPlvpXzFH4ouFADXHA4dszXtk9jwWu/MsKhGqmbQJGjqjB49yB9sO2TM+BNnQJ/4I 8t7cGdJ27WVDyilaA+YN3tTWzHGabW9bGdxWBlO5rBcdKAv+qAO50s5gjOzUrSXWLXHB+OOC4RVt Xq17I2OyS40Pe74PssxvzgC1GZunORlRx0gjjH0FuBrX8YltNjvFjNuyIzDKxqa1a/ZNYyrR2Dj1 0VUJzpSXLvueic5lE505cXtz2GcTd2Knbo1160+UH+NP4twNxMze2ZNVwj4T+AdxLeaIJkum0bVp Gl0r06gJmD4ultga+TWO7m1VMbukoJOG7wuDTmqvnF2SBELtzYeFeNbafWUXkwELkEbNlUk2DsCC Ch0fh88uDgu6xrwz0AJlijQPrsem08uuZg7haoE7BbZG1zN6ePaye/QodjKazlwkdo8buxGC33xt KGnawxcC899xPDfzTxylyWSMiQUCE6Gq3YExGF/pE9bzNtMFm/1scoiacxRZ0B5mXFGWvtoULe35 YzFxqIWMg3PNDgFa7RhTqh1DstlBplQ7xpRqx5BsdhDJZsEhBDLb/VZAsa0RBmAhwcNxWu3jaa2A +RYoSOc8/hacPKSJmEBBr4GYsABRE/HmF90gpgG4huXqowPE/eQBAvVoaieL1yRrVtjO8HjOUmDF kGXEirGdKcZ2phjcmXLJBB1Roq0Yrk/PmS2xalYi8mrlbaeq0501pwrXXGpkMnFV4GNhSD5BFQjG sGpFaM9zLGm9UZVA1Ad/RH3gMHeVib3TgZRFxlZQja2gGlxBveT10Gs7jY3r3fL0vOX3ALidlMLb J7RKBrNbrXDj0JpUraa8Oa01FuLgklta2W/+jddx3WpeR2to4Za2hg3hfayRn3BEWIOZkvza1fQK Jga7g90Semd9Qu+cBRJsLH5K1h56Zyd7+Ppek3RYqyblnN33I7+JRnzf1/gWAS0vhXE/s0HX0dUW Yr+maKetkx+YNe2Op5thnbYuGaAov7kfwP9s/BWBZ/1WqjvNwK61Ija0nqMxglaOyALD8ZXIyROG AycB1L+ZxNz2cC0dmpXsa1Z1D3cyUA09NLQ+lBdu2+pQ4jkJojyUIaUEYQSo2D8iCrXBTTJwOtAN x0DvDlxU43GIbkmhlRvv2jldzxNN0RPtAKY3EKLtdnrQrONWkWgYok0rn4sDVN5AiLZbl8/MFK4H 16QI13Sguc5EaLsVfXjLg+e6WuEVbRqr60Rng+vtFp3tto5bj67Zree219SqbjO9WgzWYorY7Hrt cmz2Ze1219V7bLY7CDmHqFEdIfixb8cNn+KKA4bM05l1eY4LZ9b1+OfiruPMcrveqb4x1U3QYnsS IkEJ0dEDy6JuEmLmxdgFsFNOzOUSQJ8t/UP7Lp86hqb5jnzaaZ2JT6x2jiXEOkRAtD0BB5Kgjlly bC4mx4GaB1Ba96fmhqcLFwhDtpMwpMMZgiZGB4jAGU4NtyMGJ+Qcx1NqdbL9ueH5PDyuT76QDmXI OTxBJoe3e+tmhieStr31te2R4UEawpHnSOjyOWoyhtTcng5U05HnSIQPnyPZu84FXucQsjX1HEk0 ocbD90YYcq62PJ+kHmGIaz5JqjcGiWNQ70+S6j1JEp8kVT1JTbqQy/qpwScJNE40rVdxtCii1SG0 DqK10LxNmuxp5E6f5sCPOHVCdIp/jNs2HoRgShP+X7/loNKeSJMnDoKzvGmyTxy4G2d0L7RMYy3b R0MG8OPUkEG/FeHb6htoyePOcx3HJrUSe6s/McG5I2nFsAnOWT5ngnP2Ncmgs64zPJMZeNwJW6QD 8XbY+OGRBNjQAqGJ53aKxf5ZRPge4YlI3OZAhZ0aJ1CPRO01+TBTsPipvXaDxd2hwirW0n3gUTjf /kN5TUQXrE10UUXwO1BeB/noHYSMDfLROy+H+eid18N89M7b4Yzxzh+c+OHh2yOcwoGKPED44SBy 7d2w58I29hkZ+4wOmQldYGPV8bHPxNhncrBzaqw6PfaZGfvMDnbOjVXnxz6b5EDxSxlq+9MvXz7z n/hlPEOSX7ZhnhK/YJbuLkGxKzPwefC1DxKb+AUzt+nwyKKfMEVnuTBMVuLXZS7dkV9PpqJ3iyPO 6Yp2ShUeiUFclRDArwEVjHDVn25EkQiP8lsSoky863vQAns6EfMb7TedJzzKxXyP6r5OuOcniCs/ 1R64WO/cE5UkApbLsyEwPgAY03fBmJ6Sy17eLcz/K1fA9jfQOAiKPl98Xr6BHNydlcrtIZgwSkAL 60pAb+2+YoFeKqBkSPHxQAPL95Q4R4Lq3YpcKg1//fpPsCEXQoinpgYhe3pYSBcQZgAqgVIJYmHK ILR4nGkpm3ggcAUKCPKNiHOs3yoy2n37idII55lAYYic1vxaGNqL2bpY8hoAE5rtWDboPfGThxjE GfO351s2f8dNK5sQx4R7qszfHnzPaUjUPiU6o/WoAKAbmqLR149yxYEEZXrFxSV00ouDm0/eVhwV rscVByfvdC/kBfzupcrZQImse3GGhVS9IPfcoF4eFiv5YLGSp8XKq2Sxah3uw6TjlbyfTZU1G69e kzS8VSAzmf4hnHd0h3UrI8k8OINnkqx5neA9jZh8VBmqmHy/U526PR6VPSagJyUrn9ev1gVfZsvI E6KzYcHrSdCZ1+l+BUid6HiFmpkgj+KGTLZn0gg1A+60ZnuU1yiyuj3zCd+DPxzAcEJchb0pg67P chbLqbSM7Ja78qR5IqXYYe0cPNdD/gizv/prP0lACp3H3eiSDHjE5tpWbG4VQufdq6LunbtvK5d1 9Pivk/Pgl2KdXj37uE5eFOsUmsWCvC+T98WEuP6E4PEENS/NeklPVM86rSc9iMmVDa+EpT6E+6SH TFXqAxpw5H0OCx+Qr17NAH7Uu+MnLLqo7XpyitpCJcAFwMw2alvZXP68AJyJg/aKsOphe0U4QvhG 7BVhdcP2igB6wIyRKGzrkCEibEMWhrCRsc/o2GdsSJ0OGx+rTox9Jsc+U4Od02PVmbHP7GCrbqw6 P/bZpIUhlBiGL/8DHsR//OLQzhDIbGK+QD5KzBeI+iSnXCBnfivzZK/Aw0/XTxIABso/ycgXQIFL PC5mxOKRzY6BfZSYLzDxSbrBsIOGE0eiqPUn5EiUaCU4ryROsuVEiwEbCN6T4NsFYjh6dV5fPNd/ y98fIYeqqwcEKZvbGPL7ZmE+8DM7on/aKvlJDmKS/ymISf6nINLrAqJC6GVJqzhEg3yNZw+lp/Qy F9nNGMBV6k1zSg8/V9BrrxqxYjUyB52GHizwjBFEkF+AUEpirt7TEnGOdEBVmF5QtNcnnmkqAhDF PJuEQulBvVRjsBqOm3TrbdKt2KSQulDQChl43aSG9JqVBJs9d4Tv7Qhf7QiI0yyD2xF3U1gxsl5+ C3MP4GaN3+a/VFkXfa2rckgFs5R1QSym32GcnS22LZ3HZ09VlF2yAVTAe/D+3UpzGRh4NU95EvS6 cmDdSuoR2TKJWLBkh4XHK+GqpeT7IMPCMygrWAyt0+FJn6wN3sE63AW6twt0tQscZo/ralC7ooxN uESPxLr7dXB5QPcD6K2uzIk19LakBwhuTH5yduyzsejt4MbkJzcGvA+gfwr/jXbt3YOzlx2z7pu4 UHuhfHAHqAdwzgIpA38AuvByzoGd04TzOJ9WkeKdyef6NGSFgBEi1tfA9iL5W7UPAx2HLIbwGmMT gu3Nos1BNiEkNlUrXuzF57DejP7bsnTv6hwBDN9MhTjGAiyt21vGRocF4iUGUQXq23rJIfj1t99y AV014VKfZL9PtpBZYoEj09oa5+VCmoCxHGsom4B0CrFT8OJflvhL506xsglQ5l1s4g7NO8Ij/tX+ VI56TaYQJRsulVPVjd+pncac0T0gabnvzh3Djy9DYks80j7F0ogL4e7mCklH77TYHdfmtmzr1D0b C9BkxNZ/6p6N9XCExJomHUMGpYaSByqWc/szbPpMQvEy67VvzuaHLkYYywjCMH5X5iRbmoD3UkeJ BYZSksXv+LS/IxZylb8j/hD+jJ9tWw5OH05ANrYXjQqYl+L9dZL64M6nNvsbDuhlIxkxRX8Ddp+t GH+0PcUfYTtAL7oRYAm4CuDHoU97v0Icx1ImMYncmerzeasp4WMJCDlfwGd9dYSc74fnKEVvy044 up4kX7cJyKnRj1nIxXgBuFubZ3m9hdDHYrpu7c525YussNhYKBtrovtWem9MkEtjtt2YrRoTskBy Ls3ggvqcQMTpO5Azfuc+OCeSXs6J5H/GOxnL2w96AW69qheK/WnvZKzEzHgn4/fuxTu5Lbqrrq6C 5ptVhVdhZKgeTT/IIxaLqQ/yiMVi/oO0YNtiyAdpwWIx+UFasFjMfZAWbFvsNpcWLJbgI8b5+N2I YTt+Jsc+U2NvstVj1Zmxz+xgq26sOj/22Zxhe1vKLBV/+2fK13dYteEfR9Fz8VvMKhrcIyIOC7BR uF38VmT78NWE2rYPYzk/irqL3w6j57YF9NqDZpR0A3a9PKEIsQibAtzFAqqwiQxA53K5HYrLd457 cXvkTXZlI3gJX8RAManEXrQql5JK5BLlewD4VX1LsXOxUi/FgxAOenzffRDWRd83JUS+6XyJgyob FXVjYT905l8LY09tNlb6ZhKOn/B2u4c9GD5ISUfvABRMOpoXfF1Symyve6FIMOXN9jaK7em8lmyp DOzFWtolM6riWq6QbBD3wGLb5W5bYN1VVr5rbQXSi4SyGAGLprd1OZVxb0A6oWsx/sC9Afvl8ofT VcHtYPvk3/IPW1YI5P6CoU5wVQi2IgohFlOnATL+lWj048GntIeno1eCqVjMTSUX2VZQzqJ6oJZn 9SAJUNgMMKaCsO9fhH33t1wghbn3h3Po75RWcwvKGthyGbznJzEpKW255CDVPR74szClRTqwa2xn cnWd3CN4GawHExEkxDLHCkLjBscGWcSWvH5YjG21pLoymusBbp+ynprnLteVi5lrPQ758lg7RLXI G4+D5zSb88wuDyGWuADZQkI1W+kgKz9aX3Pru0OOQUB27wZYpW3eAMbmG2D3xq1Hyr3rTOS8bMtN 110Fv0yFSMLSsoO36dK2US6LLJblYOWZXQV50TtWyT5ZBdB5Et9vajrINgjpchUcWk/+Ky2lzXOH 1E0Xh4arFOVVmXbg9rYCBHH25dEs5Yqq2fy+tZNmnROgEVV5TIC9T4C9rzxQhJ79NQu2TR/bri+P XQEpJh/Belek3mX2S3dS/Mtkci7/SKXn68btWg98oY3G7/ad1cqycauwcfnYuKwbD8WT+wD9vry4 jrxKF2WMYXHWo6CQDzs4iY4rewBpfbZ9EvH0MHE7LBA3pE+sd1RVHI6VQ6EHeMk1CEwgyirU13kt MXt/H3x6H1LmjSqB6GlFDzvM8iwSMPfhvaXz8mD1lByRYWkyiYU8izckvggIxT/LKbxuNfiaMPSk Fbe/EiwWpnB42wY+kTEcXvyWjuLw4rdsFIcXvxWjOLz4rRrS3LehFNzxMzP22ZgOvQ2l4I6f+bHP JnXoreLb9F+//yPjwuCfhpXKbV0LDXFdmhoiaFLnLlpZEV1F2nhqcouuiuVsDjh5ptKoAk5isSMw YXtQ9bZT09u2FJjA+6a/rQQkpakD4Ey+ELcNaTS42Qe43cPAtmsKkVhsjkYjFpij0YgF7C7asa0r 2m1yaQ1twaH5j9YAdI6ZNdgjzqLcZh7W4LmjhCGVCXmlMjnXALSWqTWAGLWpNSD+hcpk28TWGBrf 8tDoctleTzQm59DAazU1NODpmRoa8MM+0pi8D80MORg3cKXNOBg3YP0ZcDBubP2IwSQWbF0JFK8E JqfYS2IBh+wl5JW95Fxkvn5EqBULtvrPsP/8LQgkfuJaNTiswc35ujaIsBvwdW1im4qtiAXY61iE bm3TbMjbxJi8IMbkBTEoL4gxeUGMyQtjPLJwz05Or0w6BdAp+qaY3jHf5+KyEErXpSmU1vIEqNwT SN5YwI+LsRDW+CxCXsQqVQe8/fj+D//L7+ic2FQJud/aBvWtEroVnUI2xwJicj6UqlHzLVD/r1dQ fyzmL6j5pYOaX6piGqP+nl0uqB3oS36utZOfa720Yz4J4t82s33ktdnMHO17FMaW13uoTDB4biYw 7rN8XixDBwh5dIDUEhnYGUAiow8SGS0ksiPL4ML7Yosjnc7mePpYi0t4tOUW0FFo0vV/puw1uPYA jlCPtFKrf7oGuEPHPghwj8XUmMwADD+zMIfNr7W5cfPkT4GSNo8hNl48hSXj9gNSnbj9ADlKpoN3 tw04cd4D5eN32wezE9RldoL5U1AUssyH68dCdbh+/EH/eSgKAeV6AopCwL0laDMV2nHyyLZ0Tl4m B4y10LfLhkTloF2LVFjLCJ1P/EyPfWbGPhuTj8jqxqrzY5+NyUdkW6aC2GOBJB9p2TNjPspHBKwE d0NfT7HNryEBN+GM9kcAEzqj/RGyvim2hPeeM5efM0JO24l7V25xeGTSdkKInh2efVNuh4bnhxRc AhDVGQWXjDHVxO/oZwouoaYzOGPy4KiZU3IJw7ND2buSi2NlKBFvXSX314aSS1hvDBbHwMzrPcl7 t63D25Yvc8ouAeftgLIbt9gFB7g8YGFRpiVc1zjAF/jgr7lYuOAAH+GDWRImghYq3Nb2K1Q6DgE3 74Chnoix92dMPydj+jkZ1M/JmH5OxvRzIibt+aQ0iP7yq/85q5xElionaaucpFoOQAKbAhCz0PtB pqndAiNC5KkB8ScNKGuqRC21Zrd0osnrs6LYRV3tBHnX+iBRSJemhvjp8qj2VJlF7DrpxK6Tujl9 iSlfOzHltVJNTg6eMe2YaF8Hk2+dYPJaCycZq5uDybdOMPlWd2/H6u54yWtyllrakfl7s0vMIlT3 wB1JfMQQ541hMPDfq6dmctgSsSuCgckTz98fJYSY2FdLILG6PlU7F3C+5u2sEGEtZisSD0FlcUO5 XCJRCspd36iTMqUMLxsz7NZFTBO+kR2wmuJaaS+udU8TntP5xCIS+af8I/8ULXHcBII6E8/PhVqw 4Pmh5fS7gCeSQawq0umc7VB2I/rZiOdzqi4B3dgoOBoPgslShMGRihSoPIkFKVAJTiDTpECxSPJk gwJOq9DNe9wmrfZEeMvKutFlu+0Jmb0sdNlymNuVWxgXat+FedvSBW9ceERkN/Wor5wRdLE5gZWS zYRiG9P347Vt+XzRdZvbUTS7lvcdxZfmjuI3iq9Yzk5uELqHCrpjg3jW3SBZKKLAojPH1RXL6LmN Trf3nUHuO8PgziCzO4OUO+MtIfS5MwjuDEo6O0M2brUl32qUIifbAWjvUYT98T/K+QEPZbwJG9Sn aBovqU9jAYOS0Muxxr0ESg0g90iV56gB3qusjZSJAryXf9NYFX2silZV8fVeFSgYqSq/PFXl64Xi plGVx17Jx17VtwG43a5ViVe3IhXutg9CdipS4Ypt8MToV28DkG+ntoHkeRu8Hl7cB/JVk6RquY1t XbMSSbN07IA4F/h97e0ys/yWLy2WE5OjA//Pscm3/u1XDU69BtlTTe6D27IngGYvEA6udVM3BgeJ IKYGpy0OTvYGJ+vBmdeYC2r4fXAYcEFNSobgtn4n9/xzZ4tyf38aiV2r/VU+QAYBAt4/icg4EXbS kUvt6chdZnM2x9KQKMG1hnRSh1S5amORA3nOuiY26ul93jM7UKwA8890XqPqOsB2gS1FriBjQ5mC q+lffvntp1rd3UkOw1L6FqjD+HKKF5ufS+kcC2wpN4ntRfJvNDRuCwQ8xZmZXF6f+Dmi+ufDNJlq LG5zHq3Q0wSjxFoNccyiTsNctu9YYJvUqijkTBDyG28wZGWtijdm2+Nsn4SeY1Z/ehB6urXKXjNq 9ac7VJceO7tkib9SxO87Wx7jZAu/3LI9ivj6lmUATY1y7ZMcKF3Z0Jooc0ifMoexxoSixZSBqA+h K2aIIj6fPQYOKRG+kS4f2Gu7JtusqDjcKU1m04qyf2NbwR0V/yJFJasEtVk7oNsrKol3vNCO+2zy KeoCKd9gXQhbIG8G+q/vhXGbNQT7FSV7RhAlxWtbzJUZse4b4cXItv70bPX0HJQb+a/DmrOCXTA+ GZu4MLiDfCHW0jTIKCoWQjRJH/b0qoeR72wYBPznp5tRf58nm0ME2FB++PjZ2F3GGFIZr+2cmKdw +kcugvgY558ucpwqxufuIsbSJIkNNJTmzV9eRfZv3v79Lz99//nvcCX9+P0rTxXwf3jTirPOT9az aYqBlwSMiQ4y9b7amfJ1zzi6sNTAK4/zyvFggfPricb7j4IfemMHUWQID8Lc98J4yXb3x4TVgkH6 v0nTABNHUuBkoJIt+4Mun3smX9FGzyo3k+yj1ZKqWK13TT0XU0uxWk9k3vViZd1neLGUmlwsZWcN fUyvk2ulX+3Sz4YzphNQJerOz2b3I5YY253UKZh531TPVwAke5+SItmZ9r3jM0J3UeHEYcZdHKDP ftPDucLsVjtAn/2m2dbHrKiJUF78piQXszURygvtSt6Rbq2JUF5oV1guxgsvLWl7aSu3IAOg24CX lg2RQMbP7NhnbuypdWMvt5v0q7KSQO2v/sf+CH5l5yrz46FSzK8feSCZl5MhVswfoVLiLetwyfkc i6H+rEY4n/GyhtxyE+E9LKT066wPJq2yyeOslxE+LAxlX4/fmTkoDQtDydc3vswn34mF6uQ78Qf1 p3CffAk5wfRzGqaa7o3v+tZ4GqZYgGIaJvKehgm7tx7cvNtIcLDDYqBfzQBoODAoDgBo+J59YHbR IOqtWjSy/Ck4Kv+Ex5BfeQw5CX8ejspB0ZqAo3KICgM4qvgTZ5e/q2m8VNPKSrjHSoYufD6oqnGG 5nZK6lsWb+f1bjzkjE7Gq3CIBRsMP+FsLIKZg6doaJDm7bv//f1Lf335f5if/u+3X8K3L29/fP/l 52//8f3n7z/+44f/48d/1g8k/Pftf8K/Qqj97z8dUcRTiRqnmPXf3Cpr3Z2dqwC2DJioKlBTQ3BH N8A6k8J9TbQCNHyzFzZ5kO//iub+9LGeCLoHrPLz8veWy//xtFxgyf35918bKza4CGA7Vq25jKo/ 9Mt++5+/2u9/+f3nf+hf//L1/ee/7gth/9d/+/8BpGtauqQhAgA= --Boundary-00=_/2iRBaeD8M2PAeQ-- From davem@davemloft.net Mon Sep 13 16:32:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:32:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNWJV0007760 for ; Mon, 13 Sep 2004 16:32:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C70Go-0004LL-00; Mon, 13 Sep 2004 16:30:02 -0700 Date: Mon, 13 Sep 2004 16:30:02 -0700 From: "David S. Miller" To: Julian Anastasov Cc: laforge@netfilter.org, netdev@oss.sgi.com, rusty@rustcorp.com.au Subject: Re: [PATCH 2.6] ip_nat_ftp - manip at the right place Message-Id: <20040913163002.35aae28c.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 609 Lines: 18 On Sat, 11 Sep 2004 10:53:53 +0300 (EEST) Julian Anastasov wrote: > This is a resend/resync for v2.6.9-rc1-bk17: change the > way the ip_nat_ftp helper manipulates the packets: > > - no manips => no fixup > > - check the direction, do manip once and at the same time when the > headers are changed > > This is needed mostly for IPVS setups and I hope we do not > create troubles for other setups or FTP software. I'm still waiting for ACK/NACK of this. I know Rusty is travelling and Harald is probably busy too, so I know the delay in response is not because these guys are slackers :-) From davem@davemloft.net Mon Sep 13 16:35:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:35:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNZk1e008517 for ; Mon, 13 Sep 2004 16:35:46 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C70KE-0004Lr-00; Mon, 13 Sep 2004 16:33:34 -0700 Date: Mon, 13 Sep 2004 16:33:33 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jolt@tuxbox.org, pp@ee.oulu.fi, jgarzik@pobox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Fix for b44 warnings. Message-Id: <20040913163333.2fadaf93.davem@davemloft.net> In-Reply-To: <20040913163001.7fa560c6@dell_ss3.pdx.osdl.net> References: <200408292218.00756.jolt@tuxbox.org> <20040913163001.7fa560c6@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 370 Lines: 11 On Mon, 13 Sep 2004 16:30:01 -0700 Stephen Hemminger wrote: > B44 driver was using unsigned long as an io memory address. > Recent changes caused this to be a warning. This patch fixes that > and makes the readl/writel wrapper into inline's instead of macros > with magic variable side effect (yuck). Jeff, I'll merge this one. Thanks Stephen. From tab@snarc.org Mon Sep 13 16:58:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 16:59:03 -0700 (PDT) Received: from darwin.snarc.org (darwin.snarc.org [81.56.210.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8DNwqrw009265 for ; Mon, 13 Sep 2004 16:58:54 -0700 Received: from tab by darwin.snarc.org with local (Exim 4.34) id 1C70iK-0001tc-J8; Tue, 14 Sep 2004 01:58:28 +0200 Date: Tue, 14 Sep 2004 01:58:28 +0200 To: Serge Hallyn Cc: Alan Cox , Chris Wright , Linux Kernel Mailing List , akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] BSD Jail LSM Message-ID: <20040913235828.GA7212@snarc.org> References: <1094847705.2188.94.camel@serge.austin.ibm.com> <1094847787.2188.101.camel@serge.austin.ibm.com> <1094844708.18107.5.camel@localhost.localdomain> <20040912233342.GA12097@escher.cs.wm.edu> <1095072996.14355.12.camel@localhost.localdomain> <1095117605.2350.11.camel@serge.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095117605.2350.11.camel@serge.austin.ibm.com> X-Warning: Email may contain unsmilyfied humor and/or satire. User-Agent: Mutt/1.5.6+20040818i From: Vincent Hanquez X-archive-position: 8758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tab@snarc.org Precedence: bulk X-list: netdev Content-Length: 1366 Lines: 35 On Mon, Sep 13, 2004 at 06:20:05PM -0500, Serge Hallyn wrote: > +#define in_use(x) (x->jail_flags & IN_USE) > +#define set_in_use(x) (x->jail_flags |= IN_USE) > + > +#define got_network(x) (x->jail_flags & (GOT_IPV4 | GOT_IPV6)) > +#define got_ipv4(x) (x->jail_flags & (GOT_IPV4)) > +#define got_ipv6(x) (x->jail_flags & (GOT_IPV6)) > +#define set_ipv4(x) (x->jail_flags |= GOT_IPV4) > +#define set_ipv6(x) (x->jail_flags |= GOT_IPV6) > +#define unset_got_ipv4(x) (x->jail_flags &= ~GOT_IPV4) > +#define unset_got_ipv6(x) (x->jail_flags &= ~GOT_IPV6) > + > +#define get_task_security(task) (task->security) > +#define get_inode_security(inode) (inode->i_security) > +#define get_sock_security(sock) (sock->sk_security) > +#define get_file_security(file) (file->f_security) > +#define get_ipc_security(ipc) (ipc->security) > + > +#define jail_of(proc) (get_task_security(proc)) > + > +#define set_task_security(task,data) task->security = data > +#define set_inode_security(inode,data) inode->i_security = data > +#define set_sock_security(sock,data) sock->sk_security = data > +#define set_file_security(file,data) file->f_security = data > +#define set_ipc_security(ipc,data) ipc.security = data Hi Serge, Do you really need all thoses macros ? It seems to me that's too much macros for stuff which are easy to write and to understand. Just my 2cents, -- Tab From jmorris@redhat.com Mon Sep 13 17:25:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 17:26:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E0PvAp010223 for ; Mon, 13 Sep 2004 17:25:57 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8E0PdYJ004407; Mon, 13 Sep 2004 20:25:39 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8E0Pdr26039; Mon, 13 Sep 2004 20:25:39 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8E0PdiS014598; Mon, 13 Sep 2004 20:25:39 -0400 Date: Mon, 13 Sep 2004 20:25:38 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Andrew Morton cc: linux-kernel@vger.kernel.org, , "David S. Miller" Subject: Re: 2.6.9-rc1-mm5: TCP oopses In-Reply-To: <20040913015003.5406abae.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279723856-1301949747-1095121538=:22477" X-archive-position: 8759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 41788 Lines: 750 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. --279723856-1301949747-1095121538=:22477 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm experiencing TCP related oopses with this kernel (not seen in -mm4), .config file attached. Here are two backtraces, the first happened a few seconds after logging in via ssh, the second happened soon after boot (using selinux=0, just to make sure). Oops #1: ----------- KERNEL: assertion (!skb_queue_empty(&sk->sk_write_queue)) failed at net/ipv4/tcp_timer.c (322) Unable to handle kernel NULL pointer dereference at virtual address 00000048 printing eip: c03022c2 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ipv6 e1000 3c59x ac CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.9-rc1-mm5) EIP is at tcp_retransmit_skb+0x89/0x340 eax: 00000000 ebx: 00000000 ecx: f7718960 edx: 00000000 esi: f740c2a0 edi: f740c0a8 ebp: c0460f64 esp: c0460f48 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0460000 task=c039dac0) Stack: f740c0a8 00000000 0000056e f740c2a0 f740c0a8 f740c2a0 f740c10c c0460fa0 c03044b2 c0387ed4 c038901c c038615b 00000142 c0460fb8 f888bb2f f709a778 f70791c0 c181110c 00000001 f740c0a8 f740c2a0 f740c0c8 c0460fb8 c03048af Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x152/0x1ca [] die+0x100/0x186 [] do_page_fault+0x2dc/0x5d0 [] error_code+0x2d/0x38 [] tcp_retransmit_timer+0xe9/0x434 [] tcp_write_timer+0xb2/0xcd [] run_timer_softirq+0xbf/0x17f [] __do_softirq+0x64/0xd2 [] do_softirq+0x47/0x4f [] smp_apic_timer_interrupt+0xf2/0xf4 [] apic_timer_interrupt+0x1a/0x20 [] cpu_idle+0x38/0x5a [] start_kernel+0x196/0x1d5 [] 0xc0100211 ======================= [] show_stack+0x7a/0x90 [] show_registers+0x152/0x1ca [] die+0x100/0x186 [] do_page_fault+0x2dc/0x5d0 [] error_code+0x2d/0x38 [] tcp_retransmit_timer+0xe9/0x434 [] tcp_write_timer+0xb2/0xcd [] run_timer_softirq+0xbf/0x17f [] __do_softirq+0x64/0xd2 [] do_softirq+0x47/0x4f [] smp_apic_timer_interrupt+0xf2/0xf4 [] apic_timer_interrupt+0x1a/0x20 [] cpu_idle+0x38/0x5a [] start_kernel+0x196/0x1d5 [] 0xc0100211 Code: 89 45 ec 8b 47 78 be f5 ff ff ff 89 c2 c1 fa 02 01 d0 8b 97 84 00 00 00 39 c2 0f 4f d0 8b 47 60 39 d0 0f 8f b3 01 00 00 8b 75 f0 <8b> 53 48 8b 4e 10 39 ca 79 5c 39 4b 4c 79 08 0f 0b c3 03 14 61 <0>Kernel panic - not syncing: Fatal exception in interrupt Oops #2: ----------- gdb) l *0xc02fac2c 0xc02fac2c is in tcp_time_to_recover (net/ipv4/tcp_input.c:1352). 1350 static inline int tcp_skb_timedout(struct tcp_opt *tp, struct sk_buff *skb) 1351 { 1352 return (tcp_time_stamp - TCP_SKB_CB(skb)->when > tp->rto); 1353 } 1354 Unable to handle kernel NULL pointer dereference at virtual address 00000050 printing eip: c02fac2c *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ipv6 e1000 3c59x ac CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.9-rc1-mm5) EIP is at tcp_time_to_recover+0x1d0/0x214 eax: fffcc289 ebx: f77a6320 ecx: 00000002 edx: 00000000 esi: 00000003 edi: f77a6128 ebp: c0460ddc esp: c0460dc4 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0460000 task=c039dac0) Stack: 00000246 fffcc3b1 00000001 f77a6320 00000000 49a2fa4f c0460e20 c02fb752 c0460e20 c02fc1b1 00000000 00010800 49a2fa4f 037a6320 00000001 00000000 00000106 00000004 49a2f4d3 f77a6128 00000003 f77a6320 49a2fa4f c0460e60 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x152/0x1ca [] die+0x100/0x186 [] do_page_fault+0x2dc/0x5d0 [] error_code+0x2d/0x38 [] tcp_fastretrans_alert+0x146/0x6ed [] tcp_ack+0x260/0x5df [] tcp_rcv_established+0x5d0/0x868 [] tcp_v4_do_rcv+0x101/0x103 [] tcp_v4_rcv+0x80c/0x920 [] ip_local_deliver+0xa0/0x26d [] ip_rcv+0x381/0x4f9 [] netif_receive_skb+0x1f7/0x224 [] process_backlog+0x85/0x135 [] net_rx_action+0x86/0x136 [] __do_softirq+0x64/0xd2 [] do_softirq+0x47/0x4f [] do_IRQ+0x185/0x1cf [] common_interrupt+0x18/0x20 [] cpu_idle+0x38/0x5a [] start_kernel+0x196/0x1d5 [] 0xc0100211 ======================= [] show_stack+0x7a/0x90 [] show_registers+0x152/0x1ca [] die+0x100/0x186 [] do_page_fault+0x2dc/0x5d0 [] error_code+0x2d/0x38 [] tcp_fastretrans_alert+0x146/0x6ed [] tcp_ack+0x260/0x5df [] tcp_rcv_established+0x5d0/0x868 [] tcp_v4_do_rcv+0x101/0x103 [] tcp_v4_rcv+0x80c/0x920 [] ip_local_deliver+0xa0/0x26d [] ip_rcv+0x381/0x4f9 [] netif_receive_skb+0x1f7/0x224 [] process_backlog+0x85/0x135 [] net_rx_action+0x86/0x136 [] __do_softirq+0x64/0xd2 [] do_softirq+0x47/0x4f [] do_IRQ+0x185/0x1cf [] common_interrupt+0x18/0x20 [] cpu_idle+0x38/0x5a [] start_kernel+0x196/0x1d5 [] 0xc0100211 Code: 83 c4 0c 5b 5e 5f 5d c3 8b 92 7c 01 00 00 83 c2 01 e9 7a fe ff ff 8d 47 64 8b 57 64 39 c2 b8 00 00 00 00 0f 44 d0 a1 a0 f5 39 c0 <2b> 42 50 3b 83 94 00 00 00 77 c7 e9 7b fe ff ff c7 45 f0 00 00 <0>Kernel panic - not syncing: Fatal exception in interrupt -- James Morris --279723856-1301949747-1095121538=:22477 Content-Type: TEXT/plain; name="config.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="config.txt" Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9u J3QgZWRpdA0KIyBMaW51eCBrZXJuZWwgdmVyc2lvbjogMi42LjktcmMxLW1t NQ0KIyBNb24gU2VwIDEzIDE5OjUwOjU5IDIwMDQNCiMNCkNPTkZJR19YODY9 eQ0KQ09ORklHX01NVT15DQpDT05GSUdfVUlEMTY9eQ0KQ09ORklHX0dFTkVS SUNfSVNBX0RNQT15DQoNCiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRp b25zDQojDQpDT05GSUdfRVhQRVJJTUVOVEFMPXkNCkNPTkZJR19DTEVBTl9D T01QSUxFPXkNCg0KIw0KIyBHZW5lcmFsIHNldHVwDQojDQpDT05GSUdfTE9D QUxWRVJTSU9OPSIiDQpDT05GSUdfU1dBUD15DQpDT05GSUdfU1lTVklQQz15 DQojIENPTkZJR19QT1NJWF9NUVVFVUUgaXMgbm90IHNldA0KIyBDT05GSUdf QlNEX1BST0NFU1NfQUNDVCBpcyBub3Qgc2V0DQpDT05GSUdfU1lTQ1RMPXkN CkNPTkZJR19BVURJVD15DQpDT05GSUdfQVVESVRTWVNDQUxMPXkNCkNPTkZJ R19MT0dfQlVGX1NISUZUPTE1DQpDT05GSUdfSE9UUExVRz15DQpDT05GSUdf S09CSkVDVF9VRVZFTlQ9eQ0KIyBDT05GSUdfSUtDT05GSUcgaXMgbm90IHNl dA0KIyBDT05GSUdfRU1CRURERUQgaXMgbm90IHNldA0KQ09ORklHX0tBTExT WU1TPXkNCiMgQ09ORklHX0tBTExTWU1TX0FMTCBpcyBub3Qgc2V0DQojIENP TkZJR19LQUxMU1lNU19FWFRSQV9QQVNTIGlzIG5vdCBzZXQNCkNPTkZJR19G VVRFWD15DQpDT05GSUdfRVBPTEw9eQ0KIyBDT05GSUdfQ1BVU0VUUyBpcyBu b3Qgc2V0DQpDT05GSUdfSU9TQ0hFRF9OT09QPXkNCkNPTkZJR19JT1NDSEVE X0FTPXkNCkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkNCkNPTkZJR19JT1ND SEVEX0NGUT15DQojIENPTkZJR19DQ19PUFRJTUlaRV9GT1JfU0laRSBpcyBu b3Qgc2V0DQpDT05GSUdfU0hNRU09eQ0KIyBDT05GSUdfVElOWV9TSE1FTSBp cyBub3Qgc2V0DQoNCiMNCiMgTG9hZGFibGUgbW9kdWxlIHN1cHBvcnQNCiMN CkNPTkZJR19NT0RVTEVTPXkNCkNPTkZJR19NT0RVTEVfVU5MT0FEPXkNCkNP TkZJR19NT0RVTEVfRk9SQ0VfVU5MT0FEPXkNCkNPTkZJR19PQlNPTEVURV9N T0RQQVJNPXkNCiMgQ09ORklHX01PRFZFUlNJT05TIGlzIG5vdCBzZXQNCkNP TkZJR19LTU9EPXkNCkNPTkZJR19TVE9QX01BQ0hJTkU9eQ0KDQojDQojIFBy b2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcw0KIw0KQ09ORklHX1g4Nl9QQz15 DQojIENPTkZJR19YODZfRUxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZf Vk9ZQUdFUiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfTlVNQVEgaXMgbm90 IHNldA0KIyBDT05GSUdfWDg2X1NVTU1JVCBpcyBub3Qgc2V0DQojIENPTkZJ R19YODZfQklHU01QIGlzIG5vdCBzZXQNCiMgQ09ORklHX1g4Nl9WSVNXUyBp cyBub3Qgc2V0DQojIENPTkZJR19YODZfR0VORVJJQ0FSQ0ggaXMgbm90IHNl dA0KIyBDT05GSUdfWDg2X0VTNzAwMCBpcyBub3Qgc2V0DQojIENPTkZJR19N Mzg2IGlzIG5vdCBzZXQNCiMgQ09ORklHX000ODYgaXMgbm90IHNldA0KIyBD T05GSUdfTTU4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2VFNDIGlzIG5v dCBzZXQNCiMgQ09ORklHX001ODZNTVggaXMgbm90IHNldA0KIyBDT05GSUdf TTY4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NUEVOVElVTUlJIGlzIG5vdCBz ZXQNCiMgQ09ORklHX01QRU5USVVNSUlJIGlzIG5vdCBzZXQNCiMgQ09ORklH X01QRU5USVVNTSBpcyBub3Qgc2V0DQpDT05GSUdfTVBFTlRJVU00PXkNCiMg Q09ORklHX01LNiBpcyBub3Qgc2V0DQojIENPTkZJR19NSzcgaXMgbm90IHNl dA0KIyBDT05GSUdfTUs4IGlzIG5vdCBzZXQNCiMgQ09ORklHX01DUlVTT0Ug aXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVBDNiBpcyBub3Qgc2V0DQoj IENPTkZJR19NV0lOQ0hJUDIgaXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNI SVAzRCBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1lSSVhJSUkgaXMgbm90IHNl dA0KIyBDT05GSUdfTVZJQUMzXzIgaXMgbm90IHNldA0KQ09ORklHX1g4Nl9H RU5FUklDPXkNCkNPTkZJR19YODZfQ01QWENIRz15DQpDT05GSUdfWDg2X1hB REQ9eQ0KQ09ORklHX1g4Nl9MMV9DQUNIRV9TSElGVD03DQpDT05GSUdfUldT RU1fWENIR0FERF9BTEdPUklUSE09eQ0KQ09ORklHX1g4Nl9XUF9XT1JLU19P Sz15DQpDT05GSUdfWDg2X0lOVkxQRz15DQpDT05GSUdfWDg2X0JTV0FQPXkN CkNPTkZJR19YODZfUE9QQURfT0s9eQ0KQ09ORklHX1g4Nl9HT09EX0FQSUM9 eQ0KQ09ORklHX1g4Nl9JTlRFTF9VU0VSQ09QWT15DQpDT05GSUdfWDg2X1VT RV9QUFJPX0NIRUNLU1VNPXkNCkNPTkZJR19IUEVUX1RJTUVSPXkNCkNPTkZJ R19IUEVUX0VNVUxBVEVfUlRDPXkNCkNPTkZJR19TTVA9eQ0KQ09ORklHX05S X0NQVVM9OA0KQ09ORklHX1NDSEVEX1NNVD15DQpDT05GSUdfUFJFRU1QVD15 DQpDT05GSUdfWDg2X0xPQ0FMX0FQSUM9eQ0KQ09ORklHX1g4Nl9JT19BUElD PXkNCkNPTkZJR19YODZfVFNDPXkNCkNPTkZJR19YODZfTUNFPXkNCkNPTkZJ R19YODZfTUNFX05PTkZBVEFMPXkNCkNPTkZJR19YODZfTUNFX1A0VEhFUk1B TD15DQojIENPTkZJR19UT1NISUJBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0k4 SyBpcyBub3Qgc2V0DQojIENPTkZJR19NSUNST0NPREUgaXMgbm90IHNldA0K IyBDT05GSUdfWDg2X01TUiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfQ1BV SUQgaXMgbm90IHNldA0KDQojDQojIEZpcm13YXJlIERyaXZlcnMNCiMNCiMg Q09ORklHX0VERCBpcyBub3Qgc2V0DQojIENPTkZJR19OT0hJR0hNRU0gaXMg bm90IHNldA0KQ09ORklHX0hJR0hNRU00Rz15DQojIENPTkZJR19ISUdITUVN NjRHIGlzIG5vdCBzZXQNCkNPTkZJR19ISUdITUVNPXkNCiMgQ09ORklHX0hJ R0hQVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTUFUSF9FTVVMQVRJT04gaXMg bm90IHNldA0KQ09ORklHX01UUlI9eQ0KIyBDT05GSUdfRUZJIGlzIG5vdCBz ZXQNCkNPTkZJR19JUlFCQUxBTkNFPXkNCkNPTkZJR19IQVZFX0RFQ19MT0NL PXkNCkNPTkZJR19SRUdQQVJNPXkNCg0KIw0KIyBQZXJmb3JtYW5jZS1tb25p dG9yaW5nIGNvdW50ZXJzIHN1cHBvcnQNCiMNCiMgQ09ORklHX1BFUkZDVFIg aXMgbm90IHNldA0KIyBDT05GSUdfS0VYRUMgaXMgbm90IHNldA0KDQojDQoj IFBvd2VyIG1hbmFnZW1lbnQgb3B0aW9ucyAoQUNQSSwgQVBNKQ0KIw0KIyBD T05GSUdfUE0gaXMgbm90IHNldA0KIyBDT05GSUdfUE1fREVCVUcgaXMgbm90 IHNldA0KDQojDQojIEFDUEkgKEFkdmFuY2VkIENvbmZpZ3VyYXRpb24gYW5k IFBvd2VyIEludGVyZmFjZSkgU3VwcG9ydA0KIw0KQ09ORklHX0FDUEk9eQ0K Q09ORklHX0FDUElfQk9PVD15DQpDT05GSUdfQUNQSV9JTlRFUlBSRVRFUj15 DQpDT05GSUdfQUNQSV9BQz1tDQojIENPTkZJR19BQ1BJX0JBVFRFUlkgaXMg bm90IHNldA0KIyBDT05GSUdfQUNQSV9CVVRUT04gaXMgbm90IHNldA0KIyBD T05GSUdfQUNQSV9GQU4gaXMgbm90IHNldA0KIyBDT05GSUdfQUNQSV9QUk9D RVNTT1IgaXMgbm90IHNldA0KIyBDT05GSUdfQUNQSV9BU1VTIGlzIG5vdCBz ZXQNCkNPTkZJR19BQ1BJX1RISU5LUEFEPW0NCiMgQ09ORklHX0FDUElfVE9T SElCQSBpcyBub3Qgc2V0DQpDT05GSUdfQUNQSV9CTEFDS0xJU1RfWUVBUj0w DQojIENPTkZJR19BQ1BJX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19BQ1BJ X0JVUz15DQpDT05GSUdfQUNQSV9FQz15DQpDT05GSUdfQUNQSV9QT1dFUj15 DQpDT05GSUdfQUNQSV9QQ0k9eQ0KQ09ORklHX0FDUElfU1lTVEVNPXkNCiMg Q09ORklHX1g4Nl9QTV9USU1FUiBpcyBub3Qgc2V0DQoNCiMNCiMgQ1BVIEZy ZXF1ZW5jeSBzY2FsaW5nDQojDQojIENPTkZJR19DUFVfRlJFUSBpcyBub3Qg c2V0DQoNCiMNCiMgQnVzIG9wdGlvbnMgKFBDSSwgUENNQ0lBLCBFSVNBLCBN Q0EsIElTQSkNCiMNCkNPTkZJR19QQ0k9eQ0KIyBDT05GSUdfUENJX0dPQklP UyBpcyBub3Qgc2V0DQojIENPTkZJR19QQ0lfR09NTUNPTkZJRyBpcyBub3Qg c2V0DQojIENPTkZJR19QQ0lfR09ESVJFQ1QgaXMgbm90IHNldA0KQ09ORklH X1BDSV9HT0FOWT15DQpDT05GSUdfUENJX0JJT1M9eQ0KQ09ORklHX1BDSV9E SVJFQ1Q9eQ0KQ09ORklHX1BDSV9NTUNPTkZJRz15DQojIENPTkZJR19QQ0lf TVNJIGlzIG5vdCBzZXQNCkNPTkZJR19QQ0lfTEVHQUNZX1BST0M9eQ0KQ09O RklHX1BDSV9OQU1FUz15DQojIENPTkZJR19JU0EgaXMgbm90IHNldA0KIyBD T05GSUdfTUNBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDeDIwMCBpcyBub3Qg c2V0DQojIENPTkZJR19IT1RQTFVHX0NQVSBpcyBub3Qgc2V0DQoNCiMNCiMg UENNQ0lBL0NhcmRCdXMgc3VwcG9ydA0KIw0KIyBDT05GSUdfUENNQ0lBIGlz IG5vdCBzZXQNCg0KIw0KIyBQQ0kgSG90cGx1ZyBTdXBwb3J0DQojDQpDT05G SUdfSE9UUExVR19QQ0k9eQ0KIyBDT05GSUdfSE9UUExVR19QQ0lfRkFLRSBp cyBub3Qgc2V0DQojIENPTkZJR19IT1RQTFVHX1BDSV9DT01QQVEgaXMgbm90 IHNldA0KIyBDT05GSUdfSE9UUExVR19QQ0lfSUJNIGlzIG5vdCBzZXQNCiMg Q09ORklHX0hPVFBMVUdfUENJX0FDUEkgaXMgbm90IHNldA0KIyBDT05GSUdf SE9UUExVR19QQ0lfQ1BDSSBpcyBub3Qgc2V0DQojIENPTkZJR19IT1RQTFVH X1BDSV9QQ0lFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUdfUENJX1NI UEMgaXMgbm90IHNldA0KDQojDQojIEV4ZWN1dGFibGUgZmlsZSBmb3JtYXRz DQojDQpDT05GSUdfQklORk1UX0VMRj15DQojIENPTkZJR19CSU5GTVRfQU9V VCBpcyBub3Qgc2V0DQpDT05GSUdfQklORk1UX01JU0M9bQ0KDQojDQojIERl dmljZSBEcml2ZXJzDQojDQoNCiMNCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9u cw0KIw0KQ09ORklHX1NUQU5EQUxPTkU9eQ0KQ09ORklHX1BSRVZFTlRfRklS TVdBUkVfQlVJTEQ9eQ0KIyBDT05GSUdfRldfTE9BREVSIGlzIG5vdCBzZXQN CiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBub3Qgc2V0DQoNCiMNCiMgTWVt b3J5IFRlY2hub2xvZ3kgRGV2aWNlcyAoTVREKQ0KIw0KIyBDT05GSUdfTVRE IGlzIG5vdCBzZXQNCg0KIw0KIyBQYXJhbGxlbCBwb3J0IHN1cHBvcnQNCiMN CiMgQ09ORklHX1BBUlBPUlQgaXMgbm90IHNldA0KDQojDQojIFBsdWcgYW5k IFBsYXkgc3VwcG9ydA0KIw0KDQojDQojIEJsb2NrIGRldmljZXMNCiMNCkNP TkZJR19CTEtfREVWX0ZEPXkNCiMgQ09ORklHX0JMS19DUFFfREEgaXMgbm90 IHNldA0KIyBDT05GSUdfQkxLX0NQUV9DSVNTX0RBIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfVU1FTSBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9MT09QPXkN CiMgQ09ORklHX0JMS19ERVZfQ1JZUFRPTE9PUCBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX05CRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X1NYOCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9SQU09eQ0KQ09ORklH X0JMS19ERVZfUkFNX1NJWkU9ODE5Mg0KQ09ORklHX0JMS19ERVZfSU5JVFJE PXkNCiMgQ09ORklHX0xCRCBpcyBub3Qgc2V0DQojIENPTkZJR19DRFJPTV9Q S1RDRFZEIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvQVRBUEkvTUZNL1JMTCBz dXBwb3J0DQojDQpDT05GSUdfSURFPXkNCkNPTkZJR19CTEtfREVWX0lERT15 DQoNCiMNCiMgUGxlYXNlIHNlZSBEb2N1bWVudGF0aW9uL2lkZS50eHQgZm9y IGhlbHAvaW5mbyBvbiBJREUgZHJpdmVzDQojDQojIENPTkZJR19CTEtfREVW X0lERV9TQVRBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSERfSURF IGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURJU0s9eQ0KQ09ORklH X0lERURJU0tfTVVMVElfTU9ERT15DQpDT05GSUdfQkxLX0RFVl9JREVDRD15 DQojIENPTkZJR19CTEtfREVWX0lERVRBUEUgaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9JREVGTE9QUFkgaXMgbm90IHNldA0KQ09ORklHX0JMS19E RVZfSURFU0NTST15DQojIENPTkZJR19JREVfVEFTS19JT0NUTCBpcyBub3Qg c2V0DQpDT05GSUdfSURFX1RBU0tGSUxFX0lPPXkNCg0KIw0KIyBJREUgY2hp cHNldCBzdXBwb3J0L2J1Z2ZpeGVzDQojDQpDT05GSUdfSURFX0dFTkVSSUM9 eQ0KQ09ORklHX0JMS19ERVZfQ01ENjQwPXkNCiMgQ09ORklHX0JMS19ERVZf Q01ENjQwX0VOSEFOQ0VEIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lE RVBDST15DQpDT05GSUdfSURFUENJX1NIQVJFX0lSUT15DQojIENPTkZJR19C TEtfREVWX09GRkJPQVJEIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0dF TkVSSUM9eQ0KIyBDT05GSUdfQkxLX0RFVl9PUFRJNjIxIGlzIG5vdCBzZXQN CiMgQ09ORklHX0JMS19ERVZfUloxMDAwIGlzIG5vdCBzZXQNCkNPTkZJR19C TEtfREVWX0lERURNQV9QQ0k9eQ0KIyBDT05GSUdfQkxLX0RFVl9JREVETUFf Rk9SQ0VEIGlzIG5vdCBzZXQNCkNPTkZJR19JREVETUFfUENJX0FVVE89eQ0K IyBDT05GSUdfSURFRE1BX09OTFlESVNLIGlzIG5vdCBzZXQNCkNPTkZJR19C TEtfREVWX0FETUE9eQ0KIyBDT05GSUdfQkxLX0RFVl9BRUM2MlhYIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQUxJMTVYMyBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0FNRDc0WFggaXMgbm90IHNldA0KIyBDT05GSUdf QkxLX0RFVl9BVElJWFAgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9D TUQ2NFggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9UUklGTEVYIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ1k4MkM2OTMgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9DUzU1MjAgaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9DUzU1MzAgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF Vl9IUFQzNFggaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9IUFQzNjYg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9TQzEyMDAgaXMgbm90IHNl dA0KQ09ORklHX0JMS19ERVZfUElJWD15DQojIENPTkZJR19CTEtfREVWX0lU ODIxMiBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX05TODc0MTUgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9QREMyMDJYWF9PTEQgaXMgbm90 IHNldA0KIyBDT05GSUdfQkxLX0RFVl9QREMyMDJYWF9ORVcgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9TVldLUyBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX1NJSU1BR0UgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF Vl9TSVM1NTEzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0xDOTBF NjYgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9UUk0yOTAgaXMgbm90 IHNldA0KIyBDT05GSUdfQkxLX0RFVl9WSUE4MkNYWFggaXMgbm90IHNldA0K IyBDT05GSUdfSURFX0FSTSBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9J REVETUE9eQ0KIyBDT05GSUdfSURFRE1BX0lWQiBpcyBub3Qgc2V0DQpDT05G SUdfSURFRE1BX0FVVE89eQ0KIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qg c2V0DQoNCiMNCiMgU0NTSSBkZXZpY2Ugc3VwcG9ydA0KIw0KQ09ORklHX1ND U0k9eQ0KQ09ORklHX1NDU0lfUFJPQ19GUz15DQoNCiMNCiMgU0NTSSBzdXBw b3J0IHR5cGUgKGRpc2ssIHRhcGUsIENELVJPTSkNCiMNCkNPTkZJR19CTEtf REVWX1NEPXkNCiMgQ09ORklHX0NIUl9ERVZfU1QgaXMgbm90IHNldA0KIyBD T05GSUdfQ0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVW X1NSPXkNCkNPTkZJR19CTEtfREVWX1NSX1ZFTkRPUj15DQpDT05GSUdfQ0hS X0RFVl9TRz15DQoNCiMNCiMgU29tZSBTQ1NJIGRldmljZXMgKGUuZy4gQ0Qg anVrZWJveCkgc3VwcG9ydCBtdWx0aXBsZSBMVU5zDQojDQojIENPTkZJR19T Q1NJX01VTFRJX0xVTiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0NPTlNU QU5UUyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0xPR0dJTkcgaXMgbm90 IHNldA0KDQojDQojIFNDU0kgVHJhbnNwb3J0IEF0dHJpYnV0ZXMNCiMNCiMg Q09ORklHX1NDU0lfU1BJX0FUVFJTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ND U0lfRkNfQVRUUlMgaXMgbm90IHNldA0KDQojDQojIFNDU0kgbG93LWxldmVs IGRyaXZlcnMNCiMNCiMgQ09ORklHX0JMS19ERVZfM1dfWFhYWF9SQUlEIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfM1dfOVhYWCBpcyBub3Qgc2V0DQoj IENPTkZJR19TQ1NJX0FDQVJEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf QUFDUkFJRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMg bm90IHNldA0KIyBDT05GSUdfU0NTSV9BSUM3WFhYX09MRCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX0FJQzc5WFggaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9EUFRfSTJPIGlzIG5vdCBzZXQNCiMgQ09ORklHX01FR0FSQUlEX05F V0dFTiBpcyBub3Qgc2V0DQojIENPTkZJR19NRUdBUkFJRF9MRUdBQ1kgaXMg bm90IHNldA0KIyBDT05GSUdfU0NTSV9TQVRBIGlzIG5vdCBzZXQNCiMgQ09O RklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9E TVgzMTkxRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEEgaXMgbm90 IHNldA0KIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9HRFRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSVBTIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfSU5JQTEwMCBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX1NZTTUzQzhYWF8yIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ND U0lfSVBSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lDX0lTUCBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ19GQyBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgwIGlzIG5vdCBzZXQNCkNPTkZJ R19TQ1NJX1FMQTJYWFg9eQ0KIyBDT05GSUdfU0NTSV9RTEEyMVhYIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NDU0lfUUxBMjJYWCBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX1FMQTIzMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9R TEEyMzIyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxBNjMxMiBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMQTYzMjIgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9EQzM5NXggaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9E QzM5MFQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9OU1AzMiBpcyBub3Qg c2V0DQojIENPTkZJR19TQ1NJX0RFQlVHIGlzIG5vdCBzZXQNCg0KIw0KIyBN dWx0aS1kZXZpY2Ugc3VwcG9ydCAoUkFJRCBhbmQgTFZNKQ0KIw0KIyBDT05G SUdfTUQgaXMgbm90IHNldA0KDQojDQojIEZ1c2lvbiBNUFQgZGV2aWNlIHN1 cHBvcnQNCiMNCiMgQ09ORklHX0ZVU0lPTiBpcyBub3Qgc2V0DQoNCiMNCiMg SUVFRSAxMzk0IChGaXJlV2lyZSkgc3VwcG9ydA0KIw0KIyBDT05GSUdfSUVF RTEzOTQgaXMgbm90IHNldA0KDQojDQojIEkyTyBkZXZpY2Ugc3VwcG9ydA0K Iw0KIyBDT05GSUdfSTJPIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3b3JraW5n IHN1cHBvcnQNCiMNCkNPTkZJR19ORVQ9eQ0KDQojDQojIE5ldHdvcmtpbmcg b3B0aW9ucw0KIw0KQ09ORklHX1BBQ0tFVD15DQpDT05GSUdfUEFDS0VUX01N QVA9eQ0KIyBDT05GSUdfTkVUTElOS19ERVYgaXMgbm90IHNldA0KQ09ORklH X1VOSVg9eQ0KQ09ORklHX05FVF9LRVk9eQ0KQ09ORklHX0lORVQ9eQ0KQ09O RklHX0lQX01VTFRJQ0FTVD15DQpDT05GSUdfSVBfQURWQU5DRURfUk9VVEVS PXkNCkNPTkZJR19JUF9NVUxUSVBMRV9UQUJMRVM9eQ0KQ09ORklHX0lQX1JP VVRFX0ZXTUFSSz15DQpDT05GSUdfSVBfUk9VVEVfTVVMVElQQVRIPXkNCkNP TkZJR19JUF9ST1VURV9UT1M9eQ0KQ09ORklHX0lQX1JPVVRFX1ZFUkJPU0U9 eQ0KIyBDT05GSUdfSVBfUE5QIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfSVBJ UD1tDQpDT05GSUdfTkVUX0lQR1JFPXkNCkNPTkZJR19ORVRfSVBHUkVfQlJP QURDQVNUPXkNCkNPTkZJR19JUF9NUk9VVEU9eQ0KQ09ORklHX0lQX1BJTVNN X1YxPXkNCkNPTkZJR19JUF9QSU1TTV9WMj15DQojIENPTkZJR19BUlBEIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NZTl9DT09LSUVTIGlzIG5vdCBzZXQNCkNP TkZJR19JTkVUX0FIPW0NCkNPTkZJR19JTkVUX0VTUD1tDQpDT05GSUdfSU5F VF9JUENPTVA9bQ0KQ09ORklHX0lORVRfVFVOTkVMPW0NCg0KIw0KIyBJUDog VmlydHVhbCBTZXJ2ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklHX0lQX1ZT PW0NCiMgQ09ORklHX0lQX1ZTX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19J UF9WU19UQUJfQklUUz0xMg0KDQojDQojIElQVlMgdHJhbnNwb3J0IHByb3Rv Y29sIGxvYWQgYmFsYW5jaW5nIHN1cHBvcnQNCiMNCkNPTkZJR19JUF9WU19Q Uk9UT19UQ1A9eQ0KQ09ORklHX0lQX1ZTX1BST1RPX1VEUD15DQpDT05GSUdf SVBfVlNfUFJPVE9fRVNQPXkNCkNPTkZJR19JUF9WU19QUk9UT19BSD15DQoN CiMNCiMgSVBWUyBzY2hlZHVsZXINCiMNCkNPTkZJR19JUF9WU19SUj1tDQpD T05GSUdfSVBfVlNfV1JSPW0NCkNPTkZJR19JUF9WU19MQz1tDQpDT05GSUdf SVBfVlNfV0xDPW0NCkNPTkZJR19JUF9WU19MQkxDPW0NCkNPTkZJR19JUF9W U19MQkxDUj1tDQpDT05GSUdfSVBfVlNfREg9bQ0KQ09ORklHX0lQX1ZTX1NI PW0NCkNPTkZJR19JUF9WU19TRUQ9bQ0KQ09ORklHX0lQX1ZTX05RPW0NCg0K Iw0KIyBJUFZTIGFwcGxpY2F0aW9uIGhlbHBlcg0KIw0KQ09ORklHX0lQX1ZT X0ZUUD1tDQpDT05GSUdfSVBWNj1tDQojIENPTkZJR19JUFY2X1BSSVZBQ1kg aXMgbm90IHNldA0KQ09ORklHX0lORVQ2X0FIPW0NCkNPTkZJR19JTkVUNl9F U1A9bQ0KQ09ORklHX0lORVQ2X0lQQ09NUD1tDQpDT05GSUdfSU5FVDZfVFVO TkVMPW0NCkNPTkZJR19JUFY2X1RVTk5FTD1tDQpDT05GSUdfTkVURklMVEVS PXkNCiMgQ09ORklHX05FVEZJTFRFUl9ERUJVRyBpcyBub3Qgc2V0DQpDT05G SUdfQlJJREdFX05FVEZJTFRFUj15DQoNCiMNCiMgSVA6IE5ldGZpbHRlciBD b25maWd1cmF0aW9uDQojDQpDT05GSUdfSVBfTkZfQ09OTlRSQUNLPW0NCiMg Q09ORklHX0lQX05GX0NUX0FDQ1QgaXMgbm90IHNldA0KIyBDT05GSUdfSVBf TkZfQ1RfUFJPVE9fU0NUUCBpcyBub3Qgc2V0DQpDT05GSUdfSVBfTkZfRlRQ PW0NCkNPTkZJR19JUF9ORl9JUkM9bQ0KQ09ORklHX0lQX05GX1RGVFA9bQ0K Q09ORklHX0lQX05GX0FNQU5EQT1tDQpDT05GSUdfSVBfTkZfUVVFVUU9bQ0K Q09ORklHX0lQX05GX0lQVEFCTEVTPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9M SU1JVD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfSVBSQU5HRT1tDQpDT05GSUdf SVBfTkZfTUFUQ0hfTUFDPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9QS1RUWVBF PW0NCkNPTkZJR19JUF9ORl9NQVRDSF9NQVJLPW0NCkNPTkZJR19JUF9ORl9N QVRDSF9NVUxUSVBPUlQ9bQ0KQ09ORklHX0lQX05GX01BVENIX1RPUz1tDQpD T05GSUdfSVBfTkZfTUFUQ0hfUkVDRU5UPW0NCkNPTkZJR19JUF9ORl9NQVRD SF9FQ049bQ0KQ09ORklHX0lQX05GX01BVENIX0RTQ1A9bQ0KQ09ORklHX0lQ X05GX01BVENIX0FIX0VTUD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfTEVOR1RI PW0NCkNPTkZJR19JUF9ORl9NQVRDSF9UVEw9bQ0KQ09ORklHX0lQX05GX01B VENIX1RDUE1TUz1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfSEVMUEVSPW0NCkNP TkZJR19JUF9ORl9NQVRDSF9TVEFURT1tDQpDT05GSUdfSVBfTkZfTUFUQ0hf Q09OTlRSQUNLPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9PV05FUj1tDQojIENP TkZJR19JUF9ORl9NQVRDSF9QSFlTREVWIGlzIG5vdCBzZXQNCiMgQ09ORklH X0lQX05GX01BVENIX0FERFJUWVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ X05GX01BVENIX1JFQUxNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05GX01B VENIX1NDVFAgaXMgbm90IHNldA0KQ09ORklHX0lQX05GX0ZJTFRFUj1tDQpD T05GSUdfSVBfTkZfVEFSR0VUX1JFSkVDVD1tDQpDT05GSUdfSVBfTkZfVEFS R0VUX0xPRz1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0c9bQ0KQ09ORklH X0lQX05GX1RBUkdFVF9UQ1BNU1M9bQ0KQ09ORklHX0lQX05GX05BVD1tDQpD T05GSUdfSVBfTkZfTkFUX05FRURFRD15DQpDT05GSUdfSVBfTkZfVEFSR0VU X01BU1FVRVJBREU9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVDVD1t DQpDT05GSUdfSVBfTkZfVEFSR0VUX05FVE1BUD1tDQpDT05GSUdfSVBfTkZf VEFSR0VUX1NBTUU9bQ0KQ09ORklHX0lQX05GX05BVF9MT0NBTD15DQpDT05G SUdfSVBfTkZfTkFUX1NOTVBfQkFTSUM9bQ0KQ09ORklHX0lQX05GX05BVF9J UkM9bQ0KQ09ORklHX0lQX05GX05BVF9GVFA9bQ0KQ09ORklHX0lQX05GX05B VF9URlRQPW0NCkNPTkZJR19JUF9ORl9OQVRfQU1BTkRBPW0NCkNPTkZJR19J UF9ORl9NQU5HTEU9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9UT1M9bQ0KQ09O RklHX0lQX05GX1RBUkdFVF9FQ049bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9E U0NQPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfTUFSSz1tDQpDT05GSUdfSVBf TkZfVEFSR0VUX0NMQVNTSUZZPW0NCkNPTkZJR19JUF9ORl9SQVc9bQ0KQ09O RklHX0lQX05GX1RBUkdFVF9OT1RSQUNLPW0NCkNPTkZJR19JUF9ORl9BUlBU QUJMRVM9bQ0KQ09ORklHX0lQX05GX0FSUEZJTFRFUj1tDQpDT05GSUdfSVBf TkZfQVJQX01BTkdMRT1tDQpDT05GSUdfSVBfTkZfQ09NUEFUX0lQQ0hBSU5T PW0NCkNPTkZJR19JUF9ORl9DT01QQVRfSVBGV0FETT1tDQoNCiMNCiMgSVB2 NjogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCiMNCkNPTkZJR19JUDZfTkZf UVVFVUU9bQ0KQ09ORklHX0lQNl9ORl9JUFRBQkxFUz1tDQpDT05GSUdfSVA2 X05GX01BVENIX0xJTUlUPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfTUFDPW0N CkNPTkZJR19JUDZfTkZfTUFUQ0hfUlQ9bQ0KQ09ORklHX0lQNl9ORl9NQVRD SF9PUFRTPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfRlJBRz1tDQpDT05GSUdf SVA2X05GX01BVENIX0hMPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfTVVMVElQ T1JUPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfT1dORVI9bQ0KQ09ORklHX0lQ Nl9ORl9NQVRDSF9NQVJLPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfSVBWNkhF QURFUj1tDQpDT05GSUdfSVA2X05GX01BVENIX0FIRVNQPW0NCkNPTkZJR19J UDZfTkZfTUFUQ0hfTEVOR1RIPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfRVVJ NjQ9bQ0KQ09ORklHX0lQNl9ORl9GSUxURVI9bQ0KQ09ORklHX0lQNl9ORl9U QVJHRVRfTE9HPW0NCkNPTkZJR19JUDZfTkZfTUFOR0xFPW0NCkNPTkZJR19J UDZfTkZfVEFSR0VUX01BUks9bQ0KQ09ORklHX0lQNl9ORl9SQVc9bQ0KDQoj DQojIERFQ25ldDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCiMNCiMgQ09O RklHX0RFQ05FVF9ORl9HUkFCVUxBVE9SIGlzIG5vdCBzZXQNCg0KIw0KIyBC cmlkZ2U6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uDQojDQojIENPTkZJR19C UklER0VfTkZfRUJUQUJMRVMgaXMgbm90IHNldA0KQ09ORklHX1hGUk09eQ0K Q09ORklHX1hGUk1fVVNFUj15DQoNCiMNCiMgU0NUUCBDb25maWd1cmF0aW9u IChFWFBFUklNRU5UQUwpDQojDQpDT05GSUdfSVBfU0NUUD1tDQojIENPTkZJ R19TQ1RQX0RCR19NU0cgaXMgbm90IHNldA0KIyBDT05GSUdfU0NUUF9EQkdf T0JKQ05UIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDVFBfSE1BQ19OT05FIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDVFBfSE1BQ19TSEExIGlzIG5vdCBzZXQN CkNPTkZJR19TQ1RQX0hNQUNfTUQ1PXkNCkNPTkZJR19BVE09bQ0KQ09ORklH X0FUTV9DTElQPW0NCiMgQ09ORklHX0FUTV9DTElQX05PX0lDTVAgaXMgbm90 IHNldA0KIyBDT05GSUdfQVRNX0xBTkUgaXMgbm90IHNldA0KIyBDT05GSUdf QVRNX0JSMjY4NCBpcyBub3Qgc2V0DQpDT05GSUdfQlJJREdFPW0NCkNPTkZJ R19WTEFOXzgwMjFRPW0NCkNPTkZJR19ERUNORVQ9bQ0KIyBDT05GSUdfREVD TkVUX1NJT0NHSUZDT05GIGlzIG5vdCBzZXQNCkNPTkZJR19ERUNORVRfUk9V VEVSPXkNCkNPTkZJR19ERUNORVRfUk9VVEVfRldNQVJLPXkNCkNPTkZJR19M TEM9bQ0KQ09ORklHX0xMQzI9bQ0KIyBDT05GSUdfSVBYIGlzIG5vdCBzZXQN CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1gyNSBpcyBu b3Qgc2V0DQojIENPTkZJR19MQVBCIGlzIG5vdCBzZXQNCiMgQ09ORklHX05F VF9ESVZFUlQgaXMgbm90IHNldA0KIyBDT05GSUdfRUNPTkVUIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1dBTl9ST1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdf TkVUX0hXX0ZMT1dDT05UUk9MIGlzIG5vdCBzZXQNCg0KIw0KIyBRb1MgYW5k L29yIGZhaXIgcXVldWVpbmcNCiMNCkNPTkZJR19ORVRfU0NIRUQ9eQ0KQ09O RklHX05FVF9TQ0hfQ0xLX0pJRkZJRVM9eQ0KIyBDT05GSUdfTkVUX1NDSF9D TEtfR0VUVElNRU9GREFZIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9TQ0hf Q0xLX0NQVSBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1NDSF9DQlE9bQ0KQ09O RklHX05FVF9TQ0hfSFRCPW0NCkNPTkZJR19ORVRfU0NIX0hGU0M9bQ0KIyBD T05GSUdfTkVUX1NDSF9BVE0gaXMgbm90IHNldA0KQ09ORklHX05FVF9TQ0hf UFJJTz1tDQpDT05GSUdfTkVUX1NDSF9SRUQ9bQ0KQ09ORklHX05FVF9TQ0hf U0ZRPW0NCkNPTkZJR19ORVRfU0NIX1RFUUw9bQ0KQ09ORklHX05FVF9TQ0hf VEJGPW0NCkNPTkZJR19ORVRfU0NIX0dSRUQ9bQ0KQ09ORklHX05FVF9TQ0hf RFNNQVJLPW0NCiMgQ09ORklHX05FVF9TQ0hfTkVURU0gaXMgbm90IHNldA0K Q09ORklHX05FVF9TQ0hfSU5HUkVTUz1tDQpDT05GSUdfTkVUX1FPUz15DQpD T05GSUdfTkVUX0VTVElNQVRPUj15DQpDT05GSUdfTkVUX0NMUz15DQpDT05G SUdfTkVUX0NMU19UQ0lOREVYPW0NCkNPTkZJR19ORVRfQ0xTX1JPVVRFND1t DQpDT05GSUdfTkVUX0NMU19ST1VURT15DQpDT05GSUdfTkVUX0NMU19GVz1t DQpDT05GSUdfTkVUX0NMU19VMzI9bQ0KIyBDT05GSUdfQ0xTX1UzMl9QRVJG IGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9DTFNfSU5EIGlzIG5vdCBzZXQN CkNPTkZJR19ORVRfQ0xTX1JTVlA9bQ0KQ09ORklHX05FVF9DTFNfUlNWUDY9 bQ0KIyBDT05GSUdfTkVUX0NMU19BQ1QgaXMgbm90IHNldA0KIyBDT05GSUdf TkVUX0NMU19QT0xJQ0UgaXMgbm90IHNldA0KDQojDQojIE5ldHdvcmsgdGVz dGluZw0KIw0KIyBDT05GSUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0DQojIENP TkZJR19LR0RCT0UgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUUE9MTCBpcyBu b3Qgc2V0DQojIENPTkZJR19ORVRQT0xMX1JYIGlzIG5vdCBzZXQNCiMgQ09O RklHX05FVFBPTExfVFJBUCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfUE9M TF9DT05UUk9MTEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hBTVJBRElPIGlz IG5vdCBzZXQNCiMgQ09ORklHX0lSREEgaXMgbm90IHNldA0KQ09ORklHX0JU PW0NCiMgQ09ORklHX0JUX0wyQ0FQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JU X1NDTyBpcyBub3Qgc2V0DQoNCiMNCiMgQmx1ZXRvb3RoIGRldmljZSBkcml2 ZXJzDQojDQojIENPTkZJR19CVF9IQ0lVQVJUIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JUX0hDSVZIQ0kgaXMgbm90IHNldA0KQ09ORklHX05FVERFVklDRVM9 eQ0KIyBDT05GSUdfRFVNTVkgaXMgbm90IHNldA0KIyBDT05GSUdfQk9ORElO RyBpcyBub3Qgc2V0DQojIENPTkZJR19FUVVBTElaRVIgaXMgbm90IHNldA0K IyBDT05GSUdfVFVOIGlzIG5vdCBzZXQNCg0KIw0KIyBBUkNuZXQgZGV2aWNl cw0KIw0KIyBDT05GSUdfQVJDTkVUIGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhl cm5ldCAoMTAgb3IgMTAwTWJpdCkNCiMNCkNPTkZJR19ORVRfRVRIRVJORVQ9 eQ0KQ09ORklHX01JST1tDQojIENPTkZJR19IQVBQWU1FQUwgaXMgbm90IHNl dA0KIyBDT05GSUdfU1VOR0VNIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVO RE9SXzNDT009eQ0KQ09ORklHX1ZPUlRFWD1tDQojIENPTkZJR19UWVBIT09O IGlzIG5vdCBzZXQNCg0KIw0KIyBUdWxpcCBmYW1pbHkgbmV0d29yayBkZXZp Y2Ugc3VwcG9ydA0KIw0KIyBDT05GSUdfTkVUX1RVTElQIGlzIG5vdCBzZXQN CiMgQ09ORklHX0hQMTAwIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfUENJPXkN CiMgQ09ORklHX1BDTkVUMzIgaXMgbm90IHNldA0KIyBDT05GSUdfQU1EODEx MV9FVEggaXMgbm90IHNldA0KIyBDT05GSUdfQURBUFRFQ19TVEFSRklSRSBp cyBub3Qgc2V0DQojIENPTkZJR19CNDQgaXMgbm90IHNldA0KIyBDT05GSUdf Rk9SQ0VERVRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RHUlMgaXMgbm90IHNl dA0KIyBDT05GSUdfRUVQUk8xMDAgaXMgbm90IHNldA0KQ09ORklHX0UxMDA9 bQ0KIyBDT05GSUdfRTEwMF9OQVBJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZF QUxOWCBpcyBub3Qgc2V0DQojIENPTkZJR19OQVRTRU1JIGlzIG5vdCBzZXQN CiMgQ09ORklHX05FMktfUENJIGlzIG5vdCBzZXQNCiMgQ09ORklHXzgxMzlD UCBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5VE9PIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NJUzkwMCBpcyBub3Qgc2V0DQojIENPTkZJR19FUElDMTAwIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NVTkRBTkNFIGlzIG5vdCBzZXQNCiMgQ09O RklHX1RMQU4gaXMgbm90IHNldA0KIyBDT05GSUdfVklBX1JISU5FIGlzIG5v dCBzZXQNCiMgQ09ORklHX1ZJQV9WRUxPQ0lUWSBpcyBub3Qgc2V0DQoNCiMN CiMgRXRoZXJuZXQgKDEwMDAgTWJpdCkNCiMNCiMgQ09ORklHX0FDRU5JQyBp cyBub3Qgc2V0DQojIENPTkZJR19ETDJLIGlzIG5vdCBzZXQNCkNPTkZJR19F MTAwMD1tDQojIENPTkZJR19FMTAwMF9OQVBJIGlzIG5vdCBzZXQNCiMgQ09O RklHX05TODM4MjAgaXMgbm90IHNldA0KIyBDT05GSUdfSEFNQUNISSBpcyBu b3Qgc2V0DQojIENPTkZJR19ZRUxMT1dGSU4gaXMgbm90IHNldA0KIyBDT05G SUdfUjgxNjkgaXMgbm90IHNldA0KIyBDT05GSUdfU0s5OExJTiBpcyBub3Qg c2V0DQojIENPTkZJR19USUdPTjMgaXMgbm90IHNldA0KDQojDQojIEV0aGVy bmV0ICgxMDAwMCBNYml0KQ0KIw0KIyBDT05GSUdfSVhHQiBpcyBub3Qgc2V0 DQojIENPTkZJR19TMklPIGlzIG5vdCBzZXQNCg0KIw0KIyBUb2tlbiBSaW5n IGRldmljZXMNCiMNCiMgQ09ORklHX1RSIGlzIG5vdCBzZXQNCg0KIw0KIyBX aXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRpbykNCiMNCiMgQ09ORklHX05FVF9S QURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgV2FuIGludGVyZmFjZXMNCiMNCiMg Q09ORklHX1dBTiBpcyBub3Qgc2V0DQoNCiMNCiMgQVRNIGRyaXZlcnMNCiMN CiMgQ09ORklHX0FUTV9UQ1AgaXMgbm90IHNldA0KIyBDT05GSUdfQVRNX0xB TkFJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUTV9FTkkgaXMgbm90IHNldA0K IyBDT05GSUdfQVRNX0ZJUkVTVFJFQU0gaXMgbm90IHNldA0KIyBDT05GSUdf QVRNX1pBVE0gaXMgbm90IHNldA0KIyBDT05GSUdfQVRNX05JQ1NUQVIgaXMg bm90IHNldA0KIyBDT05GSUdfQVRNX0lEVDc3MjUyIGlzIG5vdCBzZXQNCiMg Q09ORklHX0FUTV9BTUJBU1NBRE9SIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FU TV9IT1JJWk9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUTV9JQSBpcyBub3Qg c2V0DQojIENPTkZJR19BVE1fRk9SRTIwMEVfTUFZQkUgaXMgbm90IHNldA0K IyBDT05GSUdfQVRNX0hFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZEREkgaXMg bm90IHNldA0KIyBDT05GSUdfSElQUEkgaXMgbm90IHNldA0KIyBDT05GSUdf UFBQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NMSVAgaXMgbm90IHNldA0KIyBD T05GSUdfTkVUX0ZDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NIQVBFUiBpcyBu b3Qgc2V0DQojIENPTkZJR19ORVRDT05TT0xFIGlzIG5vdCBzZXQNCg0KIw0K IyBJU0ROIHN1YnN5c3RlbQ0KIw0KIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0 DQoNCiMNCiMgVGVsZXBob255IFN1cHBvcnQNCiMNCiMgQ09ORklHX1BIT05F IGlzIG5vdCBzZXQNCg0KIw0KIyBJbnB1dCBkZXZpY2Ugc3VwcG9ydA0KIw0K Q09ORklHX0lOUFVUPXkNCg0KIw0KIyBVc2VybGFuZCBpbnRlcmZhY2VzDQoj DQpDT05GSUdfSU5QVVRfTU9VU0VERVY9eQ0KQ09ORklHX0lOUFVUX01PVVNF REVWX1BTQVVYPXkNCkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0x MDI0DQpDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4DQojIENP TkZJR19JTlBVVF9KT1lERVYgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRf VFNERVYgaXMgbm90IHNldA0KQ09ORklHX0lOUFVUX0VWREVWPXkNCiMgQ09O RklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQNCg0KIw0KIyBJbnB1dCBJL08g ZHJpdmVycw0KIw0KIyBDT05GSUdfR0FNRVBPUlQgaXMgbm90IHNldA0KQ09O RklHX1NPVU5EX0dBTUVQT1JUPXkNCkNPTkZJR19TRVJJTz15DQpDT05GSUdf U0VSSU9fSTgwNDI9eQ0KQ09ORklHX1NFUklPX1NFUlBPUlQ9eQ0KIyBDT05G SUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSU9f UENJUFMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklPX1JBVyBpcyBub3Qg c2V0DQoNCiMNCiMgSW5wdXQgRGV2aWNlIERyaXZlcnMNCiMNCkNPTkZJR19J TlBVVF9LRVlCT0FSRD15DQpDT05GSUdfS0VZQk9BUkRfQVRLQkQ9eQ0KIyBD T05GSUdfS0VZQk9BUkRfU1VOS0JEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0tF WUJPQVJEX0xLS0JEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX1hU S0JEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0tFWUJPQVJEX05FV1RPTiBpcyBu b3Qgc2V0DQpDT05GSUdfSU5QVVRfTU9VU0U9eQ0KQ09ORklHX01PVVNFX1BT Mj15DQojIENPTkZJR19NT1VTRV9TRVJJQUwgaXMgbm90IHNldA0KIyBDT05G SUdfTU9VU0VfVlNYWFhBQSBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9K T1lTVElDSyBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9UT1VDSFNDUkVF TiBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9NSVNDIGlzIG5vdCBzZXQN Cg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09ORklHX1ZUPXkNCkNP TkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19IV19DT05TT0xFPXkNCiMgQ09O RklHX1NFUklBTF9OT05TVEFOREFSRCBpcyBub3Qgc2V0DQoNCiMNCiMgU2Vy aWFsIGRyaXZlcnMNCiMNCkNPTkZJR19TRVJJQUxfODI1MD15DQpDT05GSUdf U0VSSUFMXzgyNTBfQ09OU09MRT15DQojIENPTkZJR19TRVJJQUxfODI1MF9B Q1BJIGlzIG5vdCBzZXQNCkNPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUz00 DQojIENPTkZJR19TRVJJQUxfODI1MF9FWFRFTkRFRCBpcyBub3Qgc2V0DQoN CiMNCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9ydA0KIw0KQ09ORklH X1NFUklBTF9DT1JFPXkNCkNPTkZJR19TRVJJQUxfQ09SRV9DT05TT0xFPXkN CkNPTkZJR19VTklYOThfUFRZUz15DQpDT05GSUdfTEVHQUNZX1BUWVM9eQ0K Q09ORklHX0xFR0FDWV9QVFlfQ09VTlQ9MjU2DQoNCiMNCiMgSVBNSQ0KIw0K IyBDT05GSUdfSVBNSV9IQU5ETEVSIGlzIG5vdCBzZXQNCg0KIw0KIyBXYXRj aGRvZyBDYXJkcw0KIw0KIyBDT05GSUdfV0FUQ0hET0cgaXMgbm90IHNldA0K IyBDT05GSUdfSFdfUkFORE9NIGlzIG5vdCBzZXQNCiMgQ09ORklHX05WUkFN IGlzIG5vdCBzZXQNCkNPTkZJR19SVEM9eQ0KIyBDT05GSUdfRFRMSyBpcyBu b3Qgc2V0DQojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0DQojIENPTkZJR19B UFBMSUNPTSBpcyBub3Qgc2V0DQojIENPTkZJR19TT05ZUEkgaXMgbm90IHNl dA0KDQojDQojIEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRyaXZl cg0KIw0KIyBDT05GSUdfQUdQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RSTSBp cyBub3Qgc2V0DQojIENPTkZJR19NV0FWRSBpcyBub3Qgc2V0DQpDT05GSUdf UkFXX0RSSVZFUj1tDQpDT05GSUdfSFBFVD15DQojIENPTkZJR19IUEVUX1JU Q19JUlEgaXMgbm90IHNldA0KQ09ORklHX0hQRVRfTU1BUD15DQpDT05GSUdf TUFYX1JBV19ERVZTPTI1Ng0KIyBDT05GSUdfSEFOR0NIRUNLX1RJTUVSIGlz IG5vdCBzZXQNCg0KIw0KIyBJMkMgc3VwcG9ydA0KIw0KIyBDT05GSUdfSTJD IGlzIG5vdCBzZXQNCg0KIw0KIyBEYWxsYXMncyAxLXdpcmUgYnVzDQojDQoj IENPTkZJR19XMSBpcyBub3Qgc2V0DQoNCiMNCiMgTWlzYyBkZXZpY2VzDQoj DQojIENPTkZJR19JQk1fQVNNIGlzIG5vdCBzZXQNCg0KIw0KIyBNdWx0aW1l ZGlhIGRldmljZXMNCiMNCiMgQ09ORklHX1ZJREVPX0RFViBpcyBub3Qgc2V0 DQoNCiMNCiMgRGlnaXRhbCBWaWRlbyBCcm9hZGNhc3RpbmcgRGV2aWNlcw0K Iw0KIyBDT05GSUdfRFZCIGlzIG5vdCBzZXQNCg0KIw0KIyBHcmFwaGljcyBz dXBwb3J0DQojDQojIENPTkZJR19GQiBpcyBub3Qgc2V0DQpDT05GSUdfVklE RU9fU0VMRUNUPXkNCg0KIw0KIyBDb25zb2xlIGRpc3BsYXkgZHJpdmVyIHN1 cHBvcnQNCiMNCkNPTkZJR19WR0FfQ09OU09MRT15DQpDT05GSUdfRFVNTVlf Q09OU09MRT15DQoNCiMNCiMgU291bmQNCiMNCiMgQ09ORklHX1NPVU5EIGlz IG5vdCBzZXQNCg0KIw0KIyBVU0Igc3VwcG9ydA0KIw0KIyBDT05GSUdfVVNC IGlzIG5vdCBzZXQNCg0KIw0KIyBVU0IgR2FkZ2V0IFN1cHBvcnQNCiMNCiMg Q09ORklHX1VTQl9HQURHRVQgaXMgbm90IHNldA0KDQojDQojIEZpbGUgc3lz dGVtcw0KIw0KQ09ORklHX0VYVDJfRlM9eQ0KQ09ORklHX0VYVDJfRlNfWEFU VFI9eQ0KQ09ORklHX0VYVDJfRlNfUE9TSVhfQUNMPXkNCkNPTkZJR19FWFQy X0ZTX1NFQ1VSSVRZPXkNCkNPTkZJR19FWFQzX0ZTPXkNCkNPTkZJR19FWFQz X0ZTX1hBVFRSPXkNCkNPTkZJR19FWFQzX0ZTX1BPU0lYX0FDTD15DQpDT05G SUdfRVhUM19GU19TRUNVUklUWT15DQpDT05GSUdfSkJEPXkNCiMgQ09ORklH X0pCRF9ERUJVRyBpcyBub3Qgc2V0DQpDT05GSUdfRlNfTUJDQUNIRT15DQoj IENPTkZJR19SRUlTRVJGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KRlNf RlMgaXMgbm90IHNldA0KQ09ORklHX0ZTX1BPU0lYX0FDTD15DQojIENPTkZJ R19YRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90 IHNldA0KIyBDT05GSUdfUk9NRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf UVVPVEEgaXMgbm90IHNldA0KIyBDT05GSUdfQVVUT0ZTX0ZTIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FVVE9GUzRfRlMgaXMgbm90IHNldA0KDQojDQojIENh Y2hlcw0KIw0KIyBDT05GSUdfQ0FDSEVGUyBpcyBub3Qgc2V0DQoNCiMNCiMg Q0QtUk9NL0RWRCBGaWxlc3lzdGVtcw0KIw0KQ09ORklHX0lTTzk2NjBfRlM9 eQ0KQ09ORklHX0pPTElFVD15DQpDT05GSUdfWklTT0ZTPXkNCkNPTkZJR19a SVNPRlNfRlM9eQ0KQ09ORklHX1VERl9GUz15DQpDT05GSUdfVURGX05MUz15 DQoNCiMNCiMgRE9TL0ZBVC9OVCBGaWxlc3lzdGVtcw0KIw0KQ09ORklHX0ZB VF9GUz15DQpDT05GSUdfTVNET1NfRlM9bQ0KQ09ORklHX1ZGQVRfRlM9eQ0K Q09ORklHX0ZBVF9ERUZBVUxUX0NPREVQQUdFPTQzNw0KQ09ORklHX0ZBVF9E RUZBVUxUX0lPQ0hBUlNFVD0iaXNvODg1OS0xIg0KIyBDT05GSUdfTlRGU19G UyBpcyBub3Qgc2V0DQoNCiMNCiMgUHNldWRvIGZpbGVzeXN0ZW1zDQojDQpD T05GSUdfUFJPQ19GUz15DQpDT05GSUdfUFJPQ19LQ09SRT15DQpDT05GSUdf U1lTRlM9eQ0KIyBDT05GSUdfREVWRlNfRlMgaXMgbm90IHNldA0KQ09ORklH X0RFVlBUU19GU19YQVRUUj15DQpDT05GSUdfREVWUFRTX0ZTX1NFQ1VSSVRZ PXkNCkNPTkZJR19UTVBGUz15DQpDT05GSUdfSFVHRVRMQkZTPXkNCkNPTkZJ R19IVUdFVExCX1BBR0U9eQ0KQ09ORklHX1JBTUZTPXkNCkNPTkZJR19LRVlG Uz15DQoNCiMNCiMgTWlzY2VsbGFuZW91cyBmaWxlc3lzdGVtcw0KIw0KIyBD T05GSUdfQURGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19BRkZTX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX0hGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJ R19IRlNQTFVTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JFRlNfRlMgaXMg bm90IHNldA0KIyBDT05GSUdfQkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklH X0VGU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfQ1JBTUZTPW0NCiMgQ09ORklH X1ZYRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSFBGU19GUyBpcyBub3Qg c2V0DQojIENPTkZJR19RTlg0RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf U1lTVl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19VRlNfRlMgaXMgbm90IHNl dA0KDQojDQojIE5ldHdvcmsgRmlsZSBTeXN0ZW1zDQojDQpDT05GSUdfTkZT X0ZTPXkNCkNPTkZJR19ORlNfVjM9eQ0KQ09ORklHX05GU19WND15DQpDT05G SUdfTkZTX0RJUkVDVElPPXkNCkNPTkZJR19ORlNEPXkNCkNPTkZJR19ORlNE X1YzPXkNCkNPTkZJR19ORlNEX1Y0PXkNCkNPTkZJR19ORlNEX1RDUD15DQpD T05GSUdfTE9DS0Q9eQ0KQ09ORklHX0xPQ0tEX1Y0PXkNCkNPTkZJR19FWFBP UlRGUz15DQpDT05GSUdfU1VOUlBDPXkNCkNPTkZJR19TVU5SUENfR1NTPXkN CkNPTkZJR19SUENTRUNfR1NTX0tSQjU9eQ0KQ09ORklHX1JQQ1NFQ19HU1Nf U1BLTTM9bQ0KIyBDT05GSUdfU01CX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19D SUZTPW0NCiMgQ09ORklHX0NJRlNfU1RBVFMgaXMgbm90IHNldA0KIyBDT05G SUdfQ0lGU19YQVRUUiBpcyBub3Qgc2V0DQojIENPTkZJR19DSUZTX1BPU0lY IGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0DQojIENP TkZJR19DT0RBX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FGU19GUyBpcyBu b3Qgc2V0DQoNCiMNCiMgUGFydGl0aW9uIFR5cGVzDQojDQojIENPTkZJR19Q QVJUSVRJT05fQURWQU5DRUQgaXMgbm90IHNldA0KQ09ORklHX01TRE9TX1BB UlRJVElPTj15DQoNCiMNCiMgTmF0aXZlIExhbmd1YWdlIFN1cHBvcnQNCiMN CkNPTkZJR19OTFM9eQ0KQ09ORklHX05MU19ERUZBVUxUPSJpc284ODU5LTEi DQpDT05GSUdfTkxTX0NPREVQQUdFXzQzNz15DQojIENPTkZJR19OTFNfQ09E RVBBR0VfNzM3IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV83 NzUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MCBpcyBu b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODUyIGlzIG5vdCBzZXQN CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTUgaXMgbm90IHNldA0KIyBDT05G SUdfTkxTX0NPREVQQUdFXzg1NyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNf Q09ERVBBR0VfODYwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFH RV84NjEgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MiBp cyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODYzIGlzIG5vdCBz ZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldA0KIyBD T05GSUdfTkxTX0NPREVQQUdFXzg2NSBpcyBub3Qgc2V0DQojIENPTkZJR19O TFNfQ09ERVBBR0VfODY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RF UEFHRV84NjkgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzkz NiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfOTUwIGlzIG5v dCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV85MzIgaXMgbm90IHNldA0K IyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBpcyBub3Qgc2V0DQojIENPTkZJ R19OTFNfQ09ERVBBR0VfODc0IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19J U084ODU5XzggaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzEy NTAgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTEgaXMg bm90IHNldA0KIyBDT05GSUdfTkxTX0FTQ0lJIGlzIG5vdCBzZXQNCkNPTkZJ R19OTFNfSVNPODg1OV8xPXkNCiMgQ09ORklHX05MU19JU084ODU5XzIgaXMg bm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0DQoj IENPTkZJR19OTFNfSVNPODg1OV80IGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19JU084ODU5XzUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlf NiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV83IGlzIG5vdCBz ZXQNCiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90IHNldA0KIyBDT05G SUdfTkxTX0lTTzg4NTlfMTMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lT Tzg4NTlfMTQgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMTUg aXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0DQoj IENPTkZJR19OTFNfS09JOF9VIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19V VEY4IGlzIG5vdCBzZXQNCg0KIw0KIyBQcm9maWxpbmcgc3VwcG9ydA0KIw0K Q09ORklHX1BST0ZJTElORz15DQpDT05GSUdfT1BST0ZJTEU9bQ0KDQojDQoj IEtlcm5lbCBoYWNraW5nDQojDQpDT05GSUdfREVCVUdfS0VSTkVMPXkNCkNP TkZJR19NQUdJQ19TWVNSUT15DQpDT05GSUdfREVCVUdfU0xBQj15DQojIENP TkZJR19ERUJVR19TUElOTE9DSyBpcyBub3Qgc2V0DQpDT05GSUdfREVCVUdf U1BJTkxPQ0tfU0xFRVA9eQ0KIyBDT05GSUdfREVCVUdfSElHSE1FTSBpcyBu b3Qgc2V0DQpDT05GSUdfREVCVUdfSU5GTz15DQpDT05GSUdfRlJBTUVfUE9J TlRFUj15DQpDT05GSUdfRUFSTFlfUFJJTlRLPXkNCkNPTkZJR19ERUJVR19T VEFDS09WRVJGTE9XPXkNCiMgQ09ORklHX0tQUk9CRVMgaXMgbm90IHNldA0K IyBDT05GSUdfREVCVUdfU1RBQ0tfVVNBR0UgaXMgbm90IHNldA0KIyBDT05G SUdfREVCVUdfUEFHRUFMTE9DIGlzIG5vdCBzZXQNCkNPTkZJR180S1NUQUNL Uz15DQojIENPTkZJR19TQ0hFRFNUQVRTIGlzIG5vdCBzZXQNCiMgQ09ORklH X0xPQ0tNRVRFUiBpcyBub3Qgc2V0DQpDT05GSUdfWDg2X0ZJTkRfU01QX0NP TkZJRz15DQpDT05GSUdfWDg2X01QUEFSU0U9eQ0KIyBDT05GSUdfS0dEQiBp cyBub3Qgc2V0DQoNCiMNCiMgU2VjdXJpdHkgb3B0aW9ucw0KIw0KQ09ORklH X0tFWVM9eQ0KQ09ORklHX0tFWVNfREVCVUdfUFJPQ19LRVlTPXkNCkNPTkZJ R19TRUNVUklUWT15DQpDT05GSUdfU0VDVVJJVFlfTkVUV09SSz15DQpDT05G SUdfU0VDVVJJVFlfQ0FQQUJJTElUSUVTPXkNCkNPTkZJR19TRUNVUklUWV9T RUxJTlVYPXkNCkNPTkZJR19TRUNVUklUWV9TRUxJTlVYX0JPT1RQQVJBTT15 DQpDT05GSUdfU0VDVVJJVFlfU0VMSU5VWF9CT09UUEFSQU1fVkFMVUU9MQ0K Q09ORklHX1NFQ1VSSVRZX1NFTElOVVhfRElTQUJMRT15DQpDT05GSUdfU0VD VVJJVFlfU0VMSU5VWF9ERVZFTE9QPXkNCiMgQ09ORklHX1NFQ1VSSVRZX1NF TElOVVhfTUxTIGlzIG5vdCBzZXQNCg0KIw0KIyBDcnlwdG9ncmFwaGljIG9w dGlvbnMNCiMNCkNPTkZJR19DUllQVE89eQ0KQ09ORklHX0NSWVBUT19ITUFD PXkNCkNPTkZJR19DUllQVE9fTlVMTD1tDQpDT05GSUdfQ1JZUFRPX01END1t DQpDT05GSUdfQ1JZUFRPX01ENT15DQpDT05GSUdfQ1JZUFRPX1NIQTE9eQ0K Q09ORklHX0NSWVBUT19TSEEyNTY9bQ0KQ09ORklHX0NSWVBUT19TSEE1MTI9 bQ0KQ09ORklHX0NSWVBUT19XSElSTFBPT0w9bQ0KQ09ORklHX0NSWVBUT19E RVM9eQ0KQ09ORklHX0NSWVBUT19CTE9XRklTSD1tDQpDT05GSUdfQ1JZUFRP X1RXT0ZJU0g9bQ0KQ09ORklHX0NSWVBUT19TRVJQRU5UPW0NCkNPTkZJR19D UllQVE9fQUVTXzU4Nj1tDQpDT05GSUdfQ1JZUFRPX0NBU1Q1PW0NCkNPTkZJ R19DUllQVE9fQ0FTVDY9bQ0KQ09ORklHX0NSWVBUT19URUE9bQ0KQ09ORklH X0NSWVBUT19BUkM0PW0NCkNPTkZJR19DUllQVE9fS0hBWkFEPW0NCkNPTkZJ R19DUllQVE9fREVGTEFURT15DQpDT05GSUdfQ1JZUFRPX01JQ0hBRUxfTUlD PW0NCkNPTkZJR19DUllQVE9fQ1JDMzJDPW0NCkNPTkZJR19DUllQVE9fVEVT VD1tDQoNCiMNCiMgTGlicmFyeSByb3V0aW5lcw0KIw0KQ09ORklHX0NSQ19D Q0lUVD1tDQpDT05GSUdfQ1JDMzI9eQ0KQ09ORklHX0xJQkNSQzMyQz1tDQpD T05GSUdfWkxJQl9JTkZMQVRFPXkNCkNPTkZJR19aTElCX0RFRkxBVEU9eQ0K Q09ORklHX1g4Nl9TTVA9eQ0KQ09ORklHX1g4Nl9IVD15DQpDT05GSUdfWDg2 X0JJT1NfUkVCT09UPXkNCkNPTkZJR19YODZfVFJBTVBPTElORT15DQpDT05G SUdfUEM9eQ0K --279723856-1301949747-1095121538=:22477-- From yoshfuji@linux-ipv6.org Mon Sep 13 18:19:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 18:19:28 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E1JMDs013304 for ; Mon, 13 Sep 2004 18:19:23 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0F63033CE7; Tue, 14 Sep 2004 10:19:16 +0900 (JST) Date: Tue, 14 Sep 2004 10:19:15 +0900 (JST) Message-Id: <20040914.101915.10604263.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, vnuorval@tcs.hut.fi, yoshfuji@linux-ipv6.org Subject: Re: [BK PATCH] [IPV6] Merge Specification Conformity Improvements From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040913155506.4c99d4c8.davem@davemloft.net> References: <20040913.231732.94153456.yoshfuji@linux-ipv6.org> <20040913155506.4c99d4c8.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2944 Lines: 100 In article <20040913155506.4c99d4c8.davem@davemloft.net> (at Mon, 13 Sep 2004 15:55:06 -0700), "David S. Miller" says: > 2) rt6_dflt_{pointer,lock} > > Maybe it would be better to export a function that operates > on these objects rather than the objects themselves. That > way we could keep them and their implementation static to > ip6_fib.c Yes! I know it is silly, of course. Well, I have a plan to remove rt6_dflt_{pointer,lock} shortly, but anyway... Signed-off-by: Hideaki YOSHIFUJI ===== include/net/ip6_route.h 1.18 vs edited ===== --- 1.18/include/net/ip6_route.h 2004-09-11 23:50:37 +09:00 +++ edited/include/net/ip6_route.h 2004-09-14 10:01:50 +09:00 @@ -89,6 +89,8 @@ extern void rt6_purge_dflt_routers(int lst_resort); +extern void rt6_reset_dflt_pointer(struct rt6_info *rt); + extern void rt6_redirect(struct in6_addr *dest, struct in6_addr *saddr, struct neighbour *neigh, ===== net/ipv6/ip6_fib.c 1.30 vs edited ===== --- 1.30/net/ipv6/ip6_fib.c 2004-09-11 23:56:06 +09:00 +++ edited/net/ipv6/ip6_fib.c 2004-09-14 10:00:33 +09:00 @@ -49,9 +49,6 @@ struct rt6_statistics rt6_stats; -extern struct rt6_info *rt6_dflt_pointer; -extern spinlock_t rt6_dflt_lock; - static kmem_cache_t * fib6_node_kmem; enum fib_walk_state_t @@ -1187,10 +1184,7 @@ if (rt->rt6i_flags&RTF_EXPIRES && rt->rt6i_expires) { if (time_after(now, rt->rt6i_expires)) { RT6_TRACE("expiring %p\n", rt); - spin_lock_bh(&rt6_dflt_lock); - if (rt == rt6_dflt_pointer) - rt6_dflt_pointer = NULL; - spin_unlock_bh(&rt6_dflt_lock); + rt6_reset_dflt_pointer(rt); return -1; } gc_args.more++; ===== net/ipv6/route.c 1.92 vs edited ===== --- 1.92/net/ipv6/route.c 2004-09-11 23:53:53 +09:00 +++ edited/net/ipv6/route.c 2004-09-14 10:10:25 +09:00 @@ -210,6 +210,16 @@ struct rt6_info *rt6_dflt_pointer; spinlock_t rt6_dflt_lock = SPIN_LOCK_UNLOCKED; +void rt6_reset_dflt_pointer(struct rt6_info *rt) +{ + spin_lock_bh(&rt6_dflt_lock); + if (rt == NULL || rt == rt6_dflt_pointer) { + RT6_TRACE("reset default router: %p->NULL\n", rt6_dflt_pointer); + rt6_dflt_pointer = NULL; + } + spin_unlock_bh(&rt6_dflt_lock); +} + /* Default Router Selection (RFC 2461 6.3.6) */ static struct rt6_info *rt6_best_dflt(struct rt6_info *rt, int oif) { @@ -959,9 +969,7 @@ write_lock_bh(&rt6_lock); - spin_lock_bh(&rt6_dflt_lock); - rt6_dflt_pointer = NULL; - spin_unlock_bh(&rt6_dflt_lock); + rt6_reset_dflt_pointer(NULL); dst_release(&rt->u.dst); @@ -1288,9 +1296,7 @@ if (rt->rt6i_flags & flags) { dst_hold(&rt->u.dst); - spin_lock_bh(&rt6_dflt_lock); - rt6_dflt_pointer = NULL; - spin_unlock_bh(&rt6_dflt_lock); + rt6_reset_dflt_pointer(NULL); read_unlock_bh(&rt6_lock); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From hadi@cyberus.ca Mon Sep 13 18:43:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 18:43:48 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E1hfE1013942 for ; Mon, 13 Sep 2004 18:43:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C72M0-00038E-5f for netdev@oss.sgi.com; Mon, 13 Sep 2004 21:43:32 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C72Lw-00038Z-G1; Mon, 13 Sep 2004 21:43:28 -0400 Subject: Re: [PATCH] Fix locking bug in lltx path From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: "David S. Miller" , netdev@oss.sgi.com, arjanv@redhat.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1095126203.1056.7.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Sep 2004 21:43:24 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1820 Lines: 58 Finaly got around to testing today and got bitten by this (was planning to send patch);-> In any case, some good news: one of the NICs tested was e1000 with and without LLTX pure forwarding (eth0->eth1 and eth1->eth0, 64 byte packets beating up the interfaces at 1/48Mpps): did not see much difference between the two. There did seem to be some latency improvements (in the range of 50 microsecs or so for the LLTX but could be experimental error, needs more validation). I think perhaps a case where multi processors fanning into one NIC would be a better test to see the value of LLTX. The good news (for me) is it doesnt seem to affect things negatively. [We saw some corrupt netpoll packets but that could be something else broken]. cheers, jamal On Mon, 2004-09-13 at 14:11, Andi Kleen wrote: > Thanks to Arjan's spinlock debug kernel for finding it. > > This fixes a silly missing spin lock in the relock path. For some > reason it seems to still work when you don't have spinlock debugging > enabled. > > Please apply. > > -Andi > > -------------------------------------------------------------------- > > Fix missing spin lock in lltx path. > > Thanks to Arjan's spinlock debug kernel for finding it. > > Signed-off-by: Andi Kleen > > diff -u linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X linux-2.6.9rc1-bk19/net/sched/sch_generic.c > --- linux-2.6.9rc1-bk19/net/sched/sch_generic.c-X 2004-09-13 08:51:46.000000000 +0200 > +++ linux-2.6.9rc1-bk19/net/sched/sch_generic.c 2004-09-13 19:22:50.000000000 +0200 > @@ -153,8 +153,10 @@ > spin_lock(&dev->queue_lock); > return -1; > } > - if (ret == -1 && nolock) > + if (ret == -1 && nolock) { > + spin_lock(&dev->queue_lock); > goto collision; > + } > } > > /* Release the driver */ > > > From hadi@cyberus.ca Mon Sep 13 19:00:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 19:00:46 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E20fw3014623 for ; Mon, 13 Sep 2004 19:00:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C72cT-0006ep-3z for netdev@oss.sgi.com; Mon, 13 Sep 2004 22:00:33 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C72cO-000525-8C; Mon, 13 Sep 2004 22:00:28 -0400 Subject: Re: [RFC] Extend netlink error codes From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Sam Leffler , Andi Kleen , netdev@oss.sgi.com In-Reply-To: <20040913203657.GF23686@postel.suug.ch> References: <20040910225158.GO20088@postel.suug.ch> <20040911155839.GN4431@wotan.suse.de> <20040911162433.GC21181@postel.suug.ch> <3A0D075D-0423-11D9-BBE1-000A95AD0668@errno.com> <1094937035.2344.189.camel@jzny.localdomain> <20040913203657.GF23686@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095127223.1057.25.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Sep 2004 22:00:23 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1491 Lines: 34 On Mon, 2004-09-13 at 16:36, Thomas Graf wrote: > * jamal <1094937035.2344.189.camel@jzny.localdomain> 2004-09-11 17:10 > > just reuse skb->cb[] and intepret it in rtnetlink in the case of > > failures. > > Good idea, however it means to change a lot of APIs used by modules > to provide the skb or a pointer to the error string buffer. > > I still think it would be best to transport the error code via > the return value in order to not change any static APIs, but > I guess that 32bit is not enough to store errno and the id > your propose below. The problem with using the return codes is you have to know somehow all the error variants within netlink code itself. If you return a TLV skb->cb[] then the netlink code could blindly forward it to user space. I dont think theres a lot of changes to APIs. the calls from netlink already pass the skb to all modules. The dumps are speacial since the ->cb[] is actually used. Of course you could do it with return codes, probably do some smart things in the netlink code without making it too knowledgeable but you may need to have a global table. > Idea: Make user space applications poll on the socket and > just print the errors async. This would allow netlink users to > use it for more than just error handling. I think i agree with what Dave says in his other email - we should probably just borrow any useful ideas they have wirthout complicating things on our part. It does seem too tangential after reading it. cheers, jamal From davem@davemloft.net Mon Sep 13 19:10:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 19:11:04 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E2Aw1V015470 for ; Mon, 13 Sep 2004 19:10:59 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C72kc-0006DR-00; Mon, 13 Sep 2004 19:08:58 -0700 Date: Mon, 13 Sep 2004 19:08:58 -0700 From: "David S. Miller" To: James Morris Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-mm5: TCP oopses Message-Id: <20040913190858.12544431.davem@davemloft.net> In-Reply-To: References: <20040913015003.5406abae.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2466 Lines: 75 On Mon, 13 Sep 2004 20:25:38 -0400 (EDT) James Morris wrote: > I'm experiencing TCP related oopses with this kernel (not seen in -mm4), > .config file attached. > > Here are two backtraces, the first happened a few seconds after logging > in via ssh, the second happened soon after boot (using selinux=0, just to > make sure). I think I fixed this one yesterday. Callers of tcp_fragment() in tcp_output.c were not accounting packets correctly. I believe this is what will fix it, and this is in Linus's tree already. I guess you have an e1000 in this box? :) (either that or some other card whose driver enables TSO by default) # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/10 15:21:43-07:00 davem@nuts.davemloft.net # [TCP]: Fix packet counting when fragmenting already sent packets. # # Calls to tcp_fragment() change the tso_factor of # an SKB, so we need to deal with that. # # Signed-off-by: David S. Miller # # net/ipv4/tcp_output.c # 2004/09/10 15:21:13-07:00 davem@nuts.davemloft.net +12 -2 # [TCP]: Fix packet counting when fragmenting already sent packets. # # Calls to tcp_fragment() change the tso_factor of # an SKB, so we need to deal with that. # # Signed-off-by: David S. Miller # diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-13 18:51:38 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-13 18:51:38 -07:00 @@ -681,8 +681,12 @@ TCP_SKB_CB(skb)->when = tcp_time_stamp; if (tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC))) break; - /* Advance the send_head. This one is sent out. */ + + /* Advance the send_head. This one is sent out. + * This call will increment packets_out. + */ update_send_head(sk, tp, skb); + tcp_minshall_update(tp, mss_now, skb); sent_pkts = 1; } @@ -968,11 +972,17 @@ return -EAGAIN; if (skb->len > cur_mss) { + int old_factor = TCP_SKB_CB(skb)->tso_factor; + int new_factor; + if (tcp_fragment(sk, skb, cur_mss)) return -ENOMEM; /* We'll try again later. */ /* New SKB created, account for it. */ - tcp_inc_pcount(&tp->packets_out, skb); + new_factor = TCP_SKB_CB(skb)->tso_factor; + tcp_dec_pcount_explicit(&tp->packets_out, + new_factor - old_factor); + tcp_inc_pcount(&tp->packets_out, skb->next); } /* Collapse two adjacent packets if worthwhile and we can. */ From hadi@cyberus.ca Mon Sep 13 19:40:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 19:40:56 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E2eoBZ018012 for ; Mon, 13 Sep 2004 19:40:50 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C73FI-0006TM-AE for netdev@oss.sgi.com; Mon, 13 Sep 2004 22:40:40 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C73FC-0000kH-2b; Mon, 13 Sep 2004 22:40:34 -0400 Subject: Re: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL) From: jamal Reply-To: hadi@cyberus.ca To: lkml@einar-lueck.de Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <41457848.6040808@de.ibm.com> References: <41457848.6040808@de.ibm.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095129624.1060.45.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Sep 2004 22:40:24 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1541 Lines: 30 On Mon, 2004-09-13 at 06:36, Einar Lueck wrote: [..] > The basic idea of the proposed patch is to utilize a new flag at the > "struct dst_entry" flags field to indicate that further routes having > the same key follow in the routing cache chain. Consequently, at cache lookup time > we recognize this flag and may apply different load balancing policies > to the available routes having the same key. The Garbage Collection is modified in > a way that ensures that all routes having the same target are removed > together from the cache. As long as whatever arrangement ensures that no packet reordering happens, should be sane. Yes, current scheme is broken in some ways (but guarantees packet ordering within a flow). Clearly the better way is to have all N equal path routes in an array of size N somehow also attached to the hash chain. Then policy flag selects algorithm executed to select 1 of N. The real difference between all of them is what the nexhop is (oif and NH MAC and maybe src IP if local). My opinion: we should kill the current code altogether and do this as post routing decision to make it more flexible. I have a tc action i am working on that could have a preprocessor of an action like a policer "flow X has now exceeded 10Mbps we need to select new route". Of course there could be a lot of other state used in overruling routing decisions; eg attached contracking information could be useful etc. There are a few challeneges to make this reality (other than the ReMAC action i am working on). cheers, jamal From jmorris@redhat.com Mon Sep 13 20:04:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 20:04:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E34dxl019007 for ; Mon, 13 Sep 2004 20:04:40 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8E34PAc010604; Mon, 13 Sep 2004 23:04:25 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8E34Pr24583; Mon, 13 Sep 2004 23:04:25 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8E34PiS022448; Mon, 13 Sep 2004 23:04:25 -0400 Date: Mon, 13 Sep 2004 23:04:24 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: "David S. Miller" cc: akpm@osdl.org, , Subject: Re: 2.6.9-rc1-mm5: TCP oopses In-Reply-To: <20040913190858.12544431.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 433 Lines: 21 On Mon, 13 Sep 2004, David S. Miller wrote: > I think I fixed this one yesterday. Callers of tcp_fragment() > in tcp_output.c were not accounting packets correctly. I > believe this is what will fix it, and this is in Linus's > tree already. This patch is also in -mm5 (linus.patch), and the oopses go away when I back it out. > I guess you have an e1000 in this box? :) Yes. - James -- James Morris From herbert@gondor.apana.org.au Mon Sep 13 20:34:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 20:35:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E3YqAg023257 for ; Mon, 13 Sep 2004 20:34:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C745J-0006zs-00; Tue, 14 Sep 2004 13:34:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C745E-00024r-00; Tue, 14 Sep 2004 13:34:20 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: 2.6.9-rc1-mm5: TCP oopses Cc: jmorris@redhat.com, akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040913190858.12544431.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Tue, 14 Sep 2004 13:34:20 +1000 X-archive-position: 8766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 931 Lines: 26 David S. Miller wrote: > > @@ -968,11 +972,17 @@ > return -EAGAIN; > > if (skb->len > cur_mss) { > + int old_factor = TCP_SKB_CB(skb)->tso_factor; > + int new_factor; > + > if (tcp_fragment(sk, skb, cur_mss)) > return -ENOMEM; /* We'll try again later. */ > > /* New SKB created, account for it. */ > - tcp_inc_pcount(&tp->packets_out, skb); > + new_factor = TCP_SKB_CB(skb)->tso_factor; > + tcp_dec_pcount_explicit(&tp->packets_out, > + new_factor - old_factor); That should be tcp_inc_pcount_explicit. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon Sep 13 21:55:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 21:56:01 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E4tsYi026551 for ; Mon, 13 Sep 2004 21:55:56 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C75Jv-0006Pv-00; Mon, 13 Sep 2004 21:53:35 -0700 Date: Mon, 13 Sep 2004 21:53:35 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-mm5: TCP oopses Message-Id: <20040913215335.64508d55.davem@davemloft.net> In-Reply-To: References: <20040913190858.12544431.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 900 Lines: 25 On Tue, 14 Sep 2004 13:34:20 +1000 Herbert Xu wrote: > > @@ -968,11 +972,17 @@ > > return -EAGAIN; > > > > if (skb->len > cur_mss) { > > + int old_factor = TCP_SKB_CB(skb)->tso_factor; > > + int new_factor; > > + > > if (tcp_fragment(sk, skb, cur_mss)) > > return -ENOMEM; /* We'll try again later. */ > > > > /* New SKB created, account for it. */ > > - tcp_inc_pcount(&tp->packets_out, skb); > > + new_factor = TCP_SKB_CB(skb)->tso_factor; > > + tcp_dec_pcount_explicit(&tp->packets_out, > > + new_factor - old_factor); > > That should be tcp_inc_pcount_explicit. Better fix is to transpose the factors in the subtraction. That's what I was trying to do here. Good eyes Herbert. From davem@davemloft.net Mon Sep 13 21:58:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 21:58:19 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E4wE2P026809 for ; Mon, 13 Sep 2004 21:58:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C75MD-0006QM-00; Mon, 13 Sep 2004 21:55:57 -0700 Date: Mon, 13 Sep 2004 21:55:56 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-mm5: TCP oopses Message-Id: <20040913215556.73026adf.davem@davemloft.net> In-Reply-To: References: <20040913190858.12544431.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 504 Lines: 17 James, does this make your problem go away? Thanks for testing. ===== net/ipv4/tcp_output.c 1.57 vs edited ===== --- 1.57/net/ipv4/tcp_output.c 2004-09-12 16:17:23 -07:00 +++ edited/net/ipv4/tcp_output.c 2004-09-13 21:36:59 -07:00 @@ -991,7 +991,7 @@ /* New SKB created, account for it. */ new_factor = TCP_SKB_CB(skb)->tso_factor; tcp_dec_pcount_explicit(&tp->packets_out, - new_factor - old_factor); + old_factor - new_factor); tcp_inc_pcount(&tp->packets_out, skb->next); } From jmorris@redhat.com Mon Sep 13 22:07:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 22:07:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E57oN4027397 for ; Mon, 13 Sep 2004 22:07:51 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8E57Uqj004541; Tue, 14 Sep 2004 01:07:30 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8E57Tr14424; Tue, 14 Sep 2004 01:07:29 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8E57TiS028175; Tue, 14 Sep 2004 01:07:29 -0400 Date: Tue, 14 Sep 2004 01:07:29 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: "David S. Miller" cc: Herbert Xu , , , Subject: Re: 2.6.9-rc1-mm5: TCP oopses In-Reply-To: <20040913215556.73026adf.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 157 Lines: 13 On Mon, 13 Sep 2004, David S. Miller wrote: > James, does this make your problem go away? Looks like it. - James -- James Morris From vkondra@mail.ru Mon Sep 13 22:20:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 22:20:23 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E5KGo5028010 for ; Mon, 13 Sep 2004 22:20:17 -0700 Received: from [81.218.113.45] (port=21860 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C75jY-000IoD-00; Tue, 14 Sep 2004 09:20:06 +0400 From: Vladimir Kondratiev To: "David S. Miller" Subject: Re: generic 802.11 stack Date: Tue, 14 Sep 2004 08:14:56 +0300 User-Agent: KMail/1.7 Cc: Jeff Garzik , greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> In-Reply-To: <20040913162153.33ff37ec.davem@davemloft.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1268174.vxxpaq9IDg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409140819.25787.vkondra@mail.ru> X-Spam: Not detected X-archive-position: 8770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1053 Lines: 34 --nextPart1268174.vxxpaq9IDg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 14 September 2004 02:21, David S. Miller wrote: DS> On Mon, 13 Sep 2004 01:50:39 -0400 DS> Jeff Garzik wrote: DS> DS> > You are the one doing the work. Which would you prefer? :) DS> > DS> > You could always send patches to netdev@oss.sgi.com and CC DS> > jgarzik@pobox.com and davem@davemloft.net. DaveM could review, and I DS> > could apply to wireless-2.6, then post a snapshot on kernel.org. DS> DS> That works for me. =46ine. Let it be this way. It may take for me some time till I can sumbit= =20 something, I want that it will kind of work with minimum functionality. --nextPart1268174.vxxpaq9IDg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBRn9dqxdj7mhC6o0RAmPRAJ48cONKGVXrZDOCb8pzXvZbrGy4EQCfbhX4 NCaUxl2t+vVjgyTvqLK5WWc= =9TUH -----END PGP SIGNATURE----- --nextPart1268174.vxxpaq9IDg-- From davem@davemloft.net Mon Sep 13 22:37:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 22:37:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E5bJJF028630 for ; Mon, 13 Sep 2004 22:37:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C75y1-0006ka-00; Mon, 13 Sep 2004 22:35:01 -0700 Date: Mon, 13 Sep 2004 22:35:00 -0700 From: "David S. Miller" To: Vladimir Kondratiev Cc: jgarzik@pobox.com, greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-Id: <20040913223500.66c06cde.davem@davemloft.net> In-Reply-To: <200409140819.25787.vkondra@mail.ru> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 260 Lines: 8 On Tue, 14 Sep 2004 08:14:56 +0300 Vladimir Kondratiev wrote: > Fine. Let it be this way. It may take for me some time till I can sumbit > something, I want that it will kind of work with minimum functionality. Ok, good luck Vladimir :-) From davem@davemloft.net Mon Sep 13 22:44:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 13 Sep 2004 22:44:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E5iZ5J029194 for ; Mon, 13 Sep 2004 22:44:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C765J-0006lK-00; Mon, 13 Sep 2004 22:42:33 -0700 Date: Mon, 13 Sep 2004 22:42:32 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: lkml@einar-lueck.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL) Message-Id: <20040913224232.4b979c7d.davem@davemloft.net> In-Reply-To: <1095129624.1060.45.camel@jzny.localdomain> References: <41457848.6040808@de.ibm.com> <1095129624.1060.45.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 794 Lines: 18 On 13 Sep 2004 22:40:24 -0400 jamal wrote: > As long as whatever arrangement ensures that no packet reordering > happens, should be sane. Yes, current scheme is broken in some ways (but > guarantees packet ordering within a flow). I think his changes ensure this as well, at least for local system sockets. You'll only get a new hop each time a route lookup is performed, which is only done once per socket unless the path becomes "sick" and TCP decides to try and do a relookup of the destination. I'm kind of ambivalent about these changes. I definitely like the first patch which cleans up those huge functions in route.c :-) But there are things I like about the current behavior, although I understand why people want things to work the way Einar is changing it to. From laforge@netfilter.org Tue Sep 14 00:12:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 00:13:07 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E7Ct10031582 for ; Tue, 14 Sep 2004 00:12:56 -0700 Received: from dsl-082-082-095-094.arcor-ip.net ([82.82.95.94] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C77Ua-0002eq-AD; Tue, 14 Sep 2004 09:12:44 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C77UX-0007QN-KY; Tue, 14 Sep 2004 09:12:41 +0200 Date: Tue, 14 Sep 2004 09:12:41 +0200 From: Harald Welte To: "David S. Miller" Cc: Julian Anastasov , netdev@oss.sgi.com, rusty@rustcorp.com.au Subject: Re: [PATCH 2.6] ip_nat_ftp - manip at the right place Message-ID: <20040914071241.GM8434@sunbeam.de.gnumonks.org> References: <20040912170323.65eadc38.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L1EIGrW/+75u5Nmw" Content-Disposition: inline In-Reply-To: <20040912170323.65eadc38.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1927 Lines: 57 --L1EIGrW/+75u5Nmw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2004 at 05:03:23PM -0700, David S. Miller wrote: > On Sat, 11 Sep 2004 10:53:53 +0300 (EEST) > Julian Anastasov wrote: >=20 > > This is a resend/resync for v2.6.9-rc1-bk17: change the > > way the ip_nat_ftp helper manipulates the packets: > >=20 > > - no manips =3D> no fixup > >=20 > > - check the direction, do manip once and at the same time when the > > headers are changed > >=20 > > This is needed mostly for IPVS setups and I hope we do not > > create troubles for other setups or FTP software. > >=20 > > Signed-off-by: Julian Anastasov >=20 > Harald and/or Rusty, please ACK/NACK this for me. I agree with the change (although I didn't test it here on my systems so far). However, as indicated in private mail to Julian, the change should be made consistent over all helpers. So please hold back the patch until I get back to you, thanks. > Thanks. --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --L1EIGrW/+75u5Nmw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBRpnpXaXGVTD0i/8RAiB9AJ4kgujUlqVuxTEXmBWUc9p7CSm5QACfedCu O2ACl+oHH+dPTEqxI+qLDfU= =lYlI -----END PGP SIGNATURE----- --L1EIGrW/+75u5Nmw-- From ltd@cisco.com Tue Sep 14 02:00:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 02:00:54 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8E90mC3005372 for ; Tue, 14 Sep 2004 02:00:49 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2004 02:02:45 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8E90SLt006911; Tue, 14 Sep 2004 02:00:32 -0700 (PDT) Received: from ltd-t30.cisco.com (syd-vpn-client-254-12.cisco.com [10.66.254.12]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXC07165; Tue, 14 Sep 2004 01:47:10 -0700 (PDT) Message-Id: <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> X-Sender: ltd@171.71.163.14 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Sep 2004 18:48:20 +1000 To: "David S. Miller" From: Lincoln Dale Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Cc: Paul P Komkoff Jr , i@stingr.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040913161912.7dcc809f.davem@davemloft.net> References: <20040913051706.GB26337@stingr.sgu.ru> <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> <20040913051706.GB26337@stingr.sgu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltd@cisco.com Precedence: bulk X-list: netdev Content-Length: 800 Lines: 22 At 09:19 AM 14/09/2004, David S. Miller wrote: > > As you can see, I am applying it unconditionally when fits. For most > > cases, this will be OK. > > There can be situations when this is not wanted (for example, when > > debugging something), so in general, tuning knob will be useful, but > > I just don't know where to add it, maybe tunnel->parms.i_flags ... > >I don't think adding such a knob is necessary, but yes i_flags >would be the place to do it. > >I will apply your patch with the "if(1)" simply removed. the logic is correct, but it may make sense to call the appropriate netfilter hook again with the "unwrapped" GRE packet, as otherwise packets-inside-GRE represent a possible security hole where one can inject packets externally and bypass firewall rules. cheers, lincoln. From hadi@cyberus.ca Tue Sep 14 05:14:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 05:15:05 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ECEv9N014715 for ; Tue, 14 Sep 2004 05:14:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C7CCq-0006l8-EE for netdev@oss.sgi.com; Tue, 14 Sep 2004 08:14:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7CCo-00083c-Hj; Tue, 14 Sep 2004 08:14:43 -0400 Subject: Re: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL) From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: lkml@einar-lueck.de, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040913224232.4b979c7d.davem@davemloft.net> References: <41457848.6040808@de.ibm.com> <1095129624.1060.45.camel@jzny.localdomain> <20040913224232.4b979c7d.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095164075.1060.100.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Sep 2004 08:14:35 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1628 Lines: 43 On Tue, 2004-09-14 at 01:42, David S. Miller wrote: > On 13 Sep 2004 22:40:24 -0400 > jamal wrote: > > > As long as whatever arrangement ensures that no packet reordering > > happens, should be sane. Yes, current scheme is broken in some ways (but > > guarantees packet ordering within a flow). > > I think his changes ensure this as well, at least for local system > sockets. You'll only get a new hop each time a route lookup is > performed, which is only done once per socket unless the path > becomes "sick" and TCP decides to try and do a relookup of the > destination. I was worried more about forwarding path. > I'm kind of ambivalent about these changes. I definitely like the > first patch which cleans up those huge functions in route.c :-) Oh, yeah that looked good - thats why i didnt comment. Your call. > But there are things I like about the current behavior, although I > understand why people want things to work the way Einar is changing > it to. I think its a little broken but not unlike say CISCOs multipath when they have caching. The general trend though is that now multipathing is getting more interesting and the policy criteria is no longer loadbalancing alone. An example interesting paper and newer devices showing up: "Experiences in Building A Multihoming Load Balancing System" by Fanglu Guo, Jiawu Chen , Wei Li, Tzi-Cker Chiueh (State University of New York at Stony Brook url: http://www.ieee-infocom.org/2004/technicalprogram.htm The idea proposed there is extensible to many other policy selections (very easily implementable via tc actions). cheers, jamal From herbert@gondor.apana.org.au Tue Sep 14 05:17:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 05:17:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ECGuY9014933 for ; Tue, 14 Sep 2004 05:16:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7CET-0001mI-00; Tue, 14 Sep 2004 22:16:25 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7CEL-0001V4-00; Tue, 14 Sep 2004 22:16:17 +1000 Date: Tue, 14 Sep 2004 22:16:17 +1000 To: "David S. Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: [INET] Add flags field to ip_tunnel_parm Message-ID: <20040914121617.GA5652@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 8165 Lines: 293 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch adds a new flags field to struct ip_tunnel_parm. The reason is that one of its users, ip_gre cannot place any new flags in the existing fields. i_flags is unuseable for GRE because any future GRE extension may use one of those bits. Of course we'll need new flags to implement the DSCP options as we did for ip6_tunnel. Signed-off-by: Herbert Xu BTW if anyone else wants to add more fields to the structure, now is the time. Another thing, the iptnl_* functions turn out to be fairly big. So I'd like to uninline them. Unfortunately I can't think of a good place to put them. Should I: 1) Put it into ipip.c and make the others depend on it. 2) Put it into xfrm4_tunnel.c and make the others depend on it. 3) Put it into some other file in net/ipv4 that's always built in. 4) Create a new module just for this (and any other shared code between them). 5) Replace inline with __attribute__ ((__unused__)). 6) Stop thinking about this and do something useful :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- /dev/null 2004-08-18 20:24:57.000000000 +1000 +++ work-2.6/include/net/ip_tunnel.h 2004-09-14 21:56:46.000000000 +1000 @@ -0,0 +1,37 @@ +#ifndef _NET_IP_TUNNEL_H +#define _NET_IP_TUNNEL_H + +#include + +struct ip_tunnel_parm_v1 +{ + char name[IFNAMSIZ]; + int link; + __u16 i_flags; + __u16 o_flags; + __u32 i_key; + __u32 o_key; + struct iphdr iph; +}; + +static inline int iptnl_get_user_parms(struct ip_tunnel_parm *p, + const void __user *up) +{ + if (!copy_from_user(p, up, sizeof(*p))) + return 0; + + memset(p, 0, sizeof(*p)); + return copy_from_user(p, up, sizeof(struct ip_tunnel_parm_v1)) ? + -EFAULT : 0; +} + +static inline int iptnl_put_user_parms(void __user *up, + const struct ip_tunnel_parm *p) +{ + if (copy_to_user(up, p, sizeof(*p)) && + copy_to_user(up, p, sizeof(struct ip_tunnel_parm_v1))) + return -EFAULT; + return 0; +} + +#endif ===== include/linux/if_tunnel.h 1.1 vs edited ===== --- 1.1/include/linux/if_tunnel.h 2002-02-06 04:39:42 +11:00 +++ edited/include/linux/if_tunnel.h 2004-09-14 21:26:20 +10:00 @@ -24,6 +24,7 @@ __u32 i_key; __u32 o_key; struct iphdr iph; + __u32 flags; }; #endif /* _IF_TUNNEL_H_ */ ===== net/ipv4/ip_gre.c 1.42 vs edited ===== --- 1.42/net/ipv4/ip_gre.c 2004-09-09 21:48:58 +10:00 +++ edited/net/ipv4/ip_gre.c 2004-09-14 21:36:21 +10:00 @@ -38,6 +38,7 @@ #include #include #include +#include #ifdef CONFIG_IPV6 #include @@ -896,17 +897,15 @@ case SIOCGETTUNNEL: t = NULL; if (dev == ipgre_fb_tunnel_dev) { - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) { - err = -EFAULT; + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) break; - } t = ipgre_tunnel_locate(&p, 0); } if (t == NULL) t = (struct ip_tunnel*)dev->priv; memcpy(&p, &t->parms, sizeof(p)); - if (copy_to_user(ifr->ifr_ifru.ifru_data, &p, sizeof(p))) - err = -EFAULT; + err = iptnl_put_user_parms(ifr->ifr_ifru.ifru_data, &p); break; case SIOCADDTUNNEL: @@ -915,8 +914,8 @@ if (!capable(CAP_NET_ADMIN)) goto done; - err = -EFAULT; - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) goto done; err = -EINVAL; @@ -973,8 +972,8 @@ t->parms.iph.tos = p.iph.tos; t->parms.iph.frag_off = p.iph.frag_off; } - if (copy_to_user(ifr->ifr_ifru.ifru_data, &t->parms, sizeof(p))) - err = -EFAULT; + err = iptnl_put_user_parms(ifr->ifr_ifru.ifru_data, + &t->parms); } else err = (cmd == SIOCADDTUNNEL ? -ENOBUFS : -ENOENT); break; @@ -985,8 +984,8 @@ goto done; if (dev == ipgre_fb_tunnel_dev) { - err = -EFAULT; - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) goto done; err = -ENOENT; if ((t = ipgre_tunnel_locate(&p, 0)) == NULL) ===== net/ipv4/ipip.c 1.44 vs edited ===== --- 1.44/net/ipv4/ipip.c 2004-09-09 21:48:58 +10:00 +++ edited/net/ipv4/ipip.c 2004-09-14 21:53:22 +10:00 @@ -116,6 +116,7 @@ #include #include #include +#include #define HASH_SIZE 16 #define HASH(addr) ((addr^(addr>>4))&0xF) @@ -667,17 +668,15 @@ case SIOCGETTUNNEL: t = NULL; if (dev == ipip_fb_tunnel_dev) { - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) { - err = -EFAULT; + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) break; - } t = ipip_tunnel_locate(&p, 0); } if (t == NULL) t = (struct ip_tunnel*)dev->priv; memcpy(&p, &t->parms, sizeof(p)); - if (copy_to_user(ifr->ifr_ifru.ifru_data, &p, sizeof(p))) - err = -EFAULT; + err = iptnl_put_user_parms(ifr->ifr_ifru.ifru_data, &p); break; case SIOCADDTUNNEL: @@ -686,8 +685,8 @@ if (!capable(CAP_NET_ADMIN)) goto done; - err = -EFAULT; - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) goto done; err = -EINVAL; @@ -729,8 +728,8 @@ t->parms.iph.tos = p.iph.tos; t->parms.iph.frag_off = p.iph.frag_off; } - if (copy_to_user(ifr->ifr_ifru.ifru_data, &t->parms, sizeof(p))) - err = -EFAULT; + err = iptnl_put_user_parms(ifr->ifr_ifru.ifru_data, + &t->parms); } else err = (cmd == SIOCADDTUNNEL ? -ENOBUFS : -ENOENT); break; @@ -741,8 +740,8 @@ goto done; if (dev == ipip_fb_tunnel_dev) { - err = -EFAULT; - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) goto done; err = -ENOENT; if ((t = ipip_tunnel_locate(&p, 0)) == NULL) ===== net/ipv6/sit.c 1.41 vs edited ===== --- 1.41/net/ipv6/sit.c 2004-09-09 21:48:58 +10:00 +++ edited/net/ipv6/sit.c 2004-09-14 21:37:36 +10:00 @@ -50,6 +50,7 @@ #include #include #include +#include /* This version of net/ipv6/sit.c is cloned of net/ipv4/ip_gre.c @@ -599,17 +600,15 @@ case SIOCGETTUNNEL: t = NULL; if (dev == ipip6_fb_tunnel_dev) { - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) { - err = -EFAULT; + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) break; - } t = ipip6_tunnel_locate(&p, 0); } if (t == NULL) t = (struct ip_tunnel*)dev->priv; memcpy(&p, &t->parms, sizeof(p)); - if (copy_to_user(ifr->ifr_ifru.ifru_data, &p, sizeof(p))) - err = -EFAULT; + err = iptnl_put_user_parms(ifr->ifr_ifru.ifru_data, &p); break; case SIOCADDTUNNEL: @@ -618,8 +617,8 @@ if (!capable(CAP_NET_ADMIN)) goto done; - err = -EFAULT; - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) goto done; err = -EINVAL; @@ -660,8 +659,8 @@ t->parms.iph.ttl = p.iph.ttl; t->parms.iph.tos = p.iph.tos; } - if (copy_to_user(ifr->ifr_ifru.ifru_data, &t->parms, sizeof(p))) - err = -EFAULT; + err = iptnl_put_user_parms(ifr->ifr_ifru.ifru_data, + &t->parms); } else err = (cmd == SIOCADDTUNNEL ? -ENOBUFS : -ENOENT); break; @@ -672,8 +671,8 @@ goto done; if (dev == ipip6_fb_tunnel_dev) { - err = -EFAULT; - if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p))) + err = iptnl_get_user_parms(&p, ifr->ifr_ifru.ifru_data); + if (err) goto done; err = -ENOENT; if ((t = ipip6_tunnel_locate(&p, 0)) == NULL) --d6Gm4EdcadzBjdND-- From i@stingr.net Tue Sep 14 05:40:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 05:40:26 -0700 (PDT) Received: from stingr.net (stingr.net [212.193.32.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ECe8F7015765 for ; Tue, 14 Sep 2004 05:40:19 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by stingr.net (Postfix) with ESMTP id EBADA42C3; Tue, 14 Sep 2004 16:39:52 +0400 (MSD) Received: from stingr.net ([127.0.0.1]) by localhost (stingr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13724-01-3; Tue, 14 Sep 2004 16:39:51 +0400 (MSD) Received: by stingr.net (Postfix, from userid 1000) id C5E3642C4; Tue, 14 Sep 2004 16:39:51 +0400 (MSD) Date: Tue, 14 Sep 2004 16:39:51 +0400 From: Paul P Komkoff Jr To: Lincoln Dale Cc: "David S. Miller" , Paul P Komkoff Jr , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-ID: <20040914123951.GL4141@stingr.sgu.ru> Mail-Followup-To: Lincoln Dale , "David S. Miller" , Paul P Komkoff Jr , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20040913051706.GB26337@stingr.sgu.ru> <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> <20040913051706.GB26337@stingr.sgu.ru> <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> User-Agent: Agent Darien Fawkes X-Mailer: Intel Ultra ATA Storage Driver X-RealName: Stingray Greatest Jr Organization: Department of Fish & Wildlife X-Virus-Scanned: by amavisd-new at stingr.net X-archive-position: 8777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: i@stingr.net Precedence: bulk X-list: netdev Content-Length: 592 Lines: 13 Replying to Lincoln Dale: > the logic is correct, but it may make sense to call the appropriate > netfilter hook again with the "unwrapped" GRE packet, as otherwise > packets-inside-GRE represent a possible security hole where one can inject > packets externally and bypass firewall rules. From what I observe, netfilter hooks *are* called for unwrapped packets. Either for usual IP packets passed from GRE tunnel, or for demangled wccp packets. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From elueck@de.ibm.com Tue Sep 14 05:40:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 05:40:34 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.29.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ECeOD1015766 for ; Tue, 14 Sep 2004 05:40:25 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8ECcrfQ152122; Tue, 14 Sep 2004 12:38:54 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ECcqnG112288; Tue, 14 Sep 2004 14:38:53 +0200 Message-ID: <4146E65D.6070309@de.ibm.com> Date: Tue, 14 Sep 2004 14:38:53 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: hadi@cyberus.ca, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL) References: <41457848.6040808@de.ibm.com> <1095129624.1060.45.camel@jzny.localdomain> <20040913224232.4b979c7d.davem@davemloft.net> In-Reply-To: <20040913224232.4b979c7d.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------020102000800030904040805" X-archive-position: 8778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 21634 Lines: 760 This is a multi-part message in MIME format. --------------020102000800030904040805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I attached the patch the way you requested in the other thread. Regards Einar --------------020102000800030904040805 Content-Type: text/x-patch; name="multipath_cached.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="multipath_cached.diff" diff -ruN linux-2.6.8.1.splitold/include/net/dst.h linux-2.6.8.1.multipath_cached/include/net/dst.h --- linux-2.6.8.1.splitold/include/net/dst.h 2004-09-10 10:24:40.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/include/net/dst.h 2004-09-10 11:16:35.000000000 +0200 @@ -48,6 +48,7 @@ #define DST_NOXFRM 2 #define DST_NOPOLICY 4 #define DST_NOHASH 8 +#define DST_BALANCED 0x10 unsigned long lastuse; unsigned long expires; diff -ruN linux-2.6.8.1.splitold/include/net/flow.h linux-2.6.8.1.multipath_cached/include/net/flow.h --- linux-2.6.8.1.splitold/include/net/flow.h 2004-09-10 10:24:40.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/include/net/flow.h 2004-09-10 11:16:35.000000000 +0200 @@ -51,6 +51,9 @@ __u8 proto; __u8 flags; +#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) +#define FLOWI_FLAG_MULTIPATHOLDROUTE 0x01 +#endif union { struct { __u16 sport; diff -ruN linux-2.6.8.1.splitold/include/net/route.h linux-2.6.8.1.multipath_cached/include/net/route.h --- linux-2.6.8.1.splitold/include/net/route.h 2004-09-10 10:24:40.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/include/net/route.h 2004-09-10 11:16:35.000000000 +0200 @@ -179,6 +179,9 @@ memcpy(&fl, &(*rp)->fl, sizeof(fl)); fl.fl_ip_sport = sport; fl.fl_ip_dport = dport; +#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) + fl.flags |= FLOWI_FLAG_MULTIPATHOLDROUTE; +#endif ip_rt_put(*rp); *rp = NULL; return ip_route_output_flow(rp, &fl, sk, 0); @@ -197,4 +200,41 @@ return rt->peer; } + +#ifdef CONFIG_IP_ROUTE_MULTIPATH_RR +extern void __multipath_remove(struct rtable *rt); +static inline void multipath_remove(struct rtable *rt) { + if ( rt->u.dst.flags & DST_BALANCED ) { + __multipath_remove( rt ); + } +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_RR */ +static inline void multipath_remove(struct rtable *rt) {} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_RR */ + + +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED +extern void __multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp); +static inline int multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp) { + if ( rth->u.dst.flags & DST_BALANCED ) { + __multipath_selectroute( flp, rth, rp ); + return 1; + } + else { + return 0; + } +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ +static inline int multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp) { + return 0; +} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ + + #endif /* _ROUTE_H */ diff -ruN linux-2.6.8.1.splitold/net/ipv4/Kconfig linux-2.6.8.1.multipath_cached/net/ipv4/Kconfig --- linux-2.6.8.1.splitold/net/ipv4/Kconfig 2004-09-10 10:25:08.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/net/ipv4/Kconfig 2004-09-10 11:16:35.000000000 +0200 @@ -94,6 +94,41 @@ equal "cost" and chooses one of them in a non-deterministic fashion if a matching packet arrives. +config IP_ROUTE_MULTIPATH_CACHED + bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" + depends on: IP_ROUTE_MULTIPATH + help + Normally, equal cost multipath routing is not supported by the + routing cache. If you say Y here, alternative routes are cached + in the routing cache and on cache lookup route is chosen in + Round Robin fashon. + + If unsure, say N. + +# +# multipath policy configuration +# +choice + prompt "Multipath policy" + depends on IP_ROUTE_MULTIPATH_CACHED + default IP_ROUTE_MULTIPATH_RR + +config IP_ROUTE_MULTIPATH_RR + bool "round robin (EXPERIMENTAL)" + help + Mulitpath routes are chosen according to Round Robin + +config IP_ROUTE_MULTIPATH_RANDOM + bool "random multipath (EXPERIMENTAL)" + help + Multipath routes are chosen in a random fashion (naive + implementation) + +endchoice +# +# END OF multipath policy configuration +# + config IP_ROUTE_TOS bool "IP: use TOS value as routing key" depends on IP_ADVANCED_ROUTER diff -ruN linux-2.6.8.1.splitold/net/ipv4/Makefile linux-2.6.8.1.multipath_cached/net/ipv4/Makefile --- linux-2.6.8.1.splitold/net/ipv4/Makefile 2004-09-10 10:25:08.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/net/ipv4/Makefile 2004-09-10 11:16:35.000000000 +0200 @@ -21,6 +21,8 @@ obj-$(CONFIG_INET_IPCOMP) += ipcomp.o obj-$(CONFIG_INET_TUNNEL) += xfrm4_tunnel.o obj-$(CONFIG_IP_PNP) += ipconfig.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RR) += multipath_rr.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RANDOM) += multipath_random.o obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ diff -ruN linux-2.6.8.1.splitold/net/ipv4/multipath_random.c linux-2.6.8.1.multipath_cached/net/ipv4/multipath_random.c --- linux-2.6.8.1.splitold/net/ipv4/multipath_random.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath_cached/net/ipv4/multipath_random.c 2004-09-13 16:45:48.000000000 +0200 @@ -0,0 +1,107 @@ +/* + * Random policy for multipath. + * + * + * Version: $Id: multipath.c,v 1.1.2.1 2004/09/02 20:01:27 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RTprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_MAX_CANDIDATES 40 + + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, + struct rtable **rp) { + struct rtable *rt; + struct rtable *candidate[MULTIPATH_MAX_CANDIDATES]; + struct rtable *decision; + unsigned char candidate_count = 0; + /* FIXME: remove debug code */ + RTprint( KERN_DEBUG"%s called\n", __FUNCTION__ ); + + /* collect all candidate */ + for (rt = rcu_dereference(first); rt; + rt = rcu_dereference(rt->u.rt_next)) { + if ( ( rt->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&rt->fl, flp) ) { + candidate[candidate_count] = rt; + ++candidate_count; + } + if ( candidate_count >= MULTIPATH_MAX_CANDIDATES ) { + break; + } + } + + /* choose a random candidate */ + decision = candidate[0]; + if ( candidate_count > 1 ) { + unsigned char i; + unsigned char candidate_no = net_random() % candidate_count; + decision = candidate[candidate_no]; + + /* make sure all candidates stay in cache */ + for ( i = 0; i < candidate_count; ++i ) { + candidate[i]->u.dst.lastuse = jiffies; + } + } + + decision->u.dst.__use++; + *rp = decision; +} + + + diff -ruN linux-2.6.8.1.splitold/net/ipv4/multipath_rr.c linux-2.6.8.1.multipath_cached/net/ipv4/multipath_rr.c --- linux-2.6.8.1.splitold/net/ipv4/multipath_rr.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath_cached/net/ipv4/multipath_rr.c 2004-09-10 11:16:35.000000000 +0200 @@ -0,0 +1,202 @@ +/* + * Round robin policy for multipath. + * + * + * Version: $Id: multipath.c,v 1.1.2.1 2004/09/02 20:01:27 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct rt_cache_candidate +{ + struct rtable *candidate; + struct rt_cache_candidate *next; +}; + +#define RTprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_MAX_CANDIDATES 40 + +static spinlock_t multipath_state_lock = SPIN_LOCK_UNLOCKED; +static struct rt_cache_candidate *multipath_state = NULL; +static int multipath_state_entrycount = 0;/* FIXME remove: is just for debug purposes */ + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +void __multipath_remove(struct rtable* rt) { + struct rt_cache_candidate *candidate; + struct rt_cache_candidate *previous = NULL; + + /* DEBUG STUFF */ + if ( !( rt->u.dst.flags & DST_BALANCED ) ) { + /* FIXME: remove debug code */ + RTprint( KERN_DEBUG"%s: unexpected argument\n", + __FUNCTION__ ); + return; + } + + spin_lock_bh(&multipath_state_lock); + + for ( candidate = multipath_state; candidate != NULL; + candidate = candidate->next ) { + if ( multipath_comparekeys(&candidate->candidate->fl, + &rt->fl) ) { + if ( candidate == multipath_state ) { + multipath_state = multipath_state->next; + } + else { + previous->next = candidate->next; + } + --multipath_state_entrycount; + kfree( candidate ); + RTprint( KERN_DEBUG"%s: removed entry. Entry " \ + "count: %d\n", __FUNCTION__, + multipath_state_entrycount ); + break; + } + + previous = candidate; + } + + spin_unlock_bh(&multipath_state_lock); +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, struct rtable **rp) +{ + struct rt_cache_candidate *cand; + struct rtable *nh, *result; + int found_old = 0; + + spin_lock_bh(&multipath_state_lock); + + /* determine entry with candidate returned last time */ + for ( cand = multipath_state; cand != NULL; cand = cand->next ) { + if ( multipath_comparekeys(&cand->candidate->fl, flp) ) { + + RTprint( KERN_CRIT"%s: determined candidate " \ + "returned last time\n", + __FUNCTION__ ); + break; + } + } + + + /* 1. make sure all alt. nexthops have the same GC related data */ + /* 2. determine the new candidate to be returned */ + result = NULL; + for (nh = rcu_dereference(first); nh; + nh = rcu_dereference(nh->u.rt_next)) { + if ( ( nh->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&nh->fl, flp ) ) { + nh->u.dst.lastuse = jiffies; + nh->u.dst.__use++; + RTprint( KERN_CRIT"%s: found balanced entry\n", + __FUNCTION__ ); + + /* determine candidate to be returned */ + if ( !(flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) ) { + if ( found_old && !result ) { + result = nh; + } + else if ( cand != NULL && + nh == cand->candidate ) { + found_old = 1; + } + } + } + } + + /* if no previous alternative exists utilize first */ + if ( result == NULL ) { + RTprint( KERN_CRIT"%s: reach end of"\ + " chain. Start again.\n", + __FUNCTION__ ); + + result = first; + } + else { + RTprint( KERN_CRIT"%s: found new " \ + "candidate\n", + __FUNCTION__ ); + } + + + /* if necessary and possible utilize the old alternative */ + if ( ( flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) != 0 && + cand != NULL ) { + RTprint( KERN_CRIT"%s: holding route \n", + __FUNCTION__ ); + result = cand->candidate; + } + + + /* store candidate to return in state */ + if ( cand == NULL ) { + /* create new state entry if necessary */ + cand = (struct rt_cachec_andidate*) + kmalloc( sizeof(struct rt_cache_candidate), + GFP_KERNEL ); + cand->next = multipath_state; + multipath_state = cand; + ++multipath_state_entrycount; + RTprint( KERN_CRIT"%s: entrycount: %d\n", + __FUNCTION__, multipath_state_entrycount ); + } + cand->candidate = result; + + spin_unlock_bh(&multipath_state_lock); + + *rp = result; +} + + diff -ruN linux-2.6.8.1.splitold/net/ipv4/route.c linux-2.6.8.1.multipath_cached/net/ipv4/route.c --- linux-2.6.8.1.splitold/net/ipv4/route.c 2004-09-14 09:38:49.000000000 +0200 +++ linux-2.6.8.1.multipath_cached/net/ipv4/route.c 2004-09-14 09:36:52.000000000 +0200 @@ -442,11 +442,13 @@ static __inline__ void rt_free(struct rtable *rt) { + multipath_remove(rt); call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free); } static __inline__ void rt_drop(struct rtable *rt) { + multipath_remove(rt); ip_rt_put(rt); call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free); } @@ -539,8 +541,28 @@ } /* Cleanup aged off entries. */ +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + /* remove all related balanced entries if necessary */ + if ( rth->u.dst.flags & DST_BALANCED ) { + struct rtable* first = rth; + *rthp = rth->u.rt_next; + while ( (*rthp)->u.dst.flags & DST_BALANCED && + compare_keys(&(*rthp)->fl, + &first->fl)) { + rth = (*rthp); + *rthp = rth->u.rt_next; + rt_free( rth ); + } + rt_free(first); + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ *rthp = rth->u.rt_next; rt_free(rth); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } spin_unlock(&rt_hash_table[i].lock); @@ -706,8 +728,28 @@ rthp = &rth->u.rt_next; continue; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + /* remove all related balanced entries if necessary */ + if ( rth->u.dst.flags & DST_BALANCED ) { + struct rtable* first = rth; + *rthp = rth->u.rt_next; + while ( (*rthp)->u.dst.flags & DST_BALANCED && + compare_keys(&(*rthp)->fl, + &first->fl)) { + rth = (*rthp); + *rthp = rth->u.rt_next; + rt_free( rth ); + } + rt_free(first); + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ *rthp = rth->u.rt_next; rt_free(rth); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ goal--; } spin_unlock_bh(&rt_hash_table[k].lock); @@ -789,7 +831,12 @@ spin_lock_bh(&rt_hash_table[hash].lock); while ((rth = *rthp) != NULL) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if (!(rth->u.dst.flags & DST_BALANCED) && + compare_keys(&rth->fl, &rt->fl)) { +#else if (compare_keys(&rth->fl, &rt->fl)) { +#endif /* Put it first */ *rthp = rth->u.rt_next; /* @@ -1622,7 +1669,18 @@ goto cleanup; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if ( res->fi->fib_nhs > 1 ) + RTprint( KERN_DEBUG"%s: balanced entry created: %d\n", + __FUNCTION__, + rth ); +#endif + rth->u.dst.flags= DST_HOST; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if ( res->fi->fib_nhs > 1 ) + rth->u.dst.flags |= DST_BALANCED; +#endif if (in_dev->cnf.no_policy) rth->u.dst.flags |= DST_NOPOLICY; if (in_dev->cnf.no_xfrm) @@ -1691,7 +1749,54 @@ struct in_device *in_dev, u32 daddr, u32 saddr, u32 tos) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + struct rtable* rth; + unsigned char hop, hopcount, lasthop; + int err = -EINVAL; + unsigned hash; + hopcount = res->fi->fib_nhs; + lasthop = hopcount - 1; + + /* distinguish between multipath and singlepath */ + if ( hopcount < 2 ) + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, + saddr, tos); + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", __FUNCTION__, + hopcount); + + /* add all alternatives to the routing cache */ + for ( hop = 0; hop < hopcount; ++hop ) { + res->nh_sel = hop; + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", + __FUNCTION__, hopcount); + + /* create a routing cache entry */ + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, + &rth ); + if ( err ) + return err; + + + /* put it into the cache */ + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + if ( err ) + return err; + + + /* only for the last hop the reference count is handled + outside */ + RTprint( KERN_DEBUG"%s: balanced entry created: %d\n", + __FUNCTION__, rth ); + if ( hop == lasthop ) + atomic_set(&(skb->dst->__refcnt), 1); + } + return err; +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); +#endif } @@ -1882,6 +1987,7 @@ goto done; martian_source: + ip_handle_martian_source(dev, in_dev, skb, daddr, saddr); goto e_inval; } @@ -1907,6 +2013,17 @@ rth->fl.fl4_fwmark == skb->nfmark && #endif rth->fl.fl4_tos == tos) { + /* check if the route is a multipath route and if so + select one of the alternatives */ + if ( multipath_selectroute( + &rth->fl, rth, + (struct rtable**)&skb->dst) ) { + dst_hold(skb->dst); + rcu_read_unlock(); + + return 0; + } + rth->u.dst.lastuse = jiffies; dst_hold(&rth->u.dst); rth->u.dst.__use++; @@ -2012,6 +2129,10 @@ } rth->u.dst.flags= DST_HOST; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if (res->fi->fib_nhs > 1) + rth->u.dst.flags |= DST_BALANCED; +#endif if (in_dev->cnf.no_xfrm) rth->u.dst.flags |= DST_NOXFRM; if (in_dev->cnf.no_policy) @@ -2103,7 +2224,71 @@ struct net_device *dev_out, unsigned flags) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + u32 tos = RT_FL_TOS(oldflp); + unsigned char hop; + unsigned hash; + int err = -EINVAL; + unsigned char hopcount = res->fi->fib_nhs; + struct rtable* rth; + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d, fl->oif: %d)\n", + __FUNCTION__, hopcount, fl->oif); + + if (res->fi->fib_nhs > 1) { + for ( hop = 0; hop < hopcount; ++hop ) { + struct net_device *dev2nexthop; + RTprint( KERN_DEBUG"%s: hop %d of %d\n", __FUNCTION__, + hop, hopcount ); + + res->nh_sel = hop; + + /* hold a work reference to the output device */ + dev2nexthop = FIB_RES_DEV(*res); + dev_hold(dev2nexthop); + + /** FIXME remove debug code */ + RTprint( KERN_DEBUG"%s: balanced entry created: %d " \ + " (GW: %u)\n", + __FUNCTION__, + rth, + FIB_RES_GW(*res) ); + + err = __mkroute_output(&rth, res, fl, oldflp, + dev2nexthop, flags); + if ( err != 0 ) { + goto cleanup; + } + + RTprint( KERN_DEBUG"%s: created successfully %d\n", + __FUNCTION__, hop ); + + hash = rt_hash_code(oldflp->fl4_dst, + oldflp->fl4_src ^ + (oldflp->oif << 5), tos); + err = rt_intern_hash(hash, rth, rp); + RTprint( KERN_DEBUG"%s: hashed %d\n", + __FUNCTION__, hop ); + + cleanup: + /* release work reference to output device */ + dev_put(dev2nexthop); + + if ( err != 0 ) { + return err; + } + } + RTprint( KERN_DEBUG"%s: exited loop\n", __FUNCTION__ ); + atomic_set(&(*rp)->u.dst.__refcnt, 1); + return err; + } + else { + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, + flags); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } /* @@ -2316,6 +2501,16 @@ #endif !((rth->fl.fl4_tos ^ flp->fl4_tos) & (IPTOS_RT_MASK | RTO_ONLINK))) { + + /* check for multipath routes and choose one if + necessary */ + if (multipath_selectroute(flp, rth, rp)) { + dst_hold(&(*rp)->u.dst); + RT_CACHE_STAT_INC(out_hit); + rcu_read_unlock_bh(); + return 0; + } + rth->u.dst.lastuse = jiffies; dst_hold(&rth->u.dst); rth->u.dst.__use++; --------------020102000800030904040805-- From elueck@de.ibm.com Tue Sep 14 05:41:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 05:41:24 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ECfHLC016143 for ; Tue, 14 Sep 2004 05:41:18 -0700 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8ECeULi142868; Tue, 14 Sep 2004 12:40:30 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ECeTHA206044; Tue, 14 Sep 2004 14:40:30 +0200 Message-ID: <4146E6BE.9000207@de.ibm.com> Date: Tue, 14 Sep 2004 14:40:30 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 1/2] ip routing - split of ip_route_[in|out]put_slow References: <4145782A.4040107@de.ibm.com> <20040913162322.51c18535.davem@davemloft.net> In-Reply-To: <20040913162322.51c18535.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------080306080307080004070007" X-archive-position: 8779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 17044 Lines: 670 This is a multi-part message in MIME format. --------------080306080307080004070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I attached the patch in the way you requested it! Regards Einar. David S. Miller wrote: >Please resubmit your patches without clobbering the patch contents >with your email client, for one thing it turns tabs into spaces. >Probably best to use attachments. > >Thanks. > > > > --------------080306080307080004070007 Content-Type: text/x-patch; name="routingsplit.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="routingsplit.diff" diff -ruN linux-2.6.8.1/net/ipv4/route.c linux-2.6.8.1.split/net/ipv4/route.c --- linux-2.6.8.1/net/ipv4/route.c 2004-09-10 10:24:12.000000000 +0200 +++ linux-2.6.8.1.split/net/ipv4/route.c 2004-09-14 09:38:49.000000000 +0200 @@ -104,6 +104,9 @@ #include #endif +#define RT_FL_TOS(oldflp) \ + ((u32)(oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK))) + #define IP_MAX_MTU 0xFFF0 #define RT_GC_TIMEOUT (300*HZ) @@ -143,6 +146,7 @@ static void ipv4_link_failure(struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu); static int rt_garbage_collect(void); +static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); static struct dst_ops ipv4_dst_ops = { @@ -1528,6 +1532,169 @@ return -EINVAL; } + +static void ip_handle_martian_source(struct net_device *dev, + struct in_device *in_dev, + struct sk_buff *skb, + u32 daddr, + u32 saddr) +{ + RT_CACHE_STAT_INC(in_martian_src); +#ifdef CONFIG_IP_ROUTE_VERBOSE + if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { + /* + * RFC1812 recommendation, if source is martian, + * the only hint is MAC header. + */ + printk(KERN_WARNING "martian source %u.%u.%u.%u from " + "%u.%u.%u.%u, on dev %s\n", + NIPQUAD(daddr), NIPQUAD(saddr), dev->name); + if (dev->hard_header_len) { + int i; + unsigned char *p = skb->mac.raw; + printk(KERN_WARNING "ll header: "); + for (i = 0; i < dev->hard_header_len; i++, p++) { + printk("%02x", *p); + if (i < (dev->hard_header_len - 1)) + printk(":"); + } + printk("\n"); + } + } +#endif +} + +static inline int __mkroute_input(struct sk_buff *skb, + struct fib_result* res, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos, + struct rtable **result) +{ + + struct rtable *rth; + int err; + struct in_device *out_dev; + unsigned flags = 0; + u32 spec_dst, itag; + + /* get a working reference to the output device */ + out_dev = in_dev_get(FIB_RES_DEV(*res)); + if (out_dev == NULL) { + if (net_ratelimit()) + printk(KERN_CRIT "Bug in ip_route_input" \ + "_slow(). Please, report\n"); + return -EINVAL; + } + + + err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(*res), + in_dev->dev, &spec_dst, &itag); + if (err < 0) { + ip_handle_martian_source(in_dev->dev, in_dev, skb, daddr, + saddr); + + err = -EINVAL; + goto cleanup; + } + + if (err) + flags |= RTCF_DIRECTSRC; + + if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && + (IN_DEV_SHARED_MEDIA(out_dev) || + inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) + flags |= RTCF_DOREDIRECT; + + if (skb->protocol != htons(ETH_P_IP)) { + /* Not IP (i.e. ARP). Do not create route, if it is + * invalid for proxy arp. DNAT routes are always valid. + */ + if (out_dev == in_dev && !(flags & RTCF_DNAT)) { + err = -EINVAL; + goto cleanup; + } + } + + + rth = dst_alloc(&ipv4_dst_ops); + if (!rth) { + err = -ENOBUFS; + goto cleanup; + } + + rth->u.dst.flags= DST_HOST; + if (in_dev->cnf.no_policy) + rth->u.dst.flags |= DST_NOPOLICY; + if (in_dev->cnf.no_xfrm) + rth->u.dst.flags |= DST_NOXFRM; + rth->fl.fl4_dst = daddr; + rth->rt_dst = daddr; + rth->fl.fl4_tos = tos; +#ifdef CONFIG_IP_ROUTE_FWMARK + rth->fl.fl4_fwmark= skb->nfmark; +#endif + rth->fl.fl4_src = saddr; + rth->rt_src = saddr; + rth->rt_gateway = daddr; + rth->rt_iif = + rth->fl.iif = in_dev->dev->ifindex; + rth->u.dst.dev = (out_dev)->dev; + dev_hold(rth->u.dst.dev); + rth->idev = in_dev_get(rth->u.dst.dev); + rth->fl.oif = 0; + rth->rt_spec_dst= spec_dst; + + rth->u.dst.input = ip_forward; + rth->u.dst.output = ip_output; + + rt_set_nexthop(rth, res, itag); + + rth->rt_flags = flags; + + *result = rth; + err = 0; + cleanup: + /* release the working reference to the output device */ + in_dev_put(out_dev); + return err; +} + +static inline int ip_mkroute_input_def(struct sk_buff *skb, + struct fib_result* res, + const struct flowi *fl, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos) +{ + struct rtable* rth; + int err; + unsigned hash; + +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (res->fi->fib_nhs > 1 && fl->oif == 0) + fib_select_multipath(fl, res); +#endif + + /* create a routing cache entry */ + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, &rth ); + if ( err ) + return err; + atomic_set(&rth->u.dst.__refcnt, 1); + + /* put it into the cache */ + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); + return rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); +} + +static inline int ip_mkroute_input(struct sk_buff *skb, + struct fib_result* res, + const struct flowi *fl, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos) +{ + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); +} + + /* * NOTE. We drop all the packets that has local source * addresses, because every properly looped back packet @@ -1539,11 +1706,10 @@ */ static int ip_route_input_slow(struct sk_buff *skb, u32 daddr, u32 saddr, - u8 tos, struct net_device *dev) + u8 tos, struct net_device *dev) { struct fib_result res; struct in_device *in_dev = in_dev_get(dev); - struct in_device *out_dev = NULL; struct flowi fl = { .nl_u = { .ip4_u = { .daddr = daddr, .saddr = saddr, @@ -1567,8 +1733,6 @@ if (!in_dev) goto out; - hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); - /* Check for the most weird martians, which can be not detected by fib_lookup. */ @@ -1621,79 +1785,14 @@ if (res.type != RTN_UNICAST) goto martian_destination; -#ifdef CONFIG_IP_ROUTE_MULTIPATH - if (res.fi->fib_nhs > 1 && fl.oif == 0) - fib_select_multipath(&fl, &res); -#endif - out_dev = in_dev_get(FIB_RES_DEV(res)); - if (out_dev == NULL) { - if (net_ratelimit()) - printk(KERN_CRIT "Bug in ip_route_input_slow(). " - "Please, report\n"); - goto e_inval; - } - - err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(res), dev, - &spec_dst, &itag); - if (err < 0) - goto martian_source; - - if (err) - flags |= RTCF_DIRECTSRC; - - if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && - (IN_DEV_SHARED_MEDIA(out_dev) || - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) - flags |= RTCF_DOREDIRECT; - - if (skb->protocol != htons(ETH_P_IP)) { - /* Not IP (i.e. ARP). Do not create route, if it is - * invalid for proxy arp. DNAT routes are always valid. - */ - if (out_dev == in_dev && !(flags & RTCF_DNAT)) - goto e_inval; - } - - rth = dst_alloc(&ipv4_dst_ops); - if (!rth) + err = ip_mkroute_input(skb, &res, &fl, in_dev, daddr, saddr, tos); + if ( err == -ENOBUFS ) goto e_nobufs; - - atomic_set(&rth->u.dst.__refcnt, 1); - rth->u.dst.flags= DST_HOST; - if (in_dev->cnf.no_policy) - rth->u.dst.flags |= DST_NOPOLICY; - if (in_dev->cnf.no_xfrm) - rth->u.dst.flags |= DST_NOXFRM; - rth->fl.fl4_dst = daddr; - rth->rt_dst = daddr; - rth->fl.fl4_tos = tos; -#ifdef CONFIG_IP_ROUTE_FWMARK - rth->fl.fl4_fwmark= skb->nfmark; -#endif - rth->fl.fl4_src = saddr; - rth->rt_src = saddr; - rth->rt_gateway = daddr; - rth->rt_iif = - rth->fl.iif = dev->ifindex; - rth->u.dst.dev = out_dev->dev; - dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); - rth->fl.oif = 0; - rth->rt_spec_dst= spec_dst; - - rth->u.dst.input = ip_forward; - rth->u.dst.output = ip_output; - - rt_set_nexthop(rth, &res, itag); - - rth->rt_flags = flags; - -intern: - err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + if ( err == -EINVAL ) + goto e_inval; + done: in_dev_put(in_dev); - if (out_dev) - in_dev_put(out_dev); if (free_res) fib_res_put(&res); out: return err; @@ -1753,7 +1852,9 @@ rth->rt_flags &= ~RTCF_LOCAL; } rth->rt_type = res.type; - goto intern; + hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + goto done; no_route: RT_CACHE_STAT_INC(in_no_route); @@ -1781,30 +1882,7 @@ goto done; martian_source: - - RT_CACHE_STAT_INC(in_martian_src); -#ifdef CONFIG_IP_ROUTE_VERBOSE - if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { - /* - * RFC1812 recommendation, if source is martian, - * the only hint is MAC header. - */ - printk(KERN_WARNING "martian source %u.%u.%u.%u from " - "%u.%u.%u.%u, on dev %s\n", - NIPQUAD(daddr), NIPQUAD(saddr), dev->name); - if (dev->hard_header_len) { - int i; - unsigned char *p = skb->mac.raw; - printk(KERN_WARNING "ll header: "); - for (i = 0; i < dev->hard_header_len; i++, p++) { - printk("%02x", *p); - if (i < (dev->hard_header_len - 1)) - printk(":"); - } - printk("\n"); - } - } -#endif + ip_handle_martian_source(dev, in_dev, skb, daddr, saddr); goto e_inval; } @@ -1875,13 +1953,166 @@ return ip_route_input_slow(skb, daddr, saddr, tos, dev); } +static inline int __mkroute_output(struct rtable **result, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + struct rtable *rth; + struct in_device *in_dev; + u32 tos = RT_FL_TOS(oldflp); + int err = 0; + + if (LOOPBACK(fl->fl4_src) && !(dev_out->flags&IFF_LOOPBACK)) + return -EINVAL; + + if (fl->fl4_dst == 0xFFFFFFFF) + res->type = RTN_BROADCAST; + else if (MULTICAST(fl->fl4_dst)) + res->type = RTN_MULTICAST; + else if (BADCLASS(fl->fl4_dst) || ZERONET(fl->fl4_dst)) + return -EINVAL; + + if (dev_out->flags & IFF_LOOPBACK) + flags |= RTCF_LOCAL; + + /* get work reference to inet device */ + in_dev = in_dev_get(dev_out); + if (!in_dev) + return -EINVAL; + + if (res->type == RTN_BROADCAST) { + flags |= RTCF_BROADCAST | RTCF_LOCAL; + if (res->fi) { + fib_info_put(res->fi); + res->fi = NULL; + } + } else if (res->type == RTN_MULTICAST) { + flags |= RTCF_MULTICAST|RTCF_LOCAL; + if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src, + oldflp->proto)) + flags &= ~RTCF_LOCAL; + /* If multicast route do not exist use + default one, but do not gateway in this case. + Yes, it is hack. + */ + if (res->fi && res->prefixlen < 4) { + fib_info_put(res->fi); + res->fi = NULL; + } + } + + + rth = dst_alloc(&ipv4_dst_ops); + if (!rth) { + err = -ENOBUFS; + goto cleanup; + } + + rth->u.dst.flags= DST_HOST; + if (in_dev->cnf.no_xfrm) + rth->u.dst.flags |= DST_NOXFRM; + if (in_dev->cnf.no_policy) + rth->u.dst.flags |= DST_NOPOLICY; + + rth->fl.fl4_dst = oldflp->fl4_dst; + rth->fl.fl4_tos = tos; + rth->fl.fl4_src = oldflp->fl4_src; + rth->fl.oif = oldflp->oif; +#ifdef CONFIG_IP_ROUTE_FWMARK + rth->fl.fl4_fwmark= oldflp->fl4_fwmark; +#endif + rth->rt_dst = fl->fl4_dst; + rth->rt_src = fl->fl4_src; + rth->rt_iif = oldflp->oif ? : dev_out->ifindex; + /* get references to the devices that are to be hold by the routing + cache entry */ + rth->u.dst.dev = dev_out; + dev_hold(dev_out); + rth->idev = in_dev_get(dev_out); + rth->rt_gateway = fl->fl4_dst; + rth->rt_spec_dst= fl->fl4_src; + + rth->u.dst.output=ip_output; + + RT_CACHE_STAT_INC(out_slow_tot); + + if (flags & RTCF_LOCAL) { + rth->u.dst.input = ip_local_deliver; + rth->rt_spec_dst = fl->fl4_dst; + } + if (flags & (RTCF_BROADCAST | RTCF_MULTICAST)) { + rth->rt_spec_dst = fl->fl4_src; + if (flags & RTCF_LOCAL && + !(dev_out->flags & IFF_LOOPBACK)) { + rth->u.dst.output = ip_mc_output; + RT_CACHE_STAT_INC(out_slow_mc); + } +#ifdef CONFIG_IP_MROUTE + if (res->type == RTN_MULTICAST) { + if (IN_DEV_MFORWARD(in_dev) && + !LOCAL_MCAST(oldflp->fl4_dst)) { + rth->u.dst.input = ip_mr_input; + rth->u.dst.output = ip_mc_output; + } + } +#endif + } + + rt_set_nexthop(rth, res, 0); + + rth->rt_flags = flags; + + *result = rth; + cleanup: + /* release work reference to inet device */ + in_dev_put(in_dev); + + return err; +} + +static inline int ip_mkroute_output_def(struct rtable **rp, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + struct rtable *rth; + int err = __mkroute_output(&rth, res, fl, oldflp, dev_out, flags); + unsigned hash; + if ( err == 0 ) { + u32 tos = RT_FL_TOS(oldflp); + + atomic_set(&rth->u.dst.__refcnt, 1); + + hash = rt_hash_code(oldflp->fl4_dst, + oldflp->fl4_src ^ (oldflp->oif << 5), tos); + err = rt_intern_hash(hash, rth, rp); + } + + return err; +} + +static inline int ip_mkroute_output(struct rtable** rp, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); +} + /* * Major route resolver routine. */ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp) { - u32 tos = oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK); + u32 tos = RT_FL_TOS(oldflp); struct flowi fl = { .nl_u = { .ip4_u = { .daddr = oldflp->fl4_dst, .saddr = oldflp->fl4_src, @@ -1897,10 +2128,7 @@ .oif = oldflp->oif }; struct fib_result res; unsigned flags = 0; - struct rtable *rth; struct net_device *dev_out = NULL; - struct in_device *in_dev = NULL; - unsigned hash; int free_res = 0; int err; @@ -2060,116 +2288,13 @@ fl.oif = dev_out->ifindex; make_route: - if (LOOPBACK(fl.fl4_src) && !(dev_out->flags&IFF_LOOPBACK)) - goto e_inval; + err = ip_mkroute_output(rp, &res, &fl, oldflp, dev_out, flags); - if (fl.fl4_dst == 0xFFFFFFFF) - res.type = RTN_BROADCAST; - else if (MULTICAST(fl.fl4_dst)) - res.type = RTN_MULTICAST; - else if (BADCLASS(fl.fl4_dst) || ZERONET(fl.fl4_dst)) - goto e_inval; - - if (dev_out->flags & IFF_LOOPBACK) - flags |= RTCF_LOCAL; - - in_dev = in_dev_get(dev_out); - if (!in_dev) - goto e_inval; - - if (res.type == RTN_BROADCAST) { - flags |= RTCF_BROADCAST | RTCF_LOCAL; - if (res.fi) { - fib_info_put(res.fi); - res.fi = NULL; - } - } else if (res.type == RTN_MULTICAST) { - flags |= RTCF_MULTICAST|RTCF_LOCAL; - if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src, oldflp->proto)) - flags &= ~RTCF_LOCAL; - /* If multicast route do not exist use - default one, but do not gateway in this case. - Yes, it is hack. - */ - if (res.fi && res.prefixlen < 4) { - fib_info_put(res.fi); - res.fi = NULL; - } - } - - rth = dst_alloc(&ipv4_dst_ops); - if (!rth) - goto e_nobufs; - - atomic_set(&rth->u.dst.__refcnt, 1); - rth->u.dst.flags= DST_HOST; - if (in_dev->cnf.no_xfrm) - rth->u.dst.flags |= DST_NOXFRM; - if (in_dev->cnf.no_policy) - rth->u.dst.flags |= DST_NOPOLICY; - rth->fl.fl4_dst = oldflp->fl4_dst; - rth->fl.fl4_tos = tos; - rth->fl.fl4_src = oldflp->fl4_src; - rth->fl.oif = oldflp->oif; -#ifdef CONFIG_IP_ROUTE_FWMARK - rth->fl.fl4_fwmark= oldflp->fl4_fwmark; -#endif - rth->rt_dst = fl.fl4_dst; - rth->rt_src = fl.fl4_src; - rth->rt_iif = oldflp->oif ? : dev_out->ifindex; - rth->u.dst.dev = dev_out; - dev_hold(dev_out); - rth->idev = in_dev_get(dev_out); - rth->rt_gateway = fl.fl4_dst; - rth->rt_spec_dst= fl.fl4_src; - - rth->u.dst.output=ip_output; - - RT_CACHE_STAT_INC(out_slow_tot); - - if (flags & RTCF_LOCAL) { - rth->u.dst.input = ip_local_deliver; - rth->rt_spec_dst = fl.fl4_dst; - } - if (flags & (RTCF_BROADCAST | RTCF_MULTICAST)) { - rth->rt_spec_dst = fl.fl4_src; - if (flags & RTCF_LOCAL && !(dev_out->flags & IFF_LOOPBACK)) { - rth->u.dst.output = ip_mc_output; - RT_CACHE_STAT_INC(out_slow_mc); - } -#ifdef CONFIG_IP_MROUTE - if (res.type == RTN_MULTICAST) { - if (IN_DEV_MFORWARD(in_dev) && - !LOCAL_MCAST(oldflp->fl4_dst)) { - rth->u.dst.input = ip_mr_input; - rth->u.dst.output = ip_mc_output; - } - } -#endif - } - - rt_set_nexthop(rth, &res, 0); - - - rth->rt_flags = flags; - - hash = rt_hash_code(oldflp->fl4_dst, oldflp->fl4_src ^ (oldflp->oif << 5), tos); - err = rt_intern_hash(hash, rth, rp); -done: if (free_res) fib_res_put(&res); if (dev_out) dev_put(dev_out); - if (in_dev) - in_dev_put(in_dev); out: return err; - -e_inval: - err = -EINVAL; - goto done; -e_nobufs: - err = -ENOBUFS; - goto done; } int __ip_route_output_key(struct rtable **rp, const struct flowi *flp) --------------080306080307080004070007-- From yoshfuji@linux-ipv6.org Tue Sep 14 05:52:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 05:52:25 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ECqIEb016868 for ; Tue, 14 Sep 2004 05:52:19 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C634533CE5; Tue, 14 Sep 2004 21:52:12 +0900 (JST) Date: Tue, 14 Sep 2004 21:52:05 +0900 (JST) Message-Id: <20040914.215205.110659321.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [INET] Add flags field to ip_tunnel_parm From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040914121617.GA5652@gondor.apana.org.au> References: <20040914121617.GA5652@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 627 Lines: 19 In article <20040914121617.GA5652@gondor.apana.org.au> (at Tue, 14 Sep 2004 22:16:17 +1000), Herbert Xu says: > BTW if anyone else wants to add more fields to the structure, now is > the time. Well, you simply cannot do this. Kernel will get garbage from old binaries, and kernel will break user space if it tries to get params into old structure. So, please change SIOxxxTUNNEL values to support both interfaces (or give up ioctl and use rtnetlink instead!) Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ltd@cisco.com Tue Sep 14 06:08:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 06:08:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ED8AD8025650 for ; Tue, 14 Sep 2004 06:08:10 -0700 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2004 06:10:08 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8ED7rLp018362; Tue, 14 Sep 2004 06:07:53 -0700 (PDT) Received: from ltd-t30.cisco.com (syd-vpn-client-254-12.cisco.com [10.66.254.12]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXC15868; Tue, 14 Sep 2004 06:06:39 -0700 (PDT) Message-Id: <5.1.0.14.2.20040914225341.03c31a08@171.71.163.14> X-Sender: ltd@171.71.163.14 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Sep 2004 23:07:50 +1000 To: Paul P Komkoff Jr From: Lincoln Dale Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Cc: "David S. Miller" , Paul P Komkoff Jr , netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040914123951.GL4141@stingr.sgu.ru> References: <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> <20040913051706.GB26337@stingr.sgu.ru> <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> <20040913051706.GB26337@stingr.sgu.ru> <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltd@cisco.com Precedence: bulk X-list: netdev Content-Length: 1093 Lines: 31 At 10:39 PM 14/09/2004, Paul P Komkoff Jr wrote: >Replying to Lincoln Dale: > > the logic is correct, but it may make sense to call the appropriate > > netfilter hook again with the "unwrapped" GRE packet, as otherwise > > packets-inside-GRE represent a possible security hole where one can inject > > packets externally and bypass firewall rules. > > From what I observe, netfilter hooks *are* called for unwrapped packets. >Either for usual IP packets passed from GRE tunnel, or for demangled >wccp packets. you probably want to ensure that the order of netfilter events are: 1. [packet comes in] 2. netfilter INPUT 3. [GRE decap] 4. [addressed to us?] Yes => netfilter INPUT No => netfilter FORWARD i don't think that both (2) and (4) are done. also just a minor nit: not all WCCP needs to be GRE-encoded; on high-performance switch/router platforms, only a layer-2 rewrite of the dst MAC addr is used instead of a layer-3 GRE tunnel. you may want the comment at line 609 to explicitly mention "WCCPv1 and WCCPv2 GRE Forwarding mode". cheers, lincoln. From jmorris@redhat.com Tue Sep 14 07:06:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 07:06:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EE6IU5027239 for ; Tue, 14 Sep 2004 07:06:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8EE5oRH007246; Tue, 14 Sep 2004 10:05:50 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8EE5or00903; Tue, 14 Sep 2004 10:05:50 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8EE5niS024419; Tue, 14 Sep 2004 10:05:50 -0400 Date: Tue, 14 Sep 2004 10:05:49 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , YOSHIFUJI Hideaki , Subject: Re: [INET] Add flags field to ip_tunnel_parm In-Reply-To: <20040914121617.GA5652@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 194 Lines: 14 On Tue, 14 Sep 2004, Herbert Xu wrote: > 3) Put it into some other file in net/ipv4 that's always built in. I'd suggest net/ipv4/ip_tunnel.c - James -- James Morris From vda@port.imtp.ilyichevsk.odessa.ua Tue Sep 14 07:23:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 07:24:05 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8EENsPB027847 for ; Tue, 14 Sep 2004 07:23:56 -0700 Received: (qmail 28038 invoked by alias); 14 Sep 2004 14:23:43 -0000 Received: from unknown (195.66.192.167) by 0 (195.66.192.168) with ESMTP; 14 Sep 2004 14:23:43 -0000 From: Denis Vlasenko To: linux-kernel@vger.kernel.org, Trond Myklebust Subject: Kernel stack overflow on 2.6.9-rc2 Date: Tue, 14 Sep 2004 17:23:34 +0300 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409141723.35009.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 8783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 3918 Lines: 131 Hi, I am putting to use an ancient box. Pentium 66. It gives me stack overflow errors on 2.6.9-rc2: init: spawning /sbin/agetty do_IRQ: stack overflow: 508 [] dump_stack+0x17/0x1b [] do_IRQ+0x177/0x17e [] common_interrupt+0x18/0x20 [] kfree_skbmem+0xd/0x21 [] __kfree_skb+0xa7/0x118 [] ei_start_xmit+0x142/0x254 [] qdisc_restart+0x41/0xc3 [] dev_queue_xmit+0x180/0x20b [] ip_finish_output2+0xa1/0x18b [] nf_hook_slow+0x91/0xc0 [] ip_finish_output+0x1c5/0x1ca [] dst_output+0x11/0x2a [] nf_hook_slow+0x91/0xc0 [] ip_push_pending_frames+0x39c/0x3f5 [] udp_push_pending_frames+0x13d/0x25c [] udp_sendmsg+0x35e/0x61a [] inet_sendmsg+0x3a/0x45 [] sock_sendmsg+0x88/0xa3 [] xdr_sendpages+0xb1/0x22e [] xprt_transmit+0xbe/0x45f [] call_transmit+0x46/0xa0 [] __rpc_execute+0x29a/0x3b1 [] rpc_call_sync+0x59/0x95 [] nfs3_rpc_wrapper+0x2d/0x70 [] nfs3_proc_getattr+0x57/0x89 [] __nfs_revalidate_inode+0xc7/0x308 [] nfs_lookup_revalidate+0x257/0x4ed [] do_lookup+0x43/0x76 [] link_path_walk+0x445/0x883 [] __vfs_follow_link+0x28/0x133 [] nfs_follow_link+0x28/0x47 [] link_path_walk+0x519/0x883 [] __vfs_follow_link+0x28/0x133 [] nfs_follow_link+0x28/0x47 [] link_path_walk+0x519/0x883 [] path_lookup+0x70/0x10a [] open_exec+0x22/0xc4 [] load_elf_binary+0xc4f/0xcc8 [] search_binary_handler+0x4b/0x196 [] load_script+0x1ea/0x220 [] search_binary_handler+0x4b/0x196 [] do_execve+0x153/0x1b9 [] sys_execve+0x2d/0x60 [] syscall_call+0x7/0xb I've run make checkstack and matched funtions using this script: cat stackovf.txt \ | { sum=0 while read empty addr name_ofs junk; do name=${name_ofs/+*/} num=`grep -F $name checkstack.list` num=${num/* /} let sum+=num echo $name_ofs $junk [$num] done echo Total: $sum } Output: dump_stack+0x17/0x1b [] do_IRQ+0x177/0x17e [] common_interrupt+0x18/0x20 [] kfree_skbmem+0xd/0x21 [] __kfree_skb+0xa7/0x118 [] ei_start_xmit+0x142/0x254 [] qdisc_restart+0x41/0xc3 [] dev_queue_xmit+0x180/0x20b [] ip_finish_output2+0xa1/0x18b [] nf_hook_slow+0x91/0xc0 [] ip_finish_output+0x1c5/0x1ca [] dst_output+0x11/0x2a [] nf_hook_slow+0x91/0xc0 [] ip_push_pending_frames+0x39c/0x3f5 [] udp_push_pending_frames+0x13d/0x25c [] udp_sendmsg+0x35e/0x61a [220] inet_sendmsg+0x3a/0x45 [] sock_sendmsg+0x88/0xa3 [208] xdr_sendpages+0xb1/0x22e [] xprt_transmit+0xbe/0x45f [] call_transmit+0x46/0xa0 [] __rpc_execute+0x29a/0x3b1 [] rpc_call_sync+0x59/0x95 [] nfs3_rpc_wrapper+0x2d/0x70 [] nfs3_proc_getattr+0x57/0x89 [] __nfs_revalidate_inode+0xc7/0x308 [152] nfs_lookup_revalidate+0x257/0x4ed [312] do_lookup+0x43/0x76 [] link_path_walk+0x445/0x883 [] __vfs_follow_link+0x28/0x133 [] nfs_follow_link+0x28/0x47 [] link_path_walk+0x519/0x883 [] __vfs_follow_link+0x28/0x133 [] nfs_follow_link+0x28/0x47 [] link_path_walk+0x519/0x883 [] path_lookup+0x70/0x10a [] open_exec+0x22/0xc4 [] load_elf_binary+0xc4f/0xcc8 [268] search_binary_handler+0x4b/0x196 [] load_script+0x1ea/0x220 [136] search_binary_handler+0x4b/0x196 [] do_execve+0x153/0x1b9 [336] sys_execve+0x2d/0x60 [] syscall_call+0x7/0xb [] Total: 1632 To save you filtering out functions with less than 100 bytes of stack: udp_sendmsg+0x35e/0x61a [220] sock_sendmsg+0x88/0xa3 [208] __nfs_revalidate_inode+0xc7/0x308 [152] nfs_lookup_revalidate+0x257/0x4ed [312] load_elf_binary+0xc4f/0xcc8 [268] load_script+0x1ea/0x220 [136] do_execve+0x153/0x1b9 [336] Total: 1632 I don't think it's new, 2.6.7-something did it too. -- vda From anton@ozlabs.org Tue Sep 14 07:25:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 07:25:54 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EEPjxZ028069 for ; Tue, 14 Sep 2004 07:25:45 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id C7CFE2BD71; Wed, 15 Sep 2004 00:25:29 +1000 (EST) Date: Wed, 15 Sep 2004 00:24:47 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Subject: network lockup with latest BK (LLTX?) Message-ID: <20040914142447.GA5615@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 13227 Lines: 289 Hi, I have a machine with a number of e1000 adapters in it. It locked up while I was bringing up the network interfaces. I have attached backtraces of all relevant cpus. There are a bunch of cpus in arp_xmit -> dev_queue_xmit, these all appear to be stuck on the dev->queue_lock. Looking closer, all cpus other than cpu 4 are stuck on the same spinlock. And since we store the cpu number in our spinlocks, we know that this lock is owned by cpu4. Looking at cpu4: pfifo_fast_dequeue+0x58/0x78 qdisc_restart+0x5c/0x340 net_tx_action+0x144/0x248 __do_softirq+0xc4/0x198 call_do_softirq+0x14/0x28 do_softirq+0x90/0xa4 local_bh_enable+0x70/0x78 dev_queue_xmit+0x2c0/0x364 ip_finish_output+0x114/0x2e0 ip_queue_xmit+0x390/0x67c tcp_transmit_skb+0x410/0xa2c tcp_write_xmit+0x1dc/0x3f4 tcp_sendmsg+0x143c/0x147c inet_sendmsg+0x80/0xac sock_aio_write+0x13c/0x170 do_sync_write+0xac/0x118 vfs_write+0xb8/0x188 sys_write+0x4c/0x90 I had a look at qdisc_restart and it looks like we can return from it with the queue_lock dropped if we hit the following: if (ret == NETDEV_TX_LOCKED && nolock) goto collision; Also I wonder why the collision case loops back to check xmit_lock_owner since in the nolock case xmit_lock_owner isnt initialized. Even so, Im not sure it explains why the cpu is stuck where it is. Anton -- 0:mon> c 0 0:mon> e cpu 0x0: Vector: 100 (System Reset) at [c000000ffec8b080] pc: c0000000003ea260: ._spin_lock+0x28/0x3c lr: c00000000036cee0: .qdisc_restart+0x2b8/0x340 sp: c000000ffec8b300 msr: 9000000000089032 current = 0xc000000ffea80d40 paca = 0xc000000000541980 pid = 1708, comm = sshd 0:mon> t [link register ] c00000000036cee0 .qdisc_restart+0x2b8/0x340 [c000000ffec8b300] c00000000036cde8 .qdisc_restart+0x1c0/0x340 (unreliable) [c000000ffec8b3a0] c00000000035ebb8 .dev_queue_xmit+0x294/0x364 [c000000ffec8b430] c00000000037a7f4 .ip_finish_output+0x114/0x2e0 [c000000ffec8b4e0] c00000000037ad50 .ip_queue_xmit+0x390/0x67c [c000000ffec8b670] c00000000038f5c4 .tcp_transmit_skb+0x410/0xa2c [c000000ffec8b790] c000000000390438 .tcp_write_xmit+0x1dc/0x3f4 [c000000ffec8b870] c000000000381f04 .tcp_sendmsg+0x143c/0x147c [c000000ffec8b9e0] c0000000003ab85c .inet_sendmsg+0x80/0xac [c000000ffec8ba70] c0000000003520f4 .sock_aio_write+0x13c/0x170 [c000000ffec8bb90] c00000000009fc3c .do_sync_write+0xac/0x118 [c000000ffec8bcf0] c00000000009fd60 .vfs_write+0xb8/0x188 [c000000ffec8bd90] c00000000009ff0c .sys_write+0x4c/0x90 [c000000ffec8be30] c000000000010508 system_call+0x40/0x44 --- Exception: c01 (System Call) at 000000000fcba3dc SP (ffffe3f0) is in userspace 0:mon> c 2 2:mon> e cpu 0x2: Vector: 501 (Hardware Interrupt) at [c00000000ffef800] pc: c0000000003ea25c: ._spin_lock+0x24/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffefa80 msr: 9000000000009032 current = 0xc0000032fff64040 paca = 0xc000000000542280 pid = 0, comm = swapper 2:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffefa80] 0000000000000000 (unreliable) [c00000000ffefb10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffefb80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffefcc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffefd60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffefe30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffefee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffeff90] c000000000017688 .call_do_softirq+0x14/0x28 [c000001e313dfa70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000001e313dfb00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c000000000013990 .default_idle+0x7c/0xdc [c000001e313dfe90] c000000000013c68 .cpu_idle+0x38/0x50 [c000001e313dff00] c000000000037320 .start_secondary+0x128/0x17c [c000001e313dff90] c00000000000cc2c start_secondary_prolog+0xc/0x10 2:mon> c 3 3:mon> e cpu 0x3: Vector: 501 (Hardware Interrupt) at [c00000000ffe7800] pc: c0000000003ea25c: ._spin_lock+0x24/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffe7a80 msr: 9000000000009032 current = 0xc0000032fff611c0 paca = 0xc000000000542700 pid = 0, comm = swapper 3:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffe7a80] 0000000000000000 (unreliable) [c00000000ffe7b10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffe7b80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffe7cc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffe7d60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffe7e30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffe7ee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffe7f90] c000000000017688 .call_do_softirq+0x14/0x28 [c000002c34b6ba70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000002c34b6bb00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c000000000013988 .default_idle+0x74/0xdc [c000002c34b6be90] c000000000013c68 .cpu_idle+0x38/0x50 [c000002c34b6bf00] c000000000037320 .start_secondary+0x128/0x17c [c000002c34b6bf90] c00000000000cc2c start_secondary_prolog+0xc/0x10 3:mon> c 4 4:mon> e cpu 0x4: Vector: 501 (Hardware Interrupt) at [c00000000ffdfb10] pc: c00000000036d3a0: .pfifo_fast_dequeue+0x58/0x78 lr: c00000000036cc84: .qdisc_restart+0x5c/0x340 sp: c00000000ffdfd90 msr: 9000000000009032 current = 0xc000002c361113c0 paca = 0xc000000000542b80 pid = 3700, comm = ssh 4:mon> t [link register ] c00000000036cc84 .qdisc_restart+0x5c/0x340 [c00000000ffdfd90] c00000000036ce6c .qdisc_restart+0x244/0x340 (unreliable) [c00000000ffdfe30] c00000000035f114 .net_tx_action+0x144/0x248 [c00000000ffdfee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffdff90] c000000000017688 .call_do_softirq+0x14/0x28 [c00000000119f2a0] c0000000000137e8 .do_softirq+0x90/0xa4 [c00000000119f330] c000000000056668 .local_bh_enable+0x70/0x78 [c00000000119f3a0] c00000000035ebe4 .dev_queue_xmit+0x2c0/0x364 [c00000000119f430] c00000000037a7f4 .ip_finish_output+0x114/0x2e0 [c00000000119f4e0] c00000000037ad50 .ip_queue_xmit+0x390/0x67c [c00000000119f670] c00000000038f5c4 .tcp_transmit_skb+0x410/0xa2c [c00000000119f790] c000000000390438 .tcp_write_xmit+0x1dc/0x3f4 [c00000000119f870] c000000000381f04 .tcp_sendmsg+0x143c/0x147c [c00000000119f9e0] c0000000003ab85c .inet_sendmsg+0x80/0xac [c00000000119fa70] c0000000003520f4 .sock_aio_write+0x13c/0x170 [c00000000119fb90] c00000000009fc3c .do_sync_write+0xac/0x118 [c00000000119fcf0] c00000000009fd60 .vfs_write+0xb8/0x188 [c00000000119fd90] c00000000009ff0c .sys_write+0x4c/0x90 [c00000000119fe30] c000000000010508 system_call+0x40/0x44 --- Exception: c01 (System Call) at 000000000fd313dc SP (ffffe980) is in userspace 4:mon> c 5 5:mon> e cpu 0x5: Vector: 501 (Hardware Interrupt) at [c00000000ffd7800] pc: c0000000003ea260: ._spin_lock+0x28/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffd7a80 msr: 9000000000009032 current = 0xc0000032fff600c0 paca = 0xc000000000543000 pid = 0, comm = swapper 5:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffd7a80] 0000000000000000 (unreliable) [c00000000ffd7b10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffd7b80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffd7cc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffd7d60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffd7e30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffd7ee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffd7f90] c000000000017688 .call_do_softirq+0x14/0x28 [c000001dfff93a70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000001dfff93b00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c00000000001398c .default_idle+0x78/0xdc [c000001dfff93e90] c000000000013c68 .cpu_idle+0x38/0x50 [c000001dfff93f00] c000000000037320 .start_secondary+0x128/0x17c [c000001dfff93f90] c00000000000cc2c start_secondary_prolog+0xc/0x10 5:mon> c 6 6:mon> e cpu 0x6: Vector: 501 (Hardware Interrupt) at [c00000000ffcf800] pc: c0000000003ea25c: ._spin_lock+0x24/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffcfa80 msr: 9000000000009032 current = 0xc000002bfff91240 paca = 0xc000000000543480 pid = 0, comm = swapper 6:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffcfa80] 0000000000000000 (unreliable) [c00000000ffcfb10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffcfb80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffcfcc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffcfd60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffcfe30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffcfee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffcff90] c000000000017688 .call_do_softirq+0x14/0x28 [c000002bfff97a70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000002bfff97b00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c00000000001398c .default_idle+0x78/0xdc [c000002bfff97e90] c000000000013c68 .cpu_idle+0x38/0x50 [c000002bfff97f00] c000000000037320 .start_secondary+0x128/0x17c [c000002bfff97f90] c00000000000cc2c start_secondary_prolog+0xc/0x10 6:mon> c 7 7:mon> e cpu 0x7: Vector: 501 (Hardware Interrupt) at [c00000000ffc7800] pc: c0000000003ea260: ._spin_lock+0x28/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffc7a80 msr: 9000000000009032 current = 0xc000002bfff909c0 paca = 0xc000000000543900 pid = 0, comm = swapper 7:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffc7a80] 0000000000000000 (unreliable) [c00000000ffc7b10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffc7b80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffc7cc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffc7d60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffc7e30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffc7ee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffc7f90] c000000000017688 .call_do_softirq+0x14/0x28 [c000002c34b6fa70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000002c34b6fb00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c000000000013984 .default_idle+0x70/0xdc [c000002c34b6fe90] c000000000013c68 .cpu_idle+0x38/0x50 [c000002c34b6ff00] c000000000037320 .start_secondary+0x128/0x17c [c000002c34b6ff90] c00000000000cc2c start_secondary_prolog+0xc/0x10 7:mon> c 8 8:mon> e cpu 0x8: Vector: 501 (Hardware Interrupt) at [c00000000ffbf800] pc: c0000000003ea260: ._spin_lock+0x28/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffbfa80 msr: 9000000000009032 current = 0xc000002bfff90140 paca = 0xc000000000543d80 pid = 0, comm = swapper 8:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffbfa80] 0000000000000000 (unreliable) [c00000000ffbfb10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffbfb80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffbfcc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffbfd60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffbfe30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffbfee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffbff90] c000000000017688 .call_do_softirq+0x14/0x28 [c000000ffff8ba70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000000ffff8bb00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c00000000001398c .default_idle+0x78/0xdc [c000000ffff8be90] c000000000013c68 .cpu_idle+0x38/0x50 [c000000ffff8bf00] c000000000037320 .start_secondary+0x128/0x17c [c000000ffff8bf90] c00000000000cc2c start_secondary_prolog+0xc/0x10 8:mon> c 9 9:mon> e cpu 0x9: Vector: 501 (Hardware Interrupt) at [c00000000ffb7800] pc: c0000000003ea260: ._spin_lock+0x28/0x3c lr: c00000000035eb68: .dev_queue_xmit+0x244/0x364 sp: c00000000ffb7a80 msr: 9000000000009032 current = 0xc000001dfff952c0 paca = 0xc000000000544200 pid = 0, comm = swapper 9:mon> t [link register ] c00000000035eb68 .dev_queue_xmit+0x244/0x364 [c00000000ffb7a80] 0000000000000000 (unreliable) [c00000000ffb7b10] c0000000003a476c .arp_xmit+0x10/0x24 [c00000000ffb7b80] c0000000003a5084 .arp_process+0x640/0x6d0 [c00000000ffb7cc0] c00000000035f4f4 .netif_receive_skb+0x2dc/0x374 [c00000000ffb7d60] c00000000035f698 .process_backlog+0x10c/0x264 [c00000000ffb7e30] c00000000035f8cc .net_rx_action+0xdc/0x230 [c00000000ffb7ee0] c000000000056524 .__do_softirq+0xc4/0x198 [c00000000ffb7f90] c000000000017688 .call_do_softirq+0x14/0x28 [c000001dfff83a70] c0000000000137e8 .do_softirq+0x90/0xa4 [c000001dfff83b00] c00000000000be34 HardwareInterrupt_entry+0x8/0x54 --- Exception: 501 (Hardware Interrupt) at c000000000013988 .default_idle+0x74/0xdc [c000001dfff83e90] c000000000013c68 .cpu_idle+0x38/0x50 [c000001dfff83f00] c000000000037320 .start_secondary+0x128/0x17c [c000001dfff83f90] c00000000000cc2c start_secondary_prolog+0xc/0x10 From hadi@cyberus.ca Tue Sep 14 07:54:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 07:54:11 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EEs5in029132 for ; Tue, 14 Sep 2004 07:54:05 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C7Egq-0004q9-Fy for netdev@oss.sgi.com; Tue, 14 Sep 2004 10:53:52 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7Egp-0004lu-5U; Tue, 14 Sep 2004 10:53:51 -0400 Subject: Re: network lockup with latest BK (LLTX?) From: jamal Reply-To: hadi@cyberus.ca To: Anton Blanchard Cc: netdev@oss.sgi.com In-Reply-To: <20040914142447.GA5615@krispykreme> References: <20040914142447.GA5615@krispykreme> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095173628.1030.3.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Sep 2004 10:53:48 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 642 Lines: 23 Yep LLTX, use patch posted by Andi yesterday. cheers, jamal On Tue, 2004-09-14 at 10:24, Anton Blanchard wrote: > Hi, > > I have a machine with a number of e1000 adapters in it. It locked up > while I was bringing up the network interfaces. I have attached > backtraces of all relevant cpus. > > There are a bunch of cpus in arp_xmit -> dev_queue_xmit, these all > appear to be stuck on the dev->queue_lock. Looking closer, all cpus > other than cpu 4 are stuck on the same spinlock. And since we store the > cpu number in our spinlocks, we know that this lock is owned by cpu4. > > Looking at cpu4: > > pfifo_fast_dequeue+0x58/0x78 From anton@ozlabs.org Tue Sep 14 08:07:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 08:07:46 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EF7fsA029709 for ; Tue, 14 Sep 2004 08:07:42 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 717E52BD7B; Wed, 15 Sep 2004 01:07:26 +1000 (EST) Date: Wed, 15 Sep 2004 01:03:27 +1000 From: Anton Blanchard To: jamal Cc: netdev@oss.sgi.com Subject: Re: network lockup with latest BK (LLTX?) Message-ID: <20040914150327.GB5615@krispykreme> References: <20040914142447.GA5615@krispykreme> <1095173628.1030.3.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095173628.1030.3.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 71 Lines: 6 > Yep LLTX, use patch posted by Andi yesterday. Thanks Jamal. Anton From kernel@linuxace.com Tue Sep 14 08:08:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 08:08:52 -0700 (PDT) Received: from home.linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8EF8lOs029899 for ; Tue, 14 Sep 2004 08:08:47 -0700 Received: (qmail 5731 invoked by uid 0); 14 Sep 2004 15:08:32 -0000 Date: Tue, 14 Sep 2004 08:08:32 -0700 From: Phil Oester To: lkml@einar-lueck.de Cc: "David S. Miller" , hadi@cyberus.ca, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 2/2] ip multipath, bk head (EXPERIMENTAL) Message-ID: <20040914150832.GA5667@linuxace.com> References: <41457848.6040808@de.ibm.com> <1095129624.1060.45.camel@jzny.localdomain> <20040913224232.4b979c7d.davem@davemloft.net> <4146E65D.6070309@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4146E65D.6070309@de.ibm.com> User-Agent: Mutt/1.4.1i X-archive-position: 8787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev Content-Length: 561 Lines: 19 On Tue, Sep 14, 2004 at 02:38:53PM +0200, Einar Lueck wrote: > I attached the patch the way you requested in the other thread. > > Regards > Einar If you say Y here, alternative routes are cached + in the routing cache and on cache lookup route is chosen in + Round Robin fashon. Shouldn't this instead say If you say Y here, alternative routes are cached in the routing cache and on cache lookup a route is chosen using the policy selected in 'Multipath policy' or somesuch. IOW, round robin is not always the policy. Phil From speattle@yahoo.com Tue Sep 14 08:35:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 08:35:52 -0700 (PDT) Received: from web90008.mail.scd.yahoo.com (web90008.mail.scd.yahoo.com [66.218.94.66]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8EFZk64002540 for ; Tue, 14 Sep 2004 08:35:47 -0700 Message-ID: <20040914153532.89992.qmail@web90008.mail.scd.yahoo.com> Received: from [216.145.61.65] by web90008.mail.scd.yahoo.com via HTTP; Tue, 14 Sep 2004 08:35:32 PDT Date: Tue, 14 Sep 2004 08:35:32 -0700 (PDT) From: S P Subject: Re: [PATCH] linux 2.6.x.x net/sched/sch_api.c -- more comment reviews To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20040913153146.161128d0.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: speattle@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1357 Lines: 53 > Please fix > for future submissions, thanks. will use attachments. > > Now, onto the patch itself. I think we're adding > more tense > errors than we're removing. For example: > > > - All real intelligent work is done inside qdisc > > modules. > > + All real intelligent work is done inside each > > qdisc modules. > > 'each' indicates singularity, yes "modules" is still > plural. I would change it instead to: > > All the real intelligent work is done inside > the qdisc modules. I think I meant inside each of the module. Not sure if your change conveys that. I did notice it's still akward, but I didn't want to take away the emphasis of individuality if the original author meant it. > Looks fine, we're missing an articles here. > So maybe the final version of this verse is: > > For complicated disciplines with multiple queues, > q->q is not a real packet queue whereas q->q.qlen > must be valid. > > The rest looks fine. Yup, I thought I lost that 'a' somewhere. And, the comma. (so the code readers don't run out of breathe) > > Thanks. So should I resubmit w/ the changes? Wasn't sure if you just applied w/ the changes or are returning for me to apply the fixes. :) __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From laforge@gnumonks.org Tue Sep 14 08:36:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 08:37:32 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EFakKS002733 for ; Tue, 14 Sep 2004 08:36:47 -0700 Received: from dsl-082-082-095-094.arcor-ip.net ([82.82.95.94] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7FMB-000438-RH; Tue, 14 Sep 2004 17:36:36 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7FLF-0007Tg-CY; Tue, 14 Sep 2004 17:35:37 +0200 Date: Tue, 14 Sep 2004 17:35:37 +0200 From: Harald Welte To: David Miller Cc: netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: [PATCH 2.6] Add NAPI support to sungem.c Message-ID: <20040914153537.GE8434@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NctWKJLgDreUm1FS" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 8971 Lines: 338 --NctWKJLgDreUm1FS Content-Type: multipart/mixed; boundary="I/+EtO164iqGPpU0" Content-Disposition: inline --I/+EtO164iqGPpU0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! Please find the attached patch to add NAPI support to the sungem.c driver (I was annoyed by the fact the pktgen could kill my Powerbook). Since this is my first hack of a network driver within at least 5 years, please be kind with me and point me to all the locking bugs and other mistakes ;) Any comments welcome, Harald --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --I/+EtO164iqGPpU0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-2.6.9-rc1-sungem-napi-0.01.patch" Content-Transfer-Encoding: quoted-printable diff -Nru linux-2.6.8.1-davem269_4/drivers/net/Kconfig linux-2.6.8.1-davem2= 69_4-sungem-napi/drivers/net/Kconfig --- linux-2.6.8.1-davem269_4/drivers/net/Kconfig 2004-08-14 12:56:00.000000= 000 +0200 +++ linux-2.6.8.1-davem269_4-sungem-napi/drivers/net/Kconfig 2004-09-14 11:= 40:40.000000000 +0200 @@ -569,6 +569,22 @@ help Support for the Sun GEM chip, aka Sun GigabitEthernet/P 2.0. See also . +config SUNGEM_NAPI + bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" + depends on SUNGEM && EXPERIMENTAL + help + NAPI is a new driver API designed to reduce CPU and interrupt load + when the driver is receiving lots of packets from the card. It is + still somewhat experimental and thus not yet enabled by default. + + If your estimated Rx load is 10kpps or more, or if the card will be + deployed on potentially unfriendly networks (e.g. in a firewall), + then say Y here. + + See for more + information. + + If in doubt, say N. =20 config NET_VENDOR_3COM bool "3COM cards" --- linux-2.6.8-rc2-nfpending-tcpwin/drivers/net/sungem.c 2004-07-22 17:48:= 43.000000000 +0200 +++ linux-2.6.8-rc2-nfpending-tcpwin-napi/drivers/net/sungem.c 2004-09-13 1= 5:48:17.299866224 +0200 @@ -5,6 +5,9 @@ *=20 * Support for Apple GMAC and assorted PHYs by * Benjamin Herrenscmidt (benh@kernel.crashing.org) + * + * Support for NAPI and NETPOLL=20 + * (C) 2004 by Harald Welte *=20 * TODO:=20 * - Get rid of all those nasty mdelay's and replace them @@ -187,6 +190,26 @@ printk(KERN_DEBUG "%s: mif interrupt\n", gp->dev->name); } =20 +static inline void +gem_irq_disable(struct gem *gp) +{ + /* Make sure we won't get any more interrupts */ + writel(0xffffffff, gp->regs + GREG_IMASK); +} + +static inline void +gem_irq_enable(struct gem *gp, unsigned int mask) +{ + /* We don't want TXDONE, but all other interrupts */ + writel(mask, gp->regs + GREG_IMASK); +} + +static inline void +gem_irq_acknowledge(struct gem *gp, unsigned int mask) +{ + writel(mask, gp->regs + GREG_IACK); +} + static int gem_pcs_interrupt(struct net_device *dev, struct gem *gp, u32 g= em_status) { u32 pcs_istat =3D readl(gp->regs + PCS_ISTAT); @@ -537,6 +560,7 @@ printk(KERN_DEBUG "%s: no buffer for rx frame\n", gp->dev->name); gp->net_stats.rx_dropped++; + gem_irq_acknowledge(gp, GREG_STAT_RXNOBUF); } =20 if (gem_status & GREG_STAT_RXTAGERR) { @@ -545,6 +569,7 @@ printk(KERN_DEBUG "%s: corrupt rx tag framing\n", gp->dev->name); gp->net_stats.rx_errors++; + gem_irq_acknowledge(gp, GREG_STAT_RXTAGERR); =20 goto do_reset; } @@ -596,6 +621,8 @@ printk(KERN_DEBUG "%s: tx interrupt, gem_status: 0x%x\n", gp->dev->name, gem_status); =20 + gem_irq_acknowledge(gp, GREG_STAT_TXALL|GREG_STAT_TXINTME); + entry =3D gp->tx_old; limit =3D ((gem_status & GREG_STAT_TXNR) >> GREG_STAT_TXNR_SHIFT); while (entry !=3D limit) { @@ -678,7 +705,11 @@ } } =20 +#ifdef CONFIG_SUNGEM_NAPI +static void gem_rx(struct gem *gp, int *work_done, int work_to_do) +#else static void gem_rx(struct gem *gp) +#endif { int entry, drops; u32 done; @@ -687,6 +718,8 @@ printk(KERN_DEBUG "%s: rx interrupt, done: %d, rx_new: %d\n", gp->dev->name, readl(gp->regs + RXDMA_DONE), gp->rx_new); =20 + gem_irq_acknowledge(gp, GREG_STAT_RXDONE); + entry =3D gp->rx_new; drops =3D 0; done =3D readl(gp->regs + RXDMA_DONE); @@ -713,6 +746,11 @@ break; } =20 +#ifdef CONFIG_SUNGEM_NAPI + if (*work_done >=3D work_to_do) + break; + +#endif skb =3D gp->rx_skbs[entry]; =20 len =3D (status & RXDCTRL_BUFSZ) >> 16; @@ -775,7 +813,12 @@ skb->csum =3D ntohs((status & RXDCTRL_TCPCSUM) ^ 0xffff); skb->ip_summed =3D CHECKSUM_HW; skb->protocol =3D eth_type_trans(skb, gp->dev); +#ifdef CONFIG_SUNGEM_NAPI + netif_receive_skb(skb); + (*work_done)++; +#else netif_rx(skb); +#endif =20 gp->net_stats.rx_packets++; gp->net_stats.rx_bytes +=3D len; @@ -798,7 +841,7 @@ { struct net_device *dev =3D dev_id; struct gem *gp =3D dev->priv; - u32 gem_status =3D readl(gp->regs + GREG_STAT); + u32 gem_status =3D readl(gp->regs + GREG_STAT2); =20 /* Swallow interrupts when shutting the chip down */ if (gp->hw_running =3D=3D 0) @@ -810,10 +853,21 @@ if (gem_abnormal_irq(dev, gp, gem_status)) goto out; } + if (gem_status & (GREG_STAT_TXALL | GREG_STAT_TXINTME)) gem_tx(dev, gp, gem_status); - if (gem_status & GREG_STAT_RXDONE) + + if (gem_status & GREG_STAT_RXDONE) { +#ifdef CONFIG_SUNGEM_NAPI + if (netif_rx_schedule_prep(dev)) { + /* Disable interrupts and register for poll */ + gem_irq_disable(gp); + __netif_rx_schedule(dev); + } +#else gem_rx(gp); +#endif + } =20 out: spin_unlock(&gp->lock); @@ -821,6 +875,29 @@ return IRQ_HANDLED; } =20 +#ifdef CONFIG_SUNGEM_NAPI +static int gem_clean(struct net_device *dev, int *budget) +{ + struct gem *gp =3D dev->priv; + int work_to_do =3D min(*budget, dev->quota); + int work_done =3D 0; + u32 gem_status =3D readl(gp->regs + GREG_STAT2); + + if (gem_status & GREG_STAT_RXDONE) + gem_rx(gp, &work_done, work_to_do); + + *budget -=3D work_done; + dev->quota -=3D work_done; + + if (work_done < work_to_do || !netif_running(dev)) { + __netif_rx_complete(dev); + gem_irq_enable(gp, GREG_STAT_TXDONE); + } + + return (work_done >=3D work_to_do); +} +#endif + static void gem_tx_timeout(struct net_device *dev) { struct gem *gp =3D dev->priv; @@ -1018,7 +1096,7 @@ u32 val; =20 /* Make sure we won't get any more interrupts */ - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); =20 /* Reset the chip */ writel(gp->swrst_base | GREG_SWRST_TXRST | GREG_SWRST_RXRST, @@ -1055,7 +1133,7 @@ (void) readl(gp->regs + MAC_RXCFG); udelay(100); =20 - writel(GREG_STAT_TXDONE, gp->regs + GREG_IMASK); + gem_irq_enable(gp, GREG_STAT_TXDONE); =20 writel(RX_RING_SIZE - 4, gp->regs + RXDMA_KICK); =20 @@ -1323,7 +1401,7 @@ /* Make sure we don't get interrupts or tx packets */ netif_stop_queue(gp->dev); =20 - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); =20 /* Reset the chip & rings */ gem_stop(gp); @@ -2220,7 +2298,7 @@ spin_lock_irq(&gp->lock); =20 gp->opened =3D 0;=09 - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); netif_stop_queue(dev); =20 /* Stop chip */ @@ -2264,7 +2342,7 @@ /* Stop traffic, mark us closed */ netif_device_detach(dev); =20 - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); =20 /* Stop chip */ gem_stop(gp); @@ -2651,6 +2729,16 @@ return 0; } =20 +#ifdef CONFIG_NET_POLL_CONTROLLER +static void gem_netpoll(struct net_device *dev) +{ + struct gem *gp =3D dev->priv; + disable_irq(gp->pdev->irq); + gem_interrupt(gp->pdev->irq, dev, NULL); + enable_irq(gp->pdev->irq); +} +#endif + static int __devinit gem_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -2811,6 +2899,15 @@ dev->ethtool_ops =3D &gem_ethtool_ops; dev->tx_timeout =3D gem_tx_timeout; dev->watchdog_timeo =3D 5 * HZ; +#ifdef CONFIG_SUNGEM_NAPI + dev->poll =3D gem_clean; + dev->weight =3D 64; +#endif + +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller =3D gem_netpoll; +#endif + dev->change_mtu =3D gem_change_mtu; dev->irq =3D pdev->irq; dev->dma =3D 0; --I/+EtO164iqGPpU0-- --NctWKJLgDreUm1FS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBRw/JXaXGVTD0i/8RAqbWAJ9wQ63jfE1S7Hi0ob0GvoWfpphUwgCghcQ9 tBj2ztJLdaPem3fw6o/Yils= =Z+UE -----END PGP SIGNATURE----- --NctWKJLgDreUm1FS-- From jgarzik@pobox.com Tue Sep 14 08:56:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 08:57:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EFuqBs003986 for ; Tue, 14 Sep 2004 08:56:53 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7FfJ-0004yi-Ay; Tue, 14 Sep 2004 16:56:21 +0100 Message-ID: <41471498.8010107@pobox.com> Date: Tue, 14 Sep 2004 11:56:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Welte CC: David Miller , netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> In-Reply-To: <20040914153537.GE8434@sunbeam.de.gnumonks.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 7887 Lines: 283 Harald Welte wrote: > Hi Dave! > > Please find the attached patch to add NAPI support to the sungem.c > driver (I was annoyed by the fact the pktgen could kill my Powerbook). > > Since this is my first hack of a network driver within at least 5 years, > please be kind with me and point me to all the locking bugs and other > mistakes ;) > > Any comments welcome, > > Harald > > > > ------------------------------------------------------------------------ > > diff -Nru linux-2.6.8.1-davem269_4/drivers/net/Kconfig linux-2.6.8.1-davem269_4-sungem-napi/drivers/net/Kconfig > --- linux-2.6.8.1-davem269_4/drivers/net/Kconfig 2004-08-14 12:56:00.000000000 +0200 > +++ linux-2.6.8.1-davem269_4-sungem-napi/drivers/net/Kconfig 2004-09-14 11:40:40.000000000 +0200 > @@ -569,6 +569,22 @@ > help > Support for the Sun GEM chip, aka Sun GigabitEthernet/P 2.0. See also > . > +config SUNGEM_NAPI > + bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" > + depends on SUNGEM && EXPERIMENTAL > + help > + NAPI is a new driver API designed to reduce CPU and interrupt load > + when the driver is receiving lots of packets from the card. It is > + still somewhat experimental and thus not yet enabled by default. > + > + If your estimated Rx load is 10kpps or more, or if the card will be > + deployed on potentially unfriendly networks (e.g. in a firewall), > + then say Y here. > + > + See for more > + information. > + > + If in doubt, say N. > > config NET_VENDOR_3COM > bool "3COM cards" > --- linux-2.6.8-rc2-nfpending-tcpwin/drivers/net/sungem.c 2004-07-22 17:48:43.000000000 +0200 > +++ linux-2.6.8-rc2-nfpending-tcpwin-napi/drivers/net/sungem.c 2004-09-13 15:48:17.299866224 +0200 > @@ -5,6 +5,9 @@ > * > * Support for Apple GMAC and assorted PHYs by > * Benjamin Herrenscmidt (benh@kernel.crashing.org) > + * > + * Support for NAPI and NETPOLL > + * (C) 2004 by Harald Welte > * > * TODO: > * - Get rid of all those nasty mdelay's and replace them > @@ -187,6 +190,26 @@ > printk(KERN_DEBUG "%s: mif interrupt\n", gp->dev->name); > } > > +static inline void > +gem_irq_disable(struct gem *gp) > +{ > + /* Make sure we won't get any more interrupts */ > + writel(0xffffffff, gp->regs + GREG_IMASK); > +} > + > +static inline void > +gem_irq_enable(struct gem *gp, unsigned int mask) > +{ > + /* We don't want TXDONE, but all other interrupts */ > + writel(mask, gp->regs + GREG_IMASK); > +} > + > +static inline void > +gem_irq_acknowledge(struct gem *gp, unsigned int mask) > +{ > + writel(mask, gp->regs + GREG_IACK); > +} PCI posting > static int gem_pcs_interrupt(struct net_device *dev, struct gem *gp, u32 gem_status) > { > u32 pcs_istat = readl(gp->regs + PCS_ISTAT); > @@ -537,6 +560,7 @@ > printk(KERN_DEBUG "%s: no buffer for rx frame\n", > gp->dev->name); > gp->net_stats.rx_dropped++; > + gem_irq_acknowledge(gp, GREG_STAT_RXNOBUF); > } > > if (gem_status & GREG_STAT_RXTAGERR) { > @@ -545,6 +569,7 @@ > printk(KERN_DEBUG "%s: corrupt rx tag framing\n", > gp->dev->name); > gp->net_stats.rx_errors++; > + gem_irq_acknowledge(gp, GREG_STAT_RXTAGERR); > > goto do_reset; > } > @@ -596,6 +621,8 @@ > printk(KERN_DEBUG "%s: tx interrupt, gem_status: 0x%x\n", > gp->dev->name, gem_status); > > + gem_irq_acknowledge(gp, GREG_STAT_TXALL|GREG_STAT_TXINTME); Are these in separate functions? If not, it's usually best to go ahead and ACK all the interrupts you are going to handle, in a single IO write (usually _before_ you handle the events). > entry = gp->tx_old; > limit = ((gem_status & GREG_STAT_TXNR) >> GREG_STAT_TXNR_SHIFT); > while (entry != limit) { > @@ -678,7 +705,11 @@ > } > } > > +#ifdef CONFIG_SUNGEM_NAPI > +static void gem_rx(struct gem *gp, int *work_done, int work_to_do) > +#else > static void gem_rx(struct gem *gp) > +#endif > { > int entry, drops; > u32 done; > @@ -687,6 +718,8 @@ > printk(KERN_DEBUG "%s: rx interrupt, done: %d, rx_new: %d\n", > gp->dev->name, readl(gp->regs + RXDMA_DONE), gp->rx_new); > > + gem_irq_acknowledge(gp, GREG_STAT_RXDONE); > + > entry = gp->rx_new; > drops = 0; > done = readl(gp->regs + RXDMA_DONE); > @@ -713,6 +746,11 @@ > break; > } > > +#ifdef CONFIG_SUNGEM_NAPI > + if (*work_done >= work_to_do) > + break; > + > +#endif > skb = gp->rx_skbs[entry]; > > len = (status & RXDCTRL_BUFSZ) >> 16; > @@ -775,7 +813,12 @@ > skb->csum = ntohs((status & RXDCTRL_TCPCSUM) ^ 0xffff); > skb->ip_summed = CHECKSUM_HW; > skb->protocol = eth_type_trans(skb, gp->dev); > +#ifdef CONFIG_SUNGEM_NAPI > + netif_receive_skb(skb); > + (*work_done)++; minor nit: surely it's better code to increment a local variable, then store the local to *work_done once all iterations are complete? > +#else > netif_rx(skb); > +#endif > > gp->net_stats.rx_packets++; > gp->net_stats.rx_bytes += len; > @@ -798,7 +841,7 @@ > { > struct net_device *dev = dev_id; > struct gem *gp = dev->priv; > - u32 gem_status = readl(gp->regs + GREG_STAT); > + u32 gem_status = readl(gp->regs + GREG_STAT2); what does this do? > /* Swallow interrupts when shutting the chip down */ > if (gp->hw_running == 0) > @@ -810,10 +853,21 @@ > if (gem_abnormal_irq(dev, gp, gem_status)) > goto out; > } > + > if (gem_status & (GREG_STAT_TXALL | GREG_STAT_TXINTME)) > gem_tx(dev, gp, gem_status); > - if (gem_status & GREG_STAT_RXDONE) > + > + if (gem_status & GREG_STAT_RXDONE) { > +#ifdef CONFIG_SUNGEM_NAPI > + if (netif_rx_schedule_prep(dev)) { > + /* Disable interrupts and register for poll */ > + gem_irq_disable(gp); > + __netif_rx_schedule(dev); > + } > +#else > gem_rx(gp); > +#endif > + } > > out: > spin_unlock(&gp->lock); > @@ -821,6 +875,29 @@ > return IRQ_HANDLED; > } > > +#ifdef CONFIG_SUNGEM_NAPI > +static int gem_clean(struct net_device *dev, int *budget) > +{ > + struct gem *gp = dev->priv; > + int work_to_do = min(*budget, dev->quota); > + int work_done = 0; > + u32 gem_status = readl(gp->regs + GREG_STAT2); > + > + if (gem_status & GREG_STAT_RXDONE) > + gem_rx(gp, &work_done, work_to_do); > + > + *budget -= work_done; > + dev->quota -= work_done; > + > + if (work_done < work_to_do || !netif_running(dev)) { > + __netif_rx_complete(dev); > + gem_irq_enable(gp, GREG_STAT_TXDONE); > + } > + > + return (work_done >= work_to_do); > +} > +#endif > + > static void gem_tx_timeout(struct net_device *dev) > { > struct gem *gp = dev->priv; > @@ -1018,7 +1096,7 @@ > u32 val; > > /* Make sure we won't get any more interrupts */ > - writel(0xffffffff, gp->regs + GREG_IMASK); > + gem_irq_disable(gp); > > /* Reset the chip */ > writel(gp->swrst_base | GREG_SWRST_TXRST | GREG_SWRST_RXRST, > @@ -1055,7 +1133,7 @@ > (void) readl(gp->regs + MAC_RXCFG); > udelay(100); > > - writel(GREG_STAT_TXDONE, gp->regs + GREG_IMASK); > + gem_irq_enable(gp, GREG_STAT_TXDONE); > > writel(RX_RING_SIZE - 4, gp->regs + RXDMA_KICK); > > @@ -1323,7 +1401,7 @@ > /* Make sure we don't get interrupts or tx packets */ > netif_stop_queue(gp->dev); > > - writel(0xffffffff, gp->regs + GREG_IMASK); > + gem_irq_disable(gp); > > /* Reset the chip & rings */ > gem_stop(gp); > @@ -2220,7 +2298,7 @@ > spin_lock_irq(&gp->lock); > > gp->opened = 0; > - writel(0xffffffff, gp->regs + GREG_IMASK); > + gem_irq_disable(gp); > netif_stop_queue(dev); > > /* Stop chip */ > @@ -2264,7 +2342,7 @@ > /* Stop traffic, mark us closed */ > netif_device_detach(dev); > > - writel(0xffffffff, gp->regs + GREG_IMASK); > + gem_irq_disable(gp); > > /* Stop chip */ > gem_stop(gp); are all these enable/disables inside locks? Jeff From adilger@clusterfs.com Tue Sep 14 09:34:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 09:34:10 -0700 (PDT) Received: from moraine.clusterfs.com (moraine.clusterfs.com [66.246.132.190]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EGY35F005157 for ; Tue, 14 Sep 2004 09:34:04 -0700 Received: from schnapps.adilger.int (localhost.localdomain [127.0.0.1]) by moraine.clusterfs.com (Postfix) with ESMTP id 1D8EE310272; Tue, 14 Sep 2004 12:33:48 -0400 (EDT) Received: by schnapps.adilger.int (Postfix, from userid 1000) id 14E43180C6; Tue, 14 Sep 2004 10:33:47 -0600 (MDT) Date: Tue, 14 Sep 2004 10:33:47 -0600 From: Andreas Dilger To: Denis Vlasenko Cc: linux-kernel@vger.kernel.org, Trond Myklebust , netdev@oss.sgi.com Subject: Re: Kernel stack overflow on 2.6.9-rc2 Message-ID: <20040914163347.GE3197@schnapps.adilger.int> Mail-Followup-To: Denis Vlasenko , linux-kernel@vger.kernel.org, Trond Myklebust , netdev@oss.sgi.com References: <200409141723.35009.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gDGSpKKIBgtShtf+" Content-Disposition: inline In-Reply-To: <200409141723.35009.vda@port.imtp.ilyichevsk.odessa.ua> User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 X-archive-position: 8791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adilger@clusterfs.com Precedence: bulk X-list: netdev Content-Length: 1489 Lines: 51 --gDGSpKKIBgtShtf+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sep 14, 2004 17:23 +0300, Denis Vlasenko wrote: > I am putting to use an ancient box. Pentium 66. > It gives me stack overflow errors on 2.6.9-rc2: >=20 > To save you filtering out functions with less than 100 > bytes of stack: >=20 > udp_sendmsg+0x35e/0x61a [220] > sock_sendmsg+0x88/0xa3 [208] > __nfs_revalidate_inode+0xc7/0x308 [152] > nfs_lookup_revalidate+0x257/0x4ed [312] > load_elf_binary+0xc4f/0xcc8 [268] > load_script+0x1ea/0x220 [136] > do_execve+0x153/0x1b9 [336] do_execve() can be trivially fixed to allocate bprm (328 bytes) instead=20 putting it on the stack. Given the frequency of exec and the odd size it should probably be in its own slab (and fix the goofy prototype indenting while you're there too ;-). load_elf_binary() on the other hand is a big mess, 132 bytes of int/long variables. nfs_lookup_revalidate() has 2 large structs on the stack, fhandle and fattr. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ --gDGSpKKIBgtShtf+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBRx1qpIg59Q01vtYRAlyQAKCsBAF7suX4kERQPLicYhoDRWplLACfW2ZZ f1CYZH/pNdU19NpgsQO9aaw= =pk5q -----END PGP SIGNATURE----- --gDGSpKKIBgtShtf+-- From ak@suse.de Tue Sep 14 09:41:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 09:41:35 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EGfUIm005580 for ; Tue, 14 Sep 2004 09:41:31 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 000FABE75B6; Tue, 14 Sep 2004 18:41:14 +0200 (CEST) Date: Tue, 14 Sep 2004 18:41:14 +0200 From: Andi Kleen To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: network lockup with latest BK (LLTX?) Message-ID: <20040914164114.GF7397@wotan.suse.de> References: <20040914142447.GA5615@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914142447.GA5615@krispykreme> X-archive-position: 8792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 301 Lines: 11 On Wed, Sep 15, 2004 at 12:24:47AM +1000, Anton Blanchard wrote: > > Hi, > > I have a machine with a number of e1000 adapters in it. It locked up > while I was bringing up the network interfaces. I have attached > backtraces of all relevant cpus. See the patch I posted yesterday to netdev. -Andi From natester@gmail.com Tue Sep 14 10:31:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 10:31:15 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EHVAdc007572 for ; Tue, 14 Sep 2004 10:31:10 -0700 Received: by mproxy.gmail.com with SMTP id 74so233615rnk for ; Tue, 14 Sep 2004 10:30:49 -0700 (PDT) Received: by 10.38.67.22 with SMTP id p22mr1102486rna; Tue, 14 Sep 2004 10:30:48 -0700 (PDT) Received: by 10.38.165.5 with HTTP; Tue, 14 Sep 2004 10:30:48 -0700 (PDT) Message-ID: <4adac7a304091410307bd36f7e@mail.gmail.com> Date: Tue, 14 Sep 2004 11:30:48 -0600 From: Nathaniel Haggard Reply-To: nate@securitymetrics.com To: netdev@oss.sgi.com Subject: Intel fw82546eb dual server card with kernel 2.6.8 and 2.6.5 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_33_31530074.1095183048765" X-archive-position: 8793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: natester@gmail.com Precedence: bulk X-list: netdev Content-Length: 37535 Lines: 508 ------=_Part_33_31530074.1095183048765 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline "ifconfig eth0 up" where eth0 is an Intel FW82546EB dual server card makes the machine freeze on both 2.6.5 gentoo SMP and 2.6.8 gentoo SMP kernels. The 2.6.8 kernel produces this error message before freezing: CPU 2: Machine Check Exception: 0000000000000004 The machine is a dual xeon 2.8 GHz. The .config file for the 2.6.5 kernel is attached. The card still works and I can assign it an ip via /etc/init.d/net.eth3 (which uses ifconfig too). Right now the machine is fine and I can't get it to panic the kernel, but I was able to panic the kernel 5 consecutive times before this. Maybe the network card was not seated properly? What are your recommendations for shooting this trouble? Thanks, Nate ------=_Part_33_31530074.1095183048765 Content-Type: application/octet-stream; name=".config" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=".config" IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMKQ09O RklHX1g4Nj15CkNPTkZJR19NTVU9eQpDT05GSUdfVUlEMTY9eQpDT05GSUdfR0VORVJJQ19JU0Ff RE1BPXkKCiMKIyBDb2RlIG1hdHVyaXR5IGxldmVsIG9wdGlvbnMKIwpDT05GSUdfRVhQRVJJTUVO VEFMPXkKQ09ORklHX0NMRUFOX0NPTVBJTEU9eQpDT05GSUdfU1RBTkRBTE9ORT15CgojCiMgR2Vu ZXJhbCBzZXR1cAojCkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQojIENPTkZJR19CU0Rf UFJPQ0VTU19BQ0NUIGlzIG5vdCBzZXQKQ09ORklHX1NZU0NUTD15CkNPTkZJR19MT0dfQlVGX1NI SUZUPTE1CkNPTkZJR19IT1RQTFVHPXkKIyBDT05GSUdfSUtDT05GSUcgaXMgbm90IHNldAojIENP TkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19LQUxMU1lNUz15CkNPTkZJR19GVVRFWD15 CkNPTkZJR19FUE9MTD15CkNPTkZJR19JT1NDSEVEX05PT1A9eQpDT05GSUdfSU9TQ0hFRF9BUz15 CkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKIyBDT05GSUdf Q0NfT1BUSU1JWkVfRk9SX1NJWkUgaXMgbm90IHNldAoKIwojIExvYWRhYmxlIG1vZHVsZSBzdXBw b3J0CiMKQ09ORklHX01PRFVMRVM9eQpDT05GSUdfTU9EVUxFX1VOTE9BRD15CiMgQ09ORklHX01P RFVMRV9GT1JDRV9VTkxPQUQgaXMgbm90IHNldApDT05GSUdfT0JTT0xFVEVfTU9EUEFSTT15CiMg Q09ORklHX01PRFZFUlNJT05TIGlzIG5vdCBzZXQKQ09ORklHX0tNT0Q9eQpDT05GSUdfU1RPUF9N QUNISU5FPXkKCiMKIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVhdHVyZXMKIwpDT05GSUdfWDg2X1BD PXkKIyBDT05GSUdfWDg2X0VMQU4gaXMgbm90IHNldAojIENPTkZJR19YODZfVk9ZQUdFUiBpcyBu b3Qgc2V0CiMgQ09ORklHX1g4Nl9OVU1BUSBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9TVU1NSVQg aXMgbm90IHNldAojIENPTkZJR19YODZfQklHU01QIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1ZJ U1dTIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X0dFTkVSSUNBUkNIIGlzIG5vdCBzZXQKIyBDT05G SUdfWDg2X0VTNzAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX00zODYgaXMgbm90IHNldAojIENPTkZJ R19NNDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfTTU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX001ODZU U0MgaXMgbm90IHNldAojIENPTkZJR19NNTg2TU1YIGlzIG5vdCBzZXQKIyBDT05GSUdfTTY4NiBp cyBub3Qgc2V0CiMgQ09ORklHX01QRU5USVVNSUkgaXMgbm90IHNldAojIENPTkZJR19NUEVOVElV TUlJSSBpcyBub3Qgc2V0CiMgQ09ORklHX01QRU5USVVNTSBpcyBub3Qgc2V0CkNPTkZJR19NUEVO VElVTTQ9eQojIENPTkZJR19NSzYgaXMgbm90IHNldAojIENPTkZJR19NSzcgaXMgbm90IHNldAoj IENPTkZJR19NSzggaXMgbm90IHNldAojIENPTkZJR19NQ1JVU09FIGlzIG5vdCBzZXQKIyBDT05G SUdfTVdJTkNISVBDNiBpcyBub3Qgc2V0CiMgQ09ORklHX01XSU5DSElQMiBpcyBub3Qgc2V0CiMg Q09ORklHX01XSU5DSElQM0QgaXMgbm90IHNldAojIENPTkZJR19NQ1lSSVhJSUkgaXMgbm90IHNl dAojIENPTkZJR19NVklBQzNfMiBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9HRU5FUklDIGlzIG5v dCBzZXQKQ09ORklHX1g4Nl9DTVBYQ0hHPXkKQ09ORklHX1g4Nl9YQUREPXkKQ09ORklHX1g4Nl9M MV9DQUNIRV9TSElGVD03CkNPTkZJR19SV1NFTV9YQ0hHQUREX0FMR09SSVRITT15CkNPTkZJR19Y ODZfV1BfV09SS1NfT0s9eQpDT05GSUdfWDg2X0lOVkxQRz15CkNPTkZJR19YODZfQlNXQVA9eQpD T05GSUdfWDg2X1BPUEFEX09LPXkKQ09ORklHX1g4Nl9HT09EX0FQSUM9eQpDT05GSUdfWDg2X0lO VEVMX1VTRVJDT1BZPXkKQ09ORklHX1g4Nl9VU0VfUFBST19DSEVDS1NVTT15CkNPTkZJR19IUEVU X1RJTUVSPXkKIyBDT05GSUdfSFBFVF9FTVVMQVRFX1JUQyBpcyBub3Qgc2V0CkNPTkZJR19TTVA9 eQpDT05GSUdfTlJfQ1BVUz04CiMgQ09ORklHX1BSRUVNUFQgaXMgbm90IHNldAojIENPTkZJR19S VElSUSBpcyBub3Qgc2V0CkNPTkZJR19YODZfTE9DQUxfQVBJQz15CkNPTkZJR19YODZfSU9fQVBJ Qz15CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9NQ0U9eQpDT05GSUdfWDg2X01DRV9OT05G QVRBTD15CiMgQ09ORklHX1g4Nl9NQ0VfUDRUSEVSTUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9T SElCQSBpcyBub3Qgc2V0CiMgQ09ORklHX0k4SyBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JPQ09E RSBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9NU1IgaXMgbm90IHNldAojIENPTkZJR19YODZfQ1BV SUQgaXMgbm90IHNldAoKIwojIEZpcm13YXJlIERyaXZlcnMKIwojIENPTkZJR19FREQgaXMgbm90 IHNldApDT05GSUdfTk9ISUdITUVNPXkKIyBDT05GSUdfSElHSE1FTTRHIGlzIG5vdCBzZXQKIyBD T05GSUdfSElHSE1FTTY0RyBpcyBub3Qgc2V0CiMgQ09ORklHX01BVEhfRU1VTEFUSU9OIGlzIG5v dCBzZXQKQ09ORklHX01UUlI9eQojIENPTkZJR19FRkkgaXMgbm90IHNldApDT05GSUdfSVJRQkFM QU5DRT15CkNPTkZJR19IQVZFX0RFQ19MT0NLPXkKIyBDT05GSUdfUkVHUEFSTSBpcyBub3Qgc2V0 CgojCiMgUG93ZXIgbWFuYWdlbWVudCBvcHRpb25zIChBQ1BJLCBBUE0pCiMKQ09ORklHX1BNPXkK Q09ORklHX1NPRlRXQVJFX1NVU1BFTkQ9eQojIENPTkZJR19QTV9ESVNLIGlzIG5vdCBzZXQKCiMK IyBBQ1BJIChBZHZhbmNlZCBDb25maWd1cmF0aW9uIGFuZCBQb3dlciBJbnRlcmZhY2UpIFN1cHBv cnQKIwpDT05GSUdfQUNQST15CkNPTkZJR19BQ1BJX0JPT1Q9eQpDT05GSUdfQUNQSV9JTlRFUlBS RVRFUj15CkNPTkZJR19BQ1BJX1NMRUVQPXkKQ09ORklHX0FDUElfU0xFRVBfUFJPQ19GUz15CkNP TkZJR19BQ1BJX0FDPXkKQ09ORklHX0FDUElfQkFUVEVSWT15CkNPTkZJR19BQ1BJX0JVVFRPTj15 CkNPTkZJR19BQ1BJX0ZBTj15CkNPTkZJR19BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19BQ1BJX1RI RVJNQUw9eQojIENPTkZJR19BQ1BJX0FTVVMgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX1RPU0hJ QkEgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0FDUElf QlVTPXkKQ09ORklHX0FDUElfRUM9eQpDT05GSUdfQUNQSV9QT1dFUj15CkNPTkZJR19BQ1BJX1BD ST15CkNPTkZJR19BQ1BJX1NZU1RFTT15CiMgQ09ORklHX1g4Nl9QTV9USU1FUiBpcyBub3Qgc2V0 CgojCiMgQVBNIChBZHZhbmNlZCBQb3dlciBNYW5hZ2VtZW50KSBCSU9TIFN1cHBvcnQKIwojIENP TkZJR19BUE0gaXMgbm90IHNldAoKIwojIENQVSBGcmVxdWVuY3kgc2NhbGluZwojCiMgQ09ORklH X0NQVV9GUkVRIGlzIG5vdCBzZXQKCiMKIyBCdXMgb3B0aW9ucyAoUENJLCBQQ01DSUEsIEVJU0Es IE1DQSwgSVNBKQojCkNPTkZJR19QQ0k9eQojIENPTkZJR19QQ0lfR09CSU9TIGlzIG5vdCBzZXQK IyBDT05GSUdfUENJX0dPTU1DT05GSUcgaXMgbm90IHNldAojIENPTkZJR19QQ0lfR09ESVJFQ1Qg aXMgbm90IHNldApDT05GSUdfUENJX0dPQU5ZPXkKQ09ORklHX1BDSV9CSU9TPXkKQ09ORklHX1BD SV9ESVJFQ1Q9eQpDT05GSUdfUENJX01NQ09ORklHPXkKIyBDT05GSUdfUENJX1VTRV9WRUNUT1Ig aXMgbm90IHNldApDT05GSUdfUENJX0xFR0FDWV9QUk9DPXkKQ09ORklHX1BDSV9OQU1FUz15CkNP TkZJR19JU0E9eQojIENPTkZJR19FSVNBIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNBIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0N4MjAwIGlzIG5vdCBzZXQKCiMKIyBQQ01DSUEvQ2FyZEJ1cyBzdXBwb3J0 CiMKIyBDT05GSUdfUENNQ0lBIGlzIG5vdCBzZXQKQ09ORklHX1BDTUNJQV9QUk9CRT15CgojCiMg UENJIEhvdHBsdWcgU3VwcG9ydAojCiMgQ09ORklHX0hPVFBMVUdfUENJIGlzIG5vdCBzZXQKCiMK IyBFeGVjdXRhYmxlIGZpbGUgZm9ybWF0cwojCkNPTkZJR19CSU5GTVRfRUxGPXkKQ09ORklHX0JJ TkZNVF9BT1VUPXkKQ09ORklHX0JJTkZNVF9NSVNDPXkKCiMKIyBEZXZpY2UgRHJpdmVycwojCgoj CiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19GV19MT0FERVI9bQoKIwojIE1lbW9y eSBUZWNobm9sb2d5IERldmljZXMgKE1URCkKIwojIENPTkZJR19NVEQgaXMgbm90IHNldAoKIwoj IFBhcmFsbGVsIHBvcnQgc3VwcG9ydAojCkNPTkZJR19QQVJQT1JUPXkKQ09ORklHX1BBUlBPUlRf UEM9eQpDT05GSUdfUEFSUE9SVF9QQ19DTUwxPXkKIyBDT05GSUdfUEFSUE9SVF9TRVJJQUwgaXMg bm90IHNldAojIENPTkZJR19QQVJQT1JUX1BDX0ZJRk8gaXMgbm90IHNldAojIENPTkZJR19QQVJQ T1JUX1BDX1NVUEVSSU8gaXMgbm90IHNldAojIENPTkZJR19QQVJQT1JUX09USEVSIGlzIG5vdCBz ZXQKIyBDT05GSUdfUEFSUE9SVF8xMjg0IGlzIG5vdCBzZXQKCiMKIyBQbHVnIGFuZCBQbGF5IHN1 cHBvcnQKIwpDT05GSUdfUE5QPXkKIyBDT05GSUdfUE5QX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBQ cm90b2NvbHMKIwojIENPTkZJR19JU0FQTlAgaXMgbm90IHNldAojIENPTkZJR19QTlBCSU9TIGlz IG5vdCBzZXQKCiMKIyBCbG9jayBkZXZpY2VzCiMKQ09ORklHX0JMS19ERVZfRkQ9eQojIENPTkZJ R19CTEtfREVWX1hEIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSSURFIGlzIG5vdCBzZXQKIyBDT05G SUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qg c2V0CiMgQ09ORklHX0JMS19ERVZfREFDOTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9V TUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9MT09QIGlzIG5vdCBzZXQKIyBDT05GSUdf QkxLX0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NBUk1FTCBpcyBub3Qgc2V0 CiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBzZXQKQ09ORklHX0xCRD15CgojCiMgQVRBL0FU QVBJL01GTS9STEwgc3VwcG9ydAojCkNPTkZJR19JREU9eQpDT05GSUdfQkxLX0RFVl9JREU9eQoK IwojIFBsZWFzZSBzZWUgRG9jdW1lbnRhdGlvbi9pZGUudHh0IGZvciBoZWxwL2luZm8gb24gSURF IGRyaXZlcwojCiMgQ09ORklHX0JMS19ERVZfSERfSURFIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E RVZfSURFRElTSz15CkNPTkZJR19JREVESVNLX01VTFRJX01PREU9eQojIENPTkZJR19JREVESVNL X1NUUk9LRSBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lERUNEPXkKIyBDT05GSUdfQkxLX0RF Vl9JREVUQVBFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9JREVGTE9QUFkgaXMgbm90IHNl dAojIENPTkZJR19CTEtfREVWX0lERVNDU0kgaXMgbm90IHNldAojIENPTkZJR19JREVfVEFTS19J T0NUTCBpcyBub3Qgc2V0CkNPTkZJR19JREVfVEFTS0ZJTEVfSU89eQoKIwojIElERSBjaGlwc2V0 IHN1cHBvcnQvYnVnZml4ZXMKIwpDT05GSUdfSURFX0dFTkVSSUM9eQpDT05GSUdfQkxLX0RFVl9D TUQ2NDA9eQojIENPTkZJR19CTEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qgc2V0CiMgQ09O RklHX0JMS19ERVZfSURFUE5QIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSURFUENJPXkKQ09O RklHX0lERVBDSV9TSEFSRV9JUlE9eQojIENPTkZJR19CTEtfREVWX09GRkJPQVJEIGlzIG5vdCBz ZXQKQ09ORklHX0JMS19ERVZfR0VORVJJQz15CiMgQ09ORklHX0JMS19ERVZfT1BUSTYyMSBpcyBu b3Qgc2V0CkNPTkZJR19CTEtfREVWX1JaMTAwMD15CkNPTkZJR19CTEtfREVWX0lERURNQV9QQ0k9 eQojIENPTkZJR19CTEtfREVWX0lERURNQV9GT1JDRUQgaXMgbm90IHNldApDT05GSUdfSURFRE1B X1BDSV9BVVRPPXkKIyBDT05GSUdfSURFRE1BX09OTFlESVNLIGlzIG5vdCBzZXQKQ09ORklHX0JM S19ERVZfQURNQT15CiMgQ09ORklHX0JMS19ERVZfQUVDNjJYWCBpcyBub3Qgc2V0CiMgQ09ORklH X0JMS19ERVZfQUxJMTVYMyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfQU1ENzRYWCBpcyBu b3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfQVRJSVhQIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF Vl9DTUQ2NFggaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1RSSUZMRVggaXMgbm90IHNldAoj IENPTkZJR19CTEtfREVWX0NZODJDNjkzIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9DUzU1 MjAgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NTNTUzMCBpcyBub3Qgc2V0CiMgQ09ORklH X0JMS19ERVZfSFBUMzRYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9IUFQzNjYgaXMgbm90 IHNldAojIENPTkZJR19CTEtfREVWX1NDMTIwMCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX1BJ SVg9eQojIENPTkZJR19CTEtfREVWX05TODc0MTUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVW X1BEQzIwMlhYX09MRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfUERDMjAyWFhfTkVXIGlz IG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TVldLUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19E RVZfU0lJTUFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfU0lTNTUxMyBpcyBub3Qgc2V0 CiMgQ09ORklHX0JMS19ERVZfU0xDOTBFNjYgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1RS TTI5MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfVklBODJDWFhYIGlzIG5vdCBzZXQKIyBD T05GSUdfSURFX0NISVBTRVRTIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSURFRE1BPXkKIyBD T05GSUdfSURFRE1BX0lWQiBpcyBub3Qgc2V0CkNPTkZJR19JREVETUFfQVVUTz15CiMgQ09ORklH X0JMS19ERVZfSEQgaXMgbm90IHNldAoKIwojIFNDU0kgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdf U0NTST15CkNPTkZJR19TQ1NJX1BST0NfRlM9eQoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNr LCB0YXBlLCBDRC1ST00pCiMKQ09ORklHX0JMS19ERVZfU0Q9eQojIENPTkZJR19DSFJfREVWX1NU IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxL X0RFVl9TUiBpcyBub3Qgc2V0CkNPTkZJR19DSFJfREVWX1NHPXkKCiMKIyBTb21lIFNDU0kgZGV2 aWNlcyAoZS5nLiBDRCBqdWtlYm94KSBzdXBwb3J0IG11bHRpcGxlIExVTnMKIwojIENPTkZJR19T Q1NJX01VTFRJX0xVTiBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1JFUE9SVF9MVU5TPXkKIyBDT05G SUdfU0NTSV9DT05TVEFOVFMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0xPR0dJTkcgaXMgbm90 IHNldAoKIwojIFNDU0kgVHJhbnNwb3J0IEF0dHJpYnV0ZXMKIwojIENPTkZJR19TQ1NJX1NQSV9B VFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRkNfQVRUUlMgaXMgbm90IHNldAoKIwojIFND U0kgbG93LWxldmVsIGRyaXZlcnMKIwojIENPTkZJR19CTEtfREVWXzNXX1hYWFhfUkFJRCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfNzAwMEZBU1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9B Q0FSRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQUhBMTUyWCBpcyBub3Qgc2V0CiMgQ09ORklH X1NDU0lfQUhBMTU0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQUFDUkFJRCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NDU0lfQUlDN1hYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQUlDN1hYWF9P TEQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzc5WFggaXMgbm90IHNldAojIENPTkZJR19T Q1NJX0FEVkFOU1lTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JTjIwMDAgaXMgbm90IHNldAoj IENPTkZJR19TQ1NJX01FR0FSQUlEIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU0FUQT15CiMgQ09O RklHX1NDU0lfU0FUQV9TVlcgaXMgbm90IHNldApDT05GSUdfU0NTSV9BVEFfUElJWD15CiMgQ09O RklHX1NDU0lfU0FUQV9QUk9NSVNFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQVRBX1NJTCBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU0FUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJ X1NBVEFfVklURVNTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQlVTTE9HSUMgaXMgbm90IHNl dAojIENPTkZJR19TQ1NJX0NQUUZDVFMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RNWDMxOTFE IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9EVEMzMjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT SV9FQVRBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDU0lfRlVUVVJFX0RPTUFJTiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfR0RUSCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfR0VORVJJQ19OQ1I1MzgwIGlzIG5vdCBzZXQKIyBDT05GSUdf U0NTSV9HRU5FUklDX05DUjUzODBfTU1JTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSVBTIGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9Q UEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lNTSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf TkNSNTNDNDA2QSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU1lNNTNDOFhYXzIgaXMgbm90IHNl dAojIENPTkZJR19TQ1NJX1BBUzE2IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9QU0kyNDBJIGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfRkFTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT SV9RTE9HSUNfSVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfRkMgaXMgbm90IHNl dAojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgwIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfUUxBMlhY WD15CiMgQ09ORklHX1NDU0lfUUxBMjFYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBMjJY WCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBMjMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfUUxBMjMyMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBNjMxMiBpcyBub3Qgc2V0CiMg Q09ORklHX1NDU0lfUUxBNjMyMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU1lNNTNDNDE2IGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9EQzM5NXggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RD MzkwVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfVDEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfVTE0XzM0RiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfVUxUUkFTVE9SIGlzIG5vdCBzZXQK IyBDT05GSUdfU0NTSV9OU1AzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREVCVUcgaXMgbm90 IHNldAoKIwojIE9sZCBDRC1ST00gZHJpdmVycyAobm90IFNDU0ksIG5vdCBJREUpCiMKIyBDT05G SUdfQ0RfTk9fSURFU0NTSSBpcyBub3Qgc2V0CgojCiMgTXVsdGktZGV2aWNlIHN1cHBvcnQgKFJB SUQgYW5kIExWTSkKIwojIENPTkZJR19NRCBpcyBub3Qgc2V0CgojCiMgRnVzaW9uIE1QVCBkZXZp Y2Ugc3VwcG9ydAojCiMgQ09ORklHX0ZVU0lPTiBpcyBub3Qgc2V0CgojCiMgSUVFRSAxMzk0IChG aXJlV2lyZSkgc3VwcG9ydAojCkNPTkZJR19JRUVFMTM5ND15CgojCiMgU3Vic3lzdGVtIE9wdGlv bnMKIwojIENPTkZJR19JRUVFMTM5NF9WRVJCT1NFREVCVUcgaXMgbm90IHNldAojIENPTkZJR19J RUVFMTM5NF9PVUlfREIgaXMgbm90IHNldAojIENPTkZJR19JRUVFMTM5NF9FWFRSQV9DT05GSUdf Uk9NUyBpcyBub3Qgc2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwoKIwojIFRleGFzIEluc3RydW1l bnRzIFBDSUx5bnggcmVxdWlyZXMgSTJDCiMKQ09ORklHX0lFRUUxMzk0X09IQ0kxMzk0PXkKCiMK IyBQcm90b2NvbCBEcml2ZXJzCiMKIyBDT05GSUdfSUVFRTEzOTRfVklERU8xMzk0IGlzIG5vdCBz ZXQKIyBDT05GSUdfSUVFRTEzOTRfU0JQMiBpcyBub3Qgc2V0CiMgQ09ORklHX0lFRUUxMzk0X0VU SDEzOTQgaXMgbm90IHNldAojIENPTkZJR19JRUVFMTM5NF9EVjEzOTQgaXMgbm90IHNldApDT05G SUdfSUVFRTEzOTRfUkFXSU89eQojIENPTkZJR19JRUVFMTM5NF9DTVAgaXMgbm90IHNldAoKIwoj IEkyTyBkZXZpY2Ugc3VwcG9ydAojCiMgQ09ORklHX0kyTyBpcyBub3Qgc2V0CgojCiMgTmV0d29y a2luZyBzdXBwb3J0CiMKQ09ORklHX05FVD15CgojCiMgTmV0d29ya2luZyBvcHRpb25zCiMKQ09O RklHX1BBQ0tFVD15CkNPTkZJR19QQUNLRVRfTU1BUD15CiMgQ09ORklHX05FVExJTktfREVWIGlz IG5vdCBzZXQKQ09ORklHX1VOSVg9eQpDT05GSUdfUklORz15CiMgQ09ORklHX05FVF9LRVkgaXMg bm90IHNldApDT05GSUdfSU5FVD15CkNPTkZJR19JUF9NVUxUSUNBU1Q9eQojIENPTkZJR19JUF9B RFZBTkNFRF9ST1VURVIgaXMgbm90IHNldAojIENPTkZJR19JUF9QTlAgaXMgbm90IHNldAojIENP TkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUEdSRSBpcyBub3Qgc2V0CiMg Q09ORklHX0lQX01ST1VURSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSUEQgaXMgbm90IHNldAojIENP TkZJR19TWU5fQ09PS0lFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfQUggaXMgbm90IHNldAoj IENPTkZJR19JTkVUX0VTUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfSVBDT01QIGlzIG5vdCBz ZXQKCiMKIyBJUDogVmlydHVhbCBTZXJ2ZXIgQ29uZmlndXJhdGlvbgojCiMgQ09ORklHX0lQX1ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNiBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQ05FVCBpcyBu b3Qgc2V0CkNPTkZJR19CUklER0U9eQpDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklM VEVSX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0JSSURHRV9ORVRGSUxURVI9eQoKIwojIElQOiBO ZXRmaWx0ZXIgQ29uZmlndXJhdGlvbgojCkNPTkZJR19JUF9ORl9DT05OVFJBQ0s9eQojIENPTkZJ R19JUF9ORl9GVFAgaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9JUkMgaXMgbm90IHNldAojIENP TkZJR19JUF9ORl9URlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfQU1BTkRBIGlzIG5vdCBz ZXQKQ09ORklHX0lQX05GX1FVRVVFPXkKQ09ORklHX0lQX05GX0lQVEFCTEVTPXkKQ09ORklHX0lQ X05GX01BVENIX0xJTUlUPXkKQ09ORklHX0lQX05GX01BVENIX0lQUkFOR0U9eQpDT05GSUdfSVBf TkZfTUFUQ0hfTUFDPXkKQ09ORklHX0lQX05GX01BVENIX1BLVFRZUEU9eQpDT05GSUdfSVBfTkZf TUFUQ0hfTUFSSz15CkNPTkZJR19JUF9ORl9NQVRDSF9NVUxUSVBPUlQ9eQpDT05GSUdfSVBfTkZf TUFUQ0hfVE9TPXkKQ09ORklHX0lQX05GX01BVENIX1JFQ0VOVD15CkNPTkZJR19JUF9ORl9NQVRD SF9FQ049eQpDT05GSUdfSVBfTkZfTUFUQ0hfRFNDUD15CkNPTkZJR19JUF9ORl9NQVRDSF9BSF9F U1A9eQpDT05GSUdfSVBfTkZfTUFUQ0hfTEVOR1RIPXkKQ09ORklHX0lQX05GX01BVENIX1RUTD15 CkNPTkZJR19JUF9ORl9NQVRDSF9UQ1BNU1M9eQpDT05GSUdfSVBfTkZfTUFUQ0hfSEVMUEVSPXkK Q09ORklHX0lQX05GX01BVENIX1NUQVRFPXkKQ09ORklHX0lQX05GX01BVENIX0NPTk5UUkFDSz15 CkNPTkZJR19JUF9ORl9NQVRDSF9PV05FUj15CiMgQ09ORklHX0lQX05GX01BVENIX1BIWVNERVYg aXMgbm90IHNldApDT05GSUdfSVBfTkZfRklMVEVSPXkKQ09ORklHX0lQX05GX1RBUkdFVF9SRUpF Q1Q9eQpDT05GSUdfSVBfTkZfTkFUPXkKQ09ORklHX0lQX05GX05BVF9ORUVERUQ9eQpDT05GSUdf SVBfTkZfVEFSR0VUX01BU1FVRVJBREU9eQpDT05GSUdfSVBfTkZfVEFSR0VUX1JFRElSRUNUPXkK Q09ORklHX0lQX05GX1RBUkdFVF9ORVRNQVA9eQpDT05GSUdfSVBfTkZfVEFSR0VUX1NBTUU9eQoj IENPTkZJR19JUF9ORl9OQVRfTE9DQUwgaXMgbm90IHNldAojIENPTkZJR19JUF9ORl9OQVRfU05N UF9CQVNJQyBpcyBub3Qgc2V0CkNPTkZJR19JUF9ORl9NQU5HTEU9eQpDT05GSUdfSVBfTkZfVEFS R0VUX1RPUz15CkNPTkZJR19JUF9ORl9UQVJHRVRfRUNOPXkKQ09ORklHX0lQX05GX1RBUkdFVF9E U0NQPXkKQ09ORklHX0lQX05GX1RBUkdFVF9NQVJLPXkKQ09ORklHX0lQX05GX1RBUkdFVF9DTEFT U0lGWT15CkNPTkZJR19JUF9ORl9UQVJHRVRfTE9HPXkKQ09ORklHX0lQX05GX1RBUkdFVF9VTE9H PXkKQ09ORklHX0lQX05GX1RBUkdFVF9UQ1BNU1M9eQpDT05GSUdfSVBfTkZfQVJQVEFCTEVTPXkK Q09ORklHX0lQX05GX0FSUEZJTFRFUj15CkNPTkZJR19JUF9ORl9BUlBfTUFOR0xFPXkKCiMKIyBC cmlkZ2U6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKIyBDT05GSUdfQlJJREdFX05GX0VCVEFC TEVTIGlzIG5vdCBzZXQKCiMKIyBTQ1RQIENvbmZpZ3VyYXRpb24gKEVYUEVSSU1FTlRBTCkKIwoj IENPTkZJR19JUF9TQ1RQIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05G SUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJ R19JUFggaXMgbm90IHNldAojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0CiMgQ09ORklHX1gyNSBp cyBub3Qgc2V0CiMgQ09ORklHX0xBUEIgaXMgbm90IHNldAojIENPTkZJR19ORVRfRElWRVJUIGlz IG5vdCBzZXQKIyBDT05GSUdfRUNPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FOX1JPVVRFUiBp cyBub3Qgc2V0CiMgQ09ORklHX05FVF9GQVNUUk9VVEUgaXMgbm90IHNldAojIENPTkZJR19ORVRf SFdfRkxPV0NPTlRST0wgaXMgbm90IHNldAoKIwojIFFvUyBhbmQvb3IgZmFpciBxdWV1ZWluZwoj CiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0CgojCiMgTmV0d29yayB0ZXN0aW5nCiMKIyBD T05GSUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJQ0VTPXkKCiMKIyBBUkNu ZXQgZGV2aWNlcwojCiMgQ09ORklHX0FSQ05FVCBpcyBub3Qgc2V0CkNPTkZJR19EVU1NWT1tCiMg Q09ORklHX0JPTkRJTkcgaXMgbm90IHNldAojIENPTkZJR19FUVVBTElaRVIgaXMgbm90IHNldAoj IENPTkZJR19UVU4gaXMgbm90IHNldAojIENPTkZJR19ORVRfU0IxMDAwIGlzIG5vdCBzZXQKCiMK IyBFdGhlcm5ldCAoMTAgb3IgMTAwTWJpdCkKIwpDT05GSUdfTkVUX0VUSEVSTkVUPXkKQ09ORklH X01JST15CiMgQ09ORklHX0hBUFBZTUVBTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NVTkdFTSBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfM0NPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0xBTkNF IGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1ZFTkRPUl9TTUMgaXMgbm90IHNldAojIENPTkZJR19O RVRfVkVORE9SX1JBQ0FMIGlzIG5vdCBzZXQKCiMKIyBUdWxpcCBmYW1pbHkgbmV0d29yayBkZXZp Y2Ugc3VwcG9ydAojCiMgQ09ORklHX05FVF9UVUxJUCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUMTcw MCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFUENBIGlzIG5vdCBzZXQKIyBDT05GSUdfSFAxMDAgaXMg bm90IHNldAojIENPTkZJR19ORVRfSVNBIGlzIG5vdCBzZXQKQ09ORklHX05FVF9QQ0k9eQojIENP TkZJR19QQ05FVDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfQU1EODExMV9FVEggaXMgbm90IHNldAoj IENPTkZJR19BREFQVEVDX1NUQVJGSVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfQUMzMjAwIGlzIG5v dCBzZXQKIyBDT05GSUdfQVBSSUNPVCBpcyBub3Qgc2V0CiMgQ09ORklHX0I0NCBpcyBub3Qgc2V0 CiMgQ09ORklHX0ZPUkNFREVUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0NTODl4MCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RHUlMgaXMgbm90IHNldApDT05GSUdfRUVQUk8xMDA9bQojIENPTkZJR19FRVBS TzEwMF9QSU8gaXMgbm90IHNldAojIENPTkZJR19FMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkVB TE5YIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFUU0VNSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FMktf UENJIGlzIG5vdCBzZXQKIyBDT05GSUdfODEzOUNQIGlzIG5vdCBzZXQKIyBDT05GSUdfODEzOVRP TyBpcyBub3Qgc2V0CiMgQ09ORklHX1NJUzkwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0VQSUMxMDAg aXMgbm90IHNldAojIENPTkZJR19TVU5EQU5DRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RMQU4gaXMg bm90IHNldAojIENPTkZJR19WSUFfUkhJTkUgaXMgbm90IHNldAojIENPTkZJR19ORVRfUE9DS0VU IGlzIG5vdCBzZXQKCiMKIyBFdGhlcm5ldCAoMTAwMCBNYml0KQojCiMgQ09ORklHX0FDRU5JQyBp cyBub3Qgc2V0CiMgQ09ORklHX0RMMksgaXMgbm90IHNldApDT05GSUdfRTEwMDA9bQpDT05GSUdf RTEwMDBfTkFQST15CiMgQ09ORklHX05TODM4MjAgaXMgbm90IHNldAojIENPTkZJR19IQU1BQ0hJ IGlzIG5vdCBzZXQKIyBDT05GSUdfWUVMTE9XRklOIGlzIG5vdCBzZXQKIyBDT05GSUdfUjgxNjkg aXMgbm90IHNldAojIENPTkZJR19TSVMxOTAgaXMgbm90IHNldAojIENPTkZJR19TSzk4TElOIGlz IG5vdCBzZXQKIyBDT05GSUdfVElHT04zIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0JST0FEQ09N IGlzIG5vdCBzZXQKCiMKIyBFdGhlcm5ldCAoMTAwMDAgTWJpdCkKIwojIENPTkZJR19JWEdCIGlz IG5vdCBzZXQKIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJUFBJIGlzIG5vdCBz ZXQKIyBDT05GSUdfUExJUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0CiMgQ09O RklHX1NMSVAgaXMgbm90IHNldAoKIwojIFdpcmVsZXNzIExBTiAobm9uLWhhbXJhZGlvKQojCiMg Q09ORklHX05FVF9SQURJTyBpcyBub3Qgc2V0CgojCiMgVG9rZW4gUmluZyBkZXZpY2VzCiMKIyBD T05GSUdfVFIgaXMgbm90IHNldAojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldAojIENPTkZJR19S Q1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NIQVBFUiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVENP TlNPTEUgaXMgbm90IHNldAoKIwojIFdhbiBpbnRlcmZhY2VzCiMKIyBDT05GSUdfV0FOIGlzIG5v dCBzZXQKCiMKIyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQKIwojIENPTkZJR19IQU1SQURJTyBpcyBu b3Qgc2V0CgojCiMgSXJEQSAoaW5mcmFyZWQpIHN1cHBvcnQKIwojIENPTkZJR19JUkRBIGlzIG5v dCBzZXQKCiMKIyBCbHVldG9vdGggc3VwcG9ydAojCiMgQ09ORklHX0JUIGlzIG5vdCBzZXQKIyBD T05GSUdfTkVUUE9MTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9QT0xMX0NPTlRST0xMRVIgaXMg bm90IHNldAoKIwojIElTRE4gc3Vic3lzdGVtCiMKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0Cgoj CiMgVGVsZXBob255IFN1cHBvcnQKIwojIENPTkZJR19QSE9ORSBpcyBub3Qgc2V0CgojCiMgSW5w dXQgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQoKIwojIFVzZXJsYW5kIGludGVyZmFj ZXMKIwpDT05GSUdfSU5QVVRfTU9VU0VERVY9eQpDT05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVg9 eQpDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VE RVZfU0NSRUVOX1k9NzY4CiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0CiMgQ09ORklH X0lOUFVUX1RTREVWIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfRVZERVYgaXMgbm90IHNldAoj IENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qgc2V0CgojCiMgSW5wdXQgSS9PIGRyaXZlcnMKIwoj IENPTkZJR19HQU1FUE9SVCBpcyBub3Qgc2V0CkNPTkZJR19TT1VORF9HQU1FUE9SVD15CkNPTkZJ R19TRVJJTz15CkNPTkZJR19TRVJJT19JODA0Mj15CiMgQ09ORklHX1NFUklPX1NFUlBPUlQgaXMg bm90IHNldAojIENPTkZJR19TRVJJT19DVDgyQzcxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklP X1BBUktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BDSVBTMiBpcyBub3Qgc2V0CgojCiMg SW5wdXQgRGV2aWNlIERyaXZlcnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQpDT05GSUdfS0VZ Qk9BUkRfQVRLQkQ9eQojIENPTkZJR19LRVlCT0FSRF9TVU5LQkQgaXMgbm90IHNldAojIENPTkZJ R19LRVlCT0FSRF9MS0tCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1hUS0JEIGlzIG5v dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTkVXVE9OIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01P VVNFPXkKQ09ORklHX01PVVNFX1BTMj15CiMgQ09ORklHX01PVVNFX1NFUklBTCBpcyBub3Qgc2V0 CiMgQ09ORklHX01PVVNFX0lOUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX0xPR0lCTSBp cyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1BDMTEwUEFEIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9V U0VfVlNYWFhBQSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5QVVRfVE9VQ0hTQ1JFRU4gaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9NSVND IGlzIG5vdCBzZXQKCiMKIyBDaGFyYWN0ZXIgZGV2aWNlcwojCkNPTkZJR19WVD15CkNPTkZJR19W VF9DT05TT0xFPXkKQ09ORklHX0hXX0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfTk9OU1RBTkRB UkQgaXMgbm90IHNldAoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUwPXkK IyBDT05GSUdfU0VSSUFMXzgyNTBfQ09OU09MRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF84 MjUwX0FDUEkgaXMgbm90IHNldApDT05GSUdfU0VSSUFMXzgyNTBfTlJfVUFSVFM9NAojIENPTkZJ R19TRVJJQUxfODI1MF9FWFRFTkRFRCBpcyBub3Qgc2V0CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBv cnQgc3VwcG9ydAojCkNPTkZJR19TRVJJQUxfQ09SRT15CkNPTkZJR19VTklYOThfUFRZUz15CkNP TkZJR19MRUdBQ1lfUFRZUz15CkNPTkZJR19MRUdBQ1lfUFRZX0NPVU5UPTI1NgpDT05GSUdfUFJJ TlRFUj15CiMgQ09ORklHX0xQX0NPTlNPTEUgaXMgbm90IHNldAojIENPTkZJR19QUERFViBpcyBu b3Qgc2V0CiMgQ09ORklHX1RJUEFSIGlzIG5vdCBzZXQKCiMKIyBMaW51eCBJbmZyYVJlZCBDb250 cm9sbGVyCiMKIyBDT05GSUdfTElSQ19TVVBQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdfUUlDMDJf VEFQRSBpcyBub3Qgc2V0CgojCiMgSVBNSQojCiMgQ09ORklHX0lQTUlfSEFORExFUiBpcyBub3Qg c2V0CgojCiMgV2F0Y2hkb2cgQ2FyZHMKIwojIENPTkZJR19XQVRDSERPRyBpcyBub3Qgc2V0CiMg Q09ORklHX0hXX1JBTkRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX05WUkFNIGlzIG5vdCBzZXQKIyBD T05GSUdfUlRDIGlzIG5vdCBzZXQKIyBDT05GSUdfR0VOX1JUQyBpcyBub3Qgc2V0CiMgQ09ORklH X0RUTEsgaXMgbm90IHNldAojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUExJ Q09NIGlzIG5vdCBzZXQKIyBDT05GSUdfU09OWVBJIGlzIG5vdCBzZXQKCiMKIyBGdGFwZSwgdGhl IGZsb3BweSB0YXBlIGRldmljZSBkcml2ZXIKIwpDT05GSUdfQUdQPXkKIyBDT05GSUdfQUdQX0FM SSBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9BVEkgaXMgbm90IHNldAojIENPTkZJR19BR1BfQU1E IGlzIG5vdCBzZXQKIyBDT05GSUdfQUdQX0FNRDY0IGlzIG5vdCBzZXQKQ09ORklHX0FHUF9JTlRF TD15CkNPTkZJR19BR1BfSU5URUxfTUNIPW0KIyBDT05GSUdfQUdQX05WSURJQSBpcyBub3Qgc2V0 CiMgQ09ORklHX0FHUF9TSVMgaXMgbm90IHNldAojIENPTkZJR19BR1BfU1dPUktTIGlzIG5vdCBz ZXQKIyBDT05GSUdfQUdQX1ZJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9FRkZJQ0VPTiBpcyBu b3Qgc2V0CkNPTkZJR19EUk09eQojIENPTkZJR19EUk1fVERGWCBpcyBub3Qgc2V0CiMgQ09ORklH X0RSTV9HQU1NQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9SMTI4IGlzIG5vdCBzZXQKIyBDT05G SUdfRFJNX1JBREVPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9JODEwIGlzIG5vdCBzZXQKQ09O RklHX0RSTV9JODMwPXkKIyBDT05GSUdfRFJNX01HQSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9T SVMgaXMgbm90IHNldAojIENPTkZJR19NV0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX1JBV19EUklW RVIgaXMgbm90IHNldAojIENPTkZJR19IQU5HQ0hFQ0tfVElNRVIgaXMgbm90IHNldAoKIwojIEky QyBzdXBwb3J0CiMKIyBDT05GSUdfSTJDIGlzIG5vdCBzZXQKCiMKIyBNaXNjIGRldmljZXMKIwoj IENPTkZJR19JQk1fQVNNIGlzIG5vdCBzZXQKCiMKIyBNdWx0aW1lZGlhIGRldmljZXMKIwojIENP TkZJR19WSURFT19ERVYgaXMgbm90IHNldAoKIwojIERpZ2l0YWwgVmlkZW8gQnJvYWRjYXN0aW5n IERldmljZXMKIwojIENPTkZJR19EVkIgaXMgbm90IHNldAoKIwojIEdyYXBoaWNzIHN1cHBvcnQK IwojIENPTkZJR19GQiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NFTEVDVCBpcyBub3Qgc2V0 CgojCiMgQ29uc29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1ZHQV9DT05TT0xF PXkKIyBDT05GSUdfTURBX0NPTlNPTEUgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15 CgojCiMgU3BlYWt1cCBjb25zb2xlIHNwZWVjaAojCiMgQ09ORklHX1NQRUFLVVAgaXMgbm90IHNl dApDT05GSUdfU1BFQUtVUF9ERUZBVUxUPSJub25lIgoKIwojIFNvdW5kCiMKQ09ORklHX1NPVU5E PXkKCiMKIyBBZHZhbmNlZCBMaW51eCBTb3VuZCBBcmNoaXRlY3R1cmUKIwpDT05GSUdfU05EPXkK Q09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRfUENNPXkKQ09ORklHX1NORF9SQVdNSURJPXkK Q09ORklHX1NORF9TRVFVRU5DRVI9eQojIENPTkZJR19TTkRfU0VRX0RVTU1ZIGlzIG5vdCBzZXQK Q09ORklHX1NORF9PU1NFTVVMPXkKQ09ORklHX1NORF9NSVhFUl9PU1M9eQpDT05GSUdfU05EX1BD TV9PU1M9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQojIENPTkZJR19TTkRfVkVSQk9TRV9Q UklOVEsgaXMgbm90IHNldAojIENPTkZJR19TTkRfREVCVUcgaXMgbm90IHNldAoKIwojIEdlbmVy aWMgZGV2aWNlcwojCkNPTkZJR19TTkRfTVBVNDAxX1VBUlQ9eQojIENPTkZJR19TTkRfRFVNTVkg aXMgbm90IHNldAojIENPTkZJR19TTkRfVklSTUlESSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9N VFBBViBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TRVJJQUxfVTE2NTUwIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX01QVTQwMSBpcyBub3Qgc2V0CgojCiMgSVNBIGRldmljZXMKIwojIENPTkZJR19T TkRfQUQxODQ4IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0NTNDIzMSBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9DUzQyMzIgaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1M0MjM2IGlzIG5vdCBzZXQK IyBDT05GSUdfU05EX0VTMTY4OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9FUzE4WFggaXMgbm90 IHNldAojIENPTkZJR19TTkRfR1VTQ0xBU1NJQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9HVVNF WFRSRU1FIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dVU01BWCBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9JTlRFUldBVkUgaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5URVJXQVZFX1NUQiBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9PUFRJOTJYX0FEMTg0OCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9PUFRJOTJYX0NTNDIzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9PUFRJOTNYIGlzIG5vdCBz ZXQKIyBDT05GSUdfU05EX1NCOCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TQjE2IGlzIG5vdCBz ZXQKIyBDT05GSUdfU05EX1NCQVdFIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1dBVkVGUk9OVCBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9DTUk4MzMwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX09Q TDNTQTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfU0dBTEFYWSBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9TU0NBUEUgaXMgbm90IHNldAoKIwojIFBDSSBkZXZpY2VzCiMKQ09ORklHX1NORF9BQzk3 X0NPREVDPXkKIyBDT05GSUdfU05EX0FMSTU0NTEgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVRJ SVhQIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVODgxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9BVTg4MjAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODMwIGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX0FaVDMzMjggaXMgbm90IHNldAojIENPTkZJR19TTkRfQlQ4N1ggaXMgbm90IHNldAoj IENPTkZJR19TTkRfQ1M0NlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0NTNDI4MSBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9FTVUxMEsxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0tPUkcxMjEy IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01JWEFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9O TTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUUzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9STUU5NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUU5NjUyIGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX0hEU1AgaXMgbm90IHNldAojIENPTkZJR19TTkRfVFJJREVOVCBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9ZTUZQQ0kgaXMgbm90IHNldAojIENPTkZJR19TTkRfQUxTNDAwMCBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9DTUlQQ0kgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MCBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9FTlMxMzcxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VT MTkzOCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9FUzE5NjggaXMgbm90IHNldAojIENPTkZJR19T TkRfTUFFU1RSTzMgaXMgbm90IHNldAojIENPTkZJR19TTkRfRk04MDEgaXMgbm90IHNldAojIENP TkZJR19TTkRfSUNFMTcxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JQ0UxNzI0IGlzIG5vdCBz ZXQKQ09ORklHX1NORF9JTlRFTDhYMD15CiMgQ09ORklHX1NORF9JTlRFTDhYME0gaXMgbm90IHNl dAojIENPTkZJR19TTkRfU09OSUNWSUJFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WSUE4MlhY IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1ZYMjIyIGlzIG5vdCBzZXQKCiMKIyBBTFNBIFVTQiBk ZXZpY2VzCiMKIyBDT05GSUdfU05EX1VTQl9BVURJTyBpcyBub3Qgc2V0CgojCiMgT3BlbiBTb3Vu ZCBTeXN0ZW0KIwojIENPTkZJR19TT1VORF9QUklNRSBpcyBub3Qgc2V0CgojCiMgVVNCIHN1cHBv cnQKIwpDT05GSUdfVVNCPXkKIyBDT05GSUdfVVNCX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBNaXNj ZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMKQ09ORklHX1VTQl9ERVZJQ0VGUz15CiMgQ09ORklHX1VT Ql9CQU5EV0lEVEggaXMgbm90IHNldAojIENPTkZJR19VU0JfRFlOQU1JQ19NSU5PUlMgaXMgbm90 IHNldAoKIwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCkNPTkZJR19VU0JfRUhDSV9I Q0Q9eQojIENPTkZJR19VU0JfRUhDSV9TUExJVF9JU08gaXMgbm90IHNldAojIENPTkZJR19VU0Jf T0hDSV9IQ0QgaXMgbm90IHNldApDT05GSUdfVVNCX1VIQ0lfSENEPXkKCiMKIyBVU0IgRGV2aWNl IENsYXNzIGRyaXZlcnMKIwojIENPTkZJR19VU0JfQVVESU8gaXMgbm90IHNldAojIENPTkZJR19V U0JfQkxVRVRPT1RIX1RUWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NSURJIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfUFJJTlRFUj15CkNPTkZJR19V U0JfU1RPUkFHRT15CiMgQ09ORklHX1VTQl9TVE9SQUdFX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1NUT1JBR0VfREFUQUZBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZS RUVDT00gaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNldAoj IENPTkZJR19VU0JfU1RPUkFHRV9EUENNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0Vf SFA4MjAwZSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFIwOSBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFI1NSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9S QUdFX0pVTVBTSE9UIGlzIG5vdCBzZXQKCiMKIyBVU0IgSHVtYW4gSW50ZXJmYWNlIERldmljZXMg KEhJRCkKIwpDT05GSUdfVVNCX0hJRD15CkNPTkZJR19VU0JfSElESU5QVVQ9eQojIENPTkZJR19I SURfRkYgaXMgbm90IHNldAojIENPTkZJR19VU0JfSElEREVWIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0FJUFRFSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9XQUNPTSBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9LQlRBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QT1dFUk1BVEUgaXMgbm90IHNl dAojIENPTkZJR19VU0JfTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1hQQUQgaXMgbm90 IHNldAojIENPTkZJR19VU0JfQVRJX1JFTU9URSBpcyBub3Qgc2V0CgojCiMgVVNCIEltYWdpbmcg ZGV2aWNlcwojCiMgQ09ORklHX1VTQl9NREM4MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTUlD Uk9URUsgaXMgbm90IHNldAojIENPTkZJR19VU0JfSFBVU0JTQ1NJIGlzIG5vdCBzZXQKCiMKIyBV U0IgTXVsdGltZWRpYSBkZXZpY2VzCiMKIyBDT05GSUdfVVNCX0RBQlVTQiBpcyBub3Qgc2V0Cgoj CiMgVmlkZW80TGludXggc3VwcG9ydCBpcyBuZWVkZWQgZm9yIFVTQiBNdWx0aW1lZGlhIGRldmlj ZSBzdXBwb3J0CiMKCiMKIyBVU0IgTmV0d29yayBhZGFwdG9ycwojCiMgQ09ORklHX1VTQl9DQVRD IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9Q RUdBU1VTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJ R19VU0JfVVNCTkVUIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBkcml2ZXJzCiMKIyBDT05GSUdf VVNCX1VTUzcyMCBpcyBub3Qgc2V0CgojCiMgVVNCIFNlcmlhbCBDb252ZXJ0ZXIgc3VwcG9ydAoj CiMgQ09ORklHX1VTQl9TRVJJQUwgaXMgbm90IHNldAoKIwojIFVTQiBNaXNjZWxsYW5lb3VzIGRy aXZlcnMKIwojIENPTkZJR19VU0JfRU1JNjIgaXMgbm90IHNldAojIENPTkZJR19VU0JfRU1JMjYg aXMgbm90IHNldAojIENPTkZJR19VU0JfVElHTCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BVUVS U1dBTEQgaXMgbm90IHNldAojIENPTkZJR19VU0JfUklPNTAwIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0xFR09UT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MQ0QgaXMgbm90IHNldAojIENP TkZJR19VU0JfTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RFU1QgaXMgbm90IHNldAoKIwoj IFVTQiBHYWRnZXQgU3VwcG9ydAojCiMgQ09ORklHX1VTQl9HQURHRVQgaXMgbm90IHNldAoKIwoj IEZpbGUgc3lzdGVtcwojCkNPTkZJR19FWFQyX0ZTPXkKIyBDT05GSUdfRVhUMl9GU19YQVRUUiBp cyBub3Qgc2V0CkNPTkZJR19FWFQzX0ZTPXkKQ09ORklHX0VYVDNfRlNfWEFUVFI9eQojIENPTkZJ R19FWFQzX0ZTX1BPU0lYX0FDTCBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDNfRlNfU0VDVVJJVFkg aXMgbm90IHNldApDT05GSUdfSkJEPXkKIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQKQ09O RklHX0ZTX01CQ0FDSEU9eQpDT05GSUdfUkVJU0VSRlNfRlM9eQojIENPTkZJR19SRUlTRVJGU19D SEVDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1JFSVNFUkZTX1BST0NfSU5GTyBpcyBub3Qgc2V0CiMg Q09ORklHX0pGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1hGU19GUyBpcyBub3Qgc2V0CiMgQ09O RklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUk9NRlNfRlMgaXMgbm90IHNldAojIENP TkZJR19RVU9UQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FVVE9GU19GUyBpcyBub3Qgc2V0CkNPTkZJ R19BVVRPRlM0X0ZTPXkKCiMKIyBDRC1ST00vRFZEIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0lTTzk2 NjBfRlM9eQpDT05GSUdfSk9MSUVUPXkKIyBDT05GSUdfWklTT0ZTIGlzIG5vdCBzZXQKQ09ORklH X1VERl9GUz15CgojCiMgRE9TL0ZBVC9OVCBGaWxlc3lzdGVtcwojCkNPTkZJR19GQVRfRlM9eQpD T05GSUdfTVNET1NfRlM9eQpDT05GSUdfVkZBVF9GUz15CiMgQ09ORklHX05URlNfRlMgaXMgbm90 IHNldAoKIwojIFBzZXVkbyBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9DX0ZTPXkKQ09ORklHX1BS T0NfS0NPUkU9eQpDT05GSUdfREVWRlNfRlM9eQojIENPTkZJR19ERVZGU19NT1VOVCBpcyBub3Qg c2V0CiMgQ09ORklHX0RFVkZTX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfREVWUFRTX0ZTX1hB VFRSIGlzIG5vdCBzZXQKQ09ORklHX1RNUEZTPXkKIyBDT05GSUdfSFVHRVRMQkZTIGlzIG5vdCBz ZXQKIyBDT05GSUdfSFVHRVRMQl9QQUdFIGlzIG5vdCBzZXQKQ09ORklHX1JBTUZTPXkKIyBDT05G SUdfU1VQRVJNT1VOVCBpcyBub3Qgc2V0CgojCiMgTWlzY2VsbGFuZW91cyBmaWxlc3lzdGVtcwoj CiMgQ09ORklHX0FERlNfRlMgaXMgbm90IHNldAojIENPTkZJR19BRkZTX0ZTIGlzIG5vdCBzZXQK IyBDT05GSUdfSEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSEZTUExVU19GUyBpcyBub3Qgc2V0 CiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19CRlNfRlMgaXMgbm90IHNldAoj IENPTkZJR19FRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19DUkFNRlMgaXMgbm90IHNldAojIENP TkZJR19TUVVBU0hGUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZYRlNfRlMgaXMgbm90IHNldAojIENP TkZJR19IUEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUU5YNEZTX0ZTIGlzIG5vdCBzZXQKIyBD T05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VGU19GUyBpcyBub3Qgc2V0CiMgQ09O RklHX0xVRlNfRlMgaXMgbm90IHNldAoKIwojIE5ldHdvcmsgRmlsZSBTeXN0ZW1zCiMKQ09ORklH X05GU19GUz15CiMgQ09ORklHX05GU19WMyBpcyBub3Qgc2V0CiMgQ09ORklHX05GU19WNCBpcyBu b3Qgc2V0CiMgQ09ORklHX05GU19ESVJFQ1RJTyBpcyBub3Qgc2V0CkNPTkZJR19ORlNEPXkKIyBD T05GSUdfTkZTRF9WMyBpcyBub3Qgc2V0CkNPTkZJR19ORlNEX1RDUD15CkNPTkZJR19MT0NLRD15 CkNPTkZJR19FWFBPUlRGUz15CkNPTkZJR19TVU5SUEM9eQojIENPTkZJR19SUENTRUNfR1NTX0tS QjUgaXMgbm90IHNldAojIENPTkZJR19TTUJfRlMgaXMgbm90IHNldAojIENPTkZJR19DSUZTIGlz IG5vdCBzZXQKIyBDT05GSUdfTkNQX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09EQV9GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX0lOVEVSTUVaWk9fRlMgaXMgbm90IHNldAojIENPTkZJR19BRlNfRlMg aXMgbm90IHNldAoKIwojIFBhcnRpdGlvbiBUeXBlcwojCiMgQ09ORklHX1BBUlRJVElPTl9BRFZB TkNFRCBpcyBub3Qgc2V0CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQoKIwojIE5hdGl2ZSBMYW5n dWFnZSBTdXBwb3J0CiMKQ09ORklHX05MUz15CkNPTkZJR19OTFNfREVGQVVMVD0iaXNvODg1OS0x IgpDT05GSUdfTkxTX0NPREVQQUdFXzQzNz15CiMgQ09ORklHX05MU19DT0RFUEFHRV83MzcgaXMg bm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT X0NPREVQQUdFXzg1MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTIgaXMgbm90 IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NP REVQQUdFXzg1NyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNl dAojIENPTkZJR19OTFNfQ09ERVBBR0VfODYxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg2MiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjMgaXMgbm90IHNldAoj IENPTkZJR19OTFNfQ09ERVBBR0VfODY0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdF Xzg2NSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldAojIENP TkZJR19OTFNfQ09ERVBBR0VfODY5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkz NiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldAojIENPTkZJ R19OTFNfQ09ERVBBR0VfOTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk0OSBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMgbm90IHNldAojIENPTkZJR19O TFNfSVNPODg1OV84IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTAgaXMgbm90 IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MSBpcyBub3Qgc2V0CkNPTkZJR19OTFNfSVNP ODg1OV8xPXkKIyBDT05GSUdfTkxTX0lTTzg4NTlfMiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19J U084ODU5XzMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV80IGlzIG5vdCBzZXQKIyBD T05GSUdfTkxTX0lTTzg4NTlfNSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzYgaXMg bm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV83IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lT Tzg4NTlfOSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzEzIGlzIG5vdCBzZXQKIyBD T05GSUdfTkxTX0lTTzg4NTlfMTQgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xNSBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1IgaXMgbm90IHNldAojIENPTkZJR19OTFNfS09J OF9VIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX1VURjggaXMgbm90IHNldAoKIwojIFByb2ZpbGlu ZyBzdXBwb3J0CiMKQ09ORklHX1BST0ZJTElORz15CkNPTkZJR19PUFJPRklMRT15CgojCiMgS2Vy bmVsIGhhY2tpbmcKIwojIENPTkZJR19ERUJVR19LRVJORUwgaXMgbm90IHNldApDT05GSUdfRUFS TFlfUFJJTlRLPXkKQ09ORklHX0RFQlVHX1NQSU5MT0NLX1NMRUVQPXkKIyBDT05GSUdfRlJBTUVf UE9JTlRFUiBpcyBub3Qgc2V0CkNPTkZJR19YODZfRklORF9TTVBfQ09ORklHPXkKQ09ORklHX1g4 Nl9NUFBBUlNFPXkKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMKIyBDT05GSUdfU0VDVVJJVFkgaXMg bm90IHNldAoKIwojIENyeXB0b2dyYXBoaWMgb3B0aW9ucwojCiMgQ09ORklHX0NSWVBUTyBpcyBu b3Qgc2V0CgojCiMgTGlicmFyeSByb3V0aW5lcwojCkNPTkZJR19DUkMzMj15CkNPTkZJR19YODZf U01QPXkKQ09ORklHX1g4Nl9IVD15CkNPTkZJR19YODZfQklPU19SRUJPT1Q9eQpDT05GSUdfWDg2 X1RSQU1QT0xJTkU9eQpDT05GSUdfUEM9eQo= ------=_Part_33_31530074.1095183048765-- From root@chaos.analogic.com Tue Sep 14 10:56:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 10:56:42 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EHuXDu008388 for ; Tue, 14 Sep 2004 10:56:34 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i8EHt1d04313; Tue, 14 Sep 2004 13:55:01 -0400 Date: Tue, 14 Sep 2004 13:55:01 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Andreas Dilger cc: Denis Vlasenko , Linux kernel , Trond Myklebust , netdev@oss.sgi.com Subject: Re: Kernel stack overflow on 2.6.9-rc2 In-Reply-To: <20040914163347.GE3197@schnapps.adilger.int> Message-ID: References: <200409141723.35009.vda@port.imtp.ilyichevsk.odessa.ua> <20040914163347.GE3197@schnapps.adilger.int> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 2132 Lines: 60 Has anybody ever explained why there is an attempt to minimize the size of the kernel stack? Temporary data allocation on the stack is FREE! The compiler just adjusts offsets for data. Even dynamic data-allocation takes only one instruction, (subl %reg, %esp). On Intel machines, the compiler requires that SS and DS be the same so that data can be accessed off the stack. That means that the stack-pointer is just some arbitrary offset in the segment(s) with enough room for downward growth. Changing if from the original 0x1000 (one Intel PAGE_SIZE) to anything smaller is weird, sort of like a contest to see how long one can hold the wrong end of a torch. It seems that some hole got opened up with the PREEMPTABLE KERNEL changes (read recursion). Removing stack data allocation just masks a far more egregious problem, I think. On Tue, 14 Sep 2004, Andreas Dilger wrote: > On Sep 14, 2004 17:23 +0300, Denis Vlasenko wrote: > > I am putting to use an ancient box. Pentium 66. > > It gives me stack overflow errors on 2.6.9-rc2: > > > > To save you filtering out functions with less than 100 > > bytes of stack: > > > > udp_sendmsg+0x35e/0x61a [220] > > sock_sendmsg+0x88/0xa3 [208] > > __nfs_revalidate_inode+0xc7/0x308 [152] > > nfs_lookup_revalidate+0x257/0x4ed [312] > > load_elf_binary+0xc4f/0xcc8 [268] > > load_script+0x1ea/0x220 [136] > > do_execve+0x153/0x1b9 [336] > > do_execve() can be trivially fixed to allocate bprm (328 bytes) instead > putting it on the stack. Given the frequency of exec and the odd size > it should probably be in its own slab (and fix the goofy prototype > indenting while you're there too ;-). > > load_elf_binary() on the other hand is a big mess, 132 bytes of int/long > variables. > > nfs_lookup_revalidate() has 2 large structs on the stack, fhandle and fattr. > > Cheers, Andreas > -- > Andreas Dilger > http://sourceforge.net/projects/ext2resize/ > http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ > > Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips). Note 96.31% of all statistics are fiction. From vda@port.imtp.ilyichevsk.odessa.ua Tue Sep 14 12:44:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 12:44:21 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8EJiFSC013828 for ; Tue, 14 Sep 2004 12:44:16 -0700 Received: (qmail 29811 invoked by alias); 14 Sep 2004 19:44:04 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 14 Sep 2004 19:44:04 -0000 From: Denis Vlasenko To: root@chaos.analogic.com, Andreas Dilger Subject: Re: Kernel stack overflow on 2.6.9-rc2 Date: Tue, 14 Sep 2004 22:43:55 +0300 User-Agent: KMail/1.5.4 Cc: Linux kernel , Trond Myklebust , netdev@oss.sgi.com References: <200409141723.35009.vda@port.imtp.ilyichevsk.odessa.ua> <20040914163347.GE3197@schnapps.adilger.int> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409142243.55949.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 8795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 491 Lines: 13 On Tuesday 14 September 2004 20:55, Richard B. Johnson wrote: > Has anybody ever explained why there is an attempt to > minimize the size of the kernel stack? Temporary data > allocation on the stack is FREE! The compiler just > adjusts offsets for data. Even dynamic data-allocation > takes only one instruction, (subl %reg, %esp). IIRC it is done in order to be able to support large number of threads on 32-bit machines and to avoid needing to do a order-1 allocation at fork(). -- vda From davem@davemloft.net Tue Sep 14 12:45:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 12:46:26 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EJjglU014031 for ; Tue, 14 Sep 2004 12:45:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7JCt-000867-00; Tue, 14 Sep 2004 12:43:15 -0700 Date: Tue, 14 Sep 2004 12:43:15 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-Id: <20040914124315.716e9c68.davem@davemloft.net> In-Reply-To: <20040914153537.GE8434@sunbeam.de.gnumonks.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 239 Lines: 7 Harald.... check current BK it has NAPI support added to the sungem.c driver already, it was written by Eric Lemoine with some fixes by myself and benh :-) I guess these are one of the old mails you're resending today after your outage. From laforge@gnumonks.org Tue Sep 14 12:52:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 12:52:50 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EJq3Sx014553 for ; Tue, 14 Sep 2004 12:52:04 -0700 Received: from dsl-082-082-095-094.arcor-ip.net ([82.82.95.94] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7JLE-0000jH-28; Tue, 14 Sep 2004 21:51:52 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7JKG-0008LR-Np; Tue, 14 Sep 2004 21:50:52 +0200 Date: Tue, 14 Sep 2004 21:50:52 +0200 From: Harald Welte To: Jeff Garzik Cc: David Miller , netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-ID: <20040914195052.GK8434@sunbeam.de.gnumonks.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <41471498.8010107@pobox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JVYm2bz4YjPqKA1I" Content-Disposition: inline In-Reply-To: <41471498.8010107@pobox.com> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 10940 Lines: 403 --JVYm2bz4YjPqKA1I Content-Type: multipart/mixed; boundary="wO3ULb5M+sQS9v8+" Content-Disposition: inline --wO3ULb5M+sQS9v8+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeff, thanks for your comments. On Tue, Sep 14, 2004 at 11:56:08AM -0400, Jeff Garzik wrote: > >+static inline void > >+gem_irq_acknowledge(struct gem *gp, unsigned int mask) > >+{ > >+ writel(mask, gp->regs + GREG_IACK); > >+} >=20 > PCI posting I'm not sure whether I need mb() or wmb() ?=20 Or even better: Can anybody direct me to a document describing the primitives in more detail than the linux include files? I'm happy to RTFM. > >+ gem_irq_acknowledge(gp, GREG_STAT_RXNOBUF); > >+ gem_irq_acknowledge(gp, GREG_STAT_RXTAGERR); > >+ gem_irq_acknowledge(gp, GREG_STAT_TXALL|GREG_STAT_TXINTME); >=20 > Are these in separate functions? If not, it's usually best to go ahead= =20 > and ACK all the interrupts you are going to handle, in a single IO write= =20 > (usually _before_ you handle the events). Not all of them are in the same function, although two of them can be combined. > >+#ifdef CONFIG_SUNGEM_NAPI > >+ netif_receive_skb(skb); > >+ (*work_done)++; >=20 > minor nit: surely it's better code to increment a local variable, then= =20 > store the local to *work_done once all iterations are complete? That's actually copy&paste from e1000_main.c ;) =20 Introducing additional local variables would add #ifdef'ed declarations, though :( Would you prefer a tg3-like rx() function that returns work_done rather than making it a return argument? > >- u32 gem_status =3D readl(gp->regs + GREG_STAT); > >+ u32 gem_status =3D readl(gp->regs + GREG_STAT2); >=20 > what does this do? GREG_STAT implicitly clears event bits 0..6 on read, which according to NAPI-HOWTO requires that you move all interrupt processing into dev->poll(). GREG_STAT2 is read-only without implicit clear, that's why I've added the explicit gem_irq_acknowledge() all over the place. > are all these enable/disables inside locks? No, enable() is also called from within the dev->poll() function, which doesn't grab the lock. > Jeff Partially revised patch attached --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --wO3ULb5M+sQS9v8+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-2.6.9-rc1-sungem-napi-0.02.patch" Content-Transfer-Encoding: quoted-printable diff -Nru linux-2.6.8.1-davem269_4/drivers/net/Kconfig linux-2.6.8.1-davem2= 69_4-sungem-napi/drivers/net/Kconfig --- linux-2.6.8.1-davem269_4/drivers/net/Kconfig 2004-08-14 12:56:00.000000= 000 +0200 +++ linux-2.6.8.1-davem269_4-sungem-napi/drivers/net/Kconfig 2004-09-14 11:= 40:40.000000000 +0200 @@ -569,6 +569,22 @@ help Support for the Sun GEM chip, aka Sun GigabitEthernet/P 2.0. See also . +config SUNGEM_NAPI + bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" + depends on SUNGEM && EXPERIMENTAL + help + NAPI is a new driver API designed to reduce CPU and interrupt load + when the driver is receiving lots of packets from the card. It is + still somewhat experimental and thus not yet enabled by default. + + If your estimated Rx load is 10kpps or more, or if the card will be + deployed on potentially unfriendly networks (e.g. in a firewall), + then say Y here. + + See for more + information. + + If in doubt, say N. =20 config NET_VENDOR_3COM bool "3COM cards" --- linux-2.6.8.1-davem269_4/drivers/net/sungem.c 2004-08-14 12:56:23.00000= 0000 +0200 +++ linux-2.6.8.1-davem269_4-sungem-napi/drivers/net/sungem.c 2004-09-14 21= :48:04.421487058 +0200 @@ -5,6 +5,9 @@ *=20 * Support for Apple GMAC and assorted PHYs by * Benjamin Herrenscmidt (benh@kernel.crashing.org) + * + * Support for NAPI and NETPOLL=20 + * (C) 2004 by Harald Welte *=20 * TODO:=20 * - Get rid of all those nasty mdelay's and replace them @@ -71,8 +74,8 @@ SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full) =20 #define DRV_NAME "sungem" -#define DRV_VERSION "0.98" -#define DRV_RELDATE "8/24/03" +#define DRV_VERSION "0.98-napi" +#define DRV_RELDATE "9/14/04" #define DRV_AUTHOR "David S. Miller (davem@redhat.com)" =20 static char version[] __devinitdata =3D @@ -187,6 +190,29 @@ printk(KERN_DEBUG "%s: mif interrupt\n", gp->dev->name); } =20 +static inline void +gem_irq_disable(struct gem *gp) +{ + /* Make sure we won't get any more interrupts */ + writel(0xffffffff, gp->regs + GREG_IMASK); + mb(); +} + +static inline void +gem_irq_enable(struct gem *gp, unsigned int mask) +{ + /* We don't want TXDONE, but all other interrupts */ + writel(mask, gp->regs + GREG_IMASK); + mb(); +} + +static inline void +gem_irq_acknowledge(struct gem *gp, unsigned int mask) +{ + writel(mask, gp->regs + GREG_IACK); + mb(); +} + static int gem_pcs_interrupt(struct net_device *dev, struct gem *gp, u32 g= em_status) { u32 pcs_istat =3D readl(gp->regs + PCS_ISTAT); @@ -531,6 +557,10 @@ */ static int gem_abnormal_irq(struct net_device *dev, struct gem *gp, u32 ge= m_status) { + /* only those two are part of bits 0..6 and need explicit + * acknowledgement via GREG_IACK */ + gem_irq_acknowledge(gp, (GREG_STAT_RXNOBUF|GREG_STAT_RXTAGERR)); + if (gem_status & GREG_STAT_RXNOBUF) { /* Frame arrived, no free RX buffers available. */ if (netif_msg_rx_err(gp)) @@ -596,6 +626,8 @@ printk(KERN_DEBUG "%s: tx interrupt, gem_status: 0x%x\n", gp->dev->name, gem_status); =20 + gem_irq_acknowledge(gp, GREG_STAT_TXALL|GREG_STAT_TXINTME); + entry =3D gp->tx_old; limit =3D ((gem_status & GREG_STAT_TXNR) >> GREG_STAT_TXNR_SHIFT); while (entry !=3D limit) { @@ -678,7 +710,11 @@ } } =20 +#ifdef CONFIG_SUNGEM_NAPI +static void gem_rx(struct gem *gp, int *work_done, int work_to_do) +#else static void gem_rx(struct gem *gp) +#endif { int entry, drops; u32 done; @@ -687,6 +723,8 @@ printk(KERN_DEBUG "%s: rx interrupt, done: %d, rx_new: %d\n", gp->dev->name, readl(gp->regs + RXDMA_DONE), gp->rx_new); =20 + gem_irq_acknowledge(gp, GREG_STAT_RXDONE); + entry =3D gp->rx_new; drops =3D 0; done =3D readl(gp->regs + RXDMA_DONE); @@ -713,6 +751,11 @@ break; } =20 +#ifdef CONFIG_SUNGEM_NAPI + if (*work_done >=3D work_to_do) + break; + +#endif skb =3D gp->rx_skbs[entry]; =20 len =3D (status & RXDCTRL_BUFSZ) >> 16; @@ -775,7 +818,12 @@ skb->csum =3D ntohs((status & RXDCTRL_TCPCSUM) ^ 0xffff); skb->ip_summed =3D CHECKSUM_HW; skb->protocol =3D eth_type_trans(skb, gp->dev); +#ifdef CONFIG_SUNGEM_NAPI + netif_receive_skb(skb); + (*work_done)++; +#else netif_rx(skb); +#endif =20 gp->net_stats.rx_packets++; gp->net_stats.rx_bytes +=3D len; @@ -798,7 +846,7 @@ { struct net_device *dev =3D dev_id; struct gem *gp =3D dev->priv; - u32 gem_status =3D readl(gp->regs + GREG_STAT); + u32 gem_status =3D readl(gp->regs + GREG_STAT2); =20 /* Swallow interrupts when shutting the chip down */ if (gp->hw_running =3D=3D 0) @@ -810,10 +858,21 @@ if (gem_abnormal_irq(dev, gp, gem_status)) goto out; } + if (gem_status & (GREG_STAT_TXALL | GREG_STAT_TXINTME)) gem_tx(dev, gp, gem_status); - if (gem_status & GREG_STAT_RXDONE) + + if (gem_status & GREG_STAT_RXDONE) { +#ifdef CONFIG_SUNGEM_NAPI + if (netif_rx_schedule_prep(dev)) { + /* Disable interrupts and register for poll */ + gem_irq_disable(gp); + __netif_rx_schedule(dev); + } +#else gem_rx(gp); +#endif + } =20 out: spin_unlock(&gp->lock); @@ -821,6 +880,29 @@ return IRQ_HANDLED; } =20 +#ifdef CONFIG_SUNGEM_NAPI +static int gem_clean(struct net_device *dev, int *budget) +{ + struct gem *gp =3D dev->priv; + int work_to_do =3D min(*budget, dev->quota); + int work_done =3D 0; + u32 gem_status =3D readl(gp->regs + GREG_STAT2); + + if (gem_status & GREG_STAT_RXDONE) + gem_rx(gp, &work_done, work_to_do); + + *budget -=3D work_done; + dev->quota -=3D work_done; + + if (work_done < work_to_do || !netif_running(dev)) { + __netif_rx_complete(dev); + gem_irq_enable(gp, GREG_STAT_TXDONE); + } + + return (work_done >=3D work_to_do); +} +#endif + static void gem_tx_timeout(struct net_device *dev) { struct gem *gp =3D dev->priv; @@ -1018,7 +1100,7 @@ u32 val; =20 /* Make sure we won't get any more interrupts */ - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); =20 /* Reset the chip */ writel(gp->swrst_base | GREG_SWRST_TXRST | GREG_SWRST_RXRST, @@ -1055,7 +1137,7 @@ (void) readl(gp->regs + MAC_RXCFG); udelay(100); =20 - writel(GREG_STAT_TXDONE, gp->regs + GREG_IMASK); + gem_irq_enable(gp, GREG_STAT_TXDONE); =20 writel(RX_RING_SIZE - 4, gp->regs + RXDMA_KICK); =20 @@ -1323,7 +1405,7 @@ /* Make sure we don't get interrupts or tx packets */ netif_stop_queue(gp->dev); =20 - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); =20 /* Reset the chip & rings */ gem_stop(gp); @@ -2218,7 +2300,7 @@ spin_lock_irq(&gp->lock); =20 gp->opened =3D 0;=09 - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); netif_stop_queue(dev); =20 /* Stop chip */ @@ -2262,7 +2344,7 @@ /* Stop traffic, mark us closed */ netif_device_detach(dev); =20 - writel(0xffffffff, gp->regs + GREG_IMASK); + gem_irq_disable(gp); =20 /* Stop chip */ gem_stop(gp); @@ -2649,6 +2731,16 @@ return 0; } =20 +#ifdef CONFIG_NET_POLL_CONTROLLER +static void gem_netpoll(struct net_device *dev) +{ + struct gem *gp =3D dev->priv; + disable_irq(gp->pdev->irq); + gem_interrupt(gp->pdev->irq, dev, NULL); + enable_irq(gp->pdev->irq); +} +#endif + static int __devinit gem_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -2809,6 +2901,15 @@ dev->ethtool_ops =3D &gem_ethtool_ops; dev->tx_timeout =3D gem_tx_timeout; dev->watchdog_timeo =3D 5 * HZ; +#ifdef CONFIG_SUNGEM_NAPI + dev->poll =3D gem_clean; + dev->weight =3D 64; +#endif + +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller =3D gem_netpoll; +#endif + dev->change_mtu =3D gem_change_mtu; dev->irq =3D pdev->irq; dev->dma =3D 0; --wO3ULb5M+sQS9v8+-- --JVYm2bz4YjPqKA1I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBR0ucXaXGVTD0i/8RApxAAKCpIOBN097L6Knp7kfZqa2K+MmP/wCgggFZ zZ5qy3S16iVlZ9IhnwHtXMc= =U0hJ -----END PGP SIGNATURE----- --JVYm2bz4YjPqKA1I-- From laforge@gnumonks.org Tue Sep 14 13:03:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 13:04:31 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EK3lkP015163 for ; Tue, 14 Sep 2004 13:03:47 -0700 Received: from dsl-082-082-095-094.arcor-ip.net ([82.82.95.94] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7JWa-00013O-Bp; Tue, 14 Sep 2004 22:03:36 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7JVe-0000Em-Nk; Tue, 14 Sep 2004 22:02:38 +0200 Date: Tue, 14 Sep 2004 22:02:38 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-ID: <20040914200238.GM8434@sunbeam.de.gnumonks.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <20040914124315.716e9c68.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aRzsUE0Mp86t8N62" Content-Disposition: inline In-Reply-To: <20040914124315.716e9c68.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1439 Lines: 46 --aRzsUE0Mp86t8N62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 14, 2004 at 12:43:15PM -0700, David S. Miller wrote: >=20 > Harald.... check current BK it has NAPI support added > to the sungem.c driver already, it was written by Eric Lemoine > with some fixes by myself and benh :-) Gnah, I hate duplicated efforts. Well, I learned a bit about NIC drivers, though :( > I guess these are one of the old mails you're resending today > after your outage. No, unfortunately not :( Before I start NAPI-enabling natsemi.c (and again duplicate work): Do you know of anybody working on this yet? --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --aRzsUE0Mp86t8N62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBR05eXaXGVTD0i/8RAsHXAJ4j2yIs5UG3OpHrry63kSoEZbZMCwCggnlD tbJMCHTlYaYvYyNkeh3yogY= =juGp -----END PGP SIGNATURE----- --aRzsUE0Mp86t8N62-- From i@stingr.net Tue Sep 14 13:12:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 13:12:25 -0700 (PDT) Received: from stingr.net (stingr.net [212.193.32.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EKCIJr015610 for ; Tue, 14 Sep 2004 13:12:19 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by stingr.net (Postfix) with ESMTP id C64E442C2; Wed, 15 Sep 2004 00:12:07 +0400 (MSD) Received: from stingr.net ([127.0.0.1]) by localhost (stingr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22594-02-3; Wed, 15 Sep 2004 00:12:06 +0400 (MSD) Received: by stingr.net (Postfix, from userid 1000) id 918C942C3; Wed, 15 Sep 2004 00:12:06 +0400 (MSD) Date: Wed, 15 Sep 2004 00:12:06 +0400 From: Paul P Komkoff Jr To: Lincoln Dale Cc: Paul P Komkoff Jr , "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-ID: <20040914201206.GM4141@stingr.sgu.ru> Mail-Followup-To: Lincoln Dale , Paul P Komkoff Jr , "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> <20040913051706.GB26337@stingr.sgu.ru> <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> <20040913051706.GB26337@stingr.sgu.ru> <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> <5.1.0.14.2.20040914225341.03c31a08@171.71.163.14> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040914225341.03c31a08@171.71.163.14> User-Agent: Agent Darien Fawkes X-Mailer: Intel Ultra ATA Storage Driver X-RealName: Stingray Greatest Jr Organization: Department of Fish & Wildlife X-Virus-Scanned: by amavisd-new at stingr.net X-archive-position: 8799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: i@stingr.net Precedence: bulk X-list: netdev Content-Length: 3435 Lines: 80 Replying to Lincoln Dale: > >From what I observe, netfilter hooks *are* called for unwrapped packets. > >Either for usual IP packets passed from GRE tunnel, or for demangled > >wccp packets. > > you probably want to ensure that the order of netfilter events are: Basically all surroinding stuff was untouched. I just enabled further processing (by kernel IP stack) of GRE-WCCP encapsulated packets. > 1. [packet comes in] > 2. netfilter INPUT > 3. [GRE decap] > 4. [addressed to us?] > Yes => netfilter INPUT > No => netfilter FORWARD > > i don't think that both (2) and (4) are done. I think (2) is done before ipgre_rcv, and (4) is done because after decapsulation skb->dev = tunnel->dev; netif_rx(skb); this packet reenters the building from matched gre interface. > also just a minor nit: not all WCCP needs to be GRE-encoded; on > high-performance switch/router platforms, only a layer-2 rewrite of the dst > MAC addr is used instead of a layer-3 GRE tunnel. you may want the comment > at line 609 to explicitly mention "WCCPv1 and WCCPv2 GRE Forwarding mode". Yes I know this :) L2 case do not need any extra processing, but not all routers support it. For example, my 4500 don't. Here is updated patch with if(1) removed and comment changed. diff -urN /usr/src/linux-2.6.8-1.521/include/linux/if_ether.h linux-2.6.8-1.521wccp/include/linux/if_ether.h --- /usr/src/linux-2.6.8-1.521/include/linux/if_ether.h 2004-08-14 09:37:15.000000000 +0400 +++ linux-2.6.8-1.521wccp/include/linux/if_ether.h 2004-09-13 08:51:02.000000000 +0400 @@ -59,6 +59,8 @@ #define ETH_P_8021Q 0x8100 /* 802.1Q VLAN Extended Header */ #define ETH_P_IPX 0x8137 /* IPX over DIX */ #define ETH_P_IPV6 0x86DD /* IPv6 over bluebook */ +#define ETH_P_WCCP 0x883E /* Web-cache coordination protocol + * defined in draft-wilson-wrec-wccp-v2-00.txt */ #define ETH_P_PPP_DISC 0x8863 /* PPPoE discovery messages */ #define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */ #define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */ diff -urN /usr/src/linux-2.6.8-1.521/net/ipv4/ip_gre.c linux-2.6.8-1.521wccp/net/ipv4/ip_gre.c --- /usr/src/linux-2.6.8-1.521/net/ipv4/ip_gre.c 2004-08-14 09:37:37.000000000 +0400 +++ linux-2.6.8-1.521wccp/net/ipv4/ip_gre.c 2004-09-15 00:03:45.586135760 +0400 @@ -605,13 +605,23 @@ if ((tunnel = ipgre_tunnel_lookup(iph->saddr, iph->daddr, key)) != NULL) { secpath_reset(skb); + skb->protocol = *(u16*)(h + 2); + /* WCCP version 1 and 2 (in GRE forwarding mode) protocol decoding. + * - Change protocol to IP + * - When dealing with WCCPv2, skip extra 4 bytes in GRE header + */ + if ((flags == 0) && (skb->protocol == __constant_htons(ETH_P_WCCP))) { + skb->protocol = __constant_htons(ETH_P_IP); + if ((*(h + offset) & 0xF0) != 0x40) + offset += 4; + } + skb->mac.raw = skb->nh.raw; skb->nh.raw = __pskb_pull(skb, offset); memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); if (skb->ip_summed == CHECKSUM_HW) skb->csum = csum_sub(skb->csum, csum_partial(skb->mac.raw, skb->nh.raw-skb->mac.raw, 0)); - skb->protocol = *(u16*)(h + 2); skb->pkt_type = PACKET_HOST; #ifdef CONFIG_NET_IPGRE_BROADCAST if (MULTICAST(iph->daddr)) { -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From davem@davemloft.net Tue Sep 14 13:51:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 13:52:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EKpPrg016625 for ; Tue, 14 Sep 2004 13:51:26 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7KEM-0008JR-00; Tue, 14 Sep 2004 13:48:50 -0700 Date: Tue, 14 Sep 2004 13:48:49 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-Id: <20040914134849.6685de79.davem@davemloft.net> In-Reply-To: <20040914200238.GM8434@sunbeam.de.gnumonks.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <20040914124315.716e9c68.davem@davemloft.net> <20040914200238.GM8434@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 266 Lines: 9 On Tue, 14 Sep 2004 22:02:38 +0200 Harald Welte wrote: > Before I start NAPI-enabling natsemi.c (and again duplicate work): Do > you know of anybody working on this yet? No I do not, have at it. I'm going to try and work on sunhme myself. From davem@davemloft.net Tue Sep 14 13:55:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 13:55:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EKt8N9017077 for ; Tue, 14 Sep 2004 13:55:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7KHy-0008Kl-00; Tue, 14 Sep 2004 13:52:34 -0700 Date: Tue, 14 Sep 2004 13:52:34 -0700 From: "David S. Miller" To: Harald Welte Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-Id: <20040914135234.72465d1a.davem@davemloft.net> In-Reply-To: <20040914195052.GK8434@sunbeam.de.gnumonks.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <41471498.8010107@pobox.com> <20040914195052.GK8434@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1271 Lines: 46 On Tue, 14 Sep 2004 21:50:52 +0200 Harald Welte wrote: > Hi Jeff, thanks for your comments. > > > On Tue, Sep 14, 2004 at 11:56:08AM -0400, Jeff Garzik wrote: > > >+static inline void > > >+gem_irq_acknowledge(struct gem *gp, unsigned int mask) > > >+{ > > >+ writel(mask, gp->regs + GREG_IACK); > > >+} > > > > PCI posting > > I'm not sure whether I need mb() or wmb() ? No, it's something else. If you do something like, as one example: /* Chip resets require 40msec settle delay. */ writel(FOO_RESET, regs + FOO); udelay(40); It's not going to work properly because the writel() can be delayed quite a long time, so you have to force the writel() to completion somehow, the usual way is via: writel(FOO_RESET, regs + FOO); (void) readl(regs + FOO); udelay(40); or similar. The read back of the register forces the write to complete on the PCI bus. But be very careful and don't do the readl() readbacks too much, especially in critical code paths, because they are expensive as they cause a full round-trip to occur on the PCI bus from the cpu. Make sure you absolutely do need the read back. Jeff, can you comment on why it is needed in this specific case of writing the chip interrupt enabling? I think it might not be. From niv@us.ibm.com Tue Sep 14 14:00:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:00:52 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EL0jOv017478 for ; Tue, 14 Sep 2004 14:00:45 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8EL0T7J465716; Tue, 14 Sep 2004 17:00:29 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8EL1gvO075324; Tue, 14 Sep 2004 17:01:42 -0400 Message-ID: <41475BEA.2030803@us.ibm.com> Date: Tue, 14 Sep 2004 14:00:26 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vuksan-hoforums@veus.hr CC: netdev@oss.sgi.com Subject: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2058 Lines: 71 Can you reproduce on the latest kernel, please? Is the OpenBSD mangling the packet in any way? Can anyone tell me if this smells like something recently fixed (MTU issues)? Doesn't sound like the windowscaling problem but could be related. thanks, Nivedita -------- Original Message -------- Subject: [Bug 3397] New: Network connections hang going through an OpenBSD firewall Date: Tue, 14 Sep 2004 09:38:24 -0700 From: bugme-daemon@osdl.org To: niv@us.ibm.com http://bugme.osdl.org/show_bug.cgi?id=3397 Summary: Network connections hang going through an OpenBSD firewall Kernel Version: 2.6.6+ Status: NEW Severity: blocking Owner: niv@us.ibm.com Submitter: vuksan-hoforums@veus.hr Distribution: Fedora Core 2, Gentoo Hardware Environment: All Software Environment: All Problem Description: We have seen a number of issues with people accessing our website http://www.cs.unm.edu/ using kernels 2.6.6+. Doing some network sniffing we can see that data request is received by the web server and the web server responds however after certain amount of bytes it simply stops. I have played with MTU sizes and if Ethereal is to be believed the transfer stops after MTU + 77 bytes. This has been reported to us by a number of different people running different distributions ie. Fedora Core 2, Gentoo. For example 2.6.5 kernel that comes with FC2 works. Secure IMAP and Secure POP don't seem to work either using 2.6.6+. What is even stranger is that SSH connections don't exhibit this kind of a problem ie. you can SSH withouth a hitch. A data point is that we are using transparent (in-line) OpenBSD firewall with Packetfilter. Steps to reproduce: Boot into 2.6.6+ kernel try pulling up http://www.cs.unm.edu/ through a web browser. It won't show up. Boot into a 2.6.5 and below and the page will show up. Any clues will be appreciated. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From garzik@havoc.gtf.org Tue Sep 14 14:02:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:03:03 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EL2F0b017694 for ; Tue, 14 Sep 2004 14:02:15 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 8B2EE767F; Tue, 14 Sep 2004 17:01:59 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8EL1Hcl003615; Tue, 14 Sep 2004 17:01:17 -0400 Date: Tue, 14 Sep 2004 17:01:17 -0400 From: Jeff Garzik To: "David S. Miller" Cc: Harald Welte , netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org, manfred@colorfullife.com Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-ID: <20040914210117.GA3344@havoc.gtf.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <20040914124315.716e9c68.davem@davemloft.net> <20040914200238.GM8434@sunbeam.de.gnumonks.org> <20040914134849.6685de79.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914134849.6685de79.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 8803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 398 Lines: 16 On Tue, Sep 14, 2004 at 01:48:49PM -0700, David S. Miller wrote: > On Tue, 14 Sep 2004 22:02:38 +0200 > Harald Welte wrote: > > > Before I start NAPI-enabling natsemi.c (and again duplicate work): Do > > you know of anybody working on this yet? > > No I do not, have at it. Talk to Manfred Spraul, he's pokes fixes natsemi bugs and pokes at it now and again... Jeff From shemminger@osdl.org Tue Sep 14 14:06:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:06:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EL6KCg018488 for ; Tue, 14 Sep 2004 14:06:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8EL63v30216; Tue, 14 Sep 2004 14:06:03 -0700 Date: Tue, 14 Sep 2004 14:06:03 -0700 From: Stephen Hemminger To: Nivedita Singhvi Cc: vuksan-hoforums@veus.hr, netdev@oss.sgi.com Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] Message-Id: <20040914140603.4698a9e5@dell_ss3.pdx.osdl.net> In-Reply-To: <41475BEA.2030803@us.ibm.com> References: <41475BEA.2030803@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1144 Lines: 26 On Tue, 14 Sep 2004 14:00:26 -0700 Nivedita Singhvi wrote: > Can you reproduce on the latest kernel, please? > Is the OpenBSD mangling the packet in any way? > > Can anyone tell me if this smells like something > recently fixed (MTU issues)? Doesn't sound like > the windowscaling problem but could be related. OpenBSD pf is easy to configure to break window scaling. The developer claims its not a bug. Basically stateless TCP connection tracking will never work, it's a bad idea. Daniel Hartmeier wrote: > The problem arises when the user creates a complicated ruleset that > passes the first SYN of a connection without creating a state entry. You > might argue that this shouldn't be possible, but some forms of stateless > filtering are being used. The man page warns against this, too. > > In this particular case, the ruleset tells pf to pass the initial SYN > without creating state (and therefore without any place to note the > window option and first scale factor). When, later, the SYN+ACK creates > state, the state just doesn't contain the information to follow the > scaled windows. From vlists@veus.hr Tue Sep 14 14:10:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:10:18 -0700 (PDT) Received: from mail.cs.unm.edu (webmail.cs.unm.edu [64.106.20.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ELACDY018876 for ; Tue, 14 Sep 2004 14:10:12 -0700 Received: from foote.cs.unm.edu ([64.106.20.108]) by mail.cs.unm.edu with esmtp (Exim 3.35 #1 (Debian)) id 1C7KYh-0002yK-00; Tue, 14 Sep 2004 15:09:51 -0600 Message-ID: <41475E1E.7010200@veus.hr> Date: Tue, 14 Sep 2004 15:09:50 -0600 From: Vladimir User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi CC: netdev@oss.sgi.com Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] References: <41475BEA.2030803@us.ibm.com> In-Reply-To: <41475BEA.2030803@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1C7KYh-0002yK-00*vZTQZUPZP0w* X-archive-position: 8805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vlists@veus.hr Precedence: bulk X-list: netdev Content-Length: 770 Lines: 34 Nivedita Singhvi wrote: > Can you reproduce on the latest kernel, please? I will try it with the latest kernel. I have tried this with kernel 2.6.8-1.521 from http://www.atrpms.net/dist/ It doesn't work with it. Should I download 2.6.8-1 from kernel.org and compile it by hand ? > Is the OpenBSD mangling the packet in any way? It is certainly possible but everything works fine with all other OSes and kernels 2.6.5 and below which leads me to believe something was changed in 2.6.6 that broke it. Are you able to reproduce it ? Thanks, Vladimir Vuksan > Can anyone tell me if this smells like something > recently fixed (MTU issues)? Doesn't sound like > the windowscaling problem but could be related. > http://bugme.osdl.org/show_bug.cgi?id=3397 From niv@us.ibm.com Tue Sep 14 14:22:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:22:05 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ELM0pt019364 for ; Tue, 14 Sep 2004 14:22:00 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8ELLiRS048354; Tue, 14 Sep 2004 17:21:44 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ELMuvO060924; Tue, 14 Sep 2004 17:22:57 -0400 Message-ID: <414760E5.4010703@us.ibm.com> Date: Tue, 14 Sep 2004 14:21:41 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir CC: netdev@oss.sgi.com Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] References: <41475BEA.2030803@us.ibm.com> <41475E1E.7010200@veus.hr> In-Reply-To: <41475E1E.7010200@veus.hr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 700 Lines: 25 Vladimir wrote: > It doesn't work with it. Should I download 2.6.8-1 from kernel.org and > compile it by hand ? If you can, download the latest (linux-2.6.9-rc2). You can get the patch against linux-2.6.8.1 vanilla from kernel.org. > It is certainly possible but everything works fine with all other OSes > and kernels 2.6.5 and below which leads me to believe something was > changed in 2.6.6 that broke it. > > Are you able to reproduce it ? Unfortunately, I have zero cycles right now (and in the near future) to address any issues, I'm afraid. Someone on netdev will likely be able to help you or have run into it already. See Stephen's post from a few minutes ago.. thanks, Nivedita From davem@davemloft.net Tue Sep 14 14:24:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:24:55 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ELOn4E019717 for ; Tue, 14 Sep 2004 14:24:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7Khq-0008Q8-00; Tue, 14 Sep 2004 14:19:18 -0700 Date: Tue, 14 Sep 2004 14:19:17 -0700 From: "David S. Miller" To: Vladimir Cc: niv@us.ibm.com, netdev@oss.sgi.com Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] Message-Id: <20040914141917.52cfa62e.davem@davemloft.net> In-Reply-To: <41475E1E.7010200@veus.hr> References: <41475BEA.2030803@us.ibm.com> <41475E1E.7010200@veus.hr> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 661 Lines: 21 On Tue, 14 Sep 2004 15:09:50 -0600 Vladimir wrote: > > Is the OpenBSD mangling the packet in any way? > > It is certainly possible but everything works fine with all other OSes > and kernels 2.6.5 and below which leads me to believe something was > changed in 2.6.6 that broke it. > > Are you able to reproduce it ? OpenBSD packet filter is busted, and the maintainer of it claims this is not a bug. That changes in 2.6.6 didn't "break" things, it enabled a feature in TCP that OpenBSD stateless TCP connection tracking cannot handle, and old TCP feature in fact, window scaling. See here for more info: http://lwn.net/Articles/92727/ From vlists@veus.hr Tue Sep 14 14:40:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:40:12 -0700 (PDT) Received: from mail.cs.unm.edu (webmail.cs.unm.edu [64.106.20.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ELe1MG020321 for ; Tue, 14 Sep 2004 14:40:01 -0700 Received: from foote.cs.unm.edu ([64.106.20.108]) by mail.cs.unm.edu with esmtp (Exim 3.35 #1 (Debian)) id 1C7L1Z-00048G-00; Tue, 14 Sep 2004 15:39:41 -0600 Message-ID: <41476519.9010606@veus.hr> Date: Tue, 14 Sep 2004 15:39:37 -0600 From: Vladimir User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: niv@us.ibm.com, netdev@oss.sgi.com Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] References: <41475BEA.2030803@us.ibm.com> <41475E1E.7010200@veus.hr> <20040914141917.52cfa62e.davem@davemloft.net> In-Reply-To: <20040914141917.52cfa62e.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1C7L1Z-00048G-00*az/HIC5FX5Y* X-archive-position: 8808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vlists@veus.hr Precedence: bulk X-list: netdev Content-Length: 696 Lines: 24 David S. Miller wrote: >OpenBSD packet filter is busted, and the maintainer of >it claims this is not a bug. > >That changes in 2.6.6 didn't "break" things, it enabled a >feature in TCP that OpenBSD stateless TCP connection tracking >cannot handle, and old TCP feature in fact, window scaling. > >See here for more info: > >http://lwn.net/Articles/92727/ > Thanks. We were able to fix our firewall so things work properly now. The problem is that this is "insidious" since it is not immediately apparent what the problem is especially since it tends to work with all other OSes except Linux with 2.6.6+. I will note this on the bug I submitted and close it. Thanks a lot, Vladimir Vuksan From vda@port.imtp.ilyichevsk.odessa.ua Tue Sep 14 14:43:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:43:19 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8ELhDUJ020685 for ; Tue, 14 Sep 2004 14:43:14 -0700 Received: (qmail 30589 invoked by alias); 14 Sep 2004 21:43:01 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 14 Sep 2004 21:43:01 -0000 From: Denis Vlasenko To: Andreas Dilger Subject: Re: Kernel stack overflow on 2.6.9-rc2 Date: Wed, 15 Sep 2004 00:42:57 +0300 User-Agent: KMail/1.5.4 Cc: linux-kernel@vger.kernel.org, Trond Myklebust , netdev@oss.sgi.com References: <200409141723.35009.vda@port.imtp.ilyichevsk.odessa.ua> <20040914163347.GE3197@schnapps.adilger.int> In-Reply-To: <20040914163347.GE3197@schnapps.adilger.int> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409150042.57208.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 8809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 954 Lines: 28 On Tuesday 14 September 2004 19:33, Andreas Dilger wrote: > On Sep 14, 2004 17:23 +0300, Denis Vlasenko wrote: > > I am putting to use an ancient box. Pentium 66. > > It gives me stack overflow errors on 2.6.9-rc2: > > > > To save you filtering out functions with less than 100 > > bytes of stack: > > > > udp_sendmsg+0x35e/0x61a [220] > > sock_sendmsg+0x88/0xa3 [208] > > __nfs_revalidate_inode+0xc7/0x308 [152] > > nfs_lookup_revalidate+0x257/0x4ed [312] > > load_elf_binary+0xc4f/0xcc8 [268] > > load_script+0x1ea/0x220 [136] > > do_execve+0x153/0x1b9 [336] > > do_execve() can be trivially fixed to allocate bprm (328 bytes) instead > putting it on the stack. Given the frequency of exec and the odd size > it should probably be in its own slab (and fix the goofy prototype > indenting while you're there too ;-). > > load_elf_binary() on the other hand is a big mess, 132 bytes of int/long > variables. 268 bytes according to checkstack. -- vda From shemminger@osdl.org Tue Sep 14 14:46:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 14:46:29 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ELkNKZ021061 for ; Tue, 14 Sep 2004 14:46:23 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8ELjnv04877; Tue, 14 Sep 2004 14:45:49 -0700 Date: Tue, 14 Sep 2004 14:45:49 -0700 From: Stephen Hemminger To: Nivedita Singhvi Cc: Vladimir , netdev@oss.sgi.com Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] Message-Id: <20040914144549.1e3a3162@dell_ss3.pdx.osdl.net> In-Reply-To: <414760E5.4010703@us.ibm.com> References: <41475BEA.2030803@us.ibm.com> <41475E1E.7010200@veus.hr> <414760E5.4010703@us.ibm.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1064 Lines: 27 On Tue, 14 Sep 2004 14:21:41 -0700 Nivedita Singhvi wrote: > Vladimir wrote: > > > It doesn't work with it. Should I download 2.6.8-1 from kernel.org and > > compile it by hand ? > > If you can, download the latest (linux-2.6.9-rc2). You can > get the patch against linux-2.6.8.1 vanilla from > kernel.org. > > > It is certainly possible but everything works fine with all other OSes > > and kernels 2.6.5 and below which leads me to believe something was > > changed in 2.6.6 that broke it. > > > > Are you able to reproduce it ? > > Unfortunately, I have zero cycles right now (and in the near > future) to address any issues, I'm afraid. Someone on netdev > will likely be able to help you or have run into it already. > See Stephen's post from a few minutes ago.. Since the latest kernel chooses window scaling factor automatically, the value chosen by default is small enough that OpenBSD busted pf will just make performance suck. If you want test it, you have to increase tcp_rmem[2] or tcp_rmem_max to force a window scale > 2. From herbert@gondor.apana.org.au Tue Sep 14 15:03:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 15:04:04 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EM3thC021698 for ; Tue, 14 Sep 2004 15:03:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7KrE-0005QM-00; Wed, 15 Sep 2004 07:29:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7Kqx-0002KO-00; Wed, 15 Sep 2004 07:28:43 +1000 Date: Wed, 15 Sep 2004 07:28:43 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [INET] Add flags field to ip_tunnel_parm Message-ID: <20040914212843.GA8925@gondor.apana.org.au> References: <20040914121617.GA5652@gondor.apana.org.au> <20040914.215205.110659321.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914.215205.110659321.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 729 Lines: 19 On Tue, Sep 14, 2004 at 09:52:05PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > Kernel will get garbage from old binaries, > and kernel will break user space if it tries > to get params into old structure. The only application that I know of does a memset on the structure so it'll be fine. Are you aware of any user-space applications that initialises every field explicitly instead of using memset? There are two in-kernel users as well (ipmr/addrconf) and they both initialise it with memset too. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Sep 14 15:06:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 15:06:44 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EM6bCT022058 for ; Tue, 14 Sep 2004 15:06:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7LRL-0006Xt-00; Wed, 15 Sep 2004 08:06:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7LRJ-0002Oq-00; Wed, 15 Sep 2004 08:06:17 +1000 Date: Wed, 15 Sep 2004 08:06:17 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [INET] Add flags field to ip_tunnel_parm Message-ID: <20040914220617.GA9213@gondor.apana.org.au> References: <20040914121617.GA5652@gondor.apana.org.au> <20040914.215205.110659321.yoshfuji@linux-ipv6.org> <20040914212843.GA8925@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914212843.GA8925@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 912 Lines: 23 On Wed, Sep 15, 2004 at 07:28:43AM +1000, herbert wrote: > On Tue, Sep 14, 2004 at 09:52:05PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > > > Kernel will get garbage from old binaries, > > and kernel will break user space if it tries > > to get params into old structure. > > The only application that I know of does a memset on the structure > so it'll be fine. Are you aware of any user-space applications that > initialises every field explicitly instead of using memset? Never mind, I see what you mean now. I suppose change the ioctl names/numbers is the easiest way now. I'd love to use netlink but that seems to require a lot of infrastructure which isn't there currently. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From shemminger@osdl.org Tue Sep 14 15:12:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 15:13:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8EMCtA2022469 for ; Tue, 14 Sep 2004 15:12:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8EMCWv10500; Tue, 14 Sep 2004 15:12:32 -0700 Date: Tue, 14 Sep 2004 15:12:32 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RFC] inet_opt space saving? Message-Id: <20040914151232.115c3eca@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1149 Lines: 34 It looks like there are lots of wasted bytes in the inet information per socket. Does this look right? diff -Nru a/include/linux/ip.h b/include/linux/ip.h --- a/include/linux/ip.h 2004-09-14 15:13:14 -07:00 +++ b/include/linux/ip.h 2004-09-14 15:13:14 -07:00 @@ -114,18 +114,18 @@ __u16 dport; /* Destination port */ __u16 num; /* Local port */ __u32 saddr; /* Sending source */ - int uc_ttl; /* Unicast TTL */ - int tos; /* TOS */ - unsigned cmsg_flags; struct ip_options *opt; __u16 sport; /* Source port */ - unsigned char hdrincl; /* Include headers ? */ - __u8 mc_ttl; /* Multicasting TTL */ - __u8 mc_loop; /* Loopback */ - __u8 pmtudisc; __u16 id; /* ID counter for DF pkts */ - unsigned recverr : 1, - freebind : 1; + __s16 uc_ttl; /* Unicast TTL */ + __u8 mc_ttl; /* Multicasting TTL */ + __u8 tos; /* TOS */ + unsigned mc_loop: 1, /* Loopback */ + hdrincl: 1, /* Include headers ? */ + recverr: 1, + freebind: 1, + cmsg_flags: 4, + pmtudisc: 2; int mc_index; /* Multicast device index */ __u32 mc_addr; struct ip_mc_socklist *mc_list; /* Group array */ From davem@davemloft.net Tue Sep 14 16:42:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 16:42:13 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ENg7Ec028056 for ; Tue, 14 Sep 2004 16:42:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7Mtq-0000Ex-00; Tue, 14 Sep 2004 16:39:50 -0700 Date: Tue, 14 Sep 2004 16:39:50 -0700 From: "David S. Miller" To: bcrl@kvack.org Cc: netdev@oss.sgi.com Subject: [PATCH] Making fib_semantics.c scale Message-Id: <20040914163950.0ae81d45.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 12116 Lines: 497 Ben, I've been hacking on fixing the routing scaling issues you found with your L2TP work. You mention dev_get_by_index() et al, those are already using nicer lookup schemes in the 2.6.x kernel and I'd happily accept a 2.4.x backport. The patch below is what I'm working with, against current 2.6.x It takes care of the fib_create_info() and fib_sync_down() overhead. fn_hash_flush() will probably still show up in your profiles and slow things down a bit, that one is a little harder to solve. Give this a go and let me know how well it works to improve your test case. Thanks. --- ../linus-2.6/include/net/ip_fib.h 2004-09-14 16:18:53.000000000 -0700 +++ include/net/ip_fib.h 2004-09-14 15:35:01.000000000 -0700 @@ -23,8 +23,7 @@ /* WARNING: The ordering of these elements must match ordering * of RTA_* rtnetlink attribute numbers. */ -struct kern_rta -{ +struct kern_rta { void *rta_dst; void *rta_src; int *rta_iif; @@ -40,9 +39,12 @@ struct rta_session *rta_sess; }; -struct fib_nh -{ - struct net_device *nh_dev; +struct fib_info; + +struct fib_nh { + struct net_device *nh_dev; + struct hlist_node nh_hash; + struct fib_info *nh_parent; unsigned nh_flags; unsigned char nh_scope; #ifdef CONFIG_IP_ROUTE_MULTIPATH @@ -60,10 +62,9 @@ * This structure contains data shared by many of routes. */ -struct fib_info -{ - struct fib_info *fib_next; - struct fib_info *fib_prev; +struct fib_info { + struct hlist_node fib_hash; + struct hlist_node fib_lhash; int fib_treeref; atomic_t fib_clntref; int fib_dead; @@ -89,8 +90,7 @@ struct fib_rule; #endif -struct fib_result -{ +struct fib_result { unsigned char prefixlen; unsigned char nh_sel; unsigned char type; @@ -119,8 +119,7 @@ #define FIB_RES_DEV(res) (FIB_RES_NH(res).nh_dev) #define FIB_RES_OIF(res) (FIB_RES_NH(res).nh_oif) -struct fib_table -{ +struct fib_table { unsigned char tb_id; unsigned tb_stamp; int (*tb_lookup)(struct fib_table *tb, const struct flowi *flp, struct fib_result *res); --- ../linus-2.6/net/ipv4/fib_semantics.c 2004-09-14 16:18:56.000000000 -0700 +++ net/ipv4/fib_semantics.c 2004-09-14 16:18:26.000000000 -0700 @@ -45,14 +45,12 @@ #define FSprintk(a...) -static struct fib_info *fib_info_list; static rwlock_t fib_info_lock = RW_LOCK_UNLOCKED; -int fib_info_cnt; - -#define for_fib_info() { struct fib_info *fi; \ - for (fi = fib_info_list; fi; fi = fi->fib_next) - -#define endfor_fib_info() } +static struct hlist_head *fib_info_hash; +static struct hlist_head *fib_info_devhash; +static struct hlist_head *fib_info_laddrhash; +static unsigned int fib_hash_size; +static unsigned int fib_info_cnt; #ifdef CONFIG_IP_ROUTE_MULTIPATH @@ -156,12 +154,12 @@ { write_lock(&fib_info_lock); if (fi && --fi->fib_treeref == 0) { - if (fi->fib_next) - fi->fib_next->fib_prev = fi->fib_prev; - if (fi->fib_prev) - fi->fib_prev->fib_next = fi->fib_next; - if (fi == fib_info_list) - fib_info_list = fi->fib_next; + hlist_del(&fi->fib_hash); + if (fi->fib_prefsrc) + hlist_del(&fi->fib_lhash); + change_nexthops(fi) { + hlist_del(&nh->nh_hash); + } endfor_nexthops(fi) fi->fib_dead = 1; fib_info_put(fi); } @@ -189,42 +187,77 @@ return 0; } -static __inline__ struct fib_info * fib_find_info(const struct fib_info *nfi) +static unsigned int fib_info_hashfn(const struct fib_info *fi) +{ + unsigned int mask = (fib_hash_size - 1); + unsigned int val = fi->fib_nhs; + + val ^= fi->fib_protocol; + val ^= fi->fib_prefsrc; + val ^= fi->fib_priority; + + return (val ^ (val >> 7) ^ (val >> 12)) & mask; +} + +static struct fib_info *fib_find_info(const struct fib_info *nfi) { - for_fib_info() { + struct hlist_head *head; + struct hlist_node *node; + struct fib_info *fi; + unsigned int hash; + + hash = fib_info_hashfn(nfi); + head = &fib_info_hash[hash]; + + hlist_for_each_entry(fi, node, head, fib_hash) { if (fi->fib_nhs != nfi->fib_nhs) continue; if (nfi->fib_protocol == fi->fib_protocol && nfi->fib_prefsrc == fi->fib_prefsrc && nfi->fib_priority == fi->fib_priority && - memcmp(nfi->fib_metrics, fi->fib_metrics, sizeof(fi->fib_metrics)) == 0 && + memcmp(nfi->fib_metrics, fi->fib_metrics, + sizeof(fi->fib_metrics)) == 0 && ((nfi->fib_flags^fi->fib_flags)&~RTNH_F_DEAD) == 0 && (nfi->fib_nhs == 0 || nh_comp(fi, nfi) == 0)) return fi; - } endfor_fib_info(); + } + return NULL; } +static unsigned int fib_devindex_hashfn(unsigned int val) +{ + unsigned int mask = (fib_hash_size - 1); + + return (val ^ (val >> 4) ^ (val >> 9)) & mask; +} + /* Check, that the gateway is already configured. Used only by redirect accept routine. */ int ip_fib_check_default(u32 gw, struct net_device *dev) { + struct hlist_head *head; + struct hlist_node *node; + struct fib_nh *nh; + unsigned int hash; + read_lock(&fib_info_lock); - for_fib_info() { - if (fi->fib_flags & RTNH_F_DEAD) - continue; - for_nexthops(fi) { - if (nh->nh_dev == dev && nh->nh_gw == gw && - nh->nh_scope == RT_SCOPE_LINK && - !(nh->nh_flags&RTNH_F_DEAD)) { - read_unlock(&fib_info_lock); - return 0; - } - } endfor_nexthops(fi); - } endfor_fib_info(); + + hash = fib_devindex_hashfn(dev->ifindex); + head = &fib_info_devhash[hash]; + hlist_for_each_entry(nh, node, head, nh_hash) { + if (nh->nh_dev == dev && + nh->nh_gw == gw && + !(nh->nh_flags&RTNH_F_DEAD)) { + read_unlock(&fib_info_lock); + return 0; + } + } + read_unlock(&fib_info_lock); + return -1; } @@ -451,6 +484,101 @@ return 0; } +static unsigned int fib_laddr_hashfn(u32 val) +{ + unsigned int mask = (fib_hash_size - 1); + + return (val ^ (val >> 7) ^ (val >> 14)) & mask; +} + +static struct hlist_head *fib_hash_alloc(int bytes) +{ + if (bytes <= PAGE_SIZE) + return kmalloc(bytes, GFP_KERNEL); + else + return (struct hlist_head *) + __get_free_pages(GFP_KERNEL, get_order(bytes)); +} + +static void fib_hash_free(struct hlist_head *hash, int bytes) +{ + if (!hash) + return; + + if (bytes <= PAGE_SIZE) + kfree(hash); + else + free_pages((unsigned long) hash, get_order(bytes)); +} + +static void fib_hash_move(struct hlist_head *new_info_hash, + struct hlist_head *new_devhash, + struct hlist_head *new_laddrhash, + unsigned int new_size) +{ + unsigned int old_size = fib_hash_size; + unsigned int i; + + write_lock(&fib_info_lock); + fib_hash_size = new_size; + + for (i = 0; i < old_size; i++) { + struct hlist_head *head = &fib_info_hash[i]; + struct hlist_node *node; + struct fib_info *fi; + + hlist_for_each_entry(fi, node, head, fib_hash) { + struct hlist_head *dest; + unsigned int new_hash; + + hlist_del(&fi->fib_hash); + + new_hash = fib_info_hashfn(fi); + dest = &new_info_hash[new_hash]; + hlist_add_head(&fi->fib_hash, dest); + } + } + fib_info_hash = new_info_hash; + + for (i = 0; i < old_size; i++) { + struct hlist_head *dhead = &fib_info_devhash[i]; + struct hlist_node *node; + struct fib_nh *nh; + + hlist_for_each_entry(nh, node, dhead, nh_hash) { + struct hlist_head *ddest; + unsigned int new_hash; + + hlist_del(&nh->nh_hash); + + new_hash = fib_devindex_hashfn(nh->nh_dev->ifindex); + ddest = &new_devhash[new_hash]; + hlist_add_head(&nh->nh_hash, ddest); + } + } + fib_info_devhash = new_devhash; + + for (i = 0; i < old_size; i++) { + struct hlist_head *lhead = &fib_info_laddrhash[i]; + struct hlist_node *node; + struct fib_info *fi; + + hlist_for_each_entry(fi, node, lhead, fib_lhash) { + struct hlist_head *ldest; + unsigned int new_hash; + + hlist_del(&fi->fib_lhash); + + new_hash = fib_laddr_hashfn(fi->fib_prefsrc); + ldest = &new_laddrhash[new_hash]; + hlist_add_head(&fi->fib_lhash, ldest); + } + } + fib_info_laddrhash = new_laddrhash; + + write_unlock(&fib_info_lock); +} + struct fib_info * fib_create_info(const struct rtmsg *r, struct kern_rta *rta, const struct nlmsghdr *nlh, int *errp) @@ -476,15 +604,45 @@ } #endif - fi = kmalloc(sizeof(*fi)+nhs*sizeof(struct fib_nh), GFP_KERNEL); err = -ENOBUFS; + if (fib_info_cnt >= fib_hash_size) { + unsigned int new_size = fib_hash_size << 1; + struct hlist_head *new_info_hash; + struct hlist_head *new_devhash; + struct hlist_head *new_laddrhash; + unsigned int bytes; + + if (!new_size) + new_size = 1; + bytes = new_size * sizeof(struct hlist_head *); + new_info_hash = fib_hash_alloc(bytes); + new_devhash = fib_hash_alloc(bytes); + new_laddrhash = fib_hash_alloc(bytes); + if (!new_info_hash || !new_devhash || !new_laddrhash) { + fib_hash_free(new_info_hash, bytes); + fib_hash_free(new_devhash, bytes); + fib_hash_free(new_laddrhash, bytes); + } else + fib_hash_move(new_info_hash, new_devhash, + new_laddrhash, new_size); + + if (!fib_hash_size) + goto failure; + } + + fi = kmalloc(sizeof(*fi)+nhs*sizeof(struct fib_nh), GFP_KERNEL); if (fi == NULL) goto failure; fib_info_cnt++; memset(fi, 0, sizeof(*fi)+nhs*sizeof(struct fib_nh)); fi->fib_protocol = r->rtm_protocol; + fi->fib_nhs = nhs; + change_nexthops(fi) { + nh->nh_parent = fi; + } endfor_nexthops(fi) + fi->fib_flags = r->rtm_flags; if (rta->rta_priority) fi->fib_priority = *rta->rta_priority; @@ -581,11 +739,24 @@ fi->fib_treeref++; atomic_inc(&fi->fib_clntref); write_lock(&fib_info_lock); - fi->fib_next = fib_info_list; - fi->fib_prev = NULL; - if (fib_info_list) - fib_info_list->fib_prev = fi; - fib_info_list = fi; + hlist_add_head(&fi->fib_hash, + &fib_info_hash[fib_info_hashfn(fi)]); + if (fi->fib_prefsrc) { + struct hlist_head *head; + + head = &fib_info_laddrhash[fib_laddr_hashfn(fi->fib_prefsrc)]; + hlist_add_head(&fi->fib_lhash, head); + } + change_nexthops(fi) { + struct hlist_head *head; + unsigned int hash; + + if (!nh->nh_dev) + continue; + hash = fib_devindex_hashfn(nh->nh_dev->ifindex); + head = &fib_info_devhash[hash]; + hlist_add_head(&nh->nh_hash, head); + } endfor_nexthops(fi) write_unlock(&fib_info_lock); return fi; @@ -884,13 +1055,38 @@ if (force) scope = -1; - for_fib_info() { - if (local && fi->fib_prefsrc == local) { - fi->fib_flags |= RTNH_F_DEAD; - ret++; - } else if (dev && fi->fib_nhs) { - int dead = 0; + BUG_ON(!fib_info_laddrhash || !fib_info_devhash); + + if (local) { + unsigned int hash = fib_laddr_hashfn(local); + struct hlist_head *head = &fib_info_laddrhash[hash]; + struct hlist_node *node; + struct fib_info *fi; + + hlist_for_each_entry(fi, node, head, fib_lhash) { + if (fi->fib_prefsrc == local) { + fi->fib_flags |= RTNH_F_DEAD; + ret++; + } + } + } + + if (dev) { + struct fib_info *prev_fi = NULL; + unsigned int hash = fib_devindex_hashfn(dev->ifindex); + struct hlist_head *head = &fib_info_devhash[hash]; + struct hlist_node *node; + struct fib_nh *nh; + + hlist_for_each_entry(nh, node, head, nh_hash) { + struct fib_info *fi = nh->nh_parent; + int dead; + BUG_ON(!fi->fib_nhs); + if (nh->nh_dev != dev || fi == prev_fi) + continue; + prev_fi = fi; + dead = 0; change_nexthops(fi) { if (nh->nh_flags&RTNH_F_DEAD) dead++; @@ -917,7 +1113,8 @@ ret++; } } - } endfor_fib_info(); + } + return ret; } @@ -930,14 +1127,33 @@ int fib_sync_up(struct net_device *dev) { - int ret = 0; + struct fib_info *prev_fi; + unsigned int hash; + struct hlist_head *head; + struct hlist_node *node; + struct fib_nh *nh; + int ret; + + BUG_ON(!fib_info_devhash); if (!(dev->flags&IFF_UP)) return 0; - for_fib_info() { - int alive = 0; + prev_fi = NULL; + hash = fib_devindex_hashfn(dev->ifindex); + head = &fib_info_devhash[hash]; + ret = 0; + + hlist_for_each_entry(nh, node, head, nh_hash) { + struct fib_info *fi = nh->nh_parent; + int alive; + + BUG_ON(!fi->fib_nhs); + if (nh->nh_dev != dev || fi == prev_fi) + continue; + prev_fi = fi; + alive = 0; change_nexthops(fi) { if (!(nh->nh_flags&RTNH_F_DEAD)) { alive++; @@ -958,7 +1174,8 @@ fi->fib_flags &= ~RTNH_F_DEAD; ret++; } - } endfor_fib_info(); + } + return ret; } From mcgrof@studorgs.rutgers.edu Tue Sep 14 16:55:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 16:55:33 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ENtNo3028683 for ; Tue, 14 Sep 2004 16:55:27 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id E761FF99BD; Tue, 14 Sep 2004 19:55:12 -0400 (EDT) Date: Tue, 14 Sep 2004 19:55:12 -0400 To: "David S. Miller" Cc: Vladimir Kondratiev , jgarzik@pobox.com, greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-ID: <20040914235512.GJ7839@ruslug.rutgers.edu> Mail-Followup-To: "David S. Miller" , Vladimir Kondratiev , jgarzik@pobox.com, greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040913223500.66c06cde.davem@davemloft.net> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 8815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 538 Lines: 18 On Mon, Sep 13, 2004 at 10:35:00PM -0700, David S. Miller wrote: > On Tue, 14 Sep 2004 08:14:56 +0300 > Vladimir Kondratiev wrote: > > > Fine. Let it be this way. It may take for me some time till I can sumbit > > something, I want that it will kind of work with minimum functionality. > > Ok, good luck Vladimir :-) Vladimir, How about dual-licensing this work as GPL/BSD? I believe the BSD teams might benefit from this work. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From yoshfuji@linux-ipv6.org Tue Sep 14 17:04:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 17:04:37 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F04U1q029177 for ; Tue, 14 Sep 2004 17:04:31 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1F32133CE5; Wed, 15 Sep 2004 09:04:25 +0900 (JST) Date: Wed, 15 Sep 2004 09:04:24 +0900 (JST) Message-Id: <20040915.090424.59114323.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, miyazawa@linux-ipv6.org Subject: [PATCH] IPV6: missing xfrm_loock() in icmpv6_{send,echo_reply}() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1168 Lines: 45 Hello. net/ipv6/icmp.c was not converted in xfrm_lookup() extraction patch. This patch converts it; adding the missing call to xfrm_lookup in icmpv6_{send,echo_reply}(). Signed-off-by: Kazunori Miyazawa Signed-off-by: Hideaki YOSHIFUJI Thanks. ===== net/ipv6/icmp.c 1.58 vs edited ===== --- 1.58/net/ipv6/icmp.c 2004-08-24 06:29:43 +09:00 +++ edited/net/ipv6/icmp.c 2004-09-15 08:53:05 +09:00 @@ -372,6 +372,8 @@ err = ip6_dst_lookup(sk, &dst, &fl); if (err) goto out; + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) + goto out_dst_release; if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) @@ -458,6 +460,8 @@ err = ip6_dst_lookup(sk, &dst, &fl); if (err) goto out; + if ((err = xfrm_lookup(&dst, &fl, sk, 0)) < 0) + goto out_dst_release; if (hlimit < 0) { if (ipv6_addr_is_multicast(&fl.fl6_dst)) @@ -489,6 +493,7 @@ out_put: if (likely(idev != NULL)) in6_dev_put(idev); +out_dst_release: dst_release(dst); out: icmpv6_xmit_unlock(); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jgarzik@pobox.com Tue Sep 14 17:11:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 17:11:52 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F0BiSs029601 for ; Tue, 14 Sep 2004 17:11:45 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7NOT-0008AI-Mt; Wed, 15 Sep 2004 01:11:29 +0100 Message-ID: <414788A4.7070003@pobox.com> Date: Tue, 14 Sep 2004 20:11:16 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: "David S. Miller" , Vladimir Kondratiev , greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> <20040914235512.GJ7839@ruslug.rutgers.edu> In-Reply-To: <20040914235512.GJ7839@ruslug.rutgers.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1280 Lines: 43 Luis R. Rodriguez wrote: > On Mon, Sep 13, 2004 at 10:35:00PM -0700, David S. Miller wrote: > >>On Tue, 14 Sep 2004 08:14:56 +0300 >>Vladimir Kondratiev wrote: >> >> >>>Fine. Let it be this way. It may take for me some time till I can sumbit >>>something, I want that it will kind of work with minimum functionality. >> >>Ok, good luck Vladimir :-) > > > Vladimir, > > How about dual-licensing this work as GPL/BSD? I believe the BSD teams might > benefit from this work. While I don't mind dual-licensing per se, I really dislike the associated _technical_ crap that comes along with it, namely * cross-OS compatibility wrappers * attempts to pretend that locking is _remotely_ similar between BSD and Linux net stacks * use of non-Linux coding styles and memes * over-engineering and over-abstraction Linus Credo #788 is "do what you must, and no more." If Vladimir is working from DaveM's code template, then he is working at the lowest, most native _Linux kernel_ levels to interface with the net stack. I'm all for code sharing -- but I'm all for rationality too. There will _inevitably_ be _fundamental_ differences between BSD and Linux net stacks, and to attempt to code for both OS's will be nasty and time consuming, IMHO. Jeff From Adam.Lewis@motorola.com Tue Sep 14 17:48:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 17:48:07 -0700 (PDT) Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F0m1UD030463 for ; Tue, 14 Sep 2004 17:48:02 -0700 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i8F0mxF7021192 for ; Tue, 14 Sep 2004 17:48:59 -0700 (MST) Received: from il02exm12.corp.mot.com (il02exm12.corp.mot.com [10.0.111.23]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i8F0kcTk010824 for ; Tue, 14 Sep 2004 19:46:39 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Sep 2004 19:47:49 -0500 Message-ID: From: Lewis Adam-CAL022 To: netdev@oss.sgi.com Subject: ksymoops can't see symbols in /proc/ksyms Date: Tue, 14 Sep 2004 19:47:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 8818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Adam.Lewis@motorola.com Precedence: bulk X-list: netdev Content-Length: 175 Lines: 1 I run ksymoops passing it an oops file. It complains that the modules have no exported symbols, and yet if I cat /proc/ksyms they are all there. Anybody know what is wrong? From greg@atheros.com Tue Sep 14 17:50:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 17:51:03 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F0otie030817 for ; Tue, 14 Sep 2004 17:50:56 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8938236; Tue, 14 Sep 2004 17:50:40 -0700 Message-ID: <41479228.8080507@atheros.com> Date: Tue, 14 Sep 2004 17:51:52 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> <20040914235512.GJ7839@ruslug.rutgers.edu> <414788A4.7070003@pobox.com> In-Reply-To: <414788A4.7070003@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 1328 Lines: 43 Jeff Garzik wrote: > > > While I don't mind dual-licensing per se, I really dislike the > associated _technical_ crap that comes along with it, namely > > * cross-OS compatibility wrappers > * attempts to pretend that locking is _remotely_ similar between BSD and > Linux net stacks > * use of non-Linux coding styles and memes > * over-engineering and over-abstraction > I won't try to argue that these are not valid points - except for maybe the last one because it is so subjective. But not in this email. I do argue that these points are not relevant to the question of whether or not a strict stack model of 802.11 management and encapsulation procedures will suffice for anything more than the most basic functionality. That is an interesting question that deserves an answer. Personally, I think it will be necessary to have more shared information and procedures between driver and 802.11 stack than is convenient or elegant in a strict stack arrangement. But, I've been wrong before. Perhaps a fresh start with unbiased implementation will do something wonderful. I look forward to seeing how a new implementation deals with the power-save packets in the presence of qos, crypto, and fragmentation - all of which are necessary evils if you want to pass wifi certification tests. g From jgarzik@pobox.com Tue Sep 14 18:19:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 18:19:58 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F1JqTg032021 for ; Tue, 14 Sep 2004 18:19:52 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7OSP-0001Cl-NT; Wed, 15 Sep 2004 02:19:37 +0100 Message-ID: <4147989C.7030708@pobox.com> Date: Tue, 14 Sep 2004 21:19:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg chesson CC: "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> <20040914235512.GJ7839@ruslug.rutgers.edu> <414788A4.7070003@pobox.com> <41479228.8080507@atheros.com> In-Reply-To: <41479228.8080507@atheros.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1084 Lines: 32 greg chesson wrote: > I won't try to argue that these are not valid points - > except for maybe the last one because it is so subjective. > But not in this email. > > I do argue that these points are not relevant to the question > of whether or not a strict stack model of 802.11 management > and encapsulation procedures will suffice for anything more > than the most basic functionality. That is an interesting question > that deserves an answer. Agreed. > Personally, I think it will be necessary to have more shared information > and procedures between > driver and 802.11 stack than is convenient or elegant in a strict stack > arrangement. > But, I've been wrong before. > Perhaps a fresh start with unbiased implementation will do something > wonderful. That's precisely what I want -- an elegant strict stack arrangement :) Since DaveM's template is _the_ net stack, I'm worried that BSD compatibility will only slow development and encumber innovation. Surely they can watch what we're doing, learn from our mistakes, and do something even better :) Jeff From herbert@gondor.apana.org.au Tue Sep 14 19:10:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 19:10:34 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F2APtF000887 for ; Tue, 14 Sep 2004 19:10:26 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7PEy-0000Qa-00; Wed, 15 Sep 2004 12:09:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7PEs-0008WA-00; Wed, 15 Sep 2004 12:09:42 +1000 Date: Wed, 15 Sep 2004 12:09:42 +1000 To: "David S. Miller" , YOSHIFUJI Hideaki , James Morris , netdev@oss.sgi.com Subject: [RTNETLINK] Convert RTM_* to enum Message-ID: <20040915020942.GA32721@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4048 Lines: 166 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: I decided to bite the bullet and use netlink for the tunnel operations. Before I do that, here is a patch to convert the RTM_* constants to an enum. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/rtnetlink.h 1.43 vs edited ===== --- 1.43/include/linux/rtnetlink.h 2004-09-10 03:24:53 +10:00 +++ edited/include/linux/rtnetlink.h 2004-09-15 11:45:24 +10:00 @@ -9,53 +9,89 @@ /* Types of messages */ -#define RTM_BASE 0x10 - -#define RTM_NEWLINK (RTM_BASE+0) -#define RTM_DELLINK (RTM_BASE+1) -#define RTM_GETLINK (RTM_BASE+2) -#define RTM_SETLINK (RTM_BASE+3) - -#define RTM_NEWADDR (RTM_BASE+4) -#define RTM_DELADDR (RTM_BASE+5) -#define RTM_GETADDR (RTM_BASE+6) - -#define RTM_NEWROUTE (RTM_BASE+8) -#define RTM_DELROUTE (RTM_BASE+9) -#define RTM_GETROUTE (RTM_BASE+10) - -#define RTM_NEWNEIGH (RTM_BASE+12) -#define RTM_DELNEIGH (RTM_BASE+13) -#define RTM_GETNEIGH (RTM_BASE+14) - -#define RTM_NEWRULE (RTM_BASE+16) -#define RTM_DELRULE (RTM_BASE+17) -#define RTM_GETRULE (RTM_BASE+18) - -#define RTM_NEWQDISC (RTM_BASE+20) -#define RTM_DELQDISC (RTM_BASE+21) -#define RTM_GETQDISC (RTM_BASE+22) - -#define RTM_NEWTCLASS (RTM_BASE+24) -#define RTM_DELTCLASS (RTM_BASE+25) -#define RTM_GETTCLASS (RTM_BASE+26) - -#define RTM_NEWTFILTER (RTM_BASE+28) -#define RTM_DELTFILTER (RTM_BASE+29) -#define RTM_GETTFILTER (RTM_BASE+30) - -#define RTM_NEWACTION (RTM_BASE+32) -#define RTM_DELACTION (RTM_BASE+33) -#define RTM_GETACTION (RTM_BASE+34) - -#define RTM_NEWPREFIX (RTM_BASE+36) -#define RTM_GETPREFIX (RTM_BASE+38) - -#define RTM_GETMULTICAST (RTM_BASE+42) - -#define RTM_GETANYCAST (RTM_BASE+46) - -#define RTM_MAX (RTM_BASE+47) +enum { + RTM_BASE = 16, +#define RTM_BASE RTM_BASE + + RTM_NEWLINK = 16, +#define RTM_NEWLINK RTM_NEWLINK + RTM_DELLINK, +#define RTM_DELLINK RTM_DELLINK + RTM_GETLINK, +#define RTM_GETLINK RTM_GETLINK + RTM_SETLINK, +#define RTM_SETLINK RTM_SETLINK + + RTM_NEWADDR = 20, +#define RTM_NEWADDR RTM_NEWADDR + RTM_DELADDR, +#define RTM_DELADDR RTM_DELADDR + RTM_GETADDR, +#define RTM_GETADDR RTM_GETADDR + + RTM_NEWROUTE = 24, +#define RTM_NEWROUTE RTM_NEWROUTE + RTM_DELROUTE, +#define RTM_DELROUTE RTM_DELROUTE + RTM_GETROUTE, +#define RTM_GETROUTE RTM_GETROUTE + + RTM_NEWNEIGH = 28, +#define RTM_NEWNEIGH RTM_NEWNEIGH + RTM_DELNEIGH, +#define RTM_DELNEIGH RTM_DELNEIGH + RTM_GETNEIGH, +#define RTM_GETNEIGH RTM_GETNEIGH + + RTM_NEWRULE = 32, +#define RTM_NEWRULE RTM_NEWRULE + RTM_DELRULE, +#define RTM_DELRULE RTM_DELRULE + RTM_GETRULE, +#define RTM_GETRULE RTM_GETRULE + + RTM_NEWQDISC = 36, +#define RTM_NEWQDISC RTM_NEWQDISC + RTM_DELQDISC, +#define RTM_DELQDISC RTM_DELQDISC + RTM_GETQDISC, +#define RTM_GETQDISC RTM_GETQDISC + + RTM_NEWTCLASS = 40, +#define RTM_NEWTCLASS RTM_NEWTCLASS + RTM_DELTCLASS, +#define RTM_DELTCLASS RTM_DELTCLASS + RTM_GETTCLASS, +#define RTM_GETTCLASS RTM_GETTCLASS + + RTM_NEWTFILTER = 44, +#define RTM_NEWTFILTER RTM_NEWTFILTER + RTM_DELTFILTER, +#define RTM_DELTFILTER RTM_DELTFILTER + RTM_GETTFILTER, +#define RTM_GETTFILTER RTM_GETTFILTER + + RTM_NEWACTION = 48, +#define RTM_NEWACTION RTM_NEWACTION + RTM_DELACTION, +#define RTM_DELACTION RTM_DELACTION + RTM_GETACTION, +#define RTM_GETACTION RTM_GETACTION + + RTM_NEWPREFIX = 52, +#define RTM_NEWPREFIX RTM_NEWPREFIX + RTM_GETPREFIX = 54, +#define RTM_GETPREFIX RTM_GETPREFIX + + RTM_GETMULTICAST = 58, +#define RTM_GETMULTICAST RTM_GETMULTICAST + + RTM_GETANYCAST = 62, +#define RTM_GETANYCAST RTM_GETANYCAST + + RTM_MAX, +#define RTM_MAX RTM_MAX +}; /* Generic structure for encapsulation of optional route information. --BXVAT5kNtrzKuDFl-- From Adam.Lewis@motorola.com Tue Sep 14 19:58:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 19:58:22 -0700 (PDT) Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F2wGiM002309 for ; Tue, 14 Sep 2004 19:58:18 -0700 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i8F2pH1M018442 for ; Tue, 14 Sep 2004 19:51:17 -0700 (MST) Received: from il02exm12.corp.mot.com (il02exm12.corp.mot.com [10.0.111.23]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i8F2w51J008883 for ; Tue, 14 Sep 2004 21:58:05 -0500 Received: by il02exm12 with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Sep 2004 21:58:05 -0500 Message-ID: From: Lewis Adam-CAL022 To: netdev@oss.sgi.com Subject: How to pass a string via iwpriv Date: Tue, 14 Sep 2004 21:58:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-archive-position: 8822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Adam.Lewis@motorola.com Precedence: bulk X-list: netdev Content-Length: 242 Lines: 7 Is there a way to create a private extension (e.g. to be invoked by iwpriv) that I can pass a string argument? Looking in wirless.h, I see types for byte, float, int, char, etc., but no char*. Anyway to pass a string to iwpriv? TIA, Adam From mcgrof@studorgs.rutgers.edu Tue Sep 14 20:02:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 20:02:27 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F32LKZ002671 for ; Tue, 14 Sep 2004 20:02:22 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 75393F99BD; Tue, 14 Sep 2004 23:02:11 -0400 (EDT) Date: Tue, 14 Sep 2004 23:02:11 -0400 To: Jeff Garzik Cc: greg chesson , "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-ID: <20040915030211.GK7839@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , greg chesson , "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> <20040914235512.GJ7839@ruslug.rutgers.edu> <414788A4.7070003@pobox.com> <41479228.8080507@atheros.com> <4147989C.7030708@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4147989C.7030708@pobox.com> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 8823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1479 Lines: 38 On Tue, Sep 14, 2004 at 09:19:24PM -0400, Jeff Garzik wrote: > greg chesson wrote: > >I won't try to argue that these are not valid points - > >except for maybe the last one because it is so subjective. > >But not in this email. > > > >I do argue that these points are not relevant to the question > >of whether or not a strict stack model of 802.11 management > >and encapsulation procedures will suffice for anything more > >than the most basic functionality. That is an interesting question > >that deserves an answer. > > Agreed. > > > >Personally, I think it will be necessary to have more shared information > >and procedures between > >driver and 802.11 stack than is convenient or elegant in a strict stack > >arrangement. > > But, I've been wrong before. > >Perhaps a fresh start with unbiased implementation will do something > >wonderful. > > That's precisely what I want -- an elegant strict stack arrangement :) > > Since DaveM's template is _the_ net stack, I'm worried that BSD > compatibility will only slow development and encumber innovation. > Surely they can watch what we're doing, learn from our mistakes, and do > something even better :) I proposed dual licensing not to specifically allow clear compatibility among linux and the BSDs on the 802.11 work, but to allow BSDers to do whatever they want with what we come up with -- help with code sharing. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From garzik@havoc.gtf.org Tue Sep 14 20:06:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 20:06:10 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F364wv003048 for ; Tue, 14 Sep 2004 20:06:04 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id E9DB776F5; Tue, 14 Sep 2004 23:05:46 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8F35kLp025360; Tue, 14 Sep 2004 23:05:46 -0400 Date: Tue, 14 Sep 2004 23:05:45 -0400 From: Jeff Garzik To: greg chesson , "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-ID: <20040915030545.GA25307@havoc.gtf.org> References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> <20040914235512.GJ7839@ruslug.rutgers.edu> <414788A4.7070003@pobox.com> <41479228.8080507@atheros.com> <4147989C.7030708@pobox.com> <20040915030211.GK7839@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915030211.GK7839@ruslug.rutgers.edu> User-Agent: Mutt/1.4.1i X-archive-position: 8824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 478 Lines: 15 On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote: > I proposed dual licensing not to specifically allow clear compatibility > among linux and the BSDs on the 802.11 work, but to allow BSDers to do > whatever they want with what we come up with -- help with code sharing. Overall, He Who Writes The Code Gets To Choose. My own personal opinion is that the BSD license goes against the stated spirit of Linux -- contribute back. But that's just me. Jeff From mcgrof@studorgs.rutgers.edu Tue Sep 14 20:17:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 20:17:48 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F3HhKS003527 for ; Tue, 14 Sep 2004 20:17:43 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 0AC2EF99BD; Tue, 14 Sep 2004 23:17:32 -0400 (EDT) Date: Tue, 14 Sep 2004 23:17:32 -0400 To: Jeff Garzik Cc: greg chesson , "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack Message-ID: <20040915031732.GL7839@ruslug.rutgers.edu> Mail-Followup-To: Jeff Garzik , greg chesson , "Luis R. Rodriguez" , "David S. Miller" , Vladimir Kondratiev , netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <4145352F.4040807@pobox.com> <20040913162153.33ff37ec.davem@davemloft.net> <200409140819.25787.vkondra@mail.ru> <20040913223500.66c06cde.davem@davemloft.net> <20040914235512.GJ7839@ruslug.rutgers.edu> <414788A4.7070003@pobox.com> <41479228.8080507@atheros.com> <4147989C.7030708@pobox.com> <20040915030211.GK7839@ruslug.rutgers.edu> <20040915030545.GA25307@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915030545.GA25307@havoc.gtf.org> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 8825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 791 Lines: 21 On Tue, Sep 14, 2004 at 11:05:45PM -0400, Jeff Garzik wrote: > On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote: > > I proposed dual licensing not to specifically allow clear compatibility > > among linux and the BSDs on the 802.11 work, but to allow BSDers to do > > whatever they want with what we come up with -- help with code sharing. > > > Overall, He Who Writes The Code Gets To Choose. > > My own personal opinion is that the BSD license goes against the stated > spirit of Linux -- contribute back. But that's just me. > Agreed -- but in this case I feel we're the bigger crowd so I wanted to address to the *author* that I feel we should be considerate to the BSD crowd. Luis -- GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E From jmorris@redhat.com Tue Sep 14 20:38:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 20:38:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F3cnMt007416 for ; Tue, 14 Sep 2004 20:38:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8F3cRSD002525; Tue, 14 Sep 2004 23:38:27 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8F3cMr16551; Tue, 14 Sep 2004 23:38:22 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8F3cMiS013491; Tue, 14 Sep 2004 23:38:22 -0400 Date: Tue, 14 Sep 2004 23:38:21 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Herbert Xu cc: "David S. Miller" , YOSHIFUJI Hideaki , Subject: Re: [RTNETLINK] Convert RTM_* to enum In-Reply-To: <20040915020942.GA32721@gondor.apana.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 330 Lines: 16 On Wed, 15 Sep 2004, Herbert Xu wrote: > I decided to bite the bullet and use netlink for the tunnel operations. > Before I do that, here is a patch to convert the RTM_* constants to an > enum. Having the enums as well as the defines is messy, I wonder if it's really worth it. - James -- James Morris From herbert@gondor.apana.org.au Tue Sep 14 20:48:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 20:48:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F3mFfs008805 for ; Tue, 14 Sep 2004 20:48:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7Qlr-0000qf-00; Wed, 15 Sep 2004 13:47:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7Qlo-0000Fi-00; Wed, 15 Sep 2004 13:47:48 +1000 Date: Wed, 15 Sep 2004 13:47:48 +1000 To: James Morris Cc: "David S. Miller" , YOSHIFUJI Hideaki , netdev@oss.sgi.com Subject: Re: [RTNETLINK] Convert RTM_* to enum Message-ID: <20040915034748.GA952@gondor.apana.org.au> References: <20040915020942.GA32721@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 653 Lines: 18 On Tue, Sep 14, 2004 at 11:38:21PM -0400, James Morris wrote: > > Having the enums as well as the defines is messy, I wonder if it's really > worth it. I think the enum is definitely worth it for reducing the churn on the MAX value. I personally don't see a point to the defines since the user-space appliations should not change behaviour based on compile-time settings. However, others seem to have a different opinion on that. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue Sep 14 21:41:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 21:41:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F4fEmD023838 for ; Tue, 14 Sep 2004 21:41:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7RYz-0000ZS-00; Tue, 14 Sep 2004 21:38:37 -0700 Date: Tue, 14 Sep 2004 21:38:37 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [RTNETLINK] Convert RTM_* to enum Message-Id: <20040914213837.75634b93.davem@davemloft.net> In-Reply-To: <20040915034748.GA952@gondor.apana.org.au> References: <20040915020942.GA32721@gondor.apana.org.au> <20040915034748.GA952@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 782 Lines: 20 On Wed, 15 Sep 2004 13:47:48 +1000 Herbert Xu wrote: > On Tue, Sep 14, 2004 at 11:38:21PM -0400, James Morris wrote: > > > > Having the enums as well as the defines is messy, I wonder if it's really > > worth it. > > I think the enum is definitely worth it for reducing the churn on > the MAX value. > > I personally don't see a point to the defines since the user-space > appliations should not change behaviour based on compile-time > settings. However, others seem to have a different opinion on that. Right. If we start using defines we have to keep them around. I know it's bogus for people to ifdef this stuff, but we know they do, and it's in bad taste to knowingly break stuff like that. Anyways, I'll apply your patch Herbert, thanks. From herbert@gondor.apana.org.au Tue Sep 14 21:46:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 21:46:44 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F4kX2J024247 for ; Tue, 14 Sep 2004 21:46:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7Rg6-00012W-00; Wed, 15 Sep 2004 14:45:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7Rg3-0000Lc-00; Wed, 15 Sep 2004 14:45:55 +1000 Date: Wed, 15 Sep 2004 14:45:55 +1000 To: "David S. Miller" Cc: jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [RTNETLINK] Convert RTM_* to enum Message-ID: <20040915044555.GA1323@gondor.apana.org.au> References: <20040915020942.GA32721@gondor.apana.org.au> <20040915034748.GA952@gondor.apana.org.au> <20040914213837.75634b93.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914213837.75634b93.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 620 Lines: 17 On Tue, Sep 14, 2004 at 09:38:37PM -0700, David S. Miller wrote: > > Right. If we start using defines we have to keep them around. > I know it's bogus for people to ifdef this stuff, but we know > they do, and it's in bad taste to knowingly break stuff like that. How about if we make it a rule that we only add new enum constants but not macros? > Anyways, I'll apply your patch Herbert, thanks. Thanks. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue Sep 14 21:49:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 21:49:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F4nNM1024677 for ; Tue, 14 Sep 2004 21:49:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7Rgy-0000aS-00; Tue, 14 Sep 2004 21:46:52 -0700 Date: Tue, 14 Sep 2004 21:46:52 -0700 From: "David S. Miller" To: Herbert Xu Cc: jmorris@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [RTNETLINK] Convert RTM_* to enum Message-Id: <20040914214652.5ef63dfa.davem@davemloft.net> In-Reply-To: <20040915044555.GA1323@gondor.apana.org.au> References: <20040915020942.GA32721@gondor.apana.org.au> <20040915034748.GA952@gondor.apana.org.au> <20040914213837.75634b93.davem@davemloft.net> <20040915044555.GA1323@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 532 Lines: 14 On Wed, 15 Sep 2004 14:45:55 +1000 Herbert Xu wrote: > On Tue, Sep 14, 2004 at 09:38:37PM -0700, David S. Miller wrote: > > > > Right. If we start using defines we have to keep them around. > > I know it's bogus for people to ifdef this stuff, but we know > > they do, and it's in bad taste to knowingly break stuff like that. > > How about if we make it a rule that we only add new enum constants > but not macros? If you create some new enumeration from scratch, sure, but for existing ones no. From vkondra@mail.ru Tue Sep 14 22:45:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 22:45:40 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F5jXVB026121 for ; Tue, 14 Sep 2004 22:45:33 -0700 Received: from [81.218.113.45] (port=26818 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1C7SbY-000HBg-00; Wed, 15 Sep 2004 09:45:22 +0400 From: Vladimir Kondratiev To: "Luis R. Rodriguez" Subject: Re: generic 802.11 stack Date: Wed, 15 Sep 2004 08:44:38 +0300 User-Agent: KMail/1.7 Cc: acx100-devel@lists.sourceforge.net, "David S. Miller" , greg chesson , hadi@cyberus.ca, Jeff Garzik , "Luis R. Rodriguez" , netdev@oss.sgi.com, prism54-devel@prism54.org, sam@errno.com References: <4145352F.4040807@pobox.com> <20040915030545.GA25307@havoc.gtf.org> <20040915031732.GL7839@ruslug.rutgers.edu> In-Reply-To: <20040915031732.GL7839@ruslug.rutgers.edu> MIME-Version: 1.0 Message-Id: <200409150844.45242.vkondra@mail.ru> Content-Type: multipart/signed; boundary="nextPart1219258.HLbHKuVhPC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-archive-position: 8832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2378 Lines: 67 --nextPart1219258.HLbHKuVhPC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Let me answer to the set of questions raised: =2D dual licensing: I am not ready to answer for legal. I will discuss with= =20 proper people and answer. =2D code style: regardless of answer on question above, I intend to do Linu= x=20 work and will not care about compatibility macros. I really dislike such=20 macros, they do make code hard to understand. =2D information sharing (driver-stack): good question indeed. I am currentl= y=20 evaluating it. This far, I think I will supply some standard link layer=20 information per packet. Like rate, RSSI etc. For Tx, it will include also=20 crypto key for hardware assisted encryption, type of protection (RTS/CTS=20 etc.) I believe it should be sufficient. To prove it, I am going to write=20 some dummy .11 driver that will be capable to simulate any Rx, with user=20 interface for feeding packets. I will use this driver to debug stack. It is complex issue to support all combination of job separation between ho= st=20 and NIC, I will choose some model like "NIC do almost nothing" and will=20 develop around it.=20 Vladimir. On Wednesday 15 September 2004 06:17, Luis R. Rodriguez wrote: LR> On Tue, Sep 14, 2004 at 11:05:45PM -0400, Jeff Garzik wrote: LR> > On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote: LR> > > I proposed dual licensing not to specifically allow clear compatibility LR> > > among linux and the BSDs on the 802.11 work, but to allow BSDers to do LR> > > whatever they want with what we come up with -- help with code sharing. LR> > LR> > LR> > Overall, He Who Writes The Code Gets To Choose. LR> > LR> > My own personal opinion is that the BSD license goes against the stat= ed LR> > spirit of Linux -- contribute back. But that's just me. LR> > LR> LR> Agreed -- but in this case I feel we're the bigger crowd so I wanted to LR> address to the *author* that I feel we should be considerate to the BSD LR> crowd. LR> LR> Luis LR> --nextPart1219258.HLbHKuVhPC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBR9bNqxdj7mhC6o0RAvicAJ9S+JJLxreQBdV87DQMWt71ACAhvwCfbUFD LbN2BOegk6f+D3w49PoRJ20= =UuPp -----END PGP SIGNATURE----- --nextPart1219258.HLbHKuVhPC-- From davem@davemloft.net Tue Sep 14 22:47:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 22:47:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F5lqeb026415 for ; Tue, 14 Sep 2004 22:47:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7SbN-0000fx-00; Tue, 14 Sep 2004 22:45:09 -0700 Date: Tue, 14 Sep 2004 22:45:09 -0700 From: "David S. Miller" To: Lincoln Dale Cc: i@stingr.net, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [RFC] Support for wccp version 1 and 2 in ip_gre.c Message-Id: <20040914224509.685cd2c6.davem@davemloft.net> In-Reply-To: <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> References: <20040913051706.GB26337@stingr.sgu.ru> <20040911194108.GS28258@stingr.sgu.ru> <20040912170505.62916147.davem@davemloft.net> <20040913051706.GB26337@stingr.sgu.ru> <5.1.0.14.2.20040914184652.03e24de0@171.71.163.14> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2791 Lines: 72 On Tue, 14 Sep 2004 18:48:20 +1000 Lincoln Dale wrote: > the logic is correct, but it may make sense to call the appropriate > netfilter hook again with the "unwrapped" GRE packet, as otherwise > packets-inside-GRE represent a possible security hole where one can inject > packets externally and bypass firewall rules. This will occur when we push the packet back into the RX path via the netif_rx() call. Paul if you want to fix up the comment, that's fine. But please send such a patch relative to what I put into the tree already which is the following: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 16:04:36-07:00 i@stingr.net # [IPV4]: Add wccp v1/v2 support to ip_gre.c # # Signed-off-by: David S. Miller # # net/ipv4/ip_gre.c # 2004/09/13 16:04:06-07:00 i@stingr.net +12 -1 # [IPV4]: Add wccp v1/v2 support to ip_gre.c # # include/linux/if_ether.h # 2004/09/13 16:04:06-07:00 i@stingr.net +2 -0 # [IPV4]: Add wccp v1/v2 support to ip_gre.c # diff -Nru a/include/linux/if_ether.h b/include/linux/if_ether.h --- a/include/linux/if_ether.h 2004-09-14 22:27:39 -07:00 +++ b/include/linux/if_ether.h 2004-09-14 22:27:39 -07:00 @@ -59,6 +59,8 @@ #define ETH_P_8021Q 0x8100 /* 802.1Q VLAN Extended Header */ #define ETH_P_IPX 0x8137 /* IPX over DIX */ #define ETH_P_IPV6 0x86DD /* IPv6 over bluebook */ +#define ETH_P_WCCP 0x883E /* Web-cache coordination protocol + * defined in draft-wilson-wrec-wccp-v2-00.txt */ #define ETH_P_PPP_DISC 0x8863 /* PPPoE discovery messages */ #define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */ #define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */ diff -Nru a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c --- a/net/ipv4/ip_gre.c 2004-09-14 22:27:39 -07:00 +++ b/net/ipv4/ip_gre.c 2004-09-14 22:27:39 -07:00 @@ -603,13 +603,24 @@ if ((tunnel = ipgre_tunnel_lookup(iph->saddr, iph->daddr, key)) != NULL) { secpath_reset(skb); + skb->protocol = *(u16*)(h + 2); + /* WCCP version 1 and 2 protocol decoding. + * - Change protocol to IP + * - When dealing with WCCPv2, Skip extra 4 bytes in GRE header + */ + if (flags == 0 && + skb->protocol == __constant_htons(ETH_P_WCCP)) { + skb->protocol = __constant_htons(ETH_P_IP); + if ((*(h + offset) & 0xF0) != 0x40) + offset += 4; + } + skb->mac.raw = skb->nh.raw; skb->nh.raw = __pskb_pull(skb, offset); memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); if (skb->ip_summed == CHECKSUM_HW) skb->csum = csum_sub(skb->csum, csum_partial(skb->mac.raw, skb->nh.raw-skb->mac.raw, 0)); - skb->protocol = *(u16*)(h + 2); skb->pkt_type = PACKET_HOST; #ifdef CONFIG_NET_IPGRE_BROADCAST if (MULTICAST(iph->daddr)) { From eric.lemoine@gmail.com Tue Sep 14 22:50:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 22:51:25 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F5oc1R026771 for ; Tue, 14 Sep 2004 22:50:39 -0700 Received: by mproxy.gmail.com with SMTP id 77so140462rnk for ; Tue, 14 Sep 2004 22:50:28 -0700 (PDT) Received: by 10.38.96.12 with SMTP id t12mr331895rnb; Tue, 14 Sep 2004 22:50:28 -0700 (PDT) Received: by 10.38.99.58 with HTTP; Tue, 14 Sep 2004 22:50:28 -0700 (PDT) Message-ID: <5cac192f04091422506d13c530@mail.gmail.com> Date: Wed, 15 Sep 2004 07:50:28 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: Harald Welte Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Cc: "David S. Miller" , netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org In-Reply-To: <20040914200238.GM8434@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <20040914124315.716e9c68.davem@davemloft.net> <20040914200238.GM8434@sunbeam.de.gnumonks.org> X-archive-position: 8834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 730 Lines: 22 On Tue, 14 Sep 2004 22:02:38 +0200, Harald Welte wrote: > On Tue, Sep 14, 2004 at 12:43:15PM -0700, David S. Miller wrote: > > > > Harald.... check current BK it has NAPI support added > > to the sungem.c driver already, it was written by Eric Lemoine > > with some fixes by myself and benh :-) > > Gnah, I hate duplicated efforts. Well, I learned a bit about NIC > drivers, though :( Your patch has the netpoll bits while current BK does not. > Before I start NAPI-enabling natsemi.c (and again duplicate work): Do > you know of anybody working on this yet? I'm not ;-) PS: If you happened to experiment with the NAPIfied SunGEM driver on your setup, could you please share the data. Thx. -- Eric From davem@davemloft.net Tue Sep 14 22:51:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 22:51:48 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F5phkL026934 for ; Tue, 14 Sep 2004 22:51:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7SfO-0000gp-00; Tue, 14 Sep 2004 22:49:18 -0700 Date: Tue, 14 Sep 2004 22:49:17 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, miyazawa@linux-ipv6.org Subject: Re: [PATCH] IPV6: missing xfrm_loock() in icmpv6_{send,echo_reply}() Message-Id: <20040914224917.033f807e.davem@davemloft.net> In-Reply-To: <20040915.090424.59114323.yoshfuji@linux-ipv6.org> References: <20040915.090424.59114323.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8F5phkL026934 X-archive-position: 8835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 427 Lines: 12 On Wed, 15 Sep 2004 09:04:24 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > net/ipv6/icmp.c was not converted in xfrm_lookup() extraction patch. > This patch converts it; adding the missing call to xfrm_lookup in > icmpv6_{send,echo_reply}(). > > Signed-off-by: Kazunori Miyazawa > Signed-off-by: Hideaki YOSHIFUJI Applied, thanks a lot. From vda@port.imtp.ilyichevsk.odessa.ua Tue Sep 14 23:18:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 23:18:58 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8F6IcBr028283 for ; Tue, 14 Sep 2004 23:18:50 -0700 Received: (qmail 403 invoked by alias); 15 Sep 2004 06:18:14 -0000 Received: from unknown (195.66.192.167) by 0 (195.66.192.168) with ESMTP; 15 Sep 2004 06:18:14 -0000 From: Denis Vlasenko To: Lewis Adam-CAL022 , netdev@oss.sgi.com Subject: Re: How to pass a string via iwpriv Date: Wed, 15 Sep 2004 09:18:01 +0300 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409150918.01534.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 8836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 501 Lines: 17 On Wednesday 15 September 2004 05:58, Lewis Adam-CAL022 wrote: > Is there a way to create a private extension (e.g. to be invoked by iwpriv) > that I can pass a string argument? Looking in wirless.h, I see types for > byte, float, int, char, etc., but no char*. example from acx100 driver: static const struct iw_priv_args acx100_ioctl_private_args[] = { ... { cmd : ACX100_IOCTL_SET_RATES, set_args : IW_PRIV_TYPE_CHAR | 256, get_args : 0, name : "SetRates" }, ... -- vda From eric.lemoine@gmail.com Tue Sep 14 23:43:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 23:43:54 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F6hnfZ029040 for ; Tue, 14 Sep 2004 23:43:50 -0700 Received: by mproxy.gmail.com with SMTP id 77so145362rnk for ; Tue, 14 Sep 2004 23:43:39 -0700 (PDT) Received: by 10.38.96.12 with SMTP id t12mr357501rnb; Tue, 14 Sep 2004 23:43:39 -0700 (PDT) Received: by 10.38.99.58 with HTTP; Tue, 14 Sep 2004 23:43:39 -0700 (PDT) Message-ID: <5cac192f040914234361e1b929@mail.gmail.com> Date: Wed, 15 Sep 2004 08:43:39 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: "David S. Miller" Subject: [SUNGEM] add tx_lock Cc: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_82_3987604.1095230619574" X-archive-position: 8837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 15433 Lines: 211 ------=_Part_82_3987604.1095230619574 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline The attached patch makes SunGEM NAPI driver in conformance to tg3 and e1000 in terms of locking logic. Applies to current BK:net-2.6. [LLTX patch to follow] -- Eric ------=_Part_82_3987604.1095230619574 Content-Type: application/octet-stream; name="patch-rset-sungem_txlock-2-6-9-rc1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-rset-sungem_txlock-2-6-9-rc1" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMTUgMDg6MjY6NTUrMDI6MDAgZXJpYy5sZW1vaW5lQGdt YWlsLmNvbSAKIyAgIFtTVU5HRU1dOiBhZGQgdHhfbG9jayB0byBjb25mb3JtIHRvIHRnMyBhbmQg ZTEwMDAKIyAgIAojICAgVXNpbmcgdHhfbG9jayBpbiBTdW5HRU0gbWFrZXMgdGhlIGRyaXZlciBs b2dpYyBpbiBjb25mb3JtYW5jZSAKIyAgIHdpdGggdGczIGFuZCBlMTAwMCwgZWFzaW5nIG1haW50 YWluYW5jZS4KIyAgIAojICAgU2lnbmVkLW9mZi1ieTogRXJpYyBMZW1vaW5lIDxlcmljLmxlbW9p bmVAZ21haWwuY29tPgojICAgCiMgCiMgZHJpdmVycy9uZXQvc3VuZ2VtLmgKIyAgIDIwMDQvMDkv MTUgMDg6MjY6NDcrMDI6MDAgZXJpYy5sZW1vaW5lQGdtYWlsLmNvbSArMSAtMAojICAgW1NVTkdF TV06IGFkZCB0eF9sb2NrIHRvIGNvbmZvcm0gdG8gdGczIGFuZCBlMTAwMAojICAgCiMgICBTaWdu ZWQtb2ZmLWJ5OiBFcmljIExlbW9pbmUgPGVyaWMubGVtb2luZUBnbWFpbC5jb20+CiMgICAKIyAK IyBkcml2ZXJzL25ldC9zdW5nZW0uYwojICAgMjAwNC8wOS8xNSAwODoyNjo0NyswMjowMCBlcmlj LmxlbW9pbmVAZ21haWwuY29tICs1OCAtMTcKIyAgIFtTdW5HRU1dOiBhZGQgdHhfbG9jayB0byBj b25mb3JtIHRvIHRnMyBhbmQgZTEwMDAKIyAgIAojICAgU2lnbmVkLW9mZi1ieTogRXJpYyBMZW1v aW5lIDxlcmljLmxlbW9pbmVAZ21haWwuY29tPgojICAgCiMgCmRpZmYgLU5ydSBhL2RyaXZlcnMv bmV0L3N1bmdlbS5jIGIvZHJpdmVycy9uZXQvc3VuZ2VtLmMKLS0tIGEvZHJpdmVycy9uZXQvc3Vu Z2VtLmMJMjAwNC0wOS0xNSAwODozNzo1MiArMDI6MDAKKysrIGIvZHJpdmVycy9uZXQvc3VuZ2Vt LmMJMjAwNC0wOS0xNSAwODozNzo1MiArMDI6MDAKQEAgLTgzMiw3ICs4MzIsOSBAQAogCQl9CiAK IAkJLyogUnVuIFRYIGNvbXBsZXRpb24gdGhyZWFkICovCisJCXNwaW5fbG9jaygmZ3AtPnR4X2xv Y2spOwogCQlnZW1fdHgoZGV2LCBncCwgZ3AtPnN0YXR1cyk7CisJCXNwaW5fdW5sb2NrKCZncC0+ dHhfbG9jayk7CiAKIAkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZ3AtPmxvY2ssIGZsYWdzKTsK IApAQCAtOTE3LDEwICs5MTksMTIgQEAKIAkgICAgICAgcmVhZGwoZ3AtPnJlZ3MgKyBNQUNfUlhD RkcpKTsKIAogCXNwaW5fbG9ja19pcnEoJmdwLT5sb2NrKTsKKwlzcGluX2xvY2soJmdwLT50eF9s b2NrKTsKIAogCWdwLT5yZXNldF90YXNrX3BlbmRpbmcgPSAyOwogCXNjaGVkdWxlX3dvcmsoJmdw LT5yZXNldF90YXNrKTsKIAorCXNwaW5fdW5sb2NrKCZncC0+dHhfbG9jayk7CiAJc3Bpbl91bmxv Y2tfaXJxKCZncC0+bG9jayk7CiB9CiAKQEAgLTk1MSwxMiArOTU1LDEyIEBACiAJCQkoY3N1bV9z dHVmZl9vZmYgPDwgMjEpKTsKIAl9CiAKLQlzcGluX2xvY2tfaXJxKCZncC0+bG9jayk7CisJc3Bp bl9sb2NrX2lycSgmZ3AtPnR4X2xvY2spOwogCiAJLyogVGhpcyBpcyBhIGhhcmQgZXJyb3IsIGxv ZyBpdC4gKi8KIAlpZiAoVFhfQlVGRlNfQVZBSUwoZ3ApIDw9IChza2Jfc2hpbmZvKHNrYiktPm5y X2ZyYWdzICsgMSkpIHsKIAkJbmV0aWZfc3RvcF9xdWV1ZShkZXYpOwotCQlzcGluX3VubG9ja19p cnEoJmdwLT5sb2NrKTsKKwkJc3Bpbl91bmxvY2tfaXJxKCZncC0+dHhfbG9jayk7CiAJCXByaW50 ayhLRVJOX0VSUiBQRlggIiVzOiBCVUchIFR4IFJpbmcgZnVsbCB3aGVuIHF1ZXVlIGF3YWtlIVxu IiwKIAkJICAgICAgIGRldi0+bmFtZSk7CiAJCXJldHVybiAxOwpAQCAtMTA0Myw3ICsxMDQ3LDcg QEAKIAkJICAgICAgIGRldi0+bmFtZSwgZW50cnksIHNrYi0+bGVuKTsKIAltYigpOwogCXdyaXRl bChncC0+dHhfbmV3LCBncC0+cmVncyArIFRYRE1BX0tJQ0spOwotCXNwaW5fdW5sb2NrX2lycSgm Z3AtPmxvY2spOworCXNwaW5fdW5sb2NrX2lycSgmZ3AtPnR4X2xvY2spOwogCiAJZGV2LT50cmFu c19zdGFydCA9IGppZmZpZXM7CiAKQEAgLTEwNzQsOSArMTA3OCwxMSBAQAogCX0KIAogCXNwaW5f bG9ja19pcnEoJmdwLT5sb2NrKTsKKwlzcGluX2xvY2soJmdwLT50eF9sb2NrKTsKIAlkZXYtPm10 dSA9IG5ld19tdHU7CiAJZ3AtPnJlc2V0X3Rhc2tfcGVuZGluZyA9IDE7CiAJc2NoZWR1bGVfd29y aygmZ3AtPnJlc2V0X3Rhc2spOworCXNwaW5fdW5sb2NrKCZncC0+dHhfbG9jayk7CiAJc3Bpbl91 bmxvY2tfaXJxKCZncC0+bG9jayk7CiAKIAlmbHVzaF9zY2hlZHVsZWRfd29yaygpOwpAQCAtMTA4 Niw3ICsxMDkyLDcgQEAKIAogI2RlZmluZSBTVE9QX1RSSUVTIDMyCiAKLS8qIE11c3QgYmUgaW52 b2tlZCB1bmRlciBncC0+bG9jay4gKi8KKy8qIE11c3QgYmUgaW52b2tlZCB1bmRlciBncC0+bG9j ayBhbmQgZ3AtPnR4X2xvY2suICovCiBzdGF0aWMgdm9pZCBnZW1fc3RvcChzdHJ1Y3QgZ2VtICpn cCkKIHsKIAlpbnQgbGltaXQ7CkBAIC0xMTEyLDcgKzExMTgsNyBAQAogCQlwcmludGsoS0VSTl9F UlIgIiVzOiBTVyByZXNldCBpcyBnaGV0dG8uXG4iLCBncC0+ZGV2LT5uYW1lKTsKIH0KIAotLyog TXVzdCBiZSBpbnZva2VkIHVuZGVyIGdwLT5sb2NrLiAqLworLyogTXVzdCBiZSBpbnZva2VkIHVu ZGVyIGdwLT5sb2NrIGFuZCBncC0+dHhfbG9jay4gKi8KIHN0YXRpYyB2b2lkIGdlbV9zdGFydF9k bWEoc3RydWN0IGdlbSAqZ3ApCiB7CiAJdW5zaWduZWQgbG9uZyB2YWw7CkBAIC0xMTM3LDcgKzEx NDMsNyBAQAogfQogCiAKLS8qIE11c3QgYmUgaW52b2tlZCB1bmRlciBncC0+bG9jay4gKi8KKy8q IE11c3QgYmUgaW52b2tlZCB1bmRlciBncC0+bG9jayBhbmQgZ3AtPnR4X2xvY2suICovCiAvLyBY WFggZGJsIGNoZWNrIHdoYXQgdGhhdCBmdW5jdGlvbiBzaG91bGQgZG8gd2hlbiBjYWxsZWQgb24g UENTIFBIWQogc3RhdGljIHZvaWQgZ2VtX2JlZ2luX2F1dG9fbmVnb3RpYXRpb24oc3RydWN0IGdl bSAqZ3AsIHN0cnVjdCBldGh0b29sX2NtZCAqZXApCiB7CkBAIC0xMjI0LDcgKzEyMzAsNyBAQAog LyogQSBsaW5rLXVwIGNvbmRpdGlvbiBoYXMgb2NjdXJyZWQsIGluaXRpYWxpemUgYW5kIGVuYWJs ZSB0aGUKICAqIHJlc3Qgb2YgdGhlIGNoaXAuCiAgKgotICogTXVzdCBiZSBpbnZva2VkIHVuZGVy IGdwLT5sb2NrLgorICogTXVzdCBiZSBpbnZva2VkIHVuZGVyIGdwLT5sb2NrIGFuZCBncC0+dHhf bG9jay4KICAqLwogc3RhdGljIGludCBnZW1fc2V0X2xpbmtfbW9kZXMoc3RydWN0IGdlbSAqZ3Ap CiB7CkBAIC0xMzMxLDcgKzEzMzcsNyBAQAogCXJldHVybiAwOwogfQogCi0vKiBNdXN0IGJlIGlu dm9rZWQgdW5kZXIgZ3AtPmxvY2suICovCisvKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxv Y2sgYW5kIGdwLT50eF9sb2NrLiAqLwogc3RhdGljIGludCBnZW1fbWRpb19saW5rX25vdF91cChz dHJ1Y3QgZ2VtICpncCkKIHsKIAlzd2l0Y2ggKGdwLT5sc3RhdGUpIHsKQEAgLTEzODksNiArMTM5 NSw3IEBACiAKIAluZXRpZl9wb2xsX2Rpc2FibGUoZ3AtPmRldik7CiAJc3Bpbl9sb2NrX2lycSgm Z3AtPmxvY2spOworCXNwaW5fbG9jaygmZ3AtPnR4X2xvY2spOwogCiAJaWYgKGdwLT5od19ydW5u aW5nICYmIGdwLT5vcGVuZWQpIHsKIAkJbmV0aWZfc3RvcF9xdWV1ZShncC0+ZGV2KTsKQEAgLTE0 MDQsNiArMTQxMSw3IEBACiAJfQogCWdwLT5yZXNldF90YXNrX3BlbmRpbmcgPSAwOwogCisJc3Bp bl91bmxvY2soJmdwLT50eF9sb2NrKTsKIAlzcGluX3VubG9ja19pcnEoJmdwLT5sb2NrKTsKIAlu ZXRpZl9wb2xsX2VuYWJsZShncC0+ZGV2KTsKIH0KQEAgLTE0MTcsNiArMTQyNSw3IEBACiAJCXJl dHVybjsKIAogCXNwaW5fbG9ja19pcnEoJmdwLT5sb2NrKTsKKwlzcGluX2xvY2soJmdwLT50eF9s b2NrKTsKIAogCS8qIElmIHRoZSBsaW5rIG9mIHRhc2sgaXMgc3RpbGwgcGVuZGluZywgd2UganVz dAogCSAqIHJlc2NoZWR1bGUgdGhlIGxpbmsgdGltZXIKQEAgLTE0ODYsMTAgKzE0OTUsMTEgQEAK IHJlc3RhcnQ6CiAJbW9kX3RpbWVyKCZncC0+bGlua190aW1lciwgamlmZmllcyArICgoMTIgKiBI WikgLyAxMCkpOwogb3V0X3VubG9jazoKKwlzcGluX3VubG9jaygmZ3AtPnR4X2xvY2spOwogCXNw aW5fdW5sb2NrX2lycSgmZ3AtPmxvY2spOwogfQogCi0vKiBNdXN0IGJlIGludm9rZWQgdW5kZXIg Z3AtPmxvY2suICovCisvKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxvY2sgYW5kIGdwLT50 eF9sb2NrLiAqLwogc3RhdGljIHZvaWQgZ2VtX2NsZWFuX3JpbmdzKHN0cnVjdCBnZW0gKmdwKQog ewogCXN0cnVjdCBnZW1faW5pdF9ibG9jayAqZ2IgPSBncC0+aW5pdF9ibG9jazsKQEAgLTE1NDAs NyArMTU1MCw3IEBACiAJfQogfQogCi0vKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxvY2su ICovCisvKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxvY2sgYW5kIGdwLT50eF9sb2NrLiAq Lwogc3RhdGljIHZvaWQgZ2VtX2luaXRfcmluZ3Moc3RydWN0IGdlbSAqZ3ApCiB7CiAJc3RydWN0 IGdlbV9pbml0X2Jsb2NrICpnYiA9IGdwLT5pbml0X2Jsb2NrOwpAQCAtMTU5MCw3ICsxNjAwLDcg QEAKIAl3bWIoKTsKIH0KIAotLyogTXVzdCBiZSBpbnZva2VkIHVuZGVyIGdwLT5sb2NrLiAqLwor LyogTXVzdCBiZSBpbnZva2VkIHVuZGVyIGdwLT5sb2NrIGFuZCBncC0+dHhfbG9jay4gKi8KIHN0 YXRpYyB2b2lkIGdlbV9pbml0X3BoeShzdHJ1Y3QgZ2VtICpncCkKIHsKIAl1MzIgbWlmY2ZnOwpA QCAtMTcyOCw3ICsxNzM4LDcgQEAKIAl9CiB9CiAKLS8qIE11c3QgYmUgaW52b2tlZCB1bmRlciBn cC0+bG9jay4gKi8KKy8qIE11c3QgYmUgaW52b2tlZCB1bmRlciBncC0+bG9jayBhbmQgZ3AtPnR4 X2xvY2suICovCiBzdGF0aWMgdm9pZCBnZW1faW5pdF9kbWEoc3RydWN0IGdlbSAqZ3ApCiB7CiAJ dTY0IGRlc2NfZG1hID0gKHU2NCkgZ3AtPmdibG9ja19kdm1hOwpAQCAtMTc2Niw3ICsxNzc2LDcg QEAKIAkJICAgICAgIGdwLT5yZWdzICsgUlhETUFfQkxBTkspOwogfQogCi0vKiBNdXN0IGJlIGlu dm9rZWQgdW5kZXIgZ3AtPmxvY2suICovCisvKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxv Y2sgYW5kIGdwLT50eF9sb2NrLiAqLwogc3RhdGljIHUzMgogZ2VtX3NldHVwX211bHRpY2FzdChz dHJ1Y3QgZ2VtICpncCkKIHsKQEAgLTE4MDksNyArMTgxOSw3IEBACiAJcmV0dXJuIHJ4Y2ZnOwog fQogCi0vKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxvY2suICovCisvKiBNdXN0IGJlIGlu dm9rZWQgdW5kZXIgZ3AtPmxvY2sgYW5kIGdwLT50eF9sb2NrLiAqLwogc3RhdGljIHZvaWQgZ2Vt X2luaXRfbWFjKHN0cnVjdCBnZW0gKmdwKQogewogCXVuc2lnbmVkIGNoYXIgKmUgPSAmZ3AtPmRl di0+ZGV2X2FkZHJbMF07CkBAIC0xODg3LDcgKzE4OTcsNyBAQAogCXdyaXRlbCgweGZmZmZmZmZm LCBncC0+cmVncyArIE1BQ19NQ01BU0spOwogfQogCi0vKiBNdXN0IGJlIGludm9rZWQgdW5kZXIg Z3AtPmxvY2suICovCisvKiBNdXN0IGJlIGludm9rZWQgdW5kZXIgZ3AtPmxvY2sgYW5kIGdwLT50 eF9sb2NrLiAqLwogc3RhdGljIHZvaWQgZ2VtX2luaXRfcGF1c2VfdGhyZXNob2xkcyhzdHJ1Y3Qg Z2VtICpncCkKIHsKICAgICAgICAJdTMyIGNmZzsKQEAgLTIwMjMsNyArMjAzMyw3IEBACiAJcmV0 dXJuIDA7CiB9CiAKLS8qIE11c3QgYmUgaW52b2tlZCB1bmRlciBncC0+bG9jay4gKi8KKy8qIE11 c3QgYmUgaW52b2tlZCB1bmRlciBncC0+bG9jayBhbmQgZ3AtPnR4X2xvY2suICovCiBzdGF0aWMg dm9pZCBnZW1faW5pdF9odyhzdHJ1Y3QgZ2VtICpncCwgaW50IHJlc3RhcnRfbGluaykKIHsKIAkv KiBPbiBBcHBsZSdzIGdtYWMsIEkgaW5pdGlhbGl6ZSB0aGUgUEhZIG9ubHkgYWZ0ZXIKQEAgLTIx MjEsOSArMjEzMSwxMSBAQAogCiAJaWYgKCFncC0+d2FrZV9vbl9sYW4pIHsKIAkJc3Bpbl9sb2Nr X2lycXNhdmUoJmdwLT5sb2NrLCBmbGFncyk7CisJCXNwaW5fbG9jaygmZ3AtPnR4X2xvY2spOwog CQlnZW1fc3RvcChncCk7CiAJCXdyaXRlbChNQUNfVFhSU1RfQ01ELCBncC0+cmVncyArIE1BQ19U WFJTVCk7CiAJCXdyaXRlbChNQUNfUlhSU1RfQ01ELCBncC0+cmVncyArIE1BQ19SWFJTVCk7CisJ CXNwaW5fdW5sb2NrKCZncC0+dHhfbG9jayk7CiAJCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdw LT5sb2NrLCBmbGFncyk7CiAJfQogCkBAIC0yMTcxLDggKzIxODMsMTAgQEAKIAkJdW5zaWduZWQg bG9uZyBmbGFnczsKIAogCQlzcGluX2xvY2tfaXJxc2F2ZSgmZ3AtPmxvY2ssIGZsYWdzKTsKKwkJ c3Bpbl9sb2NrKCZncC0+dHhfbG9jayk7CiAJCWdlbV9zdG9wKGdwKTsKLQkJc3Bpbl91bmxvY2tf aXJxcmVzdG9yZSgmZ3AtPmxvY2ssIGZsYWdzKTsJCisJCXNwaW5fdW5sb2NrKCZncC0+dHhfbG9j ayk7CisJCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdwLT5sb2NrLCBmbGFncyk7CiAJfQogfQog CkBAIC0yMjMyLDcgKzIyNDYsOSBAQAogCiAJCS8qIFJlc2V0IHRoZSBjaGlwICovCiAJCXNwaW5f bG9ja19pcnEoJmdwLT5sb2NrKTsKKwkJc3Bpbl9sb2NrKCZncC0+dHhfbG9jayk7CiAJCWdlbV9z dG9wKGdwKTsKKwkJc3Bpbl91bmxvY2soJmdwLT50eF9sb2NrKTsKIAkJc3Bpbl91bmxvY2tfaXJx KCZncC0+bG9jayk7CiAKIAkJZ3AtPmh3X3J1bm5pbmcgPSAxOwpAQCAtMjI0Niw2ICsyMjYyLDcg QEAKIAkJcHJpbnRrKEtFUk5fRVJSICIlczogZmFpbGVkIHRvIHJlcXVlc3QgaXJxICFcbiIsIGdw LT5kZXYtPm5hbWUpOwogCiAJCXNwaW5fbG9ja19pcnEoJmdwLT5sb2NrKTsKKwkJc3Bpbl9sb2Nr KCZncC0+dHhfbG9jayk7CiAjaWZkZWYgQ09ORklHX1BQQ19QTUFDCiAJCWlmICghaHdfd2FzX3Vw ICYmIGdwLT5wZGV2LT52ZW5kb3IgPT0gUENJX1ZFTkRPUl9JRF9BUFBMRSkKIAkJCWdlbV9hcHBs ZV9wb3dlcmRvd24oZ3ApOwpAQCAtMjI1NCwxMiArMjI3MSwxNCBAQAogCQlncC0+cG1fdGltZXIu ZXhwaXJlcyA9IGppZmZpZXMgKyAxMCpIWjsKIAkJYWRkX3RpbWVyKCZncC0+cG1fdGltZXIpOwog CQl1cCgmZ3AtPnBtX3NlbSk7CisJCXNwaW5fdW5sb2NrKCZncC0+dHhfbG9jayk7CiAJCXNwaW5f dW5sb2NrX2lycSgmZ3AtPmxvY2spOwogCiAJCXJldHVybiAtRUFHQUlOOwogCX0KIAogICAgICAg IAlzcGluX2xvY2tfaXJxKCZncC0+bG9jayk7CisJc3Bpbl9sb2NrKCZncC0+dHhfbG9jayk7CiAK IAkvKiBBbGxvY2F0ZSAmIHNldHVwIHJpbmcgYnVmZmVycyAqLwogCWdlbV9pbml0X3JpbmdzKGdw KTsKQEAgLTIyNjksNiArMjI4OCw3IEBACiAKIAlncC0+b3BlbmVkID0gMTsKIAorCXNwaW5fdW5s b2NrKCZncC0+dHhfbG9jayk7CiAJc3Bpbl91bmxvY2tfaXJxKCZncC0+bG9jayk7CiAKIAl1cCgm Z3AtPnBtX3NlbSk7CkBAIC0yMjg5LDYgKzIzMDksNyBAQAogCiAJLyogU3RvcCB0cmFmZmljLCBt YXJrIHVzIGNsb3NlZCAqLwogCXNwaW5fbG9ja19pcnEoJmdwLT5sb2NrKTsKKwlzcGluX2xvY2so JmdwLT50eF9sb2NrKTsKIAogCWdwLT5vcGVuZWQgPSAwOwkKIApAQCAtMjMwMyw2ICsyMzI0LDcg QEAKIAkvKiBCeWUsIHRoZSBwbSB0aW1lciB3aWxsIGZpbmlzaCB0aGUgam9iICovCiAJZnJlZV9p cnEoZ3AtPnBkZXYtPmlycSwgKHZvaWQgKikgZGV2KTsKIAorCXNwaW5fdW5sb2NrKCZncC0+dHhf bG9jayk7CiAJc3Bpbl91bmxvY2tfaXJxKCZncC0+bG9jayk7CiAKIAkvKiBGaXJlIHRoZSBQTSB0 aW1lciB0aGF0IHdpbGwgc2h1dCB1cyBkb3duIGluIGFib3V0IDEwIHNlY29uZHMgKi8KQEAgLTIz MzMsNiArMjM1NSw3IEBACiAJLyogSWYgdGhlIGRyaXZlciBpcyBvcGVuZWQsIHdlIHN0b3AgdGhl IERNQSAqLwogCWlmIChncC0+b3BlbmVkKSB7CiAJCXNwaW5fbG9ja19pcnEoJmdwLT5sb2NrKTsK KwkJc3Bpbl9sb2NrKCZncC0+dHhfbG9jayk7CiAKIAkJLyogU3RvcCB0cmFmZmljLCBtYXJrIHVz IGNsb3NlZCAqLwogCQluZXRpZl9kZXZpY2VfZGV0YWNoKGRldik7CkBAIC0yMzQzLDYgKzIzNjYs NyBAQAogCQkvKiBHZXQgcmlkIG9mIHJpbmcgYnVmZmVycyAqLwogCQlnZW1fY2xlYW5fcmluZ3Mo Z3ApOwogCisJCXNwaW5fdW5sb2NrKCZncC0+dHhfbG9jayk7CiAJCXNwaW5fdW5sb2NrX2lycSgm Z3AtPmxvY2spOwogCiAJCWlmIChncC0+cGRldi0+dmVuZG9yID09IFBDSV9WRU5ET1JfSURfQVBQ TEUpCkBAIC0yMzc2LDEyICsyNDAwLDE0IEBACiAJCX0KICNlbmRpZiAvKiBDT05GSUdfUFBDX1BN QUMgKi8KIAkJc3Bpbl9sb2NrX2lycSgmZ3AtPmxvY2spOworCQlzcGluX2xvY2soJmdwLT50eF9s b2NrKTsKIAogCQlnZW1fc3RvcChncCk7CiAJCWdwLT5od19ydW5uaW5nID0gMTsKIAkJZ2VtX2lu aXRfcmluZ3MoZ3ApOwogCQlnZW1faW5pdF9odyhncCwgMSk7CiAKKwkJc3Bpbl91bmxvY2soJmdw LT50eF9sb2NrKTsKIAkJc3Bpbl91bmxvY2tfaXJxKCZncC0+bG9jayk7CiAKIAkJbmV0aWZfZGV2 aWNlX2F0dGFjaChkZXYpOwpAQCAtMjQwMiw2ICsyNDI4LDcgQEAKIAlzdHJ1Y3QgbmV0X2Rldmlj ZV9zdGF0cyAqc3RhdHMgPSAmZ3AtPm5ldF9zdGF0czsKIAogCXNwaW5fbG9ja19pcnEoJmdwLT5s b2NrKTsKKwlzcGluX2xvY2soJmdwLT50eF9sb2NrKTsKIAogCWlmIChncC0+aHdfcnVubmluZykg ewogCQlzdGF0cy0+cnhfY3JjX2Vycm9ycyArPSByZWFkbChncC0+cmVncyArIE1BQ19GQ1NFUlIp OwpAQCAtMjQyMSw2ICsyNDQ4LDcgQEAKIAkJd3JpdGVsKDAsIGdwLT5yZWdzICsgTUFDX0xDT0xM KTsKIAl9CiAKKwlzcGluX3VubG9jaygmZ3AtPnR4X2xvY2spOwogCXNwaW5fdW5sb2NrX2lycSgm Z3AtPmxvY2spOwogCiAJcmV0dXJuICZncC0+bmV0X3N0YXRzOwpAQCAtMjQzNiw2ICsyNDY0LDcg QEAKIAkJcmV0dXJuOwogCQkKIAlzcGluX2xvY2tfaXJxKCZncC0+bG9jayk7CisJc3Bpbl9sb2Nr KCZncC0+dHhfbG9jayk7CiAKIAluZXRpZl9zdG9wX3F1ZXVlKGRldik7CiAKQEAgLTI0NjAsNiAr MjQ4OSw3IEBACiAKIAluZXRpZl93YWtlX3F1ZXVlKGRldik7CiAKKwlzcGluX3VubG9jaygmZ3At PnR4X2xvY2spOwogCXNwaW5fdW5sb2NrX2lycSgmZ3AtPmxvY2spOwogfQogCkBAIC0yNDkxLDYg KzI1MjEsNyBAQAogCiAJCS8qIFJldHVybiBjdXJyZW50IFBIWSBzZXR0aW5ncyAqLwogCQlzcGlu X2xvY2tfaXJxKCZncC0+bG9jayk7CisJCXNwaW5fbG9jaygmZ3AtPnR4X2xvY2spOwogCQljbWQt PmF1dG9uZWcgPSBncC0+d2FudF9hdXRvbmVnOwogCQljbWQtPnNwZWVkID0gZ3AtPnBoeV9taWku c3BlZWQ7CiAJCWNtZC0+ZHVwbGV4ID0gZ3AtPnBoeV9taWkuZHVwbGV4OwkJCQpAQCAtMjUwMiw2 ICsyNTMzLDcgQEAKIAkJICovCiAJCWlmIChjbWQtPmFkdmVydGlzaW5nID09IDApCiAJCQljbWQt PmFkdmVydGlzaW5nID0gY21kLT5zdXBwb3J0ZWQ7CisJCXNwaW5fdW5sb2NrKCZncC0+dHhfbG9j ayk7CiAJCXNwaW5fdW5sb2NrX2lycSgmZ3AtPmxvY2spOwogCX0gZWxzZSB7IC8vIFhYWCBQQ1Mg PwogCQljbWQtPnN1cHBvcnRlZCA9CkBAIC0yNTQxLDcgKzI1NzMsOSBAQAogCSAgICAgIAogCS8q IEFwcGx5IHNldHRpbmdzIGFuZCByZXN0YXJ0IGxpbmsgcHJvY2Vzcy4gKi8KIAlzcGluX2xvY2tf aXJxKCZncC0+bG9jayk7CisJc3Bpbl9sb2NrKCZncC0+dHhfbG9jayk7CiAJZ2VtX2JlZ2luX2F1 dG9fbmVnb3RpYXRpb24oZ3AsIGNtZCk7CisJc3Bpbl91bmxvY2soJmdwLT50eF9sb2NrKTsKIAlz cGluX3VubG9ja19pcnEoJmdwLT5sb2NrKTsKIAogCXJldHVybiAwOwpAQCAtMjU1Niw3ICsyNTkw LDkgQEAKIAogCS8qIFJlc3RhcnQgbGluayBwcm9jZXNzLiAqLwogCXNwaW5fbG9ja19pcnEoJmdw LT5sb2NrKTsKKwlzcGluX2xvY2soJmdwLT50eF9sb2NrKTsKIAlnZW1fYmVnaW5fYXV0b19uZWdv dGlhdGlvbihncCwgTlVMTCk7CisJc3Bpbl91bmxvY2soJmdwLT50eF9sb2NrKTsKIAlzcGluX3Vu bG9ja19pcnEoJmdwLT5sb2NrKTsKIAogCXJldHVybiAwOwpAQCAtMjgwOCw2ICsyODQ0LDcgQEAK IAlncC0+bXNnX2VuYWJsZSA9IERFRkFVTFRfTVNHOwogCiAJc3Bpbl9sb2NrX2luaXQoJmdwLT5s b2NrKTsKKwlzcGluX2xvY2tfaW5pdCgmZ3AtPnR4X2xvY2spOwogCWluaXRfTVVURVgoJmdwLT5w bV9zZW0pOwogCiAJaW5pdF90aW1lcigmZ3AtPmxpbmtfdGltZXIpOwpAQCAtMjg0Myw3ICsyODgw LDkgQEAKIAkJZ2VtX2FwcGxlX3Bvd2VydXAoZ3ApOwogI2VuZGlmCiAJc3Bpbl9sb2NrX2lycSgm Z3AtPmxvY2spOworCXNwaW5fbG9jaygmZ3AtPnR4X2xvY2spOwogCWdlbV9zdG9wKGdwKTsKKwlz cGluX3VubG9jaygmZ3AtPnR4X2xvY2spOwogCXNwaW5fdW5sb2NrX2lycSgmZ3AtPmxvY2spOwog CiAJLyogRmlsbCB1cCB0aGUgbWlpX3BoeSBzdHJ1Y3R1cmUgKGV2ZW4gaWYgd2Ugd29uJ3QgdXNl IGl0KSAqLwpAQCAtMjkwNiw5ICsyOTQ1LDExIEBACiAKIAkvKiBEZXRlY3QgJiBpbml0IFBIWSwg c3RhcnQgYXV0b25lZyAqLwogCXNwaW5fbG9ja19pcnEoJmdwLT5sb2NrKTsKKwlzcGluX2xvY2so JmdwLT50eF9sb2NrKTsKIAlncC0+aHdfcnVubmluZyA9IDE7CiAJZ2VtX2luaXRfcGh5KGdwKTsK IAlnZW1fYmVnaW5fYXV0b19uZWdvdGlhdGlvbihncCwgTlVMTCk7CisJc3Bpbl91bmxvY2soJmdw LT50eF9sb2NrKTsKIAlzcGluX3VubG9ja19pcnEoJmdwLT5sb2NrKTsKIAogCWlmIChncC0+cGh5 X3R5cGUgPT0gcGh5X21paV9tZGlvMCB8fApkaWZmIC1OcnUgYS9kcml2ZXJzL25ldC9zdW5nZW0u aCBiL2RyaXZlcnMvbmV0L3N1bmdlbS5oCi0tLSBhL2RyaXZlcnMvbmV0L3N1bmdlbS5oCTIwMDQt MDktMTUgMDg6Mzc6NTIgKzAyOjAwCisrKyBiL2RyaXZlcnMvbmV0L3N1bmdlbS5oCTIwMDQtMDkt MTUgMDg6Mzc6NTIgKzAyOjAwCkBAIC05NTMsNiArOTUzLDcgQEAKIAogc3RydWN0IGdlbSB7CiAJ c3BpbmxvY2tfdCBsb2NrOworCXNwaW5sb2NrX3QgdHhfbG9jazsKIAl1bnNpZ25lZCBsb25nIHJl Z3M7CiAJaW50IHJ4X25ldywgcnhfb2xkOwogCWludCB0eF9uZXcsIHR4X29sZDsK ------=_Part_82_3987604.1095230619574-- From eric.lemoine@gmail.com Tue Sep 14 23:45:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 14 Sep 2004 23:45:36 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F6jV7x029242 for ; Tue, 14 Sep 2004 23:45:32 -0700 Received: by mproxy.gmail.com with SMTP id 79so122694rnk for ; Tue, 14 Sep 2004 23:45:21 -0700 (PDT) Received: by 10.38.74.77 with SMTP id w77mr330152rna; Tue, 14 Sep 2004 23:45:21 -0700 (PDT) Received: by 10.38.99.58 with HTTP; Tue, 14 Sep 2004 23:45:21 -0700 (PDT) Message-ID: <5cac192f04091423453ae3cb@mail.gmail.com> Date: Wed, 15 Sep 2004 08:45:21 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: "David S. Miller" Subject: [SUNGEM] LLTX support Cc: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_83_7502405.1095230721613" X-archive-position: 8838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 2926 Lines: 51 ------=_Part_83_7502405.1095230721613 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline The attached patch adds LLTX support to SunGEM NAPI. The tx_lock patch I just sent must be applied first. Thanks, -- Eric ------=_Part_83_7502405.1095230721613 Content-Type: application/octet-stream; name="patch-rset-sungem_lltx-2-6-9-rc1" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-rset-sungem_lltx-2-6-9-rc1" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMTUgMDg6MzI6MjUrMDI6MDAgZXJpYy5sZW1vaW5lQGdt YWlsLmNvbSAKIyAgIFtTVU5HRU1dOiBhZGQgTExUWCBzdXBwb3J0IHRvIFN1bkdFTQojICAgCiMg ICBTaWduZWQtb2ZmLWJ5OiBFcmljIExlbW9pbmUgPGVyaWMubGVtb2luZUBnbWFpbC5jb20+CiMg CiMgZHJpdmVycy9uZXQvc3VuZ2VtLmMKIyAgIDIwMDQvMDkvMTUgMDg6MzI6MTcrMDI6MDAgZXJp Yy5sZW1vaW5lQGdtYWlsLmNvbSArMTAgLTQKIyAgIFtTVU5HRU1dOiBhZGQgTExUWCBzdXBwb3J0 IHRvIFN1bkdFTQojICAgCiMgICBTaWduZWQtb2ZmLWJ5OiBFcmljIExlbW9pbmUgPGVyaWMubGVt b2luZUBnbWFpbC5jb20+CiMgCmRpZmYgLU5ydSBhL2RyaXZlcnMvbmV0L3N1bmdlbS5jIGIvZHJp dmVycy9uZXQvc3VuZ2VtLmMKLS0tIGEvZHJpdmVycy9uZXQvc3VuZ2VtLmMJMjAwNC0wOS0xNSAw ODozODoyMCArMDI6MDAKKysrIGIvZHJpdmVycy9uZXQvc3VuZ2VtLmMJMjAwNC0wOS0xNSAwODoz ODoyMCArMDI6MDAKQEAgLTk0Miw2ICs5NDIsNyBAQAogCXN0cnVjdCBnZW0gKmdwID0gZGV2LT5w cml2OwogCWludCBlbnRyeTsKIAl1NjQgY3RybDsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOwogCiAJ Y3RybCA9IDA7CiAJaWYgKHNrYi0+aXBfc3VtbWVkID09IENIRUNLU1VNX0hXKSB7CkBAIC05NTUs MTIgKzk1NiwxNyBAQAogCQkJKGNzdW1fc3R1ZmZfb2ZmIDw8IDIxKSk7CiAJfQogCi0Jc3Bpbl9s b2NrX2lycSgmZ3AtPnR4X2xvY2spOworCWxvY2FsX2lycV9zYXZlKGZsYWdzKTsKKwlpZiAoIXNw aW5fdHJ5bG9jaygmZ3AtPnR4X2xvY2spKSB7CisJCS8qIFRlbGwgdXBwZXIgbGF5ZXIgdG8gcmVx dWV1ZSAqLworCQlsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CisJCXJldHVybiAtMTsKKwl9CiAK IAkvKiBUaGlzIGlzIGEgaGFyZCBlcnJvciwgbG9nIGl0LiAqLwogCWlmIChUWF9CVUZGU19BVkFJ TChncCkgPD0gKHNrYl9zaGluZm8oc2tiKS0+bnJfZnJhZ3MgKyAxKSkgewogCQluZXRpZl9zdG9w X3F1ZXVlKGRldik7Ci0JCXNwaW5fdW5sb2NrX2lycSgmZ3AtPnR4X2xvY2spOworCQlzcGluX3Vu bG9ja19pcnFyZXN0b3JlKCZncC0+dHhfbG9jaywgZmxhZ3MpOwogCQlwcmludGsoS0VSTl9FUlIg UEZYICIlczogQlVHISBUeCBSaW5nIGZ1bGwgd2hlbiBxdWV1ZSBhd2FrZSFcbiIsCiAJCSAgICAg ICBkZXYtPm5hbWUpOwogCQlyZXR1cm4gMTsKQEAgLTEwNDcsNyArMTA1Myw3IEBACiAJCSAgICAg ICBkZXYtPm5hbWUsIGVudHJ5LCBza2ItPmxlbik7CiAJbWIoKTsKIAl3cml0ZWwoZ3AtPnR4X25l dywgZ3AtPnJlZ3MgKyBUWERNQV9LSUNLKTsKLQlzcGluX3VubG9ja19pcnEoJmdwLT50eF9sb2Nr KTsKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZncC0+dHhfbG9jaywgZmxhZ3MpOwogCiAJZGV2 LT50cmFuc19zdGFydCA9IGppZmZpZXM7CiAKQEAgLTI5NjAsNyArMjk2Niw3IEBACiAJcGNpX3Nl dF9kcnZkYXRhKHBkZXYsIGRldik7CiAKIAkvKiBHRU0gY2FuIGRvIGl0IGFsbC4uLiAqLwotCWRl di0+ZmVhdHVyZXMgfD0gTkVUSUZfRl9TRyB8IE5FVElGX0ZfSFdfQ1NVTTsKKwlkZXYtPmZlYXR1 cmVzIHw9IE5FVElGX0ZfU0cgfCBORVRJRl9GX0hXX0NTVU0gfCBORVRJRl9GX0xMVFg7CiAJaWYg KHBjaV91c2luZ19kYWMpCiAJCWRldi0+ZmVhdHVyZXMgfD0gTkVUSUZfRl9ISUdIRE1BOwogCg== ------=_Part_83_7502405.1095230721613-- From linux_lover2004@yahoo.com Wed Sep 15 00:54:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 00:54:16 -0700 (PDT) Received: from web52204.mail.yahoo.com (web52204.mail.yahoo.com [206.190.39.86]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8F7sBtj002207 for ; Wed, 15 Sep 2004 00:54:11 -0700 Message-ID: <20040915075356.49586.qmail@web52204.mail.yahoo.com> Received: from [66.218.69.220] by web52204.mail.yahoo.com via HTTP; Wed, 15 Sep 2004 00:53:56 PDT Date: Wed, 15 Sep 2004 00:53:56 -0700 (PDT) From: linux lover Subject: What is max size return by alloc_skb? To: netdev@oss.sgi.com Cc: linux-net@vger.linux.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 339 Lines: 15 Hello, i want to know what is the maximum size alloc_skb can return? I found it returns most of the time 128 bytes, does that mean on ethernet interface max size of transmitted packet is 128? regards, linux_lover _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From linux_lover2004@yahoo.com Wed Sep 15 00:56:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 00:56:16 -0700 (PDT) Received: from web52202.mail.yahoo.com (web52202.mail.yahoo.com [206.190.39.84]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8F7uAJv002452 for ; Wed, 15 Sep 2004 00:56:11 -0700 Message-ID: <20040915075555.97673.qmail@web52202.mail.yahoo.com> Received: from [66.218.69.219] by web52202.mail.yahoo.com via HTTP; Wed, 15 Sep 2004 00:55:55 PDT Date: Wed, 15 Sep 2004 00:55:55 -0700 (PDT) From: linux lover Subject: What is max size return by alloc_skb? To: netdev@oss.sgi.com Cc: linux-net@vger.linux.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linux_lover2004@yahoo.com Precedence: bulk X-list: netdev Content-Length: 361 Lines: 16 Hello, i want to know what is the maximum size alloc_skb can return? I found it returns most of the time 128 bytes, does that mean on ethernet interface max size of transmitted packet is 128? regards, linux_lover __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From laforge@netfilter.org Wed Sep 15 01:15:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 01:15:06 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F8Ex9O003439 for ; Wed, 15 Sep 2004 01:15:00 -0700 Received: from dsl-213-023-154-201.arcor-ip.net ([213.23.154.201] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7UwA-000797-9i; Wed, 15 Sep 2004 10:14:46 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7Uw3-0007a0-Lk; Wed, 15 Sep 2004 10:14:39 +0200 Date: Wed, 15 Sep 2004 10:14:39 +0200 From: Harald Welte To: Linux NICS Cc: netdev@oss.sgi.com Subject: TX performance of Intel 82546 Message-ID: <20040915081439.GA27038@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 14122 Lines: 495 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I'm currently trying to help Robert Olsson improving the performance of the Linux in-kernel packet generator (pktgen.c). At the moment, we seem to be unable to get more than 760kpps from a single port of a 82546, (or any other PCI-X MAC supported by e1000) - that's a bit more than 51% wirespeed at 64byte packet sizes. I tried to find out whether this is a software (i.e. linux network stack, pktgen) problem, or if it is a hardware or driver problem. To do this, I hardwired some code into the e1000 driver, that automatically refills the Tx Queue with the same packet over and over again (see ugly hack attached to this email). When running in this hardwired mode, I do not get any E1000_ICR_TXQE events - so apparently the TX Queue never gets empty, and the 82546 is transferring packets as fast as possible from host memory. However, I still don't get more than 760kpps from a single port. Do you have any further recommendations comments? Is this 760kpps really a hardware limitation? Is it limited by the 82546, the PCI-X latency/bandwidth or memory latency/bandwith? Did Intel ever achieve higher tx pps rates with the 82546 MAC? If yes, on which hardware and OS ? Thanks for your help. Hardware: MSI K8D Master-F, Dual Opteron 1.4GHz, 1GB RAM, PC-2700 (DDR-333), all on C= PU1 0000:02:03.0 Ethernet controller: Intel Corp. 82546GB Gigabit Ethernet Cont= roller (rev 03) Subsystem: Intel Corp. PRO/1000 MT Dual Port Network Connection Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 24 Memory at fc9c0000 (64-bit, non-prefetchable) [size=3D128K] Memory at fc900000 (64-bit, non-prefetchable) [size=3D256K] I/O ports at a880 [size=3D64] Expansion ROM at fc8c0000 [disabled] [size=3D256K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] Capabilities: [f0] Message Signalled Interr= upts: 64bit+ Queue=3D0/0 Enable- Software linux-2.6.8.1 - modified e1000 to keep re-filling 2048 tx descriptors with same skb - board does not generate any 'tx queue empty' interrupts - thus, TX is running at full PC/HT/memory speed TxDescriptors=3D2048,2048 FlowControl=3D0,0 Speed=3D1000,1000 TxIntDelay=3D= 0,0 TxAbsIntDelay=3D0,0 InterruptThottleRate=3D0,0 No more than 763kpps possible :( tried (no improvement): - IntDelay, AbsIntDelay, dynamic ThrottleRate - enabling NAPI (disables TX interrupt) -> tx queue runs empty - smp_affinity to other cpu (not sure which has local ram) -> only 714kpps - increase skb to 128byte - 746kpps --- diff -Nru linux-2.6.8.1/drivers/net/e1000/e1000.h linux-2.6.8.1-test/driver= s/net/e1000/e1000.h --- linux-2.6.8.1/drivers/net/e1000/e1000.h 2004-08-14 10:54:47.000000000 += 0000 +++ linux-2.6.8.1-test/drivers/net/e1000/e1000.h 2004-09-13 16:37:12.000000= 000 +0000 @@ -202,6 +202,7 @@ spinlock_t stats_lock; atomic_t irq_sem; struct work_struct tx_timeout_task; + struct work_struct tx_pktgen_task; uint8_t fc_autoneg; =20 struct timer_list blink_timer; diff -Nru linux-2.6.8.1/drivers/net/e1000/e1000_main.c linux-2.6.8.1-test/d= rivers/net/e1000/e1000_main.c --- linux-2.6.8.1/drivers/net/e1000/e1000_main.c 2004-08-14 10:55:10.000000= 000 +0000 +++ linux-2.6.8.1-test/drivers/net/e1000/e1000_main.c 2004-09-13 21:19:13.9= 96635320 +0000 @@ -111,6 +111,9 @@ void e1000_update_stats(struct e1000_adapter *adapter); =20 /* Local Function Prototypes */ +static struct sk_buff *test_dummy_skb(unsigned int size); +static void test_refill_tx_queue(struct e1000_adapter *adapter); +static void test_tx_pktgen_task(struct net_device *netdev); =20 static int e1000_init_module(void); static void e1000_exit_module(void); @@ -273,6 +276,9 @@ mod_timer(&adapter->watchdog_timer, jiffies); e1000_irq_enable(adapter); =20 + test_dummy_skb(60); + test_refill_tx_queue(adapter); + return 0; } =20 @@ -281,6 +287,8 @@ { struct net_device *netdev =3D adapter->netdev; =20 + printk("%s: entering\n", __FUNCTION__); + e1000_irq_disable(adapter); free_irq(adapter->pdev->irq, netdev); del_timer_sync(&adapter->tx_fifo_stall_timer); @@ -533,6 +541,9 @@ INIT_WORK(&adapter->tx_timeout_task, (void (*)(void *))e1000_tx_timeout_task, netdev); =20 + INIT_WORK(&adapter->tx_pktgen_task, + (void (*)(void *))test_tx_pktgen_task, netdev); + /* we're going to reset, so assume we have no link for now */ =20 netif_carrier_off(netdev); @@ -765,6 +776,7 @@ { struct e1000_adapter *adapter =3D netdev->priv; =20 + printk("%s: entering\n", __FUNCTION__); e1000_down(adapter); =20 e1000_free_tx_resources(adapter); @@ -1070,13 +1082,15 @@ =20 for(i =3D 0; i < tx_ring->count; i++) { buffer_info =3D &tx_ring->buffer_info[i]; - if(buffer_info->skb) { - + if(buffer_info->dma) { pci_unmap_page(pdev, buffer_info->dma, buffer_info->length, PCI_DMA_TODEVICE); + buffer_info->dma =3D 0; + } =20 + if(buffer_info->skb) { dev_kfree_skb(buffer_info->skb); =20 buffer_info->skb =3D NULL; @@ -1434,6 +1448,7 @@ * but we've got queued Tx work that's never going * to get done, so reset controller to flush Tx. * (Do the reset outside of interrupt context). */ + printk("%s: scheduling timeout\n", __FUNCTION__); schedule_work(&adapter->tx_timeout_task); } } @@ -1555,6 +1570,7 @@ #define E1000_MAX_TXD_PWR 12 #define E1000_MAX_DATA_PER_TXD (1<trans_start =3D jiffies; + return 0; +#endif + #ifdef NETIF_F_TSO mss =3D skb_shinfo(skb)->tso_size; /* The controller does a simple calculation to=20 @@ -1791,6 +1814,8 @@ if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2 ) { netif_stop_queue(netdev); spin_unlock_irqrestore(&adapter->tx_lock, flags); + if (net_ratelimit()) + printk(KERN_DEBUG "err: no unused descriptors\n"); return 1; } spin_unlock_irqrestore(&adapter->tx_lock, flags); @@ -1834,6 +1859,7 @@ { struct e1000_adapter *adapter =3D netdev->priv; =20 + printk("%s: entering\n", __FUNCTION__); /* Do the reset outside of interrupt context */ schedule_work(&adapter->tx_timeout_task); } @@ -1843,6 +1869,7 @@ { struct e1000_adapter *adapter =3D netdev->priv; =20 + printk("%s: entering\n", __FUNCTION__); netif_device_detach(netdev); e1000_down(adapter); e1000_up(adapter); @@ -2078,6 +2105,8 @@ { if(atomic_dec_and_test(&adapter->irq_sem)) { E1000_WRITE_REG(&adapter->hw, IMS, IMS_ENABLE_MASK); + /* disable RX interrupt generation */ + //E1000_WRITE_REG(&adapter->hw, IMS, IMS_ENABLE_MASK & ~E1000_IMS_RXDMT0= ); E1000_WRITE_FLUSH(&adapter->hw); } } @@ -2103,11 +2132,27 @@ if(!icr) return IRQ_NONE; /* Not our interrupt */ =20 +#if 0 + printk("e1000_intr: icr=3D0x%08x\n", icr); + printk("%s: tdh=3D%d, tdt=3D%d\n", __FUNCTION__, + E1000_READ_REG(&adapter->hw, TDH), + E1000_READ_REG(&adapter->hw, TDT)); +#endif + if(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { hw->get_link_status =3D 1; mod_timer(&adapter->watchdog_timer, jiffies); } =20 + if (icr & E1000_ICR_TXQE) { + printk("TX queue empty: shouldn't happen!\n"); + } + + if (icr & E1000_ICR_TXDW) { + e1000_clean_tx_irq(adapter); + schedule_work(&adapter->tx_pktgen_task); + } + #ifdef CONFIG_E1000_NAPI if(netif_rx_schedule_prep(netdev)) { =20 @@ -2116,7 +2161,7 @@ */ =20 atomic_inc(&adapter->irq_sem); - E1000_WRITE_REG(hw, IMC, ~0); +// E1000_WRITE_REG(hw, IMC, ~0); __netif_rx_schedule(netdev); } #else @@ -2142,6 +2187,7 @@ int work_to_do =3D min(*budget, netdev->quota); int work_done =3D 0; =09 + //printk("%s entered\n", __FUNCTION__); e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); =20 @@ -2175,6 +2221,7 @@ boolean_t cleaned =3D FALSE; =20 =20 + //printk("%s entered\n", __FUNCTION__); i =3D tx_ring->next_to_clean; eop =3D tx_ring->buffer_info[i].next_to_watch; eop_desc =3D E1000_TX_DESC(*tx_ring, eop); @@ -2184,6 +2231,7 @@ for(cleaned =3D FALSE; !cleaned; ) { tx_desc =3D E1000_TX_DESC(*tx_ring, i); buffer_info =3D &tx_ring->buffer_info[i]; + //printk("cleaning tx_desc %d\n", i); =20 if(buffer_info->dma) { =20 @@ -2802,6 +2850,7 @@ uint32_t ctrl, ctrl_ext, rctl, manc, status; uint32_t wufc =3D adapter->wol; =20 + printk("%s: entering\n", __FUNCTION__); netif_device_detach(netdev); =20 if(netif_running(netdev)) @@ -2920,4 +2969,169 @@ } #endif =20 + +#include +#include +static struct sk_buff *test_skb; + +static struct sk_buff * +test_dummy_skb(unsigned int pkt_size) +{ + int datalen; + struct sk_buff *skb; + __u8 *eth; + struct iphdr *iph; + struct udphdr *udph; +=09 + skb =3D alloc_skb(pkt_size + 64 + 16, GFP_ATOMIC); + + if (!skb) + return NULL; + + /* increase reference count so noone can free it */ + skb_get(skb); + + skb_reserve(skb, 16); + eth =3D (__u8 *) skb_push(skb, 14); + iph =3D (struct iphdr *)skb_put(skb, sizeof(struct iphdr)); + udph =3D (struct udphdr *)skb_put(skb, sizeof(struct udphdr)); + memset(eth, 1, 6); // dst + memset(eth+6, 2, 6); // src + memset(eth+12, 0x08, 1); + memset(eth+13, 0x00, 1); + + datalen =3D pkt_size - 14 - 20 - 8; + + udph->source =3D htons(9); + udph->dest =3D htons(9); + udph->len =3D htons(datalen + 8); + udph->check =3D 0; + + iph->ihl =3D 5; + iph->version =3D 4; + iph->ttl =3D 3; + iph->tos =3D 0; + iph->protocol =3D IPPROTO_UDP; + iph->saddr =3D htonl(0x01010101); + iph->daddr =3D htonl(0x02020202); + iph->frag_off =3D 0; + iph->tot_len =3D htons(20+8+datalen); + iph->check =3D 0; + iph->check =3D ip_fast_csum((void *) iph, iph->ihl); + skb->protocol =3D __constant_htons(ETH_P_IP); + skb->mac.raw =3D ((u8 *)iph) - 14; + skb->pkt_type =3D PACKET_HOST; + + test_skb =3D skb; + + return skb; +} + +static inline void +test_tx_queue(struct e1000_adapter *adapter, int count, int tx_flags) +{ + struct e1000_desc_ring *tx_ring =3D &adapter->tx_ring; + struct e1000_tx_desc *tx_desc =3D NULL; + struct e1000_buffer *buffer_info; + uint32_t txd_upper =3D 0, txd_lower =3D E1000_TXD_CMD_IFCS; + unsigned int i; + + if(tx_flags & E1000_TX_FLAGS_TSO) { + txd_lower |=3D E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D | + E1000_TXD_CMD_TSE; + txd_upper |=3D (E1000_TXD_POPTS_IXSM | E1000_TXD_POPTS_TXSM) << 8; + } + + if(tx_flags & E1000_TX_FLAGS_CSUM) { + txd_lower |=3D E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D; + txd_upper |=3D E1000_TXD_POPTS_TXSM << 8; + } + + if(tx_flags & E1000_TX_FLAGS_VLAN) { + txd_lower |=3D E1000_TXD_CMD_VLE; + txd_upper |=3D (tx_flags & E1000_TX_FLAGS_VLAN_MASK); + } + + i =3D tx_ring->next_to_use; + + while(count--) { + buffer_info =3D &tx_ring->buffer_info[i]; + tx_desc =3D E1000_TX_DESC(*tx_ring, i); + tx_desc->buffer_addr =3D cpu_to_le64(buffer_info->dma); + tx_desc->lower.data =3D + cpu_to_le32(txd_lower | buffer_info->length); + tx_desc->upper.data =3D cpu_to_le32(txd_upper); + if(++i =3D=3D tx_ring->count) i =3D 0; + } + + tx_desc->lower.data |=3D cpu_to_le32(adapter->txd_cmd); + + /* Force memory writes to complete before letting h/w + * know there are new descriptors to fetch. (Only + * applicable for weak-ordered memory model archs, + * such as IA-64). */ + wmb(); + + tx_ring->next_to_use =3D i; +} + +static void +test_refill_tx_queue(struct e1000_adapter *adapter) +{ + int i, num; + unsigned long flags; + int reserve =3D 2 + 10;=20 +=09 + spin_lock_irqsave(&adapter->tx_lock, flags); + num =3D E1000_DESC_UNUSED(&adapter->tx_ring); + + if (num <=3D reserve) { + printk("too little unused descriptors to refill\n"); + spin_unlock_irqrestore(&adapter->tx_lock, flags); + return; + } + + //printk("%s: refilling %d descriptors\n", __FUNCTION__, num - reserve); + + i =3D 0; + while (1) { + int ret, skb_idx; + if (i >=3D num-reserve) + break; + + // printk("e1000_tx_map(%d)\n", adapter->tx_ring.next_to_use); + ret =3D e1000_tx_map(adapter, test_skb,=20 + adapter->tx_ring.next_to_use, + E1000_MAX_DATA_PER_TXD, + skb_shinfo(test_skb)->nr_frags, + skb_shinfo(test_skb)->tso_size); + skb_idx =3D adapter->tx_ring.buffer_info[adapter->tx_ring.next_to_use].n= ext_to_watch; + adapter->tx_ring.buffer_info[skb_idx].skb =3D NULL; + test_tx_queue(adapter, ret, 0); + i +=3D ret; + } + +#if 0 + printk("%s: tdh=3D%d, tdt=3D%d\n", __FUNCTION__, + E1000_READ_REG(&adapter->hw, TDH), + E1000_READ_REG(&adapter->hw, TDT)); +#endif + E1000_WRITE_REG(&adapter->hw, TDT, adapter->tx_ring.next_to_use); +#if 0 + printk("%s: tdh=3D%d, tdt=3D%d\n", __FUNCTION__, + E1000_READ_REG(&adapter->hw, TDH), + E1000_READ_REG(&adapter->hw, TDT)); +#endif + + spin_unlock_irqrestore(&adapter->tx_lock, flags); +} + +static void +test_tx_pktgen_task(struct net_device *netdev) +{ + struct e1000_adapter *adapter =3D netdev->priv; + test_refill_tx_queue(adapter); +} + + /* e1000_main.c */ --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD4DBQFBR/nvXaXGVTD0i/8RAgjbAJ4nVm5MMxyodnDdim9iijF0wZl6HACXYaog 5iztEF+7SEhhKM7PPdNgtA== =ae8b -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From P@draigBrady.com Wed Sep 15 02:19:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 02:19:22 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8F9JFLk005360 for ; Wed, 15 Sep 2004 02:19:16 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id i8F9IhwS012064; Wed, 15 Sep 2004 10:18:44 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <414808F3.70104@draigBrady.com> Date: Wed, 15 Sep 2004 10:18:43 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Welte CC: Linux NICS , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> In-Reply-To: <20040915081439.GA27038@sunbeam.de.gnumonks.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 8842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Content-Length: 1022 Lines: 25 Harald Welte wrote: > Hi! > > I'm currently trying to help Robert Olsson improving the performance of > the Linux in-kernel packet generator (pktgen.c). At the moment, we seem > to be unable to get more than 760kpps from a single port of a 82546, > (or any other PCI-X MAC supported by e1000) - that's a bit more than 51% > wirespeed at 64byte packet sizes. In my experience anything around 750Kpps is a PCI limitation, specifically PCI bus arbitration latency. Note the clock speed of the control signal used for bus arbitration has not increased in proportion to the PCI data clock speed. The application note #453 referenced below is very imformative: http://www.intel.com/design/network/products/lan/docs/82546_docs.htm I was able to confirm the above by passing 4x730Kpps through a PCI-X system with 4 ethernet controllers, but never more than 760Kpps through one particular controller. Note also you may be able to tune for transmission using setpci (google for setpci & MMRBC), or hacking with TSO? Pádraig. From hadi@cyberus.ca Wed Sep 15 05:18:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 05:18:54 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FCIkgq015164 for ; Wed, 15 Sep 2004 05:18:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C7Yk6-0005sG-1i for netdev@oss.sgi.com; Wed, 15 Sep 2004 08:18:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7Yk1-00044z-59; Wed, 15 Sep 2004 08:18:29 -0400 Subject: Re: TX performance of Intel 82546 From: jamal Reply-To: hadi@cyberus.ca To: P@draigBrady.com Cc: Harald Welte , Linux NICS , netdev@oss.sgi.com In-Reply-To: <414808F3.70104@draigBrady.com> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> Content-Type: multipart/mixed; boundary="=-LvwXueET1uGxmrAzo7XZ" Organization: jamalopolous Message-Id: <1095250706.1057.214.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Sep 2004 08:18:27 -0400 X-archive-position: 8843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 6128 Lines: 220 --=-LvwXueET1uGxmrAzo7XZ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2004-09-15 at 05:18, P@draigBrady.com wrote: > I was able to confirm the above by passing 4x730Kpps > through a PCI-X system with 4 ethernet controllers, > but never more than 760Kpps through one particular controller. > > Note also you may be able to tune for transmission > using setpci (google for setpci & MMRBC), or hacking with TSO? Our friends in FreeBSD claim they can do 1Mpps _forwarding_ with e1000 - forget about transmit only ;-> I have been experimenting after SUCON on and off because i found the BSD folks batch their transmits. They have a very dumb egress with no QoS. Results are not conclusive yet. I will post at some point. Harald try to move the wmb() just before you write the TDT as i do in kick_DMA in rearranged e1000 patch attached. I will move things around if you show worse results. BTW, anyone wanting to experiment on this patch talk to me privately. I need to clean it up - maybe this weekend. cheers, jamal --=-LvwXueET1uGxmrAzo7XZ Content-Disposition: attachment; filename=e1000p Content-Type: text/plain; name=e1000p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 269-rc1-bk10/drivers/net/e1000/e1000_main.c 2004/09/12 17:05:58 1.1 +++ 269-rc1-bk10/drivers/net/e1000/e1000_main.c 2004/09/15 12:13:24 @@ -125,6 +125,7 @@ static void e1000_watchdog(unsigned long data); static void e1000_82547_tx_fifo_stall(unsigned long data); static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev); +static int e1000_xmit_frames(struct sk_buff_head *list, struct net_device *netdev); static struct net_device_stats * e1000_get_stats(struct net_device *netdev); static int e1000_change_mtu(struct net_device *netdev, int new_mtu); static int e1000_set_mac(struct net_device *netdev, void *p); @@ -448,6 +449,7 @@ netdev->open = &e1000_open; netdev->stop = &e1000_close; netdev->hard_start_xmit = &e1000_xmit_frame; + netdev->hard_batch_xmit = &e1000_xmit_frames; netdev->get_stats = &e1000_get_stats; netdev->set_multicast_list = &e1000_set_multi; netdev->set_mac_address = &e1000_set_mac; @@ -1673,6 +1675,14 @@ } static inline void +e1000_kick_DMA(struct e1000_adapter *adapter, int i) +{ + wmb(); + + E1000_WRITE_REG(&adapter->hw, TDT, i); +} + +static inline void e1000_tx_queue(struct e1000_adapter *adapter, int count, int tx_flags) { struct e1000_desc_ring *tx_ring = &adapter->tx_ring; @@ -1711,14 +1721,16 @@ tx_desc->lower.data |= cpu_to_le32(adapter->txd_cmd); +#if 0 /* Force memory writes to complete before letting h/w * know there are new descriptors to fetch. (Only * applicable for weak-ordered memory model archs, * such as IA-64). */ wmb(); - tx_ring->next_to_use = i; E1000_WRITE_REG(&adapter->hw, TDT, i); +#endif + tx_ring->next_to_use = i; } /** @@ -1760,15 +1772,15 @@ } #define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 ) -static int -e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) +#define NETDEV_TX_DROPPED 3 +static inline int +e1000_queue_frame(struct sk_buff *skb, struct net_device *netdev) { struct e1000_adapter *adapter = netdev->priv; unsigned int first, max_per_txd = E1000_MAX_DATA_PER_TXD; unsigned int max_txd_pwr = E1000_MAX_TXD_PWR; unsigned int tx_flags = 0; unsigned int len = skb->len; - unsigned long flags; unsigned int nr_frags = 0; unsigned int mss = 0; int count = 0; @@ -1778,7 +1790,7 @@ if(unlikely(skb->len <= 0)) { dev_kfree_skb_any(skb); - return 0; + return NETDEV_TX_DROPPED; } #ifdef NETIF_F_TSO @@ -1813,27 +1825,19 @@ if(adapter->pcix_82544) count += nr_frags; - local_irq_save(flags); - if (!spin_trylock(&adapter->tx_lock)) { - /* Collision - tell upper layer to requeue */ - local_irq_restore(flags); - return -1; - } /* need: count + 2 desc gap to keep tail from touching * head, otherwise try next time */ if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { netif_stop_queue(netdev); - spin_unlock_irqrestore(&adapter->tx_lock, flags); - return 1; + return NETDEV_TX_BUSY; } if(unlikely(adapter->hw.mac_type == e1000_82547)) { if(unlikely(e1000_82547_fifo_workaround(adapter, skb))) { netif_stop_queue(netdev); mod_timer(&adapter->tx_fifo_stall_timer, jiffies); - spin_unlock_irqrestore(&adapter->tx_lock, flags); - return 1; + return NETDEV_TX_BUSY; } } @@ -1855,8 +1859,69 @@ netdev->trans_start = jiffies; + return NETDEV_TX_OK; +} + +static int +e1000_xmit_frames(struct sk_buff_head *list, struct net_device *netdev) +{ + struct e1000_adapter *adapter = netdev->priv; + int ret = NETDEV_TX_OK; + int didq = 0; + int inbatch = skb_queue_len(list); + struct sk_buff *skb = NULL; + unsigned long flags; + + local_irq_save(flags); + if (!spin_trylock(&adapter->tx_lock)) { + /* Collision - tell upper layer to requeue */ + local_irq_restore(flags); + return NETDEV_TX_LOCKED; + } + + while ((skb = __skb_dequeue(list)) != NULL) { + ret = e1000_queue_frame(skb, netdev); + if (ret == NETDEV_TX_OK) { + didq++; + } else { + if (ret == NETDEV_TX_BUSY) + break; + } + } + + if (didq) + e1000_kick_DMA(adapter, adapter->tx_ring.next_to_use); + if (skb_queue_len(list) && (inbatch > skb_queue_len(list))) + ret = NETDEV_TX_BUSY; + else + ret = NETDEV_TX_OK; spin_unlock_irqrestore(&adapter->tx_lock, flags); - return 0; + return ret; +} + +static int +e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev) +{ + struct e1000_adapter *adapter = netdev->priv; + int ret = NETDEV_TX_OK; + unsigned long flags; + + local_irq_save(flags); + if (!spin_trylock(&adapter->tx_lock)) { + /* Collision - tell upper layer to requeue */ + local_irq_restore(flags); + return NETDEV_TX_LOCKED; + } + + ret = e1000_queue_frame(skb, netdev); + if (ret == NETDEV_TX_OK) { + e1000_kick_DMA(adapter, adapter->tx_ring.next_to_use); + } + + spin_unlock_irqrestore(&adapter->tx_lock, flags); + if (ret == NETDEV_TX_DROPPED) + ret = NETDEV_TX_OK; + return ret; } /** --=-LvwXueET1uGxmrAzo7XZ-- From Robert.Olsson@data.slu.se Wed Sep 15 05:36:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 05:36:58 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FCaoxM015709 for ; Wed, 15 Sep 2004 05:36:51 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8FCaP9Y009558; Wed, 15 Sep 2004 14:36:25 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id AFB4D90265; Wed, 15 Sep 2004 14:36:25 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16712.14153.683690.710955@robur.slu.se> Date: Wed, 15 Sep 2004 14:36:25 +0200 To: P@draigBrady.com Cc: Harald Welte , Linux NICS , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 In-Reply-To: <414808F3.70104@draigBrady.com> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 8844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1251 Lines: 36 P@draigBrady.com writes: > Harald Welte wrote: > > I'm currently trying to help Robert Olsson improving the performance of > > the Linux in-kernel packet generator (pktgen.c). At the moment, we seem > > to be unable to get more than 760kpps from a single port of a 82546, > > (or any other PCI-X MAC supported by e1000) - that's a bit more than 51% > > wirespeed at 64byte packet sizes. Yes it seems intel adapters work better in BSD as they claim to route 1 Mpps and we cannot even send more ~750 kpps even with feeding the adapter only. :-) > In my experience anything around 750Kpps is a PCI limitation, > specifically PCI bus arbitration latency. Note the clock speed of > the control signal used for bus arbitration has not increased > in proportion to the PCI data clock speed. Yes data from an Opteron @ 1.6 GHz w. e1000 82546EB 64 byte pkts. 133 MHz 830 pps 100 MHz 721 pps 66 MHz 561 pps So higher bus bandwidth could increase the small packet rate. So is there a difference in PCI-tuning BSD versus Linux? And even more general can we measure the maximum numbers of transactions on a PCI-bus? Chip should be able to transfer 64 packets in single burst I don't now how set/verify this. Cheers. --ro From hadi@cyberus.ca Wed Sep 15 06:50:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 06:50:35 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FDoSY9017748 for ; Wed, 15 Sep 2004 06:50:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C7aAp-0003QR-Fx for netdev@oss.sgi.com; Wed, 15 Sep 2004 09:50:15 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7aAj-00088D-Kc; Wed, 15 Sep 2004 09:50:09 -0400 Subject: Re: TX performance of Intel 82546 From: jamal Reply-To: hadi@cyberus.ca To: Robert Olsson Cc: P@draigBrady.com, Harald Welte , Linux NICS , netdev@oss.sgi.com In-Reply-To: <16712.14153.683690.710955@robur.slu.se> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1 Organization: jamalopolous Message-Id: <1095256191.1043.17.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Sep 2004 09:49:51 -0400 Content-Transfer-Encoding: 8bit X-archive-position: 8845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1327 Lines: 42 On Wed, 2004-09-15 at 08:36, Robert Olsson wrote: > > In my experience anything around 750Kpps is a PCI limitation, > > specifically PCI bus arbitration latency. Note the clock speed of > > the control signal used for bus arbitration has not increased > > in proportion to the PCI data clock speed. > > Yes data from an Opteron @ 1.6 GHz w. e1000 82546EB 64 byte pkts. > > 133 MHz 830 pps > 100 MHz 721 pps > 66 MHz 561 pps > > So higher bus bandwidth could increase the small packet rate. Nice data. BTW, is this per interface? i thought i have seen numbers in the range of 1.3Mpps from you. > So is there a difference in PCI-tuning BSD versus Linux? As far as i could tell they batch transmit (mostly because of the way mbufs are structured really). > And even more general can we measure the maximum numbers > of transactions on a PCI-bus? You would need speacilized hardware for this i think. > Chip should be able to transfer 64 packets in single burst I don't now > how set/verify this. What Pádraig.posted in regards to the MMRBC register is actually enlightening. I kept thinking about it after i sent my last email. If indeed the overhead is incured in the setup(all fingers in my test setups point fingers at this) then increasing the burst size should show improvements. cheers, jamal From P@draigBrady.com Wed Sep 15 06:59:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 07:00:01 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FDxsCL018271 for ; Wed, 15 Sep 2004 06:59:55 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id i8FDxUwS088474; Wed, 15 Sep 2004 14:59:31 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <41484AC2.8090408@draigBrady.com> Date: Wed, 15 Sep 2004 14:59:30 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: Harald Welte , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> In-Reply-To: <16712.14153.683690.710955@robur.slu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 8846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Content-Length: 2357 Lines: 68 Robert Olsson wrote: > P@draigBrady.com writes: > > Harald Welte wrote: > > > > I'm currently trying to help Robert Olsson improving the performance of > > > the Linux in-kernel packet generator (pktgen.c). At the moment, we seem > > > to be unable to get more than 760kpps from a single port of a 82546, > > > (or any other PCI-X MAC supported by e1000) - that's a bit more than 51% > > > wirespeed at 64byte packet sizes. > > Yes it seems intel adapters work better in BSD as they claim to route > 1 Mpps and we cannot even send more ~750 kpps even with feeding the > adapter only. :-) > > > In my experience anything around 750Kpps is a PCI limitation, > > specifically PCI bus arbitration latency. Note the clock speed of > > the control signal used for bus arbitration has not increased > > in proportion to the PCI data clock speed. > > Yes data from an Opteron @ 1.6 GHz w. e1000 82546EB 64 byte pkts. > > 133 MHz 830 pps > 100 MHz 721 pps > 66 MHz 561 pps Interesting info thanks! It would be very interesting to see the performance of PCI express which should not have the bus arbitration issues. > So higher bus bandwidth could increase the small packet rate. > > So is there a difference in PCI-tuning BSD versus Linux? > And even more general can we measure the maximum numbers > of transactions on a PCI-bus? > > Chip should be able to transfer 64 packets in single burst I don't now > how set/verify this. Well from the intel docs they say "The devices include a PCI interface that maximizes the use of bursts for efficient bus usage. The controllers are able to cache up to 64 packet descriptors in a single burst for efficient PCI bandwidth usage." So I'm guessing that increasing the PCI-X burst size setting (MMRBC) will automatically get more packets sent per transfer? I said previously in this thread to google for setpci and MMRBC, but what I know about it is... To return the current setting(s): setpci -d 8086:1010 e6.b The MMRBC is the upper two bits of the lower nibble, where: 0 = 512 byte bursts 1 = 1024 byte bursts 2 = 2048 byte bursts 3 = 4096 byte bursts For me to set 4KiB bursts I do: setpci -d 8086:1010 e6.b=0e The following measured a 30% throughput improvement (on 10G) from setting the burst size to 4KiB: https://mgmt.datatag.org/sravot/TCP_WAN_perf_sr061504.pdf Pádraig. From laforge@netfilter.org Wed Sep 15 07:02:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 07:02:46 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FE2ffx018616 for ; Wed, 15 Sep 2004 07:02:41 -0700 Received: from dsl-213-023-154-201.arcor-ip.net ([213.23.154.201] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7aMg-0005eQ-Bh; Wed, 15 Sep 2004 16:02:30 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7aMY-0002Du-Re; Wed, 15 Sep 2004 16:02:23 +0200 Date: Wed, 15 Sep 2004 16:02:22 +0200 From: Harald Welte To: jamal Cc: P@draigBrady.com, Linux NICS , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 Message-ID: <20040915140222.GD1274@sunbeam.de.gnumonks.org> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <1095250706.1057.214.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4zI0WCX1RcnW9Hbu" Content-Disposition: inline In-Reply-To: <1095250706.1057.214.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1250 Lines: 37 --4zI0WCX1RcnW9Hbu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 08:18:27AM -0400, jamal wrote: > Our friends in FreeBSD claim they can do 1Mpps _forwarding_ with=20 > e1000 - forget about transmit only ;-> IMHO that was a 82547, attached to CSA and not PCI-X...=20 --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --4zI0WCX1RcnW9Hbu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBSEtuXaXGVTD0i/8RAjPDAKCntGlbr8zJGDsbWbUwE5IIktVdbQCcDKJw PxvIh2+2qWUzuo7B0/7PGOE= =bJYD -----END PGP SIGNATURE----- --4zI0WCX1RcnW9Hbu-- From fernando@gont.com.ar Wed Sep 15 07:31:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 07:31:49 -0700 (PDT) Received: from libertad.frh.utn.edu.ar (libertad.frh.utn.edu.ar [170.210.17.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FEVdlv019418 for ; Wed, 15 Sep 2004 07:31:41 -0700 Received: from fernando.gont.com.ar ([200.68.210.225]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id MAA17516 for ; Wed, 15 Sep 2004 12:09:25 -0400 Message-Id: <4.3.2.7.2.20040915112853.00cf9980@mail.daleclick.com> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Sep 2004 11:44:14 -0300 To: netdev@oss.sgi.com From: Fernando Gont Subject: TCP's reaction to soft errors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fernando@gont.com.ar Precedence: bulk X-list: netdev Content-Length: 1288 Lines: 32 Folks, I'm the author of an IETF Internet Draft that discusses a problem arising from the current TCP's reaction to soft errors. The problem has to do with long delays in connection establishment attempts that may arise in a number of scenarios. The draft proposes to change TCP's reaction to soft errors so that connections that are in the SYN-SENT or SYN-RECEIVED states are aborted upon receipt of an ICMP error message that indicates a soft error. The draft can be found at: http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-soft-errors-00.txt . I've also put online a "Discussion List" I had prepared for the last IETF meeting, which has a somewhat expanded explanation of the rationale behind the proposed fix. This document can be found at: http://www.gont.com.ar/drafts/TCP-Soft-Errors-Discussion-List.doc . I'd appreciate any comments on the draft. Thus, I'd be able to address your comments in the next revision of the draft, and will also sum-up your feedback and post it to the relevant IETF mailing list (that of the TCPM WG mailing-list). BTW, I've set up a page at http://www.gont.com.ar/drafts/tcp-soft-errors.html so that you have all the documents available from a single place. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From greg@atheros.com Wed Sep 15 07:46:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 07:46:44 -0700 (PDT) Received: from atheros.com (mail.atheros.com [65.212.155.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FEkc0d020050 for ; Wed, 15 Sep 2004 07:46:38 -0700 Received: from [10.10.10.169] (account greg HELO atheros.com) by atheros.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8947497; Wed, 15 Sep 2004 07:46:23 -0700 Message-ID: <41485608.3040509@atheros.com> Date: Wed, 15 Sep 2004 07:47:36 -0700 From: greg chesson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Kondratiev CC: "Luis R. Rodriguez" , acx100-devel@lists.sourceforge.net, "David S. Miller" , hadi@cyberus.ca, Jeff Garzik , "Luis R. Rodriguez" , netdev@oss.sgi.com, prism54-devel@prism54.org, sam@errno.com Subject: Re: generic 802.11 stack References: <4145352F.4040807@pobox.com> <20040915030545.GA25307@havoc.gtf.org> <20040915031732.GL7839@ruslug.rutgers.edu> <200409150844.45242.vkondra@mail.ru> In-Reply-To: <200409150844.45242.vkondra@mail.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@atheros.com Precedence: bulk X-list: netdev Content-Length: 2576 Lines: 58 Vladimir Kondratiev wrote: > Let me answer to the set of questions raised: > > - dual licensing: I am not ready to answer for legal. I will discuss with > proper people and answer. end the end it is your choice. > > - code style: regardless of answer on question above, I intend to do Linux > work and will not care about compatibility macros. I really dislike such > macros, they do make code hard to understand. This is true - and it's not just compatibility macro's that force the reader to find and read the macro before understanding the code. But there is a fine line between macro's that are accepted as standard practice in a kernel, e.g. LIST_INSERT_HEAD, and the same kind of thing that is used in a driver for compatibility across different versions of the Linux kernel or, dog save us, some other unix-like OS. > > - information sharing (driver-stack): good question indeed. I am currently > evaluating it. This far, I think I will supply some standard link layer > information per packet. Like rate, RSSI etc. For Tx, it will include also > crypto key for hardware assisted encryption, type of protection (RTS/CTS > etc.) I believe it should be sufficient. To prove it, I am going to write > some dummy .11 driver that will be capable to simulate any Rx, with user > interface for feeding packets. I will use this driver to debug stack. 2 cents of advice: the rx path is the easier side. the more complex and fun stuff happens on the tx side. > > It is complex issue to support all combination of job separation between host > and NIC, I will choose some model like "NIC do almost nothing" and will > develop around it. very reasonable. > > Vladimir. > > On Wednesday 15 September 2004 06:17, Luis R. Rodriguez wrote: > LR> On Tue, Sep 14, 2004 at 11:05:45PM -0400, Jeff Garzik wrote: > LR> > On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote: > LR> > > I proposed dual licensing not to specifically allow clear > compatibility LR> > > among linux and the BSDs on the 802.11 work, but to > allow BSDers to do LR> > > whatever they want with what we come up with -- > help with code sharing. LR> > > LR> > > LR> > Overall, He Who Writes The Code Gets To Choose. > LR> > > LR> > My own personal opinion is that the BSD license goes against the stated > LR> > spirit of Linux -- contribute back. But that's just me. > LR> > > LR> > LR> Agreed -- but in this case I feel we're the bigger crowd so I wanted to > LR> address to the *author* that I feel we should be considerate to the BSD > LR> crowd. > LR> > LR> Luis > LR > From hadi@cyberus.ca Wed Sep 15 07:46:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 07:46:50 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FEkfEP020051 for ; Wed, 15 Sep 2004 07:46:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C7b3E-0002Xb-4B for netdev@oss.sgi.com; Wed, 15 Sep 2004 10:46:28 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7b3C-0000Rz-Pp; Wed, 15 Sep 2004 10:46:26 -0400 Subject: Re: TX performance of Intel 82546 From: jamal Reply-To: hadi@cyberus.ca To: Harald Welte Cc: Linux NICS , netdev@oss.sgi.com In-Reply-To: <20040915140222.GD1274@sunbeam.de.gnumonks.org> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <1095250706.1057.214.camel@jzny.localdomain> <20040915140222.GD1274@sunbeam.de.gnumonks.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095259574.1032.42.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Sep 2004 10:46:14 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 465 Lines: 15 On Wed, 2004-09-15 at 10:02, Harald Welte wrote: > On Wed, Sep 15, 2004 at 08:18:27AM -0400, jamal wrote: > > > Our friends in FreeBSD claim they can do 1Mpps _forwarding_ with > > e1000 - forget about transmit only ;-> > > IMHO that was a 82547, attached to CSA and not PCI-X... I thought PCI-X should have less overhead in this case (because it has split-transaction capability), no? What do you mean by above statement of it not being PCI-X? cheers, jama From ak@suse.de Wed Sep 15 07:55:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 07:55:33 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FEtRRS020885 for ; Wed, 15 Sep 2004 07:55:28 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 67A87BEB98A; Wed, 15 Sep 2004 16:55:10 +0200 (CEST) Date: Wed, 15 Sep 2004 16:55:03 +0200 From: Andi Kleen To: Harald Welte Cc: jamal , P@draigBrady.com, Linux NICS , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 Message-ID: <20040915145503.GE20509@wotan.suse.de> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <1095250706.1057.214.camel@jzny.localdomain> <20040915140222.GD1274@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915140222.GD1274@sunbeam.de.gnumonks.org> X-archive-position: 8851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 456 Lines: 14 On Wed, Sep 15, 2004 at 04:02:22PM +0200, Harald Welte wrote: > On Wed, Sep 15, 2004 at 08:18:27AM -0400, jamal wrote: > > > Our friends in FreeBSD claim they can do 1Mpps _forwarding_ with > > e1000 - forget about transmit only ;-> > > IMHO that was a 82547, attached to CSA and not PCI-X... Still only one e1000 can be attached to CSA. I didn't think there are any that can do two. And routing only with a single NIC could be difficult... -Andi From Robert.Olsson@data.slu.se Wed Sep 15 08:34:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 08:34:24 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FFYJSd025012 for ; Wed, 15 Sep 2004 08:34:19 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8FFXt9Y016655; Wed, 15 Sep 2004 17:33:55 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 54EDD90265; Wed, 15 Sep 2004 17:33:55 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16712.24803.315813.277140@robur.slu.se> Date: Wed, 15 Sep 2004 17:33:55 +0200 To: hadi@cyberus.ca Cc: Robert Olsson , P@draigBrady.com, Harald Welte , Linux NICS , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 In-Reply-To: <1095256191.1043.17.camel@jzny.localdomain> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> <1095256191.1043.17.camel@jzny.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8FFYJSd025012 X-archive-position: 8852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1506 Lines: 45 jamal writes: > > Yes data from an Opteron @ 1.6 GHz w. e1000 82546EB 64 byte pkts. > > > > 133 MHz 830 pps > > 100 MHz 721 pps > > 66 MHz 561 pps Well the pps should kpps but everybody seem to understand this. > BTW, is this per interface? i thought i have seen numbers in the range > of 1.3Mpps from you. Yes 1.3 Mpps is aggregated forwarding performance from 2 *.1.6 GHz Opterons. In a setup where CPU0 handles eth0->eth1 and CPU1 handles eth2->eth3. So due to the fact that a single NIC's TX does not keep up with packet budget I had to use several "flows" to saturate the packet budget. This is a little breakthrough as we for the first time see some aggregated performance with packet forwarding and got something in return for all multiprocessor efforts. IMO this is much more important then the last percent of performance of pps numbers. But the aggregated performance is only seen with Opterons my conclusion as we discussed is that memory/controller is local to the CPU and gives lower latency and additional CPU adds memory controllers. Compare this to where many CPU's share same controller/memory. > What Pádraig.posted in regards to the MMRBC register is actually > enlightening. I kept thinking about it after i sent my last email. > If indeed the overhead is incured in the setup(all fingers in my test > setups point fingers at this) then increasing the burst size should show > improvements. It's worth to test... Cheers. --ro From davem@davemloft.net Wed Sep 15 08:35:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 08:36:00 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FFZtYI025207 for ; Wed, 15 Sep 2004 08:35:55 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7bmf-0001SD-00; Wed, 15 Sep 2004 08:33:25 -0700 Date: Wed, 15 Sep 2004 08:33:25 -0700 From: "David S. Miller" To: Eric Lemoine Cc: netdev@oss.sgi.com Subject: Re: [SUNGEM] add tx_lock Message-Id: <20040915083325.1c6757ec.davem@davemloft.net> In-Reply-To: <5cac192f040914234361e1b929@mail.gmail.com> References: <5cac192f040914234361e1b929@mail.gmail.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8853 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 242 Lines: 7 On Wed, 15 Sep 2004 08:43:39 +0200 Eric Lemoine wrote: > The attached patch makes SunGEM NAPI driver in conformance to tg3 and > e1000 in terms of locking logic. Applies to current BK:net-2.6. Applied, thanks Eric. From davem@davemloft.net Wed Sep 15 08:38:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 08:38:42 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FFcc05025675 for ; Wed, 15 Sep 2004 08:38:38 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7bp9-0001Sm-00; Wed, 15 Sep 2004 08:35:59 -0700 Date: Wed, 15 Sep 2004 08:35:59 -0700 From: "David S. Miller" To: Eric Lemoine Cc: netdev@oss.sgi.com Subject: Re: [SUNGEM] LLTX support Message-Id: <20040915083559.6c36759f.davem@davemloft.net> In-Reply-To: <5cac192f04091423453ae3cb@mail.gmail.com> References: <5cac192f04091423453ae3cb@mail.gmail.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 375 Lines: 13 On Wed, 15 Sep 2004 08:45:21 +0200 Eric Lemoine wrote: > The attached patch adds LLTX support to SunGEM NAPI. The tx_lock patch > I just sent must be applied first. Also applied, thanks Eric. I remember you mentioning yesterday that Harald's sungem NAPI patch had netpoll support, can you cook up a patch that adds it for current sungem? Thanks. From Robert.Olsson@data.slu.se Wed Sep 15 08:41:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 08:42:07 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FFfsmf026023 for ; Wed, 15 Sep 2004 08:41:54 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8FFfg9Y020688; Wed, 15 Sep 2004 17:41:42 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 6A3B090265; Wed, 15 Sep 2004 17:41:42 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16712.25270.406341.584928@robur.slu.se> Date: Wed, 15 Sep 2004 17:41:42 +0200 To: P@draigBrady.com Cc: Robert Olsson , Harald Welte , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 In-Reply-To: <41484AC2.8090408@draigBrady.com> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> <41484AC2.8090408@draigBrady.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 8855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 668 Lines: 28 P@draigBrady.com writes: > So I'm guessing that increasing the PCI-X burst size setting > (MMRBC) will automatically get more packets sent per transfer? > I said previously in this thread to google for setpci and MMRBC, > but what I know about it is... > > To return the current setting(s): > > setpci -d 8086:1010 e6.b > > The MMRBC is the upper two bits of the lower nibble, where: > > 0 = 512 byte bursts > 1 = 1024 byte bursts > 2 = 2048 byte bursts > 3 = 4096 byte bursts > > For me to set 4KiB bursts I do: > > setpci -d 8086:1010 e6.b=0e Thanks! That should definitely be tested. Four runs w. pktgen should be enough. --ro From eric.lemoine@gmail.com Wed Sep 15 08:56:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 08:56:15 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FFuAY7026615 for ; Wed, 15 Sep 2004 08:56:10 -0700 Received: by mproxy.gmail.com with SMTP id 79so182067rnk for ; Wed, 15 Sep 2004 08:55:52 -0700 (PDT) Received: by 10.38.70.19 with SMTP id s19mr1035392rna; Wed, 15 Sep 2004 08:55:52 -0700 (PDT) Received: by 10.38.99.58 with HTTP; Wed, 15 Sep 2004 08:55:52 -0700 (PDT) Message-ID: <5cac192f040915085516b0fc63@mail.gmail.com> Date: Wed, 15 Sep 2004 17:55:52 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: "David S. Miller" Subject: Re: [SUNGEM] LLTX support Cc: netdev@oss.sgi.com In-Reply-To: <20040915083559.6c36759f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <5cac192f04091423453ae3cb@mail.gmail.com> <20040915083559.6c36759f.davem@davemloft.net> X-archive-position: 8856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 525 Lines: 17 On Wed, 15 Sep 2004 08:35:59 -0700, David S. Miller wrote: > On Wed, 15 Sep 2004 08:45:21 +0200 > Eric Lemoine wrote: > > > The attached patch adds LLTX support to SunGEM NAPI. The tx_lock patch > > I just sent must be applied first. > > Also applied, thanks Eric. > > I remember you mentioning yesterday that Harald's sungem NAPI > patch had netpoll support, can you cook up a patch that adds > it for current sungem? Can't do it right now but will do it soon... -- Eric From davem@davemloft.net Wed Sep 15 08:58:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 08:58:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FFw5DA026835 for ; Wed, 15 Sep 2004 08:58:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7c7z-0001Va-00; Wed, 15 Sep 2004 08:55:27 -0700 Date: Wed, 15 Sep 2004 08:55:26 -0700 From: "David S. Miller" To: greg chesson Cc: vkondra@mail.ru, mcgrof@studorgs.rutgers.edu, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, mcgrof@studorgs.rutgers.edu, netdev@oss.sgi.com, prism54-devel@prism54.org, sam@errno.com Subject: Re: generic 802.11 stack Message-Id: <20040915085526.2c0d2904.davem@davemloft.net> In-Reply-To: <41485608.3040509@atheros.com> References: <4145352F.4040807@pobox.com> <20040915030545.GA25307@havoc.gtf.org> <20040915031732.GL7839@ruslug.rutgers.edu> <200409150844.45242.vkondra@mail.ru> <41485608.3040509@atheros.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 404 Lines: 12 On Wed, 15 Sep 2004 07:47:36 -0700 greg chesson wrote: > Vladimir Kondratiev wrote: > > Let me answer to the set of questions raised: > > > > - dual licensing: I am not ready to answer for legal. I will discuss with > > proper people and answer. > end the end it is your choice. He has to also ask the person who wrote the code he is basing his work upon, and that would be me :-) From manfred@colorfullife.com Wed Sep 15 09:21:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 09:21:48 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FGL2wR027819 for ; Wed, 15 Sep 2004 09:21:03 -0700 Received: from [127.0.0.2] (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8FGJWuG008819; Wed, 15 Sep 2004 18:19:33 +0200 Message-ID: <41486B93.40407@colorfullife.com> Date: Wed, 15 Sep 2004 18:19:31 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: "David S. Miller" , Harald Welte , netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <20040914124315.716e9c68.davem@davemloft.net> <20040914200238.GM8434@sunbeam.de.gnumonks.org> <20040914134849.6685de79.davem@davemloft.net> <20040914210117.GA3344@havoc.gtf.org> In-Reply-To: <20040914210117.GA3344@havoc.gtf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 610 Lines: 28 Jeff Garzik wrote: >On Tue, Sep 14, 2004 at 01:48:49PM -0700, David S. Miller wrote: > > >>On Tue, 14 Sep 2004 22:02:38 +0200 >>Harald Welte wrote: >> >> >> >>>Before I start NAPI-enabling natsemi.c (and again duplicate work): Do >>>you know of anybody working on this yet? >>> >>> >>No I do not, have at it. >> >> > >Talk to Manfred Spraul, he's pokes fixes natsemi bugs and pokes at it >now and again... > > > I don't have a NAPI patch in my tree, but I can't guarantee that there won't be an embedded system guy who suddenly appears with a patch. -- Manfred From sam@errno.com Wed Sep 15 09:45:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 09:45:11 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FGj67c028483 for ; Wed, 15 Sep 2004 09:45:06 -0700 Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i8FGilWi040727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 15 Sep 2004 09:44:48 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: "David S. Miller" Subject: Re: generic 802.11 stack Date: Wed, 15 Sep 2004 09:48:57 -0700 User-Agent: KMail/1.7 Cc: greg chesson , vkondra@mail.ru, mcgrof@studorgs.rutgers.edu, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, netdev@oss.sgi.com, prism54-devel@prism54.org References: <4145352F.4040807@pobox.com> <41485608.3040509@atheros.com> <20040915085526.2c0d2904.davem@davemloft.net> In-Reply-To: <20040915085526.2c0d2904.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409150948.58583.sam@errno.com> X-archive-position: 8859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sam@errno.com Precedence: bulk X-list: netdev Content-Length: 669 Lines: 20 On Wednesday 15 September 2004 08:55 am, David S. Miller wrote: > On Wed, 15 Sep 2004 07:47:36 -0700 > > greg chesson wrote: > > Vladimir Kondratiev wrote: > > > Let me answer to the set of questions raised: > > > > > > - dual licensing: I am not ready to answer for legal. I will discuss > > > with proper people and answer. > > > > end the end it is your choice. > > He has to also ask the person who wrote the code he is > basing his work upon, and that would be me :-) That assumes he uses no code from somewhere else. Given that your code didn't include any protocol implementation I suspect he'll be borrowing work from elsewhere.... Sam From davem@davemloft.net Wed Sep 15 10:12:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 10:12:08 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FHC2FB030207 for ; Wed, 15 Sep 2004 10:12:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7dER-0001d5-00; Wed, 15 Sep 2004 10:06:11 -0700 Date: Wed, 15 Sep 2004 10:06:11 -0700 From: "David S. Miller" To: Sam Leffler Cc: greg@atheros.com, vkondra@mail.ru, mcgrof@studorgs.rutgers.edu, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, netdev@oss.sgi.com, prism54-devel@prism54.org Subject: Re: generic 802.11 stack Message-Id: <20040915100611.4d66a952.davem@davemloft.net> In-Reply-To: <200409150948.58583.sam@errno.com> References: <4145352F.4040807@pobox.com> <41485608.3040509@atheros.com> <20040915085526.2c0d2904.davem@davemloft.net> <200409150948.58583.sam@errno.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1010 Lines: 29 On Wed, 15 Sep 2004 09:48:57 -0700 Sam Leffler wrote: > On Wednesday 15 September 2004 08:55 am, David S. Miller wrote: > > On Wed, 15 Sep 2004 07:47:36 -0700 > > > > greg chesson wrote: > > > Vladimir Kondratiev wrote: > > > > Let me answer to the set of questions raised: > > > > > > > > - dual licensing: I am not ready to answer for legal. I will discuss > > > > with proper people and answer. > > > > > > end the end it is your choice. > > > > He has to also ask the person who wrote the code he is > > basing his work upon, and that would be me :-) > > That assumes he uses no code from somewhere else. Not at all. If he wants to change the licensing of any piece of code, he has to get permission from all the authors. So, firstly, if he wants to take my code and extend it in any way he'll need permission from me to use it as anything other than pure GPL. Secondly, if he wants to add BSD code to it he cannot do so without working out the previous paragraph. From laforge@netfilter.org Wed Sep 15 10:55:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 10:55:56 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FHtn3M032058 for ; Wed, 15 Sep 2004 10:55:50 -0700 Received: from dsl-213-023-154-201.arcor-ip.net ([213.23.154.201] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7e0I-0002X1-2m; Wed, 15 Sep 2004 19:55:38 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7e0F-0002UF-7A; Wed, 15 Sep 2004 19:55:35 +0200 Date: Wed, 15 Sep 2004 19:55:35 +0200 From: Harald Welte To: Robert Olsson Cc: P@draigBrady.com, Linux NICS , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 Message-ID: <20040915175535.GA2678@sunbeam.de.gnumonks.org> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <16712.14153.683690.710955@robur.slu.se> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1471 Lines: 46 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 02:36:25PM +0200, Robert Olsson wrote: > Chip should be able to transfer 64 packets in single burst I don't now > how set/verify this. maybe this is what the E1000_TCTL_PBE flag in TXCTL and E1000_TBT register are for? I tried switching TCTL_PBE on, and played with different values of TBT (0,1,255,65535) - however, no improvement in pps rate. Maybe someone form intel could comment on this? > Cheers. > --ro --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBSIIXXaXGVTD0i/8RAs2RAKCoE8oS1LIeP+AfwTHavKvrKs0/lACcCfEJ cGKtceu8WBm1BgrYgB85lfc= =Art0 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From jketreno@linux.intel.com Wed Sep 15 10:59:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 10:59:18 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FHxBmJ032435 for ; Wed, 15 Sep 2004 10:59:11 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8FHxvdq001950; Wed, 15 Sep 2004 17:59:57 GMT Received: from [127.0.0.1] (hdlrvguser-95.hd.intel.com [10.127.52.114]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id i8FHnK4E023875; Wed, 15 Sep 2004 17:49:26 GMT Message-ID: <41488298.7060909@linux.intel.com> Date: Wed, 15 Sep 2004 12:57:44 -0500 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040902 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Jeff Garzik , vkondra@mail.ru, greg@atheros.com, netdev@oss.sgi.com, acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: generic 802.11 stack References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409090815.40358.vkondra@mail.ru> <41408D8A.5010307@atheros.com> <200409122103.21770.vkondra@mail.ru> <4144E524.1050306@pobox.com> <20040912174544.630a0b44.davem@davemloft.net> In-Reply-To: <20040912174544.630a0b44.davem@davemloft.net> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Content-Length: 4092 Lines: 95 David S. Miller wrote: >On Sun, 12 Sep 2004 20:09:08 -0400 >Jeff Garzik wrote: > > >>Vladimir Kondratiev wrote: >> >> >>>To inform about status: >>>I started to work on idea of 802.11 generic stack. I start from code by Dave. >>>This far I fixed it to compile for 2.6 (Makefile and couple of syntax >>>errors). >>>I am going to implement minimum functionality, at this stage I will somehow >>>publish the project. Anyone can suggest what it the right solution for >>>hosting? Sourceforge? Something else? >>> >>> >>I can put it into the wireless-2.6 queue, which is where I would prefer >>that work on a generic 802.11 stack went. >> >> > >This is fine with me as well. > > I have seen two paths that need to occur: 1) Creation of a generic 802.11 frame handling stack (management, data, etc.) sufficient to do .3 to .11 conversion, .11 fragmentation, state machine, etc. 2) Tight integration of a .11 stack into the kernel The first step can occur with minimal changes to the rest of the kernel, isolated completely within drivers/net/wireless. Once a stack is there, all the drivers there can be adapted to use that. This would seem reasonable to pull into the 2.6 stable series. The second step will likely require more invasive changes to other parts of the networking stack and I hadn't thought such changes would be considered for 2.6. Am I incorrect in the above? We have been cleaning up the ipw2200/ipw2100 and their corresponding ieee80211 stack so that it could then be used with the other wifi drivers (adapting it to add back in features from HostAP that are currently stub'd out) in a non-intrusive way (we would like to get ipw* merged in soon). We have a bk tree for this cloned from wireless-2.6 avialable at ipw.bkbits.net/ipw-2.6. Right now a driver can register with netdev's xmit to receive the ethernet frame and then pass it to ieee80211_skb_to_txb() to transform it into a chain of 802.11 fragments (encrypted if configured to do so) which the device can then pass to the HW. I don't like the way the skb_to_txb transform occurs, but its working right now. The next level of integration would be to have the device driver register an ieee80211 stack callback as the xmit handler, and then register a .11 xmit with the ieee80211 stack. Anyway, based on what I had read previously on this group, the sequence of steps I understood needing to be followed were: 0) Get the ipw2100 and ipw2200 drivers functionally complete so that end users can fully utilize that hardware. 1) Create generic ieee80211 frame handling stack. HW specific piece should be limited to Tx/Rx of raw frames as much as possible (while supporting drivers that can not do full 802.11 frame tx/rx). For nonintrusive inclusion in kernel, this would be achieved through calls into the ieee80211 stack from the driver vs. addition of netdev entry points. To date this has been achieved by adding infrastructure into either the ipw2100 or ipw2200 project, then merging it into ieee80211 so that the other project could leverage it. 2) Adapt other drivers besides ipw2100 and ipw2200 to use the stack 3) Once 1 and 2 are stabilized, begin restructuring the entry points to more tightly integrate the .11 handling into the netdev core. One area where I wasn't sure on how invasive it would be for stack optimizations deal with 802.11 fragmentation and encryption of said fragments such that TCP retries do not require re-fragmentation/encryption when host based enc/frag is enabled. The next potentially invasive area is the addition of TGe support which Vladimir has discussed previously. We based the current ieee80211 stack in part on the Host AP stack. In looking through the madwifi stack, there are traights that it carries that would be nice to be able to use as well moving forward -- whether through code (CVS madwifi is licensed under a GPL compatible BSD license) or aspects of design. The whole of the ieee80211 stack (and ipw2100/ipw2200 drivers) are licensed under GPL version 2. James From wsonguci@yahoo.com Wed Sep 15 11:06:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 11:06:27 -0700 (PDT) Received: from web40007.mail.yahoo.com (web40007.mail.yahoo.com [66.218.78.25]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8FI6LtL000427 for ; Wed, 15 Sep 2004 11:06:21 -0700 Message-ID: <20040915180603.98079.qmail@web40007.mail.yahoo.com> Received: from [63.87.1.243] by web40007.mail.yahoo.com via HTTP; Wed, 15 Sep 2004 11:06:03 PDT Date: Wed, 15 Sep 2004 11:06:03 -0700 (PDT) From: Song Wang Subject: Re: [Routing] Performance Comparison between 2.6 and 2.4 kernel To: hadi@cyberus.ca Cc: netdev@oss.sgi.com In-Reply-To: <1094868693.1041.86.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 8863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wsonguci@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1485 Lines: 69 Hi, The mips CPU on the board is MIPS32 compatible. I don't think it's NAPI based. The gettimeofday patch you mentioned came into the 2.6 kernel at what version? Do you think it's related to HZ change from 100 to 1000? Actually I did change HZ back to 100, but it didn't help. -Song --- jamal wrote: > > What mips board is this? NAPI based? > I would say that you should get higher numbers with > 2.6.x. > Are you running any sort of apps that need > gettimeofday? > I have certainly seen higher numbers on 2.6 vs 2.4 > starting at some > point where Andis gettimeofday patch went in - but > this was on x86. > > cheers, > jamal > > On Fri, 2004-09-10 at 20:52, Song Wang wrote: > > Hi, > > > > I'm looking for the network packet routing > > performance comparison between the latest 2.4 > > and 2.6 kernel. > > > > I did some initial testing on my mips-based > router. > > 2.6 kernel (2.6.8.1) performed way below 2.4 > kernel > > (2.4.17). It sucks. Turning on preemption on 2.6 > > kernel even makes routing performance worse. > > > > Anybody did a comprehensive study on the routing > > performance for 2.6 and 2.4 kernel? > > > > Thanks. > > > > > > > > __________________________________ > > Do you Yahoo!? > > Y! Messenger - Communicate in real time. Download > now. > > http://messenger.yahoo.com > > > > > > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From davem@davemloft.net Wed Sep 15 11:11:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 11:11:39 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FIBXnF000892 for ; Wed, 15 Sep 2004 11:11:33 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7eDD-0001lv-00; Wed, 15 Sep 2004 11:08:59 -0700 Date: Wed, 15 Sep 2004 11:08:58 -0700 From: "David S. Miller" To: Song Wang Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [Routing] Performance Comparison between 2.6 and 2.4 kernel Message-Id: <20040915110858.125cea28.davem@davemloft.net> In-Reply-To: <20040915180603.98079.qmail@web40007.mail.yahoo.com> References: <1094868693.1041.86.camel@jzny.localdomain> <20040915180603.98079.qmail@web40007.mail.yahoo.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 360 Lines: 12 On Wed, 15 Sep 2004 11:06:03 -0700 (PDT) Song Wang wrote: > The mips CPU on the board is MIPS32 compatible. > I don't think it's NAPI based. NAPI is an attribute of the network adapter, not the cpu. Although I would very much anticipate this being a MIPS or network adapter specific problem since on x86 routing is pretty fast in 2.6.x From laforge@netfilter.org Wed Sep 15 11:15:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 11:15:35 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FIFTjx001312 for ; Wed, 15 Sep 2004 11:15:29 -0700 Received: from dsl-213-023-154-201.arcor-ip.net ([213.23.154.201] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7eJJ-00031s-Vq; Wed, 15 Sep 2004 20:15:18 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7eJI-0002W4-Fc; Wed, 15 Sep 2004 20:15:16 +0200 Date: Wed, 15 Sep 2004 20:15:16 +0200 From: Harald Welte To: P@draigBrady.com Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 Message-ID: <20040915181516.GB2678@sunbeam.de.gnumonks.org> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> <41484AC2.8090408@draigBrady.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline In-Reply-To: <41484AC2.8090408@draigBrady.com> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 2109 Lines: 56 --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 02:59:30PM +0100, P@draigBrady.com wrote: > Interesting info thanks! > It would be very interesting to see the performance of PCI express > which should not have the bus arbitration issues. Unfortunately there is no e1000 for PCI Express available yet... only Marvell-Yukon and syskonnect single-port boards so far :( > Well from the intel docs they say "The devices include a PCI interface > that maximizes the use of bursts for efficient bus usage. > The controllers are able to cache up to 64 packet descriptors in > a single burst for efficient PCI bandwidth usage." >=20 > So I'm guessing that increasing the PCI-X burst size setting > (MMRBC) will automatically get more packets sent per transfer? > I said previously in this thread to google for setpci and MMRBC, > but what I know about it is... Mh, I tried it on my System, following parameters: dual 82456GB, PCI-X, 64bit, 66MHz, UP x86_64 kernel, modified e1000 with hard-wired tx descriptor refill. I did not observe any change in tx pps throughput when setting MMRBC to 512 / 4096 byte bursts. --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBSIa0XaXGVTD0i/8RAtnHAJ9FV+Z1yRbc5/GTviZDpvUlo2OxxwCgr5XW lPcRVFkyXgMWWW9TQ5zclMo= =OKqX -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- From davem@davemloft.net Wed Sep 15 11:18:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 11:18:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FII5eF001645 for ; Wed, 15 Sep 2004 11:18:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7eJP-0001n1-00; Wed, 15 Sep 2004 11:15:23 -0700 Date: Wed, 15 Sep 2004 11:15:22 -0700 From: "David S. Miller" To: Harald Welte Cc: P@draigBrady.com, Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: TX performance of Intel 82546 Message-Id: <20040915111522.02153d0c.davem@davemloft.net> In-Reply-To: <20040915181516.GB2678@sunbeam.de.gnumonks.org> References: <20040915081439.GA27038@sunbeam.de.gnumonks.org> <414808F3.70104@draigBrady.com> <16712.14153.683690.710955@robur.slu.se> <41484AC2.8090408@draigBrady.com> <20040915181516.GB2678@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 607 Lines: 16 On Wed, 15 Sep 2004 20:15:16 +0200 Harald Welte wrote: > On Wed, Sep 15, 2004 at 02:59:30PM +0100, P@draigBrady.com wrote: > > Interesting info thanks! > > It would be very interesting to see the performance of PCI express > > which should not have the bus arbitration issues. > > Unfortunately there is no e1000 for PCI Express available yet... only > Marvell-Yukon and syskonnect single-port boards so far :( There are TG3 chips that support PCI-Express. These are the 5705/5750 variants. I don't know if actual boards are being sold, or if these are currently on-board only. From jgarzik@pobox.com Wed Sep 15 12:34:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 12:34:17 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FJYBl4006497 for ; Wed, 15 Sep 2004 12:34:12 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7fXU-0006PQ-C3; Wed, 15 Sep 2004 20:34:00 +0100 Message-ID: <4148991B.9050200@pobox.com> Date: Wed, 15 Sep 2004 15:33:47 -0400 From: Jeff Garzik Reply-To: Netdev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: leonid.grossman@s2io.com, Linux Kernel Subject: The ultimate TOE design Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 2651 Lines: 70 (reply-to set to netdev) Every now and then people ask on the lists about TOE, TCP assist, and that sort of thing. Ignoring the issue of TCP hardware assist, I wanted to describe what I feel is an optimal method to _fully offload_ the Linux TCP stack. Put simply, the "ultimate TOE card" would be a card with network ports, a generic CPU (arm, mips, whatever.), some RAM, and some flash. This card's "firmware" is the Linux kernel, configured to run as a _totally indepenent network node_, with IP address(es) all its own. Then, your host system OS will communicate with the Linux kernel running on the card across the PCI bus, using IP packets (64K fixed MTU). This effectively: 1) fragment processing, IPsec, and other services onto the card. 2) You can use huge card<->host MTUs, which makes sendfile(2) faster with _zero_ kernel changes 3) You can let the PCI card do 100% of the checksum processing/generation, and treat the network connection connection across the PCI bus as CHECKSUM_UNNECESSARY. 2) With enough RAM and cpu cycles, you can even offload complex services like Web services: the PCI card runs Apache, and fetches files across the network (your PCI bus!) from the host system. 3) Does not require _any_ modification of Linux network stack. Interfacing with the card merely requires a simple DMA interface to copy IP (not ethernet) packets across the PCI bus, and that fits within the existing Linux net driver API. 4) ensures that the TOE "firmware" [the Linux kernel] can be easily updated in the event of new features or (more importantly) security problems. 5) Linux is the most RFC-compliant net stack in the world. Why re-create (or license) an inferior one? 6) Long-term maintenance of TOE firmware is a BIG problem with existing full-TOE systems. Under this design, sysadmins would update and patch their PCI card with security updates just like any other system on their network. This is added work, yes, but it's a known quantity and a task they are already doing for other systems. 7) The design is both portable [tons of embedded CPUs, with and without MMUs, can run Linux] and scalable. My dream is that some vendor will come along and implement such a design, and sell it in enough volume that it's US$100 or less. There are a few cards on the market already where implementing this design _may_ be possible, but they are all fairly expensive. Just need enough resources on the PCI to be able to Linux as a router/firewall/iSCSI/web-proxy gadget. And I'm not aware of anybody doing a direct IP-over-PCI thing, either. But I'll keep on dreaming... ;-) Jeff From laforge@gnumonks.org Wed Sep 15 12:38:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 12:39:10 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FJcQ08006907 for ; Wed, 15 Sep 2004 12:38:26 -0700 Received: from dsl-213-023-154-201.arcor-ip.net ([213.23.154.201] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C7fbb-0004cB-Cb; Wed, 15 Sep 2004 21:38:15 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C7fag-0002cL-6K; Wed, 15 Sep 2004 21:37:18 +0200 Date: Wed, 15 Sep 2004 21:37:18 +0200 From: Harald Welte To: Eric Lemoine Cc: netdev@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: Re: [PATCH 2.6] Add NAPI support to sungem.c Message-ID: <20040915193718.GE2678@sunbeam.de.gnumonks.org> References: <20040914153537.GE8434@sunbeam.de.gnumonks.org> <20040914124315.716e9c68.davem@davemloft.net> <20040914200238.GM8434@sunbeam.de.gnumonks.org> <5cac192f04091422506d13c530@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//IivP0gvsAy3Can" Content-Disposition: inline In-Reply-To: <5cac192f04091422506d13c530@mail.gmail.com> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1342 Lines: 42 --//IivP0gvsAy3Can Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 07:50:28AM +0200, Eric Lemoine wrote: > Your patch has the netpoll bits while current BK does not. Well, it's straight forward to merge them into BK... > PS: If you happened to experiment with the NAPIfied SunGEM driver on > your setup, could you please share the data. Thx. I didn't do any measurements so far... I only know that my Powerbook doesn't stop responding anymore when I flood it with pktgen ;) =20 > Eric --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --//IivP0gvsAy3Can Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBSJnuXaXGVTD0i/8RAnSqAJwJ3IxGdAD9xL1VTHwYw+F1E+Pu0wCfRpS+ mZaQizF4BVK6pV0jCIoHiH4= =cRJ/ -----END PGP SIGNATURE----- --//IivP0gvsAy3Can-- From paul@clubi.ie Wed Sep 15 13:05:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:05:11 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FK537W007656 for ; Wed, 15 Sep 2004 13:05:05 -0700 Received: from fogarty.jakma.org (fogarty.jakma.org [212.17.55.50]) by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id i8FK4e84025200; Wed, 15 Sep 2004 21:04:50 +0100 Date: Wed, 15 Sep 2004 21:04:38 +0100 (IST) From: Paul Jakma X-X-Sender: paul@fogarty.jakma.org To: Netdev cc: leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design In-Reply-To: <4148991B.9050200@pobox.com> Message-ID: References: <4148991B.9050200@pobox.com> X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@clubi.ie Precedence: bulk X-list: netdev Content-Length: 1137 Lines: 28 On Wed, 15 Sep 2004, Jeff Garzik wrote: > Put simply, the "ultimate TOE card" would be a card with network ports, a > generic CPU (arm, mips, whatever.), some RAM, and some flash. This card's > "firmware" is the Linux kernel, configured to run as a _totally indepenent > network node_, with IP address(es) all its own. > > Then, your host system OS will communicate with the Linux kernel running on > the card across the PCI bus, using IP packets (64K fixed MTU). > My dream is that some vendor will come along and implement such a > design, and sell it in enough volume that it's US$100 or less. > There are a few cards on the market already where implementing this > design _may_ be possible, but they are all fairly expensive. The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI card running Linux. Or is that what you were referring to with " but they are all fairly expensive."? > Jeff regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: There is nothing so easy but that it becomes difficult when you do it reluctantly. -- Publius Terentius Afer (Terence) From dlstevens@us.ibm.com Wed Sep 15 13:11:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:11:39 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKBXCc008067 for ; Wed, 15 Sep 2004 13:11:34 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8FKBCZd214180; Wed, 15 Sep 2004 16:11:12 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8FKBBBg145284; Wed, 15 Sep 2004 14:11:11 -0600 In-Reply-To: <4148991B.9050200@pobox.com> To: Netdev Cc: leonid.grossman@s2io.com, Linux Kernel , netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: The ultimate TOE design X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 15 Sep 2004 14:11:04 -0600 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/15/2004 14:11:11, Serialize complete at 09/15/2004 14:11:11 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 8870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 763 Lines: 17 I've never understood why people are so interested in off-loading networking. Isn't that just a multi-processor system where you can't use any of the network processor cycles for anything else? And, of course, to be cheap, the network processor will be slower, and much harder to debug and update software. If the PCI bus is too slow, or MTU's too small, wouldn't it be better to fix those directly and use a fast host processor that can also do other things when not needed for networking? And why have memory on a NIC that can't be used by other things? Why don't we off-load filesystems to disks instead? Or a graphics card that implements X ? :-) I'd rather have shared system resources-- more flexible. :-) +-DLS From alan@lxorguk.ukuu.org.uk Wed Sep 15 13:17:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:17:59 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKHrX3008457 for ; Wed, 15 Sep 2004 13:17:54 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8FJFHfG020589; Wed, 15 Sep 2004 20:15:17 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8FJENxu020574; Wed, 15 Sep 2004 20:14:23 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: The ultimate TOE design From: Alan Cox To: Paul Jakma Cc: Netdev , leonid.grossman@s2io.com, Linux Kernel Mailing List In-Reply-To: References: <4148991B.9050200@pobox.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095275660.20569.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 15 Sep 2004 20:14:22 +0100 X-archive-position: 8871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 400 Lines: 10 On Mer, 2004-09-15 at 21:04, Paul Jakma wrote: > The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI > card running Linux. Or is that what you were referring to with > " but they are all fairly expensive."? Last time I checked 2Ghz accelerators for intel and AMD were quite cheap and also had the advantage they ran user mode code when idle from network processing. From jgarzik@pobox.com Wed Sep 15 13:25:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:25:39 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKPYhq008857 for ; Wed, 15 Sep 2004 13:25:35 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7gL9-0000IO-5s; Wed, 15 Sep 2004 21:25:19 +0100 Message-ID: <4148A51F.7030909@pobox.com> Date: Wed, 15 Sep 2004 16:25:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Stevens CC: Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1268 Lines: 30 David Stevens wrote: > I've never understood why people are so interested in off-loading > networking. Isn't that just a multi-processor system where you can't > use any of the network processor cycles for anything else? And, of > course, to be cheap, the network processor will be slower, and much > harder to debug and update software. Well I do agree there is a strong don't-bother-with-TOE argument: Moore's law, the CPUs (manufactured in vast quantities) will usually However, there are companies are Just Gotta Do TOE... and I am not inclined to assist in any effort that compromises Linux's RFC compliancy or security. Current TOE efforts seem to be of the "shove your data through this black box" variety, which is rather disheartening. Even non-TOE NICs these days have ever-more-complex firmwares. tg3 is a MIPS-based engine for example. > If the PCI bus is too slow, or MTU's too small, wouldn't > it be better to fix those directly and use a fast host processor that can > also do other things when not needed for networking? And why have > memory on a NIC that can't be used by other things? PCI bus tends to be slower than DRAM<->CPU speed, and MTUs across the Internet will be small as long as ethernet enjoys continued success. Jeff From nhorman@redhat.com Wed Sep 15 13:26:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:26:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKQQWs009049 for ; Wed, 15 Sep 2004 13:26:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8FKQAgA013915; Wed, 15 Sep 2004 16:26:10 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8FKQ9r24160; Wed, 15 Sep 2004 16:26:09 -0400 Received: from redhat.com (hmsendeavour.rdu.redhat.com [172.16.57.156]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i8FKQ9Np016033; Wed, 15 Sep 2004 16:26:09 -0400 Message-ID: <4148A561.5070401@redhat.com> Date: Wed, 15 Sep 2004 16:26:09 -0400 From: Neil Horman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0; hi, Mom) Gecko/20020604 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma CC: Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design References: <4148991B.9050200@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 1501 Lines: 42 Paul Jakma wrote: > On Wed, 15 Sep 2004, Jeff Garzik wrote: > >> Put simply, the "ultimate TOE card" would be a card with network >> ports, a generic CPU (arm, mips, whatever.), some RAM, and some >> flash. This card's "firmware" is the Linux kernel, configured to run >> as a _totally indepenent network node_, with IP address(es) all its own. >> >> Then, your host system OS will communicate with the Linux kernel >> running on the card across the PCI bus, using IP packets (64K fixed MTU). > > >> My dream is that some vendor will come along and implement such a >> design, and sell it in enough volume that it's US$100 or less. There >> are a few cards on the market already where implementing this design >> _may_ be possible, but they are all fairly expensive. > > > The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI card > running Linux. Or is that what you were referring to with " > but they are all fairly expensive."? > >> Jeff > > > regards, IBM's PowerNP chip was also very simmilar (a powerpc core with lots of hardware assists for DMA and packet inspection in the extended register area). Don't know if they still sell it, but at one time I had heard they had booted linux on it. Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From rugolsky@telemetry-investments.com Wed Sep 15 13:31:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:31:52 -0700 (PDT) Received: from ti41.telemetry-investments.com (209-166-240-202.cust.walrus.com [209.166.240.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKVerv009548 for ; Wed, 15 Sep 2004 13:31:40 -0700 Received: from ti64.telemetry-investments.com (ti64 [192.168.8.64]) by ti41.telemetry-investments.com (Postfix) with ESMTP id F18A0100D8; Wed, 15 Sep 2004 16:31:22 -0400 (EDT) Received: by ti64.telemetry-investments.com (Postfix, from userid 343) id E5EEA10062; Wed, 15 Sep 2004 16:31:22 -0400 (EDT) Date: Wed, 15 Sep 2004 16:31:22 -0400 From: "Bill Rugolsky Jr." To: Netdev Cc: Jeff Garzik , David Stevens Subject: Re: The ultimate TOE design Message-ID: <20040915203122.GA25987@ti64.telemetry-investments.com> References: <4148991B.9050200@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 8874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brugolsky@telemetry-investments.com Precedence: bulk X-list: netdev Content-Length: 1189 Lines: 28 On Wed, Sep 15, 2004 at 02:11:04PM -0600, David Stevens wrote: > If the PCI bus is too slow, or MTU's too small, wouldn't > it be better to fix those directly and use a fast host processor that can > also do other things when not needed for networking? And why have > memory on a NIC that can't be used by other things? I tend to agree. Referring to the Opteron with its per-CPU memory controller, Robert Olsson just wrote in the "TX performance of Intel 82546" thread: This is a little breakthrough as we for the first time see some aggregated performance with packet forwarding and got something in return for all multiprocessor efforts. IMO this is much more important then the last percent of performance of pps numbers. In 2005, we'll have commodity dual-core packages, making a four-core (dual-CPU) system available at an attractive price point. The number will rise dramatically after that. I don't really think CPU cycles are the problem. A useful reason I can see for "offloading" is isolation of concerns, e.g., locking, real-time latencies, security, etc. But then, why not run something like the Xen2 virtual machine environment? Regards, Bill Rugolsky From davids@webmaster.com Wed Sep 15 13:39:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:40:03 -0700 (PDT) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.168]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKdvZx009997 for ; Wed, 15 Sep 2004 13:39:57 -0700 Received: from WorldClient by webmaster.com (MDaemon.PRO.v7.1.0.R) with ESMTP id md50000184066.msg for ; Wed, 15 Sep 2004 13:16:38 -0700 Received: from [206.171.168.130] via WorldClient with HTTP; Wed, 15 Sep 2004 13:16:36 -0700 Date: Wed, 15 Sep 2004 13:16:36 -0700 From: "David Schwartz" To: "David Stevens" , "Netdev" , leonid.grossman@s2io.com, "Linux Kernel" Subject: Re: The ultimate TOE design MIME-Version: 1.0 Content-Type: text/plain Message-ID: X-Mailer: WorldClient 7.1.0 In-Reply-To: References: <4148991B.9050200@pobox.com> X-Authenticated-Sender: joelkatz@webmaster.com X-MDRemoteIP: 127.0.0.1 X-Return-Path: davids@webmaster.com X-MDaemon-Deliver-To: netdev@oss.sgi.com Reply-To: davids@webmaster.com X-MDAV-Processed: mail1.webmaster.com, Wed, 15 Sep 2004 13:16:39 -0700 X-archive-position: 8875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davids@webmaster.com Precedence: bulk X-list: netdev Content-Length: 1566 Lines: 38 David Stevens wrote: > I've never understood why people are so interested in off-loading > networking. Isn't that just a multi-processor system where you can't > use any of the network processor cycles for anything else? And, of > course, to be cheap, the network processor will be slower, and much > harder to debug and update software. The issues of debugging the network processor software and maintaining it is certainly a legitimate one. However, nothing stops you from using the extra network processor cycles for other purposes. > If the PCI bus is too slow, or MTU's too small, wouldn't > it be better to fix those directly and use a fast host processor that > can > also do other things when not needed for networking? And why have > memory on a NIC that can't be used by other things? This isn't an either-or. Processors are cheap. Memory is cheap. > Why don't we off-load filesystems to disks instead? Or a graphics > card that implements X ? :-) I'd rather have shared system resources-- > more flexible. :-) It's not one or the other. If, for example, your network card, graphics card, and hard drive controller all use a common instruction set and are all interconnected by a fast bus, code can be fairly mobile and run wherever it's the most efficient. Nothing stops the OS from offloading internal tasks to these processors as well. The only real stumbling blocks have been cost/volume considerations and the fact that the central processor(s) can be so fast, and the I/O so slow in comparison, that there's not much to gain. DS From jgarzik@pobox.com Wed Sep 15 13:42:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:42:22 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKgG3O010254 for ; Wed, 15 Sep 2004 13:42:17 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7gbN-0000lA-EI; Wed, 15 Sep 2004 21:42:05 +0100 Message-ID: <4148A90F.80003@pobox.com> Date: Wed, 15 Sep 2004 16:41:51 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Cox CC: Paul Jakma , Netdev , leonid.grossman@s2io.com, Linux Kernel Mailing List Subject: Re: The ultimate TOE design References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> In-Reply-To: <1095275660.20569.0.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 623 Lines: 22 Alan Cox wrote: > On Mer, 2004-09-15 at 21:04, Paul Jakma wrote: > >>The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI >>card running Linux. Or is that what you were referring to with >>" but they are all fairly expensive."? > > > Last time I checked 2Ghz accelerators for intel and AMD were quite cheap > and also had the advantage they ran user mode code when idle from > network processing. The point was more to show people who are doing TOE _anyway_ to a decent design. As I said in another post, "just don't bother with TOE" is a very valid answer with today's CPUs. Jeff From nhorman@redhat.com Wed Sep 15 13:54:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:54:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKsfwq011154 for ; Wed, 15 Sep 2004 13:54:41 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8FKsU5b022005; Wed, 15 Sep 2004 16:54:30 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8FKsUr01788; Wed, 15 Sep 2004 16:54:30 -0400 Received: from redhat.com (hmsendeavour.rdu.redhat.com [172.16.57.156]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i8FKsUNp021782; Wed, 15 Sep 2004 16:54:30 -0400 Message-ID: <4148AC06.60400@redhat.com> Date: Wed, 15 Sep 2004 16:54:30 -0400 From: Neil Horman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0; hi, Mom) Gecko/20020604 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: David Stevens , Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design References: <4148A51F.7030909@pobox.com> In-Reply-To: <4148A51F.7030909@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 2570 Lines: 60 Jeff Garzik wrote: > David Stevens wrote: > >> I've never understood why people are so interested in off-loading >> networking. Isn't that just a multi-processor system where you can't >> use any of the network processor cycles for anything else? And, of >> course, to be cheap, the network processor will be slower, and much >> harder to debug and update software. > > > Well I do agree there is a strong don't-bother-with-TOE argument: > Moore's law, the CPUs (manufactured in vast quantities) will usually > > > However, there are companies are Just Gotta Do TOE... and I am not > inclined to assist in any effort that compromises Linux's RFC compliancy > or security. Current TOE efforts seem to be of the "shove your data > through this black box" variety, which is rather disheartening. > > Even non-TOE NICs these days have ever-more-complex firmwares. tg3 is a > MIPS-based engine for example. > > >> If the PCI bus is too slow, or MTU's too small, wouldn't >> it be better to fix those directly and use a fast host processor that can >> also do other things when not needed for networking? And why have >> memory on a NIC that can't be used by other things? > > > PCI bus tends to be slower than DRAM<->CPU speed, and MTUs across the > Internet will be small as long as ethernet enjoys continued success. > > Jeff There is also something to be said for the embedded market here. offload chips are fairly usefull when building switches and routers. Dave M. in a thread just a few weeks ago provided some metrics for how much bandwidth a PCI-x bus and a some-odd-gigahertz processor could handle. It worked that a pc with the right componenets could theoretically handle about 4 gigahertz nics running traffic full duplex at line rate. Thats great, but it doesn't come close to what you need for a 24 port gigabit L3 switch, nor does it approach the correct price point. Most of these designs use a less expensive processor running at a slower speed, and an offload chip (that incorporates tx/rx logic and a switching fabric) to preform most of the routing and switching. For cost concious network equipment manufacturers, they are really the way to go. Unfortunately, many of them don't actaully run as a co-processor, and so don't enable Jeff's idea very well (yet :)) Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From davem@davemloft.net Wed Sep 15 13:55:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 13:55:53 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FKtm3Y011350 for ; Wed, 15 Sep 2004 13:55:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7gm4-000227-00; Wed, 15 Sep 2004 13:53:08 -0700 Date: Wed, 15 Sep 2004 13:53:08 -0700 From: "David S. Miller" To: Alan Cox Cc: paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-Id: <20040915135308.78bf74f0.davem@davemloft.net> In-Reply-To: <1095275660.20569.0.camel@localhost.localdomain> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 867 Lines: 22 On Wed, 15 Sep 2004 20:14:22 +0100 Alan Cox wrote: > On Mer, 2004-09-15 at 21:04, Paul Jakma wrote: > > The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI > > card running Linux. Or is that what you were referring to with > > " but they are all fairly expensive."? > > Last time I checked 2Ghz accelerators for intel and AMD were quite cheap > and also had the advantage they ran user mode code when idle from > network processing. ROFL, and this is my position on this topic as well. There are absolutely no justified economics in these TOE engines. By the time you deploy them, the cpus and memory catch up and what's more those are general purpose and not just for networking as David Stevens and others have said. TOE is just junk, and we'll reject any attempt to put that garbage into the kernel. From davem@davemloft.net Wed Sep 15 14:04:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:04:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FL42xQ011971 for ; Wed, 15 Sep 2004 14:04:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7gu3-00023T-00; Wed, 15 Sep 2004 14:01:23 -0700 Date: Wed, 15 Sep 2004 14:01:23 -0700 From: "David S. Miller" To: Jeff Garzik Cc: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-Id: <20040915140123.14185ede.davem@davemloft.net> In-Reply-To: <4148A90F.80003@pobox.com> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 318 Lines: 10 On Wed, 15 Sep 2004 16:41:51 -0400 Jeff Garzik wrote: > The point was more to show people who are doing TOE _anyway_ to a decent > design. We shouldn't be forced to refine people's non-sensible ideas which we'll not support anyways. If TOE is supported on Windows only, I happily welcome that. From garzik@havoc.gtf.org Wed Sep 15 14:09:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:09:51 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FL9kI7012366 for ; Wed, 15 Sep 2004 14:09:46 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 533AA76AA; Wed, 15 Sep 2004 17:08:19 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8FL8IIQ022946; Wed, 15 Sep 2004 17:08:18 -0400 Date: Wed, 15 Sep 2004 17:08:18 -0400 From: Jeff Garzik To: "David S. Miller" Cc: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-ID: <20040915210818.GA22649@havoc.gtf.org> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915140123.14185ede.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 8880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 754 Lines: 25 On Wed, Sep 15, 2004 at 02:01:23PM -0700, David S. Miller wrote: > On Wed, 15 Sep 2004 16:41:51 -0400 > Jeff Garzik wrote: > > > The point was more to show people who are doing TOE _anyway_ to a decent > > design. > > We shouldn't be forced to refine people's non-sensible ideas which > we'll not support anyways. I just described a design that -we already support-. It's generic scalable model that has application outside the acronym "TOE". Did you read my message, or just see 'TOE' and nothing else? Sun used this model with their x86 cards. Total MP did something similar with their 4-processor PowerPC cards. There's nothing inherently wrong with sticking a computer running Linux inside another computer ;-) Jeff From david.lang@digitalinsight.com Wed Sep 15 14:10:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:10:40 -0700 (PDT) Received: from warden3.diginsite.com (warden3-p.diginsite.com [208.147.64.186]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8FLATnE012557 for ; Wed, 15 Sep 2004 14:10:35 -0700 Received: from sacims01.digitalinsight.com by warden3.diginsite.com via smtpd (for oss.sgi.com [192.48.159.27]) with SMTP; Wed, 15 Sep 2004 14:10:25 -0700 Received: by sacexc01.diginsite.com with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Sep 2004 14:10:09 -0700 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvexc00.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SYHQ8CSM; Wed, 15 Sep 2004 14:08:35 -0700 From: David Lang To: Alan Cox Cc: Paul Jakma , Netdev , leonid.grossman@s2io.com, Linux Kernel Mailing List Date: Wed, 15 Sep 2004 14:10:03 -0700 (PDT) X-X-Sender: dlang@dlang.diginsite.com Subject: Re: The ultimate TOE design In-Reply-To: <1095275660.20569.0.camel@localhost.localdomain> Message-ID: References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david.lang@digitalinsight.com Precedence: bulk X-list: netdev Content-Length: 1233 Lines: 26 On Wed, 15 Sep 2004, Alan Cox wrote: > On Mer, 2004-09-15 at 21:04, Paul Jakma wrote: >> The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI >> card running Linux. Or is that what you were referring to with >> " but they are all fairly expensive."? > > Last time I checked 2Ghz accelerators for intel and AMD were quite cheap > and also had the advantage they ran user mode code when idle from > network processing. That depends on how many of these accelerators you already have in the system. If you have 4 of them and they are heavily used so that you want to offload them it definantly isn't cheap to add a 5th (you useually have to go up to 8 or so and the difference between 4 and 8 is frequently 2x-4x the cost of the 4 processor box) now if you start with a single CPU system then yes, adding a second one is cheap. but these are useually not the people who really need TOE (they may think that they do, but that's a different story :-) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From linux-netdev@gmane.org Wed Sep 15 14:11:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:11:54 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLBkg4012788 for ; Wed, 15 Sep 2004 14:11:47 -0700 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7h3v-0002qB-00 for ; Wed, 15 Sep 2004 23:11:35 +0200 Received: from pixpat.austin.ibm.com ([192.35.232.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2004 23:11:35 +0200 Received: from wesley by pixpat.austin.ibm.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2004 23:11:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Wes Felter Subject: Re: The ultimate TOE design Date: Wed, 15 Sep 2004 16:03:57 -0500 Message-ID: References: <4148991B.9050200@pobox.com> <4148A561.5070401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pixpat.austin.ibm.com User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en In-Reply-To: <4148A561.5070401@redhat.com> Cc: linux-kernel@vger.kernel.org X-archive-position: 8882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wesley@felter.org Precedence: bulk X-list: netdev Content-Length: 1580 Lines: 35 Neil Horman wrote: > Paul Jakma wrote: > >> On Wed, 15 Sep 2004, Jeff Garzik wrote: >> >>> Put simply, the "ultimate TOE card" would be a card with network >>> ports, a generic CPU (arm, mips, whatever.), some RAM, and some >>> flash. This card's "firmware" is the Linux kernel, configured to run >>> as a _totally indepenent network node_, with IP address(es) all its own. >>> >>> Then, your host system OS will communicate with the Linux kernel >>> running on the card across the PCI bus, using IP packets (64K fixed >>> MTU). >> The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI >> card running Linux. Or is that what you were referring to with "> exist> but they are all fairly expensive."? > IBM's PowerNP chip was also very simmilar (a powerpc core with lots of > hardware assists for DMA and packet inspection in the extended register > area). Don't know if they still sell it, but at one time I had heard > they had booted linux on it. An IXP or PowerNP wouldn't work for Jeff's idea. The IXP's XScale core and PowerNP's PowerPC core are way too slow to do any significant processing; they are intended for control tasks like updating the routing tables. All the work in the IXP or PowerNP is done by the microengines, which have weird, non-Linux-compatible architectures. To do 10 Gbps Ethernet with Jeff's approach, wouldn't you need a 5-10 GHz processor on the card? Sounds expensive. A 440GX or BCM1250 on a cheap PCI card would be fun to play with, though. Wes Felter - wesley@felter.org - http://felter.org/wesley/ From garzik@havoc.gtf.org Wed Sep 15 14:16:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:16:04 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLG0b8013378 for ; Wed, 15 Sep 2004 14:16:00 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id C97B77769; Wed, 15 Sep 2004 17:15:43 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8FLFhYQ023973; Wed, 15 Sep 2004 17:15:43 -0400 Date: Wed, 15 Sep 2004 17:15:43 -0400 From: Jeff Garzik To: Wes Felter Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-ID: <20040915211543.GA23906@havoc.gtf.org> References: <4148991B.9050200@pobox.com> <4148A561.5070401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 8883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 255 Lines: 10 On Wed, Sep 15, 2004 at 04:03:57PM -0500, Wes Felter wrote: > To do 10 Gbps Ethernet with Jeff's approach, wouldn't you need a 5-10 > GHz processor on the card? Sounds expensive. Do you need a 5-10 Ghz Intel server to handle 10 Gbps ethernet? Jeff From davem@davemloft.net Wed Sep 15 14:16:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:16:44 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLGerI013604 for ; Wed, 15 Sep 2004 14:16:40 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7h62-00024v-00; Wed, 15 Sep 2004 14:13:46 -0700 Date: Wed, 15 Sep 2004 14:13:46 -0700 From: "David S. Miller" To: Jeff Garzik Cc: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-Id: <20040915141346.5c5e5377.davem@davemloft.net> In-Reply-To: <20040915210818.GA22649@havoc.gtf.org> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8884 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 422 Lines: 12 On Wed, 15 Sep 2004 17:08:18 -0400 Jeff Garzik wrote: > There's nothing inherently wrong with sticking a computer running > Linux inside another computer ;-) And we already support that :-) Plus we have things like TSO too but that doesn't require a full Linux instance to realize on a networking port. Simple silicon implements this already. I don't see how that differs from your "big MTU" ideas. From mcr@sandelman.ottawa.on.ca Wed Sep 15 14:16:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:16:55 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLGnYP013650 for ; Wed, 15 Sep 2004 14:16:50 -0700 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8FLGUj15834 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Wed, 15 Sep 2004 17:16:32 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8FLNCo26779 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 15 Sep 2004 17:23:17 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i8FLFPck016494; Wed, 15 Sep 2004 17:15:25 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i8FLFASx016415; Wed, 15 Sep 2004 17:15:11 -0400 To: "David S. Miller" cc: Jeff Garzik , alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design In-Reply-To: Message from "David S. Miller" of "Wed, 15 Sep 2004 14:01:23 PDT." <20040915140123.14185ede.davem@davemloft.net> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Sep 2004 17:15:10 -0400 Message-ID: <16414.1095282910@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 8885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 1595 Lines: 41 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David S Miller writes: >> The point was more to show people who are doing TOE _anyway_ to a decent >> design. David> We shouldn't be forced to refine people's non-sensible ideas which David> we'll not support anyways. David> If TOE is supported on Windows only, I happily welcome that. Ha. Too hard to do :-) The TOEs and L7 content switches that I know of are supported... UNDER LINUX ONLY The one that I'm most familliar with (Seaway's SW5000/NCA2000) provides a new socket family to the host, which corresponds to streams that terminate on the NCA2000. The host can request things like having two TCP streams be cross-connected, even adding/subtracting SSL along the way. This code does not interact with the Linux IP stack at all --- so it isn't exactly a TOE. You have to, at a minimum recompile applications. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQUiw3YqHRg3pndX9AQHrwQQAoK2C4btD6vk/UZ1Bv7zTgtbw/EvZuU2F ZqPDiYfHMIsfsCYBWqLrjU2oxkkO+RgH3NOoNTJQuuVFjLlDw2pPHgH9DXaYdZy8 3To0LGdmIZR4u+mMx2WFRyYjuDM1iQ3ZbAskN5JzW3Jc77SbrJZaap1fQua5U3qg gfNQ21OPkSI= =+JBc -----END PGP SIGNATURE----- From jgarzik@pobox.com Wed Sep 15 14:24:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:24:20 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLODVk014443 for ; Wed, 15 Sep 2004 14:24:14 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7hFy-0002HF-Vh; Wed, 15 Sep 2004 22:24:03 +0100 Message-ID: <4148B2E5.50106@pobox.com> Date: Wed, 15 Sep 2004 17:23:49 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> In-Reply-To: <20040915141346.5c5e5377.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 964 Lines: 32 David S. Miller wrote: > On Wed, 15 Sep 2004 17:08:18 -0400 > Jeff Garzik wrote: > > >>There's nothing inherently wrong with sticking a computer running >>Linux inside another computer ;-) > > > And we already support that :-) > > Plus we have things like TSO too but that doesn't require a full Linux > instance to realize on a networking port. > Simple silicon implements this already. > I don't see how that differs from your "big MTU" ideas. Part of this is about how to talk to business people.... marketing. The typical definition of TOE is "offload 90+% of the net stack", as opposed to "TCP assist", which is stuff like TSO. If people ask about how to support TOE in Linux, you can say "sure, we _already_ support TOE, just stick Linux on a PCI card" rather than "no we don't support it." And wha-la, we support TOE with zero code changes ;-) Jeff, who would love to have a bunch of Athlons on PCI cards to play with. From Imran.Badr@cavium.com Wed Sep 15 14:33:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:33:33 -0700 (PDT) Received: from smtp2.cavium.com (smtp2.cavium.com [209.113.159.134]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLXQjr014851 for ; Wed, 15 Sep 2004 14:33:27 -0700 Received: from exch1.caveonetworks.com (Not Verified[192.168.14.20]) by smtp2.cavium.com with NetIQ MailMarshal (v6,0,3,8) id ; Wed, 15 Sep 2004 17:32:59 -0400 Received: from IMRANPC ([67.118.240.18]) by exch1.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Sep 2004 17:33:11 -0400 Reply-To: From: "Imran Badr" To: "Wes Felter" , Cc: Subject: Re: The ultimate TOE design Date: Wed, 15 Sep 2004 14:25:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 15 Sep 2004 21:33:11.0538 (UTC) FILETIME=[99AE9D20:01C49B6B] X-archive-position: 8887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: imran.badr@cavium.com Precedence: bulk X-list: netdev Content-Length: 2364 Lines: 62 Please see: Cavium Networks Introduces OCTEON(TM) Family of Integrated Network Services Processors With up to 16 MIPS64(R)-Based Cores for Internet Services, Content and Security Processing" http://www.linuxelectrons.com/article.php?story=20040913082030668&mode=print -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Wes Felter Sent: Wednesday, September 15, 2004 2:04 PM To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: [SPAM] Re: The ultimate TOE design Neil Horman wrote: > Paul Jakma wrote: > >> On Wed, 15 Sep 2004, Jeff Garzik wrote: >> >>> Put simply, the "ultimate TOE card" would be a card with network >>> ports, a generic CPU (arm, mips, whatever.), some RAM, and some >>> flash. This card's "firmware" is the Linux kernel, configured to run >>> as a _totally indepenent network node_, with IP address(es) all its own. >>> >>> Then, your host system OS will communicate with the Linux kernel >>> running on the card across the PCI bus, using IP packets (64K fixed >>> MTU). >> The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI >> card running Linux. Or is that what you were referring to with "> exist> but they are all fairly expensive."? > IBM's PowerNP chip was also very simmilar (a powerpc core with lots of > hardware assists for DMA and packet inspection in the extended register > area). Don't know if they still sell it, but at one time I had heard > they had booted linux on it. An IXP or PowerNP wouldn't work for Jeff's idea. The IXP's XScale core and PowerNP's PowerPC core are way too slow to do any significant processing; they are intended for control tasks like updating the routing tables. All the work in the IXP or PowerNP is done by the microengines, which have weird, non-Linux-compatible architectures. To do 10 Gbps Ethernet with Jeff's approach, wouldn't you need a 5-10 GHz processor on the card? Sounds expensive. A 440GX or BCM1250 on a cheap PCI card would be fun to play with, though. Wes Felter - wesley@felter.org - http://felter.org/wesley/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From davem@davemloft.net Wed Sep 15 14:35:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:35:19 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLZEAC015067 for ; Wed, 15 Sep 2004 14:35:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7hLC-00026V-00; Wed, 15 Sep 2004 14:29:26 -0700 Date: Wed, 15 Sep 2004 14:29:26 -0700 From: "David S. Miller" To: Jeff Garzik Cc: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-Id: <20040915142926.7bc456a4.davem@davemloft.net> In-Reply-To: <4148B2E5.50106@pobox.com> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <4148B2E5.50106@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 543 Lines: 15 On Wed, 15 Sep 2004 17:23:49 -0400 Jeff Garzik wrote: > The typical definition of TOE is "offload 90+% of the net stack", as > opposed to "TCP assist", which is stuff like TSO. I think a better goal is "offload 90+% of the net stack cost" which is effectively what TSO does on the send side. This is why these discussions are so circular. If we want to discuss something specific, like receive offload schemes, that is a very different matter. And I'm sure folks like Rusty have a lot to contribute in this area :-) From linux-netdev@gmane.org Wed Sep 15 14:35:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:35:54 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLZmro015261 for ; Wed, 15 Sep 2004 14:35:49 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7hRC-0003Ug-00 for ; Wed, 15 Sep 2004 23:35:38 +0200 Received: from pixpat.austin.ibm.com ([192.35.232.241]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2004 23:35:38 +0200 Received: from wesley by pixpat.austin.ibm.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2004 23:35:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Wes Felter Subject: Re: The ultimate TOE design Date: Wed, 15 Sep 2004 16:35:31 -0500 Message-ID: References: <4148991B.9050200@pobox.com> <4148A561.5070401@redhat.com> <20040915211543.GA23906@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pixpat.austin.ibm.com User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en In-Reply-To: <20040915211543.GA23906@havoc.gtf.org> Cc: linux-kernel@vger.kernel.org X-archive-position: 8889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wesley@felter.org Precedence: bulk X-list: netdev Content-Length: 610 Lines: 19 Jeff Garzik wrote: > On Wed, Sep 15, 2004 at 04:03:57PM -0500, Wes Felter wrote: > >>To do 10 Gbps Ethernet with Jeff's approach, wouldn't you need a 5-10 >>GHz processor on the card? Sounds expensive. > > > Do you need a 5-10 Ghz Intel server to handle 10 Gbps ethernet? Yes. (Or a 4-way ~2GHz server.) When the fastest general-purpose processors cannot handle the fastest Ethernet links, putting such a processor on a NIC won't help much. I think this is why people are attracted to TOE ASICs, even if that isn't the right solution. -- Wes Felter - wesley@felter.org - http://felter.org/wesley/ From dsaxena@plexity.net Wed Sep 15 14:36:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:36:26 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLaHwr015519 for ; Wed, 15 Sep 2004 14:36:18 -0700 Received: from plexity.net (c-24-20-152-76.client.comcast.net[24.20.152.76]) by comcast.net (sccrmhc11) with ESMTP id <2004091521360101100hrp2oe>; Wed, 15 Sep 2004 21:36:02 +0000 Received: by plexity.net (Postfix, from userid 1025) id 0A3C52185CD; Wed, 15 Sep 2004 14:36:01 -0700 (PDT) Date: Wed, 15 Sep 2004 14:36:00 -0700 From: Deepak Saxena To: Paul Jakma Cc: Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design Message-ID: <20040915213600.GA12153@plexity.net> Reply-To: dsaxena@plexity.net References: <4148991B.9050200@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Plexity Networks User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 8890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dsaxena@plexity.net Precedence: bulk X-list: netdev Content-Length: 1365 Lines: 32 On Sep 15 2004, at 21:04, Paul Jakma was caught saying: > On Wed, 15 Sep 2004, Jeff Garzik wrote: > > >Put simply, the "ultimate TOE card" would be a card with network ports, a > >generic CPU (arm, mips, whatever.), some RAM, and some flash. This card's > >"firmware" is the Linux kernel, configured to run as a _totally indepenent > >network node_, with IP address(es) all its own. > > > >Then, your host system OS will communicate with the Linux kernel running > >on the card across the PCI bus, using IP packets (64K fixed MTU). > > >My dream is that some vendor will come along and implement such a > >design, and sell it in enough volume that it's US$100 or less. > >There are a few cards on the market already where implementing this > >design _may_ be possible, but they are all fairly expensive. > > The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI > card running Linux. Or is that what you were referring to with > " but they are all fairly expensive."? Unfortunately all the SW that lets one make use of the interesting features of the IXPs (microEngines, crypto, etc) is a pile of propietary code. ~Deepak -- Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/ "Unlike me, many of you have accepted the situation of your imprisonment and will die here like rotten cabbages." - Number 6 From jheffner@psc.edu Wed Sep 15 14:36:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:36:38 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLaWSc015618 for ; Wed, 15 Sep 2004 14:36:32 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8FLaJpY022298 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Sep 2004 17:36:19 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8FLaIMe008837; Wed, 15 Sep 2004 17:36:18 -0400 (EDT) Date: Wed, 15 Sep 2004 17:36:18 -0400 (EDT) From: John Heffner To: Netdev cc: Subject: Re: The ultimate TOE design In-Reply-To: <4148991B.9050200@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 8891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1420 Lines: 30 My view on TOE is that it is brought up in response to the fact that when leading edge network technologies are brought out (GigE a few years ago, 10 GigE now), hosts can't keep up. Specifically, these people usually don't care about wasting their man CPU cycles, but rather the fact they can't get the full rate out of their expensive new NIC. The reason hosts can't keep up are (a) host bus speeds, or (not exclusive) (b) the CPU can't handle per-packet processing In the case of (a), TOE doesn't really help. In the case of (b), Jeff's proposed general-purpose offload doesn't help -- you really need a custom ASIC or maybe FPGA if you hope to beat the host CPU. Thus I think Jeff's idea is not likely to fly with this crowd of TOE proponents. The other (much nicer) solution to case (b) is to just USE A BIGGER MTU. 1500 bytes is ridiculously small. Even with a 9k MTU, the benefits of TOE or TSO are nearly vanishing. Those who say they require high performance, but are unwilling to buy or produce networking gear with an MTU larger than 1500 bytes probably deserve what they get. There are other possible justifications for TOE (with other counter-arguments) -- basically to reduce load on the main CPU -- but I think these are for the most part NOT what is driving the market (let me know if I'm being myopic here). This issue is also largely or completely solved by using a bigger MTU. -John From joelja@darkwing.uoregon.edu Wed Sep 15 14:41:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:41:26 -0700 (PDT) Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLfLX3016469 for ; Wed, 15 Sep 2004 14:41:21 -0700 Received: from twin.uoregon.edu (IDENT:ERTzz4c+pKVXok6KkR3me4dObRuwy3w5@twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i8FLf5eK003794 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 15 Sep 2004 14:41:10 -0700 (PDT) Date: Wed, 15 Sep 2004 14:41:05 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: David Stevens cc: Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joelja@darkwing.uoregon.edu Precedence: bulk X-list: netdev Content-Length: 2267 Lines: 47 On Wed, 15 Sep 2004, David Stevens wrote: > I've never understood why people are so interested in off-loading > networking. Isn't that just a multi-processor system where you can't > use any of the network processor cycles for anything else? And, of > course, to be cheap, the network processor will be slower, and much > harder to debug and update software. I's like to amplify this, adding more general purpose cpu to a machine strikes me as the right design choice since they're simply more generally useful than dedicated cpu's. look at linux software raid compared to the alternatives, frankly I haven't seen a hardware controller that can touch it for performance given a similar number of disks and interfaces... Currently graphcas card have substantionaly more memory bandwidth and pipelines than most general purpose cpu's but eventually that won't be the case. as it is gpus still represent the biggest chunk of independat computational power in a and at least on the server side we don't even use them. > If the PCI bus is too slow, or MTU's too small, wouldn't > it be better to fix those directly and use a fast host processor that can > also do other things when not needed for networking? And why have > memory on a NIC that can't be used by other things? Between hyper-transport tunnels, pci-x, pci-express and infinband, the bottlnecks between the cpu core and the perhiperals and memory are falling away at a rapid clip even as cpu's get faster. we're in a much better position to build balanced systems then we were 2 years ago. > Why don't we off-load filesystems to disks instead? Or a graphics > card that implements X ? :-) I'd rather have shared system resources-- > more flexible. :-) > > +-DLS > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 From garzik@havoc.gtf.org Wed Sep 15 14:43:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:43:18 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLhDts016672 for ; Wed, 15 Sep 2004 14:43:14 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 13D967782; Wed, 15 Sep 2004 17:42:57 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8FLgvWa026080; Wed, 15 Sep 2004 17:42:57 -0400 Date: Wed, 15 Sep 2004 17:42:57 -0400 From: Jeff Garzik To: Wes Felter Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-ID: <20040915214257.GA26042@havoc.gtf.org> References: <4148991B.9050200@pobox.com> <4148A561.5070401@redhat.com> <20040915211543.GA23906@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 8893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 442 Lines: 21 On Wed, Sep 15, 2004 at 04:35:31PM -0500, Wes Felter wrote: > Jeff Garzik wrote: > > >On Wed, Sep 15, 2004 at 04:03:57PM -0500, Wes Felter wrote: > > > >>To do 10 Gbps Ethernet with Jeff's approach, wouldn't you need a 5-10 > >>GHz processor on the card? Sounds expensive. > > > > > >Do you need a 5-10 Ghz Intel server to handle 10 Gbps ethernet? > > Yes. (Or a 4-way ~2GHz server.) It was a rhetoric question. No, you don't. Jeff From eric.lemoine@gmail.com Wed Sep 15 14:43:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:43:32 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLhQ9E016755 for ; Wed, 15 Sep 2004 14:43:27 -0700 Received: by mproxy.gmail.com with SMTP id 77so271758rnk for ; Wed, 15 Sep 2004 14:43:16 -0700 (PDT) Received: by 10.38.96.12 with SMTP id t12mr999342rnb; Wed, 15 Sep 2004 14:43:16 -0700 (PDT) Received: by 10.38.99.58 with HTTP; Wed, 15 Sep 2004 14:43:16 -0700 (PDT) Message-ID: <5cac192f04091514433c9e13c8@mail.gmail.com> Date: Wed, 15 Sep 2004 23:43:16 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: "David S. Miller" Subject: Re: [SUNGEM] LLTX support Cc: netdev@oss.sgi.com In-Reply-To: <20040915083559.6c36759f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_159_24512419.1095284596697" References: <5cac192f04091423453ae3cb@mail.gmail.com> <20040915083559.6c36759f.davem@davemloft.net> X-archive-position: 8894 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 3083 Lines: 58 ------=_Part_159_24512419.1095284596697 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, 15 Sep 2004 08:35:59 -0700, David S. Miller wrote: > On Wed, 15 Sep 2004 08:45:21 +0200 > Eric Lemoine wrote: > > > The attached patch adds LLTX support to SunGEM NAPI. The tx_lock patch > > I just sent must be applied first. > > Also applied, thanks Eric. > > I remember you mentioning yesterday that Harald's sungem NAPI > patch had netpoll support, can you cook up a patch that adds > it for current sungem? Patch attached. Unlike Harald's, this patch doesn't disable_irq before calling gem_interrupt because gem_interrupt is safe to reentrance. Hopefully this is correct... -- Eric ------=_Part_159_24512419.1095284596697 Content-Type: application/octet-stream; name="rset-sungem_netpoll-2-6-9-rc1.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rset-sungem_netpoll-2-6-9-rc1.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMTUgMjM6Mzc6MjQrMDI6MDAgZXJpYy5sZW1vaW5lQGdt YWlsLmNvbSAKIyAgIFtTVU5HRU1dIG5ldHBvbGwgc3VwcG9ydAojICAgCiMgICBTaWduZWQtb2Zm LWJ5OiBFcmljIExlbW9pbmUgPGVyaWMubGVtb2luZUBnbWFpbC5jb20+CiMgCiMgZHJpdmVycy9u ZXQvc3VuZ2VtLmMKIyAgIDIwMDQvMDkvMTUgMjM6Mzc6MTUrMDI6MDAgZXJpYy5sZW1vaW5lQGdt YWlsLmNvbSArMTYgLTAKIyAgIFtTVU5HRU1dIG5ldHBvbGwgc3VwcG9ydAojICAgCiMgICBTaWdu ZWQtb2ZmLWJ5OiBFcmljIExlbW9pbmUgPGVyaWMubGVtb2luZUBnbWFpbC5jb20+CiMgCmRpZmYg LU5ydSBhL2RyaXZlcnMvbmV0L3N1bmdlbS5jIGIvZHJpdmVycy9uZXQvc3VuZ2VtLmMKLS0tIGEv ZHJpdmVycy9uZXQvc3VuZ2VtLmMJMjAwNC0wOS0xNSAyMzozODoxMiArMDI6MDAKKysrIGIvZHJp dmVycy9uZXQvc3VuZ2VtLmMJMjAwNC0wOS0xNSAyMzozODoxMiArMDI6MDAKQEAgLTUsNiArNSw5 IEBACiAgKiAKICAqIFN1cHBvcnQgZm9yIEFwcGxlIEdNQUMgYW5kIGFzc29ydGVkIFBIWXMgYnkK ICAqIEJlbmphbWluIEhlcnJlbnNjbWlkdCAoYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnKQorICoK KyAqIE5BUEkgYW5kIE5FVFBPTEwgc3VwcG9ydAorICogKEMpIDIwMDQgYnkgRXJpYyBMZW1vaW5l IChlcmljLmxlbW9pbmVAZ21haWwuY29tKQogICogCiAgKiBUT0RPOiAKICAqICAtIEdldCByaWQg b2YgYWxsIHRob3NlIG5hc3R5IG1kZWxheSdzIGFuZCByZXBsYWNlIHRoZW0KQEAgLTg5OCw2ICs5 MDEsMTYgQEAKIAlyZXR1cm4gSVJRX0hBTkRMRUQ7CiB9CiAKKyNpZmRlZiBDT05GSUdfTkVUX1BP TExfQ09OVFJPTExFUgorc3RhdGljIHZvaWQgZ2VtX3BvbGxfY29udHJvbGxlcihzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2KQoreworCS8qIGdlbV9pbnRlcnJ1cHQgaXMgc2FmZSB0byByZWVudHJhbmNl IHNvIG5vIG5lZWQKKwkgKiB0byBkaXNhYmxlX2lycSBoZXJlLgorCSAqLworCWdlbV9pbnRlcnJ1 cHQoZGV2LT5pcnEsIGRldiwgTlVMTCk7Cit9CisjZW5kaWYKKwogc3RhdGljIHZvaWQgZ2VtX3R4 X3RpbWVvdXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldikKIHsKIAlzdHJ1Y3QgZ2VtICpncCA9IGRl di0+cHJpdjsKQEAgLTI5MzQsNiArMjk0Nyw5IEBACiAJZGV2LT5jaGFuZ2VfbXR1ID0gZ2VtX2No YW5nZV9tdHU7CiAJZGV2LT5pcnEgPSBwZGV2LT5pcnE7CiAJZGV2LT5kbWEgPSAwOworI2lmZGVm IENPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVSCisgICAgICAgIGRldi0+cG9sbF9jb250cm9sbGVy ID0gZ2VtX3BvbGxfY29udHJvbGxlcjsKKyNlbmRpZgogCiAJaWYgKHJlZ2lzdGVyX25ldGRldihk ZXYpKSB7CiAJCXByaW50ayhLRVJOX0VSUiBQRlggIkNhbm5vdCByZWdpc3RlciBuZXQgZGV2aWNl LCAiCg== ------=_Part_159_24512419.1095284596697-- From davem@davemloft.net Wed Sep 15 14:49:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:49:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLn6Y8017524 for ; Wed, 15 Sep 2004 14:49:06 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C7hbc-00029W-00; Wed, 15 Sep 2004 14:46:24 -0700 Date: Wed, 15 Sep 2004 14:46:24 -0700 From: "David S. Miller" To: John Heffner Cc: netdev@oss.sgi.com, leonid.grossman@s2io.com Subject: Re: The ultimate TOE design Message-Id: <20040915144624.1339fbc5.davem@davemloft.net> In-Reply-To: References: <4148991B.9050200@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 504 Lines: 12 On Wed, 15 Sep 2004 17:36:18 -0400 (EDT) John Heffner wrote: > The other (much nicer) solution to case (b) is to just USE A BIGGER MTU. > 1500 bytes is ridiculously small. Even with a 9k MTU, the benefits of TOE > or TSO are nearly vanishing. Those who say they require high performance, > but are unwilling to buy or produce networking gear with an MTU larger > than 1500 bytes probably deserve what they get. TSO gives a kind of virtual 64K MTU, FWIW. But I do see your point. From tony.p.lee@gmail.com Wed Sep 15 14:59:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 14:59:28 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FLxLTH018321 for ; Wed, 15 Sep 2004 14:59:22 -0700 Received: by mproxy.gmail.com with SMTP id 76so189020rnk for ; Wed, 15 Sep 2004 14:59:03 -0700 (PDT) Received: by 10.38.125.33 with SMTP id x33mr838441rnc; Wed, 15 Sep 2004 14:59:03 -0700 (PDT) Received: by 10.38.165.50 with HTTP; Wed, 15 Sep 2004 14:59:03 -0700 (PDT) Message-ID: <470b63970409151459635625f5@mail.gmail.com> Date: Wed, 15 Sep 2004 14:59:03 -0700 From: Tony Lee Reply-To: Tony Lee To: Paul Jakma Subject: Re: The ultimate TOE design Cc: Netdev , leonid.grossman@s2io.com, Linux Kernel In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4148991B.9050200@pobox.com> X-archive-position: 8896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tony.p.lee@gmail.com Precedence: bulk X-list: netdev Content-Length: 1807 Lines: 50 On Wed, 15 Sep 2004 21:04:38 +0100 (IST), Paul Jakma wrote: > On Wed, 15 Sep 2004, Jeff Garzik wrote: > > > Put simply, the "ultimate TOE card" would be a card with network ports, a > > generic CPU (arm, mips, whatever.), some RAM, and some flash. This card's > > "firmware" is the Linux kernel, configured to run as a _totally indepenent > > network node_, with IP address(es) all its own. > > > > Then, your host system OS will communicate with the Linux kernel running on > > the card across the PCI bus, using IP packets (64K fixed MTU). > > > My dream is that some vendor will come along and implement such a > > design, and sell it in enough volume that it's US$100 or less. > > There are a few cards on the market already where implementing this > > design _may_ be possible, but they are all fairly expensive. > > The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI > card running Linux. Or is that what you were referring to with > " but they are all fairly expensive."? > > > Jeff > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A I believe Broadcom 5704 (570x) chip/nic card come with 2 MIPS CPUs (133 MHz) one each for both Tx and Rx data path. The GIGE nic card cost < $50 couple years ago. Too bad, the software SDK for them is closed (quoted at $96K couple years ago) . Otherwise, there can be some interesting applications with that extremely inexpensive chip/nic card. RDMA over TCP/UDP with that chip/nic card over gige can be very interesting. so is SSL proxy, SSH tunnel, etc. With the right distributing processing design, it might even possible to offload SMB, NFS to the "right" nic card. -Tony -- Having fun with Xilinx Virtex Pro II reconfigurable HW + integrated PPC + Linux From rusty@rustcorp.com.au Wed Sep 15 15:17:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 15:17:55 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FMHlj3018908 for ; Wed, 15 Sep 2004 15:17:48 -0700 Received: from bach (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 5AFDA2BD6A; Thu, 16 Sep 2004 08:17:30 +1000 (EST) Subject: Re: [PATCH 2.6] ip_nat_ftp - manip at the right place From: Rusty Russell To: "David S. Miller" Cc: Julian Anastasov , Harald Welte , netdev@oss.sgi.com In-Reply-To: <20040913163002.35aae28c.davem@davemloft.net> References: <20040913163002.35aae28c.davem@davemloft.net> Content-Type: text/plain Message-Id: <1095286400.1940.8.camel@bach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 08:13:20 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 8897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev Content-Length: 982 Lines: 28 On Tue, 2004-09-14 at 09:30, David S. Miller wrote: > On Sat, 11 Sep 2004 10:53:53 +0300 (EEST) > Julian Anastasov wrote: > > > This is a resend/resync for v2.6.9-rc1-bk17: change the > > way the ip_nat_ftp helper manipulates the packets: > > > > - no manips => no fixup > > > > - check the direction, do manip once and at the same time when the > > headers are changed > > > > This is needed mostly for IPVS setups and I hope we do not > > create troubles for other setups or FTP software. > > I'm still waiting for ACK/NACK of this. I know Rusty is travelling > and Harald is probably busy too, so I know the delay in response is not > because these guys are slackers :-) Mine is because I'm porting the existing FTP testsuite to nfsim, so I can test the patch doesn't break anything. As far as I can tell, this change isn't vital, so I'm not losing sleep to do it... Thanks, Rusty. -- Anyone who quotes me in their signature is an idiot -- Rusty Russell From jgarzik@pobox.com Wed Sep 15 15:27:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 15:27:14 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FMR8C5019350 for ; Wed, 15 Sep 2004 15:27:08 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7iEq-0003wa-Rb; Wed, 15 Sep 2004 23:26:57 +0100 Message-ID: <4148C1A2.2030309@pobox.com> Date: Wed, 15 Sep 2004 18:26:42 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <4148B2E5.50106@pobox.com> <20040915142926.7bc456a4.davem@davemloft.net> In-Reply-To: <20040915142926.7bc456a4.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 718 Lines: 24 David S. Miller wrote: > On Wed, 15 Sep 2004 17:23:49 -0400 > Jeff Garzik wrote: > > >>The typical definition of TOE is "offload 90+% of the net stack", as >>opposed to "TCP assist", which is stuff like TSO. > > > I think a better goal is "offload 90+% of the net stack cost" which > is effectively what TSO does on the send side. A better goal is to not bother with TOE at all, and just get multi-core processors with huge memory bandwidth :) Again, the point of my message is to have something _positive_ to tell people when they specifically asked about TOE. Rather than "no, we'll never do TOE" we have "it's possible, but there are better questions you should be asking" Jeff From jgarzik@pobox.com Wed Sep 15 15:31:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 15:31:41 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FMVZCh019718 for ; Wed, 15 Sep 2004 15:31:35 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C7iJB-00042e-3h; Wed, 15 Sep 2004 23:31:25 +0100 Message-ID: <4148C2B0.20504@pobox.com> Date: Wed, 15 Sep 2004 18:31:12 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> In-Reply-To: <20040915141346.5c5e5377.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 440 Lines: 14 David S. Miller wrote: > Plus we have things like TSO too but that doesn't require a full Linux > instance to realize on a networking port. > Simple silicon implements this already. > I don't see how that differs from your "big MTU" ideas. WRT MTU: if the card is a buffering endpoint, rather than a passthrough, the card deals with Path MTU and fragmentation, leaving the card<->host MTU at 64K, getting nice big fat frames. Jeff From paul@clubi.ie Wed Sep 15 16:04:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:04:12 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FN441r020589 for ; Wed, 15 Sep 2004 16:04:05 -0700 Received: from fogarty.jakma.org (fogarty.jakma.org [212.17.55.50]) by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id i8FN3o46026727; Thu, 16 Sep 2004 00:03:53 +0100 Date: Thu, 16 Sep 2004 00:03:48 +0100 (IST) From: Paul Jakma X-X-Sender: paul@fogarty.jakma.org To: Deepak Saxena cc: Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design In-Reply-To: <20040915213600.GA12153@plexity.net> Message-ID: References: <4148991B.9050200@pobox.com> <20040915213600.GA12153@plexity.net> X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@clubi.ie Precedence: bulk X-list: netdev Content-Length: 507 Lines: 18 On Wed, 15 Sep 2004, Deepak Saxena wrote: > Unfortunately all the SW that lets one make use of the interesting > features of the IXPs (microEngines, crypto, etc) is a pile of > propietary code. My vague understanding is that while Intel's microengine code is proprietary, they do provide the docs to the microengines to let you write your own, no? > ~Deepak regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Better tried by twelve than carried by six. -- Jeff Cooper From paul@clubi.ie Wed Sep 15 16:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:06:05 -0700 (PDT) Received: from hibernia.jakma.org (hibernia.jakma.org [212.17.55.49]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FN5xQM020809 for ; Wed, 15 Sep 2004 16:06:00 -0700 Received: from fogarty.jakma.org (fogarty.jakma.org [212.17.55.50]) by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id i8FN5k4H026747; Thu, 16 Sep 2004 00:05:47 +0100 Date: Thu, 16 Sep 2004 00:05:44 +0100 (IST) From: Paul Jakma X-X-Sender: paul@fogarty.jakma.org To: Alan Cox cc: Netdev , leonid.grossman@s2io.com, Linux Kernel Mailing List Subject: Re: The ultimate TOE design In-Reply-To: <1095275660.20569.0.camel@localhost.localdomain> Message-ID: References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paul@clubi.ie Precedence: bulk X-list: netdev Content-Length: 568 Lines: 19 On Wed, 15 Sep 2004, Alan Cox wrote: > Last time I checked 2Ghz accelerators for intel and AMD were quite > cheap and also had the advantage they ran user mode code when idle > from network processing. Indeed. Unfortunately though, my vague understanding is, the interesting bits on the IXP, the microengines, are integrated with the XScale ASIC. I agree it's silly to stick a general purpose CPU in there, but you get it for "free" anyway. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: War is an equal opportunity destroyer. From romieu@fr.zoreil.com Wed Sep 15 16:11:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:11:32 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FNBPgf021310 for ; Wed, 15 Sep 2004 16:11:26 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8FN9avr027133; Thu, 16 Sep 2004 01:09:37 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8FN9ab3027132; Thu, 16 Sep 2004 01:09:36 +0200 Date: Thu, 16 Sep 2004 01:09:36 +0200 From: Francois Romieu To: Hans-Frieder Vogt Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040915230936.GA24467@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <20040913220209.GA13175@electric-eye.fr.zoreil.com> <200409140131.11927.hfvogt@arcor.de> <200409160040.03532.hfvogt@arcor.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <200409160040.03532.hfvogt@arcor.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1706 Lines: 53 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hans-Frieder Vogt : [...] [...] > Of course x86-64 has the address-space that enables >4GB RAM, and x86-64 > always supports DAC (as stated in include/asm-x86_64/pci.h), but I have > currently only 1GB RAM, so, strictly speaking, DAC is not really necessary. Worse than that: r8169 in 2.6.9-rc[1/2] does not advertise its ability to DMA to high memory. > Strange enough, the latest Realtek driver 2.2 does not even support DAC (only > the lower 32 bit of the DMA-Addresses are written to the registers). > Could it be that the Realtek driver does not support DAC for a good reason? > > Anyway, I will continue searching for the problem... Can you simply try the attached patch with the network cable unplugged ? It will not fix your issue but if the result & 0x08 != 0, you can probably stop your testing for now as it will mean "known issue". -- Ueimor --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-xx0.patch" drivers/net/r8169.c | 3 +++ 1 files changed, 3 insertions(+) diff -puN drivers/net/r8169.c~r8169-xx0 drivers/net/r8169.c --- linux-2.6.9-rc1/drivers/net/r8169.c~r8169-xx0 2004-09-15 23:57:46.000000000 +0200 +++ linux-2.6.9-rc1-romieu/drivers/net/r8169.c 2004-09-16 00:59:26.000000000 +0200 @@ -1533,6 +1533,9 @@ rtl8169_hw_start(struct net_device *dev) /* Enable all known interrupts by setting the interrupt mask. */ RTL_W16(IntrMask, rtl8169_intr_mask); + printk(KERN_INFO PFX + "%s: Config2 = 0x%02x\n", dev->name, RTL_R8(Config2)); + netif_start_queue(dev); } _ --X1bOJ3K7DJ5YkBrT-- From jmorris@redhat.com Wed Sep 15 16:16:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:16:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FNGRX4021802 for ; Wed, 15 Sep 2004 16:16:28 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8FNGHil024168; Wed, 15 Sep 2004 19:16:17 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8FNGHr11719; Wed, 15 Sep 2004 19:16:17 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8FNGHiS019705; Wed, 15 Sep 2004 19:16:17 -0400 Date: Wed, 15 Sep 2004 19:16:16 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: John Heffner cc: Netdev , Subject: Re: The ultimate TOE design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 366 Lines: 16 On Wed, 15 Sep 2004, John Heffner wrote: > The other (much nicer) solution to case (b) is to just USE A BIGGER MTU. > 1500 bytes is ridiculously small. Even with a 9k MTU, the benefits of TOE > or TSO are nearly vanishing. Do you have any figures on (large) MTU size vs performance on a current commidity system? - James -- James Morris From rddunlap@osdl.org Wed Sep 15 16:23:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:23:13 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FNN8pB025375 for ; Wed, 15 Sep 2004 16:23:08 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8FNMLv13281; Wed, 15 Sep 2004 16:22:21 -0700 Date: Wed, 15 Sep 2004 16:17:50 -0700 From: "Randy.Dunlap" To: "David S. Miller" Cc: speattle@yahoo.com, netdev@oss.sgi.com Subject: Re: [PATCH] linux 2.6.x.x - include/net/neighbour.h spell-check Message-Id: <20040915161750.69016175.rddunlap@osdl.org> In-Reply-To: <20040913162724.7a6f2213.davem@davemloft.net> References: <20040913174842.96183.qmail@web90003.mail.scd.yahoo.com> <20040913162724.7a6f2213.davem@davemloft.net> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 676 Lines: 22 On Mon, 13 Sep 2004 16:27:24 -0700 David S. Miller wrote: | On Mon, 13 Sep 2004 10:48:39 -0700 (PDT) | S P wrote: | | > in linux 2.6.x.x kernel's include/net/neighbour.h | > 'Neighbour' and 'Neighbor' are used interchangeably. | > | > neighbour is british variation of neighbor, so i'd say | > neighbor is more appropriate. but then the header's | > named neighbour. | | Does anyone remember what happened on linux-kernel when | the similar case of American English "color" vs. British | English "colour" was being debated? | | In any event, whatever we decide we should do tree-wide. I don't recall any mass changes from -our to -or. -- ~Randy From leonid.grossman@s2io.com Wed Sep 15 16:30:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:30:54 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FNUjOn025747 for ; Wed, 15 Sep 2004 16:30:46 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8FNTtje010903; Wed, 15 Sep 2004 19:29:55 -0400 (EDT) Received: from lgt40 ([10.16.16.152]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8FNTsqG025184; Wed, 15 Sep 2004 19:29:54 -0400 (EDT) Message-Id: <200409152329.i8FNTsqG025184@guinness.s2io.com> From: "Leonid Grossman" To: "'David S. Miller'" , "'Jeff Garzik'" Cc: , , , Subject: RE: The ultimate TOE design Date: Wed, 15 Sep 2004 16:29:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSba93oeMQT0vylSiqa+KzHVJsgAQABuSwQ In-Reply-To: <20040915142926.7bc456a4.davem@davemloft.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 2584 Lines: 65 I think Jeff's "ultimate TOE card" based upon generic embedded CPU is doable at GbE, but we may not see such a product because it's too late for it to succeed. TOE is a pretty questionable product in itself; one of the main reasons people build TOE cards is to put RDMA on top of it and end up with an RNIC (NIC+TOE+RDMA) Ethernet card. The hope is to eventually run all three types of server traffic (network, storage, IPC) over an RNIC, and get rid of two other HBAs in a system. For this "fabric conversion" over Ethernet to happen it has to be at 10GbE not GbE, since storage (FiberChannel) is already at 4Gb. And at 10GbE, embedded CPUs just don't cut it - it has to be custom ASIC (granted, with some means to simplify debugging and reduce the risk of hw bugs and TCP changes). On some other points on the thread: WRT the TOE price, I suspect that when RNICs come out they will command little premium over conventional NICs - it will be just a technology upgrade. WRT larger MTU - going to bigger MTUs helps a lot, but it will be years before the infrastructure moves beyond 9600 byte MTU. Even right now, usage of 9600 byte Jumbos is not universal. WRT TSO, for applications that don't require RDMA TSO indeed helps a lot on the transmit side for 1500 MTU - 10GbE cards are innevitably CPU bound, and we are seeing ~3x throughput improvement with normal frames. This leaves receive offload schemes in Linux as a biggest improvement (short of supporting TOE) to make. It will be great to see such receive schemes defined and implemented, as I stated in an earlier thread we will be willing to participate in such work and put the support in S2io 10GbE ASIC and drivers. > -----Original Message----- > From: David S. Miller [mailto:davem@davemloft.net] > Sent: Wednesday, September 15, 2004 2:29 PM > To: Jeff Garzik > Cc: alan@lxorguk.ukuu.org.uk; paul@clubi.ie; > netdev@oss.sgi.com; leonid.grossman@s2io.com; > linux-kernel@vger.kernel.org > Subject: Re: The ultimate TOE design > > On Wed, 15 Sep 2004 17:23:49 -0400 > Jeff Garzik wrote: > > > The typical definition of TOE is "offload 90+% of the net > stack", as > > opposed to "TCP assist", which is stuff like TSO. > > I think a better goal is "offload 90+% of the net stack cost" > which is effectively what TSO does on the send side. > > This is why these discussions are so circular. > > If we want to discuss something specific, like receive > offload schemes, that is a very different matter. And I'm > sure folks like Rusty have a lot to contribute in this area :-) > From leonid.grossman@s2io.com Wed Sep 15 16:37:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:37:36 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FNbUkl026172 for ; Wed, 15 Sep 2004 16:37:31 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8FNbFje010942; Wed, 15 Sep 2004 19:37:15 -0400 (EDT) Received: from lgt40 ([10.16.16.152]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8FNbDqG026335; Wed, 15 Sep 2004 19:37:14 -0400 (EDT) Message-Id: <200409152337.i8FNbDqG026335@guinness.s2io.com> From: "Leonid Grossman" To: "'James Morris'" , "'John Heffner'" Cc: "'Netdev'" Subject: RE: The ultimate TOE design Date: Wed, 15 Sep 2004 16:37:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSbegcP7sjzlZ6wTRuboNhJ31SBhgAAhlxg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 906 Lines: 37 > -----Original Message----- > From: James Morris [mailto:jmorris@redhat.com] > Sent: Wednesday, September 15, 2004 4:16 PM > To: John Heffner > Cc: Netdev; leonid.grossman@s2io.com > Subject: Re: The ultimate TOE design > > On Wed, 15 Sep 2004, John Heffner wrote: > > > The other (much nicer) solution to case (b) is to just USE > A BIGGER MTU. > > 1500 bytes is ridiculously small. Even with a 9k MTU, the > benefits of > > TOE or TSO are nearly vanishing. > > Do you have any figures on (large) MTU size vs performance on > a current commidity system? It's very system-dependent. Say on 2-way Xeon our card goes from ~2Gbps to ~6Gbps, on 64-bit systems the delta is obviously less. For 9k MTU, the delta goes down of course but it is still ~10% on 2.6 systems - say on 2-way Opterons we go from 7Gbps to 7.6Gbps. Leonid > > > - James > -- > James Morris > > > From jheffner@psc.edu Wed Sep 15 16:52:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 16:52:46 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8FNqevp027034 for ; Wed, 15 Sep 2004 16:52:41 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8FNqPpY024522 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Sep 2004 19:52:26 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8FNqPMe009599; Wed, 15 Sep 2004 19:52:25 -0400 (EDT) Date: Wed, 15 Sep 2004 19:52:25 -0400 (EDT) From: John Heffner To: James Morris cc: Netdev , Subject: Re: The ultimate TOE design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 8907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1148 Lines: 30 On Wed, 15 Sep 2004, James Morris wrote: > On Wed, 15 Sep 2004, John Heffner wrote: > > > The other (much nicer) solution to case (b) is to just USE A BIGGER MTU. > > 1500 bytes is ridiculously small. Even with a 9k MTU, the benefits of TOE > > or TSO are nearly vanishing. > > Do you have any figures on (large) MTU size vs performance on a current > commidity system? What qualifies as large? I ran some measurements out to 9k w/GigE a few years ago. (Something like 100 byte increments.) I can try to find the data if anyone is interested. I may try to run a similar experiment on 10 GigE with modern hardware, and I think these cards can go out to 16k as well. The basic idea is that the margainal benefit (in terms of CPU cycles) of increasing the MTU is proportional to log(MTU). In all experiments I have done or seen, the data agree with this, except for discontinuities due to PCI settings, page sizes and maybe a couple other things. There are some arguments that going to much larger MTUs could be of substantial benefit other than CPU cycles, but this is harder to quantify. See . -John From hadi@cyberus.ca Wed Sep 15 17:58:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 17:58:29 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G0wN1D028377 for ; Wed, 15 Sep 2004 17:58:24 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C7kbG-0006Yy-Eb for netdev@oss.sgi.com; Wed, 15 Sep 2004 20:58:14 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7kb6-0004QI-M4; Wed, 15 Sep 2004 20:58:04 -0400 Subject: Re: The ultimate TOE design From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: "David S. Miller" , alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org In-Reply-To: <4148B2E5.50106@pobox.com> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <4148B2E5.50106@pobox.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095296279.1064.80.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Sep 2004 20:57:59 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 672 Lines: 17 Jeff, You are only allowed to start a TOE thread only every six months ;-> On a serious note, I think that PCI-express (if it lives upto its expectation) will demolish dreams of a lot of these TOE investments. Our problem is NOT the CPU right now (80% idle processing 450Kpps forwarding). Bus and memory distance/latency are. If intel would get rid of the big conspiracy in the form of chipset division and just integrate the MC like AMD is, we'll be on our our way to kill TOE and a lot of the network processors (like the IXP). Dang, running Linux is more exciting than microcoding things to fit into a 2Kword program store. I rest my canadiana $.02 cheers, jamal From andrea@novell.com Wed Sep 15 18:07:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 18:07:12 -0700 (PDT) Received: from mail-relay-1.tiscali.it (mail-relay-1.tiscali.it [213.205.33.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G176KI028804 for ; Wed, 15 Sep 2004 18:07:07 -0700 Received: from dualathlon.random (217.133.42.200) by mail-relay-1.tiscali.it (7.1.021.3) id 40F404C800F24655; Thu, 16 Sep 2004 03:05:07 +0200 Received: by dualathlon.random (Postfix, from userid 500) id 8448E4496; Thu, 16 Sep 2004 03:05:09 +0200 (CEST) Date: Thu, 16 Sep 2004 03:05:09 +0200 From: Andrea Arcangeli To: "David S. Miller" Cc: Alan Cox , paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-ID: <20040916010509.GP15426@dualathlon.random> References: <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <20040915135308.78bf74f0.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915135308.78bf74f0.davem@davemloft.net> X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 User-Agent: Mutt/1.5.6i X-archive-position: 8909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrea@novell.com Precedence: bulk X-list: netdev Content-Length: 883 Lines: 16 On Wed, Sep 15, 2004 at 01:53:08PM -0700, David S. Miller wrote: > There are absolutely no justified economics in these > TOE engines. By the time you deploy them, the cpus > and memory catch up and what's more those are general > purpose and not just for networking as David Stevens > and others have said. I'm not sure if economics are the worst part of what is being shipped, to me the worst part is security, I'd never trust myself such a non-open-source TCP stack for something critical even if it was going to be much cheaper and performant. Even my PDA is using the linux tcp stack, and my cell phone only speaks UDP with the wap server anyways. TCP segment offload OTOH doesn't involve much "intelligence" in the NIC and it's very reasonable to trust it especially because all the incoming packets (the real potential offenders) are still processed by the linux tcp stack. From jmorris@redhat.com Wed Sep 15 18:43:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 18:43:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G1hqoY029591 for ; Wed, 15 Sep 2004 18:43:52 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8G1hf2x024616; Wed, 15 Sep 2004 21:43:41 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8G1hfr15089; Wed, 15 Sep 2004 21:43:41 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8G1hfiS028004; Wed, 15 Sep 2004 21:43:41 -0400 Date: Wed, 15 Sep 2004 21:43:41 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: John Heffner cc: Netdev , Subject: Re: The ultimate TOE design In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 774 Lines: 26 On Wed, 15 Sep 2004, John Heffner wrote: > > Do you have any figures on (large) MTU size vs performance on a current > > commidity system? > > What qualifies as large? I ran some measurements out to 9k w/GigE a few > years ago. (Something like 100 byte increments.) I can try to find the > data if anyone is interested. I may try to run a similar experiment on 10 > GigE with modern hardware, and I think these cards can go out to 16k as > well. Anything above 1500 bytes (up to 64k would be interesting). > There are some arguments that going to much larger MTUs could be of > substantial benefit other than CPU cycles, but this is harder to quantify. > See . Thanks for the info. - James -- James Morris From yoshfuji@linux-ipv6.org Wed Sep 15 20:59:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 20:59:33 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G3xRbM003712 for ; Wed, 15 Sep 2004 20:59:27 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 3611633CE5; Thu, 16 Sep 2004 12:59:22 +0900 (JST) Date: Thu, 16 Sep 2004 12:59:21 +0900 (JST) Message-Id: <20040916.125921.56481183.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] [IPV6] NDISC: ensure responding to NS without link-layer information. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1155 Lines: 35 Hello. When sending NA in response to NS, we may not know the link-layer address for the destination of the NA since unicast NS is not required to include its link-layer information. In this case, we first need to resolve the link-layer address. (RFC 2461 7.2.4) We now create neighbour entry for the destination and link-layer information will be automatically solved in the output path. Signed-off-by: Hideaki YOSHIFUJI Also available at . Thanks. diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-16 12:54:26 +09:00 +++ b/net/ipv6/ndisc.c 2004-09-16 12:54:26 +09:00 @@ -810,7 +810,8 @@ * update / create cache entry * for the source address */ - neigh = __neigh_lookup(&nd_tbl, saddr, dev, lladdr || !dev->addr_len); + neigh = __neigh_lookup(&nd_tbl, saddr, dev, + !inc || lladdr || !dev->addr_len); if (neigh) neigh_update(neigh, lladdr, NUD_STALE, NEIGH_UPDATE_F_WEAK_OVERRIDE| -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From leonid.grossman@s2io.com Wed Sep 15 22:27:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 22:27:26 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G5RJ4e006755 for ; Wed, 15 Sep 2004 22:27:20 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8G5Pwje012531; Thu, 16 Sep 2004 01:25:58 -0400 (EDT) Received: from lgt40 ([192.168.0.7]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8G5PtqG009228; Thu, 16 Sep 2004 01:25:55 -0400 (EDT) Message-Id: <200409160525.i8G5PtqG009228@guinness.s2io.com> From: "Leonid Grossman" To: , "'Jeff Garzik'" Cc: "'David S. Miller'" , , , , Subject: RE: The ultimate TOE design Date: Wed, 15 Sep 2004 22:25:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSbiENKKFilyoSbReWBeZCyQiJppwAIlPwg In-Reply-To: <1095296279.1064.80.camel@jzny.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 1573 Lines: 43 > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Wednesday, September 15, 2004 5:58 PM > To: Jeff Garzik > Cc: David S. Miller; alan@lxorguk.ukuu.org.uk; paul@clubi.ie; > netdev@oss.sgi.com; leonid.grossman@s2io.com; > linux-kernel@vger.kernel.org > Subject: Re: The ultimate TOE design > > Jeff, > You are only allowed to start a TOE thread only every six months ;-> > > On a serious note, I think that PCI-express (if it lives upto its > expectation) will demolish dreams of a lot of these TOE investments. > Our problem is NOT the CPU right now (80% idle processing > 450Kpps forwarding). Bus and memory distance/latency are. In servers, both bottlenecks are there - if you look at the cost of TCP and filesystem processing at 10GbE, CPU is a huge problem (and will be for foreseeable future), even for fastest 64-bit systems. I agree though that bus and memory are bigger issues, this is exactly the reason for all these RDMA over Ethernet investments :-) Anyways, did not mean to start an argument - with all the new CPU, bus and HBA technologies coming to the market it will be another 18-24 months before we know what works and what doesn't... Leonid >If > intel would get rid of the big conspiracy in the form of > chipset division and just integrate the MC like AMD is, we'll > be on our our way to kill TOE and a lot of the network > processors (like the IXP). Dang, running Linux is more > exciting than microcoding things to fit into a 2Kword program store. > > I rest my canadiana $.02 > > cheers, > jamal > From mmporter@cox.net Wed Sep 15 22:52:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 22:52:09 -0700 (PDT) Received: from fed1rmmtao01.cox.net (fed1rmmtao01.cox.net [68.230.241.38]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G5q40h007661 for ; Wed, 15 Sep 2004 22:52:04 -0700 Received: from liberty.homelinux.org ([68.2.43.39]) by fed1rmmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040916055147.OQKA22078.fed1rmmtao01.cox.net@liberty.homelinux.org>; Thu, 16 Sep 2004 01:51:47 -0400 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id WAA25903; Wed, 15 Sep 2004 22:51:29 -0700 Date: Wed, 15 Sep 2004 22:51:29 -0700 From: Matt Porter To: Neil Horman Cc: Paul Jakma , Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design Message-ID: <20040915225129.B25752@home.com> References: <4148991B.9050200@pobox.com> <4148A561.5070401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4148A561.5070401@redhat.com>; from nhorman@redhat.com on Wed, Sep 15, 2004 at 04:26:09PM -0400 X-archive-position: 8913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Content-Length: 797 Lines: 15 On Wed, Sep 15, 2004 at 04:26:09PM -0400, Neil Horman wrote: > IBM's PowerNP chip was also very simmilar (a powerpc core with lots of > hardware assists for DMA and packet inspection in the extended register > area). Don't know if they still sell it, but at one time I had heard > they had booted linux on it. Well, yes, PowerNP support has been in the kernel for years and embedded Linux distros like Mvista support them. It's no longer an IBM chip, though. AMCC purchased the PPC4xx network processors (PowerNP) from IBM and later purchased the entire standard SoC PPC4xx product line from IBM. That is, except for the PPC4xx STB chips like are found in the Hauppage MediaMVP, IBM retained those. AMCC pretty much owns all the PPC4xx line and PowerNP 405H/L are still available. -Matt From ak@suse.de Wed Sep 15 23:20:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 15 Sep 2004 23:20:55 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G6KnsG008585 for ; Wed, 15 Sep 2004 23:20:50 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 1020EBF09F3; Thu, 16 Sep 2004 08:20:34 +0200 (CEST) Date: Thu, 16 Sep 2004 08:20:33 +0200 From: Andi Kleen To: "David S. Miller" Cc: John Heffner , netdev@oss.sgi.com, leonid.grossman@s2io.com Subject: Re: The ultimate TOE design Message-ID: <20040916062033.GB12915@wotan.suse.de> References: <4148991B.9050200@pobox.com> <20040915144624.1339fbc5.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915144624.1339fbc5.davem@davemloft.net> X-archive-position: 8914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 653 Lines: 16 On Wed, Sep 15, 2004 at 02:46:24PM -0700, David S. Miller wrote: > On Wed, 15 Sep 2004 17:36:18 -0400 (EDT) > John Heffner wrote: > > > The other (much nicer) solution to case (b) is to just USE A BIGGER MTU. > > 1500 bytes is ridiculously small. Even with a 9k MTU, the benefits of TOE > > or TSO are nearly vanishing. Those who say they require high performance, > > but are unwilling to buy or produce networking gear with an MTU larger > > than 1500 bytes probably deserve what they get. > > TSO gives a kind of virtual 64K MTU, FWIW. But I do see your > point. We still need to solve the same problem for RX though. -Andi From romieu@fr.zoreil.com Thu Sep 16 00:03:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 00:03:33 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G73RDp009890 for ; Thu, 16 Sep 2004 00:03:28 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8G72Fvr000410; Thu, 16 Sep 2004 09:02:15 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8G72BR9000409; Thu, 16 Sep 2004 09:02:11 +0200 Date: Thu, 16 Sep 2004 09:02:11 +0200 From: Francois Romieu To: Hans-Frieder Vogt Cc: Jon Mason , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040916070211.GA32592@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <200409160040.03532.hfvogt@arcor.de> <20040915230936.GA24467@electric-eye.fr.zoreil.com> <200409160132.34160.hfvogt@arcor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409160132.34160.hfvogt@arcor.de> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 8915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 580 Lines: 17 Hans-Frieder Vogt : [...] > r8169: eth0: Config2 = 0x10 > > ... does not seem to be the already known issue? Anyhow, if you have more Typo of mine: it is. The BSD people have noticed some time ago that the DAC of the chipset apparently does bad things when the card is inserted in a 32 bits wide slot. Jon, if your ppc64 box offers 64 bits wide PCI slots, it would be nice if you could ttry 2.6.9-rc2-bkX, apply http://www.fr.zoreil.com/people/francois/misc/r8169-xx0.patch and report the content of the "Config2" line in the logs of the kernel. -- Ueimor From lmb@suse.de Thu Sep 16 02:03:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 02:03:56 -0700 (PDT) Received: from mx.in-addr.de (postfix@gate.in-addr.de [212.8.193.158]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G93ou7015698 for ; Thu, 16 Sep 2004 02:03:51 -0700 Received: by mx.in-addr.de (mx.in-addr.de, from userid 10) id 2F2034C18; Thu, 16 Sep 2004 11:03:39 +0200 (CEST) Received: by hermes.in-addr.de (Postfix, from userid 500) id B9226D8D; Thu, 16 Sep 2004 11:03:28 +0200 (CEST) Date: Thu, 16 Sep 2004 11:03:28 +0200 From: Lars Marowsky-Bree To: Netdev Cc: Linux Kernel Subject: Re: The ultimate TOE design Message-ID: <20040916090328.GO26852@marowsky-bree.de> References: <4148991B.9050200@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4148991B.9050200@pobox.com> X-Ctuhulu: HASTUR User-Agent: Mutt/1.5.6i X-archive-position: 8916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lmb@suse.de Precedence: bulk X-list: netdev Content-Length: 1173 Lines: 35 On 2004-09-15T15:33:47, Jeff Garzik said: > Then, your host system OS will communicate with the Linux kernel running > on the card across the PCI bus, using IP packets (64K fixed MTU). > > This effectively: Actually, given that there's almost no reason to offload TCP/IP processing for speed (better spent the money on CPU / memory for the main system), I like the idea of this for security: Off-load the packet filtering to create an additional security barrier. (Different CPU architecture and all that.) (With two cards, one could even use the conntrack fail-over internally. - A Linux-running NIC with builtin firewalling, sell to all the windows weenies... ;) With dedicated processors, maybe a IP/Sec accelerator would also be cool, but I'd think a crypto accelerator for the main system would again be saner here (unless, of course, the argument of the security domain isolation is applied again). Admittedely, one can solve all these differently, but it still might be cool. ;-) Sincerely, Lars Marowsky-Brée -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company From vnuorval@tcs.hut.fi Thu Sep 16 02:09:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 02:09:19 -0700 (PDT) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G99Dfi016135 for ; Thu, 16 Sep 2004 02:09:13 -0700 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id BAB578001F0; Thu, 16 Sep 2004 12:08:57 +0300 (EEST) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8G98vSf028697; Thu, 16 Sep 2004 12:08:57 +0300 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8G98sds028693; Thu, 16 Sep 2004 12:08:55 +0300 Date: Thu, 16 Sep 2004 12:08:54 +0300 (EEST) From: Ville Nuorvala To: Herbert Xu Cc: "David S. Miller" , YOSHIFUJI Hideaki , James Morris , netdev@oss.sgi.com Subject: [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum) In-Reply-To: <20040915020942.GA32721@gondor.apana.org.au> Message-ID: References: <20040915020942.GA32721@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 1171 Lines: 31 On Wed, 15 Sep 2004, Herbert Xu wrote: > I decided to bite the bullet and use netlink for the tunnel operations. It's great if you have the time and energy to do this! Let me know if I can be of any assistance with the ip6_tunnel.c modifications. While designing the netlink interface it might perhaps be a good idea to take a look at draft-ietf-ipv6-inet-tunnel-mib-02.txt, which is currently in IESG processing. The IPv6 specific tunnel encapsulation limit (below) is still missing from the draft but will be included in the RFC. tunnelIfEncapsLimit OBJECT-TYPE SYNTAX Integer32 (-1 | 0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of additional encapsulations permitted for packets undergoing encapsulation at this node. A value of -1 indicates that no limit is present (except as a result of the packet size)." REFERENCE "RFC 2473, section 4.1.1" ::= { tunnelIfEntry 11 } Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From ltd@cisco.com Thu Sep 16 02:30:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 02:30:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G9U27r016872 for ; Thu, 16 Sep 2004 02:30:03 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 16 Sep 2004 02:33:53 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8G9TiwW020973; Thu, 16 Sep 2004 02:29:44 -0700 (PDT) Received: from ltd-t30.cisco.com (syd-vpn-client-254-122.cisco.com [10.66.254.122]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXE11646; Thu, 16 Sep 2004 02:28:29 -0700 (PDT) Message-Id: <5.1.0.14.2.20040916192213.04240008@171.71.163.14> X-Sender: ltd@171.71.163.14 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 Sep 2004 19:29:43 +1000 To: Jeff Garzik , "David S. Miller" From: Lincoln Dale Subject: Re: The ultimate TOE design Cc: alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, linux-kernel@vger.kernel.org In-Reply-To: <4148B2E5.50106@pobox.com> References: <20040915141346.5c5e5377.davem@davemloft.net> <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltd@cisco.com Precedence: bulk X-list: netdev Content-Length: 1319 Lines: 37 not that i disagree with the general idea and rationale, but reality is what it is today for some reasons: At 07:23 AM 16/09/2004, Jeff Garzik wrote: > Jeff, who would love to have a bunch of Athlons > on PCI cards to play with. . . . this ignore the realities of power restrictions of PCI today . . . sure, one could create a PCI card that takes a power-connector, but that don't scale so well either . . . At 07:29 AM 16/09/2004, David S. Miller wrote: >I think a better goal is "offload 90+% of the net stack cost" which >is effectively what TSO does on the send side. > >This is why these discussions are so circular. TSO works on LAN-like environments (zero latency, minimal drop), it doesn't work so well across the internet . . . i believe that there are better alternatives than TSO, but it involves NICs having decent scatter-gather DMA engines and being able to be handled multiple transactions (packets/frames) at once. in theory, NICs like tg2/tg3 should be capable of implementing something like this -- if one could get to the ucode on the embedded cores. at least with PCI Express the general architecture of a PC starts to have a hope of keeping up with Moore's law. the same couldn't be said prior to DDR-SDRAM and higher front-side-bus frequencies. cheers, lincoln. From hadi@cyberus.ca Thu Sep 16 02:58:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 02:58:21 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8G9wEeX019532 for ; Thu, 16 Sep 2004 02:58:15 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C7t1c-00058S-W4 for netdev@oss.sgi.com; Thu, 16 Sep 2004 05:58:00 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7t1Y-0005s3-2f; Thu, 16 Sep 2004 05:57:56 -0400 Subject: RE: The ultimate TOE design From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: "'Jeff Garzik'" , "'David S. Miller'" , alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <200409160525.i8G5PtqG009228@guinness.s2io.com> References: <200409160525.i8G5PtqG009228@guinness.s2io.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095328673.1063.130.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Sep 2004 05:57:54 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4253 Lines: 119 On Thu, 2004-09-16 at 01:25, Leonid Grossman wrote: > > > -----Original Message----- > > From: jamal [mailto:hadi@cyberus.ca] > > On a serious note, I think that PCI-express (if it lives upto its > > expectation) will demolish dreams of a lot of these TOE investments. > > Our problem is NOT the CPU right now (80% idle processing > > 450Kpps forwarding). Bus and memory distance/latency are. > > In servers, both bottlenecks are there - if you look at the cost of TCP and > filesystem processing at 10GbE, CPU is a huge problem (and will be for > foreseeable future), even for fastest 64-bit systems. True, but with the bus contention being a non-issue you got more of that xeon being available for use (lets say i can use 50% more of its capacity then i can do more). IOW, it becomes a compute capacity problem mostly - one that you should in theory be able to throw more CPU at. SMT (the way power5 and some of the network processors do it[1]) should go a long way to address both additional compute and hardware threading to work around memory latencies. With PCI-express, compute power in mini-clustering in the form of AS (http://www.asi-sig.org/home) is being plotted as we speak. To sumarize: The problem to solve in 24 months maybe 100Gige. > I agree though that bus and memory are bigger issues, this is exactly the > reason for all these RDMA over Ethernet investments :-) And AS does a damn good job at specing all those RDMA requirements; my view is that intel is going to build them chips - so it can be done on a $5 board off the pacific rim. This takes most of the small players out of the market. > Anyways, did not mean to start an argument - with all the new CPU, bus and > HBA technologies coming to the market it will be another 18-24 months before > we know what works and what doesn't... Agreed. Would you like to invest on something that will obsoleted in 18-24 months though? OR even not obsoleted, but holds that uncertainty? I think thats the risk facing you when you are in the offload bussiness. Here are results for Hifn 7956 ref board on 2.6GHz P4 (HT) system, kernel 2.6.6 SMP as compared to a s/ware only setup on same machine. [Name of tester withheld to protect privacy]. first column - algo, second - packet size, third - time in us spend by hw crypto, forth - time in us spent by sw crypto: des 64: 28 3 des 128: 29 6 des 192: 33 9 des 256: 33 12 des 320: 37 15 des 384: 38 18 des 448: 41 21 des 512: 42 23 des 576: 45 26 des 640: 46 29 des 704: 49 33 des 768: 50 35 des 832: 53 38 des 896: 54 41 des 960: 57 44 des 1024: 58 47 des 1088: 61 50 des 1152: 62 53 des 1216: 66 56 des 1280: 66 59 des 1344: 70 62 des 1408: 71 65 des 1472: 74 68 des3_ede 64: 28 6 des3_ede 128: 30 13 des3_ede 192: 34 20 des3_ede 256: 43 26 des3_ede 320: 38 33 des3_ede 384: 48 40 des3_ede 448: 44 45 des3_ede 512: 54 53 des3_ede 576: 50 60 des3_ede 640: 59 67 des3_ede 704: 55 74 des3_ede 768: 66 78 des3_ede 832: 61 85 des3_ede 896: 72 94 des3_ede 960: 67 100 des3_ede 1024: 77 107 des3_ede 1088: 73 114 des3_ede 1152: 82 121 des3_ede 1216: 79 127 des3_ede 1280: 88 128 des3_ede 1344: 84 135 des3_ede 1408: 94 147 des3_ede 1472: 90 153 aes 64: 28 2 aes 192: 33 6 aes 320: 37 10 aes 448: 46 15 aes 576: 53 19 aes 704: 53 23 aes 832: 65 28 aes 960: 66 32 aes 1088: 71 37 aes 1216: 80 41 aes 1344: 83 45 aes 1472: 92 50 Moral of the data above: The 2.6Ghz is already showing signs of obsoleting the hifn crypto offloader[2]. I think it took less than a year for it to happen. cheers, jamal [1] I also like the MIPS.com approach to SMT [2] There are actually issues with some of the crypto offloading in Linux; however this does serve as a good example. From johnpol@2ka.mipt.ru Thu Sep 16 03:47:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 03:47:08 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GAktuW021320 for ; Thu, 16 Sep 2004 03:46:56 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i8GAkdxm011434; Thu, 16 Sep 2004 14:46:39 +0400 Subject: Kernel connector - userspace <-> kernelspace "linker". From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: netdev@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mcQn/wn0/BKtRO/PaPc5" Organization: MIPT Message-Id: <1095331899.18219.58.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 16 Sep 2004 14:51:39 +0400 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on dea.vocord.com X-Virus-Status: Clean X-archive-position: 8920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 34380 Lines: 509 --=-mcQn/wn0/BKtRO/PaPc5 Content-Type: multipart/mixed; boundary="=-cgNL2/x9Za/yEgPSnppb" --=-cgNL2/x9Za/yEgPSnppb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hmm, do not know how to describe...=20 Kind of mega-picture can be found at=20 http://tservice.net.ru/~s0mbre/?section=3Dgallery&item=3Dconnector_design This driver adds possibility to connect anything with anything using netlink based network. One must register callback and identificator. When driver receives special netlink message with appropriate identificator, appropriate callback will be called. I think that the code better explains what I'm trying to say. cn_queue.[ch] - main queue processing routings. connector.[ch] - interface to the external modules. ucon.c - userspace daemon. It is broken a bit, but the main idea is=20 very clear. cn_test.c - module to test new connector. Makefile - it will link all above cruft. Origianlly this was written for SuperIO and w1 subsystems to connect=20 them to userspace, but actually it can be used outside those projects. Greg KH recommended to send it to linux-kernl@ mail list, but I personally=20 no not like that too "floodfil" list. Please review and comment. --=20 Evgeniy Polyakov Crash is better than data corruption. -- Art Grabowski --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=cn_queue.c Content-Type: text/x-csrc; name=cn_queue.c; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAljbl9xdWV1ZS5jDQogKiANCiAqIDIwMDQgQ29weXJpZ2h0IChjKSBFdmdlbml5IFBv bHlha292IDxqb2hucG9sQDJrYS5taXB0LnJ1Pg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAq IA0KICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl IGl0IGFuZC9vciBtb2RpZnkNCiAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQogKiB0aGUgRnJlZSBTb2Z0d2FyZSBG b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcg0KICogKGF0IHlv dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCiAqDQogKiBUaGlzIHByb2dyYW0gaXMgZGlz dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCiAqIGJ1dCBXSVRI T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQog KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT ZWUgdGhlDQogKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0K ICoNCiAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlDQogKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0 ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBs YWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQ0KICoNCiAqLw0KDQoj aW5jbHVkZSA8bGludXgva2VybmVsLmg+DQojaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQojaW5j bHVkZSA8bGludXgvbGlzdC5oPg0KI2luY2x1ZGUgPGxpbnV4L3dvcmtxdWV1ZS5oPg0KI2luY2x1 ZGUgPGxpbnV4L3NwaW5sb2NrLmg+DQojaW5jbHVkZSA8bGludXgvc2xhYi5oPg0KI2luY2x1ZGUg PGxpbnV4L3NrYnVmZi5oPg0KI2luY2x1ZGUgPGxpbnV4L3N1c3BlbmQuaD4NCg0KI2luY2x1ZGUg ImNuX3F1ZXVlLmgiDQoNCnN0YXRpYyB2b2lkIGNuX3F1ZXVlX3dyYXBwZXIodm9pZCAqZGF0YSkN CnsNCglzdHJ1Y3QgY25fY2FsbGJhY2tfZW50cnkgKmNicSA9IChzdHJ1Y3QgY25fY2FsbGJhY2tf ZW50cnkgKilkYXRhOw0KDQoJYXRvbWljX2luYygmY2JxLT5jYi0+cmVmY250KTsNCgljYnEtPmNi LT5jYWxsYmFjayhjYnEtPmNiLT5wcml2KTsNCglhdG9taWNfZGVjKCZjYnEtPmNiLT5yZWZjbnQp Ow0KDQoJY2JxLT5kZXN0cnVjdF9kYXRhKGNicS0+ZGRhdGEpOw0KfQ0KDQpzdGF0aWMgc3RydWN0 IGNuX2NhbGxiYWNrX2VudHJ5ICpjbl9xdWV1ZV9hbGxvY19jYWxsYmFja19lbnRyeShzdHJ1Y3QN CgkJCQkJCQkgICAgICAgY25fY2FsbGJhY2sgKmNiKQ0Kew0KCXN0cnVjdCBjbl9jYWxsYmFja19l bnRyeSAqY2JxOw0KDQoJY2JxID0ga21hbGxvYyhzaXplb2YoKmNicSksIEdGUF9LRVJORUwpOw0K CWlmICghY2JxKSB7DQoJCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIGNyZWF0ZSBuZXcgY2Fs bGJhY2sgcXVldWUuXG4iKTsNCgkJcmV0dXJuIE5VTEw7DQoJfQ0KDQoJbWVtc2V0KGNicSwgMCwg c2l6ZW9mKCpjYnEpKTsNCg0KCWNicS0+Y2IgPSBjYjsNCg0KCUlOSVRfV09SSygmY2JxLT53b3Jr LCAmY25fcXVldWVfd3JhcHBlciwgY2JxKTsNCg0KCXJldHVybiBjYnE7DQp9DQoNCnN0YXRpYyB2 b2lkIGNuX3F1ZXVlX2ZyZWVfY2FsbGJhY2soc3RydWN0IGNuX2NhbGxiYWNrX2VudHJ5ICpjYnEp DQp7DQoJY2FuY2VsX2RlbGF5ZWRfd29yaygmY2JxLT53b3JrKTsNCg0KCXdoaWxlIChhdG9taWNf cmVhZCgmY2JxLT5jYi0+cmVmY250KSkgew0KCQlwcmludGsoS0VSTl9JTkZPICJXYWl0aW5nICVz IHRvIGJlY2FtZSBmcmVlOiByZWZjbnQ9JWQuXG4iLA0KCQkgICAgICAgY2JxLT5wZGV2LT5uYW1l LCBhdG9taWNfcmVhZCgmY2JxLT5jYi0+cmVmY250KSk7DQoJCXNldF9jdXJyZW50X3N0YXRlKFRB U0tfSU5URVJSVVBUSUJMRSk7DQoJCXNjaGVkdWxlX3RpbWVvdXQoSFopOw0KDQoJCWlmIChjdXJy ZW50LT5mbGFncyAmIFBGX0ZSRUVaRSkNCgkJCXJlZnJpZ2VyYXRvcihQRl9GUkVFWkUpOw0KDQoJ CWlmIChzaWduYWxfcGVuZGluZyhjdXJyZW50KSkNCgkJCWZsdXNoX3NpZ25hbHMoY3VycmVudCk7 DQoJfQ0KDQoJa2ZyZWUoY2JxKTsNCn0NCg0KaW50IGNuX2NiX2VxdWFsKHN0cnVjdCBjYl9pZCAq aTEsIHN0cnVjdCBjYl9pZCAqaTIpDQp7DQoJcmV0dXJuICgoaTEtPmlkeCA9PSBpMi0+aWR4KSAm JiAoaTEtPnZhbCA9PSBpMi0+dmFsKSk7DQp9DQoNCmludCBjbl9xdWV1ZV9hZGRfY2FsbGJhY2so c3RydWN0IGNuX3F1ZXVlX2RldiAqZGV2LCBzdHJ1Y3QgY25fY2FsbGJhY2sgKmNiKQ0Kew0KCXN0 cnVjdCBjbl9jYWxsYmFja19lbnRyeSAqY2JxLCAqbiwgKl9fY2JxOw0KCWludCBmb3VuZCA9IDA7 DQoNCgljYnEgPSBjbl9xdWV1ZV9hbGxvY19jYWxsYmFja19lbnRyeShjYik7DQoJaWYgKCFjYnEp DQoJCXJldHVybiAtRU5PTUVNOw0KDQoJYXRvbWljX2luYygmZGV2LT5yZWZjbnQpOw0KCWNicS0+ cGRldiA9IGRldjsNCg0KCXNwaW5fbG9jaygmZGV2LT5xdWV1ZV9sb2NrKTsNCglsaXN0X2Zvcl9l YWNoX2VudHJ5X3NhZmUoX19jYnEsIG4sICZkZXYtPnF1ZXVlX2xpc3QsIGNhbGxiYWNrX2VudHJ5 KSB7DQoJCWlmIChjbl9jYl9lcXVhbCgmX19jYnEtPmNiLT5pZCwgJmNiLT5pZCkpIHsNCgkJCWZv dW5kID0gMTsNCgkJCWJyZWFrOw0KCQl9DQoJfQ0KCWlmICghZm91bmQpIHsNCgkJYXRvbWljX3Nl dCgmY2JxLT5jYi0+cmVmY250LCAxKTsNCgkJbGlzdF9hZGRfdGFpbCgmY2JxLT5jYWxsYmFja19l bnRyeSwgJmRldi0+cXVldWVfbGlzdCk7DQoJfQ0KCXNwaW5fdW5sb2NrKCZkZXYtPnF1ZXVlX2xv Y2spOw0KDQoJaWYgKGZvdW5kKSB7DQoJCWF0b21pY19kZWMoJmRldi0+cmVmY250KTsNCgkJYXRv bWljX3NldCgmY2JxLT5jYi0+cmVmY250LCAwKTsNCgkJY25fcXVldWVfZnJlZV9jYWxsYmFjayhj YnEpOw0KCQlyZXR1cm4gLUVJTlZBTDsNCgl9DQoNCgljYnEtPm5scyA9IGRldi0+bmxzOw0KCWNi cS0+c2VxID0gMDsNCgljYnEtPmdyb3VwID0gKytkZXYtPm5ldGxpbmtfZ3JvdXBzOw0KDQoJcmV0 dXJuIDA7DQp9DQoNCnZvaWQgY25fcXVldWVfZGVsX2NhbGxiYWNrKHN0cnVjdCBjbl9xdWV1ZV9k ZXYgKmRldiwgc3RydWN0IGNuX2NhbGxiYWNrICpjYikNCnsNCglzdHJ1Y3QgY25fY2FsbGJhY2tf ZW50cnkgKmNicSA9IE5VTEwsICpuOw0KCWludCBmb3VuZCA9IDA7DQoNCglzcGluX2xvY2soJmRl di0+cXVldWVfbG9jayk7DQoJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKGNicSwgbiwgJmRldi0+ cXVldWVfbGlzdCwgY2FsbGJhY2tfZW50cnkpIHsNCgkJaWYgKGNuX2NiX2VxdWFsKCZjYnEtPmNi LT5pZCwgJmNiLT5pZCkpIHsNCgkJCWxpc3RfZGVsKCZjYnEtPmNhbGxiYWNrX2VudHJ5KTsNCgkJ CWZvdW5kID0gMTsNCgkJCWJyZWFrOw0KCQl9DQoJfQ0KCXNwaW5fdW5sb2NrKCZkZXYtPnF1ZXVl X2xvY2spOw0KDQoJaWYgKGZvdW5kKSB7DQoJCWF0b21pY19kZWMoJmNicS0+Y2ItPnJlZmNudCk7 DQoJCWNuX3F1ZXVlX2ZyZWVfY2FsbGJhY2soY2JxKTsNCgkJYXRvbWljX2RlYygmZGV2LT5yZWZj bnQpOw0KCX0NCn0NCg0Kc3RydWN0IGNuX3F1ZXVlX2RldiAqY25fcXVldWVfYWxsb2NfZGV2KGNo YXIgKm5hbWUsIHN0cnVjdCBzb2NrICpubHMpDQp7DQoJc3RydWN0IGNuX3F1ZXVlX2RldiAqZGV2 Ow0KDQoJZGV2ID0ga21hbGxvYyhzaXplb2YoKmRldiksIEdGUF9LRVJORUwpOw0KCWlmICghZGV2 KSB7DQoJCXByaW50ayhLRVJOX0VSUiAiJXM6IEZhaWxlZCB0byBhbGxvY3RlIG5ldyBzdHJ1Y3Qg Y25fcXVldWVfZGV2LlxuIiwNCgkJICAgICAgIG5hbWUpOw0KCQlyZXR1cm4gTlVMTDsNCgl9DQoN CgltZW1zZXQoZGV2LCAwLCBzaXplb2YoKmRldikpOw0KDQoJc25wcmludGYoZGV2LT5uYW1lLCBz aXplb2YoZGV2LT5uYW1lKSwgIiVzIiwgbmFtZSk7DQoNCglhdG9taWNfc2V0KCZkZXYtPnJlZmNu dCwgMCk7DQoJSU5JVF9MSVNUX0hFQUQoJmRldi0+cXVldWVfbGlzdCk7DQoJc3Bpbl9sb2NrX2lu aXQoJmRldi0+cXVldWVfbG9jayk7DQoNCglkZXYtPm5scyA9IG5sczsNCglkZXYtPm5ldGxpbmtf Z3JvdXBzID0gMDsNCg0KCWRldi0+Y25fcXVldWUgPSBjcmVhdGVfd29ya3F1ZXVlKGRldi0+bmFt ZSk7DQoJaWYgKCFkZXYtPmNuX3F1ZXVlKSB7DQoJCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRv IGNyZWF0ZSAlcyBxdWV1ZS5cbiIsIGRldi0+bmFtZSk7DQoJCWtmcmVlKGRldik7DQoJCXJldHVy biBOVUxMOw0KCX0NCg0KCXJldHVybiBkZXY7DQp9DQoNCnZvaWQgY25fcXVldWVfZnJlZV9kZXYo c3RydWN0IGNuX3F1ZXVlX2RldiAqZGV2KQ0Kew0KCXN0cnVjdCBjbl9jYWxsYmFja19lbnRyeSAq Y2JxLCAqbjsNCg0KCWZsdXNoX3dvcmtxdWV1ZShkZXYtPmNuX3F1ZXVlKTsNCglkZXN0cm95X3dv cmtxdWV1ZShkZXYtPmNuX3F1ZXVlKTsNCg0KCXNwaW5fbG9jaygmZGV2LT5xdWV1ZV9sb2NrKTsN CglsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoY2JxLCBuLCAmZGV2LT5xdWV1ZV9saXN0LCBjYWxs YmFja19lbnRyeSkgew0KCQlsaXN0X2RlbCgmY2JxLT5jYWxsYmFja19lbnRyeSk7DQoJCWF0b21p Y19kZWMoJmNicS0+Y2ItPnJlZmNudCk7DQoJfQ0KCXNwaW5fdW5sb2NrKCZkZXYtPnF1ZXVlX2xv Y2spOw0KDQoJd2hpbGUgKGF0b21pY19yZWFkKCZkZXYtPnJlZmNudCkpIHsNCgkJcHJpbnRrKEtF Uk5fSU5GTyAiV2FpdGluZyAlcyB0byBiZWNhbWUgZnJlZTogcmVmY250PSVkLlxuIiwNCgkJICAg ICAgIGRldi0+bmFtZSwgYXRvbWljX3JlYWQoJmRldi0+cmVmY250KSk7DQoJCXNldF9jdXJyZW50 X3N0YXRlKFRBU0tfSU5URVJSVVBUSUJMRSk7DQoJCXNjaGVkdWxlX3RpbWVvdXQoSFopOw0KDQoJ CWlmIChjdXJyZW50LT5mbGFncyAmIFBGX0ZSRUVaRSkNCgkJCXJlZnJpZ2VyYXRvcihQRl9GUkVF WkUpOw0KDQoJCWlmIChzaWduYWxfcGVuZGluZyhjdXJyZW50KSkNCgkJCWZsdXNoX3NpZ25hbHMo Y3VycmVudCk7DQoJfQ0KDQoJbWVtc2V0KGRldiwgMCwgc2l6ZW9mKCpkZXYpKTsNCglrZnJlZShk ZXYpOw0KCWRldiA9IE5VTEw7DQp9DQoNCkVYUE9SVF9TWU1CT0woY25fcXVldWVfYWRkX2NhbGxi YWNrKTsNCkVYUE9SVF9TWU1CT0woY25fcXVldWVfZGVsX2NhbGxiYWNrKTsNCkVYUE9SVF9TWU1C T0woY25fcXVldWVfYWxsb2NfZGV2KTsNCkVYUE9SVF9TWU1CT0woY25fcXVldWVfZnJlZV9kZXYp Ow0K --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=cn_queue.h Content-Type: text/x-chdr; name=cn_queue.h; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAljbl9xdWV1ZS5oDQogKiANCiAqIDIwMDQgQ29weXJpZ2h0IChjKSBFdmdlbml5IFBv bHlha292IDxqb2hucG9sQDJrYS5taXB0LnJ1Pg0KICogQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAq IA0KICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRl IGl0IGFuZC9vciBtb2RpZnkNCiAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVy YWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQogKiB0aGUgRnJlZSBTb2Z0d2FyZSBG b3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcg0KICogKGF0IHlv dXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCiAqDQogKiBUaGlzIHByb2dyYW0gaXMgZGlz dHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwNCiAqIGJ1dCBXSVRI T1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mDQog KiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBT ZWUgdGhlDQogKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0K ICoNCiAqIFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFs IFB1YmxpYyBMaWNlbnNlDQogKiBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0 ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZQ0KICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBs YWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQ0KICovDQoNCiNpZm5k ZWYgX19DTl9RVUVVRV9IDQojZGVmaW5lIF9fQ05fUVVFVUVfSA0KDQojaW5jbHVkZSA8YXNtL3R5 cGVzLmg+DQoNCnN0cnVjdCBjYl9pZA0Kew0KCV9fdTMyCQkJaWR4Ow0KCV9fdTMyCQkJdmFsOw0K fTsNCg0KI2lmZGVmIF9fS0VSTkVMX18NCg0KI2luY2x1ZGUgPGFzbS9hdG9taWMuaD4NCg0KI2lu Y2x1ZGUgPGxpbnV4L2xpc3QuaD4NCiNpbmNsdWRlIDxsaW51eC93b3JrcXVldWUuaD4NCg0KI2Rl ZmluZSBDTl9DQlFfTkFNRUxFTgkJMzINCg0Kc3RydWN0IGNuX3F1ZXVlX2Rldg0Kew0KCWF0b21p Y190CQlyZWZjbnQ7DQoJdW5zaWduZWQgY2hhcgkJbmFtZVtDTl9DQlFfTkFNRUxFTl07DQoNCglz dHJ1Y3Qgd29ya3F1ZXVlX3N0cnVjdAkqY25fcXVldWU7DQoJDQoJc3RydWN0IGxpc3RfaGVhZCAJ cXVldWVfbGlzdDsNCglzcGlubG9ja190IAkJcXVldWVfbG9jazsNCg0KCWludAkJCW5ldGxpbmtf Z3JvdXBzOw0KCXN0cnVjdCBzb2NrCQkqbmxzOw0KfTsNCg0Kc3RydWN0IGNuX2NhbGxiYWNrDQp7 DQoJdW5zaWduZWQgY2hhcgkJbmFtZVtDTl9DQlFfTkFNRUxFTl07DQoJDQoJc3RydWN0IGNiX2lk CQlpZDsNCgl2b2lkCQkJKCogY2FsbGJhY2spKHZvaWQgKik7DQoJdm9pZAkJCSpwcml2Ow0KCQ0K CWF0b21pY190CQlyZWZjbnQ7DQp9Ow0KDQpzdHJ1Y3QgY25fY2FsbGJhY2tfZW50cnkNCnsNCglz dHJ1Y3QgbGlzdF9oZWFkCWNhbGxiYWNrX2VudHJ5Ow0KCXN0cnVjdCBjbl9jYWxsYmFjawkqY2I7 DQoJc3RydWN0IHdvcmtfc3RydWN0CXdvcms7DQoJc3RydWN0IGNuX3F1ZXVlX2RldgkqcGRldjsN CgkNCgl2b2lkCQkJKCogZGVzdHJ1Y3RfZGF0YSkodm9pZCAqKTsNCgl2b2lkCQkJKmRkYXRhOw0K DQoJaW50CQkJc2VxLCBncm91cDsNCglzdHJ1Y3Qgc29jawkJKm5sczsNCn07DQoNCmludCBjbl9x dWV1ZV9hZGRfY2FsbGJhY2soc3RydWN0IGNuX3F1ZXVlX2RldiAqZGV2LCBzdHJ1Y3QgY25fY2Fs bGJhY2sgKmNiKTsNCnZvaWQgY25fcXVldWVfZGVsX2NhbGxiYWNrKHN0cnVjdCBjbl9xdWV1ZV9k ZXYgKmRldiwgc3RydWN0IGNuX2NhbGxiYWNrICpjYik7DQoNCnN0cnVjdCBjbl9xdWV1ZV9kZXYg KmNuX3F1ZXVlX2FsbG9jX2RldihjaGFyICpuYW1lLCBzdHJ1Y3Qgc29jayAqKTsNCnZvaWQgY25f cXVldWVfZnJlZV9kZXYoc3RydWN0IGNuX3F1ZXVlX2RldiAqZGV2KTsNCg0KaW50IGNuX2NiX2Vx dWFsKHN0cnVjdCBjYl9pZCAqLCBzdHJ1Y3QgY2JfaWQgKik7DQoNCiNlbmRpZiAvKiBfX0tFUk5F TF9fICovDQojZW5kaWYgLyogX19DTl9RVUVVRV9IICovDQo= --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=cn_test.c Content-Type: text/x-csrc; name=cn_test.c; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAljbl90ZXN0LmMNCiAqIA0KICogMjAwNCBDb3B5cmlnaHQgKGMpIEV2Z2VuaXkgUG9s eWFrb3YgPGpvaG5wb2xAMmthLm1pcHQucnU+DQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KICog DQogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUg aXQgYW5kL29yIG1vZGlmeQ0KICogaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkNCiAqIHRoZSBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQogKiAoYXQgeW91 ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBkaXN0 cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KICogYnV0IFdJVEhP VVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YNCiAq IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNl ZSB0aGUNCiAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQog Kg0KICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwg UHVibGljIExpY2Vuc2UNCiAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRl IHRvIHRoZSBGcmVlIFNvZnR3YXJlDQogKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxh Y2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIxMTEtMTMwNyAgVVNBDQogKi8NCg0KI2luY2x1 ZGUgPGxpbnV4L2tlcm5lbC5oPg0KI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPg0KI2luY2x1ZGUg PGxpbnV4L21vZHVsZXBhcmFtLmg+DQoNCiNpbmNsdWRlICJjb25uZWN0b3IuaCINCg0Kc3RhdGlj IHN0cnVjdCBjYl9pZCBjbl90ZXN0X2lkID0geyAweDEyMywgMHg0NTYgfTsNCnN0YXRpYyBjaGFy IGNuX3Rlc3RfbmFtZVtdID0gImNuX3Rlc3QiOw0KDQp2b2lkIGNuX3Rlc3RfY2FsbGJhY2sodm9p ZCAqZGF0YSkNCnsNCglzdHJ1Y3QgY25fbXNnICptc2cgPSAoc3RydWN0IGNuX21zZyAqKWRhdGE7 DQoNCglwcmludGsoIiVzOiBpZHg9JXgsIHZhbD0leCwgbGVuPSVkLlxuIiwNCgkgICAgICAgX19m dW5jX18sIG1zZy0+aWQuaWR4LCBtc2ctPmlkLnZhbCwgbXNnLT5sZW4pOw0KfQ0KDQpzdGF0aWMg aW50IGNuX3Rlc3RfaW5pdCh2b2lkKQ0Kew0KCWludCBlcnI7DQoNCgllcnIgPSBjbl9hZGRfY2Fs bGJhY2soJmNuX3Rlc3RfaWQsIGNuX3Rlc3RfbmFtZSwgY25fdGVzdF9jYWxsYmFjayk7DQoJaWYg KGVycikNCgkJcmV0dXJuIGVycjsNCgljbl90ZXN0X2lkLnZhbCsrOw0KCWVyciA9IGNuX2FkZF9j YWxsYmFjaygmY25fdGVzdF9pZCwgY25fdGVzdF9uYW1lLCBjbl90ZXN0X2NhbGxiYWNrKTsNCglp ZiAoZXJyKSB7DQoJCWNuX2RlbF9jYWxsYmFjaygmY25fdGVzdF9pZCk7DQoJCXJldHVybiBlcnI7 DQoJfQ0KDQoJcmV0dXJuIDA7DQp9DQoNCnN0YXRpYyB2b2lkIGNuX3Rlc3RfZmluaSh2b2lkKQ0K ew0KCWNuX2RlbF9jYWxsYmFjaygmY25fdGVzdF9pZCk7DQoJY25fdGVzdF9pZC52YWwtLTsNCglj bl9kZWxfY2FsbGJhY2soJmNuX3Rlc3RfaWQpOw0KfQ0KDQptb2R1bGVfaW5pdChjbl90ZXN0X2lu aXQpOw0KbW9kdWxlX2V4aXQoY25fdGVzdF9maW5pKTsNCg== --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=connector.c Content-Type: text/x-csrc; name=connector.c; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAljb25uZWN0b3IuYw0KICogDQogKiAyMDA0IENvcHlyaWdodCAoYykgRXZnZW5peSBQ b2x5YWtvdiA8am9obnBvbEAya2EubWlwdC5ydT4NCiAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQog KiANCiAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0 ZSBpdCBhbmQvb3IgbW9kaWZ5DQogKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l cmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KICogdGhlIEZyZWUgU29mdHdhcmUg Rm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3INCiAqIChhdCB5 b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uDQogKg0KICogVGhpcyBwcm9ncmFtIGlzIGRp c3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQogKiBidXQgV0lU SE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0K ICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg U2VlIHRoZQ0KICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4N CiAqDQogKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZQ0KICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3Jp dGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCiAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ bGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCiAqLw0KDQojaW5j bHVkZSA8bGludXgva2VybmVsLmg+DQojaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQojaW5jbHVk ZSA8bGludXgvbGlzdC5oPg0KI2luY2x1ZGUgPGxpbnV4L3NrYnVmZi5oPg0KI2luY2x1ZGUgPGxp bnV4L25ldGxpbmsuaD4NCiNpbmNsdWRlIDxsaW51eC9tb2R1bGVwYXJhbS5oPg0KDQojaW5jbHVk ZSA8bmV0L3NvY2suaD4NCg0KI2luY2x1ZGUgIi4uL2Nvbm5lY3Rvci9jb25uZWN0b3IuaCINCiNp bmNsdWRlICIuLi9jb25uZWN0b3IvY25fcXVldWUuaCINCg0KTU9EVUxFX0xJQ0VOU0UoIkdQTCIp Ow0KTU9EVUxFX0FVVEhPUigiRXZnZW5peSBQb2x5YWtvdiA8am9obnBvbEAya2EubWlwdC5ydT4i KTsNCk1PRFVMRV9ERVNDUklQVElPTigiR2VuZXJpYyB1c2Vyc3BhY2UgPC0+IGtlcm5lbHNwYWNl IGNvbm5lY3Rvci4iKTsNCg0Kc3RhdGljIGludCB1bml0ID0gTkVUTElOS19ORkxPRzsNCm1vZHVs ZV9wYXJhbSh1bml0LCBpbnQsIDApOw0KDQpzdHJ1Y3QgY25fZGV2IGNkZXY7DQoNCi8qDQogKiBt c2ctPnNlcSBhbmQgbXNnLT5hY2sgYXJlIHVzZWQgdG8gZGV0ZXJtaW5lIG1lc3NhZ2UgZ2VuZWFs b2d5Lg0KICogV2hlbiBzb21lb25lIHNlbmRzIG1lc3NhZ2UgaXQgcHV0cyB0aGVyZSBsb2NhbGx5 IHVuaXF1ZSBzZXF1ZW5jZSANCiAqIGFuZCByYW5kb20gYWNrbm93bGVkZ2UgbnVtYmVycy4NCiAq IFNlcXVlbmNlIG51bWJlciBtYXkgYmUgY29waWVkIGludG8gbmxtc2doZHItPm5sbXNnX3NlcSB0 b28uDQogKg0KICogU2VxdWVuY2UgbnVtYmVyIGlzIGluY3JlbWVudGVkIHdpdGggZWFjaCBtZXNz YWdlIHRvIGJlIHNlbnQuDQogKg0KICogSWYgd2UgZXhwZWN0IHJlcGx5IHRvIG91ciBtZXNzYWdl LCANCiAqIHRoZW4gc2VxdWVuY2UgbnVtYmVyIGluIHJlY2VpdmVkIG1lc3NhZ2UgTVVTVCBiZSB0 aGUgc2FtZSBhcyBpbiBvcmlnaW5hbCBtZXNzYWdlLA0KICogYW5kIGFja25vd2xlZGdlIG51bWJl ciBNVVNUIGJlIHRoZSBzYW1lICsgMS4NCiAqDQogKiBJZiB3ZSByZWNlaXZlIG1lc3NhZ2UgYW5k IGl0J3Mgc2VxdWVuY2UgbnVtYmVyIGlzIG5vdCBlcXVhbCB0byBvbmUgd2UgYXJlIGV4cGVjdGlu ZywgDQogKiB0aGVuIGl0IGlzIG5ldyBtZXNzYWdlLg0KICogSWYgd2UgcmVjZWl2ZSBtZXNzYWdl IGFuZCBpdCdzIHNlcXVlbmNlIG51bWJlciBpcyB0aGUgc2FtZSBhcyBvbmUgd2UgYXJlIGV4cGVj dGluZywNCiAqIGJ1dCBpdCdzIGFja25vd2xlZGdlIGlzIG5vdCBlcXVhbCBhY2tub3dsZWRnZSBu dW1iZXIgaW4gb3JpZ2luYWwgbWVzc2FnZSArIDEsDQogKiB0aGVuIGl0IGlzIG5ldyBtZXNzYWdl Lg0KICoNCiAqLw0Kdm9pZCBjbl9uZXRsaW5rX3NlbmQoc3RydWN0IGNuX21zZyAqbXNnKQ0Kew0K CXN0cnVjdCBjbl9jYWxsYmFja19lbnRyeSAqbiwgKl9fY2JxOw0KCXVuc2lnbmVkIGludCBzaXpl Ow0KCXN0cnVjdCBza19idWZmICpza2I7DQoJc3RydWN0IG5sbXNnaGRyICpubGg7DQoJc3RydWN0 IGNuX21zZyAqZGF0YTsNCglzdHJ1Y3QgY25fZGV2ICpkZXYgPSAmY2RldjsNCgl1MzIgZ3JvdXBz ID0gMDsNCglpbnQgZm91bmQgPSAwOw0KDQoJc3Bpbl9sb2NrKCZkZXYtPmNiZGV2LT5xdWV1ZV9s b2NrKTsNCglsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoX19jYnEsIG4sICZkZXYtPmNiZGV2LT5x dWV1ZV9saXN0LCBjYWxsYmFja19lbnRyeSkgew0KCQlpZiAoY25fY2JfZXF1YWwoJl9fY2JxLT5j Yi0+aWQsICZtc2ctPmlkKSkgew0KCQkJZm91bmQgPSAxOw0KCQkJZ3JvdXBzID0gX19jYnEtPmdy b3VwOw0KCQl9DQoJfQ0KCXNwaW5fdW5sb2NrKCZkZXYtPmNiZGV2LT5xdWV1ZV9sb2NrKTsNCg0K CWlmICghZm91bmQpIHsNCgkJcHJpbnRrKEtFUk5fRVJSICJGYWlsZWQgdG8gZmluZCBtdWx0aWNh c3QgbmV0bGluayBncm91cCBmb3IgY2FsbGJhY2tbMHgleC4weCV4XS4gc2VxPSV1XG4iLA0KCQkg ICAgICAgbXNnLT5pZC5pZHgsIG1zZy0+aWQudmFsLCBtc2ctPnNlcSk7DQoJCXJldHVybjsNCgl9 DQoNCglzaXplID0gTkxNU0dfU1BBQ0Uoc2l6ZW9mKCptc2cpICsgbXNnLT5sZW4pOw0KDQoJc2ti ID0gYWxsb2Nfc2tiKHNpemUsIEdGUF9BVE9NSUMpOw0KCWlmICghc2tiKSB7DQoJCXByaW50ayhL RVJOX0VSUiAiRmFpbGVkIHRvIGFsbG9jYXRlIG5ldyBza2Igd2l0aCBzaXplPSV1LlxuIiwgc2l6 ZSk7DQoJCXJldHVybjsNCgl9DQoNCglubGggPSBOTE1TR19QVVQoc2tiLCAwLCBtc2ctPnNlcSwg TkxNU0dfRE9ORSwgc2l6ZSAtIHNpemVvZigqbmxoKSk7DQoNCglkYXRhID0gKHN0cnVjdCBjbl9t c2cgKilOTE1TR19EQVRBKG5saCk7DQoNCgltZW1jcHkoZGF0YSwgbXNnLCBzaXplb2YoKmRhdGEp ICsgbXNnLT5sZW4pOw0KI2lmIDANCglwcmludGsoIiVzOiBsZW49JXUsIHNlcT0ldSwgYWNrPSV1 LCBncm91cD0ldS5cbiIsDQoJICAgICAgIF9fZnVuY19fLCBtc2ctPmxlbiwgbXNnLT5zZXEsIG1z Zy0+YWNrLCBncm91cHMpOw0KI2VuZGlmDQoJTkVUTElOS19DQihza2IpLmRzdF9ncm91cHMgPSBn cm91cHM7DQoJbmV0bGlua19icm9hZGNhc3QoZGV2LT5ubHMsIHNrYiwgMCwgZ3JvdXBzLCBHRlBf QVRPTUlDKTsNCg0KCXJldHVybjsNCg0KICAgICAgbmxtc2dfZmFpbHVyZToNCglwcmludGsoS0VS Tl9FUlIgIkZhaWxlZCB0byBzZW5kICV1LiV1XG4iLCBtc2ctPnNlcSwgbXNnLT5hY2spOw0KCWtm cmVlX3NrYihza2IpOw0KCXJldHVybjsNCn0NCg0Kc3RhdGljIGludCBjbl9jYWxsX2NhbGxiYWNr KHN0cnVjdCBjbl9tc2cgKm1zZywgdm9pZCAoKmRlc3RydWN0X2RhdGEpICh2b2lkICopLCB2b2lk ICpkYXRhKQ0Kew0KCXN0cnVjdCBjbl9jYWxsYmFja19lbnRyeSAqbiwgKl9fY2JxOw0KCXN0cnVj dCBjbl9kZXYgKmRldiA9ICZjZGV2Ow0KCWludCBmb3VuZCA9IDA7DQoNCglzcGluX2xvY2soJmRl di0+Y2JkZXYtPnF1ZXVlX2xvY2spOw0KCWxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShfX2NicSwg biwgJmRldi0+Y2JkZXYtPnF1ZXVlX2xpc3QsIGNhbGxiYWNrX2VudHJ5KSB7DQoJCWlmIChjbl9j Yl9lcXVhbCgmX19jYnEtPmNiLT5pZCwgJm1zZy0+aWQpKSB7DQoJCQlfX2NicS0+Y2ItPnByaXYg PSBtc2c7DQoNCgkJCV9fY2JxLT5kZGF0YSA9IGRhdGE7DQoJCQlfX2NicS0+ZGVzdHJ1Y3RfZGF0 YSA9IGRlc3RydWN0X2RhdGE7DQoNCgkJCXF1ZXVlX3dvcmsoZGV2LT5jYmRldi0+Y25fcXVldWUs ICZfX2NicS0+d29yayk7DQoJCQlmb3VuZCA9IDE7DQoJCQlicmVhazsNCgkJfQ0KCX0NCglzcGlu X3VubG9jaygmZGV2LT5jYmRldi0+cXVldWVfbG9jayk7DQoNCglyZXR1cm4gZm91bmQ7DQp9DQoN CnN0YXRpYyBpbnQgX19jbl9yeF9za2Ioc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IG5sbXNn aGRyICpubGgpDQp7DQoJdTMyIHBpZCwgdWlkLCBzZXEsIGdyb3VwOw0KCXN0cnVjdCBjbl9tc2cg Km1zZzsNCg0KCXBpZCA9IE5FVExJTktfQ1JFRFMoc2tiKS0+cGlkOw0KCXVpZCA9IE5FVExJTktf Q1JFRFMoc2tiKS0+dWlkOw0KCXNlcSA9IG5saC0+bmxtc2dfc2VxOw0KCWdyb3VwID0gTkVUTElO S19DQigoc2tiKSkuZ3JvdXBzOw0KCW1zZyA9IChzdHJ1Y3QgY25fbXNnICopTkxNU0dfREFUQShu bGgpOw0KI2lmIDANCglwcmludGsoS0VSTl9JTkZPICJwaWQ9JXUsIHVpZD0ldSwgc2VxPSV1LCBn cm91cD0ldS5cbiIsDQoJICAgICAgIHBpZCwgdWlkLCBzZXEsIGdyb3VwKTsNCiNlbmRpZg0KCXJl dHVybiBjbl9jYWxsX2NhbGxiYWNrKG1zZywgKHZvaWQgKCopKHZvaWQgKikpa2ZyZWVfc2tiLCBz a2IpOw0KfQ0KDQpzdGF0aWMgdm9pZCBjbl9yeF9za2Ioc3RydWN0IHNrX2J1ZmYgKl9fc2tiKQ0K ew0KCXN0cnVjdCBubG1zZ2hkciAqbmxoOw0KCXUzMiBsZW47DQoJaW50IGVycjsNCglzdHJ1Y3Qg c2tfYnVmZiAqc2tiOw0KDQoJc2tiID0gc2tiX2dldChfX3NrYik7DQoJaWYgKCFza2IpIHsNCgkJ cHJpbnRrKEtFUk5fRVJSICJGYWlsZWQgdG8gcmVmZXJlbmNlIGFuIHNrYi5cbiIpOw0KCQlyZXR1 cm47DQoJfQ0KI2lmIDANCglwcmludGsoS0VSTl9JTkZPDQoJICAgICAgICJza2I6IGxlbj0ldSwg ZGF0YV9sZW49JXUsIHRydWVzaXplPSV1LCBwcm90bz0ldSwgY2xvbmVkPSVkLCBzaGFyZWQ9JWQu XG4iLA0KCSAgICAgICBza2ItPmxlbiwgc2tiLT5kYXRhX2xlbiwgc2tiLT50cnVlc2l6ZSwgc2ti LT5wcm90b2NvbCwNCgkgICAgICAgc2tiX2Nsb25lZChza2IpLCBza2Jfc2hhcmVkKHNrYikpOw0K I2VuZGlmDQoJd2hpbGUgKHNrYi0+bGVuID49IE5MTVNHX1NQQUNFKDApKSB7DQoJCW5saCA9IChz dHJ1Y3Qgbmxtc2doZHIgKilza2ItPmRhdGE7DQoJCWlmIChubGgtPm5sbXNnX2xlbiA8IHNpemVv ZihzdHJ1Y3QgY25fbXNnKSB8fA0KCQkgICAgc2tiLT5sZW4gPCBubGgtPm5sbXNnX2xlbiB8fA0K CQkgICAgbmxoLT5ubG1zZ19sZW4gPiBDT05ORUNUT1JfTUFYX01TR19TSVpFKSB7DQoJCQlwcmlu dGsoS0VSTl9JTkZPICJubG1zZ19sZW49JXUsIHNpemVvZigqbmxoKT0ldVxuIiwNCgkJCSAgICAg ICBubGgtPm5sbXNnX2xlbiwgc2l6ZW9mKCpubGgpKTsNCgkJCWJyZWFrOw0KCQl9DQoNCgkJbGVu ID0gTkxNU0dfQUxJR04obmxoLT5ubG1zZ19sZW4pOw0KCQlpZiAobGVuID4gc2tiLT5sZW4pDQoJ CQlsZW4gPSBza2ItPmxlbjsNCg0KCQllcnIgPSBfX2NuX3J4X3NrYihza2IsIG5saCk7DQoJCWlm IChlcnIpIHsNCgkJCWlmIChlcnIgPCAwKQ0KCQkJCW5ldGxpbmtfYWNrKHNrYiwgbmxoLCAtZXJy KTsNCgkJCWtmcmVlX3NrYihza2IpOw0KCQkJYnJlYWs7DQoJCX0gZWxzZSB7DQoJCQlpZiAobmxo LT5ubG1zZ19mbGFncyAmIE5MTV9GX0FDSykNCgkJCQluZXRsaW5rX2Fjayhza2IsIG5saCwgMCk7 DQoJCQlrZnJlZV9za2Ioc2tiKTsNCgkJCWJyZWFrOw0KCQl9DQoJCXNrYl9wdWxsKHNrYiwgbGVu KTsNCgl9DQp9DQoNCnN0YXRpYyB2b2lkIGNuX2lucHV0KHN0cnVjdCBzb2NrICpzaywgaW50IGxl bikNCnsNCglzdHJ1Y3Qgc2tfYnVmZiAqc2tiOw0KDQoJd2hpbGUgKChza2IgPSBza2JfZGVxdWV1 ZSgmc2stPnNrX3JlY2VpdmVfcXVldWUpKSAhPSBOVUxMKQ0KCQljbl9yeF9za2Ioc2tiKTsNCn0N Cg0KaW50IGNuX2FkZF9jYWxsYmFjayhzdHJ1Y3QgY2JfaWQgKmlkLCBjaGFyICpuYW1lLCB2b2lk ICgqY2FsbGJhY2spICh2b2lkICopKQ0Kew0KCWludCBlcnI7DQoJc3RydWN0IGNuX2RldiAqZGV2 ID0gJmNkZXY7DQoJc3RydWN0IGNuX2NhbGxiYWNrICpjYjsNCg0KCWNiID0ga21hbGxvYyhzaXpl b2YoKmNiKSwgR0ZQX0tFUk5FTCk7DQoJaWYgKCFjYikgew0KCQlwcmludGsoS0VSTl9JTkZPICIl czogRmFpbGVkIHRvIGFsbG9jYXRlIG5ldyBzdHJ1Y3QgY25fY2FsbGJhY2suXG4iLA0KCQkgICAg ICAgZGV2LT5jYmRldi0+bmFtZSk7DQoJCXJldHVybiAtRU5PTUVNOw0KCX0NCg0KCW1lbXNldChj YiwgMCwgc2l6ZW9mKCpjYikpOw0KDQoJc25wcmludGYoY2ItPm5hbWUsIHNpemVvZihjYi0+bmFt ZSksICIlcyIsIG5hbWUpOw0KDQoJbWVtY3B5KCZjYi0+aWQsIGlkLCBzaXplb2YoY2ItPmlkKSk7 DQoJY2ItPmNhbGxiYWNrID0gY2FsbGJhY2s7DQoNCglhdG9taWNfc2V0KCZjYi0+cmVmY250LCAw KTsNCg0KCWVyciA9IGNuX3F1ZXVlX2FkZF9jYWxsYmFjayhkZXYtPmNiZGV2LCBjYik7DQoJaWYg KGVycikgew0KCQlrZnJlZShjYik7DQoJCXJldHVybiBlcnI7DQoJfQ0KDQoJcmV0dXJuIDA7DQp9 DQoNCnZvaWQgY25fZGVsX2NhbGxiYWNrKHN0cnVjdCBjYl9pZCAqaWQpDQp7DQoJc3RydWN0IGNu X2RldiAqZGV2ID0gJmNkZXY7DQoJc3RydWN0IGNuX2NhbGxiYWNrX2VudHJ5ICpuLCAqX19jYnE7 DQoNCglsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoX19jYnEsIG4sICZkZXYtPmNiZGV2LT5xdWV1 ZV9saXN0LCBjYWxsYmFja19lbnRyeSkgew0KCQlpZiAoY25fY2JfZXF1YWwoJl9fY2JxLT5jYi0+ aWQsIGlkKSkgew0KCQkJY25fcXVldWVfZGVsX2NhbGxiYWNrKGRldi0+Y2JkZXYsIF9fY2JxLT5j Yik7DQoJCQlicmVhazsNCgkJfQ0KCX0NCn0NCg0Kc3RhdGljIGludCBjbl9pbml0KHZvaWQpDQp7 DQoJc3RydWN0IGNuX2RldiAqZGV2ID0gJmNkZXY7DQoNCglkZXYtPmlucHV0ID0gY25faW5wdXQ7 DQoNCglkZXYtPm5scyA9IG5ldGxpbmtfa2VybmVsX2NyZWF0ZSh1bml0LCBkZXYtPmlucHV0KTsN CglpZiAoIWRldi0+bmxzKSB7DQoJCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIGNyZWF0ZSBu ZXcgbmV0bGluayBzb2NrZXQoJXUpLlxuIiwNCgkJICAgICAgIHVuaXQpOw0KCQlyZXR1cm4gLUVJ TzsNCgl9DQoNCglkZXYtPmNiZGV2ID0gY25fcXVldWVfYWxsb2NfZGV2KCJjcXVldWUiLCBkZXYt Pm5scyk7DQoJaWYgKCFkZXYtPmNiZGV2KSB7DQoJCWlmIChkZXYtPm5scy0+c2tfc29ja2V0KQ0K CQkJc29ja19yZWxlYXNlKGRldi0+bmxzLT5za19zb2NrZXQpOw0KCQlyZXR1cm4gLUVJTlZBTDsN Cgl9DQoNCglyZXR1cm4gMDsNCn0NCg0Kc3RhdGljIHZvaWQgY25fZmluaSh2b2lkKQ0Kew0KCXN0 cnVjdCBjbl9kZXYgKmRldiA9ICZjZGV2Ow0KDQoJY25fcXVldWVfZnJlZV9kZXYoZGV2LT5jYmRl dik7DQoJaWYgKGRldi0+bmxzLT5za19zb2NrZXQpDQoJCXNvY2tfcmVsZWFzZShkZXYtPm5scy0+ c2tfc29ja2V0KTsNCn0NCg0KbW9kdWxlX2luaXQoY25faW5pdCk7DQptb2R1bGVfZXhpdChjbl9m aW5pKTsNCg0KRVhQT1JUX1NZTUJPTChjbl9hZGRfY2FsbGJhY2spOw0KRVhQT1JUX1NZTUJPTChj bl9kZWxfY2FsbGJhY2spOw0KRVhQT1JUX1NZTUJPTChjbl9uZXRsaW5rX3NlbmQpOw0K --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=connector.h Content-Type: text/x-chdr; name=connector.h; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAljb25uZWN0b3IuaA0KICogDQogKiAyMDA0IENvcHlyaWdodCAoYykgRXZnZW5peSBQ b2x5YWtvdiA8am9obnBvbEAya2EubWlwdC5ydT4NCiAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQog KiANCiAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0 ZSBpdCBhbmQvb3IgbW9kaWZ5DQogKiBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5l cmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQ0KICogdGhlIEZyZWUgU29mdHdhcmUg Rm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3INCiAqIChhdCB5 b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uDQogKg0KICogVGhpcyBwcm9ncmFtIGlzIGRp c3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsDQogKiBidXQgV0lU SE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0K ICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAg U2VlIHRoZQ0KICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4N CiAqDQogKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZQ0KICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3Jp dGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCiAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQ bGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0xMzA3ICBVU0ENCiAqLw0KDQojaWZu ZGVmIF9fQ09OTkVDVE9SX0gNCiNkZWZpbmUgX19DT05ORUNUT1JfSA0KDQojaW5jbHVkZSAiLi4v Y29ubmVjdG9yL2NuX3F1ZXVlLmgiDQoNCiNkZWZpbmUgQ09OTkVDVE9SX01BWF9NU0dfU0laRSAJ MTAyNA0KDQpzdHJ1Y3QgY25fbXNnDQp7DQoJc3RydWN0IGNiX2lkIAkJaWQ7DQoNCglfX3UzMgkJ CXNlcTsNCglfX3UzMgkJCWFjazsNCg0KCV9fdTMyCQkJbGVuOwkJLyogTGVuZ3RoIG9mIHRoZSBm b2xsb3dpbmcgZGF0YSAqLw0KCV9fdTgJCQlkYXRhWzBdOw0KfTsNCg0KI2lmZGVmIF9fS0VSTkVM X18NCg0KI2luY2x1ZGUgPG5ldC9zb2NrLmg+DQoNCnN0cnVjdCBjbl9kZXYNCnsNCgl1MzIJCQlz ZXEsIGdyb3VwczsNCglzdHJ1Y3Qgc29jayAJCSpubHM7DQoJdm9pZCAJCQkoKmlucHV0KShzdHJ1 Y3Qgc29jayAqc2ssIGludCBsZW4pOw0KDQoJc3RydWN0IGNuX3F1ZXVlX2RldgkqY2JkZXY7DQp9 Ow0KDQppbnQgY25fYWRkX2NhbGxiYWNrKHN0cnVjdCBjYl9pZCAqLCBjaGFyICosIHZvaWQgKCog Y2FsbGJhY2spKHZvaWQgKikpOw0Kdm9pZCBjbl9kZWxfY2FsbGJhY2soc3RydWN0IGNiX2lkICop Ow0Kdm9pZCBjbl9uZXRsaW5rX3NlbmQoc3RydWN0IGNuX21zZyAqKTsNCg0KI2VuZGlmIC8qIF9f S0VSTkVMX18gKi8NCiNlbmRpZiAvKiBfX0NPTk5FQ1RPUl9IICovDQo= --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=Makefile Content-Type: text/x-makefile; name=Makefile; charset=KOI8-R Content-Transfer-Encoding: base64 b2JqLW0JCTo9IGNuLm8gY25fdGVzdC5vDQpjbi1vYmpzCQk6PSBjbl9xdWV1ZS5vIGNvbm5lY3Rv ci5vDQoNCiNLRElSCTo9IC9saWIvbW9kdWxlcy8kKHNoZWxsIHVuYW1lIC1yKS9idWlsZA0KS0RJ Ugk6PSAvdXNyL2xvY2FsL3NyYy9saW51eC0yLjYvbGludXgtMi42LjYNClBXRAk6PSAkKHNoZWxs IHB3ZCkNCg0KZGVmYXVsdDoNCgkkKE1BS0UpIC1DICQoS0RJUikgU1VCRElSUz0kKFBXRCkgbW9k dWxlcw0KDQpjbGVhbjoNCglybSAtZiAqLm8gKi5rbyAqLm1vZC4qIC4qLmNtZCAqfg0KCXJtIC1y ZiAudG1wX3ZlcnNpb25zDQoNCnVjb246CXVjb24uYyBjb25uZWN0b3IuaA0KCWdjYyAtVyAtV2Fs bCAtTzkgdWNvbi5jIC1vIHVjb24NCg== --=-cgNL2/x9Za/yEgPSnppb Content-Disposition: attachment; filename=ucon.c Content-Type: text/x-csrc; name=ucon.c; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAqIAl1Y29uLmMNCiAqDQogKiBDb3B5cmlnaHQgKGMpIDIwMDQgRXZnZW5peSBQb2x5YWtv diA8am9obnBvbEAya2EubWlwdC5ydT4NCiAqIA0KICoNCiAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVl IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQogKiBpdCB1 bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxp c2hlZCBieQ0KICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24g MiBvZiB0aGUgTGljZW5zZSwgb3INCiAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNp b24uDQogKg0KICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQg aXQgd2lsbCBiZSB1c2VmdWwsDQogKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQ0KICogR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4NCiAqDQogKiBZb3Ugc2hvdWxkIGhhdmUgcmVj ZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KICogYWxvbmcg d2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCiAq IEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1B IDAyMTExLTEzMDcgVVNBDQogKi8NCg0KI2luY2x1ZGUgPGFzbS90eXBlcy5oPg0KDQojaW5jbHVk ZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KI2luY2x1ZGUgPHN5cy9w b2xsLmg+DQoNCiNpbmNsdWRlIDxsaW51eC9uZXRsaW5rLmg+DQojaW5jbHVkZSA8bGludXgvcnRu ZXRsaW5rLmg+DQoNCiNpbmNsdWRlIDxhcnBhL2luZXQuaD4NCg0KI2luY2x1ZGUgPHN0ZGlvLmg+ DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8dW5pc3RkLmg+DQojaW5jbHVkZSA8c3Ry aW5nLmg+DQojaW5jbHVkZSA8ZXJybm8uaD4NCiNpbmNsdWRlIDx0aW1lLmg+DQoNCiNpbmNsdWRl ICJjb25uZWN0b3IuaCINCiNpbmNsdWRlICIuLi9zb2VrcmlzL3NjX2Nvbm4uaCINCg0Kc3RhdGlj IGludCBuZWVkX2V4aXQ7DQpfX3UzMiBzZXE7DQoNCnN0YXRpYyBpbnQgbmV0bGlua19zZW5kKGlu dCBzLCBjaGFyICpkYXRhKQ0Kew0KCXN0cnVjdCBubG1zZ2hkciAqbmxoOw0KCXVuc2lnbmVkIGlu dCBzaXplOw0KCWludCBlcnI7DQoJY2hhciBidWZbMTI4XTsNCglzdHJ1Y3QgY25fbXNnICptLCAq bXNnOw0KCXN0cnVjdCBzY19jb25uX2RhdGEgKmNtZDsNCg0KCXNpemUgPSBOTE1TR19TUEFDRShz aXplb2Yoc3RydWN0IGNuX21zZykgKyBzaXplb2Yoc3RydWN0IHNjX2Nvbm5fZGF0YSkpOw0KDQoJ bmxoID0gKHN0cnVjdCBubG1zZ2hkciAqKWJ1ZjsNCglubGgtPm5sbXNnX3NlcSA9IHNlcSsrOw0K CW5saC0+bmxtc2dfcGlkID0gZ2V0cGlkKCk7DQoJbmxoLT5ubG1zZ190eXBlID0gTkxNU0dfRE9O RTsNCglubGgtPm5sbXNnX2xlbiA9IE5MTVNHX0xFTkdUSChzaXplIC0gc2l6ZW9mKCpubGgpKTsN CglubGgtPm5sbXNnX2ZsYWdzID0gMDsNCg0KCW0gPSBOTE1TR19EQVRBKG5saCk7DQoJbXNnID0g KHN0cnVjdCBjbl9tc2cgKilkYXRhOw0KCWNtZCA9IChzdHJ1Y3Qgc2NfY29ubl9kYXRhICopKG1z ZyArIDEpOw0KDQoJcHJpbnRmKCIlczogbGVuPSV1LCBzZXE9JXUsIGFjaz0ldSwgIg0KCSAgICAg ICAic25hbWU9JXMsIGxuYW1lPSVzLCBpZHg9MHgleCwgY21kPSUwMnggWyUwMnguJTAyeC4lMDJ4 XS5cbiIsDQoJICAgICAgIF9fZnVuY19fLA0KCSAgICAgICBtc2ctPmxlbiwgbXNnLT5zZXEsIG1z Zy0+YWNrLA0KCSAgICAgICBjbWQtPnNuYW1lLA0KCSAgICAgICBjbWQtPmxuYW1lLCBjbWQtPmlk eCwgY21kLT5jbWQsIGNtZC0+cDAsIGNtZC0+cDEsIGNtZC0+cDIpOw0KDQoJbWVtY3B5KG0sIGRh dGEsIHNpemVvZigqbSkgKyBtc2ctPmxlbik7DQoNCgllcnIgPSBzZW5kKHMsIG5saCwgc2l6ZSwg MCk7DQoJaWYgKGVyciA9PSAtMSkNCgkJZnByaW50ZihzdGRlcnIsICJGYWlsZWQgdG8gc2VuZDog JXMgWyVkXS5cbiIsDQoJCQlzdHJlcnJvcihlcnJubyksIGVycm5vKTsNCg0KCXJldHVybiBlcnI7 DQp9DQoNCmludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pDQp7DQoJaW50IHM7DQoJY2hh ciBidWZbMTAyNF07DQoJaW50IGxlbjsNCglzdHJ1Y3Qgbmxtc2doZHIgKnJlcGx5Ow0KCXN0cnVj dCBzb2NrYWRkcl9ubCBsX2xvY2FsOw0KCXN0cnVjdCBjbl9tc2cgKmRhdGE7DQoJc3RydWN0IHNj X2Nvbm5fZGF0YSAqbTsNCglGSUxFICpvdXQ7DQoJdGltZV90IHRtOw0KCXN0cnVjdCBwb2xsZmQg cGZkOw0KDQoJaWYgKGFyZ2MgPCAyKQ0KCQlvdXQgPSBzdGRvdXQ7DQoJZWxzZSB7DQoJCW91dCA9 IGZvcGVuKGFyZ3ZbMV0sICJhKyIpOw0KCQlpZiAoIW91dCkgew0KCQkJZnByaW50ZihzdGRlcnIs ICJVbmFibGUgdG8gb3BlbiAlcyBmb3Igd3JpdGluZzogJXNcbiIsDQoJCQkJYXJndlsxXSwgc3Ry ZXJyb3IoZXJybm8pKTsNCgkJCW91dCA9IHN0ZG91dDsNCgkJfQ0KCX0NCg0KCW1lbXNldChidWYs IDAsIHNpemVvZihidWYpKTsNCg0KCXMgPSBzb2NrZXQoUEZfTkVUTElOSywgU09DS19ER1JBTSwg TkVUTElOS19ORkxPRyk7DQoJaWYgKHMgPT0gLTEpIHsNCgkJcGVycm9yKCJzb2NrZXQiKTsNCgkJ cmV0dXJuIC0xOw0KCX0NCg0KCWxfbG9jYWwubmxfZmFtaWx5ID0gQUZfTkVUTElOSzsNCglsX2xv Y2FsLm5sX2dyb3VwcyA9IDE7DQoJbF9sb2NhbC5ubF9waWQgPSBnZXRwaWQoKTsNCg0KCWlmIChi aW5kKHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikmbF9sb2NhbCwgc2l6ZW9mKHN0cnVjdCBzb2NrYWRk cl9ubCkpID09DQoJICAgIC0xKSB7DQoJCXBlcnJvcigiYmluZCIpOw0KCQljbG9zZShzKTsNCgkJ cmV0dXJuIC0xOw0KCX0NCg0KCXBmZC5mZCA9IHM7DQoNCgl3aGlsZSAoIW5lZWRfZXhpdCkgew0K CQlwZmQuZXZlbnRzID0gUE9MTElOOw0KCQlwZmQucmV2ZW50cyA9IDA7DQoJCS8qc3dpdGNoIChw b2xsKCZwZmQsIDEsIC0xKSkgDQoJCSAgIHsNCgkJICAgY2FzZSAwOg0KCQkgICBuZWVkX2V4aXQg PSAxOw0KCQkgICBicmVhazsNCgkJICAgY2FzZSAtMToNCgkJICAgaWYgKGVycm5vICE9IEVJTlRS KSANCgkJICAgew0KCQkgICBuZWVkX2V4aXQgPSAxOw0KCQkgICBicmVhazsNCgkJICAgfQ0KCQkg ICBjb250aW51ZTsNCgkJICAgfSAqLw0KCQlpZiAobmVlZF9leGl0KQ0KCQkJYnJlYWs7DQoNCgkJ ZGF0YSA9IChzdHJ1Y3QgY25fbXNnICopYnVmOw0KDQoJCWRhdGEtPmlkLmlkeCA9IDB4YWFiYjsN CgkJZGF0YS0+aWQudmFsID0gMHhjY2RkOw0KCQlkYXRhLT5zZXEgPSBzZXErKzsNCgkJZGF0YS0+ YWNrID0gKHNlcSBeIDB4MTIzNCk7DQoJCWRhdGEtPmxlbiA9IHNpemVvZigqbSk7DQoNCgkJbSA9 IChzdHJ1Y3Qgc2NfY29ubl9kYXRhICopKGRhdGEgKyAxKTsNCgkJbWVtc2V0KG0sIDAsIHNpemVv ZigqbSkpOw0KDQoJCW0tPmNtZCA9IFNDX0NNRF9MREVWX1JFQUQ7DQoJCW0tPmlkeCA9IDB4ZmY7 DQoJCXNwcmludGYobS0+c25hbWUsICJQQzg3MzZYIik7DQoJCXNwcmludGYobS0+bG5hbWUsICJH UElPIik7DQoNCgkJbS0+cDAgPSAyMTsNCg0KCQlsZW4gPSBuZXRsaW5rX3NlbmQocywgYnVmKTsN Cg0KCQlsZW4gPSByZWN2KHMsIGJ1Ziwgc2l6ZW9mKGJ1ZiksIDApOw0KCQlpZiAobGVuID09IC0x KSB7DQoJCQlwZXJyb3IoInJlY3YgYnVmIik7DQoJCQljbG9zZShzKTsNCgkJCXJldHVybiAtMTsN CgkJfQ0KCQlyZXBseSA9IChzdHJ1Y3Qgbmxtc2doZHIgKilidWY7DQoNCgkJc3dpdGNoIChyZXBs eS0+bmxtc2dfdHlwZSkgew0KCQljYXNlIE5MTVNHX0VSUk9SOg0KCQkJZnByaW50ZihvdXQsICJF cnJvciBtZXNzYWdlIHJlY2VpdmVkLlxuIik7DQoJCQlmZmx1c2gob3V0KTsNCgkJCWJyZWFrOw0K CQljYXNlIE5MTVNHX0RPTkU6DQoJCQlkYXRhID0gKHN0cnVjdCBjbl9tc2cgKilOTE1TR19EQVRB KHJlcGx5KTsNCgkJCW0gPSAoc3RydWN0IHNjX2Nvbm5fZGF0YSAqKShkYXRhICsgMSk7DQoNCgkJ CXRpbWUoJnRtKTsNCgkJCWZwcmludGYob3V0LA0KCQkJCSIlLjI0cyA6IFsleC4leF0gW3NlcT0l dSwgYWNrPSV1XSwgc25hbWU9JXMsIGxuYW1lPSVzLCBpZHg9JXUsIGNtZD0lIzAyeCBbJSMwMngu JSMwMnguJSMwMnhdXG4iLA0KCQkJCWN0aW1lKCZ0bSksIGRhdGEtPmlkLmlkeCwgZGF0YS0+aWQu dmFsLA0KCQkJCWRhdGEtPnNlcSwgZGF0YS0+YWNrLCBtLT5zbmFtZSwgbS0+bG5hbWUsDQoJCQkJ bS0+aWR4LCBtLT5jbWQsIG0tPnAwLCBtLT5wMSwgbS0+cDIpOw0KCQkJZmZsdXNoKG91dCk7DQoJ CQlicmVhazsNCgkJZGVmYXVsdDoNCgkJCWJyZWFrOw0KCQl9DQoNCgkJc2xlZXAoMSk7DQoJfQ0K DQoJY2xvc2Uocyk7DQoJcmV0dXJuIDA7DQp9DQo= --=-cgNL2/x9Za/yEgPSnppb-- --=-mcQn/wn0/BKtRO/PaPc5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBSXA7IKTPhE+8wY0RApWEAJwPkuzLA0h4fnVWjfOQlsBcj0rKpgCglGwp HSpi06OQW3ozVuqzVth7LlU= =xxSJ -----END PGP SIGNATURE----- --=-mcQn/wn0/BKtRO/PaPc5-- From pekkas@netcore.fi Thu Sep 16 04:14:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 04:15:17 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GBEuh9022447 for ; Thu, 16 Sep 2004 04:14:56 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8GBDeq00392; Thu, 16 Sep 2004 14:13:40 +0300 Date: Thu, 16 Sep 2004 14:13:40 +0300 (EEST) From: Pekka Savola To: Ville Nuorvala cc: Herbert Xu , "David S. Miller" , YOSHIFUJI Hideaki , James Morris , Subject: Re: [RTNETLINK] Tunnel config via netlink (Was Re: Convert RTM_* to enum) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1115 Lines: 26 On Thu, 16 Sep 2004, Ville Nuorvala wrote: > While designing the netlink interface it might perhaps be a good idea to > take a look at draft-ietf-ipv6-inet-tunnel-mib-02.txt, which is currently > in IESG processing. The IPv6 specific tunnel encapsulation limit (below) > is still missing from the draft but will be included in the RFC. > > tunnelIfEncapsLimit OBJECT-TYPE > SYNTAX Integer32 (-1 | 0..255) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The maximum number of additional encapsulations permitted > for packets undergoing encapsulation at this node. A value > of -1 indicates that no limit is present (except as a result > of the packet size)." > REFERENCE "RFC 2473, section 4.1.1" > ::= { tunnelIfEntry 11 } FWIW, I've always viewed this as a mostly unnecessary feature that nobody bothers to implement, but YMMV. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From hadi@cyberus.ca Thu Sep 16 04:31:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 04:31:21 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GBVF8d026206 for ; Thu, 16 Sep 2004 04:31:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C7uTe-0006yh-Rm for netdev@oss.sgi.com; Thu, 16 Sep 2004 07:31:02 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7uTc-00062i-Kh; Thu, 16 Sep 2004 07:31:00 -0400 Subject: Re: [Routing] Performance Comparison between 2.6 and 2.4 kernel From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Song Wang , netdev@oss.sgi.com In-Reply-To: <20040915110858.125cea28.davem@davemloft.net> References: <1094868693.1041.86.camel@jzny.localdomain> <20040915180603.98079.qmail@web40007.mail.yahoo.com> <20040915110858.125cea28.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095334258.1065.158.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Sep 2004 07:30:58 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 768 Lines: 23 On Wed, 2004-09-15 at 14:08, David S. Miller wrote: > On Wed, 15 Sep 2004 11:06:03 -0700 (PDT) > Song Wang wrote: > > > The mips CPU on the board is MIPS32 compatible. > > I don't think it's NAPI based. > > NAPI is an attribute of the network adapter, not > the cpu. > > Although I would very much anticipate this being > a MIPS or network adapter specific problem since > on x86 routing is pretty fast in 2.6.x Note, I could hit 4-500Kpps on a bcom sb1250 800Mhz; trying to simulate Andis gettimeofday changes (which are in 2.6 since i havent seen a 2.6 port for that board ) gives another 100Kpps. Theres still room for improvement just havent had time. You are right though it could be a 2.6.x arch specific issue. Bacchus? cheers, jamal From nhorman@redhat.com Thu Sep 16 04:37:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 04:37:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GBbRp1026664 for ; Thu, 16 Sep 2004 04:37:28 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8GBbHHc027523; Thu, 16 Sep 2004 07:37:17 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8GBbHr31771; Thu, 16 Sep 2004 07:37:17 -0400 Received: from redhat.com (hmsendeavour.rdu.redhat.com [172.16.57.156]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i8GBbGit019325; Thu, 16 Sep 2004 07:37:16 -0400 Message-ID: <41497AEC.1010807@redhat.com> Date: Thu, 16 Sep 2004 07:37:16 -0400 From: Neil Horman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0; hi, Mom) Gecko/20020604 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Felter CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: The ultimate TOE design References: <4148991B.9050200@pobox.com> <4148A561.5070401@redhat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nhorman@redhat.com Precedence: bulk X-list: netdev Content-Length: 3502 Lines: 80 Wes Felter wrote: > Neil Horman wrote: > >> Paul Jakma wrote: >> >>> On Wed, 15 Sep 2004, Jeff Garzik wrote: >>> >>>> Put simply, the "ultimate TOE card" would be a card with network >>>> ports, a generic CPU (arm, mips, whatever.), some RAM, and some >>>> flash. This card's "firmware" is the Linux kernel, configured to >>>> run as a _totally indepenent network node_, with IP address(es) all >>>> its own. >>>> >>>> Then, your host system OS will communicate with the Linux kernel >>>> running on the card across the PCI bus, using IP packets (64K fixed >>>> MTU). > > >>> The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI >>> card running Linux. Or is that what you were referring to with >>> " but they are all fairly expensive."? > > >> IBM's PowerNP chip was also very simmilar (a powerpc core with lots of >> hardware assists for DMA and packet inspection in the extended >> register area). Don't know if they still sell it, but at one time I >> had heard they had booted linux on it. > > > An IXP or PowerNP wouldn't work for Jeff's idea. The IXP's XScale core > and PowerNP's PowerPC core are way too slow to do any significant > processing; they are intended for control tasks like updating the > routing tables. All the work in the IXP or PowerNP is done by the > microengines, which have weird, non-Linux-compatible architectures. > I didn't say the assist hardware wouldn't need an extra driver. Its not 100% free, as Jeff proposes, but the CPU portion of these designs is _sufficient_ to run linux, and a driver can be written to drive the remainder of these chips. Its the combination that network device manufacturers design to today: A specialized chip to do L3/L2 forwarding at line rate over a large number of ports, and just enough general purpose CPU to manage the user interface, the forwarding hardware and any overflow forwarding that the forwarding hardware can't deal with quickly. > To do 10 Gbps Ethernet with Jeff's approach, wouldn't you need a 5-10 > GHz processor on the card? Sounds expensive. > To handle port densities that are competing in the market today? Yes, which as I mentioned earlier would price designs like this out of the market. Jeffs idea is a nice one, but it doesn't really fit well with the hardware that networking equipment manufacturers are building today. Take a look at Broadcoms StrataSwitch/StrataXGS lines, or Switchcores Xpeedium processors. These are the sorts of things we have to work with . They provide network stack offload in competitive port densities, but they aren't also general purpose processors. They need a driver to massage their behavior into something more linux friendly. If we could develop an infrastrucutre that made these chips easy to integrate into a platform running linux, linux could quickly come to dominate a large portion of the network device space. Neil > Wes Felter - wesley@felter.org - http://felter.org/wesley/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From herbert@gondor.apana.org.au Thu Sep 16 04:58:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 04:59:08 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GBwu5X027415 for ; Thu, 16 Sep 2004 04:58:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7uuK-0006Np-00; Thu, 16 Sep 2004 21:58:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7uuC-0000F9-00; Thu, 16 Sep 2004 21:58:28 +1000 Date: Thu, 16 Sep 2004 21:58:28 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [INET] Kill ip6_get_dsfield Message-ID: <20040916115827.GA29046@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4229 Lines: 143 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch kills the duplicate implementation of ip6_get_dsfield in inet_ecn.h. It now uses ipv6_get_dsfield from dsfield.h instead. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/inet_ecn.h 1.8 vs edited ===== --- 1.8/include/net/inet_ecn.h 2004-09-14 06:03:39 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-16 21:41:34 +10:00 @@ -78,13 +78,11 @@ iph->tos &= ~INET_ECN_MASK; } -#define ip6_get_dsfield(iph) ((ntohs(*(u16*)(iph)) >> 4) & 0xFF) - struct ipv6hdr; static inline void IP6_ECN_set_ce(struct ipv6hdr *iph) { - if (INET_ECN_is_not_ect(ip6_get_dsfield(iph))) + if (INET_ECN_is_not_ect(ipv6_get_dsfield(iph))) return; *(u32*)iph |= htonl(INET_ECN_CE << 20); } ===== net/ipv4/ip_gre.c 1.42 vs edited ===== --- 1.42/net/ipv4/ip_gre.c 2004-09-14 09:04:06 +10:00 +++ edited/net/ipv4/ip_gre.c 2004-09-16 21:42:57 +10:00 @@ -36,6 +36,7 @@ #include #include #include +#include #include #include @@ -547,7 +548,7 @@ if (skb->protocol == htons(ETH_P_IP)) inner = old_iph->tos; else if (skb->protocol == htons(ETH_P_IPV6)) - inner = ip6_get_dsfield((struct ipv6hdr*)old_iph); + inner = ipv6_get_dsfield((struct ipv6hdr *)old_iph); return INET_ECN_encapsulate(tos, inner); } ===== net/ipv6/sit.c 1.40 vs edited ===== --- 1.40/net/ipv6/sit.c 2004-09-09 06:37:53 +10:00 +++ edited/net/ipv6/sit.c 2004-09-16 21:43:53 +10:00 @@ -50,6 +50,7 @@ #include #include #include +#include /* This version of net/ipv6/sit.c is cloned of net/ipv4/ip_gre.c @@ -566,7 +567,7 @@ iph->frag_off = 0; iph->protocol = IPPROTO_IPV6; - iph->tos = INET_ECN_encapsulate(tos, ip6_get_dsfield(iph6)); + iph->tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6)); iph->daddr = rt->rt_dst; iph->saddr = rt->rt_src; ===== net/ipv6/tcp_ipv6.c 1.94 vs edited ===== --- 1.94/net/ipv6/tcp_ipv6.c 2004-09-08 03:00:52 +10:00 +++ edited/net/ipv6/tcp_ipv6.c 2004-09-16 21:44:44 +10:00 @@ -57,6 +57,7 @@ #include #include #include +#include #include @@ -1646,7 +1647,7 @@ skb->len - th->doff*4); TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq); TCP_SKB_CB(skb)->when = 0; - TCP_SKB_CB(skb)->flags = ip6_get_dsfield(skb->nh.ipv6h); + TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(skb->nh.ipv6h); TCP_SKB_CB(skb)->sacked = 0; sk = __tcp_v6_lookup(&skb->nh.ipv6h->saddr, th->source, ===== net/ipv6/xfrm6_input.c 1.18 vs edited ===== --- 1.18/net/ipv6/xfrm6_input.c 2004-09-09 06:37:53 +10:00 +++ edited/net/ipv6/xfrm6_input.c 2004-09-16 21:44:59 +10:00 @@ -11,6 +11,7 @@ #include #include +#include #include #include #include @@ -21,7 +22,7 @@ struct ipv6hdr *outer_iph = skb->nh.ipv6h; struct ipv6hdr *inner_iph = skb->h.ipv6h; - if (INET_ECN_is_ce(ip6_get_dsfield(outer_iph))) + if (INET_ECN_is_ce(ipv6_get_dsfield(outer_iph))) IP6_ECN_set_ce(inner_iph); } ===== net/sched/sch_red.c 1.16 vs edited ===== --- 1.16/net/sched/sch_red.c 2004-09-09 06:37:53 +10:00 +++ edited/net/sched/sch_red.c 2004-09-16 21:45:24 +10:00 @@ -40,6 +40,7 @@ #include #include #include +#include /* Random Early Detection (RED) algorithm. @@ -167,7 +168,7 @@ IP_ECN_set_ce(skb->nh.iph); return 1; case __constant_htons(ETH_P_IPV6): - if (INET_ECN_is_not_ect(ip6_get_dsfield(skb->nh.ipv6h))) + if (INET_ECN_is_not_ect(ipv6_get_dsfield(skb->nh.ipv6h))) return 0; IP6_ECN_set_ce(skb->nh.ipv6h); return 1; --J2SCkAp4GZ/dPZZf-- From hadi@cyberus.ca Thu Sep 16 05:09:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 05:09:31 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GC9PB2027981 for ; Thu, 16 Sep 2004 05:09:25 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C7v4Z-0002gL-RV for netdev@oss.sgi.com; Thu, 16 Sep 2004 08:09:11 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C7v4Y-0001cl-6A; Thu, 16 Sep 2004 08:09:10 -0400 Subject: Re: Kernel connector - userspace <-> kernelspace "linker". From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: netdev@oss.sgi.com In-Reply-To: <1095331899.18219.58.camel@uganda> References: <1095331899.18219.58.camel@uganda> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095336548.1064.167.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Sep 2004 08:09:08 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 8925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1283 Lines: 31 On Thu, 2004-09-16 at 06:51, Evgeniy Polyakov wrote: > Hmm, do not know how to describe... > Kind of mega-picture can be found at > http://tservice.net.ru/~s0mbre/?section=gallery&item=connector_design > > This driver adds possibility to connect anything with anything using > netlink based network. > One must register callback and identificator. When driver receives > special netlink message with appropriate identificator, appropriate > callback will be called. > I think that the code better explains what I'm trying to say. I dont have time to evaluate the code right now - but will at the end of day. Just trying to understand your concepts: Essentially you are building a unified messaging for userspace-userpace(i.e IPC), userspace-kernel, kernel-kernel with each component residing in whatever spot (kernel or userland)having a unique name and Id. Is this correct? Clearly there could be name/Id conflicts etc. Are you addressing those? Any event and filtering capability already in or planned? Example event I want to be notified when module with name "sean paul" comes online and filter will be "it has to have ID in the range of 0x200-0x400". I am still trying to wakeup but it does sound like a good idea to have a generic messaging subsystem. cheers, jamal From herbert@gondor.apana.org.au Thu Sep 16 05:40:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 05:40:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GCeVMs029135 for ; Thu, 16 Sep 2004 05:40:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C7vYF-0006cz-00; Thu, 16 Sep 2004 22:39:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C7vY3-0001hL-00; Thu, 16 Sep 2004 22:39:39 +1000 Date: Thu, 16 Sep 2004 22:39:39 +1000 To: "David S. Miller" , YOSHIFUJI Hideaki , James Morris , netdev@oss.sgi.com Subject: [IPSEC] Implement DSCP decapsulation Message-ID: <20040916123939.GA3403@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 8926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3788 Lines: 112 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: This patch adds DSCP decapsulation for IPsec. This is enabled by a per-state flag which is off by default. Leaving it off by default maintains compatibility and is also good for performance reasons. I decided to not implement a toggle on the output path since not encapsulating the DSCP can and should be done by netfilter. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/linux/pfkeyv2.h 1.10 vs edited ===== --- 1.10/include/linux/pfkeyv2.h 2004-04-20 04:42:38 +10:00 +++ edited/include/linux/pfkeyv2.h 2004-09-16 21:58:42 +10:00 @@ -245,6 +245,7 @@ /* Security Association flags */ #define SADB_SAFLAGS_PFS 1 +#define SADB_SAFLAGS_DECAP_DSCP 0x40000000 #define SADB_SAFLAGS_NOECN 0x80000000 /* Security Association states */ ===== include/linux/xfrm.h 1.25 vs edited ===== --- 1.25/include/linux/xfrm.h 2004-07-12 20:00:21 +10:00 +++ edited/include/linux/xfrm.h 2004-09-16 21:58:42 +10:00 @@ -190,6 +190,7 @@ __u8 replay_window; __u8 flags; #define XFRM_STATE_NOECN 1 +#define XFRM_STATE_DECAP_DSCP 2 }; struct xfrm_usersa_id { ===== include/net/inet_ecn.h 1.11 vs edited ===== --- 1.11/include/net/inet_ecn.h 2004-09-16 21:58:08 +10:00 +++ edited/include/net/inet_ecn.h 2004-09-16 22:32:25 +10:00 @@ -78,6 +78,12 @@ iph->tos &= ~INET_ECN_MASK; } +static inline void ipv4_copy_dscp(struct iphdr *outer, struct iphdr *inner) +{ + u32 dscp = ipv4_get_dsfield(outer) & ~INET_ECN_MASK; + ipv4_change_dsfield(inner, INET_ECN_MASK, dscp); +} + struct ipv6hdr; static inline void IP6_ECN_set_ce(struct ipv6hdr *iph) ===== net/ipv4/xfrm4_input.c 1.12 vs edited ===== --- 1.12/net/ipv4/xfrm4_input.c 2004-09-09 21:48:58 +10:00 +++ edited/net/ipv4/xfrm4_input.c 2004-09-16 22:03:27 +10:00 @@ -101,6 +101,8 @@ if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) goto drop; + if (x->props.flags & XFRM_STATE_DECAP_DSCP) + ipv4_copy_dscp(iph, skb->h.ipiph); if (!(x->props.flags & XFRM_STATE_NOECN)) ipip_ecn_decapsulate(skb); skb->mac.raw = memmove(skb->data - skb->mac_len, ===== net/ipv6/xfrm6_input.c 1.22 vs edited ===== --- 1.22/net/ipv6/xfrm6_input.c 2004-09-16 21:58:08 +10:00 +++ edited/net/ipv6/xfrm6_input.c 2004-09-16 22:03:04 +10:00 @@ -88,6 +88,8 @@ if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) goto drop; + if (x->props.flags & XFRM_STATE_DECAP_DSCP) + ipv6_copy_dscp(skb->nh.ipv6h, skb->h.ipv6h); if (!(x->props.flags & XFRM_STATE_NOECN)) ipip6_ecn_decapsulate(skb); skb->mac.raw = memmove(skb->data - skb->mac_len, ===== net/key/af_key.c 1.69 vs edited ===== --- 1.69/net/key/af_key.c 2004-09-12 21:51:42 +10:00 +++ edited/net/key/af_key.c 2004-09-16 21:58:43 +10:00 @@ -683,6 +683,8 @@ sa->sadb_sa_flags = 0; if (x->props.flags & XFRM_STATE_NOECN) sa->sadb_sa_flags |= SADB_SAFLAGS_NOECN; + if (x->props.flags & XFRM_STATE_DECAP_DSCP) + sa->sadb_sa_flags |= SADB_SAFLAGS_DECAP_DSCP; /* hard time */ if (hsc & 2) { @@ -965,6 +967,8 @@ x->props.replay_window = sa->sadb_sa_replay; if (sa->sadb_sa_flags & SADB_SAFLAGS_NOECN) x->props.flags |= XFRM_STATE_NOECN; + if (sa->sadb_sa_flags & SADB_SAFLAGS_DECAP_DSCP) + x->props.flags |= XFRM_STATE_DECAP_DSCP; lifetime = (struct sadb_lifetime*) ext_hdrs[SADB_EXT_LIFETIME_HARD-1]; if (lifetime != NULL) { --BXVAT5kNtrzKuDFl-- From leonid.grossman@s2io.com Thu Sep 16 06:11:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:11:46 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDBdfD030164 for ; Thu, 16 Sep 2004 06:11:39 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8GDApje014445; Thu, 16 Sep 2004 09:10:51 -0400 (EDT) Received: from lgt40 ([192.168.0.7]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8GDAnqG005123; Thu, 16 Sep 2004 09:10:49 -0400 (EDT) Message-Id: <200409161310.i8GDAnqG005123@guinness.s2io.com> From: "Leonid Grossman" To: "'Andi Kleen'" , "'David S. Miller'" Cc: "'John Heffner'" , Subject: RE: The ultimate TOE design Date: Thu, 16 Sep 2004 06:10:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSbtUdAVlJKbWtuT2WwPjWidudMagANpfOg In-Reply-To: <20040916062033.GB12915@wotan.suse.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 1781 Lines: 50 > -----Original Message----- > From: Andi Kleen [mailto:ak@suse.de] > Sent: Wednesday, September 15, 2004 11:21 PM > To: David S. Miller > Cc: John Heffner; netdev@oss.sgi.com; leonid.grossman@s2io.com > Subject: Re: The ultimate TOE design > > On Wed, Sep 15, 2004 at 02:46:24PM -0700, David S. Miller wrote: > > On Wed, 15 Sep 2004 17:36:18 -0400 (EDT) John Heffner > > wrote: > > > > > The other (much nicer) solution to case (b) is to just > USE A BIGGER MTU. > > > 1500 bytes is ridiculously small. Even with a 9k MTU, > the benefits > > > of TOE or TSO are nearly vanishing. Those who say they > require high > > > performance, but are unwilling to buy or produce networking gear > > > with an MTU larger than 1500 bytes probably deserve what they get. > > > > TSO gives a kind of virtual 64K MTU, FWIW. But I do see your point. > > We still need to solve the same problem for RX though. > > -Andi Ditto. We can dream about benefits of huge MTUs, but the reality is that moving beyond 9k MTU is years away. Reasons - mainly infrastructure, plus MTU above ~10k may loose checksum protection (granted, this depends whether the errors are simple or complex, and also this may not be a showstopper for some people). Even 9k MTU is very far from being universally accepted, eight years after our Alteon spec went out :-). TSO works great for the transmit side (even for 9k MTU, the impact is not insignificant), but RX problem that Andi is talking about is a major issue for a lot of users. I don't have hard data yet, but the expectations are that the effect of doing "RX side TSO" will be close to having 64k RX MTU - I'll publish some numbers once we bring up first Unix drivers with this feature and do some measurements. Leonid > From Valdis.Kletnieks@vt.edu Thu Sep 16 06:15:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:15:39 -0700 (PDT) Received: from turing-police.cc.vt.edu (IDENT:root@turing-police.cc.vt.edu [128.173.14.107]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDFYkJ030524 for ; Thu, 16 Sep 2004 06:15:35 -0700 Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.13.1/8.13.1) with ESMTP id i8G6XClT019796; Thu, 16 Sep 2004 02:33:14 -0400 Message-Id: <200409160633.i8G6XClT019796@turing-police.cc.vt.edu> X-Mailer: exmh version 2.7.1 07/26/2004 with nmh-1.1-RC3 To: David Stevens Cc: Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design In-Reply-To: Your message of "Wed, 15 Sep 2004 14:11:04 MDT." From: Valdis.Kletnieks@vt.edu References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1833311858P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 16 Sep 2004 02:33:10 -0400 X-archive-position: 8928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: netdev Content-Length: 1765 Lines: 45 --==_Exmh_1833311858P Content-Type: text/plain; charset=us-ascii On Wed, 15 Sep 2004 14:11:04 MDT, David Stevens said: > Why don't we off-load filesystems to disks instead? Or a graphics > card that implements X ? :-) I'd rather have shared system resources-- > more flexible. :-) All depends where in the "cycle of reincarnation" we are at the moment. Way back in 1964, IBM released this monster called System/360 - and one of the things it did was push a *lot* of the disk processing off on the channel and disk controller using a count-key-data format rather than the fixed-block that Linux uses. So out on the platters, the disk format would say things like "This is a 400 byte record, the first 56 of which is a search key". A lot of stuff, both userspace and OS, used things like 'Search Key Equal' and letting the disk do all the searching. There was also this terminal beast called the 3270, which had a local controller for the terminals, and only interrupted the CPU on 'page send' type events. Back then, the ideas made sense - it wasn't at all unreasonable for a single S/360-65 to drive 3,000+ concurrent terminals in an airline reservation system or similar (and we're talking about a box that had literally only half the hamsters of a VAX780). But today, the 3270 isn't seen much anymore, and currently IBM emulates the CKD format on fixed-block systems for their z/Series boxes running z/OS or whatever MVS is called now.... --==_Exmh_1833311858P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBSTOmcC3lWbTT17ARAmroAJ4t/GYMC09woAJLa4BvbV4TgxoNWwCgg0cW y50v9EReZojc6s9/HwxVc58= =yw9V -----END PGP SIGNATURE----- --==_Exmh_1833311858P-- From alan@lxorguk.ukuu.org.uk Thu Sep 16 06:23:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:24:03 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDNtPL031024 for ; Thu, 16 Sep 2004 06:23:56 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8GCJQdS022796; Thu, 16 Sep 2004 13:19:26 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8GCJPdv022795; Thu, 16 Sep 2004 13:19:25 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: The ultimate TOE design From: Alan Cox To: Lincoln Dale Cc: Jeff Garzik , "David S. Miller" , paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, Linux Kernel Mailing List In-Reply-To: <5.1.0.14.2.20040916192213.04240008@171.71.163.14> References: <20040915141346.5c5e5377.davem@davemloft.net> <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <5.1.0.14.2.20040916192213.04240008@171.71.163.14> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095337159.22739.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 16 Sep 2004 13:19:21 +0100 X-archive-position: 8929 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 414 Lines: 10 On Iau, 2004-09-16 at 10:29, Lincoln Dale wrote: > . . . this ignore the realities of power restrictions of PCI today . . . > sure, one could create a PCI card that takes a power-connector, but that > don't scale so well either . . . At 1Ghz the Athlon Geode NX draws about 6W. Thats less than my SCSI controller. I'm sure its not co-incidence that powerpc shows up on such boards a lot more than x86 however. From tgraf@suug.ch Thu Sep 16 06:28:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:28:57 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDSmaa031475 for ; Thu, 16 Sep 2004 06:28:49 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 7CB4581; Thu, 16 Sep 2004 15:28:14 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id B4D4A1C0E8; Thu, 16 Sep 2004 15:28:56 +0200 (CEST) Date: Thu, 16 Sep 2004 15:28:56 +0200 From: Thomas Graf To: "David S. Miller" Cc: Patrick McHardy , Alexey Kuznetsov , netdev@oss.sgi.com Subject: [PATCH 2.6 NET] Fixes slab corruption in cbq_destroy Message-ID: <20040916132856.GA27293@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 901 Lines: 31 Fixes slab corruption in cbq_destroy. cbq_destroy_filters and qdisc_put_rtab(q->link.R_tab) are already called in cbq_destroy_class. The latter lead to a slab corruption due to repeated freeing of q->link.R_tab because q->link is part of q->classes. Problem introduced in 1.21. Signed-off-by: Thomas Graf --- linux-2.6.9-rc2-bk2.orig/net/sched/sch_cbq.c 2004-09-16 14:52:23.000000000 +0200 +++ linux-2.6.9-rc2-bk2/net/sched/sch_cbq.c 2004-09-16 14:53:53.000000000 +0200 @@ -1770,10 +1770,6 @@ #ifdef CONFIG_NET_CLS_POLICE q->rx_class = NULL; #endif - for (h = 0; h < 16; h++) { - for (cl = q->classes[h]; cl; cl = cl->next) - cbq_destroy_filters(cl); - } for (h = 0; h < 16; h++) { struct cbq_class *next; @@ -1783,8 +1779,6 @@ cbq_destroy_class(sch, cl); } } - - qdisc_put_rtab(q->link.R_tab); } static void cbq_put(struct Qdisc *sch, unsigned long arg) From tgraf@suug.ch Thu Sep 16 06:31:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:31:17 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDVCCN031821 for ; Thu, 16 Sep 2004 06:31:13 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 44E8A81; Thu, 16 Sep 2004 15:30:40 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 2CA8C1C0E8; Thu, 16 Sep 2004 15:31:23 +0200 (CEST) Date: Thu, 16 Sep 2004 15:31:23 +0200 From: Thomas Graf To: "David S. Miller" Cc: Patrick McHardy , Alexey Kuznetsov , netdev@oss.sgi.com Subject: [PATCH 2.4 NET] Fixes slab corruption in cbq_destroy Message-ID: <20040916133123.GB27293@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 8931 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 787 Lines: 29 Backport of 2.6 patch: Fixes slab corruption in cbq_destroy. cbq_destroy_filters and qdisc_put_rtab(q->link.R_tab) are already called in cbq_destroy_class. The latter lead to a slab corruption due to repeated freeing of q->link.R_tab because q->link is part of q->classes. --- linux-2.4.28-pre3-bk2.orig/net/sched/sch_cbq.c 2004-09-16 14:59:56.000000000 +0200 +++ linux-2.4.28-pre3-bk2/net/sched/sch_cbq.c 2004-09-16 15:01:53.000000000 +0200 @@ -1736,10 +1736,6 @@ #ifdef CONFIG_NET_CLS_POLICE q->rx_class = NULL; #endif - for (h = 0; h < 16; h++) { - for (cl = q->classes[h]; cl; cl = cl->next) - cbq_destroy_filters(cl); - } for (h = 0; h < 16; h++) { struct cbq_class *next; @@ -1750,7 +1746,6 @@ } } - qdisc_put_rtab(q->link.R_tab); MOD_DEC_USE_COUNT; } From ak@suse.de Thu Sep 16 06:33:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:33:28 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDXMr7032046 for ; Thu, 16 Sep 2004 06:33:23 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 02AAEBFFB23; Thu, 16 Sep 2004 15:33:07 +0200 (CEST) Date: Thu, 16 Sep 2004 15:33:01 +0200 From: Andi Kleen To: Alan Cox Cc: Lincoln Dale , Jeff Garzik , "David S. Miller" , paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, Linux Kernel Mailing List Subject: Re: The ultimate TOE design Message-ID: <20040916133301.GA15562@wotan.suse.de> References: <20040915141346.5c5e5377.davem@davemloft.net> <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <5.1.0.14.2.20040916192213.04240008@171.71.163.14> <1095337159.22739.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095337159.22739.7.camel@localhost.localdomain> X-archive-position: 8932 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 536 Lines: 13 On Thu, Sep 16, 2004 at 01:19:21PM +0100, Alan Cox wrote: > On Iau, 2004-09-16 at 10:29, Lincoln Dale wrote: > > . . . this ignore the realities of power restrictions of PCI today . . . > > sure, one could create a PCI card that takes a power-connector, but that > > don't scale so well either . . . > > At 1Ghz the Athlon Geode NX draws about 6W. Thats less than my SCSI Are you sure that's worst case, not average? Worst case is usually much worse on a big CPU like an Athlon, but the power supply has to be sized for it. -Andi From kaber@trash.net Thu Sep 16 06:49:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 06:49:31 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GDnOoK032724 for ; Thu, 16 Sep 2004 06:49:25 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1C7wi6-0000Sw-00; Thu, 16 Sep 2004 15:54:06 +0200 Message-ID: <4149998C.6060501@trash.net> Date: Thu, 16 Sep 2004 15:47:56 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: "David S. Miller" , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fixes slab corruption in cbq_destroy References: <20040916132856.GA27293@postel.suug.ch> In-Reply-To: <20040916132856.GA27293@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 45 Thomas Graf wrote: >Fixes slab corruption in cbq_destroy. cbq_destroy_filters and >qdisc_put_rtab(q->link.R_tab) are already called in cbq_destroy_class. >The latter lead to a slab corruption due to repeated freeing of >q->link.R_tab because q->link is part of q->classes. Problem introduced >in 1.21. > > I don't see how there can be slab corruption. qdisc_put_rtab only calls kfree if the table is found in qdisc_rtab_list, which only happens once. But the patch is still fine as cleanup :) Regards Patrick >Signed-off-by: Thomas Graf > > >--- linux-2.6.9-rc2-bk2.orig/net/sched/sch_cbq.c 2004-09-16 14:52:23.000000000 +0200 >+++ linux-2.6.9-rc2-bk2/net/sched/sch_cbq.c 2004-09-16 14:53:53.000000000 +0200 >@@ -1770,10 +1770,6 @@ > #ifdef CONFIG_NET_CLS_POLICE > q->rx_class = NULL; > #endif >- for (h = 0; h < 16; h++) { >- for (cl = q->classes[h]; cl; cl = cl->next) >- cbq_destroy_filters(cl); >- } > > for (h = 0; h < 16; h++) { > struct cbq_class *next; >@@ -1783,8 +1779,6 @@ > cbq_destroy_class(sch, cl); > } > } >- >- qdisc_put_rtab(q->link.R_tab); > } > > static void cbq_put(struct Qdisc *sch, unsigned long arg) > > > From alan@lxorguk.ukuu.org.uk Thu Sep 16 07:01:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 07:02:08 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GE1sCT000903 for ; Thu, 16 Sep 2004 07:01:55 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8GCvpVi022839; Thu, 16 Sep 2004 13:57:52 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8GCvo4A022838; Thu, 16 Sep 2004 13:57:50 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: The ultimate TOE design From: Alan Cox To: Andi Kleen Cc: Lincoln Dale , Jeff Garzik , "David S. Miller" , paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, Linux Kernel Mailing List In-Reply-To: <20040916133301.GA15562@wotan.suse.de> References: <20040915141346.5c5e5377.davem@davemloft.net> <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <5.1.0.14.2.20040916192213.04240008@171.71.163.14> <1095337159.22739.7.camel@localhost.localdomain> <20040916133301.GA15562@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095339466.22739.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 16 Sep 2004 13:57:47 +0100 X-archive-position: 8934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 358 Lines: 10 On Iau, 2004-09-16 at 14:33, Andi Kleen wrote: > > At 1Ghz the Athlon Geode NX draws about 6W. Thats less than my SCSI > > Are you sure that's worst case, not average? Worst case is usually > much worse on a big CPU like an Athlon, but the power supply > has to be sized for it. You are correct - 6W average 9W TDP, still less than my scsicontroller 8) From tgraf@suug.ch Thu Sep 16 07:09:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 07:09:43 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GE9Y0o001393 for ; Thu, 16 Sep 2004 07:09:34 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 8B18481; Thu, 16 Sep 2004 16:09:01 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 4AB351C0E8; Thu, 16 Sep 2004 16:09:43 +0200 (CEST) Date: Thu, 16 Sep 2004 16:09:43 +0200 From: Thomas Graf To: Patrick McHardy Cc: "David S. Miller" , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fixes slab corruption in cbq_destroy Message-ID: <20040916140943.GC27293@postel.suug.ch> References: <20040916132856.GA27293@postel.suug.ch> <4149998C.6060501@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4149998C.6060501@trash.net> X-archive-position: 8935 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1803 Lines: 36 * Patrick McHardy <4149998C.6060501@trash.net> 2004-09-16 15:47 > Thomas Graf wrote: > > >Fixes slab corruption in cbq_destroy. cbq_destroy_filters and > >qdisc_put_rtab(q->link.R_tab) are already called in cbq_destroy_class. > >The latter lead to a slab corruption due to repeated freeing of > >q->link.R_tab because q->link is part of q->classes. Problem introduced > >in 1.21. > > > > > I don't see how there can be slab corruption. qdisc_put_rtab only > calls kfree if the table is found in qdisc_rtab_list, which only > happens once. But the patch is still fine as cleanup :) On second call to qdisc_put_rtab with tab pointing to an already freed qdisc_rate_table: sch_api.c:271: if (!tab || --tab->refcnt) Sep 16 01:52:51 axs kernel: Slab corruption: start=d8bd4f30, len=2048 Sep 16 01:52:51 axs kernel: Redzone: 0x5a2cf071/0x5a2cf071. Sep 16 01:52:51 axs kernel: Last user: [](cbq_destroy_class+0x36/0x60) Sep 16 01:52:51 axs kernel: 410: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ^^ I guess this is the --tab->refcnt Sep 16 01:52:51 axs kernel: Prev obj: start=d8bd4724, len=2048 Sep 16 01:52:51 axs kernel: Redzone: 0x170fc2a5/0x170fc2a5. Sep 16 01:52:51 axs kernel: Last user: [](qdisc_get_rtab+0x77/0xcd) Sep 16 01:52:51 axs kernel: 000: 04 00 00 00 00 00 40 00 20 bc be 00 05 00 00 00 Sep 16 01:52:51 axs kernel: 010: 05 00 00 00 05 00 00 00 05 00 00 00 05 00 00 00 Sep 16 01:52:51 axs kernel: Next obj: start=d8bd573c, len=2048 Sep 16 01:52:51 axs kernel: Redzone: 0x170fc2a5/0x170fc2a5. Sep 16 01:52:51 axs kernel: Last user: [](alloc_skb+0x48/0xe1) Sep 16 01:52:51 axs kernel: 000: 6c 04 00 00 28 00 05 06 d5 d5 48 41 00 00 00 00 Sep 16 01:52:51 axs kernel: 010: 00 00 00 00 04 00 00 00 12 00 10 00 00 00 10 00 From leonid.grossman@s2io.com Thu Sep 16 07:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 07:59:48 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GExfvn002794 for ; Thu, 16 Sep 2004 07:59:42 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8GEwIje015064; Thu, 16 Sep 2004 10:58:18 -0400 (EDT) Received: from lgt40 ([192.168.0.7]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8GEvtqH022604; Thu, 16 Sep 2004 10:58:05 -0400 (EDT) Message-Id: <200409161458.i8GEvtqH022604@guinness.s2io.com> From: "Leonid Grossman" To: Cc: "'Jeff Garzik'" , "'David S. Miller'" , , , , Subject: RE: The ultimate TOE design Date: Thu, 16 Sep 2004 07:57:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSb06dFuGUNFy82T+We47s42jS1ggAG/ENA In-Reply-To: <1095328673.1063.130.camel@jzny.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8936 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 5652 Lines: 158 > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Thursday, September 16, 2004 2:58 AM > To: Leonid Grossman > Cc: 'Jeff Garzik'; 'David S. Miller'; > alan@lxorguk.ukuu.org.uk; paul@clubi.ie; netdev@oss.sgi.com; > linux-kernel@vger.kernel.org > Subject: RE: The ultimate TOE design > > On Thu, 2004-09-16 at 01:25, Leonid Grossman wrote: > > > > > -----Original Message----- > > > From: jamal [mailto:hadi@cyberus.ca] > > > > On a serious note, I think that PCI-express (if it lives upto its > > > expectation) will demolish dreams of a lot of these TOE > investments. > > > Our problem is NOT the CPU right now (80% idle processing 450Kpps > > > forwarding). Bus and memory distance/latency are. > > > > In servers, both bottlenecks are there - if you look at the cost of > > TCP and filesystem processing at 10GbE, CPU is a huge problem (and > > will be for foreseeable future), even for fastest 64-bit systems. > > True, but with the bus contention being a non-issue you got > more of that xeon being available for use (lets say i can use > 50% more of its capacity then i can do more). IOW, it becomes > a compute capacity problem mostly - one that you should in > theory be able to throw more CPU at. SMT (the way power5 and > some of the network processors do it[1]) should go a long way > to address both additional compute and hardware threading to > work around memory latencies. With PCI-express, compute power > in mini-clustering in the form of AS > (http://www.asi-sig.org/home) is being plotted as we speak. > To sumarize: The problem to solve in 24 months maybe 100Gige. > > > I agree though that bus and memory are bigger issues, this > is exactly > > the reason for all these RDMA over Ethernet investments :-) > > And AS does a damn good job at specing all those RDMA > requirements; my view is that intel is going to build them > chips - so it can be done on a > $5 board off the pacific rim. This takes most of the small > players out of the market. > > > Anyways, did not mean to start an argument - with all the > new CPU, bus > > and HBA technologies coming to the market it will be another 18-24 > > months before we know what works and what doesn't... > > Agreed. Would you like to invest on something that will obsoleted in > 18-24 months though? OR even not obsoleted, but holds that > uncertainty? > I think thats the risk facing you when you are in the offload > bussiness. Well.. Any business has risks, this one doesn't seem to be higher than others :-) I view 18-26 mo timeframe as a start of the offload mass-adoption, not the end of it. In our tests, the bus contention and the %cpu are mostly orthogonal problems; PCI-X DDR and PCI-Express will help but only to a point. (BTW this is all related to the higher end systems - 2-4 way and above, running 10GbE NICs. Client is a different story, cpu is mostly "free" there). My sense is that (unlike on previous cycles) the "slow host, fast network" scenario is here to stay for a long while, and will have to be addressed one way or another - whether it is a full TOE+RDMA offload in a longer run, or an improvement to "static" offloads. In server space, applications will never be happy with less than 80% cpu. Leonid > > Here are results for Hifn 7956 ref board on 2.6GHz P4 (HT) > system, kernel 2.6.6 SMP as compared to a s/ware only setup > on same machine. > [Name of tester withheld to protect privacy]. > > first column - algo, second - packet size, third - time in us > spend by hw crypto, forth - time in us spent by sw crypto: > > des 64: 28 3 > des 128: 29 6 > des 192: 33 9 > des 256: 33 12 > des 320: 37 15 > des 384: 38 18 > des 448: 41 21 > des 512: 42 23 > des 576: 45 26 > des 640: 46 29 > des 704: 49 33 > des 768: 50 35 > des 832: 53 38 > des 896: 54 41 > des 960: 57 44 > des 1024: 58 47 > des 1088: 61 50 > des 1152: 62 53 > des 1216: 66 56 > des 1280: 66 59 > des 1344: 70 62 > des 1408: 71 65 > des 1472: 74 68 > des3_ede 64: 28 6 > des3_ede 128: 30 13 > des3_ede 192: 34 20 > des3_ede 256: 43 26 > des3_ede 320: 38 33 > des3_ede 384: 48 40 > des3_ede 448: 44 45 > des3_ede 512: 54 53 > des3_ede 576: 50 60 > des3_ede 640: 59 67 > des3_ede 704: 55 74 > des3_ede 768: 66 78 > des3_ede 832: 61 85 > des3_ede 896: 72 94 > des3_ede 960: 67 100 > des3_ede 1024: 77 107 > des3_ede 1088: 73 114 > des3_ede 1152: 82 121 > des3_ede 1216: 79 127 > des3_ede 1280: 88 128 > des3_ede 1344: 84 135 > des3_ede 1408: 94 147 > des3_ede 1472: 90 153 > aes 64: 28 2 > aes 192: 33 6 > aes 320: 37 10 > aes 448: 46 15 > aes 576: 53 19 > aes 704: 53 23 > aes 832: 65 28 > aes 960: 66 32 > aes 1088: 71 37 > aes 1216: 80 41 > aes 1344: 83 45 > aes 1472: 92 50 > > Moral of the data above: The 2.6Ghz is already showing signs > of obsoleting the hifn crypto offloader[2]. I think it took > less than a year for it to happen. > > cheers, > jamal > > [1] I also like the MIPS.com approach to SMT > > [2] There are actually issues with some of the crypto > offloading in Linux; however this does serve as a good example. > From kaber@trash.net Thu Sep 16 08:00:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 08:00:07 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GF00XB002832 for ; Thu, 16 Sep 2004 08:00:01 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1C7xoJ-0000ap-00; Thu, 16 Sep 2004 17:04:36 +0200 Message-ID: <4149AA12.10306@trash.net> Date: Thu, 16 Sep 2004 16:58:26 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Thomas Graf CC: "David S. Miller" , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fixes slab corruption in cbq_destroy References: <20040916132856.GA27293@postel.suug.ch> <4149998C.6060501@trash.net> <20040916140943.GC27293@postel.suug.ch> In-Reply-To: <20040916140943.GC27293@postel.suug.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 531 Lines: 22 Thomas Graf wrote: >* Patrick McHardy <4149998C.6060501@trash.net> 2004-09-16 15:47 > > >>I don't see how there can be slab corruption. qdisc_put_rtab only >>calls kfree if the table is found in qdisc_rtab_list, which only >>happens once. But the patch is still fine as cleanup :) >> >> > >On second call to qdisc_put_rtab with tab pointing to an already >freed qdisc_rate_table: > >sch_api.c:271: if (!tab || --tab->refcnt) > > You're right, no double free but accessing and modifying of freed memory. Regards Patrick From johnpol@2ka.mipt.ru Thu Sep 16 08:48:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 08:48:46 -0700 (PDT) Received: from ffke-campus-gw.mipt.ru (ffke-campus-gw.mipt.ru [194.85.82.65]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GFme6v007395 for ; Thu, 16 Sep 2004 08:48:41 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by ffke-campus-gw.mipt.ru (8.12.11/8.12.11) with SMTP id i8GFoSQh011897; Thu, 16 Sep 2004 19:50:30 +0400 Date: Thu, 16 Sep 2004 20:03:04 +0400 From: Evgeniy Polyakov To: jamal Cc: netdev@oss.sgi.com, Evgeniy Polyakov Subject: Re: Kernel connector - userspace <-> kernelspace "linker". Message-Id: <20040916200304.4fad9b6d@zanzibar.2ka.mipt.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1765 Lines: 43 Sorry for thread destruction, but I have not received you mail, but see it in archive. I do beleive it is due to permanent glitch of 2ka.mipt.ru SMTP server. > I dont have time to evaluate the code right now - but will at the end of > day. Just trying to understand your concepts: > > Essentially you are building a unified messaging for > userspace-userpace(i.e IPC), userspace-kernel, kernel-kernel with each > component residing in whatever spot (kernel or userland)having a unique > name and Id. Is this correct? Actually name and ID should be transformed to ID0 and ID1(they are callled idx and val and are u32 values, since I strongly object against any ASCII based identificators( sigh, I am cunning - superio has such ids)). Since userspace can not register callback function, then it is not quite fair to call it generic, but the idea is right. > Clearly there could be name/Id conflicts etc. Are you addressing those? Hmm, u32+u32 - I do not beleive that it can conflict, but if they do, then first registered with given idx+val will pay the pipper and call the tune. Second call with the same parameters for register_callback() fill fail. > Any event and filtering capability already in or planned? Example event > I want to be notified when module with name "sean paul" comes online and > filter will be "it has to have ID in the range of 0x200-0x400". Such information does exist in connector driver and it _can_ be easily obtained. I will call it feature request that fits the design and will implement this today/tomorrow. :) > I am still trying to wakeup but it does sound like a good idea to have a > generic messaging subsystem. Good afternoon :). cheers, jamal Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From niv@us.ibm.com Thu Sep 16 09:18:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 09:18:58 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GGIlAj008203 for ; Thu, 16 Sep 2004 09:18:53 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (sccrmhc13) with ESMTP id <2004091616183001600mkv8de>; Thu, 16 Sep 2004 16:18:31 +0000 Message-ID: <4149BCE9.7040501@us.ibm.com> Date: Thu, 16 Sep 2004 09:18:49 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leonid Grossman CC: "'Andi Kleen'" , "'David S. Miller'" , "'John Heffner'" , netdev@oss.sgi.com Subject: Re: The ultimate TOE design References: <200409161310.i8GDAnqG005123@guinness.s2io.com> In-Reply-To: <200409161310.i8GDAnqG005123@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 596 Lines: 18 Leonid Grossman wrote: > We can dream about benefits of huge MTUs, but the reality is that moving > beyond 9k MTU is years away. Reasons - mainly infrastructure, plus MTU above > ~10k may loose checksum protection (granted, this depends whether the errors > are simple or complex, and also this may not be a showstopper for some > people). > Even 9k MTU is very far from being universally accepted, eight years after > our Alteon spec went out :-). One other factor is TCP congestion control, and congestion windows we obey. Most of the time, you just can't send that much. thanks, Nivedita From roland@topspin.com Thu Sep 16 09:36:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 09:36:52 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GGajUt008993 for ; Thu, 16 Sep 2004 09:36:46 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Sep 2004 09:36:35 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Sep 2004 09:36:35 -0700 Received: from roland by eddore with local (Exim 4.34) id 1C7zFL-0005Ov-3Z; Thu, 16 Sep 2004 09:36:35 -0700 To: cramerj@intel.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH][resend] Update e1000 to use module_param() X-Message-Flag: Warning: May contain useful information From: Roland Dreier Date: Thu, 16 Sep 2004 09:36:35 -0700 Message-ID: <52oek6tbl8.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 16 Sep 2004 16:36:35.0103 (UTC) FILETIME=[5497E2F0:01C49C0B] X-archive-position: 8940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 1581 Lines: 43 (resending because this seems to have been lost; e1000 still has mixed MODULE_PARM and module_param use) The change to e1000_main.c in ChangeSet@1.1722.32.6, 2004-05-27 13:44:06-04:00, ganesh.venkatesan@intel.com [PATCH] e1000 7/7: Support for ethtool msglevel based error added module_param(debug, ...) to e1000_main.c. Since e1000_param.c still uses MODULE_PARM(), this means that one gets e1000: Ignoring new-style parameters in presence of obsolete ones when e1000 is loaded, so the debug parameter cannot even be set. The patch below fixes this by updating e1000_param.c to use module_param() as well. Since module_param might make the parameters visible in sysfs, I removed the __devinitdata notation from the parameter arrays as well, just to be safe. Thanks, Roland Signed-off-by: Roland Dreier Index: linux-2.6.8.1/drivers/net/e1000/e1000_param.c =================================================================== --- linux-2.6.8.1.orig/drivers/net/e1000/e1000_param.c 2004-08-14 03:55:48.000000000 -0700 +++ linux-2.6.8.1/drivers/net/e1000/e1000_param.c 2004-08-15 08:16:31.109671753 -0700 @@ -55,9 +55,11 @@ * over and over (plus this helps to avoid typo bugs). */ +static int param_count; + #define E1000_PARAM(X, S) \ -static const int __devinitdata X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ -MODULE_PARM(X, "1-" __MODULE_STRING(E1000_MAX_NIC) "i"); \ +static int X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ +module_param_array(X, int, param_count, 0); \ MODULE_PARM_DESC(X, S); /* Transmit Descriptor Count From zilvinas@gemtek.lt Thu Sep 16 11:11:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 11:11:45 -0700 (PDT) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GIBbbK011780 for ; Thu, 16 Sep 2004 11:11:38 -0700 Received: from [192.168.3.3] ([192.168.2.249]) by barclay.balt.net (8.12.11/8.12.11/Debian-5) with ESMTP id i8GIAsMn028993 for ; Thu, 16 Sep 2004 21:10:54 +0300 Subject: Crypto tests via tcrypt.o modules failes From: Zilvinas Valinskas Reply-To: zilvinas@gemtek.lt To: netdev@oss.sgi.com Content-Type: text/plain Organization: Gemtek Baltic Message-Id: <1095358282.3359.83.camel@swoop.gemtek.lt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 21:11:22 +0300 Content-Transfer-Encoding: 7bit X-archive-position: 8941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev Content-Length: 1521 Lines: 45 Hello, I've got here Xscale IXP425, vanilla linux 2.4.27 + ipsec + Xscale arch patch (I use IPsec patch backported from 2.6 kernel by Herbert Xu). I've successfully compiled kernel, and booted on Xscale and Intel CPUs. Loaded encryption modules and ran 'insmod tcrypt.o' to verify if encryption is fine. Not all tests went through. Details are here,http://www.gemtek.lt/~zilvinas/crypto/tcrypt-tests Further testing reveals : 1. AH with 'Null' encryption and w/o IPComp works just fine. 2. I've tried ESP with AES-CBC. 2.1 <-> no luck, computers can't ping each other. (the same linux 2.4.27 + ipsec kernel on both boards). 2.2 <-> , the same 2.4.27 + ipsec kernel was used, compiled for a different architectures though. No luck either. 2.3 <-> - no luch either. 2.4 <-> success, with ESP/AES-CBC, AH ... Does it mean, crypto is not big-endian safe/clean ? Any pointers where to start or ideas how to track and fix - are welcome. (I don't have much expertise here though .. Never too late to start learning). I would say Xscale IXP425 has a rather interesting 32, 16 bits read/write results if address is not aligned properly. In the same directory - http://www.gemtek.lt/~zilvinas/crypto/ i've put *.pdf describing what exactly is happening. Perhaps that is a culprit ? Thank you, I appreciate any help. ps. I am not subscribed to netdev@oss.sgi.com, please keep me on CC: From jdmason@us.ibm.com Thu Sep 16 11:21:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 11:21:14 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GIL6bG012200 for ; Thu, 16 Sep 2004 11:21:07 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8GIKImf177706; Thu, 16 Sep 2004 14:20:19 -0400 Received: from dyn94194162.austin.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8GIKHGv063210; Thu, 16 Sep 2004 12:20:18 -0600 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Date: Thu, 16 Sep 2004 13:20:16 -0500 User-Agent: KMail/1.6.2 Cc: Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com References: <200409130035.50823.hfvogt@arcor.de> <200409160132.34160.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> In-Reply-To: <20040916070211.GA32592@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> X-archive-position: 8942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1931 Lines: 45 > Jon, if your ppc64 box offers 64 bits wide PCI slots, it would be nice if > you could ttry 2.6.9-rc2-bkX, apply > http://www.fr.zoreil.com/people/francois/misc/r8169-xx0.patch > and report the content of the "Config2" line in the logs of the kernel. Here is the info you requested: r8169 Gigabit Ethernet driver 1.6LK loaded eth8: Identified chip type is 'RTL8169s/8110s'. eth8: RTL8169 at 0xa0000000800b7000, 00:40:f4:96:fc:3f, IRQ 131 r8169: eth8: Config2 = 0x01 r8169: eth8: link up My p630 has 64bit PCI-X slots, but my r8169 adapter is a 32bit adapter. See lspci output below (with a 64bit PCI-X e1000 adapter as a comparison). ..... 0001:61:01.1 Ethernet controller: Intel Corp. 82546GB Gigabit Ethernet Controller (rev 03) Subsystem: IBM: Unknown device 0289 Flags: bus master, 66Mhz, medium devsel, latency 144, IRQ 122 Memory at cc100000 (64-bit, non-prefetchable) [size=cc000000] Memory at cc040000 (64-bit, non-prefetchable) [size=256K] I/O ports at 12ec00 [size=64] Expansion ROM at 00040000 [disabled] Capabilities: [dc] Power Management version 2 Capabilities: [e4] Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- ...... 0002:01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Flags: bus master, 66Mhz, medium devsel, latency 74, IRQ 131 I/O ports at 20fc00 [size=e0000000] Memory at e0020000 (32-bit, non-prefetchable) [size=256] Expansion ROM at 00020000 [disabled] Capabilities: [dc] Power Management version 2 I think my AMD64 system at home has a 64bit integrated adapter, as the performance on it is 2.5x faster (either that or r8169 and ppc don't play well together). I will verify this when I get home. -- Jon Mason jdmason@us.ibm.com From fernando@gont.com.ar Thu Sep 16 12:23:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 12:23:51 -0700 (PDT) Received: from libertad.frh.utn.edu.ar (libertad.frh.utn.edu.ar [170.210.17.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GJNg2J017199 for ; Thu, 16 Sep 2004 12:23:43 -0700 Received: from fernando.gont.com.ar ([200.68.238.155]) by libertad.frh.utn.edu.ar (8.9.3/8.8.7) with ESMTP id RAA24213; Thu, 16 Sep 2004 17:01:26 -0400 Message-Id: <4.3.2.7.2.20040916162351.00e16d00@pop.gmx.net> X-Sender: fgont@mail.daleclick.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Sep 2004 16:34:51 -0300 To: "David S. Miller" , Fernando Gont From: Fernando Gont Subject: Re: ICMP attacks against TCP Cc: netdev@oss.sgi.com In-Reply-To: <20040913160133.69185327.davem@davemloft.net> References: <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> <4.3.2.7.2.20040912223315.00df2890@mail.daleclick.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fernando@gont.com.ar Precedence: bulk X-list: netdev Content-Length: 481 Lines: 20 At 16:01 13/09/2004 -0700, David S. Miller wrote: > > There are some other work-arounds (for example, ignoring ICMP Source > Quench > > messages) are not implemented in Linux, though. > >I have no problem changing Linux to ignore these ICMP Source Quench >messages, I completely agree with the draft. I've made the >change in both my 2.4.x and 2.6.x trees as follows: Great! Thanks so much for your feedback! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From jmorris@redhat.com Thu Sep 16 12:25:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 12:26:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GJPv6i017553 for ; Thu, 16 Sep 2004 12:25:57 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8GJPjVN005822; Thu, 16 Sep 2004 15:25:45 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8GJPir24237; Thu, 16 Sep 2004 15:25:44 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8GJPiiS022900; Thu, 16 Sep 2004 15:25:44 -0400 Date: Thu, 16 Sep 2004 15:25:44 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Zilvinas Valinskas cc: netdev@oss.sgi.com Subject: Re: Crypto tests via tcrypt.o modules failes In-Reply-To: <1095358282.3359.83.camel@swoop.gemtek.lt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 344 Lines: 21 On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > Details are here,http://www.gemtek.lt/~zilvinas/crypto/tcrypt-tests AES is failing, but it has proven to be endian safe on other architectures. Where does the 'fig' come from in: <4>decrypt: fig Can you try a completely unpatched kernel? - James -- James Morris From jmorris@redhat.com Thu Sep 16 12:29:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 12:29:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GJTM0G017888 for ; Thu, 16 Sep 2004 12:29:22 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8GJTAT5006599; Thu, 16 Sep 2004 15:29:10 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8GJTAr25042; Thu, 16 Sep 2004 15:29:10 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8GJTAiS023052; Thu, 16 Sep 2004 15:29:10 -0400 Date: Thu, 16 Sep 2004 15:29:10 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Zilvinas Valinskas cc: netdev@oss.sgi.com Subject: Re: Crypto tests via tcrypt.o modules failes In-Reply-To: <1095358282.3359.83.camel@swoop.gemtek.lt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 307 Lines: 15 On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > I would say Xscale IXP425 has a rather interesting 32, 16 bits > read/write results if address is not aligned properly. Odd, no other algorithms seem to be having any problems. Can you post your .config? - James -- James Morris From davem@davemloft.net Thu Sep 16 13:16:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:16:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKGPjM019733 for ; Thu, 16 Sep 2004 13:16:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C82cm-000424-00; Thu, 16 Sep 2004 13:13:00 -0700 Date: Thu, 16 Sep 2004 13:13:00 -0700 From: "David S. Miller" To: Eric Lemoine Cc: netdev@oss.sgi.com Subject: Re: [SUNGEM] LLTX support Message-Id: <20040916131300.6388d432.davem@davemloft.net> In-Reply-To: <5cac192f04091514433c9e13c8@mail.gmail.com> References: <5cac192f04091423453ae3cb@mail.gmail.com> <20040915083559.6c36759f.davem@davemloft.net> <5cac192f04091514433c9e13c8@mail.gmail.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 767 Lines: 20 On Wed, 15 Sep 2004 23:43:16 +0200 Eric Lemoine wrote: > On Wed, 15 Sep 2004 08:35:59 -0700, David S. Miller wrote: > > On Wed, 15 Sep 2004 08:45:21 +0200 > > Eric Lemoine wrote: > > > > > The attached patch adds LLTX support to SunGEM NAPI. The tx_lock patch > > > I just sent must be applied first. > > > > Also applied, thanks Eric. > > > > I remember you mentioning yesterday that Harald's sungem NAPI > > patch had netpoll support, can you cook up a patch that adds > > it for current sungem? > > Patch attached. Unlike Harald's, this patch doesn't disable_irq before > calling gem_interrupt because gem_interrupt is safe to reentrance. Looks fine to me. Patch applied, thanks Eric. From davem@davemloft.net Thu Sep 16 13:17:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:17:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKHP9r019935 for ; Thu, 16 Sep 2004 13:17:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C82eC-00042Q-00; Thu, 16 Sep 2004 13:14:28 -0700 Date: Thu, 16 Sep 2004 13:14:28 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] [IPV6] NDISC: ensure responding to NS without link-layer information. Message-Id: <20040916131428.39736d91.davem@davemloft.net> In-Reply-To: <20040916.125921.56481183.yoshfuji@linux-ipv6.org> References: <20040916.125921.56481183.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8GKHP9r019935 X-archive-position: 8947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 607 Lines: 17 On Thu, 16 Sep 2004 12:59:21 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > When sending NA in response to NS, we may not know the > link-layer address for the destination of the NA > since unicast NS is not required to include its link-layer information. > In this case, we first need to resolve the link-layer address. > (RFC 2461 7.2.4) > > We now create neighbour entry for the destination > and link-layer information will be automatically solved > in the output path. > > Signed-off-by: Hideaki YOSHIFUJI Patch applied, thank you. From davem@davemloft.net Thu Sep 16 13:29:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:29:49 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKTghB020552 for ; Thu, 16 Sep 2004 13:29:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C82px-00044S-00; Thu, 16 Sep 2004 13:26:37 -0700 Date: Thu, 16 Sep 2004 13:26:37 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [INET] Kill ip6_get_dsfield Message-Id: <20040916132637.69a07e57.davem@davemloft.net> In-Reply-To: <20040916115827.GA29046@gondor.apana.org.au> References: <20040916115827.GA29046@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 309 Lines: 9 On Thu, 16 Sep 2004 21:58:28 +1000 Herbert Xu wrote: > This patch kills the duplicate implementation of ip6_get_dsfield in > inet_ecn.h. It now uses ipv6_get_dsfield from dsfield.h instead. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Thu Sep 16 13:31:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:31:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKVP8L020778 for ; Thu, 16 Sep 2004 13:31:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C82re-00044r-00; Thu, 16 Sep 2004 13:28:22 -0700 Date: Thu, 16 Sep 2004 13:28:22 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, jmorris@redhat.com, netdev@oss.sgi.com Subject: Re: [IPSEC] Implement DSCP decapsulation Message-Id: <20040916132822.0f1ae663.davem@davemloft.net> In-Reply-To: <20040916123939.GA3403@gondor.apana.org.au> References: <20040916123939.GA3403@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 530 Lines: 13 On Thu, 16 Sep 2004 22:39:39 +1000 Herbert Xu wrote: > This patch adds DSCP decapsulation for IPsec. This is enabled by > a per-state flag which is off by default. Leaving it off by default > maintains compatibility and is also good for performance reasons. > > I decided to not implement a toggle on the output path since not > encapsulating the DSCP can and should be done by netfilter. > > Signed-off-by: Herbert Xu Looks great. Patch applied, thanks Herbert. From davem@davemloft.net Thu Sep 16 13:33:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:33:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKX5AB021233 for ; Thu, 16 Sep 2004 13:33:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C82sd-000458-00; Thu, 16 Sep 2004 13:29:23 -0700 Date: Thu, 16 Sep 2004 13:29:23 -0700 From: "David S. Miller" To: Thomas Graf Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fixes slab corruption in cbq_destroy Message-Id: <20040916132923.0ac971f8.davem@davemloft.net> In-Reply-To: <20040916132856.GA27293@postel.suug.ch> References: <20040916132856.GA27293@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 381 Lines: 10 On Thu, 16 Sep 2004 15:28:56 +0200 Thomas Graf wrote: > Fixes slab corruption in cbq_destroy. cbq_destroy_filters and > qdisc_put_rtab(q->link.R_tab) are already called in cbq_destroy_class. > The latter lead to a slab corruption due to repeated freeing of > q->link.R_tab because q->link is part of q->classes. Problem introduced > in 1.21. Good catch, applied. From tgraf@suug.ch Thu Sep 16 13:33:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:33:26 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKXIGU021307 for ; Thu, 16 Sep 2004 13:33:19 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 2CCC281; Thu, 16 Sep 2004 22:32:45 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 9DD021C0E8; Thu, 16 Sep 2004 22:33:27 +0200 (CEST) Date: Thu, 16 Sep 2004 22:33:27 +0200 From: Thomas Graf To: Patrick McHardy Cc: "David S. Miller" , Alexey Kuznetsov , netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fixes slab corruption in cbq_destroy Message-ID: <20040916203327.GA27685@postel.suug.ch> References: <20040916132856.GA27293@postel.suug.ch> <4149998C.6060501@trash.net> <20040916140943.GC27293@postel.suug.ch> <4149AA12.10306@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4149AA12.10306@trash.net> X-archive-position: 8951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 964 Lines: 28 * Patrick McHardy <4149AA12.10306@trash.net> 2004-09-16 16:58 > Thomas Graf wrote: > > >* Patrick McHardy <4149998C.6060501@trash.net> 2004-09-16 15:47 > > > > > >>I don't see how there can be slab corruption. qdisc_put_rtab only > >>calls kfree if the table is found in qdisc_rtab_list, which only > >>happens once. But the patch is still fine as cleanup :) > >> > >> > > > >On second call to qdisc_put_rtab with tab pointing to an already > >freed qdisc_rate_table: > > > >sch_api.c:271: if (!tab || --tab->refcnt) > > > > > You're right, no double free but accessing and modifying of freed memory. My patch description was misleading should have been something like this: Fixes slab corruption in cbq_destroy. cbq_destroy_filters and qdisc_put_rtab(q->link.R_tab) are already called in cbq_destroy_class. The latter lead to a slab corruption due to use of q->link.R_tab after being freed by previous call to qdisc_put_rtab. Problem introduced in 1.21. From davem@davemloft.net Thu Sep 16 13:33:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:33:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKXYlv021502 for ; Thu, 16 Sep 2004 13:33:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C82tE-00045L-00; Thu, 16 Sep 2004 13:30:00 -0700 Date: Thu, 16 Sep 2004 13:29:59 -0700 From: "David S. Miller" To: Thomas Graf Cc: kaber@trash.net, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH 2.4 NET] Fixes slab corruption in cbq_destroy Message-Id: <20040916132959.20dee2fd.davem@davemloft.net> In-Reply-To: <20040916133123.GB27293@postel.suug.ch> References: <20040916133123.GB27293@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 125 Lines: 6 On Thu, 16 Sep 2004 15:31:23 +0200 Thomas Graf wrote: > Backport of 2.6 patch: Also applied, thanks again. From leonid.grossman@s2io.com Thu Sep 16 13:35:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:35:53 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKZk6s022188 for ; Thu, 16 Sep 2004 13:35:47 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8GKYtje017327; Thu, 16 Sep 2004 16:34:55 -0400 (EDT) Received: from lgt40 ([10.16.16.152]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8GKYq39023185; Thu, 16 Sep 2004 16:34:53 -0400 (EDT) Message-Id: <200409162034.i8GKYq39023185@guinness.s2io.com> From: "Leonid Grossman" To: "'Nivedita Singhvi'" Cc: "'Andi Kleen'" , "'David S. Miller'" , "'John Heffner'" , Subject: RE: The ultimate TOE design Date: Thu, 16 Sep 2004 13:34:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcScHpszQFHMhYwXQdGoAJXpfLc5+gACdLIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <4149BCE9.7040501@us.ibm.com> X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 1061 Lines: 35 > -----Original Message----- > From: Nivedita Singhvi [mailto:niv@us.ibm.com] > Sent: Thursday, September 16, 2004 9:19 AM > To: Leonid Grossman > Cc: 'Andi Kleen'; 'David S. Miller'; 'John Heffner'; > netdev@oss.sgi.com > Subject: Re: The ultimate TOE design > > Leonid Grossman wrote: > > > We can dream about benefits of huge MTUs, but the reality is that > > moving beyond 9k MTU is years away. Reasons - mainly > infrastructure, > > plus MTU above ~10k may loose checksum protection (granted, this > > depends whether the errors are simple or complex, and also this may > > not be a showstopper for some people). > > Even 9k MTU is very far from being universally accepted, > eight years > > after our Alteon spec went out :-). > > One other factor is TCP congestion control, and congestion > windows we obey. Most of the time, you just can't send that much. It's a bit painful to setup, but in general with 9k jumbos and TSO we were able to get close to pci-x 133 limit - both in LAN and WAN tests. Leonid > > thanks, > Nivedita > > From davem@redhat.com Thu Sep 16 13:47:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 13:47:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GKl83F022657 for ; Thu, 16 Sep 2004 13:47:09 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8GKktHQ026223; Thu, 16 Sep 2004 16:46:55 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8GKkor15188; Thu, 16 Sep 2004 16:46:50 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8GKkgrL008581; Thu, 16 Sep 2004 16:46:43 -0400 Date: Thu, 16 Sep 2004 13:44:05 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [RFC] inet_opt space saving? Message-Id: <20040916134405.4093e659.davem@redhat.com> In-Reply-To: <20040914151232.115c3eca@dell_ss3.pdx.osdl.net> References: <20040914151232.115c3eca@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 527 Lines: 22 On Tue, 14 Sep 2004 15:12:32 -0700 Stephen Hemminger wrote: > It looks like there are lots of wasted bytes in the inet information > per socket. Does this look right? I see one error at least. > + cmsg_flags: 4, There are 5 bits, not 4. #define IP_CMSG_PKTINFO 1 #define IP_CMSG_TTL 2 #define IP_CMSG_TOS 4 #define IP_CMSG_RECVOPTS 8 #define IP_CMSG_RETOPTS 16 This is also the number of right shifts, plus one, made by ip_cmsg_recv(). The rest of your transformations look perfectly fine. From herbert@gondor.apana.org.au Thu Sep 16 14:19:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 14:20:03 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GLJrZ0023517 for ; Thu, 16 Sep 2004 14:19:54 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C83f9-0002KM-00; Fri, 17 Sep 2004 07:19:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C83f1-0002X7-00; Fri, 17 Sep 2004 07:19:23 +1000 From: Herbert Xu To: martin.bouzek@radas-atc.cz Subject: Re: Minor IPSec bug + solution Cc: linux-kernel@vger.kernel.org, davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <1095327372.4466.87.camel@mabouzek> X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Fri, 17 Sep 2004 07:19:23 +1000 X-archive-position: 8955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 778 Lines: 20 Martin Bouzek wrote: > > I was setting up an VPN via IPSec in kernel 2.6.x on IPv4 and found the > following bug. It is not possible to set up an IPComp/ESP tunnel with > IPComp set as mandatory. The following setup works fine for me: You can never set IPComp as mandatory because ipcomp_output() will not compress anything that is incompressible. > function. For tunnels it returns > > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family); The check is correct as it is. Internal states must never match any required transform. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From zdzichu@irc.pl Thu Sep 16 14:26:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 14:26:12 -0700 (PDT) Received: from mother.localdomain (serwer.tvgawex.pl [212.122.214.2]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8GLQ43g023948 for ; Thu, 16 Sep 2004 14:26:06 -0700 Received: (qmail 17866 invoked by uid 1000); 14 Sep 2004 21:41:45 -0000 Date: Tue, 14 Sep 2004 23:41:44 +0200 From: Tomasz Torcz To: Nivedita Singhvi Cc: netdev@oss.sgi.com, vlists@veus.hr Subject: Re: [Fwd: [Bug 3397] New: Network connections hang going through an OpenBSD firewall] Message-ID: <20040914214144.GA17571@irc.pl> References: <41475BEA.2030803@us.ibm.com> <41475E1E.7010200@veus.hr> <414760E5.4010703@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414760E5.4010703@us.ibm.com> User-Agent: Mutt/1.5.4i X-archive-position: 8956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zdzichu@irc.pl Precedence: bulk X-list: netdev Content-Length: 399 Lines: 11 On Tue, Sep 14, 2004 at 02:21:41PM -0700, Nivedita Singhvi wrote: > If you can, download the latest (linux-2.6.9-rc2). You can > get the patch against linux-2.6.8.1 vanilla from > kernel.org. Patch against 2.6.8. It won't apply clean on 2.6.8.1. -- Tomasz Torcz Morality must always be based on practicality. zdzichu@irc.-nie.spam-.pl -- Baron Vladimir Harkonnen From shemminger@osdl.org Thu Sep 16 14:44:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 14:44:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GLi2ql024450 for ; Thu, 16 Sep 2004 14:44:03 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8GLhWv29549; Thu, 16 Sep 2004 14:43:33 -0700 Date: Thu, 16 Sep 2004 14:43:32 -0700 From: Stephen Hemminger To: Robert Olsson , "David S. Miller" Cc: netdev@oss.sgi.com, Jamal Hadi Salim Subject: [PATCH] pktgen handle netdev device getting full. Message-Id: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2215 Lines: 78 I was trying out pktgen on a NIC with an undersized ring, so hard_start_xmit would always return non-zero when full. This caused a slew of console messages. Better to just have pktgen retry in this case. Also, can use do_div to do the 64 bit divide rather than doing long string of if statements when computing results. Signed-off-by: Stephen Hemminger diff -Nru a/net/core/pktgen.c b/net/core/pktgen.c --- a/net/core/pktgen.c 2004-09-16 14:42:25 -07:00 +++ b/net/core/pktgen.c 2004-09-16 14:42:25 -07:00 @@ -589,7 +589,7 @@ { struct net_device *odev = NULL; struct sk_buff *skb = NULL; - __u64 total = 0; + __u32 total = 0; __u64 idle = 0; __u64 lcount = 0; int nr_frags = 0; @@ -636,28 +636,20 @@ if (!(odev->features & NETIF_F_LLTX)) spin_lock_bh(&odev->xmit_lock); - if (!netif_queue_stopped(odev)) { + last_ok = 0; + if (!netif_queue_stopped(odev)) { atomic_inc(&skb->users); - if (odev->hard_start_xmit(skb, odev)) { - + if (odev->hard_start_xmit(skb, odev) == NETDEV_TX_OK) { + last_ok = 1; + info->sofar++; + info->seq_num++; + } else { + /* Device kicked us out :( + so retry again */ atomic_dec(&skb->users); - if (net_ratelimit()) { - printk(KERN_INFO "Hard xmit error\n"); - } - info->errors++; - last_ok = 0; } - else { - last_ok = 1; - info->sofar++; - info->seq_num++; - } - } - else { - /* Re-try it next time */ - last_ok = 0; } if (!(odev->features & NETIF_F_LLTX)) @@ -733,15 +725,9 @@ { char *p = info->result; __u64 bps, pps = 0; - - if (total > 1000) - pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); - else if(total > 100) - pps = (__u32)(info->sofar * 10000) / ((__u32)(total) / 100); - else if(total > 10) - pps = (__u32)(info->sofar * 100000) / ((__u32)(total) / 10); - else if(total > 1) - pps = (__u32)(info->sofar * 1000000) / (__u32)total; + + pps = info->sofar * 1000000; + do_div(pps, total); bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */ p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps) errors: %llu", From ltd@cisco.com Thu Sep 16 15:37:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 15:37:45 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GMbdkr025472 for ; Thu, 16 Sep 2004 15:37:40 -0700 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 16 Sep 2004 15:37:42 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8GMbJ3c029713; Thu, 16 Sep 2004 15:37:19 -0700 (PDT) Received: from ltd-t30.cisco.com (syd-vpn-client-254-35.cisco.com [10.66.254.35]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXE72930; Thu, 16 Sep 2004 15:36:02 -0700 (PDT) Message-Id: <5.1.0.14.2.20040917083305.04f4d008@171.71.163.14> X-Sender: ltd@171.71.163.14 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 Sep 2004 08:37:17 +1000 To: Alan Cox From: Lincoln Dale Subject: Re: The ultimate TOE design Cc: Andi Kleen , Jeff Garzik , "David S. Miller" , paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, Linux Kernel Mailing List In-Reply-To: <1095339466.22739.22.camel@localhost.localdomain> References: <20040916133301.GA15562@wotan.suse.de> <20040915141346.5c5e5377.davem@davemloft.net> <4148991B.9050200@pobox.com> <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <5.1.0.14.2.20040916192213.04240008@171.71.163.14> <1095337159.22739.7.camel@localhost.localdomain> <20040916133301.GA15562@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 8958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltd@cisco.com Precedence: bulk X-list: netdev Content-Length: 1236 Lines: 35 Hi Alan, At 10:57 PM 16/09/2004, Alan Cox wrote: >On Iau, 2004-09-16 at 14:33, Andi Kleen wrote: > > > At 1Ghz the Athlon Geode NX draws about 6W. Thats less than my SCSI > > > > Are you sure that's worst case, not average? Worst case is usually > > much worse on a big CPU like an Athlon, but the power supply > > has to be sized for it. > >You are correct - 6W average 9W TDP, still less than my scsicontroller >8) sure -- ok -- that gets you the main processor. now add to that a Northbridge (perhaps AMD doesnt need that but i'm sure it still does), Southbridge, DDR-SDRAM, ancilliary chips for doing MAC, PHY, ... couple that with the voltage of PCI where you're likely to need step-up/step-down circuits (which aren't 100% efficient themselves), you're still going to get very close to the limit, if not over it. ... and after all that, the Geode is really designed to be an embedded processor. Jeff was implying using garden-variety processors which seem to have large heatsinks, not to mention cooling fans, not to mention quite significant heat generation. we're not _quite_ at the stage of being able to take garden-variety processors and build-your-own-blade-server using PCI _just_ yet. :-) cheers, lincoln. From greearb@candelatech.com Thu Sep 16 15:59:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 15:59:51 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GMxi7a026364 for ; Thu, 16 Sep 2004 15:59:45 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8GN28LH011338; Thu, 16 Sep 2004 16:02:08 -0700 Message-ID: <414A1AD2.1090109@candelatech.com> Date: Thu, 16 Sep 2004 15:59:30 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Robert Olsson , "David S. Miller" , netdev@oss.sgi.com, Jamal Hadi Salim Subject: Re: [PATCH] pktgen handle netdev device getting full. References: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> In-Reply-To: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 747 Lines: 20 Stephen Hemminger wrote: > I was trying out pktgen on a NIC with an undersized ring, so > hard_start_xmit would always return non-zero when full. This caused a slew > of console messages. Better to just have pktgen retry in this case. My understanding is that if the queue is not stopped, then you should not get the hard xmit errors. So, in a proper driver, you should not see these printks. By the way, is there any interest in adding my patch that also allows pktgen to receive packets (and count the statistics, etc)? I know DaveM objected to the hook in the skb-receive logic some time back, but maybe he has a different opinion now? Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@davemloft.net Thu Sep 16 16:02:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:02:22 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GN2HN9026703 for ; Thu, 16 Sep 2004 16:02:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C85Dd-0004NW-00; Thu, 16 Sep 2004 15:59:13 -0700 Date: Thu, 16 Sep 2004 15:59:13 -0700 From: "David S. Miller" To: Ben Greear Cc: shemminger@osdl.org, Robert.Olsson@data.slu.se, davem@redhat.com, netdev@oss.sgi.com, hadi@znyx.com Subject: Re: [PATCH] pktgen handle netdev device getting full. Message-Id: <20040916155913.577b878b.davem@davemloft.net> In-Reply-To: <414A1AD2.1090109@candelatech.com> References: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> <414A1AD2.1090109@candelatech.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 946 Lines: 22 On Thu, 16 Sep 2004 15:59:30 -0700 Ben Greear wrote: > Stephen Hemminger wrote: > > I was trying out pktgen on a NIC with an undersized ring, so > > hard_start_xmit would always return non-zero when full. This caused a slew > > of console messages. Better to just have pktgen retry in this case. > > My understanding is that if the queue is not stopped, then you > should not get the hard xmit errors. So, in a proper driver, > you should not see these printks. That is absolutely correct, that is why Stephen's patch is not correct (aside from the do_div() part which I'll happily apply if submitted by itself). > By the way, is there any interest in adding my patch that also allows > pktgen to receive packets (and count the statistics, etc)? I know > DaveM objected to the hook in the skb-receive logic some time back, > but maybe he has a different opinion now? I still object to this, it will be abused. From pavlic@de.ibm.com Thu Sep 16 16:11:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:11:23 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNBEg9027081 for ; Thu, 16 Sep 2004 16:11:15 -0700 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8GNAwLi121342; Thu, 16 Sep 2004 23:10:58 GMT Received: from d12ml068.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8GNAv2t211080; Fri, 17 Sep 2004 01:10:57 +0200 Reply-To: To: netdev@oss.sgi.com, linux-net@vger.kernel.org MIME-Version: 1.0 Sensitivity: Subject: [PATCH] introducing new net device feature NETIF_F_MC_ALL X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Frank Pavlic Message-ID: Date: Fri, 17 Sep 2004 01:10:54 +0200 X-MIMETrack: Serialize by Router on D12ML068/12/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 17/09/2004 01:10:57, Serialize complete at 17/09/2004 01:10:57 Content-Type: multipart/alternative; boundary="=_alternative 0078A6C4C1256F11_=" X-archive-position: 8961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavlic@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 27374 Lines: 646 This is a multipart message in MIME format. --=_alternative 0078A6C4C1256F11_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I introduced a new net device feature flag NETIF=5FF=5FMC=5FALL. Setting this flag network devices drivers will be triggered on every=20 multicast join and drop regardless of already existing dev=5Fmc=5Flist entry .=20 The reason is that s390 device drivers lcs and qeth need to be informed=20 for every new Multicast IP address being joined or dropped to register them at the hardware to get=20 multicast traffic running for the specific Multicast group. As LCS and OSA Express hardware are able to virtualize network devices=20 and so to get a lot of systems=20 running concurrently with the same physical hardware it is not enough for=20 both device drivers to just get triggered=20 when a new dev=5Fmc=5Flist entry is allocated. For example in case of Token Ring this would happen only once as the=20 hardware multicast address is hardcoded in=20 ip=5Ftr=5Fmc=5Fmap. Thus every further join of a new Multicast group p on a= =20 Token Ring device would never trigger=20 the drivers again. As this multicast IP address has not been registered=20 yet on the card multicast packets for this group will be dropped by the hardware. Similar applies to Ethernet . diff -urN linux-2.6/drivers/s390/net/lcs.c=20 linux-2.6-s390/drivers/s390/net/lcs.c --- linux-2.6/drivers/s390/net/lcs.c Thu Aug 26 11:23:33 2004 +++ linux-2.6-s390/drivers/s390/net/lcs.c Thu Aug 26 11:23:45 2004 @@ -11,7 +11,7 @@ * Frank Pavlic (pavlic@de.ibm.com) and * Martin Schwidefsky * - * $Revision: 1.89 $ $Date: 2004/08/24 10:49:27 $ + * $Revision: 1.90 $ $Date: 2004/08/26 03:29:44 $ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -59,7 +59,7 @@ /** * initialization string for output */ -#define VERSION=5FLCS=5FC "$Revision: 1.89 $" +#define VERSION=5FLCS=5FC "$Revision: 1.90 $" static char version[] =5F=5Finitdata =3D "LCS driver ("VERSION=5FLCS=5FC "= /"=20 VERSION=5FLCS=5FH ")"; static char debug=5Fbuffer[255]; @@ -101,9 +101,9 @@ return -ENOMEM; } debug=5Fregister=5Fview(lcs=5Fdbf=5Fsetup, &debug=5Fhex=5Fascii=5Fv= iew); - debug=5Fset=5Flevel(lcs=5Fdbf=5Fsetup, 4); + debug=5Fset=5Flevel(lcs=5Fdbf=5Fsetup, 2); debug=5Fregister=5Fview(lcs=5Fdbf=5Ftrace, &debug=5Fhex=5Fascii=5Fv= iew); - debug=5Fset=5Flevel(lcs=5Fdbf=5Ftrace, 4); + debug=5Fset=5Flevel(lcs=5Fdbf=5Ftrace, 2); return 0; } @@ -1276,9 +1276,8 @@ LCS=5FDBF=5FTEXT(4, trace, "setmulti"); card =3D (struct lcs=5Fcard *) dev->priv; - if (!lcs=5Fset=5Fthread=5Fstart=5Fbit(card, LCS=5FSET=5FMC=5FTHREA= D)) { + if (!lcs=5Fset=5Fthread=5Fstart=5Fbit(card, LCS=5FSET=5FMC=5FTHREA= D)) schedule=5Fwork(&card->kernel=5Fthread=5Fstarter); - } } #endif /* CONFIG=5FIP=5FMULTICAST */ @@ -2181,8 +2180,10 @@ goto out; memcpy(card->dev->dev=5Faddr, card->mac, LCS=5FMAC=5FLENGTH); #ifdef CONFIG=5FIP=5FMULTICAST - if (!lcs=5Fcheck=5Fmulticast=5Fsupport(card)) + if (!lcs=5Fcheck=5Fmulticast=5Fsupport(card)) { card->dev->set=5Fmulticast=5Flist =3D lcs=5Fset=5Fmulticast= =5Flist; + card->dev->features |=3D NETIF=5FF=5FMC=5FALL; + } #endif netif=5Fstop=5Fqueue(card->dev); lcs=5Fset=5Fallowed=5Fthreads(card,0xffffffff); @@ -2294,7 +2295,6 @@ PRINT=5FERR("Initialization failed\n"); return rc; } - return 0; } diff -urN linux-2.6/drivers/s390/net/qeth=5Fmain.c=20 linux-2.6-s390/drivers/s390/net/qeth=5Fmain.c --- linux-2.6/drivers/s390/net/qeth=5Fmain.c Thu Aug 26 11:23:42 2004 +++ linux-2.6-s390/drivers/s390/net/qeth=5Fmain.c Thu Aug 26 11:23:45 2004 @@ -1,6 +1,6 @@ /* * - * linux/drivers/s390/net/qeth=5Fmain.c ($Revision: 1.132 $) + * linux/drivers/s390/net/qeth=5Fmain.c ($Revision: 1.133 $) @@ -1,6 +1,6 @@ /* * - * linux/drivers/s390/net/qeth=5Fmain.c ($Revision: 1.132 $) + * linux/drivers/s390/net/qeth=5Fmain.c ($Revision: 1.133 $) * * Linux on zSeries OSA Express and HiperSockets support * @@ -12,7 +12,7 @@ * Frank Pavlic (pavlic@de.ibm.com) and * Thomas Spatzier * - * $Revision: 1.132 $ $Date: 2004/08/19 12:39:43 $ + * $Revision: 1.133 $ $Date: 2004/08/26 03:29:44 $ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -78,7 +78,7 @@ #include "qeth=5Fmpc.h" #include "qeth=5Ffs.h" -#define VERSION=5FQETH=5FC "$Revision: 1.132 $" +#define VERSION=5FQETH=5FC "$Revision: 1.133 $" static const char *version =3D "qeth S/390 OSA-Express driver"; /** @@ -6263,6 +6263,7 @@ } else { PRINT=5FINFO("Multicast enabled\n"); card->dev->flags |=3D IFF=5FMULTICAST; + card->dev->features |=3D NETIF=5FF=5FMC=5FALL; } return rc; } diff -urN linux-2.6/include/linux/netdevice.h=20 linux-2.6-s390/include/linux/netdevice.h --- linux-2.6/include/linux/netdevice.h Thu Aug 26 11:23:43 2004 +++ linux-2.6-s390/include/linux/netdevice.h Thu Aug 26 11:23:45 2004 @@ -408,7 +408,10 @@ #define NETIF=5FF=5FVLAN=5FCHALLENGED 1024 /* Device cannot hand= le=20 VLAN packets */ #define NETIF=5FF=5FTSO 2048 /* Can offload TCP/IP segmentat= ion=20 */ #define NETIF=5FF=5FLLTX 4096 /* LockLess TX */ - +#define NETIF=5FF=5FMC=5FALL 8192 /* trigger driver on every=20 multicast + * address been added/deleted + */ + /* Called after device is detached from network. */ void (*uninit)(struct net=5Fdevice *dev); /* Called after last user reference disappears. */ diff -urN linux-2.6/net/core/dev=5Fmcast.c=20 linux-2.6-s390/net/core/dev=5Fmcast.c --- linux-2.6/net/core/dev=5Fmcast.c Sat Aug 14 12:55:10 2004 +++ linux-2.6-s390/net/core/dev=5Fmcast.c Thu Aug 26 11:23:45 2004 @@ -145,6 +145,8 @@ } err =3D -ENOENT; done: + if (dev->features & NETIF=5FF=5FMC=5FALL) + =5F=5Fdev=5Fmc=5Fupload(dev); spin=5Funlock=5Fbh(&dev->xmit=5Flock); return err; } @@ -193,6 +195,9 @@ return 0; done: + if (dev->features & NETIF=5FF=5FMC=5FALL) + =5F=5Fdev=5Fmc=5Fupload(dev); + spin=5Funlock=5Fbh(&dev->xmit=5Flock); if (dmi1) kfree(dmi1); diff -urN linux-2.6/net/ipv4/igmp.c linux-2.6-s390/net/ipv4/igmp.c --- linux-2.6/net/ipv4/igmp.c Thu Aug 26 11:23:21 2004 +++ linux-2.6-s390/net/ipv4/igmp.c Thu Aug 26 11:23:45 2004 @@ -1202,7 +1202,6 @@ if (!in=5Fdev->dead) ip=5Frt=5Fmulticast=5Fevent(in=5Fde= v); - ip=5Fma=5Fput(i); return; } diff -urN linux-2.6/net/ipv6/mcast.c linux-2.6-s390/net/ipv6/mcast.c --- linux-2.6/net/ipv6/mcast.c Sat Aug 14 12:56:01 2004 +++ linux-2.6-s390/net/ipv6/mcast.c Thu Aug 26 11:23:45 2004 @@ -882,7 +882,6 @@ write=5Funlock=5Fbh(&idev->lock); igmp6=5Fgroup=5Fdropped(ma); - ma=5Fput(ma); return 0; } Mit freundlichen Gr=FCssen / Best regards Frank Pavlic =20 Linux for eServer Development Schoenaicher Str. 220, 71032 Boeblingen Phone: ext. +49-(0)7031/16-2463, int. *120-2463 mailto: pavlic@de.ibm.com --=_alternative 0078A6C4C1256F11_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I introduced a new net device feature flag NETIF=5FF=5FMC=5FALL.
Setting this flag network devices dr= ivers will be triggered on every multicast join and drop
regardless of already existing dev= =5Fmc=5Flist entry .
The reason is that s390 device drive= rs lcs and qeth need to be informed for every new Multicast IP
address being joined or dropped to r= egister them at the hardware to get multicast traffic running for
the specific Multicast group.
As LCS and OSA Express hardware &nbs= p;are able to virtualize network devices and so to get a lot of systems
running concurrently with the same p= hysical hardware it is not enough for both device drivers to just get triggered
when a new dev=5Fmc=5Flist entry is = allocated.
For example in case of Token Ring th= is would happen only once as the hardware multicast address is hardcoded in
ip=5Ftr=5Fmc=5Fmap. Thus every furth= er join of a new Multicast group p on a Token Ring device would never trigger
the drivers again. As this multicast IP address has not been registered yet on the card multicast packets for this group
will be dropped  by the hardwar= e. Similar applies to Ethernet .


diff -urN linux-2.6/drivers/s390/net= /lcs.c linux-2.6-s390/drivers/s390/net/lcs.c
--- linux-2.6/drivers/s390/net/lcs.c    Thu Aug 26 11:23:33 2004
+++ linux-2.6-s390/drivers/s390/net/= lcs.c       Thu Aug 26 11:23:45 2004
@@ -11,7 +11,7 @@
  *                       Frank Pavlic (pavlic@de.ib= m.com) and
  *                       Martin Schwidefsky <sch= widefsky@de.ibm.com>
  *
- *    $Revision: 1.89 $ &= nbsp;       $Date: 2004/08/24 10:49:27 $
+ *    $Revision: 1.90 $ &= nbsp;       $Date: 2004/08/26 03:29:44 $
  *
  * This program is free softwa= re; you can redistribute it and/or modify
  * it under the terms of the G= NU General Public License as published by
@@ -59,7 +59,7 @@
 /**
  * initialization string for o= utput
  */
-#define VERSION=5FLCS=5FC  &qu= ot;$Revision: 1.89 $"
+#define VERSION=5FLCS=5FC  &qu= ot;$Revision: 1.90 $"

 static char version[] =5F=5Fin= itdata =3D "LCS driver ("VERSION=5FLCS=5FC "/" VERSION=5FLCS= =5FH ")";
 static char debug=5Fbuffer[255= ];
@@ -101,9 +101,9 @@
          &= nbsp;     return -ENOMEM;
        }
        debug=5F= register=5Fview(lcs=5Fdbf=5Fsetup, &debug=5Fhex=5Fascii=5Fview);
-       debug=5Fset= =5Flevel(lcs=5Fdbf=5Fsetup, 4);
+       debug=5Fset= =5Flevel(lcs=5Fdbf=5Fsetup, 2);
        debug=5F= register=5Fview(lcs=5Fdbf=5Ftrace, &debug=5Fhex=5Fascii=5Fview);
-       debug=5Fset= =5Flevel(lcs=5Fdbf=5Ftrace, 4);
+       debug=5Fset= =5Flevel(lcs=5Fdbf=5Ftrace, 2);
        return 0= ;
 }

@@ -1276,9 +1276,8 @@
         LC= S=5FDBF=5FTEXT(4, trace, "setmulti");
         ca= rd =3D (struct lcs=5Fcard *) dev->priv;

-        if (!lc= s=5Fset=5Fthread=5Fstart=5Fbit(card, LCS=5FSET=5FMC=5FTHREAD)) {
+        if (!lc= s=5Fset=5Fthread=5Fstart=5Fbit(card, LCS=5FSET=5FMC=5FTHREAD))
          &= nbsp;     schedule=5Fwork(&card->kernel=5Fthread=5Fstarter);
-       }
 }

 #endif /* CONFIG=5FIP=5FMULTIC= AST */
@@ -2181,8 +2180,10 @@
          &= nbsp;     goto out;
        memcpy(c= ard->dev->dev=5Faddr, card->mac, LCS=5FMAC=5FLENGTH);
 #ifdef CONFIG=5FIP=5FMULTICAST=
-       if (!lcs=5Fch= eck=5Fmulticast=5Fsupport(card))
+       if (!lcs=5Fch= eck=5Fmulticast=5Fsupport(card)) {
          &= nbsp;     card->dev->set=5Fmulticast=5Flist =3D lcs=5Fset=5Fmulti= cast=5Flist;
+               card->dev->features |=3D NETIF=5FF=5FMC=5FALL;
+       }
 #endif
        netif=5F= stop=5Fqueue(card->dev);
        lcs=5Fse= t=5Fallowed=5Fthreads(card,0xffffffff);
@@ -2294,7 +2295,6 @@
          &= nbsp;     PRINT=5FERR("Initialization failed\n");
          &= nbsp;     return rc;
        }
-
        return 0= ;
 }

diff -urN linux-2.6/drivers/s390/net= /qeth=5Fmain.c linux-2.6-s390/drivers/s390/net/qeth=5Fmain.c
--- linux-2.6/drivers/s390/net/qeth= =5Fmain.c      Thu Aug 26 11:23:42 2004
+++ linux-2.6-s390/drivers/s390/net/= qeth=5Fmain.c Thu Aug 26 11:23:45 2004
@@ -1,6 +1,6 @@
 /*
  *
- * linux/drivers/s390/net/qeth=5Fma= in.c ($Revision: 1.132 $)
+ * linux/drivers/s390/net/qeth=5Fma= in.c ($Revision: 1.133 $)
@@ -1,6 +1,6 @@
 /*
  *
- * linux/drivers/s390/net/qeth=5Fma= in.c ($Revision: 1.132 $)
+ * linux/drivers/s390/net/qeth=5Fma= in.c ($Revision: 1.133 $)
  *
  * Linux on zSeries OSA Express and HiperSockets support
  *
@@ -12,7 +12,7 @@
  *                       Frank Pavlic (pavlic@de.ib= m.com) and
  *                       Thomas Spatzier <tspat@= de.ibm.com>
  *
- *    $Revision: 1.132 $        $Date: 2004/08/19 12:39:43 $
+ *    $Revision: 1.133 $        $Date: 2004/08/26 03:29:44 $
  *
  * This program is free softwa= re; you can redistribute it and/or modify
  * it under the terms of the G= NU General Public License as published by
@@ -78,7 +78,7 @@
 #include "qeth=5Fmpc.h&qu= ot;
 #include "qeth=5Ffs.h&quo= t;

-#define VERSION=5FQETH=5FC "$R= evision: 1.132 $"
+#define VERSION=5FQETH=5FC "$R= evision: 1.133 $"
 static const char *version =3D= "qeth S/390 OSA-Express driver";

 /**
@@ -6263,6 +6263,7 @@
        } else {=
          &= nbsp;     PRINT=5FINFO("Multicast enabled\n");
          &= nbsp;     card->dev->flags |=3D IFF=5FMULTICAST;
+               card->dev->features |=3D NETIF=5FF=5FMC=5FALL;
        }
        return r= c;
 }
diff -urN linux-2.6/include/linux/ne= tdevice.h linux-2.6-s390/include/linux/netdevice.h
--- linux-2.6/include/linux/netdevic= e.h Thu Aug 26 11:23:43 2004
+++ linux-2.6-s390/include/linux/net= device.h    Thu Aug 26 11:23:45 2004
@@ -408,7 +408,10 @@
 #define NETIF=5FF=5FVLAN=5FCHA= LLENGED        1024    /* Device cannot handle VLAN packets */
 #define NETIF=5FF=5FTSO  =          2048    /* Can offload TCP/IP segmenta= tion */
 #define NETIF=5FF=5FLLTX  = ;         4096    /* LockLess TX */
-
+#define NETIF=5FF=5FMC=5FALL  =       8192    /* trigger driver on every multicast
+                                        * address been added/deleted
+                                        */
+
        /* Called after device is detached from network. */
        void &nb= sp;                  (*uninit)(str= uct net=5Fdevice *dev);
        /* Called after last user reference disappears. */
diff -urN linux-2.6/net/core/dev=5Fm= cast.c linux-2.6-s390/net/core/dev=5Fmcast.c
--- linux-2.6/net/core/dev=5Fmcast.c=      Sat Aug 14 12:55:10 2004
+++ linux-2.6-s390/net/core/dev=5Fmc= ast.c Thu Aug 26 11:23:45 2004
@@ -145,6 +145,8 @@
        }
        err =3D = -ENOENT;
 done:
+       if (dev->f= eatures & NETIF=5FF=5FMC=5FALL)
+               =5F=5Fdev=5Fmc=5Fupload(dev);
        spin=5Fu= nlock=5Fbh(&dev->xmit=5Flock);
        return e= rr;
 }
@@ -193,6 +195,9 @@
        return 0= ;

 done:
+       if (dev->f= eatures & NETIF=5FF=5FMC=5FALL)
+               =5F=5Fdev=5Fmc=5Fupload(dev);
+
        spin=5Fu= nlock=5Fbh(&dev->xmit=5Flock);
        if (dmi1= )
          &= nbsp;     kfree(dmi1);
diff -urN linux-2.6/net/ipv4/igmp.c linux-2.6-s390/net/ipv4/igmp.c
--- linux-2.6/net/ipv4/igmp.c   Thu Aug 26 11:23:21 2004
+++ linux-2.6-s390/net/ipv4/igmp.c &= nbsp;    Thu Aug 26 11:23:45 2004
@@ -1202,7 +1202,6 @@

          &= nbsp;                     if (!in=5Fdev->dead)
          &= nbsp;                             ip=5Frt=5Fmulticast=5Fevent(in=5Fdev);
-
          &= nbsp;                     ip=5F= ma=5Fput(i);
          &= nbsp;                     retur= n;
          &= nbsp;             }
diff -urN linux-2.6/net/ipv6/mcast.c linux-2.6-s390/net/ipv6/mcast.c
--- linux-2.6/net/ipv6/mcast.c  = ;Sat Aug 14 12:56:01 2004
+++ linux-2.6-s390/net/ipv6/mcast.c     Thu Aug 26 11:23:45 2004
@@ -882,7 +882,6 @@
          &= nbsp;                     write= =5Funlock=5Fbh(&idev->lock);

          &= nbsp;                     igmp6= =5Fgroup=5Fdropped(ma);
-
          &= nbsp;                     ma=5F= put(ma);
          &= nbsp;                     return 0;
          &= nbsp;             }


Mit  freundlichen Gr=FCssen / Best regards
Frank Pavlic
 
Linux for eServer Development
Schoenaicher Str. 220, 71032 Boeblingen
Phone:  ext. +49-(0)7031/16-2463, int. *120-2463
mailto:   pavlic@de.ibm.com


 --=_alternative 0078A6C4C1256F11_=-- From shemminger@osdl.org Thu Sep 16 16:18:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:18:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNIHpv027473 for ; Thu, 16 Sep 2004 16:18:18 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8GNHrv15271; Thu, 16 Sep 2004 16:17:53 -0700 Date: Thu, 16 Sep 2004 16:17:53 -0700 From: Stephen Hemminger To: Jes Sorensen , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] acenic - don't spin in hard_start_xmit when ring fills Message-Id: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1613 Lines: 52 Running performance tests on the acenic, I noticed that the driver spins when the transmit ring gets full. This might have been okay when CPU's were slower, but it isn't the right thing to do. Better to return TX_BUSY and let network scheduling handle it. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-09-16 16:17:09 -07:00 +++ b/drivers/net/acenic.c 2004-09-16 16:17:09 -07:00 @@ -2517,11 +2517,10 @@ struct tx_desc *desc; u32 idx, flagsize; -restart: idx = ap->tx_prd; if (tx_ring_full(ap, ap->tx_ret_csm, idx)) - goto overflow; + return NETDEV_TX_BUSY; #if MAX_SKB_FRAGS if (!skb_shinfo(skb)->nr_frags) @@ -2625,27 +2624,7 @@ } dev->trans_start = jiffies; - return 0; - -overflow: - /* - * This race condition is unavoidable with lock-free drivers. - * We wake up the queue _before_ tx_prd is advanced, so that we can - * enter hard_start_xmit too early, while tx ring still looks closed. - * This happens ~1-4 times per 100000 packets, so that we can allow - * to loop syncing to other CPU. Probably, we need an additional - * wmb() in ace_tx_intr as well. - * - * Note that this race is relieved by reserving one more entry - * in tx ring than it is necessary (see original non-SG driver). - * However, with SG we need to reserve 2*MAX_SKB_FRAGS+1, which - * is already overkill. - * - * Alternative is to return with 1 not throttling queue. In this - * case loop becomes longer, no more useful effects. - */ - barrier(); - goto restart; + return NETDEV_TX_OK; } From shemminger@osdl.org Thu Sep 16 16:21:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:21:30 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNLOVg031008 for ; Thu, 16 Sep 2004 16:21:24 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8GNKpv16366; Thu, 16 Sep 2004 16:20:51 -0700 Date: Thu, 16 Sep 2004 16:20:51 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Ben Greear , Robert.Olsson@data.slu.se, davem@redhat.com, netdev@oss.sgi.com, hadi@znyx.com Subject: Re: [PATCH] pktgen handle netdev device getting full. Message-Id: <20040916162051.1b55ae5b@dell_ss3.pdx.osdl.net> In-Reply-To: <20040916155913.577b878b.davem@davemloft.net> References: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> <414A1AD2.1090109@candelatech.com> <20040916155913.577b878b.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1447 Lines: 34 On Thu, 16 Sep 2004 15:59:13 -0700 "David S. Miller" wrote: > On Thu, 16 Sep 2004 15:59:30 -0700 > Ben Greear wrote: > > > Stephen Hemminger wrote: > > > I was trying out pktgen on a NIC with an undersized ring, so > > > hard_start_xmit would always return non-zero when full. This caused a slew > > > of console messages. Better to just have pktgen retry in this case. > > > > My understanding is that if the queue is not stopped, then you > > should not get the hard xmit errors. So, in a proper driver, > > you should not see these printks. Well the E1000 fill's it Tx ring and returns TX_BUSY, and on SMP can also get TX_LOCKED now. If that happens, the message shows up. Several other drivers don't set stopped when ring is almost full, but rely on scheduler to do it for them. > That is absolutely correct, that is why Stephen's patch is > not correct (aside from the do_div() part which I'll happily > apply if submitted by itself). > > > By the way, is there any interest in adding my patch that also allows > > pktgen to receive packets (and count the statistics, etc)? I know > > DaveM objected to the hook in the skb-receive logic some time back, > > but maybe he has a different opinion now? > > I still object to this, it will be abused. Robert also has a new version of pktgen but he wanted to hold off till 2.7, but now that 2.7 is delayed maybe it should come sooner. From pavlic@de.ibm.com Thu Sep 16 16:22:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:22:26 -0700 (PDT) Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.29.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNMKeN031223 for ; Thu, 16 Sep 2004 16:22:20 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8GNM4nO118830; Thu, 16 Sep 2004 23:22:04 GMT Received: from d12ml068.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8GNM3oU102084; Fri, 17 Sep 2004 01:22:04 +0200 To: netdev@oss.sgi.com, linux-net@vger.kernel.org MIME-Version: 1.0 Subject: [PATCH] introducing new net device feature NETIF_F_MC_ALL X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Frank Pavlic Message-ID: Date: Fri, 17 Sep 2004 01:22:01 +0200 X-MIMETrack: Serialize by Router on D12ML068/12/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 17/09/2004 01:22:04, Serialize complete at 17/09/2004 01:22:04 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8GNMKeN031223 X-archive-position: 8964 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavlic@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 7451 Lines: 210 Hi, I introduced a new net device feature flag NETIF_F_MC_ALL. Setting this flag network devices drivers will be triggered on every multicast join and drop regardless of already existing dev_mc_list entry . The reason is that s390 device drivers lcs and qeth need to be informed for every new Multicast IP address being joined or dropped to register them at the hardware to get multicast traffic running for the specific Multicast group. As LCS and OSA Express hardware are able to virtualize network devices and so to get a lot of systems running concurrently with the same physical hardware it is not enough for both device drivers to just get triggered when a new dev_mc_list entry is allocated. For example in case of Token Ring this would happen only once as the hardware multicast address is hardcoded in ip_tr_mc_map. Thus every further join of a new Multicast group p on a Token Ring device would never trigger the drivers again. As this multicast IP address has not been registered yet on the card multicast packets for this group will be dropped by the hardware. Similar applies to Ethernet . diff -urN linux-2.6/drivers/s390/net/lcs.c linux-2.6-s390/drivers/s390/net/lcs.c --- linux-2.6/drivers/s390/net/lcs.c Thu Aug 26 11:23:33 2004 +++ linux-2.6-s390/drivers/s390/net/lcs.c Thu Aug 26 11:23:45 2004 @@ -11,7 +11,7 @@ * Frank Pavlic (pavlic@de.ibm.com) and * Martin Schwidefsky * - * $Revision: 1.89 $ $Date: 2004/08/24 10:49:27 $ + * $Revision: 1.90 $ $Date: 2004/08/26 03:29:44 $ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -59,7 +59,7 @@ /** * initialization string for output */ -#define VERSION_LCS_C "$Revision: 1.89 $" +#define VERSION_LCS_C "$Revision: 1.90 $" static char version[] __initdata = "LCS driver ("VERSION_LCS_C "/" VERSION_LCS_H ")"; static char debug_buffer[255]; @@ -101,9 +101,9 @@ return -ENOMEM; } debug_register_view(lcs_dbf_setup, &debug_hex_ascii_view); - debug_set_level(lcs_dbf_setup, 4); + debug_set_level(lcs_dbf_setup, 2); debug_register_view(lcs_dbf_trace, &debug_hex_ascii_view); - debug_set_level(lcs_dbf_trace, 4); + debug_set_level(lcs_dbf_trace, 2); return 0; } @@ -1276,9 +1276,8 @@ LCS_DBF_TEXT(4, trace, "setmulti"); card = (struct lcs_card *) dev->priv; - if (!lcs_set_thread_start_bit(card, LCS_SET_MC_THREAD)) { + if (!lcs_set_thread_start_bit(card, LCS_SET_MC_THREAD)) schedule_work(&card->kernel_thread_starter); - } } #endif /* CONFIG_IP_MULTICAST */ @@ -2181,8 +2180,10 @@ goto out; memcpy(card->dev->dev_addr, card->mac, LCS_MAC_LENGTH); #ifdef CONFIG_IP_MULTICAST - if (!lcs_check_multicast_support(card)) + if (!lcs_check_multicast_support(card)) { card->dev->set_multicast_list = lcs_set_multicast_list; + card->dev->features |= NETIF_F_MC_ALL; + } #endif netif_stop_queue(card->dev); lcs_set_allowed_threads(card,0xffffffff); @@ -2294,7 +2295,6 @@ PRINT_ERR("Initialization failed\n"); return rc; } - return 0; } diff -urN linux-2.6/drivers/s390/net/qeth_main.c linux-2.6-s390/drivers/s390/net/qeth_main.c --- linux-2.6/drivers/s390/net/qeth_main.c Thu Aug 26 11:23:42 2004 +++ linux-2.6-s390/drivers/s390/net/qeth_main.c Thu Aug 26 11:23:45 2004 @@ -1,6 +1,6 @@ /* * - * linux/drivers/s390/net/qeth_main.c ($Revision: 1.132 $) + * linux/drivers/s390/net/qeth_main.c ($Revision: 1.133 $) @@ -1,6 +1,6 @@ /* * - * linux/drivers/s390/net/qeth_main.c ($Revision: 1.132 $) + * linux/drivers/s390/net/qeth_main.c ($Revision: 1.133 $) * * Linux on zSeries OSA Express and HiperSockets support * @@ -12,7 +12,7 @@ * Frank Pavlic (pavlic@de.ibm.com) and * Thomas Spatzier * - * $Revision: 1.132 $ $Date: 2004/08/19 12:39:43 $ + * $Revision: 1.133 $ $Date: 2004/08/26 03:29:44 $ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -78,7 +78,7 @@ #include "qeth_mpc.h" #include "qeth_fs.h" -#define VERSION_QETH_C "$Revision: 1.132 $" +#define VERSION_QETH_C "$Revision: 1.133 $" static const char *version = "qeth S/390 OSA-Express driver"; /** @@ -6263,6 +6263,7 @@ } else { PRINT_INFO("Multicast enabled\n"); card->dev->flags |= IFF_MULTICAST; + card->dev->features |= NETIF_F_MC_ALL; } return rc; } diff -urN linux-2.6/include/linux/netdevice.h linux-2.6-s390/include/linux/netdevice.h --- linux-2.6/include/linux/netdevice.h Thu Aug 26 11:23:43 2004 +++ linux-2.6-s390/include/linux/netdevice.h Thu Aug 26 11:23:45 2004 @@ -408,7 +408,10 @@ #define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */ #define NETIF_F_TSO 2048 /* Can offload TCP/IP segmentation */ #define NETIF_F_LLTX 4096 /* LockLess TX */ - +#define NETIF_F_MC_ALL 8192 /* trigger driver on every multicast + * address been added/deleted + */ + /* Called after device is detached from network. */ void (*uninit)(struct net_device *dev); /* Called after last user reference disappears. */ diff -urN linux-2.6/net/core/dev_mcast.c linux-2.6-s390/net/core/dev_mcast.c --- linux-2.6/net/core/dev_mcast.c Sat Aug 14 12:55:10 2004 +++ linux-2.6-s390/net/core/dev_mcast.c Thu Aug 26 11:23:45 2004 @@ -145,6 +145,8 @@ } err = -ENOENT; done: + if (dev->features & NETIF_F_MC_ALL) + __dev_mc_upload(dev); spin_unlock_bh(&dev->xmit_lock); return err; } @@ -193,6 +195,9 @@ return 0; done: + if (dev->features & NETIF_F_MC_ALL) + __dev_mc_upload(dev); + spin_unlock_bh(&dev->xmit_lock); if (dmi1) kfree(dmi1); diff -urN linux-2.6/net/ipv4/igmp.c linux-2.6-s390/net/ipv4/igmp.c --- linux-2.6/net/ipv4/igmp.c Thu Aug 26 11:23:21 2004 +++ linux-2.6-s390/net/ipv4/igmp.c Thu Aug 26 11:23:45 2004 @@ -1202,7 +1202,6 @@ if (!in_dev->dead) ip_rt_multicast_event(in_dev); - ip_ma_put(i); return; } diff -urN linux-2.6/net/ipv6/mcast.c linux-2.6-s390/net/ipv6/mcast.c --- linux-2.6/net/ipv6/mcast.c Sat Aug 14 12:56:01 2004 +++ linux-2.6-s390/net/ipv6/mcast.c Thu Aug 26 11:23:45 2004 @@ -882,7 +882,6 @@ write_unlock_bh(&idev->lock); igmp6_group_dropped(ma); - ma_put(ma); return 0; } Mit freundlichen Grüssen / Best regards Frank Pavlic Linux for eServer Development Schoenaicher Str. 220, 71032 Boeblingen Phone: ext. +49-(0)7031/16-2463, int. *120-2463 mailto: pavlic@de.ibm.com From greearb@candelatech.com Thu Sep 16 16:22:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:22:49 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNMhhI031374 for ; Thu, 16 Sep 2004 16:22:43 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8GNP6LH011643; Thu, 16 Sep 2004 16:25:06 -0700 Message-ID: <414A2035.2040304@candelatech.com> Date: Thu, 16 Sep 2004 16:22:29 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, Robert.Olsson@data.slu.se, davem@redhat.com, netdev@oss.sgi.com, hadi@znyx.com Subject: Re: [PATCH] pktgen handle netdev device getting full. References: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> <414A1AD2.1090109@candelatech.com> <20040916155913.577b878b.davem@davemloft.net> In-Reply-To: <20040916155913.577b878b.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8965 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 2771 Lines: 69 David S. Miller wrote: > On Thu, 16 Sep 2004 15:59:30 -0700 > Ben Greear wrote: > > >>Stephen Hemminger wrote: >> >>>I was trying out pktgen on a NIC with an undersized ring, so >>>hard_start_xmit would always return non-zero when full. This caused a slew >>>of console messages. Better to just have pktgen retry in this case. >> >>My understanding is that if the queue is not stopped, then you >>should not get the hard xmit errors. So, in a proper driver, >>you should not see these printks. > > > That is absolutely correct, that is why Stephen's patch is > not correct (aside from the do_div() part which I'll happily > apply if submitted by itself). Well, in his defense, the e1000 and probably other drivers will cause this printk to happen (or, at least earlier versions of the e1000 in the 2.4.25 kernel will). >>By the way, is there any interest in adding my patch that also allows >>pktgen to receive packets (and count the statistics, etc)? I know >>DaveM objected to the hook in the skb-receive logic some time back, >>but maybe he has a different opinion now? > > > I still object to this, it will be abused. Even if the hook is exported GPL? (The bridging hook is almost identical in abusability, and it is not even exported GPL, just plain exported....) Just for grins, here is the /proc output from one of my tests. This is a pair of GigE nics running back to back on the same machine. Since it is the same clock, we can get very exact latency numbers, as well as packet drops, etc.... VERSION-1 Params: count 0 min_pkt_size: 60 max_pkt_size: 60 cur_pkt_size 60 frags: 0 ipg: 11478 multiskb: 0 ifname: eth2 dst_min: 172.2.2.3 dst_max: 172.2.2.3 src_min: 172.2.2.2 src_max: 172.2.2.2 src_mac: 00:07:E9:1F:97:C9 dst_mac: 00:07:E9:1F:97:C8 udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 peer_multiskb: 0 Flags: Current: pkts-sofar: 3488264 errors: 0 started: 1095376671654330us elapsed: 43664674us idle: 42349478538ns next_tx: 211092296137443(24804)ns seq_num: 3488265 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0x20202ac cur_daddr: 0x30202ac cur_udp_dst: 9 cur_udp_src: 9 pkts_rcvd: 3488254 bytes_rcvd: 174412700 last_seq_rcvd: 3488254 ooo_rcvd: 0 dup_rcvd: 0 seq_gap_rcvd(dropped): 0 non_pg_rcvd: 0 avg_latency: 148us min_lat: 6us max_lat: 2259us pkts_in_sample: 3488254 Buckets(us) [ 0 0 0 14416 55106 138901 266024 523649 1040910 1382427 66662 139 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@davemloft.net Thu Sep 16 16:23:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:23:36 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNNVTH031742 for ; Thu, 16 Sep 2004 16:23:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C85YF-0004PN-00; Thu, 16 Sep 2004 16:20:31 -0700 Date: Thu, 16 Sep 2004 16:20:30 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: greearb@candelatech.com, Robert.Olsson@data.slu.se, davem@redhat.com, netdev@oss.sgi.com, hadi@znyx.com Subject: Re: [PATCH] pktgen handle netdev device getting full. Message-Id: <20040916162030.3a65e7d5.davem@davemloft.net> In-Reply-To: <20040916162051.1b55ae5b@dell_ss3.pdx.osdl.net> References: <20040916144332.37f19fcb@dell_ss3.pdx.osdl.net> <414A1AD2.1090109@candelatech.com> <20040916155913.577b878b.davem@davemloft.net> <20040916162051.1b55ae5b@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8966 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 583 Lines: 14 On Thu, 16 Sep 2004 16:20:51 -0700 Stephen Hemminger wrote: > Well the E1000 fill's it Tx ring and returns TX_BUSY, and on > SMP can also get TX_LOCKED now. If that happens, the message shows up. > Several other drivers don't set stopped when ring is almost full, but > rely on scheduler to do it for them. TX_LOCKED is special, and actually this points out that pktgen.c needs to change how it interprets hard_start_xmit() return values now that TX_LOCKED is possible too. I'm sorry, is that what your patch was doing? Then it was correct, please resend. From davem@davemloft.net Thu Sep 16 16:25:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:25:56 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNPpmF032312 for ; Thu, 16 Sep 2004 16:25:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C85aU-0004Pg-00; Thu, 16 Sep 2004 16:22:50 -0700 Date: Thu, 16 Sep 2004 16:22:50 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jes@wildopensource.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] acenic - don't spin in hard_start_xmit when ring fills Message-Id: <20040916162250.5b7cfa85.davem@davemloft.net> In-Reply-To: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> References: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8967 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 653 Lines: 16 On Thu, 16 Sep 2004 16:17:53 -0700 Stephen Hemminger wrote: > Running performance tests on the acenic, I noticed that the driver > spins when the transmit ring gets full. This might have been okay when > CPU's were slower, but it isn't the right thing to do. Better to > return TX_BUSY and let network scheduling handle it. Acenic does completely lockless processing, are you sure you didn't add a race or bug? Also, NETDEV_TX_BUSY is not a valid return value for non-LLTX drivers. From Documentation/networking/netdevices.txt: o NETDEV_TX_LOCKED Locking failed, please retry quickly. Only valid when NETIF_F_LLTX is set. From shemminger@osdl.org Thu Sep 16 16:42:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:42:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNgSbH032755 for ; Thu, 16 Sep 2004 16:42:28 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8GNgAv20622; Thu, 16 Sep 2004 16:42:10 -0700 Date: Thu, 16 Sep 2004 16:42:06 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jes@wildopensource.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] acenic - don't spin in hard_start_xmit when ring fills Message-Id: <20040916164206.707204d4@dell_ss3.pdx.osdl.net> In-Reply-To: <20040916162250.5b7cfa85.davem@davemloft.net> References: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> <20040916162250.5b7cfa85.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8968 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 984 Lines: 24 On Thu, 16 Sep 2004 16:22:50 -0700 "David S. Miller" wrote: > On Thu, 16 Sep 2004 16:17:53 -0700 > Stephen Hemminger wrote: > > > Running performance tests on the acenic, I noticed that the driver > > spins when the transmit ring gets full. This might have been okay when > > CPU's were slower, but it isn't the right thing to do. Better to > > return TX_BUSY and let network scheduling handle it. > > Acenic does completely lockless processing, are you sure you didn't > add a race or bug? NO, the bus just isn't fast enough to keep up with the number of small packets I am shoving at it. You got TX_LOCKED and TX_BUSY confused. The problem is drivers that don't check to see if the last packet sent fills the ring and stop themselves. > o NETDEV_TX_BUSY Cannot transmit packet, try later > Usually a bug, means queue start/stop flow control is broken in > the driver. Note: the driver must NOT put the skb in its DMA ring. From davem@davemloft.net Thu Sep 16 16:53:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 16:53:49 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8GNrinT000770 for ; Thu, 16 Sep 2004 16:53:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C861S-0004SC-00; Thu, 16 Sep 2004 16:50:42 -0700 Date: Thu, 16 Sep 2004 16:50:42 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jes@wildopensource.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] acenic - don't spin in hard_start_xmit when ring fills Message-Id: <20040916165042.362a3e79.davem@davemloft.net> In-Reply-To: <20040916164206.707204d4@dell_ss3.pdx.osdl.net> References: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> <20040916162250.5b7cfa85.davem@davemloft.net> <20040916164206.707204d4@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 723 Lines: 24 On Thu, 16 Sep 2004 16:42:06 -0700 Stephen Hemminger wrote: > NO, the bus just isn't fast enough to keep up with the number of small > packets I am shoving at it. > > You got TX_LOCKED and TX_BUSY confused. The problem is drivers that > don't check to see if the last packet sent fills the ring and stop > themselves. I understand. But that still makes this change buggy. I believe the two choices are: 1) Accept this spinning performance characteristic of the acenic driver. or 2) Finally give up on acenic's clever lockless scheme and add the necessary locking + start/stop tx flow control so it will never have to return TX_BUSY except in absolutely catastrophic failure cases. From jgarzik@pobox.com Thu Sep 16 17:39:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 17:39:13 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H0d8MJ001569 for ; Thu, 16 Sep 2004 17:39:09 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C86m9-0000GM-07; Fri, 17 Sep 2004 01:38:57 +0100 Message-ID: <414A3213.9030401@pobox.com> Date: Thu, 16 Sep 2004 20:38:43 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ravinandan.arakali@s2io.com CC: netdev@oss.sgi.com, leonid.grossman@s2io.com, raghavendra.koushik@s2io.com, rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel References: <002201c499b4$7c7b60c0$a010100a@S2IOtech.com> In-Reply-To: <002201c499b4$7c7b60c0$a010100a@S2IOtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8970 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 705 Lines: 24 Ravinandan Arakali wrote: > Hi Jeff, > Attached is the patch with the first round comments incorporated. > In addition, this patch contains > Some fixes related to 32-bit systems. > Few fixes related to Rx path in NAPI. hmmm... it's a big undescribed patch that doesn't apply anymore :/ drivers/net/Kconfig 1.91 -> 1.92: 2657 lines 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/Kconfig.rej drivers/net/s2io-regs.h 1.1 -> 1.2: 775 lines drivers/net/s2io.c 1.6 -> 1.7: 4393 lines 1 out of 148 hunks FAILED -- saving rejects to file drivers/net/s2io.c.rej drivers/net/s2io.h 1.5 -> 1.6: 854 lines Can you please split it up into individual changes, or at least smaller chunks? Jeff From ravinandan.arakali@s2io.com Thu Sep 16 17:47:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 17:47:54 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H0llMq002002 for ; Thu, 16 Sep 2004 17:47:48 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8H0lVje018980; Thu, 16 Sep 2004 20:47:31 -0400 (EDT) Received: from rarakali ([10.16.16.160]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id i8H0lS39025846; Thu, 16 Sep 2004 20:47:29 -0400 (EDT) Reply-To: From: "Ravinandan Arakali" To: "'Jeff Garzik'" Cc: , , , Subject: RE: Patch submission for S2io Xframe driver to 2.6 kernel Date: Thu, 16 Sep 2004 17:53:30 -0700 Message-ID: <005001c49c50$c06b9810$a010100a@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <414A3213.9030401@pobox.com> Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 8971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@s2io.com Precedence: bulk X-list: netdev Content-Length: 1263 Lines: 42 Jeff, We tried it out with 2.6.7. Can you pls specify the kernel version on which you tried and we will send a patch which works for that version. We will also send a more detailed description of the changes along with that. Thanks, Ravi -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Thursday, September 16, 2004 5:39 PM To: ravinandan.arakali@s2io.com Cc: netdev@oss.sgi.com; leonid.grossman@s2io.com; raghavendra.koushik@s2io.com; rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel Ravinandan Arakali wrote: > Hi Jeff, > Attached is the patch with the first round comments incorporated. > In addition, this patch contains > Some fixes related to 32-bit systems. > Few fixes related to Rx path in NAPI. hmmm... it's a big undescribed patch that doesn't apply anymore :/ drivers/net/Kconfig 1.91 -> 1.92: 2657 lines 1 out of 1 hunk FAILED -- saving rejects to file drivers/net/Kconfig.rej drivers/net/s2io-regs.h 1.1 -> 1.2: 775 lines drivers/net/s2io.c 1.6 -> 1.7: 4393 lines 1 out of 148 hunks FAILED -- saving rejects to file drivers/net/s2io.c.rej drivers/net/s2io.h 1.5 -> 1.6: 854 lines Can you please split it up into individual changes, or at least smaller chunks? Jeff From jgarzik@pobox.com Thu Sep 16 17:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 17:53:19 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H0rD0u002429 for ; Thu, 16 Sep 2004 17:53:14 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C86zn-0000jK-8A; Fri, 17 Sep 2004 01:53:03 +0100 Message-ID: <414A3562.2090803@pobox.com> Date: Thu, 16 Sep 2004 20:52:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ravinandan.arakali@s2io.com CC: netdev@oss.sgi.com, leonid.grossman@s2io.com, raghavendra.koushik@s2io.com, rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel References: <005001c49c50$c06b9810$a010100a@S2IOtech.com> In-Reply-To: <005001c49c50$c06b9810$a010100a@S2IOtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8972 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 704 Lines: 22 Ravinandan Arakali wrote: > Jeff, > We tried it out with 2.6.7. Can you pls specify the kernel version > on which you tried and we will send a patch which works for that version. > We will also send a more detailed description of the changes along with > that. Always diff against the latest version of the kernel. You can find out the latest version by going to http://www.kernel.org/ You'll typically want the latest snapshot (preferably), or the latest pre-patch. Standard patch submission format is described at http://linux.yyz.us/patch-format.html and in Documentation/SubmittingPatches. When submitting a series of patches, it is normal patches to depend on preceding patches. Jeff From timg@tpi.com Thu Sep 16 20:04:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 20:04:35 -0700 (PDT) Received: from mail.tpi.com (mail.tpi.com [198.107.51.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H34S40004547 for ; Thu, 16 Sep 2004 20:04:29 -0700 Received: from [10.0.2.3] (unknown [10.0.2.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.tpi.com (Postfix) with ESMTP id 45CC82AAA1 for ; Thu, 16 Sep 2004 20:21:27 -0700 (PDT) Subject: CBQ quits when HZ=1000 From: Tim Gardner Reply-To: timg@tpi.com To: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-vAEaIfk+1qDMsT9RzRZi" Organization: TriplePoint, Inc. Message-Id: <1095390252.3932.38.camel@tim.rtg.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 21:04:12 -0600 X-archive-position: 8973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: timg@tpi.com Precedence: bulk X-list: netdev Content-Length: 2740 Lines: 53 --=-vAEaIfk+1qDMsT9RzRZi Content-Type: text/plain Content-Transfer-Encoding: 7bit I have a reasonably simple setup that shapes traffic to/from one address on a bridge. When HZ=100, everything works great. When HZ=1000, CBQ stops all traffic to this address forever as soon as throughput hits the CBQ limit, 1Mbit in this case. See attached rules. Has anyone else observed similar behavior? The kernel is 2.4.22 on an SC1100 (x86). PSCHED_CLOCK_SOURCE==PSCHED_JIFFIES rtg -- timg@tpi.com http://www.tpi.com 406-443-5357(MT) 503-601-0234(OR) --=-vAEaIfk+1qDMsT9RzRZi Content-Disposition: attachment; filename=cbqsetup Content-Type: text/x-sh; name=cbqsetup; charset=UTF-8 Content-Transfer-Encoding: 7bit #!/bin/sh # tc qdisc del dev eth0 root > /dev/null 2>&1 tc qdisc del dev eth1 root > /dev/null 2>&1 tc qdisc del dev eth0 ingress > /dev/null 2>&1 tc qdisc del dev eth1 ingress > /dev/null 2>&1 # =============================== #download ******************************************************************** tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1024 cell 8 mpu 64 tc class add dev eth0 parent 1:0 classid 1:10 cbq bandwidth 100Mbit rate 100Mbit isolated weight 1Mbit prio 5 allot 1514 cell 8 maxburst 100 avpkt 1024 bounded mpu 64 minburst 2 minidle 20 # =============================== tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 5 # Client 1 Download ********************************************************** tc class add dev eth0 parent 1:10 classid 1:101 cbq bandwidth 100Mbit bounded isolated rate 1024Kbit weight 102Kbit prio 5 allot 1522 cell 8 maxburst 102 avpkt 1024 mpu 64 minburst 10 minidle 51 tc qdisc add dev eth0 parent 1:101 handle 101: sfq perturb 5 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 10.0.2.4 flowid 1:101 # =============================== #upload ********************************************************************** tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 7Mbit avpkt 1024 cell 8 mpu 64 tc class add dev eth1 parent 1:0 classid 1:10 cbq bandwidth 7Mbit rate 7Mbit isolated weight 0.7Mbit prio 5 allot 1514 cell 8 maxburst 100 avpkt 1024 bounded mpu 64 minburst 2 minidle 20 # =============================== tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 5 # Client 1 Upload ************************************************************ tc class add dev eth1 parent 1:10 classid 1:101 cbq bandwidth 7Mbit bounded isolated rate 1024Kbit weight 102Kbit prio 5 allot 1522 cell 8 maxburst 102 avpkt 1024 mpu 64 minburst 10 minidle 51 tc qdisc add dev eth1 parent 1:101 handle 101: sfq perturb 5 tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip src 10.0.2.4 flowid 1:101 --=-vAEaIfk+1qDMsT9RzRZi-- From rddunlap@osdl.org Thu Sep 16 20:08:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 20:09:00 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H38tPP004946 for ; Thu, 16 Sep 2004 20:08:55 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8H38Zv16559; Thu, 16 Sep 2004 20:08:35 -0700 Date: Thu, 16 Sep 2004 20:07:35 -0700 From: "Randy.Dunlap" To: Jeff Garzik Cc: ravinandan.arakali@s2io.com, netdev@oss.sgi.com, leonid.grossman@s2io.com, raghavendra.koushik@s2io.com, rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel Message-Id: <20040916200735.57909f02.rddunlap@osdl.org> In-Reply-To: <414A3562.2090803@pobox.com> References: <005001c49c50$c06b9810$a010100a@S2IOtech.com> <414A3562.2090803@pobox.com> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8974 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1349 Lines: 56 On Thu, 16 Sep 2004 20:52:50 -0400 Jeff Garzik wrote: | Ravinandan Arakali wrote: | > Jeff, | > We tried it out with 2.6.7. Can you pls specify the kernel version | > on which you tried and we will send a patch which works for that version. | > We will also send a more detailed description of the changes along with | > that. For splitting it up :), e.g.: - 1 patch could be for renaming only, no code/logic changes (like TxCfg to tx_cfg); maybe including comments/whitespace changes; - 1 could be to eliminate (most/all) typedefs - 1 could be for errata/workarounds - 1 could be for ethtool support (changes) - 1 for NAPI support (changes) - 1 for 2BUFF mode etc... Q1: why is this change needed? static inline u64 readq(void *addr) { u64 ret = 0; ret = readl(addr + 4); - ret <<= 32; - ret |= readl(addr); + (u64) ret <<= 32; + (u64) ret |= readl(addr); | | Always diff against the latest version of the kernel. You can find out | the latest version by going to http://www.kernel.org/ You'll typically | want the latest snapshot (preferably), or the latest pre-patch. | | Standard patch submission format is described at | http://linux.yyz.us/patch-format.html and in | Documentation/SubmittingPatches. | | When submitting a series of patches, it is normal patches to depend on | preceding patches. -- ~Randy From rddunlap@osdl.org Thu Sep 16 21:00:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 21:00:16 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H40BbL009103 for ; Thu, 16 Sep 2004 21:00:11 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8H3xnv21825; Thu, 16 Sep 2004 20:59:49 -0700 Date: Thu, 16 Sep 2004 20:58:49 -0700 From: "Randy.Dunlap" To: Cc: jgarzik@pobox.com, netdev@oss.sgi.com, leonid.grossman@s2io.com, raghavendra.koushik@s2io.com, rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel Message-Id: <20040916205849.55ce05e5.rddunlap@osdl.org> In-Reply-To: <002201c499b4$7c7b60c0$a010100a@S2IOtech.com> References: <413116FF.7000701@pobox.com> <002201c499b4$7c7b60c0$a010100a@S2IOtech.com> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8975 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 624 Lines: 25 On Mon, 13 Sep 2004 10:09:53 -0700 Ravinandan Arakali wrote: | Hi Jeff, | Attached is the patch with the first round comments incorporated. | In addition, this patch contains | Some fixes related to 32-bit systems. | Few fixes related to Rx path in NAPI. | | Thanks to all for the comments. | | Pls review this patch as well and come back with your comments. 1. typo? first name is still used in source code: -static char s2io_driver_version[] = "Version 1.0"; +static char s2iO_driver_version[] = "Version 1.1"; 2. don't init. globals to 0 -- it's done automatically for you. (more this weekend....) -- ~Randy From dgibson@ozlabs.org Thu Sep 16 23:33:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 23:33:40 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H6XYsP015663 for ; Thu, 16 Sep 2004 23:33:34 -0700 Received: by ozlabs.org (Postfix, from userid 1007) id B10E92BD6A; Fri, 17 Sep 2004 16:33:17 +1000 (EST) Date: Fri, 17 Sep 2004 16:20:42 +1000 From: David Gibson To: Andrew Morton Cc: David Miller , trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [TRIVIAL] Fix recent bug in fib_semantics.c Message-ID: <20040917062042.GE6523@zax> Mail-Followup-To: David Gibson , Andrew Morton , David Miller , trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 8976 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david@gibson.dropbear.id.au Precedence: bulk X-list: netdev Content-Length: 1051 Lines: 34 Andrew, please apply: When fib_create_info() allocates new hash tables, it neglects to initialize them. This leads to an oops during boot on at least machine I use. This patch addresses the problem. Signed-off-by: David Gibson Index: working-2.6/net/ipv4/fib_semantics.c =================================================================== --- working-2.6.orig/net/ipv4/fib_semantics.c 2004-09-17 09:20:04.000000000 +1000 +++ working-2.6/net/ipv4/fib_semantics.c 2004-09-17 16:24:42.634638304 +1000 @@ -604,8 +604,12 @@ if (!new_info_hash || !new_laddrhash) { fib_hash_free(new_info_hash, bytes); fib_hash_free(new_laddrhash, bytes); - } else + } else { + memset(new_info_hash, 0, bytes); + memset(new_laddrhash, 0, bytes); + fib_hash_move(new_info_hash, new_laddrhash, new_size); + } if (!fib_hash_size) goto failure; -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From jgarzik@pobox.com Thu Sep 16 23:37:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 23:37:40 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H6bYOq016025 for ; Thu, 16 Sep 2004 23:37:35 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8CN0-0005Pc-K3; Fri, 17 Sep 2004 07:37:22 +0100 Message-ID: <414A8614.5000807@pobox.com> Date: Fri, 17 Sep 2004 02:37:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gibson CC: Andrew Morton , David Miller , trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c References: <20040917062042.GE6523@zax> In-Reply-To: <20040917062042.GE6523@zax> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 359 Lines: 15 David Gibson wrote: > Andrew, please apply: > > When fib_create_info() allocates new hash tables, it neglects to > initialize them. This leads to an oops during boot on at least > machine I use. This patch addresses the problem. > > Signed-off-by: David Gibson This may be the oops in fib_xxx I just saw on my Athlon64 box... Jeff From edmudama@gmail.com Thu Sep 16 23:47:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 16 Sep 2004 23:47:25 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H6lFOs016608 for ; Thu, 16 Sep 2004 23:47:15 -0700 Received: by mproxy.gmail.com with SMTP id 77so546216rnk for ; Thu, 16 Sep 2004 23:46:59 -0700 (PDT) Received: by 10.38.96.55 with SMTP id t55mr46362rnb; Thu, 16 Sep 2004 23:46:59 -0700 (PDT) Received: by 10.38.70.11 with HTTP; Thu, 16 Sep 2004 23:46:59 -0700 (PDT) Message-ID: <311601c90409162346184649eb@mail.gmail.com> Date: Fri, 17 Sep 2004 00:46:59 -0600 From: Eric Mudama Reply-To: Eric Mudama To: David Stevens Subject: Re: The ultimate TOE design Cc: Netdev , leonid.grossman@s2io.com, Linux Kernel In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4148991B.9050200@pobox.com> X-archive-position: 8978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edmudama@gmail.com Precedence: bulk X-list: netdev Content-Length: 203 Lines: 4 On Wed, 15 Sep 2004 14:11:04 -0600, David Stevens wrote: > Why don't we off-load filesystems to disks instead? Disks have had file systems on them since close to the beginning... From johnpol@2ka.mipt.ru Fri Sep 17 00:08:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 00:08:55 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H78iTZ017524 for ; Fri, 17 Sep 2004 00:08:45 -0700 Received: from localhost.localdomain (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i8H78OUO024449; Fri, 17 Sep 2004 11:08:25 +0400 Received: from localhost.localdomain (uganda [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8H7DQwZ006511; Fri, 17 Sep 2004 11:13:26 +0400 Received: (from s0mbre@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8H7DP9g006510; Fri, 17 Sep 2004 11:13:25 +0400 X-Authentication-Warning: localhost.localdomain: s0mbre set sender to johnpol@2ka.mipt.ru using -f Date: Fri, 17 Sep 2004 11:13:25 +0400 From: Evgeniy Polyakov To: jamal Cc: netdev@oss.sgi.com, Evgeniy Polyakov Subject: Re: Kernel connector - userspace <-> kernelspace "linker". Message-ID: <20040917071325.GA6502@uganda.factory.vocord.ru> References: <20040916200304.4fad9b6d@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040916200304.4fad9b6d@zanzibar.2ka.mipt.ru> User-Agent: Mutt/1.4.1i X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on dea.vocord.com X-Virus-Status: Clean X-archive-position: 8979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 12652 Lines: 548 On Thu, Sep 16, 2004 at 08:03:04PM +0400, Evgeniy Polyakov wrote: > Sorry for thread destruction, but I have not received you mail, > but see it in archive. I do beleive it is due to permanent glitch of > 2ka.mipt.ru SMTP server. > > > I dont have time to evaluate the code right now - but will at the end of > > day. Just trying to understand your concepts: > > > > Essentially you are building a unified messaging for > > userspace-userpace(i.e IPC), userspace-kernel, kernel-kernel with each > > component residing in whatever spot (kernel or userland)having a unique > > name and Id. Is this correct? > > Actually name and ID should be transformed to ID0 and ID1(they are callled > idx and val and are u32 values, since I strongly object against any ASCII > based identificators( sigh, I am cunning - superio has such ids)). > Since userspace can not register callback function, then it is not quite > fair to call it generic, but the idea is right. > > > Clearly there could be name/Id conflicts etc. Are you addressing those? > > Hmm, u32+u32 - I do not beleive that it can conflict, but if they do, then > first registered with given idx+val will pay the pipper and call the tune. > Second call with the same parameters for register_callback() fill fail. > > > Any event and filtering capability already in or planned? Example event > > I want to be notified when module with name "sean paul" comes online and > > filter will be "it has to have ID in the range of 0x200-0x400". > > Such information does exist in connector driver and it _can_ be easily > obtained. I will call it feature request that fits the design > and will implement this today/tomorrow. :) > > > I am still trying to wakeup but it does sound like a good idea to have a > > generic messaging subsystem. > > Good afternoon :). kind of dmesg: Notify group 1 for idx: 291-300 Notify group 1 for val: 1110-1119 1130-1139 Request was sent. Group=0x1. + + <6>Notifying group 1 with event 0 about 123.456. + + <6>Notifying group 1 with event 0 about 123.457. + + <6>Notifying group 1 with event 1 about 123.457. + + <6>Notifying group 1 with event 1 about 123.456. 0 - device added 1 - removed Kind of patch... * looking for johnpol@2ka.mipt.ru-2004/connector--main--0--patch-10 to compare with * comparing to johnpol@2ka.mipt.ru-2004/connector--main--0--patch-10 M cn_test.c M connector.c M connector.h M ucon.c * modified files --- orig/cn_test.c +++ mod/cn_test.c @@ -22,11 +22,13 @@ #include #include #include +#include #include "connector.h" static struct cb_id cn_test_id = { 0x123, 0x456 }; static char cn_test_name[] = "cn_test"; +static struct sock *nls; void cn_test_callback(void *data) { @@ -36,21 +38,112 @@ __func__, msg->id.idx, msg->id.val, msg->len); } +static int cn_test_want_notify(void) +{ + struct cn_ctl_msg *ctl; + struct cn_notify_req *req; + struct cn_msg *msg = NULL; + int size, size0; + struct sk_buff *skb; + struct nlmsghdr *nlh; + u32 group = 1; + + size0 = sizeof(*msg) + sizeof(*ctl) + 3*sizeof(*req); + + size = NLMSG_SPACE(size0); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + + return -ENOMEM; + } + + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh)); + + msg = (struct cn_msg *)NLMSG_DATA(nlh); + + memset(msg, 0, size0); + + msg->id.idx = -1; + msg->id.val = -1; + msg->seq = 0x123; + msg->ack = 0x345; + msg->len = size0 - sizeof(*msg); + + ctl = (struct cn_ctl_msg *)(msg + 1); + + ctl->idx_notify_num = 1; + ctl->val_notify_num = 2; + ctl->group = group; + + req = (struct cn_notify_req *)(ctl + 1); + + /* + * Idx. + */ + req->first = cn_test_id.idx; + req->range = 10; + + /* + * Val 0. + */ + req++; + req->first = cn_test_id.val; + req->range = 10; + + /* + * Val 1. + */ + req++; + req->first = cn_test_id.val + 20; + req->range = 10; + + NETLINK_CB(skb).dst_groups = ctl->group; + //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); + netlink_unicast(nls, skb, 0, 0); + + printk(KERN_INFO "Request was sent. Group=0x%x.\n", group); + + return 0; + +nlmsg_failure: + printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); + kfree_skb(skb); + return -EINVAL; +} + static int cn_test_init(void) { int err; + + nls = netlink_kernel_create(NETLINK_NFLOG, NULL); + if (!nls) { + printk(KERN_ERR "Failed to create new netlink socket(%u).\n", NETLINK_NFLOG); + return -EIO; + } + + err = cn_test_want_notify(); + if (err) + goto err_out; err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); if (err) - return err; + goto err_out; cn_test_id.val++; err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); if (err) { cn_del_callback(&cn_test_id); - return err; + goto err_out; } return 0; + +err_out: + if (nls->sk_socket) + sock_release(nls->sk_socket); + + return err; } static void cn_test_fini(void) @@ -58,6 +151,8 @@ cn_del_callback(&cn_test_id); cn_test_id.val--; cn_del_callback(&cn_test_id); + if (nls->sk_socket) + sock_release(nls->sk_socket); } module_init(cn_test_init); --- orig/connector.c +++ mod/connector.c @@ -36,9 +36,17 @@ MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector."); static int unit = NETLINK_NFLOG; +static u32 cn_idx = -1; +static u32 cn_val = -1; + module_param(unit, int, 0); +module_param(cn_idx, uint, 0); +module_param(cn_val, uint, 0); + +spinlock_t notify_lock = SPIN_LOCK_UNLOCKED; +static LIST_HEAD(notify_list); -struct cn_dev cdev; +static struct cn_dev cdev; /* * msg->seq and msg->ack are used to determine message genealogy. @@ -59,7 +67,7 @@ * then it is new message. * */ -void cn_netlink_send(struct cn_msg *msg) +void cn_netlink_send(struct cn_msg *msg, u32 __groups) { struct cn_callback_entry *n, *__cbq; unsigned int size; @@ -70,20 +78,25 @@ u32 groups = 0; int found = 0; - spin_lock(&dev->cbdev->queue_lock); - list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { - if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { - found = 1; - groups = __cbq->group; + if (!__groups) + { + spin_lock(&dev->cbdev->queue_lock); + list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { + found = 1; + groups = __cbq->group; + } } - } - spin_unlock(&dev->cbdev->queue_lock); + spin_unlock(&dev->cbdev->queue_lock); - if (!found) { - printk(KERN_ERR "Failed to find multicast netlink group for callback[0x%x.0x%x]. seq=%u\n", - msg->id.idx, msg->id.val, msg->seq); - return; + if (!found) { + printk(KERN_ERR "Failed to find multicast netlink group for callback[0x%x.0x%x]. seq=%u\n", + msg->id.idx, msg->id.val, msg->seq); + return; + } } + else + groups = __groups; size = NLMSG_SPACE(sizeof(*msg) + msg->len); @@ -147,6 +160,15 @@ seq = nlh->nlmsg_seq; group = NETLINK_CB((skb)).groups; msg = (struct cn_msg *)NLMSG_DATA(nlh); + + if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) + { + printk(KERN_ERR "skb does not have enough length: requested msg->len=%u[%u], nlh->nlmsg_len=%u[%u], skb->len=%u[must be %u].\n", + msg->len, NLMSG_SPACE(msg->len), + nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*nlh), + skb->len, msg->len + sizeof(*msg)); + return -EINVAL; + } #if 0 printk(KERN_INFO "pid=%u, uid=%u, seq=%u, group=%u.\n", pid, uid, seq, group); @@ -188,7 +210,7 @@ err = __cn_rx_skb(skb, nlh); if (err) { - if (err < 0) + if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK)) netlink_ack(skb, nlh, -err); kfree_skb(skb); break; @@ -210,6 +232,59 @@ cn_rx_skb(skb); } +static void cn_notify(struct cb_id *id, u32 notify_event) +{ + struct cn_ctl_entry *ent; + + spin_lock(¬ify_lock); + list_for_each_entry(ent, ¬ify_list, notify_entry) + { + int i; + struct cn_notify_req *req; + struct cn_ctl_msg *ctl = ent->msg; + int a, b; + + a = b = 0; + + req = (struct cn_notify_req *)ctl->data; + for (i=0; iidx_notify_num; ++i, ++req) + { + if (id->idx >= req->first && id->idx < req->first + req->range) + { + printk("+ "); + a = 1; + break; + } + } + + for (i=0; ival_notify_num; ++i, ++req) + { + if (id->val >= req->first && id->val < req->first + req->range) + { + printk("+ "); + b = 1; + break; + } + } + + if (a && b) + { + struct cn_msg m; + + printk(KERN_INFO "Notifying group %x with event %u about %x.%x.\n", + ctl->group, notify_event, + id->idx, id->val); + + memset(&m, 0, sizeof(m)); + m.ack = notify_event; + + memcpy(&m.id, id, sizeof(m.id)); + cn_netlink_send(&m, ctl->group); + } + } + spin_unlock(¬ify_lock); +} + int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)) { int err; @@ -237,6 +312,8 @@ kfree(cb); return err; } + + cn_notify(id, 0); return 0; } @@ -249,16 +326,85 @@ list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { if (cn_cb_equal(&__cbq->cb->id, id)) { cn_queue_del_callback(dev->cbdev, __cbq->cb); + cn_notify(id, 1); break; } } } +static void cn_callback(void * data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + struct cn_ctl_msg *ctl; + struct cn_ctl_entry *ent; + u32 size; + + if (msg->len < sizeof(*ctl)) + { + printk(KERN_ERR "Wrong connector request size %u, must be >= %u.\n", + msg->len, sizeof(*ctl)); + return; + } + + ctl = (struct cn_ctl_msg *)msg->data; + + size = sizeof(*ctl) + (ctl->idx_notify_num + ctl->val_notify_num)*sizeof(struct cn_notify_req); + + if (msg->len != size) + { + printk(KERN_ERR "Wrong connector request size %u, must be == %u.\n", + msg->len, size); + return; + } + + size += sizeof(*ent); + + ent = kmalloc(size, GFP_ATOMIC); + if (!ent) + { + printk(KERN_ERR "Failed to allocate %d bytes for new notify entry.\n", size); + return; + } + + memset(ent, 0, size); + + ent->msg = (struct cn_ctl_msg *)(ent + 1); + + memcpy(ent->msg, ctl, size - sizeof(*ent)); + + spin_lock(¬ify_lock); + list_add(&ent->notify_entry, ¬ify_list); + spin_unlock(¬ify_lock); + + { + int i; + struct cn_notify_req *req; + + printk("Notify group %x for idx: ", ctl->group); + + req = (struct cn_notify_req *)ctl->data; + for (i=0; iidx_notify_num; ++i, ++req) + { + printk("%u-%u ", req->first, req->first+req->range-1); + } + + printk("\nNotify group %x for val: ", ctl->group); + + for (i=0; ival_notify_num; ++i, ++req) + { + printk("%u-%u ", req->first, req->first+req->range-1); + } + printk("\n"); + } +} + static int cn_init(void) { struct cn_dev *dev = &cdev; dev->input = cn_input; + dev->id.idx = cn_idx; + dev->id.val = cn_val; dev->nls = netlink_kernel_create(unit, dev->input); if (!dev->nls) { @@ -274,13 +420,14 @@ return -EINVAL; } - return 0; + return cn_add_callback(&dev->id, "connector", &cn_callback); } static void cn_fini(void) { struct cn_dev *dev = &cdev; + cn_del_callback(&dev->id); cn_queue_free_dev(dev->cbdev); if (dev->nls->sk_socket) sock_release(dev->nls->sk_socket); --- orig/connector.h +++ mod/connector.h @@ -37,12 +37,34 @@ __u8 data[0]; }; +struct cn_notify_req +{ + __u32 first; + __u32 range; +}; + +struct cn_ctl_msg +{ + __u32 idx_notify_num; + __u32 val_notify_num; + __u32 group; + __u8 data[0]; +}; + #ifdef __KERNEL__ #include +struct cn_ctl_entry +{ + struct list_head notify_entry; + struct cn_ctl_msg *msg; +}; + struct cn_dev { + struct cb_id id; + u32 seq, groups; struct sock *nls; void (*input)(struct sock *sk, int len); @@ -52,7 +74,7 @@ int cn_add_callback(struct cb_id *, char *, void (* callback)(void *)); void cn_del_callback(struct cb_id *); -void cn_netlink_send(struct cn_msg *); +void cn_netlink_send(struct cn_msg *, u32); #endif /* __KERNEL__ */ #endif /* __CONNECTOR_H */ --- orig/ucon.c +++ mod/ucon.c @@ -118,8 +118,7 @@ l_local.nl_groups = 1; l_local.nl_pid = getpid(); - if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == - -1) { + if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) { perror("bind"); close(s); return -1; > > cheers, > jamal > > Evgeniy Polyakov > > Only failure makes us experts. -- Theo de Raadt -- Signed-off-by: Evgeniy Polyakov -- Evgeniy Polyakov ( s0mbre ) Crash is better than data corruption. -- Artur Grabowski From zilvinas@gemtek.lt Fri Sep 17 00:43:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 00:44:07 -0700 (PDT) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H7hskn021342 for ; Fri, 17 Sep 2004 00:43:57 -0700 Received: from [192.168.3.3] ([192.168.2.249]) by barclay.balt.net (8.12.11/8.12.11/Debian-5) with ESMTP id i8H7hAFm007109; Fri, 17 Sep 2004 10:43:11 +0300 Subject: Re: Crypto tests via tcrypt.o modules failes From: Zilvinas Valinskas Reply-To: zilvinas@gemtek.lt To: James Morris Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-tv8yCFiSNkVdaGMy0ck1" Organization: Gemtek Baltic Message-Id: <1095407021.4174.1.camel@swoop.gemtek.lt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 10:43:41 +0300 X-archive-position: 8980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev Content-Length: 22611 Lines: 991 --=-tv8yCFiSNkVdaGMy0ck1 Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached .config for Xscale. On Thu, 2004-09-16 at 22:29, James Morris wrote: > On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > > > I would say Xscale IXP425 has a rather interesting 32, 16 bits > > read/write results if address is not aligned properly. > > Odd, no other algorithms seem to be having any problems. Can you post > your .config? > > - James --=-tv8yCFiSNkVdaGMy0ck1 Content-Disposition: attachment; filename=.config Content-Type: text/plain; name=.config; charset=iso-8859-1 Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # CONFIG_ARM=y # CONFIG_EISA is not set # CONFIG_SBUS is not set # CONFIG_MCA is not set CONFIG_UID16=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_GENERIC_BUST_SPINLOCK is not set # CONFIG_GENERIC_ISA_DMA is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_ADVANCED_OPTIONS is not set # CONFIG_OBSOLETE is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KMOD is not set # # System Type # # CONFIG_ARCH_ADIFCC is not set # CONFIG_ARCH_ANAKIN is not set # CONFIG_ARCH_ARCA5K is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_CAMELOT is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_IOP3XX is not set # CONFIG_ARCH_IXP1200 is not set # CONFIG_ARCH_IXP2000 is not set CONFIG_ARCH_IXP425=y # CONFIG_ARCH_OMAHA is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_MX1ADS is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_RISCSTATION is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_AT91RM9200 is not set # # Archimedes/A5000 Implementations # # # Archimedes/A5000 Implementations (select only ONE) # # CONFIG_ARCH_ARC is not set # CONFIG_ARCH_A5K is not set # # Footbridge Implementations # # CONFIG_ARCH_CATS is not set # CONFIG_ARCH_PERSONAL_SERVER is not set # CONFIG_ARCH_EBSA285_ADDIN is not set # CONFIG_ARCH_EBSA285_HOST is not set # CONFIG_ARCH_NETWINDER is not set # # SA11x0 Implementations # # CONFIG_SA1100_ACCELENT is not set # CONFIG_SA1100_ASSABET is not set # CONFIG_ASSABET_NEPONSET is not set # CONFIG_SA1100_ADSAGC is not set # CONFIG_SA1100_ADSBITSY is not set # CONFIG_SA1100_ADSBITSYPLUS is not set # CONFIG_SA1100_BRUTUS is not set # CONFIG_SA1100_CEP is not set # CONFIG_SA1100_CERF is not set # CONFIG_SA1100_H3100 is not set # CONFIG_SA1100_H3600 is not set # CONFIG_SA1100_H3800 is not set # CONFIG_SA1100_H3XXX is not set # CONFIG_H3600_SLEEVE is not set # CONFIG_SA1100_EXTENEX1 is not set # CONFIG_SA1100_FLEXANET is not set # CONFIG_SA1100_FREEBIRD is not set # CONFIG_SA1100_FRODO is not set # CONFIG_SA1100_GRAPHICSCLIENT is not set # CONFIG_SA1100_GRAPHICSMASTER is not set # CONFIG_SA1100_HACKKIT is not set # CONFIG_SA1100_BADGE4 is not set # CONFIG_SA1100_JORNADA720 is not set # CONFIG_SA1100_HUW_WEBPANEL is not set # CONFIG_SA1100_ITSY is not set # CONFIG_SA1100_LART is not set # CONFIG_SA1100_NANOENGINE is not set # CONFIG_SA1100_OMNIMETER is not set # CONFIG_SA1100_PANGOLIN is not set # CONFIG_SA1100_PLEB is not set # CONFIG_SA1100_PT_SYSTEM3 is not set # CONFIG_SA1100_SHANNON is not set # CONFIG_SA1100_SHERMAN is not set # CONFIG_SA1100_SIMPAD is not set # CONFIG_SA1100_SIMPUTER is not set # CONFIG_SA1100_PFS168 is not set # CONFIG_SA1100_VICTOR is not set # CONFIG_SA1100_XP860 is not set # CONFIG_SA1100_YOPY is not set # CONFIG_SA1100_USB is not set # CONFIG_SA1100_USB_NETLINK is not set # CONFIG_SA1100_USB_CHAR is not set # CONFIG_SA1100_SSP is not set # # IXP425 Implementation Options # # CONFIG_ARCH_IXDP425 is not set # CONFIG_ARCH_IXCDP1100 is not set # CONFIG_ARCH_PRPMC1100 is not set CONFIG_ARCH_IXP425_COYOTE=y # CONFIG_ARCH_SE4000 is not set # # IXP425 Options # CONFIG_IXP425_SDRAM_SIZE=64 # CONFIG_IXP425_LARGE_SDRAM is not set CONFIG_IXP425_PCI_ERRATA=y # CONFIG_IXP425_OS_TIMER1 is not set # CONFIG_XSCALE_PMU_TIMER is not set # # AT91RM9200 Implementations # # CONFIG_ARCH_AT91RM9200DK is not set # # CLPS711X/EP721X Implementations # # CONFIG_ARCH_AUTCPU12 is not set # CONFIG_ARCH_CDB89712 is not set # CONFIG_ARCH_CLEP7312 is not set # CONFIG_ARCH_EDB7211 is not set # CONFIG_ARCH_FORTUNET is not set # CONFIG_ARCH_GUIDEA07 is not set # CONFIG_ARCH_P720T is not set # CONFIG_ARCH_EP7211 is not set # CONFIG_ARCH_EP7212 is not set # CONFIG_ARCH_ACORN is not set # CONFIG_FOOTBRIDGE is not set # CONFIG_FOOTBRIDGE_HOST is not set # CONFIG_FOOTBRIDGE_ADDIN is not set # # Processor Type # CONFIG_CPU_32=y # CONFIG_CPU_26 is not set # CONFIG_CPU_ARM610 is not set # CONFIG_CPU_ARM710 is not set # CONFIG_CPU_ARM720T is not set # CONFIG_CPU_ARM920T is not set # CONFIG_CPU_ARM922T is not set # CONFIG_PLD is not set # CONFIG_CPU_ARM926T is not set # CONFIG_CPU_ARM1020 is not set # CONFIG_CPU_ARM1026 is not set # CONFIG_CPU_SA110 is not set # CONFIG_CPU_SA1100 is not set # CONFIG_CPU_32v3 is not set # CONFIG_CPU_32v4 is not set CONFIG_CPU_32v5=y CONFIG_CPU_XSCALE=y CONFIG_ARM_THUMB=y # # Processor Features # # CONFIG_XSCALE_PMU_TIMER is not set CONFIG_XSCALE_CACHE_ERRATA=y # CONFIG_XSCALE_BDI2000 is not set # CONFIG_DISCONTIGMEM is not set CONFIG_CPU_BIG_ENDIAN=y # # General setup # CONFIG_PCI=y CONFIG_PCI_AUTOCONFIG=y # CONFIG_ISA is not set # CONFIG_ISA_DMA is not set CONFIG_KERNEL_START=0xc0000000 # CONFIG_ZBOOT_ROM is not set CONFIG_ZBOOT_ROM_TEXT=0 CONFIG_ZBOOT_ROM_BSS=0 CONFIG_PCI_NAMES=y # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_NET=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # # At least one math emulation must be selected # CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set # CONFIG_FPE_FASTFPE is not set CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_PM is not set # CONFIG_ARTHUR is not set CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/mtdblock2 init=/linuxrc mem=64M@0x0 reboot=h" CONFIG_ALIGNMENT_TRAP=y # # Parallel port support # # CONFIG_PARPORT is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=y CONFIG_MTD_REDBOOT_PARTS=y # CONFIG_MTD_CMDLINE_PARTS is not set # CONFIG_MTD_AFS_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=y # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_GEN_PROBE=y # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_CFI_INTELEXT=y # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_CFI_STAA is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # CONFIG_MTD_AMDSTD is not set # CONFIG_MTD_SHARP is not set # CONFIG_MTD_JEDEC is not set # # Mapping drivers for chip access # # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_NORA is not set # CONFIG_MTD_ARM_INTEGRATOR is not set # CONFIG_MTD_CDB89712 is not set # CONFIG_MTD_SA1100 is not set # CONFIG_MTD_DC21285 is not set # CONFIG_MTD_IQ80310 is not set # CONFIG_MTD_EPXA10DB is not set # CONFIG_MTD_FORTUNET is not set # CONFIG_MTD_AUTCPU12 is not set CONFIG_MTD_IXP425=y # CONFIG_MTD_EDB7312 is not set # CONFIG_MTD_IMPA7 is not set # CONFIG_MTD_CEIVA is not set # CONFIG_MTD_PCI is not set # CONFIG_MTD_PCMCIA is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC1000 is not set # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOCPROBE is not set # # NAND Flash Device Drivers # # CONFIG_MTD_NAND is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y # CONFIG_IP_ROUTE_FWMARK is not set CONFIG_IP_ROUTE_NAT=y # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_TOS is not set # CONFIG_IP_ROUTE_VERBOSE is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_AMANDA=y CONFIG_IP_NF_TFTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y # CONFIG_IP_NF_MATCH_PKTTYPE is not set CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y # CONFIG_IP_NF_MATCH_RECENT is not set # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set CONFIG_IP_NF_MATCH_AH_ESP=y # CONFIG_IP_NF_MATCH_LENGTH is not set # CONFIG_IP_NF_MATCH_TTL is not set CONFIG_IP_NF_MATCH_TCPMSS=y # CONFIG_IP_NF_MATCH_HELPER is not set CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_UNCLEAN=y # CONFIG_IP_NF_MATCH_OWNER is not set # CONFIG_IP_NF_MATCH_PHYSDEV is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y # CONFIG_IP_NF_TARGET_MIRROR is not set CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_NAT_AMANDA=y # CONFIG_IP_NF_NAT_LOCAL is not set # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_NAT_TFTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y # CONFIG_IP_NF_TARGET_ECN is not set # CONFIG_IP_NF_TARGET_DSCP is not set CONFIG_IP_NF_TARGET_MARK=y # CONFIG_IP_NF_TARGET_LOG is not set CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_IP_NF_ARPTABLES is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_KHTTPD is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set CONFIG_VLAN_8021Q=y # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set CONFIG_BRIDGE=y CONFIG_BRIDGE_NF_EBTABLES=y CONFIG_BRIDGE_EBT_T_FILTER=y CONFIG_BRIDGE_EBT_T_NAT=y CONFIG_BRIDGE_EBT_BROUTE=y CONFIG_BRIDGE_EBT_LOG=y CONFIG_BRIDGE_EBT_IPF=y CONFIG_BRIDGE_EBT_ARPF=y # CONFIG_BRIDGE_EBT_AMONG is not set # CONFIG_BRIDGE_EBT_LIMIT is not set CONFIG_BRIDGE_EBT_VLANF=y # CONFIG_BRIDGE_EBT_802_3 is not set # CONFIG_BRIDGE_EBT_PKTTYPE is not set # CONFIG_BRIDGE_EBT_STP is not set CONFIG_BRIDGE_EBT_MARKF=y # CONFIG_BRIDGE_EBT_ARPREPLY is not set CONFIG_BRIDGE_EBT_SNAT=y CONFIG_BRIDGE_EBT_DNAT=y CONFIG_BRIDGE_EBT_REDIRECT=y CONFIG_BRIDGE_EBT_MARK_T=y # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=y # CONFIG_NET_SCH_HTB is not set # CONFIG_NET_SCH_CSZ is not set # CONFIG_NET_SCH_HFSC is not set # CONFIG_NET_SCH_PRIO is not set CONFIG_NET_SCH_RED=y # CONFIG_NET_SCH_SFQ is not set # CONFIG_NET_SCH_TEQL is not set CONFIG_NET_SCH_TBF=y # CONFIG_NET_SCH_GRED is not set # CONFIG_NET_SCH_NETEM is not set # CONFIG_NET_SCH_DSMARK is not set # CONFIG_NET_SCH_INGRESS is not set # CONFIG_NET_QOS is not set CONFIG_NET_CLS=y # CONFIG_NET_CLS_TCINDEX is not set # CONFIG_NET_CLS_ROUTE4 is not set CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_U32=y # # Network testing # # CONFIG_NET_PKTGEN is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_ARM_AM79C961A is not set # CONFIG_ARM_CIRRUS is not set # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set # CONFIG_E100 is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_FORCEDETH is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_SUNDANCE_MMIO is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set CONFIG_IXP425_ETH=m # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=y CONFIG_PPP_MULTILINK=y # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=y CONFIG_PPP_SYNC_TTY=y CONFIG_PPP_DEFLATE=y # CONFIG_PPP_BSDCOMP is not set CONFIG_PPPOE=y # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # CONFIG_STRIP is not set # CONFIG_WAVELAN is not set # CONFIG_ARLAN is not set # CONFIG_AIRONET4500 is not set # CONFIG_AIRONET4500_NONCS is not set # CONFIG_AIRONET4500_PROC is not set # CONFIG_AIRO is not set # CONFIG_HERMES is not set # CONFIG_PLX_HERMES is not set # CONFIG_TMD_HERMES is not set # CONFIG_PCI_HERMES is not set CONFIG_NET_WIRELESS=y # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ATA/ATAPI/MFM/RLL support # # CONFIG_IDE is not set # CONFIG_BLK_DEV_IDE_MODES is not set # CONFIG_BLK_DEV_HD is not set # # SCSI support # # CONFIG_SCSI is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_UINPUT is not set # # Character devices # # CONFIG_VT is not set CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set CONFIG_IPMI_WATCHDOG=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_PCWATCHDOG is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_60XX_WDT is not set # CONFIG_SC1200_WDT is not set # CONFIG_SCx200_WDT is not set # CONFIG_SOFT_WATCHDOG is not set # CONFIG_W83877F_WDT is not set # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SCx200 is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_PM768 is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # # Direct Rendering Manager (XFree86 DRI support) # # CONFIG_DRM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_QFMT_V2 is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set # CONFIG_EXT3_FS is not set # CONFIG_JBD is not set # CONFIG_JBD_DEBUG is not set # CONFIG_FAT_FS is not set # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=0 CONFIG_CRAMFS=y CONFIG_TMPFS=y CONFIG_RAMFS=y # CONFIG_ISO9660_FS is not set # CONFIG_JOLIET is not set # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_MINIX_FS=y # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set # CONFIG_EXT2_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # CONFIG_XFS_FS is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_RT is not set # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m # CONFIG_NFS_V3 is not set # CONFIG_NFS_DIRECTIO is not set # CONFIG_ROOT_NFS is not set # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_SUNRPC=m CONFIG_LOCKD=m # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set # CONFIG_MSDOS_PARTITION is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SMB_NLS is not set # CONFIG_NLS is not set # # Sound # # CONFIG_SOUND is not set # # Misc devices # # # USB support # # CONFIG_USB is not set # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_FRAME_POINTER=y # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_INFO is not set # CONFIG_NO_PGT_CACHE is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SLAB is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_WAITQ is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_ERRORS=y CONFIG_DEBUG_LL=y # CONFIG_DEBUG_DC21285_PORT is not set # CONFIG_DEBUG_CLPS711X_UART2 is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=y CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_TEA=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_MICHAEL_MIC=y CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y --=-tv8yCFiSNkVdaGMy0ck1-- From zilvinas@gemtek.lt Fri Sep 17 00:49:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 00:49:44 -0700 (PDT) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H7nanJ021715 for ; Fri, 17 Sep 2004 00:49:37 -0700 Received: from [192.168.3.3] ([192.168.2.249]) by barclay.balt.net (8.12.11/8.12.11/Debian-5) with ESMTP id i8H7mrLl007246; Fri, 17 Sep 2004 10:48:54 +0300 Subject: Re: Crypto tests via tcrypt.o modules failes From: Zilvinas Valinskas Reply-To: zilvinas@gemtek.lt To: James Morris Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Gemtek Baltic Message-Id: <1095407364.4174.6.camel@swoop.gemtek.lt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 10:49:25 +0300 Content-Transfer-Encoding: 7bit X-archive-position: 8981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev Content-Length: 2050 Lines: 76 On Thu, 2004-09-16 at 22:25, James Morris wrote: > On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > > > Details are here,http://www.gemtek.lt/~zilvinas/crypto/tcrypt-tests > > AES is failing, but it has proven to be endian safe on other > architectures. > > > Where does the 'fig' come from in: > > <4>decrypt: fig that's my printk ... here goes diff : --- aes.c (revision 1164) +++ aes.c (working copy) @@ -344,11 +344,22 @@ u32 b0[4], b1[4]; const u32 *kp = E_KEY + 4; + int i; + + printk("encrypt: fig\n"); + + printk("encrypting block: "); + for (i=0; i<16; i++) + printk("%02X ", in[i]); + printk("\n"); + b0[0] = u32_in (in) ^ E_KEY[0]; b0[1] = u32_in (in + 4) ^ E_KEY[1]; b0[2] = u32_in (in + 8) ^ E_KEY[2]; b0[3] = u32_in (in + 12) ^ E_KEY[3]; + if (ctx->key_length > 24) { f_nround (b1, b0, kp); f_nround (b0, b1, kp); @@ -397,12 +408,17 @@ u32 b0[4], b1[4]; const int key_len = ctx->key_length; const u32 *kp = D_KEY + key_len + 20; + int i; + printk("decrypt: fig\n"); + b0[0] = u32_in (in) ^ E_KEY[key_len + 24]; b0[1] = u32_in (in + 4) ^ E_KEY[key_len + 25]; b0[2] = u32_in (in + 8) ^ E_KEY[key_len + 26]; b0[3] = u32_in (in + 12) ^ E_KEY[key_len + 27]; + if (key_len > 24) { i_nround (b1, b0, kp); i_nround (b0, b1, kp); @@ -428,6 +444,11 @@ u32_out (out + 4, b0[1]); u32_out (out + 8, b0[2]); u32_out (out + 12, b0[3]); + + printk("decrypted block: "); + for (i=0; i<16; i++) + printk("%02X ", out[i]); + printk("\n"); I've tried to check/make sure - when two boards Xscale <-> Xscale encrypts and decrypts data the same. Although it matches - content print exactly the same - ping gets no echo-reply ... :( No clue where to start looking. > > Can you try a completely unpatched kernel? > > > - James From zilvinas@gemtek.lt Fri Sep 17 00:56:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 00:56:52 -0700 (PDT) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H7ujWL022194 for ; Fri, 17 Sep 2004 00:56:47 -0700 Received: from [192.168.3.3] ([192.168.2.249]) by barclay.balt.net (8.12.11/8.12.11/Debian-5) with ESMTP id i8H7u2qE007407; Fri, 17 Sep 2004 10:56:02 +0300 Subject: Re: Crypto tests via tcrypt.o modules failes From: Zilvinas Valinskas Reply-To: zilvinas@gemtek.lt To: James Morris Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Gemtek Baltic Message-Id: <1095407793.4174.10.camel@swoop.gemtek.lt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 10:56:33 +0300 Content-Transfer-Encoding: 7bit X-archive-position: 8982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev Content-Length: 908 Lines: 34 strings like "dst_output: 0" in tcrypto-tests is due to this patch : --- include/net/dst.h (revision 1173) +++ include/net/dst.h (working copy) @@ -217,6 +217,7 @@ for (;;) { err = skb->dst->output(skb); + printk("dst_output: %d\n", err); if (likely(err == 0)) return err; @@ -232,6 +233,7 @@ for (;;) { err = skb->dst->input(skb); + printk("dst_input: %d\n", err); if (likely(err == 0)) return err; On Thu, 2004-09-16 at 22:29, James Morris wrote: > On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > > > I would say Xscale IXP425 has a rather interesting 32, 16 bits > > read/write results if address is not aligned properly. > > Odd, no other algorithms seem to be having any problems. Can you post > your .config? > > > - James From martin.bouzek@radas-atc.cz Fri Sep 17 02:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:24:11 -0700 (PDT) Received: from out.smtp.cz (peter.smtp.cz [81.95.97.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9O1n4023645 for ; Fri, 17 Sep 2004 02:24:01 -0700 Received: (qmail 17274 invoked from network); 17 Sep 2004 09:23:45 -0000 Received: from unknown (HELO ?192.168.1.100?) (staff.praha@radas-atc.cz@62.177.68.19) by peter.smtp.cz with AES256-SHA encrypted SMTP; 17 Sep 2004 09:23:44 -0000 Subject: Re: Minor IPSec bug + solution From: Martin Bouzek Reply-To: martin.bouzek@radas-atc.cz To: Herbert Xu Cc: Linux Kernel , davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Radas, s.r.o. Message-Id: <1095413173.2708.106.camel@mabouzek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 17 Sep 2004 11:26:13 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 8983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: martin.bouzek@radas-atc.cz Precedence: bulk X-list: netdev Content-Length: 2370 Lines: 59 On Thu, 2004-09-16 at 23:19, Herbert Xu wrote: > Martin Bouzek wrote: > > > > I was setting up an VPN via IPSec in kernel 2.6.x on IPv4 and found the > > following bug. It is not possible to set up an IPComp/ESP tunnel with > > IPComp set as mandatory. The following setup works fine for me: > > You can never set IPComp as mandatory because ipcomp_output() will not > compress anything that is incompressible. Sure. I receive IP-IP packets and they are checked with the same rules as IPComp. > > > function. For tunnels it returns > > > > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family); > > The check is correct as it is. Internal states must never match any > required transform. Well, I am not expierienced with the networking kernel code, nevertheless I still think the check is not correct. As I understand it, xfrm_state_addr_cmp returns 0 when tmpl->saddr is 0.0.0.0 (ipv4) or when tmpl->saddr.a4 == x->props.saddr.a4, that is why there is the "!" before it. The "xfrm_state_ok" itself returns nonzero if the tmpl matches the state. In such case the "xfrm_policy_ok" will return index to next state in sec_path. If no matching state is found the "xfrm_policy_ok" returns -1 (if not tmpl->optional) and in such case "__xfrm_policy_check" returns 0 and packet is rejected. So the following happens for me when packet is received for mandatory IPComp tunnel: With my setup the pol->xfrm_nr is 1 and sp->len is 1 (in "__xfrm_policy_check" context). "xfrm_policy_ok" is called and it calls the "xfrm_state_ok". x->tunnel_users is 2 - so the "tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family)" is returned. Because tmpl->optional is set to 0 (required IPComp), xfrm_state_addr_cmp is not called at all and "xfrm_state_ok" returns 0. Because sp->x[idx].xvec->props.mode is set, "xfrm_policy_ok" returns -1 (again tmpl->optional is 0). And so "__xfrm_policy_check" returns 0 and packet is droped. If you are still not convinced, please look at the xfrm_state_ok and the part for non-tunnel. It clearly returns 1 when the tmpl and x matches. Moreover with "tmpl->optional || !xfrm_state_addr_cmp(tmpl, x, family);" in "xfrm_state_ok" I can set up the mandatory IPComp without problems. I am not sure there are not any side effects, but it seems ok to me. Regards Martin Bouzek - martin.bouzek@radas-atc.cz From ganesh.venkatesan@intel.com Fri Sep 17 02:54:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:54:20 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9sFld026198 for ; Fri, 17 Sep 2004 02:54:15 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9vsn7023371; Fri, 17 Sep 2004 09:57:54 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9utG4004941; Fri, 17 Sep 2004 09:56:59 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702535921993 ; Fri, 17 Sep 2004 02:53:59 -0700 Date: Fri, 17 Sep 2004 02:53:59 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 1/3 2.5] e100 - Use pci_device_name for syslog messages till registering netdevice Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 757 Lines: 21 diff -up linux-2.5/drivers/net/e100.c linux-2.5/drivers/net/e100.c.new --- linux-2.5/drivers/net/e100.c 2004-09-09 14:51:31.000000000 -0700 +++ linux-2.5/drivers/net/e100.c.new 2004-09-09 14:51:32.000000000 -0700 @@ -2173,6 +2173,7 @@ static int __devinit e100_probe(struct p #ifdef CONFIG_NET_POLL_CONTROLLER netdev->poll_controller = e100_netpoll; #endif + strcpy(netdev->name, pci_name(pdev)); nic = netdev_priv(netdev); nic->netdev = netdev; @@ -2256,6 +2257,7 @@ static int __devinit e100_probe(struct p pci_enable_wake(pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); + strcpy(netdev->name, "eth%d"); if((err = register_netdev(netdev))) { DPRINTK(PROBE, ERR, "Cannot register net device, aborting.\n"); goto err_out_free; From ganesh.venkatesan@intel.com Fri Sep 17 02:53:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:53:42 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9rbJW026094 for ; Fri, 17 Sep 2004 02:53:37 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9tN0S023598; Fri, 17 Sep 2004 09:55:23 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9rwrg029011; Fri, 17 Sep 2004 09:54:10 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702532632054 ; Fri, 17 Sep 2004 02:53:26 -0700 Date: Fri, 17 Sep 2004 02:53:26 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 0/3 2.5] e100 - driver update Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 348 Lines: 10 1 Changed error reporting strategy to use pci_device_name for errors to be logged prior to registering the net device with the kernel. 2 Use NET_IP_ALIGN to set rx data buffer address alignment. NET_IP_ALIGN is defined to be appropriate for the processor architecture for which the driver is compiled. 3 Driver version number update From ganesh.venkatesan@intel.com Fri Sep 17 02:54:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:54:50 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9sjZe026462 for ; Fri, 17 Sep 2004 02:54:45 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9smjP030218; Fri, 17 Sep 2004 09:54:48 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9wCN9004061; Fri, 17 Sep 2004 09:58:28 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702542908069 ; Fri, 17 Sep 2004 02:54:29 -0700 Date: Fri, 17 Sep 2004 02:54:29 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [patch 2/3 2.5] e100 - use NET_IP_ALIGN to set rx data buffer alignment Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 921 Lines: 22 diff -up linux-2.5/drivers/net/e100.c linux-2.5/drivers/net/e100.c.new --- linux-2.5/drivers/net/e100.c 2004-09-09 14:51:31.000000000 -0700 +++ linux-2.5/drivers/net/e100.c.new 2004-09-09 14:51:32.000000000 -0700 @@ -1425,14 +1425,12 @@ static inline void e100_start_receiver(s #define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN) static inline int e100_rx_alloc_skb(struct nic *nic, struct rx *rx) { - unsigned int rx_offset = 2; /* u32 align protocol headers */ - - if(!(rx->skb = dev_alloc_skb(RFD_BUF_LEN + rx_offset))) + if(!(rx->skb = dev_alloc_skb(RFD_BUF_LEN + NET_IP_ALIGN))) return -ENOMEM; /* Align, init, and map the RFD. */ rx->skb->dev = nic->netdev; - skb_reserve(rx->skb, rx_offset); + skb_reserve(rx->skb, NET_IP_ALIGN); memcpy(rx->skb->data, &nic->blank_rfd, sizeof(struct rfd)); rx->dma_addr = pci_map_single(nic->pdev, rx->skb->data, RFD_BUF_LEN, PCI_DMA_BIDIRECTIONAL); From ganesh.venkatesan@intel.com Fri Sep 17 02:55:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:55:14 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9t9hU026644 for ; Fri, 17 Sep 2004 02:55:10 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9vodq013060; Fri, 17 Sep 2004 09:57:50 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9vmUu010103; Fri, 17 Sep 2004 09:57:54 GMT Received: from [10.23.51.23] ([10.23.51.23]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702545316223 ; Fri, 17 Sep 2004 02:54:53 -0700 Date: Fri, 17 Sep 2004 02:54:54 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: netdev@oss.sgi.com, Subject: [patch 3/3 2.5] e100 driver version number update Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 552 Lines: 16 diff -up linux-2.5/drivers/net/e100.c linux-2.5/drivers/net/e100.c.new --- linux-2.5/drivers/net/e100.c 2004-09-09 14:51:31.000000000 -0700 +++ linux-2.5/drivers/net/e100.c.new 2004-09-09 14:51:32.000000000 -0700 @@ -154,8 +154,8 @@ #define DRV_NAME "e100" -#define DRV_EXT "-NAPI" -#define DRV_VERSION "3.0.27-k2"DRV_EXT +#define DRV_EXT "-NAPI" +#define DRV_VERSION "3.1.4"DRV_EXT #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" #define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" #define PFX DRV_NAME ": " From ganesh.venkatesan@intel.com Fri Sep 17 02:55:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:55:31 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9tQWi026830 for ; Fri, 17 Sep 2004 02:55:26 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9vC0S024713; Fri, 17 Sep 2004 09:57:12 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9u0rY030160; Fri, 17 Sep 2004 09:56:00 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702551529853 ; Fri, 17 Sep 2004 02:55:15 -0700 Date: Fri, 17 Sep 2004 02:55:15 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 0/5 2.4] e1000 driver update Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 273 Lines: 7 1) Removed support for advanced TCO features 2) Fix MODULE_PARM, module_param and module_param_array 3) Fix VLAN filter setup errors (while running on PPC) 4) Polarity reversal workaround for 10F/10H links 5) White space changes, driver version number update and others From ganesh.venkatesan@intel.com Fri Sep 17 02:55:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:55:49 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9titC027166 for ; Fri, 17 Sep 2004 02:55:44 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9vU0S024867; Fri, 17 Sep 2004 09:57:30 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9uHrY030264; Fri, 17 Sep 2004 09:56:17 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702553332236 ; Fri, 17 Sep 2004 02:55:33 -0700 Date: Fri, 17 Sep 2004 02:55:33 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 1/5 2.4] e1000 - remove support for advanced TCO features Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1157 Lines: 37 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-09-16 08:09:08.000000000 -0700 @@ -339,7 +339,8 @@ e1000_down(struct e1000_adapter *adapter void e1000_reset(struct e1000_adapter *adapter) { - uint32_t pba, manc; + uint32_t pba; + /* Repartition Pba for greater than 9k mtu * To take effect CTRL.RST is required. */ @@ -382,12 +338,6 @@ e1000_reset(struct e1000_adapter *adapte e1000_reset_adaptive(&adapter->hw); e1000_phy_get_info(&adapter->hw, &adapter->phy_info); - - if(adapter->en_mng_pt) { - manc = E1000_READ_REG(&adapter->hw, MANC); - manc |= (E1000_MANC_ARP_EN | E1000_MANC_EN_MNG2HOST); - E1000_WRITE_REG(&adapter->hw, MANC, manc); - } } /** @@ -523,8 +488,6 @@ e1000_probe(struct pci_dev *pdev, if(pci_using_dac) netdev->features |= NETIF_F_HIGHDMA; - adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw); - /* before reading the EEPROM, reset the controller to * put the device in a known good starting state */ From ganesh.venkatesan@intel.com Fri Sep 17 02:56:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:56:14 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9u7OY027509 for ; Fri, 17 Sep 2004 02:56:08 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9trJB030244; Fri, 17 Sep 2004 09:55:53 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9wqUs010618; Fri, 17 Sep 2004 09:58:52 GMT Received: from [10.23.51.23] ([10.23.51.23]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702555116355 ; Fri, 17 Sep 2004 02:55:51 -0700 Date: Fri, 17 Sep 2004 02:55:51 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 2/5 2.4] e1000 - Fix MODULE_PARM, module_param and module_param_array usage Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 11637 Lines: 343 diff -up linux-2.4/drivers/net/e1000/e1000_param.c linux-2.4/drivers/net/e1000.new/e1000_param.c --- linux-2.4/drivers/net/e1000/e1000_param.c 2004-09-16 23:06:05.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_param.c 2004-09-16 23:06:07.000000000 -0700 @@ -34,10 +34,16 @@ #define E1000_MAX_NIC 32 -#define OPTION_UNSET -1 +#define OPTION_UNSET -1 #define OPTION_DISABLED 0 #define OPTION_ENABLED 1 +/* All parameters are treated the same, as an integer array of values. + * This macro just reduces the need to repeat the same declaration code + * over and over (plus this helps to avoid typo bugs). + */ + +#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET } /* Module Parameters are always initialized to -1, so that the driver * can tell the difference between no user specified value or the * user asking for the default value. @@ -48,17 +54,10 @@ * "Extensions to the C Language Family" of the GCC documentation. */ -#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET } - -/* All parameters are treated the same, as an integer array of values. - * This macro just reduces the need to repeat the same declaration code - * over and over (plus this helps to avoid typo bugs). - */ - -#define E1000_PARAM(X, S) \ -static const int __devinitdata X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ -MODULE_PARM(X, "1-" __MODULE_STRING(E1000_MAX_NIC) "i"); \ -MODULE_PARM_DESC(X, S); +#define E1000_PARAM(X, desc) \ + static const int __devinitdata X[E1000_MAX_NIC+1] = E1000_PARAM_INIT; \ + MODULE_PARM(X, "1-" __MODULE_STRING(E1000_MAX_NIC) "i"); \ + MODULE_PARM_DESC(X, desc); /* Transmit Descriptor Count * @@ -212,7 +211,7 @@ E1000_PARAM(InterruptThrottleRate, "Inte #define MAX_TXABSDELAY 0xFFFF #define MIN_TXABSDELAY 0 -#define DEFAULT_ITR 8000 +#define DEFAULT_ITR 1 #define MAX_ITR 100000 #define MIN_ITR 100 @@ -235,7 +234,7 @@ struct e1000_option { static int __devinit e1000_validate_option(int *value, struct e1000_option *opt, - struct e1000_adapter *adapter) + struct e1000_adapter *adapter) { if(*value == OPTION_UNSET) { *value = opt->def; @@ -256,7 +255,7 @@ e1000_validate_option(int *value, struct case range_option: if(*value >= opt->arg.r.min && *value <= opt->arg.r.max) { DPRINTK(PROBE, INFO, - "%s set to %i\n", opt->name, *value); + "%s set to %i\n", opt->name, *value); return 0; } break; @@ -322,9 +321,10 @@ e1000_check_options(struct e1000_adapter opt.arg.r.max = mac_type < e1000_82544 ? E1000_MAX_TXD : E1000_MAX_82544_TXD; - tx_ring->count = TxDescriptors[bd]; - e1000_validate_option(&tx_ring->count, &opt, adapter); - E1000_ROUNDUP(tx_ring->count, REQ_TX_DESCRIPTOR_MULTIPLE); + tx_ring->count = TxDescriptors[bd]; + e1000_validate_option(&tx_ring->count, &opt, adapter); + E1000_ROUNDUP(tx_ring->count, + REQ_TX_DESCRIPTOR_MULTIPLE); } { /* Receive Descriptor Count */ struct e1000_option opt = { @@ -340,9 +340,10 @@ e1000_check_options(struct e1000_adapter opt.arg.r.max = mac_type < e1000_82544 ? E1000_MAX_RXD : E1000_MAX_82544_RXD; - rx_ring->count = RxDescriptors[bd]; - e1000_validate_option(&rx_ring->count, &opt, adapter); - E1000_ROUNDUP(rx_ring->count, REQ_RX_DESCRIPTOR_MULTIPLE); + rx_ring->count = RxDescriptors[bd]; + e1000_validate_option(&rx_ring->count, &opt, adapter); + E1000_ROUNDUP(rx_ring->count, + REQ_RX_DESCRIPTOR_MULTIPLE); } { /* Checksum Offload Enable/Disable */ struct e1000_option opt = { @@ -352,9 +353,9 @@ e1000_check_options(struct e1000_adapter .def = OPTION_ENABLED }; - int rx_csum = XsumRX[bd]; - e1000_validate_option(&rx_csum, &opt, adapter); - adapter->rx_csum = rx_csum; + int rx_csum = XsumRX[bd]; + e1000_validate_option(&rx_csum, &opt, adapter); + adapter->rx_csum = rx_csum; } { /* Flow Control */ @@ -374,9 +375,9 @@ e1000_check_options(struct e1000_adapter .p = fc_list }} }; - int fc = FlowControl[bd]; - e1000_validate_option(&fc, &opt, adapter); - adapter->hw.fc = adapter->hw.original_fc = fc; + int fc = FlowControl[bd]; + e1000_validate_option(&fc, &opt, adapter); + adapter->hw.fc = adapter->hw.original_fc = fc; } { /* Transmit Interrupt Delay */ struct e1000_option opt = { @@ -388,8 +389,9 @@ e1000_check_options(struct e1000_adapter .max = MAX_TXDELAY }} }; - adapter->tx_int_delay = TxIntDelay[bd]; - e1000_validate_option(&adapter->tx_int_delay, &opt, adapter); + adapter->tx_int_delay = TxIntDelay[bd]; + e1000_validate_option(&adapter->tx_int_delay, &opt, + adapter); } { /* Transmit Absolute Interrupt Delay */ struct e1000_option opt = { @@ -401,8 +403,9 @@ e1000_check_options(struct e1000_adapter .max = MAX_TXABSDELAY }} }; - adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; - e1000_validate_option(&adapter->tx_abs_int_delay, &opt, adapter); + adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; + e1000_validate_option(&adapter->tx_abs_int_delay, &opt, + adapter); } { /* Receive Interrupt Delay */ struct e1000_option opt = { @@ -414,8 +417,9 @@ e1000_check_options(struct e1000_adapter .max = MAX_RXDELAY }} }; - adapter->rx_int_delay = RxIntDelay[bd]; - e1000_validate_option(&adapter->rx_int_delay, &opt, adapter); + adapter->rx_int_delay = RxIntDelay[bd]; + e1000_validate_option(&adapter->rx_int_delay, &opt, + adapter); } { /* Receive Absolute Interrupt Delay */ struct e1000_option opt = { @@ -427,8 +431,9 @@ e1000_check_options(struct e1000_adapter .max = MAX_RXABSDELAY }} }; - adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; - e1000_validate_option(&adapter->rx_abs_int_delay, &opt, adapter); + adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; + e1000_validate_option(&adapter->rx_abs_int_delay, &opt, + adapter); } { /* Interrupt Throttling Rate */ struct e1000_option opt = { @@ -440,22 +445,24 @@ e1000_check_options(struct e1000_adapter .max = MAX_ITR }} }; - adapter->itr = InterruptThrottleRate[bd]; - switch(adapter->itr) { - case -1: - adapter->itr = 1; - break; - case 0: - DPRINTK(PROBE, INFO, "%s turned off\n", opt.name); - break; - case 1: - DPRINTK(PROBE, INFO, - "%s set to dynamic mode\n", opt.name); - break; - default: - e1000_validate_option(&adapter->itr, &opt, adapter); - break; - } + adapter->itr = InterruptThrottleRate[bd]; + switch(adapter->itr) { + case -1: + adapter->itr = 1; + break; + case 0: + DPRINTK(PROBE, INFO, "%s turned off\n", + opt.name); + break; + case 1: + DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", + opt.name); + break; + default: + e1000_validate_option(&adapter->itr, &opt, + adapter); + break; + } } switch(adapter->hw.media_type) { @@ -483,18 +490,20 @@ e1000_check_fiber_options(struct e1000_a { int bd = adapter->bd_number; bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; - if((Speed[bd] != OPTION_UNSET)) { DPRINTK(PROBE, INFO, "Speed not valid for fiber adapters, " "parameter ignored\n"); } + if((Duplex[bd] != OPTION_UNSET)) { DPRINTK(PROBE, INFO, "Duplex not valid for fiber adapters, " "parameter ignored\n"); } + if((AutoNeg[bd] != OPTION_UNSET) && (AutoNeg[bd] != 0x20)) { - DPRINTK(PROBE, INFO, "AutoNeg other than Full/1000 is " - "not valid for fiber adapters, parameter ignored\n"); + DPRINTK(PROBE, INFO, "AutoNeg other than 1000/Full is " + "not valid for fiber adapters, " + "parameter ignored\n"); } } @@ -527,8 +536,8 @@ e1000_check_copper_options(struct e1000_ .p = speed_list }} }; - speed = Speed[bd]; - e1000_validate_option(&speed, &opt, adapter); + speed = Speed[bd]; + e1000_validate_option(&speed, &opt, adapter); } { /* Duplex */ struct e1000_opt_list dplx_list[] = {{ 0, "" }, @@ -544,8 +553,8 @@ e1000_check_copper_options(struct e1000_ .p = dplx_list }} }; - dplx = Duplex[bd]; - e1000_validate_option(&dplx, &opt, adapter); + dplx = Duplex[bd]; + e1000_validate_option(&dplx, &opt, adapter); } if(AutoNeg[bd] != OPTION_UNSET && (speed != 0 || dplx != 0)) { @@ -611,24 +620,24 @@ e1000_check_copper_options(struct e1000_ break; case HALF_DUPLEX: DPRINTK(PROBE, INFO, "Half Duplex specified without Speed\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at Half Duplex only\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "Half Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | ADVERTISE_100_HALF; break; case FULL_DUPLEX: DPRINTK(PROBE, INFO, "Full Duplex specified without Speed\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at Full Duplex only\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_FULL | ADVERTISE_100_FULL | ADVERTISE_1000_FULL; break; case SPEED_10: - DPRINTK(PROBE, INFO, - "10 Mbps Speed specified without Duplex\n"); + DPRINTK(PROBE, INFO, "10 Mbps Speed specified " + "without Duplex\n"); DPRINTK(PROBE, INFO, "Using Autonegotiation at 10 Mbps only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_10_HALF | @@ -647,10 +656,10 @@ e1000_check_copper_options(struct e1000_ adapter->hw.autoneg_advertised = 0; break; case SPEED_100: - DPRINTK(PROBE, INFO, - "100 Mbps Speed specified without Duplex\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at 100 Mbps only\n"); + DPRINTK(PROBE, INFO, "100 Mbps Speed specified " + "without Duplex\n"); + DPRINTK(PROBE, INFO, "Using Autonegotiation at " + "100 Mbps only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_100_HALF | ADVERTISE_100_FULL; @@ -668,10 +677,11 @@ e1000_check_copper_options(struct e1000_ adapter->hw.autoneg_advertised = 0; break; case SPEED_1000: + DPRINTK(PROBE, INFO, "1000 Mbps Speed specified without " + "Duplex\n"); DPRINTK(PROBE, INFO, - "1000 Mbps Speed specified without Duplex\n"); - DPRINTK(PROBE, INFO, - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + "Using Autonegotiation at 1000 Mbps " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -679,7 +689,8 @@ e1000_check_copper_options(struct e1000_ DPRINTK(PROBE, INFO, "Half Duplex is not supported at 1000 Mbps\n"); DPRINTK(PROBE, INFO, - "Using Autonegotiation at 1000 Mbps Full Duplex only\n"); + "Using Autonegotiation at 1000 Mbps " + "Full Duplex only\n"); adapter->hw.autoneg = adapter->fc_autoneg = 1; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -696,8 +707,8 @@ e1000_check_copper_options(struct e1000_ /* Speed, AutoNeg and MDI/MDI-X must all play nice */ if (e1000_validate_mdi_setting(&(adapter->hw)) < 0) { DPRINTK(PROBE, INFO, - "Speed, AutoNeg and MDI-X specifications are " - "incompatible. Setting MDI-X to a compatible value.\n"); + "Speed, AutoNeg and MDI-X specifications are " + "incompatible. Setting MDI-X to a compatible value.\n"); } } From ganesh.venkatesan@intel.com Fri Sep 17 02:56:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:56:27 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9uLut027678 for ; Fri, 17 Sep 2004 02:56:21 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr004.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9wewY011222; Fri, 17 Sep 2004 09:58:40 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9wxG0005880; Fri, 17 Sep 2004 09:59:05 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702560522175 ; Fri, 17 Sep 2004 02:56:05 -0700 Date: Fri, 17 Sep 2004 02:56:05 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 3/5 2.4] e1000 - Fix VLAN filter setup errors (while running on PPC) Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 965 Lines: 27 diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-09-16 08:09:08.000000000 -0700 @@ -2345,8 +2345,8 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & - E1000_RXD_SPC_VLAN_MASK)); + le16_to_cpu(rx_desc->special) & + E1000_RXD_SPC_VLAN_MASK); } else { netif_receive_skb(skb); } @@ -2354,8 +2354,8 @@ if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_rx(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & - E1000_RXD_SPC_VLAN_MASK)); + le16_to_cpu(rx_desc->special) & + E1000_RXD_SPC_VLAN_MASK); } else { netif_rx(skb); } From ganesh.venkatesan@intel.com Fri Sep 17 02:56:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:56:40 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9uXcH027943 for ; Fri, 17 Sep 2004 02:56:33 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9wJ0S025399; Fri, 17 Sep 2004 09:58:19 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9xJG0006045; Fri, 17 Sep 2004 09:59:21 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702562122201 ; Fri, 17 Sep 2004 02:56:22 -0700 Date: Fri, 17 Sep 2004 02:56:22 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 4/5 2.4] e1000 - Polarity reversal workaround for 10F/10H links Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 6187 Lines: 168 diff -up linux-2.4/drivers/net/e1000/e1000_hw.c linux-2.4/drivers/net/e1000.new/e1000_hw.c --- linux-2.4/drivers/net/e1000/e1000_hw.c 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.c 2004-09-16 08:09:08.000000000 -0700 @@ -65,6 +65,7 @@ static void e1000_release_eeprom(struct static void e1000_standby_eeprom(struct e1000_hw *hw); static int32_t e1000_id_led_init(struct e1000_hw * hw); static int32_t e1000_set_vco_speed(struct e1000_hw *hw); +static int32_t e1000_polarity_reversal_workaround(struct e1000_hw *hw); static int32_t e1000_set_phy_mode(struct e1000_hw *hw); /* IGP cable length table */ @@ -1594,6 +1595,15 @@ e1000_phy_force_speed_duplex(struct e100 ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data); if(ret_val) return ret_val; + + if((hw->mac_type == e1000_82544 || hw->mac_type == e1000_82543) && + (!hw->autoneg) && + (hw->forced_speed_duplex == e1000_10_full || + hw->forced_speed_duplex == e1000_10_half)) { + ret_val = e1000_polarity_reversal_workaround(hw); + if(ret_val) + return ret_val; + } } return E1000_SUCCESS; } @@ -1983,6 +1993,7 @@ e1000_check_for_link(struct e1000_hw *hw uint32_t ctrl; uint32_t status; uint32_t rctl; + uint32_t icr; uint32_t signal = 0; int32_t ret_val; uint16_t phy_data; @@ -2032,6 +2043,25 @@ e1000_check_for_link(struct e1000_hw *hw * link-up */ e1000_check_downshift(hw); + /* If we are on 82544 or 82543 silicon and speed/duplex + * are forced to 10H or 10F, then we will implement the polarity + * reversal workaround. We disable interrupts first, and upon + * returning, place the devices interrupt state to its previous + * value except for the link status change interrupt which will + * happen due to the execution of this workaround. + */ + + if((hw->mac_type == e1000_82544 || hw->mac_type == e1000_82543) && + (!hw->autoneg) && + (hw->forced_speed_duplex == e1000_10_full || + hw->forced_speed_duplex == e1000_10_half)) { + E1000_WRITE_REG(hw, IMC, 0xffffffff); + ret_val = e1000_polarity_reversal_workaround(hw); + icr = E1000_READ_REG(hw, ICR); + E1000_WRITE_REG(hw, ICS, (icr & ~E1000_ICS_LSC)); + E1000_WRITE_REG(hw, IMS, IMS_ENABLE_MASK); + } + } else { /* No link detected */ e1000_config_dsp_after_link_change(hw, FALSE); @@ -5216,3 +5231,88 @@ e1000_enable_mng_pass_thru(struct e1000_ return FALSE; } +static int32_t +e1000_polarity_reversal_workaround(struct e1000_hw *hw) +{ + int32_t ret_val; + uint16_t mii_status_reg; + uint16_t i; + + /* Polarity reversal workaround for forced 10F/10H links. */ + + /* Disable the transmitter on the PHY */ + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0019); + if(ret_val) + return ret_val; + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0xFFFF); + if(ret_val) + return ret_val; + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0000); + if(ret_val) + return ret_val; + + /* This loop will early-out if the NO link condition has been met. */ + for(i = PHY_FORCE_TIME; i > 0; i--) { + /* Read the MII Status Register and wait for Link Status bit + * to be clear. + */ + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + if((mii_status_reg & ~MII_SR_LINK_STATUS) == 0) break; + msec_delay_irq(100); + } + + /* Recommended delay time after link has been lost */ + msec_delay_irq(1000); + + /* Now we will re-enable th transmitter on the PHY */ + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0019); + if(ret_val) + return ret_val; + msec_delay_irq(50); + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0xFFF0); + if(ret_val) + return ret_val; + msec_delay_irq(50); + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0xFF00); + if(ret_val) + return ret_val; + msec_delay_irq(50); + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0x0000); + if(ret_val) + return ret_val; + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0000); + if(ret_val) + return ret_val; + + /* This loop will early-out if the link condition has been met. */ + for(i = PHY_FORCE_TIME; i > 0; i--) { + /* Read the MII Status Register and wait for Link Status bit + * to be set. + */ + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + if(mii_status_reg & MII_SR_LINK_STATUS) break; + msec_delay_irq(100); + } + return E1000_SUCCESS; +} + diff -up linux-2.4/drivers/net/e1000/e1000_osdep.h linux-2.4/drivers/net/e1000.new/e1000_osdep.h --- linux-2.4/drivers/net/e1000/e1000_osdep.h 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_osdep.h 2004-09-16 08:09:08.000000000 -0700 @@ -49,6 +49,12 @@ set_current_state(TASK_UNINTERRUPTIBLE); \ schedule_timeout((x * HZ)/1000 + 2); \ } } while(0) +/* Some workarounds require millisecond delays and are run during interrupt + * context. Most notably, when establishing link, the phy may need tweaking + * but cannot process phy register reads/writes faster than millisecond + * intervals...and we establish link due to a "link status change" interrupt. + */ +#define msec_delay_irq(x) mdelay(x) #endif #define PCI_COMMAND_REGISTER PCI_COMMAND From ganesh.venkatesan@intel.com Fri Sep 17 02:56:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:57:02 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9usg1028247 for ; Fri, 17 Sep 2004 02:56:54 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr004.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9xDwY011452; Fri, 17 Sep 2004 09:59:13 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9xUG2006159; Fri, 17 Sep 2004 09:59:38 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702563822229 ; Fri, 17 Sep 2004 02:56:38 -0700 Date: Fri, 17 Sep 2004 02:56:38 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 5/5 2.4] e1000 - white space corrections, driver version number update and others Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 7025 Lines: 240 diff -up linux-2.4/drivers/net/e1000/e1000_hw.c linux-2.4/drivers/net/e1000.new/e1000_hw.c --- linux-2.4/drivers/net/e1000/e1000_hw.c 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.c 2004-09-16 08:09:08.000000000 -0700 @@ -125,6 +125,7 @@ e1000_phy_init_script(struct e1000_hw *h { DEBUGFUNC("e1000_phy_init_script"); + if(hw->phy_init_script) { msec_delay(20); @@ -1391,6 +1392,7 @@ e1000_phy_setup_autoneg(struct e1000_hw DEBUGOUT1("Auto-Neg Advertising %x\n", mii_autoneg_adv_reg); ret_val = e1000_write_phy_reg(hw, PHY_1000T_CTRL, mii_1000t_ctrl_reg); + if(ret_val) return ret_val; @@ -2466,6 +2468,7 @@ e1000_read_phy_reg(struct e1000_hw *hw, DEBUGFUNC("e1000_read_phy_reg"); + if(hw->phy_type == e1000_phy_igp && (reg_addr > MAX_PHY_MULTI_PAGE_REG)) { ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT, @@ -2570,6 +2573,7 @@ e1000_write_phy_reg(struct e1000_hw *hw, DEBUGFUNC("e1000_write_phy_reg"); + if(hw->phy_type == e1000_phy_igp && (reg_addr > MAX_PHY_MULTI_PAGE_REG)) { ret_val = e1000_write_phy_reg_ex(hw, IGP01E1000_PHY_PAGE_SELECT, @@ -3537,6 +3541,7 @@ e1000_read_eeprom(struct e1000_hw *hw, return E1000_SUCCESS; } + /****************************************************************************** * Verifies that the EEPROM has a valid checksum * @@ -3623,6 +3628,7 @@ e1000_write_eeprom(struct e1000_hw *hw, DEBUGFUNC("e1000_write_eeprom"); + /* A check for invalid values: offset too large, too many words, and not * enough words. */ diff -up linux-2.4/drivers/net/e1000/e1000_hw.h linux-2.4/drivers/net/e1000.new/e1000_hw.h --- linux-2.4/drivers/net/e1000/e1000_hw.h 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_hw.h 2004-09-16 08:09:08.000000000 -0700 @@ -36,6 +36,7 @@ #include "e1000_osdep.h" + /* Forward declarations of structures used by the shared code */ struct e1000_hw; struct e1000_hw_stats; diff -up linux-2.4/drivers/net/e1000/e1000_main.c linux-2.4/drivers/net/e1000.new/e1000_main.c --- linux-2.4/drivers/net/e1000/e1000_main.c 2004-09-16 08:09:07.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_main.c 2004-09-16 08:09:08.000000000 -0700 @@ -243,34 +243,6 @@ e1000_exit_module(void) module_exit(e1000_exit_module); -/** - * e1000_irq_enable - Enable default interrupt generation settings - * @adapter: board private structure - **/ - -static inline void -e1000_irq_enable(struct e1000_adapter *adapter) -{ - if(atomic_dec_and_test(&adapter->irq_sem)) { - E1000_WRITE_REG(&adapter->hw, IMS, IMS_ENABLE_MASK); - E1000_WRITE_FLUSH(&adapter->hw); - } -} - -/** - * e1000_irq_disable - Mask off interrupt generation on the NIC - * @adapter: board private structure - **/ - -static inline void -e1000_irq_disable(struct e1000_adapter *adapter) -{ - atomic_inc(&adapter->irq_sem); - E1000_WRITE_REG(&adapter->hw, IMC, ~0); - E1000_WRITE_FLUSH(&adapter->hw); - synchronize_irq(); -} - int e1000_up(struct e1000_adapter *adapter) { @@ -2087,6 +2059,34 @@ e1000_update_stats(struct e1000_adapter } /** + * e1000_irq_disable - Mask off interrupt generation on the NIC + * @adapter: board private structure + **/ + +static inline void +e1000_irq_disable(struct e1000_adapter *adapter) +{ + atomic_inc(&adapter->irq_sem); + E1000_WRITE_REG(&adapter->hw, IMC, ~0); + E1000_WRITE_FLUSH(&adapter->hw); + synchronize_irq(); +} + +/** + * e1000_irq_enable - Enable default interrupt generation settings + * @adapter: board private structure + **/ + +static inline void +e1000_irq_enable(struct e1000_adapter *adapter) +{ + if(likely(atomic_dec_and_test(&adapter->irq_sem))) { + E1000_WRITE_REG(&adapter->hw, IMS, IMS_ENABLE_MASK); + E1000_WRITE_FLUSH(&adapter->hw); + } +} + +/** * e1000_intr - Interrupt Handler * @irq: interrupt number * @data: pointer to a network interface device structure @@ -2230,42 +2230,7 @@ e1000_clean_tx_irq(struct e1000_adapter } /** - * e1000_rx_checksum - Receive Checksum Offload for 82543 - * @adapter: board private structure - * @rx_desc: receive descriptor - * @sk_buff: socket buffer with received data - **/ - -static inline void -e1000_rx_checksum(struct e1000_adapter *adapter, - struct e1000_rx_desc *rx_desc, - struct sk_buff *skb) -{ - /* 82543 or newer only */ - if((adapter->hw.mac_type < e1000_82543) || - /* Ignore Checksum bit is set */ - (rx_desc->status & E1000_RXD_STAT_IXSM) || - /* TCP Checksum has not been calculated */ - (!(rx_desc->status & E1000_RXD_STAT_TCPCS))) { - skb->ip_summed = CHECKSUM_NONE; - return; - } - - /* At this point we know the hardware did the TCP checksum */ - /* now look at the TCP checksum error bit */ - if(rx_desc->errors & E1000_RXD_ERR_TCPE) { - /* let the stack verify checksum errors */ - skb->ip_summed = CHECKSUM_NONE; - adapter->hw_csum_err++; - } else { - /* TCP checksum is good */ - skb->ip_summed = CHECKSUM_UNNECESSARY; - adapter->hw_csum_good++; - } -} - -/** - * e1000_clean_rx_irq - Send received data up the network stack, + * e1000_clean_rx_irq - Send received data up the network stack * @adapter: board private structure **/ @@ -2610,6 +2622,41 @@ e1000_mii_ioctl(struct net_device *netde return E1000_SUCCESS; } +/** + * e1000_rx_checksum - Receive Checksum Offload for 82543 + * @adapter: board private structure + * @rx_desc: receive descriptor + * @sk_buff: socket buffer with received data + **/ + +static inline void +e1000_rx_checksum(struct e1000_adapter *adapter, + struct e1000_rx_desc *rx_desc, + struct sk_buff *skb) +{ + /* 82543 or newer only */ + if(unlikely((adapter->hw.mac_type < e1000_82543) || + /* Ignore Checksum bit is set */ + (rx_desc->status & E1000_RXD_STAT_IXSM) || + /* TCP Checksum has not been calculated */ + (!(rx_desc->status & E1000_RXD_STAT_TCPCS)))) { + skb->ip_summed = CHECKSUM_NONE; + return; + } + + /* At this point we know the hardware did the TCP checksum */ + /* now look at the TCP checksum error bit */ + if(rx_desc->errors & E1000_RXD_ERR_TCPE) { + /* let the stack verify checksum errors */ + skb->ip_summed = CHECKSUM_NONE; + adapter->hw_csum_err++; + } else { + /* TCP checksum is good */ + skb->ip_summed = CHECKSUM_UNNECESSARY; + adapter->hw_csum_good++; + } +} + void e1000_pci_set_mwi(struct e1000_hw *hw) { @@ -2905,12 +2905,12 @@ e1000_resume(struct pci_dev *pdev) * without having to re-enable interrupts. It's not called while * the interrupt routine is executing. */ - -static void e1000_netpoll (struct net_device *dev) +static void +e1000_netpoll (struct net_device *netdev) { - struct e1000_adapter *adapter = dev->priv; + struct e1000_adapter *adapter = netdev->priv; disable_irq(adapter->pdev->irq); - e1000_intr (adapter->pdev->irq, dev, NULL); + e1000_intr(adapter->pdev->irq, netdev, NULL); enable_irq(adapter->pdev->irq); } #endif From ganesh.venkatesan@intel.com Fri Sep 17 02:57:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:57:16 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9vAfL028539 for ; Fri, 17 Sep 2004 02:57:10 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9xpdq014013; Fri, 17 Sep 2004 09:59:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9xbV6011014; Fri, 17 Sep 2004 09:59:54 GMT Received: from [10.23.51.23] ([10.23.51.23]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702565316454 ; Fri, 17 Sep 2004 02:56:53 -0700 Date: Fri, 17 Sep 2004 02:56:54 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 0/8 2.5] e1000 - driver update Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 509 Lines: 13 1) Changed error reporting strategy to use pci_device_name for errors to be logged prior to registering the net device with the kernel. 2) Removed support for advanced TCO features 3) Fix MODULE_PARM, module_param and module_param_array 4) Check value returned by from pci_enable_device 5) Fix VLAN filter setup errors (while running on PPC) 6) Polarity reversal workaround for 10F/10H links 7) Ethtool -- 82545 do not support WoL 8) White space changes, driver version number update and others From ganesh.venkatesan@intel.com Fri Sep 17 02:57:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:57:24 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9vJOM028695 for ; Fri, 17 Sep 2004 02:57:19 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8HA0wn7024873; Fri, 17 Sep 2004 10:00:58 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9vcre030932; Fri, 17 Sep 2004 09:57:47 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702570332406 ; Fri, 17 Sep 2004 02:57:03 -0700 Date: Fri, 17 Sep 2004 02:57:03 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 1/8 2.5] e1000 - use pci_device_name for syslog messages till registering netdevice Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2451 Lines: 78 diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-09-09 11:17:12.000000000 -0700 @@ -53,7 +53,6 @@ #include #include #include -#include #include #include #include @@ -64,7 +63,6 @@ #include #include #include -#include #include #ifdef NETIF_F_TSO #include diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-09 11:17:12.000000000 -0700 @@ -422,11 +422,6 @@ e1000_probe(struct pci_dev *pdev, adapter->hw.back = adapter; adapter->msg_enable = (1 << debug) - 1; - rtnl_lock(); - /* we need to set the name early for the DPRINTK macro */ - if(dev_alloc_name(netdev, netdev->name) < 0) - goto err_free_unlock; - mmio_start = pci_resource_start(pdev, BAR_0); mmio_len = pci_resource_len(pdev, BAR_0); @@ -466,6 +461,7 @@ e1000_probe(struct pci_dev *pdev, #ifdef CONFIG_NET_POLL_CONTROLLER netdev->poll_controller = e1000_netpoll; #endif + strcpy(netdev->name, pci_name(pdev)); netdev->mem_start = mmio_start; netdev->mem_end = mmio_start + mmio_len; @@ -553,7 +543,6 @@ e1000_probe(struct pci_dev *pdev, netif_carrier_off(netdev); netif_stop_queue(netdev); - DPRINTK(PROBE, INFO, "Intel(R) PRO/1000 Network Connection\n"); e1000_check_options(adapter); /* Initial Wake on LAN setting @@ -586,12 +581,13 @@ e1000_probe(struct pci_dev *pdev, /* reset the hardware with the new settings */ e1000_reset(adapter); - /* We're already holding the rtnl lock; call the no-lock version */ - if((err = register_netdevice(netdev))) + strcpy(netdev->name, "eth%d"); + if((err = register_netdev(netdev))) goto err_register; + DPRINTK(PROBE, INFO, "Intel(R) PRO/1000 Network Connection\n"); + cards_found++; - rtnl_unlock(); return 0; err_register: @@ -599,8 +595,6 @@ err_sw_init: err_eeprom: iounmap(adapter->hw.hw_addr); err_ioremap: -err_free_unlock: - rtnl_unlock(); free_netdev(netdev); err_alloc_etherdev: pci_release_regions(pdev); From ganesh.venkatesan@intel.com Fri Sep 17 02:57:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:57:35 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9vTFQ028847 for ; Fri, 17 Sep 2004 02:57:29 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9vWjP031496; Fri, 17 Sep 2004 09:57:32 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9vvra031054; Fri, 17 Sep 2004 09:57:58 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702571330031 ; Fri, 17 Sep 2004 02:57:14 -0700 Date: Fri, 17 Sep 2004 02:57:13 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 2/8 2.5] e1000 - Removed support for advanced TCO features Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8996 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1194 Lines: 37 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-09 11:17:12.000000000 -0700 @@ -311,7 +311,8 @@ e1000_down(struct e1000_adapter *adapter void e1000_reset(struct e1000_adapter *adapter) { - uint32_t pba, manc; + uint32_t pba; + /* Repartition Pba for greater than 9k mtu * To take effect CTRL.RST is required. */ @@ -354,12 +355,6 @@ e1000_reset(struct e1000_adapter *adapte e1000_reset_adaptive(&adapter->hw); e1000_phy_get_info(&adapter->hw, &adapter->phy_info); - - if(adapter->en_mng_pt) { - manc = E1000_READ_REG(&adapter->hw, MANC); - manc |= (E1000_MANC_ARP_EN | E1000_MANC_EN_MNG2HOST); - E1000_WRITE_REG(&adapter->hw, MANC, manc); - } } /** @@ -498,8 +503,6 @@ e1000_probe(struct pci_dev *pdev, /* hard_start_xmit is safe against parallel locking */ netdev->features |= NETIF_F_LLTX; - adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw); - /* before reading the EEPROM, reset the controller to * put the device in a known good starting state */ From ganesh.venkatesan@intel.com Fri Sep 17 02:57:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:58:03 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9vqVY029465 for ; Fri, 17 Sep 2004 02:57:52 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9xc0S026230; Fri, 17 Sep 2004 09:59:38 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8HA1XMv005673; Fri, 17 Sep 2004 10:01:40 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702574108330 ; Fri, 17 Sep 2004 02:57:41 -0700 Date: Fri, 17 Sep 2004 02:57:41 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 4/8 2.5] e1000 Check value returned by from pci_enable_device Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8997 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1238 Lines: 31 diff -up linux-2.5/drivers/net/e1000/e1000_ethtool.c linux-2.5/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.5/drivers/net/e1000/e1000_ethtool.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_ethtool.c 2004-09-09 11:17:12.000000000 -0700 @@ -1017,8 +1017,8 @@ e1000_setup_desc_rings(struct e1000_adap struct e1000_rx_desc *rx_desc = E1000_RX_DESC(*rxdr, i); struct sk_buff *skb; - if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, - GFP_KERNEL))) { + if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, + GFP_KERNEL))) { ret_val = 6; goto err_nomem; } diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-09 11:17:12.000000000 -0700 @@ -2881,9 +2881,9 @@ e1000_resume(struct pci_dev *pdev) { struct net_device *netdev = pci_get_drvdata(pdev); struct e1000_adapter *adapter = netdev->priv; - uint32_t manc; + uint32_t manc, ret; - pci_enable_device(pdev); + ret = pci_enable_device(pdev); pci_set_power_state(pdev, 0); pci_restore_state(pdev, adapter->pci_state); From ganesh.venkatesan@intel.com Fri Sep 17 02:57:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:58:03 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9vpMK029341 for ; Fri, 17 Sep 2004 02:57:51 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9wd1L012370; Fri, 17 Sep 2004 09:58:47 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9wCrY031220; Fri, 17 Sep 2004 09:58:12 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702572830059 ; Fri, 17 Sep 2004 02:57:28 -0700 Date: Fri, 17 Sep 2004 02:57:28 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 3/8 2.5] e1000 - Fix MODULE_PARM, module_param and module_param_array usage Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8997 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 9728 Lines: 312 diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-09-09 11:17:12.000000000 -0700 @@ -71,7 +71,6 @@ #include #include #include -#include #define BAR_0 0 #define BAR_1 1 diff -up linux-2.5/drivers/net/e1000/e1000_param.c linux-2.5/drivers/net/e1000.new/e1000_param.c --- linux-2.5/drivers/net/e1000/e1000_param.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_param.c 2004-09-09 11:17:12.000000000 -0700 @@ -34,10 +34,16 @@ #define E1000_MAX_NIC 32 -#define OPTION_UNSET -1 +#define OPTION_UNSET -1 #define OPTION_DISABLED 0 #define OPTION_ENABLED 1 +/* All parameters are treated the same, as an integer array of values. + * This macro just reduces the need to repeat the same declaration code + * over and over (plus this helps to avoid typo bugs). + */ + +#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET } /* Module Parameters are always initialized to -1, so that the driver * can tell the difference between no user specified value or the * user asking for the default value. @@ -48,17 +49,11 @@ * "Extensions to the C Language Family" of the GCC documentation. */ -#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET } - -/* All parameters are treated the same, as an integer array of values. - * This macro just reduces the need to repeat the same declaration code - * over and over (plus this helps to avoid typo bugs). - */ - -#define E1000_PARAM(X, S) \ -static const int __devinitdata X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ -MODULE_PARM(X, "1-" __MODULE_STRING(E1000_MAX_NIC) "i"); \ -MODULE_PARM_DESC(X, S); +#define E1000_PARAM(X, desc) \ + static int __devinitdata X[E1000_MAX_NIC+1] = E1000_PARAM_INIT; \ + static int num_##X = 0; \ + module_param_array(X, int, num_##X, 0); \ + MODULE_PARM_DESC(X, desc); /* Transmit Descriptor Count * @@ -306,5 +312,9 @@ e1000_check_options(struct e1000_adapter "Warning: no configuration for board #%i\n", bd); DPRINTK(PROBE, NOTICE, "Using defaults for all values\n"); #ifndef module_param_array - bd = E1000_MAX_NIC; #endif } @@ -322,9 +327,14 @@ e1000_check_options(struct e1000_adapter opt.arg.r.max = mac_type < e1000_82544 ? E1000_MAX_TXD : E1000_MAX_82544_TXD; - tx_ring->count = TxDescriptors[bd]; - e1000_validate_option(&tx_ring->count, &opt, adapter); - E1000_ROUNDUP(tx_ring->count, REQ_TX_DESCRIPTOR_MULTIPLE); + if (num_TxDescriptors > bd) { + tx_ring->count = TxDescriptors[bd]; + e1000_validate_option(&tx_ring->count, &opt, adapter); + E1000_ROUNDUP(tx_ring->count, + REQ_TX_DESCRIPTOR_MULTIPLE); + } else { + tx_ring->count = opt.def; + } } { /* Receive Descriptor Count */ struct e1000_option opt = { @@ -340,9 +349,14 @@ e1000_check_options(struct e1000_adapter opt.arg.r.max = mac_type < e1000_82544 ? E1000_MAX_RXD : E1000_MAX_82544_RXD; - rx_ring->count = RxDescriptors[bd]; - e1000_validate_option(&rx_ring->count, &opt, adapter); - E1000_ROUNDUP(rx_ring->count, REQ_RX_DESCRIPTOR_MULTIPLE); + if (num_RxDescriptors > bd) { + rx_ring->count = RxDescriptors[bd]; + e1000_validate_option(&rx_ring->count, &opt, adapter); + E1000_ROUNDUP(rx_ring->count, + REQ_RX_DESCRIPTOR_MULTIPLE); + } else { + rx_ring->count = opt.def; + } } { /* Checksum Offload Enable/Disable */ struct e1000_option opt = { @@ -352,9 +365,13 @@ e1000_check_options(struct e1000_adapter .def = OPTION_ENABLED }; - int rx_csum = XsumRX[bd]; - e1000_validate_option(&rx_csum, &opt, adapter); - adapter->rx_csum = rx_csum; + if (num_XsumRX > bd) { + int rx_csum = XsumRX[bd]; + e1000_validate_option(&rx_csum, &opt, adapter); + adapter->rx_csum = rx_csum; + } else { + adapter->rx_csum = opt.def; + } } { /* Flow Control */ @@ -374,9 +391,13 @@ e1000_check_options(struct e1000_adapter .p = fc_list }} }; - int fc = FlowControl[bd]; - e1000_validate_option(&fc, &opt, adapter); - adapter->hw.fc = adapter->hw.original_fc = fc; + if (num_FlowControl > bd) { + int fc = FlowControl[bd]; + e1000_validate_option(&fc, &opt, adapter); + adapter->hw.fc = adapter->hw.original_fc = fc; + } else { + adapter->hw.fc = opt.def; + } } { /* Transmit Interrupt Delay */ struct e1000_option opt = { @@ -388,8 +409,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_TXDELAY }} }; - adapter->tx_int_delay = TxIntDelay[bd]; - e1000_validate_option(&adapter->tx_int_delay, &opt, adapter); + if (num_TxIntDelay > bd) { + adapter->tx_int_delay = TxIntDelay[bd]; + e1000_validate_option(&adapter->tx_int_delay, &opt, + adapter); + } else { + adapter->tx_int_delay = opt.def; + } } { /* Transmit Absolute Interrupt Delay */ struct e1000_option opt = { @@ -401,8 +426,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_TXABSDELAY }} }; - adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; - e1000_validate_option(&adapter->tx_abs_int_delay, &opt, adapter); + if (num_TxAbsIntDelay > bd) { + adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; + e1000_validate_option(&adapter->tx_abs_int_delay, &opt, + adapter); + } else { + adapter->tx_abs_int_delay = opt.def; + } } { /* Receive Interrupt Delay */ struct e1000_option opt = { @@ -414,8 +443,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_RXDELAY }} }; - adapter->rx_int_delay = RxIntDelay[bd]; - e1000_validate_option(&adapter->rx_int_delay, &opt, adapter); + if (num_RxIntDelay > bd) { + adapter->rx_int_delay = RxIntDelay[bd]; + e1000_validate_option(&adapter->rx_int_delay, &opt, + adapter); + } else { + adapter->rx_int_delay = opt.def; + } } { /* Receive Absolute Interrupt Delay */ struct e1000_option opt = { @@ -427,8 +460,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_RXABSDELAY }} }; - adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; - e1000_validate_option(&adapter->rx_abs_int_delay, &opt, adapter); + if (num_RxAbsIntDelay > bd) { + adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; + e1000_validate_option(&adapter->rx_abs_int_delay, &opt, + adapter); + } else { + adapter->rx_abs_int_delay = opt.def; + } } { /* Interrupt Throttling Rate */ struct e1000_option opt = { @@ -440,20 +477,27 @@ e1000_check_options(struct e1000_adapter .max = MAX_ITR }} }; - adapter->itr = InterruptThrottleRate[bd]; - switch(adapter->itr) { - case -1: + if (num_InterruptThrottleRate > bd) { + adapter->itr = InterruptThrottleRate[bd]; + switch(adapter->itr) { + case -1: + adapter->itr = 1; + break; + case 0: + DPRINTK(PROBE, INFO, "%s turned off\n", + opt.name); + break; + case 1: + DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", + opt.name); + break; + default: + e1000_validate_option(&adapter->itr, &opt, + adapter); + break; + } + } else { adapter->itr = 1; - break; - case 0: - DPRINTK(PROBE, INFO, "%s turned off\n", opt.name); - break; - case 1: - DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", opt.name); - break; - default: - e1000_validate_option(&adapter->itr, &opt, adapter); - break; } } @@ -481,17 +522,19 @@ static void __devinit e1000_check_fiber_options(struct e1000_adapter *adapter) { int bd = adapter->bd_number; - bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; - - if((Speed[bd] != OPTION_UNSET)) { + if(num_Speed > bd) { DPRINTK(PROBE, INFO, "Speed not valid for fiber adapters, " "parameter ignored\n"); } - if((Duplex[bd] != OPTION_UNSET)) { + if(num_Duplex > bd) { DPRINTK(PROBE, INFO, "Duplex not valid for fiber adapters, " "parameter ignored\n"); } - if((AutoNeg[bd] != OPTION_UNSET) && (AutoNeg[bd] != 0x20)) { + if((num_AutoNeg > bd) && (AutoNeg[bd] != 0x20)) { DPRINTK(PROBE, INFO, "AutoNeg other than 1000/Full is " "not valid for fiber adapters, " "parameter ignored\n"); @@ -510,7 +562,7 @@ e1000_check_copper_options(struct e1000_ { int speed, dplx; int bd = adapter->bd_number; - bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; { /* Speed */ struct e1000_opt_list speed_list[] = {{ 0, "" }, @@ -527,8 +581,12 @@ e1000_check_copper_options(struct e1000_ .p = speed_list }} }; - speed = Speed[bd]; - e1000_validate_option(&speed, &opt, adapter); + if (num_Speed > bd) { + speed = Speed[bd]; + e1000_validate_option(&speed, &opt, adapter); + } else { + speed = opt.def; + } } { /* Duplex */ struct e1000_opt_list dplx_list[] = {{ 0, "" }, @@ -544,11 +602,16 @@ e1000_check_copper_options(struct e1000_ .p = dplx_list }} }; - dplx = Duplex[bd]; - e1000_validate_option(&dplx, &opt, adapter); + if (num_Duplex > bd) { + dplx = Duplex[bd]; + e1000_validate_option(&dplx, &opt, adapter); + } else { + dplx = opt.def; + } } + if((num_AutoNeg > bd) && (speed != 0 || dplx != 0)) { - if(AutoNeg[bd] != OPTION_UNSET && (speed != 0 || dplx != 0)) { DPRINTK(PROBE, INFO, "AutoNeg specified along with Speed or Duplex, " "parameter ignored\n"); @@ -605,6 +670,7 @@ e1000_check_copper_options(struct e1000_ switch (speed + dplx) { case 0: adapter->hw.autoneg = adapter->fc_autoneg = 1; + if((num_Speed > bd) && (speed != 0 || dplx != 0)) - if(Speed[bd] != OPTION_UNSET || Duplex[bd] != OPTION_UNSET) DPRINTK(PROBE, INFO, "Speed and duplex autonegotiation enabled\n"); break; From ganesh.venkatesan@intel.com Fri Sep 17 02:58:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:58:14 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9w58I029550 for ; Fri, 17 Sep 2004 02:58:05 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9w8jP031696; Fri, 17 Sep 2004 09:58:08 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9wPra031315; Fri, 17 Sep 2004 09:58:34 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702575032480 ; Fri, 17 Sep 2004 02:57:50 -0700 Date: Fri, 17 Sep 2004 02:57:50 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 5/8 2.5] e1000 - Fix VLAN filter setup errors (while running on PPC) Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8998 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1011 Lines: 27 diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-09 11:17:12.000000000 -0700 @@ -2322,8 +2322,8 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_receive_skb(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & - E1000_RXD_SPC_VLAN_MASK)); + le16_to_cpu(rx_desc->special) & + E1000_RXD_SPC_VLAN_MASK); } else { netif_receive_skb(skb); } @@ -2331,8 +2331,8 @@ e1000_clean_rx_irq(struct e1000_adapter if(unlikely(adapter->vlgrp && (rx_desc->status & E1000_RXD_STAT_VP))) { vlan_hwaccel_rx(skb, adapter->vlgrp, - le16_to_cpu(rx_desc->special & - E1000_RXD_SPC_VLAN_MASK)); + le16_to_cpu(rx_desc->special) & + E1000_RXD_SPC_VLAN_MASK); } else { netif_rx(skb); } From ganesh.venkatesan@intel.com Fri Sep 17 02:58:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:58:27 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9wJ9w029799 for ; Fri, 17 Sep 2004 02:58:20 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9w5JB031336; Fri, 17 Sep 2004 09:58:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8HA0nV2011816; Fri, 17 Sep 2004 10:01:04 GMT Received: from [10.23.51.23] ([10.23.51.23]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702580316630 ; Fri, 17 Sep 2004 02:58:03 -0700 Date: Fri, 17 Sep 2004 02:58:04 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 6/8 2.5] e1000 - Polarity reversal workaround for 10F/10H links Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 8999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 6187 Lines: 168 diff -up linux-2.5/drivers/net/e1000/e1000_hw.c linux-2.5/drivers/net/e1000.new/e1000_hw.c --- linux-2.5/drivers/net/e1000/e1000_hw.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_hw.c 2004-09-09 11:17:12.000000000 -0700 @@ -65,6 +65,7 @@ static void e1000_release_eeprom(struct static void e1000_standby_eeprom(struct e1000_hw *hw); static int32_t e1000_id_led_init(struct e1000_hw * hw); static int32_t e1000_set_vco_speed(struct e1000_hw *hw); +static int32_t e1000_polarity_reversal_workaround(struct e1000_hw *hw); static int32_t e1000_set_phy_mode(struct e1000_hw *hw); /* IGP cable length table */ @@ -1594,6 +1595,15 @@ e1000_phy_force_speed_duplex(struct e100 ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data); if(ret_val) return ret_val; + + if((hw->mac_type == e1000_82544 || hw->mac_type == e1000_82543) && + (!hw->autoneg) && + (hw->forced_speed_duplex == e1000_10_full || + hw->forced_speed_duplex == e1000_10_half)) { + ret_val = e1000_polarity_reversal_workaround(hw); + if(ret_val) + return ret_val; + } } return E1000_SUCCESS; } @@ -1983,6 +1993,7 @@ e1000_check_for_link(struct e1000_hw *hw uint32_t ctrl; uint32_t status; uint32_t rctl; + uint32_t icr; uint32_t signal = 0; int32_t ret_val; uint16_t phy_data; @@ -2032,6 +2043,25 @@ e1000_check_for_link(struct e1000_hw *hw * link-up */ e1000_check_downshift(hw); + /* If we are on 82544 or 82543 silicon and speed/duplex + * are forced to 10H or 10F, then we will implement the polarity + * reversal workaround. We disable interrupts first, and upon + * returning, place the devices interrupt state to its previous + * value except for the link status change interrupt which will + * happen due to the execution of this workaround. + */ + + if((hw->mac_type == e1000_82544 || hw->mac_type == e1000_82543) && + (!hw->autoneg) && + (hw->forced_speed_duplex == e1000_10_full || + hw->forced_speed_duplex == e1000_10_half)) { + E1000_WRITE_REG(hw, IMC, 0xffffffff); + ret_val = e1000_polarity_reversal_workaround(hw); + icr = E1000_READ_REG(hw, ICR); + E1000_WRITE_REG(hw, ICS, (icr & ~E1000_ICS_LSC)); + E1000_WRITE_REG(hw, IMS, IMS_ENABLE_MASK); + } + } else { /* No link detected */ e1000_config_dsp_after_link_change(hw, FALSE); @@ -5216,3 +5246,88 @@ e1000_enable_mng_pass_thru(struct e1000_ return FALSE; } +static int32_t +e1000_polarity_reversal_workaround(struct e1000_hw *hw) +{ + int32_t ret_val; + uint16_t mii_status_reg; + uint16_t i; + + /* Polarity reversal workaround for forced 10F/10H links. */ + + /* Disable the transmitter on the PHY */ + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0019); + if(ret_val) + return ret_val; + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0xFFFF); + if(ret_val) + return ret_val; + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0000); + if(ret_val) + return ret_val; + + /* This loop will early-out if the NO link condition has been met. */ + for(i = PHY_FORCE_TIME; i > 0; i--) { + /* Read the MII Status Register and wait for Link Status bit + * to be clear. + */ + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + if((mii_status_reg & ~MII_SR_LINK_STATUS) == 0) break; + msec_delay_irq(100); + } + + /* Recommended delay time after link has been lost */ + msec_delay_irq(1000); + + /* Now we will re-enable th transmitter on the PHY */ + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0019); + if(ret_val) + return ret_val; + msec_delay_irq(50); + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0xFFF0); + if(ret_val) + return ret_val; + msec_delay_irq(50); + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0xFF00); + if(ret_val) + return ret_val; + msec_delay_irq(50); + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_GEN_CONTROL, 0x0000); + if(ret_val) + return ret_val; + + ret_val = e1000_write_phy_reg(hw, M88E1000_PHY_PAGE_SELECT, 0x0000); + if(ret_val) + return ret_val; + + /* This loop will early-out if the link condition has been met. */ + for(i = PHY_FORCE_TIME; i > 0; i--) { + /* Read the MII Status Register and wait for Link Status bit + * to be set. + */ + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + ret_val = e1000_read_phy_reg(hw, PHY_STATUS, &mii_status_reg); + if(ret_val) + return ret_val; + + if(mii_status_reg & MII_SR_LINK_STATUS) break; + msec_delay_irq(100); + } + return E1000_SUCCESS; +} + diff -up linux-2.5/drivers/net/e1000/e1000_osdep.h linux-2.5/drivers/net/e1000.new/e1000_osdep.h --- linux-2.5/drivers/net/e1000/e1000_osdep.h 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_osdep.h 2004-09-09 11:17:12.000000000 -0700 @@ -49,6 +49,12 @@ set_current_state(TASK_UNINTERRUPTIBLE); \ schedule_timeout((x * HZ)/1000 + 2); \ } } while(0) +/* Some workarounds require millisecond delays and are run during interrupt + * context. Most notably, when establishing link, the phy may need tweaking + * but cannot process phy register reads/writes faster than millisecond + * intervals...and we establish link due to a "link status change" interrupt. + */ +#define msec_delay_irq(x) mdelay(x) #endif #define PCI_COMMAND_REGISTER PCI_COMMAND From ganesh.venkatesan@intel.com Fri Sep 17 02:58:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:58:46 -0700 (PDT) Received: from fmsfmr003.fm.intel.com (fmr10.intel.com [192.55.52.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9wX4Y030156 for ; Fri, 17 Sep 2004 02:58:33 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8H9xS1L012665; Fri, 17 Sep 2004 09:59:28 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8HA13G4007078; Fri, 17 Sep 2004 10:01:16 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702581622391 ; Fri, 17 Sep 2004 02:58:16 -0700 Date: Fri, 17 Sep 2004 02:58:16 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 7/8 2.5] e1000 - Ethtool -- 82545 do not support WoL Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 578 Lines: 14 diff -up linux-2.5/drivers/net/e1000/e1000_ethtool.c linux-2.5/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.5/drivers/net/e1000/e1000_ethtool.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_ethtool.c 2004-09-09 11:17:12.000000000 -0700 @@ -1442,6 +1442,8 @@ e1000_get_wol(struct net_device *netdev, case E1000_DEV_ID_82543GC_COPPER: case E1000_DEV_ID_82544EI_FIBER: case E1000_DEV_ID_82546EB_QUAD_COPPER: + case E1000_DEV_ID_82545EM_FIBER: + case E1000_DEV_ID_82545EM_COPPER: wol->supported = 0; wol->wolopts = 0; return; From ganesh.venkatesan@intel.com Fri Sep 17 02:58:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 02:58:54 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8H9wk9t030426 for ; Fri, 17 Sep 2004 02:58:46 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8HA2On7025409; Fri, 17 Sep 2004 10:02:24 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8H9x9rc031575; Fri, 17 Sep 2004 09:59:13 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091702582932557 ; Fri, 17 Sep 2004 02:58:29 -0700 Date: Fri, 17 Sep 2004 02:58:29 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: ganesh.venkatesan@intel.com, Subject: [patch 8/8 2.5] e1000 - White space changes, driver version number update and others Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2098 Lines: 50 diff -up linux-2.5/drivers/net/e1000/e1000_ethtool.c linux-2.5/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.5/drivers/net/e1000/e1000_ethtool.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_ethtool.c 2004-09-09 11:17:12.000000000 -0700 @@ -637,7 +637,6 @@ err_setup_rx: return err; } - #define REG_PATTERN_TEST(R, M, W) \ { \ uint32_t pat, value; \ diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-09-09 11:17:12.000000000 -0700 @@ -75,6 +75,8 @@ #define BAR_0 0 #define BAR_1 1 #define BAR_5 5 +#define PCI_DMA_64BIT 0xffffffffffffffffULL +#define PCI_DMA_32BIT 0x00000000ffffffffULL #define INTEL_E1000_ETHERNET_DEVICE(device_id) {\ PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)} diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-09 11:17:11.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-09 11:17:12.000000000 -0700 @@ -48,7 +48,7 @@ char e1000_driver_string[] = "Intel(R) P #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.3.19-k2"DRIVERNAPI; +char e1000_driver_version[] = "5.4.11"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table @@ -386,10 +386,10 @@ e1000_probe(struct pci_dev *pdev, if((err = pci_enable_device(pdev))) return err; - if(!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) { + if(!(err = pci_set_dma_mask(pdev, PCI_DMA_64BIT))) { pci_using_dac = 1; } else { - if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) { + if((err = pci_set_dma_mask(pdev, PCI_DMA_32BIT))) { E1000_ERR("No usable DMA configuration, aborting\n"); return err; } From ganesh.venkatesan@intel.com Fri Sep 17 03:05:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 03:05:29 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HA5Nn5032225 for ; Fri, 17 Sep 2004 03:05:23 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8HA84dq017489; Fri, 17 Sep 2004 10:08:04 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8HA80Uu015947; Fri, 17 Sep 2004 10:08:07 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091703050217449 ; Fri, 17 Sep 2004 03:05:02 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 17 Sep 2004 03:05:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH][resend] Update e1000 to use module_param() Date: Fri, 17 Sep 2004 03:05:00 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E028C8E99@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH][resend] Update e1000 to use module_param() Thread-Index: AcScC39eyxL29yW1TRmvRlbR0r4eEQAkghKQ From: "Venkatesan, Ganesh" To: "Roland Dreier" , "cramerj" , "Ronciak, John" Cc: , , X-OriginalArrivalTime: 17 Sep 2004 10:05:02.0202 (UTC) FILETIME=[CC256DA0:01C49C9D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8HA5Nn5032225 X-archive-position: 9002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 2095 Lines: 64 Roland: Thanks for the patch. Based on some feedback from the community we had developed a patch several weeks ago. We just submitted the patch. Please let me know if you see any issues with it. Thanks, Ganesh. -----Original Message----- From: Roland Dreier [mailto:roland@topspin.com] Sent: Thursday, September 16, 2004 9:37 AM To: cramerj; Ronciak, John; Venkatesan, Ganesh Cc: jgarzik@pobox.com; netdev@oss.sgi.com; linux-kernel@vger.kernel.org Subject: [PATCH][resend] Update e1000 to use module_param() (resending because this seems to have been lost; e1000 still has mixed MODULE_PARM and module_param use) The change to e1000_main.c in ChangeSet@1.1722.32.6, 2004-05-27 13:44:06-04:00, ganesh.venkatesan@intel.com [PATCH] e1000 7/7: Support for ethtool msglevel based error added module_param(debug, ...) to e1000_main.c. Since e1000_param.c still uses MODULE_PARM(), this means that one gets e1000: Ignoring new-style parameters in presence of obsolete ones when e1000 is loaded, so the debug parameter cannot even be set. The patch below fixes this by updating e1000_param.c to use module_param() as well. Since module_param might make the parameters visible in sysfs, I removed the __devinitdata notation from the parameter arrays as well, just to be safe. Thanks, Roland Signed-off-by: Roland Dreier Index: linux-2.6.8.1/drivers/net/e1000/e1000_param.c =================================================================== --- linux-2.6.8.1.orig/drivers/net/e1000/e1000_param.c 2004-08-14 03:55:48.000000000 -0700 +++ linux-2.6.8.1/drivers/net/e1000/e1000_param.c 2004-08-15 08:16:31.109671753 -0700 @@ -55,9 +55,11 @@ * over and over (plus this helps to avoid typo bugs). */ +static int param_count; + #define E1000_PARAM(X, S) \ -static const int __devinitdata X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ -MODULE_PARM(X, "1-" __MODULE_STRING(E1000_MAX_NIC) "i"); \ +static int X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ +module_param_array(X, int, param_count, 0); \ MODULE_PARM_DESC(X, S); /* Transmit Descriptor Count From herbert@gondor.apana.org.au Fri Sep 17 03:27:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 03:28:03 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HARr55000335 for ; Fri, 17 Sep 2004 03:27:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8Fxe-0006bk-00; Fri, 17 Sep 2004 20:27:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8FxY-0003nn-00; Fri, 17 Sep 2004 20:27:20 +1000 Date: Fri, 17 Sep 2004 20:27:20 +1000 To: Martin Bouzek Cc: Linux Kernel , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: Minor IPSec bug + solution Message-ID: <20040917102720.GA14579@gondor.apana.org.au> References: <1095413173.2708.106.camel@mabouzek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095413173.2708.106.camel@mabouzek> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 637 Lines: 16 On Fri, Sep 17, 2004 at 11:26:13AM +0200, Martin Bouzek wrote: > > > > function. For tunnels it returns > > > > > > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family); > > Well, I am not expierienced with the networking kernel code, > nevertheless I still think the check is not correct. If you change the && to ||, then an ESP tunnel SA marked as required can be matched by a simple IPIP SA with the same addresses. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Fri Sep 17 04:50:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 04:50:57 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HBooYb005636 for ; Fri, 17 Sep 2004 04:50:50 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 5D97F33CE5; Fri, 17 Sep 2004 20:50:46 +0900 (JST) Date: Fri, 17 Sep 2004 20:50:38 +0900 (JST) Message-Id: <20040917.205038.61628907.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [XFRM] Make XFRM core subsystem af-independent From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 21493 Lines: 646 Hello. Following changesets make XFRM core subsystem af-independent. Please pull following changesets from: . HEADLINES --------- ChangeSet@1.1925, 2004-09-17 20:13:22+09:00, yoshfuji@linux-ipv6.org [IPV4] replace ip_route_output_key() with ip_route_output_flow(). ChangeSet@1.1926, 2004-09-17 20:13:43+09:00, yoshfuji@linux-ipv6.org [XFRM] make xfrm_lookup() fully af-independent. DIFFSTATS --------- include/net/route.h | 5 ++--- net/atm/clip.c | 8 ++++---- net/core/netfilter.c | 4 ++-- net/ipv4/arp.c | 6 +++--- net/ipv4/icmp.c | 6 +++--- net/ipv4/igmp.c | 6 +++--- net/ipv4/ip_gre.c | 10 +++++----- net/ipv4/ip_output.c | 2 +- net/ipv4/ipip.c | 8 ++++---- net/ipv4/ipmr.c | 4 ++-- net/ipv4/ipvs/ip_vs_xmit.c | 6 +++--- net/ipv4/netfilter/ip_fw_compat_masq.c | 2 +- net/ipv4/netfilter/ip_nat_core.c | 2 +- net/ipv4/netfilter/ipt_MASQUERADE.c | 2 +- net/ipv4/netfilter/ipt_REJECT.c | 6 +++--- net/ipv4/route.c | 26 +++++++++++++------------- net/ipv4/syncookies.c | 2 +- net/ipv4/xfrm4_policy.c | 2 +- net/ipv6/sit.c | 4 ++-- net/sctp/protocol.c | 30 ++++++++---------------------- 20 files changed, 63 insertions(+), 78 deletions(-) CHANGESETS ---------- ChangeSet@1.1925, 2004-09-17 20:13:22+09:00, yoshfuji@linux-ipv6.org [IPV4] replace ip_route_output_key() with ip_route_output_flow(). Since ip_route_output_key() is identical to ip_route_output_flow(), except for the lack of the sk and the flags arguments, let's use the later generic one. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/route.h b/include/net/route.h --- a/include/net/route.h 2004-09-17 20:14:58 +09:00 +++ b/include/net/route.h 2004-09-17 20:14:58 +09:00 @@ -115,8 +115,7 @@ u32 src, u8 tos, struct net_device *dev); extern void ip_rt_advice(struct rtable **rp, int advice); extern void rt_cache_flush(int how); -extern int __ip_route_output_key(struct rtable **, const struct flowi *flp); -extern int ip_route_output_key(struct rtable **, struct flowi *flp); +extern int __ip_route_output_flow(struct rtable **, const struct flowi *flp); extern int ip_route_output_flow(struct rtable **rp, struct flowi *flp, struct sock *sk, int flags); extern int ip_route_input(struct sk_buff*, u32 dst, u32 src, u8 tos, struct net_device *devin); extern unsigned short ip_rt_frag_needed(struct iphdr *iph, unsigned short new_mtu); @@ -158,7 +157,7 @@ int err; if (!dst || !src) { - err = __ip_route_output_key(rp, &fl); + err = __ip_route_output_flow(rp, &fl); if (err) return err; fl.fl4_dst = (*rp)->rt_dst; diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c 2004-09-17 20:14:58 +09:00 +++ b/net/atm/clip.c 2004-09-17 20:14:58 +09:00 @@ -556,7 +556,7 @@ unlink_clip_vcc(clip_vcc); return 0; } - error = ip_route_output_key(&rt,&fl); + error = ip_route_output_flow(&rt, &fl, NULL, 0); if (error) return error; neigh = __neigh_lookup(&clip_tbl,&ip,rt->u.dst.dev,1); ip_rt_put(rt); diff -Nru a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c --- a/net/bridge/br_netfilter.c 2004-09-17 20:14:58 +09:00 +++ b/net/bridge/br_netfilter.c 2004-09-17 20:14:58 +09:00 @@ -168,8 +168,8 @@ * Let us now consider the case that ip_route_input() fails: * * After a "echo '0' > /proc/sys/net/ipv4/ip_forward" ip_route_input() - * will fail, while __ip_route_output_key() will return success. The source - * address for __ip_route_output_key() is set to zero, so __ip_route_output_key + * will fail, while __ip_route_output_flow() will return success. The source + * address for __ip_route_output_flow() is set to zero, so __ip_route_output_flow * thinks we're handling a locally generated packet and won't care * if IP forwarding is allowed. We send a warning message to the users's * log telling her to put IP forwarding on. @@ -225,7 +225,7 @@ { .ip4_u = { .daddr = iph->daddr, .saddr = 0 , .tos = RT_TOS(iph->tos)} }, .proto = 0}; - if (!ip_route_output_key(&rt, &fl)) { + if (!ip_route_output_flow(&rt, &fl, NULL, 0)) { /* Bridged-and-DNAT'ed traffic doesn't * require ip_forwarding. */ if (((struct dst_entry *)rt)->dev == dev) { diff -Nru a/net/core/netfilter.c b/net/core/netfilter.c --- a/net/core/netfilter.c 2004-09-17 20:14:58 +09:00 +++ b/net/core/netfilter.c 2004-09-17 20:14:58 +09:00 @@ -631,7 +631,7 @@ fl.nl_u.ip4_u.fwmark = (*pskb)->nfmark; #endif fl.proto = iph->protocol; - if (ip_route_output_key(&rt, &fl) != 0) + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) return -1; /* Drop old route. */ @@ -641,7 +641,7 @@ /* non-local src, find valid iif to satisfy * rp-filter when calling ip_route_input. */ fl.nl_u.ip4_u.daddr = iph->saddr; - if (ip_route_output_key(&rt, &fl) != 0) + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) return -1; odst = (*pskb)->dst; diff -Nru a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/arp.c 2004-09-17 20:14:58 +09:00 @@ -430,7 +430,7 @@ int flag = 0; /*unsigned long now; */ - if (ip_route_output_key(&rt, &fl) < 0) + if (ip_route_output_flow(&rt, &fl, NULL, 0) < 0) return 1; if (rt->u.dst.dev != dev) { NET_INC_STATS_BH(LINUX_MIB_ARPFILTER); @@ -1004,7 +1004,7 @@ struct flowi fl = { .nl_u = { .ip4_u = { .daddr = ip, .tos = RTO_ONLINK } } }; struct rtable * rt; - if ((err = ip_route_output_key(&rt, &fl)) != 0) + if ((err = ip_route_output_flow(&rt, &fl, NULL, 0)) != 0) return err; dev = rt->u.dst.dev; ip_rt_put(rt); @@ -1092,7 +1092,7 @@ struct flowi fl = { .nl_u = { .ip4_u = { .daddr = ip, .tos = RTO_ONLINK } } }; struct rtable * rt; - if ((err = ip_route_output_key(&rt, &fl)) != 0) + if ((err = ip_route_output_flow(&rt, &fl, NULL, 0)) != 0) return err; dev = rt->u.dst.dev; ip_rt_put(rt); diff -Nru a/net/ipv4/icmp.c b/net/ipv4/icmp.c --- a/net/ipv4/icmp.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/icmp.c 2004-09-17 20:14:58 +09:00 @@ -403,7 +403,7 @@ .saddr = rt->rt_spec_dst, .tos = RT_TOS(skb->nh.iph->tos) } }, .proto = IPPROTO_ICMP }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) goto out_unlock; } if (icmpv4_xrlim_allow(rt, icmp_param->data.icmph.type, @@ -521,7 +521,7 @@ .saddr = saddr, .tos = RT_TOS(tos) } }, .proto = IPPROTO_ICMP }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) goto out_unlock; } if (ip_options_echo(&icmp_param.replyopts, skb_in)) @@ -549,7 +549,7 @@ .tos = RT_TOS(tos) } }, .proto = IPPROTO_ICMP }; ip_rt_put(rt); - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) goto out_unlock; } diff -Nru a/net/ipv4/igmp.c b/net/ipv4/igmp.c --- a/net/ipv4/igmp.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/igmp.c 2004-09-17 20:14:58 +09:00 @@ -286,7 +286,7 @@ .nl_u = { .ip4_u = { .daddr = IGMPV3_ALL_MCR } }, .proto = IPPROTO_IGMP }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { kfree_skb(skb); return NULL; } @@ -630,7 +630,7 @@ struct flowi fl = { .oif = dev->ifindex, .nl_u = { .ip4_u = { .daddr = dst } }, .proto = IPPROTO_IGMP }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) return -1; } if (rt->rt_src == 0) { @@ -1317,7 +1317,7 @@ __dev_put(dev); } - if (!dev && !ip_route_output_key(&rt, &fl)) { + if (!dev && !ip_route_output_flow(&rt, &fl, NULL, 0)) { dev = rt->u.dst.dev; ip_rt_put(rt); } diff -Nru a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c --- a/net/ipv4/ip_gre.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/ip_gre.c 2004-09-17 20:14:58 +09:00 @@ -481,7 +481,7 @@ fl.fl4_dst = eiph->saddr; fl.fl4_tos = RT_TOS(eiph->tos); fl.proto = IPPROTO_GRE; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { kfree_skb(skb2); return; } @@ -494,7 +494,7 @@ fl.fl4_dst = eiph->daddr; fl.fl4_src = eiph->saddr; fl.fl4_tos = eiph->tos; - if (ip_route_output_key(&rt, &fl) || + if (ip_route_output_flow(&rt, &fl, NULL, 0) || rt->u.dst.dev->type != ARPHRD_IPGRE) { ip_rt_put(rt); kfree_skb(skb2); @@ -751,7 +751,7 @@ .saddr = tiph->saddr, .tos = RT_TOS(tos) } }, .proto = IPPROTO_GRE }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { tunnel->stat.tx_carrier_errors++; goto tx_error; } @@ -1103,7 +1103,7 @@ .tos = RT_TOS(t->parms.iph.tos) } }, .proto = IPPROTO_GRE }; struct rtable *rt; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) return -EADDRNOTAVAIL; dev = rt->u.dst.dev; ip_rt_put(rt); @@ -1176,7 +1176,7 @@ .tos = RT_TOS(iph->tos) } }, .proto = IPPROTO_GRE }; struct rtable *rt; - if (!ip_route_output_key(&rt, &fl)) { + if (!ip_route_output_flow(&rt, &fl, NULL, 0)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -Nru a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c --- a/net/ipv4/ip_output.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/ip_output.c 2004-09-17 20:14:58 +09:00 @@ -1308,7 +1308,7 @@ { .sport = skb->h.th->dest, .dport = skb->h.th->source } }, .proto = sk->sk_protocol }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) return; } diff -Nru a/net/ipv4/ipip.c b/net/ipv4/ipip.c --- a/net/ipv4/ipip.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/ipip.c 2004-09-17 20:14:58 +09:00 @@ -407,7 +407,7 @@ fl.fl4_daddr = eiph->saddr; fl.fl4_tos = RT_TOS(eiph->tos); fl.proto = IPPROTO_IPIP; - if (ip_route_output_key(&rt, &key)) { + if (ip_route_output_flow(&rt, &key, NULL, 0)) { kfree_skb(skb2); return; } @@ -420,7 +420,7 @@ fl.fl4_daddr = eiph->daddr; fl.fl4_src = eiph->saddr; fl.fl4_tos = eiph->tos; - if (ip_route_output_key(&rt, &fl) || + if (ip_route_output_flow(&rt, &fl, NULL, 0) || rt->u.dst.dev->type != ARPHRD_TUNNEL) { ip_rt_put(rt); kfree_skb(skb2); @@ -556,7 +556,7 @@ .saddr = tiph->saddr, .tos = RT_TOS(tos) } }, .proto = IPPROTO_IPIP }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; } @@ -816,7 +816,7 @@ .tos = RT_TOS(iph->tos) } }, .proto = IPPROTO_IPIP }; struct rtable *rt; - if (!ip_route_output_key(&rt, &fl)) { + if (!ip_route_output_flow(&rt, &fl, NULL, 0)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -Nru a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c --- a/net/ipv4/ipmr.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/ipmr.c 2004-09-17 20:14:58 +09:00 @@ -1156,7 +1156,7 @@ .saddr = vif->local, .tos = RT_TOS(iph->tos) } }, .proto = IPPROTO_IPIP }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) goto out_free; encap = sizeof(struct iphdr); } else { @@ -1165,7 +1165,7 @@ { .daddr = iph->daddr, .tos = RT_TOS(iph->tos) } }, .proto = IPPROTO_IPIP }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) goto out_free; } diff -Nru a/net/ipv4/ipvs/ip_vs_xmit.c b/net/ipv4/ipvs/ip_vs_xmit.c --- a/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/ipvs/ip_vs_xmit.c 2004-09-17 20:14:58 +09:00 @@ -77,7 +77,7 @@ .tos = rtos, } }, }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { spin_unlock(&dest->dst_lock); IP_VS_DBG_RL("ip_route_output error, " "dest: %u.%u.%u.%u\n", @@ -100,7 +100,7 @@ .tos = rtos, } }, }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { IP_VS_DBG_RL("ip_route_output error, dest: " "%u.%u.%u.%u\n", NIPQUAD(cp->daddr)); return NULL; @@ -170,7 +170,7 @@ EnterFunction(10); - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { IP_VS_DBG_RL("ip_vs_bypass_xmit(): ip_route_output error, " "dest: %u.%u.%u.%u\n", NIPQUAD(iph->daddr)); goto tx_error_icmp; diff -Nru a/net/ipv4/netfilter/ip_fw_compat_masq.c b/net/ipv4/netfilter/ip_fw_compat_masq.c --- a/net/ipv4/netfilter/ip_fw_compat_masq.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/netfilter/ip_fw_compat_masq.c 2004-09-17 20:14:58 +09:00 @@ -84,7 +84,7 @@ /* Pass 0 instead of saddr, since it's going to be changed anyway. */ - if (ip_route_output_key(&rt, &fl) != 0) { + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) { DEBUGP("ipnat_rule_masquerade: Can't reroute.\n"); return NF_DROP; } diff -Nru a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c --- a/net/ipv4/netfilter/ip_nat_core.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/netfilter/ip_nat_core.c 2004-09-17 20:14:58 +09:00 @@ -213,7 +213,7 @@ struct rtable *rt; /* FIXME: IPTOS_TOS(iph->tos) --RR */ - if (ip_route_output_key(&rt, &fl) != 0) { + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) { DEBUGP("do_extra_mangle: Can't get route to %u.%u.%u.%u\n", NIPQUAD(var_ip)); return 0; diff -Nru a/net/ipv4/netfilter/ipt_MASQUERADE.c b/net/ipv4/netfilter/ipt_MASQUERADE.c --- a/net/ipv4/netfilter/ipt_MASQUERADE.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/netfilter/ipt_MASQUERADE.c 2004-09-17 20:14:58 +09:00 @@ -106,7 +106,7 @@ .fwmark = (*pskb)->nfmark #endif } } }; - if (ip_route_output_key(&rt, &fl) != 0) { + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) { /* Funky routing can do this. */ if (net_ratelimit()) printk("MASQUERADE:" diff -Nru a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c --- a/net/ipv4/netfilter/ipt_REJECT.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/netfilter/ipt_REJECT.c 2004-09-17 20:14:58 +09:00 @@ -71,13 +71,13 @@ fl.nl_u.ip4_u.saddr = iph->daddr; fl.nl_u.ip4_u.tos = RT_TOS(iph->tos); - if (ip_route_output_key(&rt, &fl) != 0) + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) return NULL; } else { /* non-local src, find valid iif to satisfy * rp-filter when calling ip_route_input. */ fl.nl_u.ip4_u.daddr = iph->daddr; - if (ip_route_output_key(&rt, &fl) != 0) + if (ip_route_output_flow(&rt, &fl, NULL, 0) != 0) return NULL; odst = skb->dst; @@ -300,7 +300,7 @@ { .daddr = skb_in->nh.iph->saddr, .saddr = saddr, .tos = RT_TOS(tos) } } }; - if (ip_route_output_key(&rt, &fl)) + if (ip_route_output_flow(&rt, &fl, NULL, 0)) return; } /* RFC says return as much as we can without exceeding 576 bytes. */ diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/route.c 2004-09-17 20:14:58 +09:00 @@ -2172,7 +2172,7 @@ goto done; } -int __ip_route_output_key(struct rtable **rp, const struct flowi *flp) +int __ip_route_output_flow(struct rtable **rp, const struct flowi *flp) { unsigned hash; struct rtable *rth; @@ -2206,20 +2206,11 @@ return ip_route_output_slow(rp, flp); } -int ip_route_output_key(struct rtable **rp, struct flowi *flp) -{ - int err; - - if ((err = __ip_route_output_key(rp, flp)) != 0) - return err; - return flp->proto ? xfrm_lookup((struct dst_entry**)rp, flp, NULL, 0) : 0; -} - int ip_route_output_flow(struct rtable **rp, struct flowi *flp, struct sock *sk, int flags) { int err; - if ((err = __ip_route_output_key(rp, flp)) != 0) + if ((err = __ip_route_output_flow(rp, flp)) != 0) return err; return flp->proto ? xfrm_lookup((struct dst_entry**)rp, flp, sk, flags) : 0; } @@ -2369,7 +2360,7 @@ if (rta[RTA_OIF - 1]) memcpy(&oif, RTA_DATA(rta[RTA_OIF - 1]), sizeof(int)); fl.oif = oif; - err = ip_route_output_key(&rt, &fl); + err = ip_route_output_flow(&rt, &fl, NULL, 0); } if (err) goto out_free; @@ -2797,4 +2788,4 @@ EXPORT_SYMBOL(__ip_select_ident); EXPORT_SYMBOL(ip_route_input); -EXPORT_SYMBOL(ip_route_output_key); +EXPORT_SYMBOL(ip_route_output_flow); diff -Nru a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c --- a/net/ipv4/syncookies.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/syncookies.c 2004-09-17 20:14:58 +09:00 @@ -184,7 +184,7 @@ .uli_u = { .ports = { .sport = skb->h.th->dest, .dport = skb->h.th->source } } }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { tcp_openreq_free(req); goto out; } diff -Nru a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv4/xfrm4_policy.c 2004-09-17 20:14:58 +09:00 @@ -19,7 +19,7 @@ static int xfrm4_dst_lookup(struct xfrm_dst **dst, struct flowi *fl) { - return __ip_route_output_key((struct rtable**)dst, fl); + return __ip_route_output_flow((struct rtable**)dst, fl); } /* Check that the bundle accepts the flow and its components are diff -Nru a/net/ipv6/sit.c b/net/ipv6/sit.c --- a/net/ipv6/sit.c 2004-09-17 20:14:58 +09:00 +++ b/net/ipv6/sit.c 2004-09-17 20:14:58 +09:00 @@ -481,7 +481,7 @@ .tos = RT_TOS(tos) } }, .oif = tunnel->parms.link, .proto = IPPROTO_IPV6 }; - if (ip_route_output_key(&rt, &fl)) { + if (ip_route_output_flow(&rt, &fl, NULL, 0)) { tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; } @@ -749,7 +749,7 @@ .oif = tunnel->parms.link, .proto = IPPROTO_IPV6 }; struct rtable *rt; - if (!ip_route_output_key(&rt, &fl)) { + if (!ip_route_output_flow(&rt, &fl, NULL, 0)) { tdev = rt->u.dst.dev; ip_rt_put(rt); } diff -Nru a/net/sctp/protocol.c b/net/sctp/protocol.c --- a/net/sctp/protocol.c 2004-09-17 20:14:58 +09:00 +++ b/net/sctp/protocol.c 2004-09-17 20:14:58 +09:00 @@ -455,7 +455,7 @@ __FUNCTION__, NIPQUAD(fl.fl4_dst), NIPQUAD(fl.fl4_src)); - if (!ip_route_output_key(&rt, &fl)) { + if (!ip_route_output_flow(&rt, &fl, NULL, 0)) { dst = &rt->u.dst; } @@ -498,7 +498,7 @@ if (AF_INET == laddr->a.sa.sa_family) { fl.fl4_src = laddr->a.v4.sin_addr.s_addr; - if (!ip_route_output_key(&rt, &fl)) { + if (!ip_route_output_flow(&rt, &fl, NULL, 0)) { dst = &rt->u.dst; goto out_unlock; } ChangeSet@1.1926, 2004-09-17 20:13:43+09:00, yoshfuji@linux-ipv6.org [XFRM] make xfrm_lookup() fully af-independent. This extracts af-dependent portion from xfrm_lookup() and put it into net/ipv4/route.c:ip_route_output_flow(), the user of xfrm_lookup() in IPv4 side. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c 2004-09-17 20:15:01 +09:00 +++ b/net/ipv4/route.c 2004-09-17 20:15:01 +09:00 @@ -2212,7 +2212,16 @@ if ((err = __ip_route_output_flow(rp, flp)) != 0) return err; - return flp->proto ? xfrm_lookup((struct dst_entry**)rp, flp, sk, flags) : 0; + + if (flp->proto) { + if (!flp->fl4_src) + flp->fl4_src = (*rp)->rt_src; + if (!flp->fl4_dst) + flp->fl4_dst = (*rp)->rt_dst; + return xfrm_lookup((struct dst_entry **)rp, flp, sk, flags); + } + + return 0; } static int rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, diff -Nru a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c --- a/net/xfrm/xfrm_policy.c 2004-09-17 20:15:01 +09:00 +++ b/net/xfrm/xfrm_policy.c 2004-09-17 20:15:01 +09:00 @@ -711,25 +711,11 @@ { struct xfrm_policy *policy; struct xfrm_state *xfrm[XFRM_MAX_DEPTH]; - struct rtable *rt = (struct rtable*)*dst_p; - struct dst_entry *dst; + struct dst_entry *dst, *dst_orig = *dst_p; int nx = 0; int err; u32 genid; - u16 family = (*dst_p)->ops->family; - - switch (family) { - case AF_INET: - if (!fl->fl4_src) - fl->fl4_src = rt->rt_src; - if (!fl->fl4_dst) - fl->fl4_dst = rt->rt_dst; - case AF_INET6: - /* Still not clear... */ - default: - /* nothing */; - } - + u16 family = dst_orig->ops->family; restart: genid = atomic_read(&flow_cache_genid); policy = NULL; @@ -738,7 +724,7 @@ if (!policy) { /* To accelerate a bit... */ - if ((rt->u.dst.flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT]) + if ((dst_orig->flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT]) return 0; policy = flow_cache_lookup(fl, family, @@ -813,7 +799,7 @@ return 0; } - dst = &rt->u.dst; + dst = dst_orig; err = xfrm_bundle_create(policy, xfrm, nx, fl, &dst, family); if (unlikely(err)) { @@ -843,12 +829,12 @@ write_unlock_bh(&policy->lock); } *dst_p = dst; - ip_rt_put(rt); + dst_release(dst_orig); xfrm_pol_put(policy); return 0; error: - ip_rt_put(rt); + dst_release(dst_orig); xfrm_pol_put(policy); *dst_p = NULL; return err; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From herbert@gondor.apana.org.au Fri Sep 17 05:41:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 05:41:32 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HCfM9j006663 for ; Fri, 17 Sep 2004 05:41:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8I2s-0007fV-00; Fri, 17 Sep 2004 22:40:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8I2m-0005BS-00; Fri, 17 Sep 2004 22:40:52 +1000 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: [XFRM] Make XFRM core subsystem af-independent Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040917.205038.61628907.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Fri, 17 Sep 2004 22:40:52 +1000 X-archive-position: 9005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1229 Lines: 31 YOSHIFUJI Hideaki / ???? wrote: > > ChangeSet@1.1925, 2004-09-17 20:13:22+09:00, yoshfuji@linux-ipv6.org > [IPV4] replace ip_route_output_key() with ip_route_output_flow(). > > Since ip_route_output_key() is identical to ip_route_output_flow(), > except for the lack of the sk and the flags arguments, > let's use the later generic one. > > Signed-off-by: Hideaki YOSHIFUJI > > diff -Nru a/net/atm/clip.c b/net/atm/clip.c > --- a/net/atm/clip.c 2004-09-17 20:14:58 +09:00 > +++ b/net/atm/clip.c 2004-09-17 20:14:58 +09:00 > @@ -556,7 +556,7 @@ > unlink_clip_vcc(clip_vcc); > return 0; > } > - error = ip_route_output_key(&rt,&fl); > + error = ip_route_output_flow(&rt, &fl, NULL, 0); Yuck. You've bloated the source as well as the binary for the sake of deleting one function. Please provide ip_route_output_key() as an inline wrapper around ip_route_output_flow() so that its users don't have to change. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Sep 17 06:11:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 06:12:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HDBp9H008037 for ; Fri, 17 Sep 2004 06:11:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8IWQ-0007o7-00; Fri, 17 Sep 2004 23:11:30 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8IWM-0005Ey-00; Fri, 17 Sep 2004 23:11:26 +1000 From: Herbert Xu To: yoshfuji@linux-ipv6.org (YOSHIFUJI Hideaki / ????) Subject: Re: [XFRM] Make XFRM core subsystem af-independent Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040917.205038.61628907.yoshfuji@linux-ipv6.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Fri, 17 Sep 2004 23:11:26 +1000 X-archive-position: 9006 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 585 Lines: 17 YOSHIFUJI Hideaki / ???? wrote: > > ChangeSet@1.1926, 2004-09-17 20:13:43+09:00, yoshfuji@linux-ipv6.org > [XFRM] make xfrm_lookup() fully af-independent. > > This extracts af-dependent portion from xfrm_lookup() > and put it into net/ipv4/route.c:ip_route_output_flow(), > the user of xfrm_lookup() in IPv4 side. This one looks great. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From joern@wohnheim.fh-wedel.de Fri Sep 17 06:39:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 06:39:37 -0700 (PDT) Received: from mail.fh-wedel.de (mail.fh-wedel.de [213.39.232.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HDdUKY008688 for ; Fri, 17 Sep 2004 06:39:31 -0700 Received: from wohnheim.fh-wedel.de (wohnheim.fh-wedel.de [213.39.233.138]) by mail.fh-wedel.de (8.12.11/8.12.9/Debian-1) with ESMTP id i8HDc6SM023943; Fri, 17 Sep 2004 15:38:06 +0200 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1C8IwD-000869-00; Fri, 17 Sep 2004 15:38:09 +0200 Date: Fri, 17 Sep 2004 15:38:09 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Lincoln Dale Cc: Alan Cox , Andi Kleen , Jeff Garzik , "David S. Miller" , paul@clubi.ie, netdev@oss.sgi.com, leonid.grossman@s2io.com, Linux Kernel Mailing List Subject: Re: The ultimate TOE design Message-ID: <20040917133809.GD28745@wohnheim.fh-wedel.de> References: <1095275660.20569.0.camel@localhost.localdomain> <4148A90F.80003@pobox.com> <20040915140123.14185ede.davem@davemloft.net> <20040915210818.GA22649@havoc.gtf.org> <20040915141346.5c5e5377.davem@davemloft.net> <5.1.0.14.2.20040916192213.04240008@171.71.163.14> <1095337159.22739.7.camel@localhost.localdomain> <20040916133301.GA15562@wotan.suse.de> <5.1.0.14.2.20040917083305.04f4d008@171.71.163.14> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5.1.0.14.2.20040917083305.04f4d008@171.71.163.14> User-Agent: Mutt/1.3.28i X-archive-position: 9007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: netdev Content-Length: 1161 Lines: 30 On Fri, 17 September 2004 08:37:17 +1000, Lincoln Dale wrote: > > sure -- ok -- that gets you the main processor. > now add to that a Northbridge (perhaps AMD doesnt need that but i'm sure it > still does), Southbridge, DDR-SDRAM, ancilliary chips for doing MAC, PHY, > ... > > couple that with the voltage of PCI where you're likely to need > step-up/step-down circuits (which aren't 100% efficient themselves), you're > still going to get very close to the limit, if not over it. > > ... and after all that, the Geode is really designed to be an embedded > processor. > Jeff was implying using garden-variety processors which seem to have large > heatsinks, not to mention cooling fans, not to mention quite significant > heat generation. > > we're not _quite_ at the stage of being able to take garden-variety > processors and build-your-own-blade-server using PCI _just_ yet. :-) FWIW, I've already been working with complete systems that suck their power from PCI. They do exist, just not in the grocery store next door. Jörn -- Das Aufregende am Schreiben ist es, eine Ordnung zu schaffen, wo vorher keine existiert hat. -- Doris Lessing From yoshfuji@linux-ipv6.org Fri Sep 17 07:11:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 07:11:37 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HEBVVI009690 for ; Fri, 17 Sep 2004 07:11:31 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id CBF0833CE5; Fri, 17 Sep 2004 23:11:27 +0900 (JST) Date: Fri, 17 Sep 2004 23:11:27 +0900 (JST) Message-Id: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040917.205038.61628907.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9008 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 440 Lines: 10 In article (at Fri, 17 Sep 2004 22:40:52 +1000), Herbert Xu says: > Please provide ip_route_output_key() as an inline wrapper around > ip_route_output_flow() so that its users don't have to change. No. Because I've succesfully changed all users (AFAIK), there's no need to keep it. And, I believe the name "ip_route_output_key()" itself was the bug. --yoshfuji From jgarzik@pobox.com Fri Sep 17 07:29:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 07:29:42 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HETZnb010436 for ; Fri, 17 Sep 2004 07:29:36 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8Jjo-0002Kl-RG; Fri, 17 Sep 2004 15:29:24 +0100 Message-ID: <414AF4B4.2090806@pobox.com> Date: Fri, 17 Sep 2004 10:29:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Venkatesan CC: netdev@oss.sgi.com Subject: Re: [patch 1/3 2.5] e100 - Use pci_device_name for syslog messages till registering netdevice References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9009 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 29 Lines: 2 applied 3 patches to 2.6.x. From jmorris@redhat.com Fri Sep 17 07:58:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 07:58:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HEwoP5011606 for ; Fri, 17 Sep 2004 07:58:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8HEwaOH011517; Fri, 17 Sep 2004 10:58:36 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8HEwar17453; Fri, 17 Sep 2004 10:58:36 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8HEwZiS019606; Fri, 17 Sep 2004 10:58:36 -0400 Date: Fri, 17 Sep 2004 10:58:35 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Zilvinas Valinskas cc: netdev@oss.sgi.com Subject: Re: Crypto tests via tcrypt.o modules failes In-Reply-To: <1095358282.3359.83.camel@swoop.gemtek.lt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9010 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 506 Lines: 18 On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > I would say Xscale IXP425 has a rather interesting 32, 16 bits > read/write results if address is not aligned properly. In the same > directory - http://www.gemtek.lt/~zilvinas/crypto/ i've put *.pdf > describing what exactly is happening. I've had a report that all is well on an Xscale PXA (SoC) system, with a 2.6.7-rc2 kernel. Are there any significant differences between that and what you have? - James -- James Morris From jgarzik@pobox.com Fri Sep 17 08:01:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:01:15 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HF19Nn011964 for ; Fri, 17 Sep 2004 08:01:09 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8KEM-0003l1-Kw; Fri, 17 Sep 2004 16:00:58 +0100 Message-ID: <414AFC1E.5010204@pobox.com> Date: Fri, 17 Sep 2004 11:00:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Venkatesan CC: netdev@oss.sgi.com Subject: Re: [patch 8/8 2.5] e1000 - White space changes, driver version number update and others References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9011 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 859 Lines: 27 > @@ -386,10 +386,10 @@ e1000_probe(struct pci_dev *pdev, > if((err = pci_enable_device(pdev))) > return err; > > - if(!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) { > + if(!(err = pci_set_dma_mask(pdev, PCI_DMA_64BIT))) { > pci_using_dac = 1; > } else { > - if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) { > + if((err = pci_set_dma_mask(pdev, PCI_DMA_32BIT))) { > E1000_ERR("No usable DMA configuration, aborting\n"); > return err; > } > > > > Applied patches 1-2 and patches 4-7 to 2.6.x. Patch #8 (quoted above) is rejected because DMA_..BIT_MASK is the preferred method for 2.6.x kernels. The above patch is a regression. Patch #3 is rejected because of an email problem: > bk import -tpatch -CR -ye1000 - Fix MODULE_PARM, module_param and /tmp/patch25004 . > patch: **** malformed patch at line 62: } From alan@lxorguk.ukuu.org.uk Fri Sep 17 08:18:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:18:31 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFIKK5013477 for ; Fri, 17 Sep 2004 08:18:21 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8HEFbNk026130; Fri, 17 Sep 2004 15:15:38 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8HEFaIS026129; Fri, 17 Sep 2004 15:15:36 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: The ultimate TOE design From: Alan Cox To: Eric Mudama Cc: David Stevens , Netdev , leonid.grossman@s2io.com, Linux Kernel Mailing List In-Reply-To: <311601c90409162346184649eb@mail.gmail.com> References: <4148991B.9050200@pobox.com> <311601c90409162346184649eb@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095430526.26088.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 17 Sep 2004 15:15:28 +0100 X-archive-position: 9012 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 718 Lines: 17 On Gwe, 2004-09-17 at 07:46, Eric Mudama wrote: > On Wed, 15 Sep 2004 14:11:04 -0600, David Stevens wrote: > > Why don't we off-load filesystems to disks instead? > > Disks have had file systems on them since close to the beginning... This is essentially the path Lustre is taking. Although it seems you don't want to have a "full" file system on the disk since you lose to much flexibility, instead you want the ability to allocate by handle giving hints about locality and use. People have also tried full file system offload - intel for example prototyped an I2O file system class, and adaptec clearly were trying this out on aacraid development from looking at the public headers. Alan From zilvinas@gemtek.lt Fri Sep 17 08:21:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:21:43 -0700 (PDT) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFLb58017032 for ; Fri, 17 Sep 2004 08:21:38 -0700 Received: from [192.168.3.3] ([192.168.2.249]) by barclay.balt.net (8.12.11/8.12.11/Debian-5) with ESMTP id i8HFKrMj015569; Fri, 17 Sep 2004 18:20:53 +0300 Subject: Re: Crypto tests via tcrypt.o modules failes From: Zilvinas Valinskas Reply-To: zilvinas@gemtek.lt To: James Morris Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Gemtek Baltic Message-Id: <1095434486.32091.2.camel@swoop.gemtek.lt> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 18:21:26 +0300 Content-Transfer-Encoding: 7bit X-archive-position: 9013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev Content-Length: 839 Lines: 21 On Fri, 2004-09-17 at 17:58, James Morris wrote: > On Thu, 16 Sep 2004, Zilvinas Valinskas wrote: > > > I would say Xscale IXP425 has a rather interesting 32, 16 bits > > read/write results if address is not aligned properly. In the same > > directory - http://www.gemtek.lt/~zilvinas/crypto/ i've put *.pdf > > describing what exactly is happening. > > I've had a report that all is well on an Xscale PXA (SoC) system, with a > 2.6.7-rc2 kernel. Are there any significant differences between that and > what you have? 2.4.27 and 2.6.7-rc2 I think quite different - can you tell me which parts to check for differencies ? Here I use 2.4.27 + IPsec patch (from Herbert Xu) + Xscale bits (arch/arm - directory is only patched). I can do a full diff between vanilla 2.4.27 and what I've got if you like and put on web. > > - James From jgarzik@pobox.com Fri Sep 17 08:27:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:27:34 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFRRC7017469 for ; Fri, 17 Sep 2004 08:27:30 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8Kdp-0004Z0-1b; Fri, 17 Sep 2004 16:27:17 +0100 Message-ID: <414B0249.30706@pobox.com> Date: Fri, 17 Sep 2004 11:27:05 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Venkatesan CC: netdev@oss.sgi.com Subject: Re: [patch 1/5 2.4] e1000 - remove support for advanced TCO features References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9014 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 30 Lines: 2 applied patches 1-5 to 2.4.x From jgarzik@pobox.com Fri Sep 17 08:29:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:30:03 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFTv6c017797 for ; Fri, 17 Sep 2004 08:29:58 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8KgE-0004fT-Et; Fri, 17 Sep 2004 16:29:46 +0100 Message-ID: <414B02DE.2020100@pobox.com> Date: Fri, 17 Sep 2004 11:29:34 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 1 2.4.27] pcnet32: discard oversize rx packets References: <20040809231444.GB13717@us.ibm.com> In-Reply-To: <20040809231444.GB13717@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9015 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 30 Lines: 2 applied patches 1-5 to 2.4.x From jdmason@us.ibm.com Fri Sep 17 08:44:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:44:35 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFiKga018360 for ; Fri, 17 Sep 2004 08:44:26 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8HFhRZd098340; Fri, 17 Sep 2004 11:43:27 -0400 Received: from dyn94194162.austin.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8HFhROW177964; Fri, 17 Sep 2004 09:43:27 -0600 From: Jon Mason Organization: IBM To: Francois Romieu Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Date: Fri, 17 Sep 2004 10:43:21 -0500 User-Agent: KMail/1.6.2 Cc: Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> In-Reply-To: <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> X-archive-position: 9016 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2800 Lines: 63 On Thursday 16 September 2004 01:20 pm, Jon Mason wrote: > > Jon, if your ppc64 box offers 64 bits wide PCI slots, it would be nice if > > you could ttry 2.6.9-rc2-bkX, apply > > http://www.fr.zoreil.com/people/francois/misc/r8169-xx0.patch > > and report the content of the "Config2" line in the logs of the kernel. > > Here is the info you requested: > > r8169 Gigabit Ethernet driver 1.6LK loaded > eth8: Identified chip type is 'RTL8169s/8110s'. > eth8: RTL8169 at 0xa0000000800b7000, 00:40:f4:96:fc:3f, IRQ 131 > r8169: eth8: Config2 = 0x01 > r8169: eth8: link up > > My p630 has 64bit PCI-X slots, but my r8169 adapter is a 32bit adapter. > See lspci output below (with a 64bit PCI-X e1000 adapter as a comparison). > ..... > 0001:61:01.1 Ethernet controller: Intel Corp. 82546GB Gigabit Ethernet > Controller (rev 03) > Subsystem: IBM: Unknown device 0289 > Flags: bus master, 66Mhz, medium devsel, latency 144, IRQ 122 > Memory at cc100000 (64-bit, non-prefetchable) [size=cc000000] > Memory at cc040000 (64-bit, non-prefetchable) [size=256K] > I/O ports at 12ec00 [size=64] > Expansion ROM at 00040000 [disabled] > Capabilities: [dc] Power Management version 2 > Capabilities: [e4] Capabilities: [f0] Message Signalled > Interrupts: 64bit+ Queue=0/0 Enable- > ...... > 0002:01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 > Gigabit Ethernet (rev 10) > Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit > Ethernet Flags: bus master, 66Mhz, medium devsel, latency 74, IRQ 131 I/O > ports at 20fc00 [size=e0000000] > Memory at e0020000 (32-bit, non-prefetchable) [size=256] > Expansion ROM at 00020000 [disabled] > Capabilities: [dc] Power Management version 2 > > > I think my AMD64 system at home has a 64bit integrated adapter, as the > performance on it is 2.5x faster (either that or r8169 and ppc don't play > well together). I will verify this when I get home. Well, it appears that my home system only has a 32bit adapter as well (see below). 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Micro-Star International Co., Ltd.: Unknown device 702c Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16 I/O ports at c800 [size=cff20000] Memory at cfffb700 (32-bit, non-prefetchable) [size=256] Expansion ROM at 00020000 [disabled] Capabilities: [dc] Power Management version 2 Before I make any sweeping comments about the performance on ppc64, I should probably do some more tests. I'll have to get back to you regarding that. Would you like me to run the "Config2" patch on my amd64 system? -- Jon Mason jdmason@us.ibm.com From jgarzik@pobox.com Fri Sep 17 08:55:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:55:19 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFtDl3018861 for ; Fri, 17 Sep 2004 08:55:13 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8L4f-0005Ma-LE; Fri, 17 Sep 2004 16:55:01 +0100 Message-ID: <414B08C7.3050505@pobox.com> Date: Fri, 17 Sep 2004 11:54:47 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Schirmer CC: Pekka Pietikainen , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][1/4] b44: Ignore carrier lost errors References: <200408292218.00756.jolt@tuxbox.org> <200408292233.03879.jolt@tuxbox.org> In-Reply-To: <200408292233.03879.jolt@tuxbox.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9017 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 411 Lines: 16 Florian Schirmer wrote: > Hi, > > some (?) hardware seems to be buggy and is reporting bogus carrier lost > values. Both reference implementations from Broadcom indicate that this > counter is not reliable and therefore ignore it. We should do the same. > "Fixes" the carrier lost problem i've seen. > > Regards, > Florian > > Signed-off-by: Florian Schirmer patch applied to 2.6.x From jgarzik@pobox.com Fri Sep 17 08:55:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 08:55:29 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HFtN6Q018894 for ; Fri, 17 Sep 2004 08:55:24 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8L4q-0005N5-Vg; Fri, 17 Sep 2004 16:55:13 +0100 Message-ID: <414B08D5.2020804@pobox.com> Date: Fri, 17 Sep 2004 11:55:01 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Schirmer CC: Pekka Pietikainen , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][2/4] b44: Cleanup SiliconBackplane definitions/functions References: <200408292218.00756.jolt@tuxbox.org> <200408292234.04238.jolt@tuxbox.org> In-Reply-To: <200408292234.04238.jolt@tuxbox.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9018 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 275 Lines: 14 Florian Schirmer wrote: > Hi, > > there is a good amount of code to support SiliconBackplane functions which are unneeded or simply plain wrong. Lets get rid of it. > > Regards, > Florian > > Signed-off-by: Florian Schirmer patch applied to 2.6.x. From jgarzik@pobox.com Fri Sep 17 09:00:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 09:01:04 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HG0xoO019589 for ; Fri, 17 Sep 2004 09:00:59 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8LAG-0005a0-9e; Fri, 17 Sep 2004 17:00:48 +0100 Message-ID: <414B0A24.1000609@pobox.com> Date: Fri, 17 Sep 2004 12:00:36 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Florian Schirmer , pp@ee.oulu.fi, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][1/4] b44: Ignore carrier lost errors References: <200408292218.00756.jolt@tuxbox.org> <200408292233.03879.jolt@tuxbox.org> <41324158.4020709@pobox.com> <200408292304.25447.jolt@tuxbox.org> <20040829164528.220424e5.davem@davemloft.net> In-Reply-To: <20040829164528.220424e5.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9020 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 455 Lines: 18 David S. Miller wrote: > On Sun, 29 Aug 2004 23:04:24 +0200 > Florian Schirmer wrote: > > >>Sorry for that. KMail seems to mangle the message as soon as you sign >>it. Please find the non broken versions attached to this mail. > > > I think Florian's changes are fine. > > BTW, can someone fixup something for me? Update MODULE_AUTHOR() > please :-) 3/4 of this driver have been rewritten since I last > touched it, heh. done. From jgarzik@pobox.com Fri Sep 17 09:00:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 09:00:55 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HG0nI2019557 for ; Fri, 17 Sep 2004 09:00:49 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8LA4-0005Zt-5G; Fri, 17 Sep 2004 17:00:36 +0100 Message-ID: <414B0A18.6020806@pobox.com> Date: Fri, 17 Sep 2004 12:00:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pietikainen CC: Florian Schirmer , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH][1/4] b44: Ignore carrier lost errors References: <200408292218.00756.jolt@tuxbox.org> <200408292233.03879.jolt@tuxbox.org> <41324158.4020709@pobox.com> <200408292304.25447.jolt@tuxbox.org> <20040829164528.220424e5.davem@davemloft.net> <20040829234928.GA10060@havoc.gtf.org> <20040830061020.GA21270@ee.oulu.fi> In-Reply-To: <20040830061020.GA21270@ee.oulu.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9019 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 582 Lines: 18 Pekka Pietikainen wrote: > On Sun, Aug 29, 2004 at 07:49:28PM -0400, Jeff Garzik wrote: > >>>BTW, can someone fixup something for me? Update MODULE_AUTHOR() >>>please :-) 3/4 of this driver have been rewritten since I last >>>touched it, heh. >> >>hehe. I'll take care of it tonight when I queue Florian's stuff >>to netdev-2.6 (and thus -mm, and thus eventually mainline). > > And here's a resend of the bounce buffer patch, which should still > apply on top of Florians (or without) just fine. > > Signed-off-by: Pekka Pietikainen patch applied to 2.6.x. From shemminger@osdl.org Fri Sep 17 09:02:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 09:02:53 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HG2kkP020110 for ; Fri, 17 Sep 2004 09:02:46 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8HG2Iv27175; Fri, 17 Sep 2004 09:02:18 -0700 Date: Fri, 17 Sep 2004 09:02:17 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jes@wildopensource.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] acenic - don't spin in hard_start_xmit when ring fills Message-Id: <20040917090217.43483d10@dell_ss3.pdx.osdl.net> In-Reply-To: <20040916165042.362a3e79.davem@davemloft.net> References: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> <20040916162250.5b7cfa85.davem@davemloft.net> <20040916164206.707204d4@dell_ss3.pdx.osdl.net> <20040916165042.362a3e79.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9021 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 996 Lines: 30 On Thu, 16 Sep 2004 16:50:42 -0700 "David S. Miller" wrote: > On Thu, 16 Sep 2004 16:42:06 -0700 > Stephen Hemminger wrote: > > > NO, the bus just isn't fast enough to keep up with the number of small > > packets I am shoving at it. > > > > You got TX_LOCKED and TX_BUSY confused. The problem is drivers that > > don't check to see if the last packet sent fills the ring and stop > > themselves. > > I understand. > > But that still makes this change buggy. I believe the two choices > are: > > 1) Accept this spinning performance characteristic of the > acenic driver. What if there is buggy, hardware that never drains the ring. It can happen. > 2) Finally give up on acenic's clever lockless scheme and add > the necessary locking + start/stop tx flow control so it > will never have to return TX_BUSY except in absolutely > catastrophic failure cases. I'll code up a non-lockless version and see if makes any real difference. From jgarzik@pobox.com Fri Sep 17 09:03:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 09:03:29 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HG3KB6020418 for ; Fri, 17 Sep 2004 09:03:20 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8LCX-0005f7-6N; Fri, 17 Sep 2004 17:03:09 +0100 Message-ID: <414B0AB1.7070906@pobox.com> Date: Fri, 17 Sep 2004 12:02:57 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Schirmer CC: Pekka Pietikainen , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Andrew Morton Subject: Re: [PATCH][1/4] b44: Ignore carrier lost errors References: <200408292218.00756.jolt@tuxbox.org> <200408292233.03879.jolt@tuxbox.org> <41324158.4020709@pobox.com> <200408292304.25447.jolt@tuxbox.org> In-Reply-To: <200408292304.25447.jolt@tuxbox.org> Content-Type: multipart/mixed; boundary="------------010801080306060802060205" X-archive-position: 9022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 22757 Lines: 332 This is a multi-part message in MIME format. --------------010801080306060802060205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Florian, I was unable to apply your patch #3 (phy-less-mode) and patch #4 (bcm47xx support). Could you please resend these two patches, diff'd against the attached b44 driver (my current version in netdev-2.6)? Please send one patch per email, as per http://linux.yyz.us/patch-format.html, even when resending patches. Jeff --------------010801080306060802060205 Content-Type: application/x-bzip2; name="b44.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="b44.tar.bz2" QlpoOTFBWSZTWf2r2iIAVy3/xf52AgB7/////////v////8AAIAEAAgACGBUvvvhxB9fDrAA Lvoej0ENp64+2+y+53xUezdGI8ddzTR0DQuYfQfQD31qdc2Ptbp6AFAz1j6DvvXE1pvmbVdu z7by+9fHABRffezZtj5Zhrvt9Ppve75X2G9u2M20nbG1Po5Nc503WZdnqPvu+9A73y2e++9j 6LX3PeN1p1yeuPt0V225aMO+5e73uzfe993xx3UBk33d3zPNfT6+pjNtbWN49uvbbuV2a9vr 1vvdT77baKvvm07me7bO4ZAbYnNvHV2t7d7y7XAHevd3g71l9vbe8x3HX3m+EppBAAgBNACY IBNGU8CaGibTU0nk0xTKPJDJoASmggRAjVPCIwhkp5pJ6hjU8p+o0ho9T1Gh5IZAAAAEmkiK IynkCnibSaJ6moP1I9pTTbVHpMgbUGJ6noj1ANAAAEKSICTJkNSaY1T3qo/SnqfpPU0aTSem mGppHiT1NoniT1HoIMTT1MBEoETTRMQiPU2gnqjymo2ZU9T9NG1R6TUye0mk9qh6nppDT1Gh 6TIaBEkIJoAIEmNVP0JtVGTJp6YUeoHqA9T9UAGQMgGgY+0/t+zvmtj/4SmAEsENwhQX7JIL 4vJZHoBwfeN/wzD8n4UoZ7iBRrYhZLJTRFLC2wJnQmFJESQ5Jz04IxrHLUgYASAwhEwEZAaU ROqr9iAfL3YKH/KH8X0/jNCh8988lI00FGQGMkQHRiiiEpahZpgokkmSF/Ct/ikvX7PZQx/2 4s/+ItSwhrGv+HD90Ph7p6V9OHx++vZPhufc/w/BQxmThbhXbd8p/dQ/3VLix+/GMsscKqKI 6Hyyt0a7leY14fHqfPCu22VdRx5tkiX9T/p/b+5/mP+0YkfLylKb8EOIQywRQxFUENEFDQUk yUpSSS0zNNUUJMxARCFKVSRNJFQ8ZwohmEiKYgYhiYlZzMiYSiIqqaoKf0+/8OldmD3FjUwU qxIFX3r7cqRDtpRVgwHzYXEix8NiJ4HwpW0SvO+19vHaKMsYqY+3ZJH7Y6HXDDxH5839S9aP JIOHrcf5sx21TQd0ENAilSvPwVO76w7TsgsvkeYYq7nnTenXOPiy7cHxn4qdYRsU3TJMi7KL 8vZRt7Nr5+Qe2lMRp3sD1yVKVl7wObdlauc97+zJ8aKMF3cfhttYwuvEzw31nNNKjklR5eD5 +zu1ZtOPANosjdclAuuuuuuuruuyhtz9+BpM7upbNxqNvW5afh8hNSOeKJWwpQhUkMmSRaTh BuqCkPZLXkU2BH2oNUUU/XxMEoCJKCokiZmoimGQqpoKQooihiCkiqkooKpmoZCKKKaKYmgI qqloYJSpIqKzFDISSomphlpYJH2ZgNVAP1rKUooaJKZgqqiZSiGJmhCCapkqCoJoGgoJmC1m NURD8uOFE0VIFqcqYpKSWYoKQpIqqZSiQIgmFqkkIIifwWVSBEoUU1vKGQARNMwfNhiUrRVL SBUSUDFSUETffwTAkpPg7e3Z1BsjLAhBLR/R+YP2x937P/QDX6yU9H0TTh+28bUcyb8xAz4B OkyYQfT9sRWTPFZUDsIjeZNhAcZ4ybtHhbQQ4ww0KcTZmSil0zOm17r0NjpCH0oZKUpp2/x3 n2Om7cySGtecLWbEgdg3tlle/L8/QGa2kxEYaa75brRLxZzhNsnkZpgkMvMZVGoKraSy2xal qJukpqrrJQujWtIF1S4MFUVRohy1MKFBg65Lo1rDlCcM8B2x8L5ow7dRFo1+q7NlQMTnQMkz Xt6EARzp1J3zIHFzdJ4h0vlpVgjIiCoqReFaMiLUsRiqItsnCGJlMy0zFMErRWLllCMV3SiI iaQqCxSJCYqYqPROrVkYltmDLvgY0oCJfEG7q6KqSaaowdaxTEMZFBN60ZqiKpPBasi6tqXb FqozbVGNGoc80w6NZjWrHht3nCLpYIKsiyDjVKlWrlMUtrUQRIsgxqLUGsWoKVWsqiiLkUU0 VkuQ88ckihJ1m2ZLJOjq6Q5yJuStIFFNBSLUSPSMqSiJiA5ypktA0BRSJEFLQdIDJpCgaXaP ywB9S6+UKvq2P3qaSv9CTkUHgr9/XOVKuQWCUGZxOnYSwerCG0UJUI5row8B4qc7PMp+aVKn H+n6XdzM/Wf5+yfzf7RPgStHTBecGn26IgzMepSWxJTR64zgDFCYAhCEJJLxr+HjcoTbqxwK UbUx/H5N8r4XcNYzRk9/X7ed4Y9CGGiHZmawgJTQhes6dLRNAJXud5oJr8cM+fMU6aQtIdNr dGYIwXYsM7P1CTChg1AnC4UyVqEiSgoBiCIiCxsRp5iga5EUNHtkct5yVpKCqDedfvmHtPqk qp6Y2+z8/B2AfIgCH6oIDvB+vuUbMBkA5+9WgJc9LFmY7smp6YwS7l5EQ6lNqR0Agu6gXLqf 9voXhKldfp24nz24HWUQoVuxxyVNVAGg0YE+uilbWd9aoSfEeAD4CO3+J+/eby1PCO6eft+j 5yQDyaFODBlT0FUkOKghb7ccoXkCd+uH+KAg1AAZOg9DzCLKkvY6bJyWkQOyKEOH1TcKyiqM 3yL1oBHmX8gMjBOPL/jyonx8aA5BlOL0/fXvQGLv0n739034d0f4+cyfdwpHDq9fXQNumAok BSdsJ2Rvt6tUm8rp0uf8W1vgu9uEpt55/ruZsZPXRnuTyIPpn2Eesg2gpprzfIgxFXe3jPpg QMy9VGzR2Q862FWxyC+r73kr1NH96H7M8uhDrPXPq2+u/SPdeKWcPMXXwpOnVqmf+Y2WqSdY vHjD49y+J9mbU8q8Imcw9XIakbxs0F9ZfOXNt5Nh3n8Sn5Y0SuNmd3bksyjfeePs+30f7R08 uNjbO+0q18+GUi2jz+j7Ndtli1a0+Lyg725sqpXEpXxqynZXJmYpWz8qtQFJsIB0eKLrfTwS /GHWH2PGJs3lEhCQsZ0coMBb1Xm3H4U9RcDNPcvUFv/nuouplR+rHZDTa1TYBc5ZwlBYhixb fJuhh52/5P0i2k3Gso0d6h9FJG1B5jxRg7MYLH9y31fVq4tOU3aCBCQgvr49+3pOn4P6sUre fNj1+6ZqVSXjiU9dF2Rb2JL0LTv6Ggn5iLqvvYfe+1p4Y1G9x8xKhLdOcKdmZi8209Y1GbO2 VV32movY0+JVn+DeYvs5vdZYpjimvrZsEhM1V1KpipOOR+azdxyIBp16vdD4JJmNy9iIQZhv HXjI8ZqpCgJdgtR+D9GbnTl/L8jDnMxIgvqMtBhMbvnOeRxydZlfYK9dEYQvs6O89VpaVfGv r+vRIund8xgosfkrri4viUqBKDLbn1YB/lzt5XX7ZjU3ftXlTEBvVrr93SbhzwHk0kQuZmSO L2Ff1jehJ3NlqfwMcuMblGPxNW+2YYvBD4j3x63rtUuzfUPJc9r5Dgmc9Fnvn1/k5wYIdNst uGfHEX7d7c4pjrNtiypm0bLNklun4bNzFy04xRnY2JbqW5HAuL7Br8LyqFzWiE2hWJrXcSVo w2YoqkntZwe/Jyj2zwiYlCHwe2dTFk6S4zV0reqNWBRaNnjtoq9LrPUcNkp9UrcqOVBmTfbF +w8XWJCQk3kkoH8iESCPHM9xIwM+P+Ht95HZ7TjOPr3oOgPlkVU6lWhQVFFiqLFfmngKYCkZ 2TZaduZhbmGZS222W0KWlttspaszDMlLpQWNRcLKKaKKovosIkqB2JIkrdPu3o2qiixSRFgI hoYCNU5VVTSiVS8E+mzlXeYiA7S1/NwjycyxY28TsB/yTZ2XZisRGZBlbNYPgpRftQZSWD3o OqFGEXNePh+Hy8vZlTJsArIDjmhZxJbVDRBJDfdGqhk7gIeW3cJ5XlgobYsKwmsOm97DM9y5 k9/6skj88fn3YI2H02X3m4mUQ3j6CY5r8z4NwPSy38J1QGDY2AOUIhAW9OvM1EvI3n09fTfP oV2uFc9MMacqmY7KTw9x/BcLA24eaJ4muPjjhHmZ91Muojtu8uYjSlGyYrMbUQsTUI8ewyhJ C31BwZrlPYyfNjVr5m4OV5SixBM3C7jiXTErZ0rr90tEJ6uN6ZOlXM2T071tsWA6agqSOPWE IViNSKqdWqJC/ajSgusnkdMpIQj5CIiJInbcAc5GBGb1FgmctnserFntQk7RtDXr+jvke9sK Z6ZNfWW7/izPxEUzZmTMPRiYulbGgVkHDiaRKj0cfFCPjWHFg2TIPD8Ezt+bfk2H9UO6GK68 ms1xukZ95vkxBaVrTQE+dwgoxcg8XsYjI6cqJdAu7MlUQOHoVuEeRsw+06EbxjouZ2kn8sIx YNFlHRzOJAlGlEUzJJdYuM5NZlcWO+fQOJCQHDs8Hijsm7qo4noLHY6wzskMZhA0U0EQHV3E KXmDsrKbjgnDJmsgKTQLAVz5cIYIXud5HHwPSbXYmgSEmNY7WEEUbQN1CdIJJ08HYFmn2qvJ M9Avp6qiLaZuTQ72wuBQX58nKTJyaa3KlmID8M3Pqi5lK2A2pHAzVeynKVpcgzpOTg68Pn8c bd4jFcZRC7r43nPfwxsiPw2Oe3J+SJk27RX7XGx2j3JVNBP4dyuBamBgzu6QqHSdfJHVHeZs 323FcSlBG0vS5ltarjmFFg1KNbWq1qj05mVRr12ke95OTb0F35KXCVZRTXYd4s+/wvUmqoPC osYHWy44HcXBAzRJQdxcQ5QdjRIGl2Z2RJwYzWZZ3W1/NfqJRyh8f19no2+OUpSlLzVIXFug rVYb1NiHXI1cdMond0n3UJNy7hzjoNgoeuXlrphhRvgwRpQ8ro8TNjml3HS647SssIkFTuXE IaxMcO/zt6edY4VzYptb0t4h9xlg+t6tDN2vj+GDN+jDddVVJnOHQa1U1GAgSENewX9cs9uy lopiFuhztjnsuOqGCacKIMYZOPDXkPO+y336+S+J11XoXAPFbH+hCyDCmu9CSEkyGz843Kqo G6MRtMstDiofAPSttkcIQnVgSzims4tFW1qkMzJ0zDns2fZaX7C52aRZlBsbbM0YEx9m5Bng 57BZ4Os3Ra8MZVQv6ck38OnSxY4Z5XTWezn5XwYxMijyRv4LeKXPHFkGdsGorOCRhzZqKTDC afZ9fVG27EhlWMB7rGYa66ZM9FEyWxFlBI12xJVbTh0eXqprqoTwdLfVYvBdCPFKKZqCi5R0 he8DZbmk8qchmldZTowMbeG5VdSa9gQGMnZO57mXWjm0+mkpwXZp16tFsI8NRdVrhUp4uk7z w+eUeYDZWxgO8h24cvfb653eqJwrdYZT4NsemsY4ip99JZQFiSkBMRCAkkkCEa4128Es15d3 qfDsHOOka/U2Qj74DRCrPNoe+VeREqjijDbfpmUWFBc+cUFpdFPzrXrkVN2pk6H3wnhj3Q/n jo0Z5EKaaixXZiYoUVnlEeXW6rOu7E7NVbfBarSRG/dn4+s5zx7z6T8J8x0t6+r9I/jN80Hv +3NbfN9w17z2xVNV7LJpr0QxBcp0gs8YH7YbxPL4Yf79PITsCFfxhmOsuCZkjdTZCnlnWjCa GSDpQzDotvgLAfhVFuHHZVs89icaLI/6zzlO/ltbG5nj6hrJkhIBCZIGZJkgQgrFvjLKmZ7G PkvAVMz/1+S1Go9jxn/D9ygp+fB6yP1v8P1oLoy+ksqIYNiJrKGzdA+2G/4CSSE4zSROJgSv On2fq7j7Qf1wCR/Qe/9qwU8PaVkRqJy+b5oQWOPgHozr9CYN1zYOgupMv9KJhNDd6D63+4gs 7JKiewbVkh/2QFT/WAP89fp+9mVVKfVMJCQpVColA5khKhKQyQhH4IO300PN0Pqrf10FPo+a fB7/V7n61CQA2nfi24UqTabTOXMMhB6jMUU9HZxfZZU2oB0qO9EP/iBRcSZCEn5/OQMEBgmm smGEFgfPOVXteZgKKGL0xkvN+kNEUsl+jvmaPX0ooPehwSYTCfuwxwa3y5b14atldb19u7+n p8HwecNskWAiEihmkAKRGQKAwytriYrgvauErv9v4k7vj38qph5OT4WBVZaU99HFs3PeneCn 4kIMg4zThQRl+8B1B3zO6tduNFqYHQcmcemimJs6vuPvXvnE+XEMloSr8H93TkfwE9k+R20A 4xypmPmi7YCONNNBC/ga/CQHbDTzO32nQocwrOZ4k1UcQmMUYP1lgRNR3GPORImhbL78eSml rEctFkpccunXm3jb1WtGHqU9UcHjG568T4sz91aqRKYdHTCRjQYqLSrJNUjUBBwoQa9ztVMv pjz9vfXp/mc8Du6ZR9aXvj7fpqnNKT0EXLnDpjRS8/l9sPDuKvNQd+ae9KDbpslwtUfn/b8Z bKW+xWLv2GaiXjJ/vj+P18EvX8/bVxY6IUaa+dulDJci5OxxTjxTXjD76HIToF34tGl5NxvF UQRBN4FBeFcKLVgBryMzfy38TcX485L45juwxgc5+/mD5eLf7+jWfuMuHDo0/m+0h0Hia1d8 DzOcZ4bPB83H80baDlIDnX0YkGhU9keTkz9466H0Fc43OcqIWH0xzRIrhnZmZvHKg61VZaZu zTppbSUuktOD2vRSUZp2u9dXFX7bbqNV2jHPcoo7d38bpKVJB9MZrDrLIYUZt08dMG26QObo r5eXv1Y2GFUSyn5R9cOErqrXvcK6J79fldOoa1lFUNVdwNUguxpq31YTd8E23j262udGud/B ptoro7cc3rcod3AXpfelTw2oPLbQ/NSMkW0W/wFpLO/ZwvGN1me3BY5rOuV21IoqRqWNdvfu vhmXNBfw8tvooKaQ0Q6q24tXeo1+/hozKnRRDXveAoPwXuVJtyNDC06ebrnpw1Z4W8uOamOX LTDXRe74w4dNEqumunfHCZbJ1sw5Xim2JSdoIPLfdKmvdyYxlq02FcTXofik5n1vxRH0q6FW eKd9ipj/rPrg96qWUKGwqH1lLQF0W5oPXK9ePfLmV1MQeTVRwe18Cm3NxXT3EuIqreqHXOim lsceX1t+kmCgpEpUoEaQKBQiQAoQggGKoghoJhJgAE/dFezsKKj2RX9EFCQEkQhGQMUKVEL/ CQkSJD3nr75Y1kbL531/W+I1+981wPs1uUm+qLOI6CXEpP0SNoW1Ln44vBOHcuOS5/Ycvgz6 d1imQ/o3BqU555mTxHyI6s/dpChqb/FQSr3eiEWkeMamwidEC9RiU8O0+qUoP7LYdtXgaDWG gHYr8Zdn8b+H+2/egPvATdBGc69efXtvrJt6Fwu+pHQHL4Tw3nadJGrUX69smsNltOqkf7e2 4zrPrsidL67y7jopwZZpwhDqepsMb/D8JQzWVY0r/mw19Zd2dj013Qs0EWiHFVn0VKnu00tZ WOxATt3P4FwScwe2lRYtqFAwTc/983uiN5u81TZk1dw7Ge64qmnEF1110WnY5ZV9QjjuioBR D38/Wdvt9cNL+tcfZzyNWjGPQ/TZmhwMcrW732m/52GPxNrt9qazytrkpvjPdrnhwaqURtFS IRLUvkFLKsn00gjIFGHFCg4GBhJDRosghxA1igayjadLsQNMvxUTikHMuKimMgM9ezADkEtL IW6wIM90rOCEFBCBQ6i5ASBpkGrctYCGXf7N31+er434ePLrzPHgjmqzyxiSlFyNLmQqiuHN 9su8r4EiHz2BHcGYRYccQ4J1Vap4MFvb9s83j6TpshhwpvuXtGo8i667OCVGF9HtONHvd/rE ylX8+yh2Zn0SSSB8cf5zjLaP1UrBEMszKyRQAUCYwqLKwqZLlEgtVFQpkhSkyGZYYwBpRQGV Wo/XgGR880fP1nn7k8PjKfhE14mHVJUwAN7vN6v/Xt5qGo4vD9CgfxTEl1p6EPRR3ZM3S376 nTozM18GwzKU5pDfFOvpopuP/DfwBoxknKSqgv7+UjrRikRh/X/QGezhxAB/PHZ5u2tbms1F mPngdGzMhYgA0lS50iFTjljiTak9RJBBBQ4h7POIJvyrE/b4MMgTDPlXRMjW1NZJvCmzAXTM PxvhFc5HozbvgCQ2MO+Ag86sMIxcthoaKIilQayBp1u99ko7UnDkhh+Igw2OhuaA2SJdgMIJ DCSAEPeb/8VY7hDoASZhpHZxCZF73q9NB4ZHCE/ZL2wrsPLlzTjtFVURUUSSSSSSSQiJiHd3 d7c5j80fRz7vevnGdcdbW4BH7Hs5r77+n+PRr5QznFPhMXtVQD/rJ2BNADph0uH79HJ0dHRa VfsK2wgw1p8FMiDVoIIEyVvLax8zG1rg/53d1xk+6g+ANmBxHa1xy+IGD4tFgciciIhgyBq/ D8HqzZQOEwwwQg4XBRC2RRRHRf6WcEHa30FqiZVVVT0Ib+StJznH/PlxOfk5+dPe2vvDG7Zy QbQcJyGjKRAYg7NFAzQiit4B7UaWJJX1/vfD3TbdxCDyNCk9fWvWE7BnQgxOHji8IdZsTilC 8DyREN5y9EWKIw1wWuTYjatage+Ou1tVacdGGGYiGYybNDNm9YPKPmhF9T98/IMwxNFEQRER VUMQTVUstFSVjpDbySOXpqhx3Nhs1mGEzwBoi5PGJpJgMEnYHcgPNZrJ01C3SkOwqPcKrqkq kNuzmqh70Ln0gIfWDk/4J+akyNMhREyQUfjxvz6bqtaaV5VVVl5bebuV18HVjTZppx26bg6i yIpsICokIK57Gr4U5yMRtYCl4kiO4ccIYKTNRoHNJxJrIHCUFnHBkm2NB3Wy2yumOMPAhlvR YNGdm94gf+5DhWSLZDessy48fIHJ1gc7iX8hgVa73yffLEcB5EBUVjVG8sYc8yJMVvmvCLqD 11wg7qbu+EMI6zVs3bpzqrr02V6qMEGEviir9pwhDpgQglTmPX0TwgdMbrf4r1TPTWBBvS7s edD+BJ/1gS+P3rBBWg+9CR500EXYuDQXmQwmk7ciD8PC566/ygH+q8qSPxtnChHDWt4nUI35 QKV/orFkmEI1rwpm2pvwP55QbRnrhahKlAS/m7flzJxi1DG65hwf6caPHIPbU/Qn5+SDBvRq R4035wcN/ETNK4tn6UZI417tZZLg1baIQw/OryLhoLPjmOeJp0EIBcrUkA7cWrUlRKpUouUl ZJxjlscKk3NufhWNg9OEo6pHInZWpvtudAkyNGZOPudnQ35RgdMcNW2A0C12L752iolBLtxb RHCc/x8mjVFXJ6S7zEI8UKYsO7hPHJ2HhnINxe70QK90H9iLoifd+V++vFHpfhmKmpy553P0 QM6Ep75qTi0zhSijZfd1eq6g02ai6MN7tyLwI0oDshZwxMUBxwcNHe0ThhJjP2OOqUYLWLQj FVKut+5bFamtSEdb6MopYpuZXqakg3oLr92+LZJVT5cZBzotRQg2IPKm9CKFCXDZ4ITFLY10 Mawd89vj4ZNGP0uzn19WjT7m9iI1VT8bzlerMA7OBbPsM3mlx9NqidWUzezWnw2O37O22+Hb Hlrs79jJtfL0H2+junDK9Q74fh9frPkJGEJGAx8UBX9zI+xthgyfrIBqf2h/Kha0yIyG0rJi Vn335qGug1wAphZSAmCCMosfxa5MlhlimzmaM0a2kqCpql/ZGNXSVDMgXgSH3TOImIfpgloA msxFDET6yAbSJuIGSu/xdFlDWNvSrQAyRAAhPseuyf4Ant+r7h+QT6PYBKP5afg7VHRn3if9 DD6Gg1Jk0Rg7Cn6Pxmxy5bivyBwn5HrpSq5pU/u/DyAaiBqbEfOZnpVB/OHynzfOc9pE0T7Q SiUXSwdxNCg0EdLptSDUNpAyqnAZgqcTU3pUAMLBRvkpkJcQ7qCYSVIZkVsAEUXlqCuQHv0a UyB3Lm0BF4UNBmhBbMPO4UESOaj+SZy/0/M8aVJCKpGpU7gfg6pszFOaAL/tA/VN+rAyTkQm 0BTQUlLoto1bBBk+ZldSAEMKBNEDzOveeZOCNieIGTHrnzt8aPYNfUigaOTu8RCRUoDhc5yo loExZTSw5ojEHB0q8D9hEogGBNhgLl/jnvB8RXPt58tO2OtXWE7xG2MpzhRmZ94EL1uTkBFM 6KqhOvdkkIbaXPFAts5I6TroUYsrc6k14iLw1IvMYB3jDPTfj4dXJPIEmkHtmBXAYmtlK1He afPdgBLVC20xLMZJRCYJKrIZGGLDiGSTJhCZoJoCDVvX4v6aT89WMZz9FO3+nNXcbl6cTtCA xIUlASI8r59axVry3c+KQVLnlUi+HuIJQ9x6Xk8jkWHFZ9VRQ3h2KwhyikEwT1ybo/Dr0q6M 5z30EwYaOgfP6UlR3X0YljEA2bwkjC4dOzmcwKDCKYD1Gzy1Ckwkt0nFlfAOxNJoYZWCwImj 8/HXnjgTseBK1O0As2MuohSOMBfeCOgPIelaDeFmkMkBrhOReuO/r8s5X5TnePAg9ChMdTB3 EYdCKHzBGZGCogeWUJXZamxCzQnWZbJS8a1vLodtzK7eh4vCKCKd5kAzM3ebwDmoLMIu+DTe XONFgwLTxz02uF3cUjqlg3nEqBqh34akQ5hySw5tShxA0yEJFgG0XWgOJCIaJzOEqpANEKHN mpQ0ImhhKO+GN99Sa1pz0H6lTlnNFYVKHiq80yAiBwVxW5KWJxTLe1ExFbuhkKGSORdolW4O DNKCbSwSETj0dQ+exDZTbfQaXbZ0HRRfsgX8tOnpMzT0KSWofcItrcuHWn4W13Za/9Au8DQN 3FGcUeoJtgwYpUW2fXIpCMS6xG/CfBuJyDAj00nExBkJAIJfmCZUak5sWxRg5glHFesQbvEx nzLHYuF01KWLmDszmArx/xuZuxEuBttQ5OirdgbQhevrjHDASTRhZByiyGBmTBthMAaKUzEo 6Zmjag7p1LwWQjV6cpSj6CWIiI+bNLHId30gMHNdMu7oeXZvumGStAyizL75AnESe/CedBhh PQBvaHKbnzBdRG1xLDYEzoXVBOgXyuxczNNVeSZmHWJzOpDzECyXWDmDF7pwKyYcTaab8CJg ttxxgdE0BYbnRxFvuVeUUOVBQZbPRO1OR5zzIvgvoGAJBoakh7SYzmHrkTzPeOPDj0lzpQrD EnfYGTChWtEFMQxizk64J0MvIE7g5Hx3zc1PEWWKPZUG2sKdOYX2Q2IN8cMeNk4Y5SD4cdBw JaKallQfPfxE2NTM7+ZFSROwZbu1VUkIU/Eh5MaIpxVOegQWHSnQExBtS2BTQwF1HQdqHh3s 0DBIzIxrzIRs3nSOfNI4HU8FejREwicZ6hK6kNAH6scqZRyTFAtYNRoFSHJB3ygbIyAziRYz x9tF0cI5efmWADprgm+5TUMy++grsh2h1TDwLDEQw5x6QnSp3GD570qHDqBOme7AwQwkqo3D hEXLG3OA80zigMzQSRMRKwROkhz/tCiwiVSI90HpIgmqZq2c4XDG4R8eWSp8ZIgaGXTvH4yr UGtdSxUyYQgjoOo0qxbFIljDldDGwzi1VjkCZopoQHbCmZlHUvekwOYRQyRIlhuGahYpcNjH yI9OecKOTsFF4SBIJciYn2jtQYCxQEHn7/FrsQMG4HDxFc0x7plMrUy8Q1GJZJsFncFwHD3A s1YgGNOK7i2DVPUd3s2NTkaJj05WLimZlQAY2U2UCHCl6glu/CeN+xg2DAbiBM4BZdoDzQB0 lyoF0pGgCGYvjq9V9e1Oy0M3Wjmdgmg9e2bglHeRMGMSD4PNOghkVdcaj1PMzHVyDxN9qSsW djP45EiTB3PDuBqzI0UUb0E94Ke0HgcZzPHl4yZ8ZsUk7VCYCoiZLkzNw7ESiJE2d41xInML ZCbQg8ruYQ3XJSGxtChD2C/UVoaUyjKUEDGneSxqKAQ0AhETg41uFDPeBQeCVOhzBdyR3cAv qlxuC27wd+xAIpZP3JPijQHIjCMAsDUlBiTKlh98vh0fFang8ACUI6+lOw8nN5aONNLnnaw8 OZZgJrojrfvph6Oq7RXB8Pi69Q9xtvPKLWBMMw95BjIQQErBkUUl4WETsDtJhA5E8DjPcVqA QzU3QS5FIde4ubIZAeRwDkgyMU7rg0UyxJ3uKSFwZcjzYXMUA5KOIBIoUognPQcr0DQ0hWpi JA0LO8xKls9DmER0jg62eZrKImKTkr4Gk0MBSTSkDCdxxMj5OvfFb8OmqDgmZUAgJzT1DCo4 24Y1NIdIdMc9sjBGJbfvVybn7JRlgrQkNNrYbFaLlGiVrbBnHB0HB5dnA3Q2WNgQZDJAmCZE 9cyXdxDjlOYGg4edB6QIBsZMacMhwDWhLHKQ2BeBYfNEYaSMYxIHy2LZiRMhQDiFeB4u1wbn YEIgXJXc9LXgjr0uAqOQkp+ccDCjJLAGB1eHzAlw8k3q4xdUtvr0GUMLEBMMXwzc/tSdjIHc d3oKD5oAfa8fts+QW+bLly5mZmm61jcy1ty5laXC5mLhRxy4NcbbmOOZcxGjg5a23MhgPQQO YdrBiMRZJAgEIQxdsDHVvlQMERtYNoOHEKcmVgK90pmXTBdQ50NNcaBcNN6aJYAh7RYGh0Bb oGvYsA2pdyl3Y3w+z+zxosIbkeCkYyQAYjz5a6mjtO9Q9/hvVVVWlRRFxqKqiKmqUYiKqLRR WwXfang0YTqNaRPWvP4/MHMd+FeBPJOg8h1vVVVUVUkFRENUkyVK1s5jNhJlZZXBnKqqpIqh impKSmKqIqgippqIkiI0WNEVUVVEURRUUFFHE93crGGEDrvA07PpHA+Mr5HIbQGMNyLtXX5/ Z6D01rJJJJ2f6XHzT6vj/KfcJkKoTOrDq3Ozel3/YY8Ji7fXU8vj+vdkvZ7fZ4n/f5f0eqxe +D6/5g7j8vz4tjdpTcsmol/fPwDe0+8mSSBJJfEzQUe+fqnpJuF0kkCSSc6lixYy2NFFEiJq IkSJFxxCPb83iIlvgTm07jIBqBh2I+Ut/TD4UuOafDBCi8g6PE3H3Fz2lS7w8xzaIc6bLYDo DHE2a5nmLlIJtgZAQXCxuBnAfPTHH6PPYwK4tzbMHXGo0ngUvDw5AnaqJNJZk1NTVsWmSYZM mQuzMhS5DDVw/gD8tzIqEopuMRNf0mfNcbfKycW3HSFvEwIwEMnU3jdGDn7sTgM8vgq48UqJ IcAwuCwOfAWYsydOWNHoDYgGcYEVIBASEU00zaYmdoWHB1AjqWA9jJo8sAapEy76BYw5vF4D HN1N/jaoHB5JhN2dBkvTINNLwgTeZ9TQ7Lfg64yqSUpwzg2xxLpUYzLWNV9mbXCzBab9lPPo pKArQ+TVWW5rzITV5uZYkXXLrZjzhSSMhll3G8TU5KX8pJqOXppd3SSBQTw69fBGGRrlUm5c i5YJlQpKIQkNFqmM9Gd+gdiC288ZhqJqCTUFgjOSbIU2aYZ22FJTTsxSLBriwcM6F/hQqNwg aOyrqoXiZkQpIJDeQWxMRR3sUxL6BUGaU9it0bZ36H24UkigetTV7XmZAwkUkF3Dc2ICJaGW RuqGZpoH5AxkDQXEHm4scDyLHC2yY0kk0TO6YxiJ2cMRzgMkEgbiInnpu5za0J3I7NzzLFZ9 o62OnLKV878MX5rCiiUp9ntT9Z/OkfqPbsatLs/dDa3x+khM7SThsYGx/YGPUofE7v8ANhVP 2DQUNgR+1drVHcaBIS/bUlFN9RjJpuCEPQV9WB/aOzn2pajsyoBKQkmmoEOLVV0q7y5dw3LG qXebwhIyi5zTFa0b8AcJY0eZuF2MSB+RrDcc6WPujVfgN3dk/N9jJz0NsMiGcl4MoYHYs0Hn BMDEIDhCnLzkfMlw0YSBCBmhyNYB0btnRNoDEcz4tliYs4UCZcrEOSck5JDchvznaXR1N7fl aWOuCKGDA4kGQkJxDt48i+81OGR213hgTdoPnyqbNg2821ejc38/I6hoOLB2zUzWBy415amh ThAyHEMQaLkDsZObtzzUO3eSZGhwxukrw8p5mJmXmFMAqF1O0YamZt2lssu3fgGRmiB2k0UQ cGeQw3dlQ47okLCgRpR0ORFLsJsFUZEtYYd3PM5tJmpILkNFO5TGRsGxRYm6rDSeU6aGlid3 xYk3vcO4kTa9pUQLCg0mT6Eytya6gLotUZjxHoPQeg/4IZGp0oPssNk4gnFWwSx4chO4c/X7 AzDdDwb8R69CbkZO8niayKIDYYCqChg6SJ5h/qf9A7OGyHCQ+icoiltYYRUTRRFL5c/z0M9B vTfF4XMPJz99RABh82Pp58s8qThUKLA+Oa8nYfX+G/kyyEjiNTKLUQs6KMulioEupd7fbz9m 3kePZMMgZg+fVVkQ9Z1sFw1TjQs7juZMAVQgrTB/hkoGICRyPb+B+/+35p57eKD9G6rGEqDO s0Q36wOQBoGXKyHnKRm/U359iwfLfT+MfWJYKImaaiau8+fMNDoohY07mRUYQ7sLgEMEtDsa 2qBNzGls9uj8ODOYXDGIFuGbwnSEccmfR1WT0g9zn0RgSKf73IT8rxoD1xu5hIE7MUSn8KHn SSUePdtkdIDvnc9VgUFh6zkdQAGHnLeVKTjiHlJ2Zjf1saCA3OGcuGlKvX7k9z+G2vg+hz8j HqHoh6Q7CU8KK9NfkP24XxMDlpHIB6IIfW/PlmHhH1Aj20RloVTMcXxmVkS2VjCexsiTdkoM iRHYyFSfjVo0SiaQuvlcQQEINEFJQbYYTBTRZmR0R7QKCCdTxe+1Guujvov+oeS9LX/eoX7n sQLWuBD+q43lHk6BeUc4WkHkc/R5v648/SI2TM5pchIJ8U4QA8ApBaAVklICyodoCwcsPM0x kfojYV0gZCXKW5LQMkgWBY4BKloUbaU8uTRNaZlp/MnBhQ1ZYnGHj5mx2yMm9zDFMzSbu3bS hU3s3ho29PplON0tqiqoVGWFFipPEX4fBzo0jbu0mRCBsog5c8Jt+qAGcYPAigdzzcHpprgG 6Ad17gwRiiT7rFi9lvAe37jwH4ypqX7w5mxOuiFIOEp009SHIO7vCYTwc2/diirkZhOuGQd/ 5A6uxRQr16mJqMhNRE26B2e4sWJKGcYczvewxoe1Y3JehY0a6t1u+zxioa8TU3if16pASxCh UhP1pofL6TH134PIYXgHW5ykiljazI6E6QO7pNPKRYGmoDc3BLE8Z13AZ321O+mXMHCVZ+UY S4M0MLAs7Y2HoRtGmqQ+B84PvkbDiHU8UfNREj+IdAOXxSk3vTiUmw8zle9PrxsWN3VBDvUq erOwzoEUidpk1NatFhcwMqHGvi2aV0bFge3QmXAkxpMfElTGEw28cNMaNjHaNqZJdw5a3OZu XLJg2oRJKmIqmGb885sgxFi+IdEJAocgIEKMamoMsePPryPSM8mhOEGIAbg1YDGGt2AZAIjH 1sMVgcoO5NKnHl0pLHnl/9ABS1jVDzfRbVDOJFNuwEsZvGHMVOsIFay17JBo7B+r0Hb3dwKB iCW9OhnwjWJizp3ZIJh5ZXQ0ZKabMYpiGZS0OQyyBvJQiCmb72uNJNaMMsprNCaE9plKy4Jz LCp0cbdF6M0lcga06dweCE1KkkbAlBRW6y2jxeqnc52AD4GWQMbdZ2I3U2DClHBLUVYtX5qb nTEprKcIcSOTy2B80V0MBHag/n/n0sSYU3dDfVy3QIYNQ9MbxHIbvUCVOfvdnveDenYHdiwy ++yiJjp7qUz+W7kX8sMWreB3dsXtDXlrwOoV06RFhmbPy7mlroXyVsbNGWC9bB13qFiLaKC1 ccr12TbrnA1G1hKAgLmZgNZzbCbAnRMWIvifnzTG47pMOrZsMBDY74a5Zhy0dFX0ckLpPJG1 +VoUZYpYq/tkwjtXS08ONBjOgqaZtmtuWxXIvqxOJILovd5bMmbSWqzWHmZ2T9L8ttVE9OG2 OmYSt27cecsxjbsnjfjtwYuclDQgNuJaps7WxdntZ2sbp7cSTAiSO1UxzRI7OELRA1jRO8M2 2Lj7/pdtJmjUbl8cKvYe14m0u7NcM7vLu6Ls14WdjId9qMQooiuK7tGhd2DKQroFGA1CBdyp NKvTtysv+tJIB3FgDoj3P1d+zN3YZi4k0ZyZ+tJMHVrMcjoRehPzjHOb09HWYDs1TffnubbO xJIzY1jia4Bc05NTOqmwt5IrjY3t8lDVraP8oo6JubcjR6zt8AHAD5YICnB6CcyCakHxgoDC U97xENj6T0h3hnqaQTqBR+lTpN/5FOTIJu8zt6Thus/MlJzQGPCWOOOenDvQxMCsKZSGKQOg DvYMyKd+zUj5kIdMBPXP6g4YN88I7Tu8/IMHjhTpBu+oG6xth4D3ED5g1NR1Mwga7c2IFxZY klsndewO1LMcZvgcLILZ6aW6kRi4ah2dbdfKQhyGCLoRDwos8lrkedO2rmgxTjQLLugTHoRM VCIEzaCDIWbSbBcxoRYjqdvVJeKXKmTw6vvHFeLEFSwfah5e+EUNL/bFVTR9NoQ7k6ih5xKI 85gMOiIhDgCIbdettjbJUzdEdUOKLxHffJ9cqkCpZg6RkkI952D4aCE+El61NLTZD1fycjkI Yg8E7ev0WHZhajMKLTJhmJAYwUCtGYxggZjMwwS1VFURFUNUQcH0bKh4HPYz254nifYxoMqD ig9jPeD4gyISBIHCFAUhiJxBWjuQ36oG1SUggUghQqcRk80iyCPPktgrCSTU1ndk9DuMm9OI Hw8EoRBA78X6T7mWyew4bX37RFPbO9TY71qdNBJWDXL1HqP11pYpT63CL3OY2vnPR8lvTtTB AGsXvQiQxwGmuy6LVd275zg4MuFN/BNqcmC/R9OGGJ6AdOoApIgKTso+0JAQhVT9uWryS1h0 TMEtgGKy5m4KLknzKUwwCkvc9jzB2FL8cH6+O9DEOnAK1oCU0USkRmsYlOUBvBsSG80ZIYan DMcGNGKajTANNATiYBPklBKho4udoXzjDb+aviTkWoPFN8CSQkJCQ7Q5bLuM9fv5CFrIHMcB kg30HI9nwO0gchOKqbhEZYIYJSZlNgWBQGZx4eW9/aG123C44lVRijC4jZW544ocHd7/6dAL coB6uihbRT3iCmgFiBY5olQLfwsHCycrPvRz24J1hMeEVSceT3mlcCugOrv89k5oEidlJQkJ PKonb9NT44Bhfxzy9fphP5YPeXqUNpx1f62QLkpB+NFAJCHw/fa8vkH71MM/Qv68pMkE1ioX xTlBx/VQXQ/LajGPq/ZJfMsC2iEgRPpwoExsjqnqcAPQoflvVAiVQFAGvwhp08wO1D62baAO 5i5yhjg5J6LzABBq4g70evQzbQBVUm8GPSGBJrWfsPFxlxX2h9B4PwDt3pTLGO5kkzJMzF/R cpXoG7QYzIGFhwAGjgm7ADMbp2BUWnTxxEnpSvemviPRBvZcZ6RiYFP2DO7gy+9m04p6A4m0 HJMgMYic+g0BucENjeKNpEtBDuYVoCxBYEnR48ZE+2Anpbv3/tJJ4vbCBwAL0zkTEQfwWa8x pehCXCqpSqO4zBrUjrwKpiYeaJIEkCEHs54NjJ7i/D8NTJD1+R0c89BQhu41a0g3kCoYgooI MPa9yNN4nYD4+A/Hs4po8SdOodCPQrp39fT0H9m7rIOKM0a1KwwslaUXSrfDNXkBgYJwkNeu +brQJkPuaOjyXY3w37tTxAXkb/wKIh0qxZbgFvl9+BPOIvYMz8p/McEvH6h0zB3wkCv2wqFR ZUKnAowh9maMIAoaS78hRDKTIUCGo/GTQvhATK0GjMIXuWdffNRM/kb00ORmZDryADY58u8t yAKDSM922C7O1mi0A1iK2qFtJQMiRuqHnynGnHYVNKgeZg6Kc2ga44uAsRUOGcCbsTI3eAUJ uPnwLZZKUR+gRNx0IKekNao7GaaOMhjZDij0wO0w53ZuiUAdAeZMVMNhKqscyHhCnQznKaMj a+KiHuUM02d0nEErFqBk3mnUOowDnzCcniQt1/OUO3sSON4Qfxg3AZ/cQiUOr2O73DUxP2Ci U1MUk5JQ0gfjoblfDt/hhaByPIDLnQIUQ8qLEGiCCSJKqtjdNpD4+8zge74U3SvGh5cwLIPW yEOsgQHcAWHz0fx5OnSFBYNEDg4ZUOOQCQeDaqWCgoPeBg5DcOHiK8oFnU0oVDuQvG88tEaQ I+HFwi4ZEByqRpHccKAeAgWwR14mK4AlNInYmuvb3U7qB+c22jxgTxTULRSQ/C19naJpuPoE 5oBsyBqNeD9OTNZCKQJqB3KR27fXwDOWPlRMZt/ftLclcG5KXg8JmPdaKIQZE2dCZHFnnulc tijAoRqCT8Y3j1MVMaWhLTxnRedBvMuDA4y64LpFiV1DRdU/5JDd0KNBJBVwbE3wwHknEE0b YibD+sQjJANqB0Msn048gba+yZa25MAKN25kIWw746YcOxE2D9qF/vBBTjwOwA55DDSAppCA FKNZY4lB3IHg4P5c7cHvoHCWL0Yo9ChA6h7nz9biuKf2YlNSU1w1i8uAag8ds7QOoI1UREEl ErQgnnTjiqQFt6N9HkHpMGJoU9JA4TAlsuAvJOL2PpweREwcOBIRAGUSoMjRQBSNLA57xcbz I3UJFQJHMxjI6oEicTaMAZQwA5aSQCUUZ5m0MF1cpnD0yML5B4/RS0Bt70of08z1QN6SnZml EKhVV2PFBPXnygpAWTMei20njcI89FGjAVN0Mk4gYS6mgQCDl+D+Z9HkjWgyZQLgHOp+L85t RLdG/l50U9/0hm2Dr1kF5SPgp7SBRAMaB2TJDIjASYOvbxgkKluTJCEk0O9+ZwkDwVkFrRJ9 HRe+hUIHQds17C8dl87vAYDAgIZAEJn+Ieo0j8DSt/VKaPB9uLGDDKcbhN32I7rwIoPPBlVG jCA5OaDQxH2T3Jx5dd6VoZVGRePGhz73X3fHQwar1w9OzgDr7iGBJwjuJ09tXwljir431aGw TTqRdQ08prwh5MsMOSeh1PtHl7ht5FJK/fKLRZ7NrJSmx03yELDzDzIkj4Ivmec+KH15bUSF qNrfOgWu7kVpUoqrTqadrNwnsYElYBoeEoiq3IIxA5xQIAadBBRWCjxbUWvYOe+gNh1Y6tlO ZXYzeBGfLGZw9pIIiKvBwGAX55zfUJs8aBeg18mT1nNJ494aCJkILIwiiDimJiP0d4ceJxQs cSZgooHP4uPK1ht8HhHh6Uk7QjviZKbIJSxXFm3SSEIEYyhSn36LwngzZkaAJsgz8yWFf3Ti egdgNTdMi2l9TgwPZzDv1PaEQdR3YhzFqAUI7jndLy5URrZSOPhqwmiGIsiSGOSHjW4nP3E2 zhTqRiGvJVOJQ5ZAUcG+VqNeltaC5WLxSDLRR6ttBw0Z7PN2BQuzUNtwjiNJLLPdmRqymqZq 2gxiS1ZFRqWsSasqAWuVFmQX3UuTefhS5EZjassaFsgzIPQBMqu3s0QqAcpeNRvpB4TQyagO zkLQWbFFB+T6m8uYALBaBDRwkmCtT9G3lwOSQIgccmRzd9ghqEqDCqqVVMgQqFQXsfyxNxAY fd1Gvuv4LFJr41qv9HbvEXMOpAgRX/cPw3Nh+4iV7J2+yiXucdUt9IazB9gfIp4ccWhzfQ2v I94jiM1+IB3/6vuh3AD+UES1UuPuEs8oEOd3XenGqNgPZzDaIlgIXtEgKRvSg68560Pn+ehT UyBewBwLKcEHXxDwrIiSRipGQf1h8iOrwgpbNQ9QsDfZKJ1VCrO95nbxJ4CMCzbi8lU5AIUH PRH+wN4IVJBKDpJIOxsIihyZgioF3NbmrKamCkMBzO5RE39QSIdhOAQz2MOr0qpOtkxMRRfQ 1awlVIguEpVkO1lYslSoFQ2gXUKvCfXYeHCUEiQP3CjgcWEPc64VSr45/ecXwMi28c2m0NIz xwCJqmLW+ZxscWdkK3wuOTZkO1J0k54VckHlO9WZybZrY+PZjhnYqvNapJtDRiB24o+qjeD6 k44g3RDCdSoM6JhsvvZxC40SpVvY8oN2xvcpbaTAdWUQSMFHtFGxGJ1HbeHDN0zwJ2sKhD2l yXzdo6cYtoBGH0hJlOrFiw8PbW3f1qcl1IPQ6lTQk5rmVMelUu5d6uZvKqVtVfTMSxsYelsn ywXIIeXCfb6YuDjgkiMZovDMTxZjtbAgTHePMe1WsD2iSHkYmAyIMqAUjDdUdDhncCAcQL1+ nfQeiUUNkF2JgB2vpS2igKa1vCYw4kOhquhz8QDipUtkLXnGDdH3cPXfFGUDIfEWLWiWaA6i MHmmTl8zpctDNpYUQqCUosEfoeouTEkPNiSISY+yiUXTmQTdg72rpNMU8gu8LgoUCbeC512e cf83NnYtNHBIWrDGvhDy7JeptEzAyeASa75XYnXopY64TdB3IGIMF0dkNh+jzYRhVEVNFBNQ 0GGaDnP8Sr1lU4XuMgTnTiqS28NETaIb8sgozb58QwJGBKyC3vIoNkwPun5vpzibQtAVGpKj QUFLlZLWbfdQXjq7snYnnYx1KLoLI8OYo5cwhfTPq6vay9RGzhSd6EotVo81Xs91djKQvi8U +yrbN4V3qhGCDaqdEgm1VKyRCs1qeKJQkUG0yiiqB5B/1DTsDBDZQk7OcYAdA1zizvZOROCS T4McNqhmKyTmGaQH4e5N7UQxZSkbOb0jewME2KzF6YHMM7sU4xSDSYlDJYHDDWT32ze9YuPc sKXNzQmkh6SIShmtA0MWV9nxOB7SkYwns45K4bVRJCYHVayWi1WlPh3mEkMwW3qyLU7irnRU uU8qLplLhUxMTIEtIIYDTcpDBhgNkNhdGnMKGCA0kOhULyTSw3QrRWm1zU2wAkBkXXjjshnl web95hFhYBTpAOJcnXM5ZKh2nMM0IgKHrCMUx0mo7ZR0mZciUht+xcqNNIplWtLDOwLsSIvA 1ncHJjjXJi/EiIZBuDYRm0GxTyDHOFJupXQfZFGv3IVVFaxSkYZ5k4ACcUN+SDtyoxy1egQk InwUntaiHYwbt80NyFwNi23WhMzgZg2uEmSpExfcLxBg4pWk2hvUKsFihnsjwDwTzN8GiaEJ 0M9+HnOKDwUKURIrqc8ooEp9Bli+3OLbLGLl21kFInExIssKWI0ZVbjbZtJ27xgewHpibkCs Mdh7u4zuof3oGj5Y1DSjPU1WRFRVYsPK1JWTbDBOC0SfZwemfvnt4XoZUeubnFdoyLIwhIQg EYDIJKUoqXcIZ17+SiJoAZAfd7sMPF+oWyfbvnLcvdlJOJPkEkD3IFw8IdMnlL0LJ+AOH6QQ JUJsBvlyhWaNdCtdh9rMbRAlkihgJ50ExMSoQjCsBzfe/nF09ZOJGjXU/MQKbx3IBsD8RqOw Ve3znd+UPbLpigP1HDvvbgEmEyZmEgINhxI4DgN7L/8Wlw1onkQUKOFG/5xJH1BlX9h9IjE/ /U/aEiJULqSmhEoVYkEPRA5aqZIer1B9ngKLkxhifoJUVmtYAuaT7wowKbzIBiTrnqJ2d4UA 7DMpSmCOZSbDb+pZXH9xo0/pfWvvMGSbdAdlF2N4UG3I3IJDMOeqPiOZKXdCu6IwbpZeAGpv oMxtym5/doC2oUm0T4xKshpo3L8KD3JJgimB279zMNeeEQVGZDrEdHSj9rSalo6P7xk0b9Oh mCbbYfqRRDc6Gvp0vDgERVVEVRFRA0FBERQ0TUVVI1UVVVVUVCVEVStVSqi7pVGpUUREYxBi KqjREVFVRSSE6Dg/ByOuh58tk72eeZhjCc9LSV7FxO8l0Hs+6ven1EdJvotETsQeZ2C/mKZt y0LBQZpWKShahDAHBK/pnFfYsbwyrPYE2OPgBNDeGfewiH5xkFkACYKRr4QzxkH/7EEiGlzB B95/D2VW6qZKyKjAGj1VAr1WR8MDyC//i7kinChIftXtEQA= --------------010801080306060802060205-- From romieu@fr.zoreil.com Fri Sep 17 09:03:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 09:03:34 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HG3SlD020424 for ; Fri, 17 Sep 2004 09:03:28 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8HG1pvr029422; Fri, 17 Sep 2004 18:01:51 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8HG1pqP029421; Fri, 17 Sep 2004 18:01:51 +0200 Date: Fri, 17 Sep 2004 18:01:51 +0200 From: Francois Romieu To: Jon Mason Cc: Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040917160151.GA29337@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9023 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 395 Lines: 12 Jon Mason : [...] > Before I make any sweeping comments about the performance on ppc64, I should > probably do some more tests. I'll have to get back to you regarding that. > > Would you like me to run the "Config2" patch on my amd64 system? Please do. If I read you correctly, 2.6.9-rc2-bkX works (more or less) on both your ppc64 and amd64 systems, right ? -- Ueimor From jmorris@redhat.com Fri Sep 17 09:10:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 09:10:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HGALLm021292 for ; Fri, 17 Sep 2004 09:10:21 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8HGA8DT001270; Fri, 17 Sep 2004 12:10:08 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8HG9wr15021; Fri, 17 Sep 2004 12:09:58 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.80.63]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i8HG9wiS024593; Fri, 17 Sep 2004 12:09:58 -0400 Date: Fri, 17 Sep 2004 12:09:58 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Zilvinas Valinskas cc: netdev@oss.sgi.com Subject: Re: Crypto tests via tcrypt.o modules failes In-Reply-To: <1095434486.32091.2.camel@swoop.gemtek.lt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9024 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 462 Lines: 16 On Fri, 17 Sep 2004, Zilvinas Valinskas wrote: > > I've had a report that all is well on an Xscale PXA (SoC) system, with a > > 2.6.7-rc2 kernel. Are there any significant differences between that and > > what you have? > 2.4.27 and 2.6.7-rc2 I think quite different - can you tell me which > parts to check for differencies ? It should work on either kernel (btw, the PXA is little endian, so they are different). -- James Morris From davem@davemloft.net Fri Sep 17 11:31:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:31:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HIV6ch023569 for ; Fri, 17 Sep 2004 11:31:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8NSS-00064Y-00; Fri, 17 Sep 2004 11:27:44 -0700 Date: Fri, 17 Sep 2004 11:27:44 -0700 From: "David S. Miller" To: David Gibson Cc: akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Message-Id: <20040917112744.190f6f3e.davem@davemloft.net> In-Reply-To: <20040917062042.GE6523@zax> References: <20040917062042.GE6523@zax> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9025 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 161 Lines: 5 Thanks David, I'll push this upstream asap. I can't believe in all the route testing I did I never triggered this on my sparc64 boxes, must have been lucky :( From davem@davemloft.net Fri Sep 17 11:35:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:35:12 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HIZ7Yb023942 for ; Fri, 17 Sep 2004 11:35:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8NWN-000656-00; Fri, 17 Sep 2004 11:31:47 -0700 Date: Fri, 17 Sep 2004 11:31:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jes@wildopensource.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] acenic - don't spin in hard_start_xmit when ring fills Message-Id: <20040917113147.342eef72.davem@davemloft.net> In-Reply-To: <20040917090217.43483d10@dell_ss3.pdx.osdl.net> References: <20040916161753.37254cbd@dell_ss3.pdx.osdl.net> <20040916162250.5b7cfa85.davem@davemloft.net> <20040916164206.707204d4@dell_ss3.pdx.osdl.net> <20040916165042.362a3e79.davem@davemloft.net> <20040917090217.43483d10@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9026 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 787 Lines: 23 On Fri, 17 Sep 2004 09:02:17 -0700 Stephen Hemminger wrote: > On Thu, 16 Sep 2004 16:50:42 -0700 > "David S. Miller" wrote: > > > 1) Accept this spinning performance characteristic of the > > acenic driver. > > What if there is buggy, hardware that never drains the ring. > It can happen. You're preaching to the choir :-) I've been bugging Alexey about this aspect of the Acenic driver since day one. > > 2) Finally give up on acenic's clever lockless scheme and add > > the necessary locking + start/stop tx flow control so it > > will never have to return TX_BUSY except in absolutely > > catastrophic failure cases. > > I'll code up a non-lockless version and see if makes any real difference. Let me know how it goes. From dave@thedillows.org Fri Sep 17 11:37:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:37:40 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8HIbX24024351 for ; Fri, 17 Sep 2004 11:37:33 -0700 Received: (qmail 13247 invoked by uid 0); 17 Sep 2004 18:36:11 -0000 Received: from user-69-1-45-93.knology.net (HELO ori.thedillows.org) (69.1.45.93) by smtp1.knology.net with SMTP; 17 Sep 2004 18:36:11 -0000 Received: from ori.thedillows.org (localhost.thedillows.org [127.0.0.1]) by ori.thedillows.org (8.12.8/8.12.8) with ESMTP id i8HIbLMn021140; Fri, 17 Sep 2004 14:37:21 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i8HIbL0q021138; Fri, 17 Sep 2004 14:37:21 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: [PATCH 2.6-bk] [RESEND] typhoon: PCI cleanups and ethtool_ops conversion From: David Dillow To: Jeff Garzik Cc: linux-net@vger.kernel.org, Netdev Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1095446240.21058.2.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Sep 2004 14:37:21 -0400 X-archive-position: 9027 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 17293 Lines: 597 Jeff, please do a bk pull http://typhoon.bkbits.net/typhoon-2.5 This will update the following files: drivers/net/typhoon.c | 259 ++++++++++++++++++++++++++------------------------ 1 files changed, 136 insertions(+), 123 deletions(-) through these ChangeSets: (04/09/09 1.2061) PCI cleanups and convert to ethtool_ops *) Reorder MWI initialization *) Perform proper cleanup on probe failure *) Remove cruft, and avoid locking up NIC on reset Signed-off-by: David A. Dillow # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/09 22:57:10-04:00 dave@thedillows.org # PCI cleanups and convert to ethtool_ops # *) Reorder MWI initialization # *) Perform proper cleanup on probe failure # *) Remove cruft, and avoid locking up NIC on reset # # Signed-off-by: David A. Dillow # # drivers/net/typhoon.c # 2004/09/09 22:49:47-04:00 dave@thedillows.org +12 -4 # Update release date and version, add TODO list. # # drivers/net/typhoon.c # 2004/09/09 00:55:56-04:00 dave@thedillows.org +0 -6 # Remove cruft from when the typhoon driver left the NIC in D3 state. # Its remove could be a problem on a warm-boot from Windows if 3Com's # drivers left the card in D3, but they don't do that, and the code # is blocking progress elsewhere in the PCI system. # # drivers/net/typhoon.c # 2004/09/09 00:30:09-04:00 dave@thedillows.org +81 -84 # Convert to using ethtool_ops, and add some extra abilities. # # drivers/net/typhoon.c # 2004/09/08 23:30:07-04:00 dave@thedillows.org +14 -14 # Make use of netdev_priv() # # drivers/net/typhoon.c # 2004/09/08 01:28:47-04:00 dave@thedillows.org +9 -8 # Still seeing hangs with 100us wait, so bump it to 5ms if we can # sleep, and 500us otherwise. # # drivers/net/typhoon.c # 2004/09/08 00:50:01-04:00 dave@thedillows.org +21 -8 # PCI cleanups: # * move pci_set_mwi() earlier in setup # * call pci_clear_mwi() in ->remove() and ->probe() error path # * call pci_disable_device() on probe error # * make use of DMA_32BIT_MASK constant # diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c 2004-09-09 22:59:32 -04:00 +++ b/drivers/net/typhoon.c 2004-09-09 22:59:32 -04:00 @@ -1,6 +1,6 @@ /* typhoon.c: A Linux Ethernet device driver for 3Com 3CR990 family of NICs */ /* - Written 2002-2003 by David Dillow + Written 2002-2004 by David Dillow Based on code written 1998-2000 by Donald Becker and Linux 2.2.x driver by David P. McLean . @@ -33,8 +33,16 @@ *) Waiting for a command response takes 8ms due to non-preemptable polling. Only significant for getting stats and creating SAs, but an ugly wart never the less. - *) I've not tested multicast. I think it works, but reports welcome. + + TODO: *) Doesn't do IPSEC offloading. Yet. Keep yer pants on, it's coming. + *) Add more support for ethtool (especially for NIC stats) + *) Allow disabling of RX checksum offloading + *) Fix MAC changing to work while the interface is up + (Need to put commands on the TX ring, which changes + the locking) + *) Add in FCS to {rx,tx}_bytes, since the hardware doesn't. See + http://oss.sgi.com/cgi-bin/mesg.cgi?a=netdev&i=20031215152211.7003fe8e.rddunlap%40osdl.org */ /* Set the copy breakpoint for the copy-only-tiny-frames scheme. @@ -85,8 +93,8 @@ #define PKT_BUF_SZ 1536 #define DRV_MODULE_NAME "typhoon" -#define DRV_MODULE_VERSION "1.5.3" -#define DRV_MODULE_RELDATE "03/12/15" +#define DRV_MODULE_VERSION "1.5.4" +#define DRV_MODULE_RELDATE "04/09/09" #define PFX DRV_MODULE_NAME ": " #define ERR_PFX KERN_ERR PFX @@ -410,21 +418,22 @@ out: writel(TYPHOON_INTR_ALL, ioaddr + TYPHOON_REG_INTR_MASK); writel(TYPHOON_INTR_ALL, ioaddr + TYPHOON_REG_INTR_STATUS); - udelay(100); - return err; /* The 3XP seems to need a little extra time to complete the load * of the sleep image before we can reliably boot it. Failure to * do this occasionally results in a hung adapter after boot in * typhoon_init_one() while trying to read the MAC address or * putting the card to sleep. 3Com's driver waits 5ms, but - * that seems to be overkill -- with a 50usec delay, it survives - * 35000 typhoon_init_one() calls, where it only make it 25-100 - * without it. - * - * As it turns out, still occasionally getting a hung adapter, - * so I'm bumping it to 100us. + * that seems to be overkill. However, if we can sleep, we might + * as well give it that much time. Otherwise, we'll give it 500us, + * which should be enough (I've see it work well at 100us, but still + * saw occasional problems.) */ + if(wait_type == WaitSleep) + msleep(5); + else + udelay(500); + return err; } static int @@ -688,7 +697,7 @@ static void typhoon_vlan_rx_register(struct net_device *dev, struct vlan_group *grp) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; int err; @@ -726,7 +735,7 @@ static void typhoon_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); spin_lock_bh(&tp->state_lock); if(tp->vlgrp) tp->vlgrp->vlan_devices[vid] = NULL; @@ -757,7 +766,7 @@ static int typhoon_start_tx(struct sk_buff *skb, struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct transmit_ring *txRing; struct tx_desc *txd, *first_txd; dma_addr_t skb_dma; @@ -908,7 +917,7 @@ static void typhoon_set_rx_mode(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; u32 mc_filter[2]; u16 filter; @@ -965,6 +974,9 @@ /* 3Com's Linux driver uses txMultipleCollisions as it's * collisions value, but there is some other collision info as well... + * + * The extra status reported would be a good candidate for + * ethtool_ops->get_{strings,stats}() */ stats->tx_packets = le32_to_cpu(s->txPackets); stats->tx_bytes = le32_to_cpu(s->txBytes); @@ -1002,7 +1014,7 @@ static struct net_device_stats * typhoon_get_stats(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct net_device_stats *stats = &tp->stats; struct net_device_stats *saved = &tp->stats_saved; @@ -1030,9 +1042,10 @@ return 0; } -static inline void -typhoon_ethtool_gdrvinfo(struct typhoon *tp, struct ethtool_drvinfo *info) +static void +typhoon_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { + struct typhoon *tp = netdev_priv(dev); struct pci_dev *pci_dev = tp->pdev; struct cmd_desc xp_cmd; struct resp_desc xp_resp[3]; @@ -1055,9 +1068,11 @@ strcpy(info->bus_info, pci_name(pci_dev)); } -static inline void -typhoon_ethtool_gset(struct typhoon *tp, struct ethtool_cmd *cmd) +static int +typhoon_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) { + struct typhoon *tp = netdev_priv(dev); + cmd->supported = SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | SUPPORTED_Autoneg; @@ -1107,15 +1122,19 @@ cmd->autoneg = AUTONEG_DISABLE; cmd->maxtxpkt = 1; cmd->maxrxpkt = 1; + + return 0; } -static inline int -typhoon_ethtool_sset(struct typhoon *tp, struct ethtool_cmd *cmd) +static int +typhoon_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; int xcvr; int err; + err = -EINVAL; if(cmd->autoneg == AUTONEG_ENABLE) { xcvr = TYPHOON_XCVR_AUTONEG; } else { @@ -1125,23 +1144,23 @@ else if(cmd->speed == SPEED_100) xcvr = TYPHOON_XCVR_100HALF; else - return -EINVAL; + goto out; } else if(cmd->duplex == DUPLEX_FULL) { if(cmd->speed == SPEED_10) xcvr = TYPHOON_XCVR_10FULL; else if(cmd->speed == SPEED_100) xcvr = TYPHOON_XCVR_100FULL; else - return -EINVAL; + goto out; } else - return -EINVAL; + goto out; } INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_XCVR_SELECT); xp_cmd.parm1 = cpu_to_le16(xcvr); err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL); if(err < 0) - return err; + goto out; tp->xcvr_select = xcvr; if(cmd->autoneg == AUTONEG_ENABLE) { @@ -1152,93 +1171,80 @@ tp->duplex = cmd->duplex; } - return 0; +out: + return err; } -static inline int -typhoon_ethtool_ioctl(struct net_device *dev, void __user *useraddr) +static void +typhoon_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { - struct typhoon *tp = (struct typhoon *) dev->priv; - u32 ethcmd; + struct typhoon *tp = netdev_priv(dev); - if(copy_from_user(ðcmd, useraddr, sizeof(ethcmd))) - return -EFAULT; - - switch (ethcmd) { - case ETHTOOL_GDRVINFO: { - struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; - - typhoon_ethtool_gdrvinfo(tp, &info); - if(copy_to_user(useraddr, &info, sizeof(info))) - return -EFAULT; - return 0; - } - case ETHTOOL_GSET: { - struct ethtool_cmd cmd = { ETHTOOL_GSET }; - - typhoon_ethtool_gset(tp, &cmd); - if(copy_to_user(useraddr, &cmd, sizeof(cmd))) - return -EFAULT; - return 0; - } - case ETHTOOL_SSET: { - struct ethtool_cmd cmd; - if(copy_from_user(&cmd, useraddr, sizeof(cmd))) - return -EFAULT; + wol->supported = WAKE_PHY | WAKE_MAGIC; + wol->wolopts = 0; + if(tp->wol_events & TYPHOON_WAKE_LINK_EVENT) + wol->wolopts |= WAKE_PHY; + if(tp->wol_events & TYPHOON_WAKE_MAGIC_PKT) + wol->wolopts |= WAKE_MAGIC; + memset(&wol->sopass, 0, sizeof(wol->sopass)); +} - return typhoon_ethtool_sset(tp, &cmd); - } - case ETHTOOL_GLINK:{ - struct ethtool_value edata = { ETHTOOL_GLINK }; +static int +typhoon_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) +{ + struct typhoon *tp = netdev_priv(dev); - edata.data = netif_carrier_ok(dev) ? 1 : 0; - if(copy_to_user(useraddr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_GWOL: { - struct ethtool_wolinfo wol = { ETHTOOL_GWOL }; + if(wol->wolopts & ~(WAKE_PHY | WAKE_MAGIC)) + return -EINVAL; - if(tp->wol_events & TYPHOON_WAKE_LINK_EVENT) - wol.wolopts |= WAKE_PHY; - if(tp->wol_events & TYPHOON_WAKE_MAGIC_PKT) - wol.wolopts |= WAKE_MAGIC; - if(copy_to_user(useraddr, &wol, sizeof(wol))) - return -EFAULT; - return 0; - } - case ETHTOOL_SWOL: { - struct ethtool_wolinfo wol; - - if(copy_from_user(&wol, useraddr, sizeof(wol))) - return -EFAULT; - tp->wol_events = 0; - if(wol.wolopts & WAKE_PHY) - tp->wol_events |= TYPHOON_WAKE_LINK_EVENT; - if(wol.wolopts & WAKE_MAGIC) - tp->wol_events |= TYPHOON_WAKE_MAGIC_PKT; - return 0; - } - default: - break; - } + tp->wol_events = 0; + if(wol->wolopts & WAKE_PHY) + tp->wol_events |= TYPHOON_WAKE_LINK_EVENT; + if(wol->wolopts & WAKE_MAGIC) + tp->wol_events |= TYPHOON_WAKE_MAGIC_PKT; - return -EOPNOTSUPP; + return 0; } -static int -typhoon_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) +static u32 +typhoon_get_rx_csum(struct net_device *dev) { - switch (cmd) { - case SIOCETHTOOL: - return typhoon_ethtool_ioctl(dev, ifr->ifr_data); - default: - break; - } - - return -EOPNOTSUPP; + /* For now, we don't allow turning off RX checksums. + */ + return 1; } +static void +typhoon_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) +{ + ering->rx_max_pending = RXENT_ENTRIES; + ering->rx_mini_max_pending = 0; + ering->rx_jumbo_max_pending = 0; + ering->tx_max_pending = TXLO_ENTRIES - 1; + + ering->rx_pending = RXENT_ENTRIES; + ering->rx_mini_pending = 0; + ering->rx_jumbo_pending = 0; + ering->tx_pending = TXLO_ENTRIES - 1; +} + +static struct ethtool_ops typhoon_ethtool_ops = { + .get_settings = typhoon_get_settings, + .set_settings = typhoon_set_settings, + .get_drvinfo = typhoon_get_drvinfo, + .get_wol = typhoon_get_wol, + .set_wol = typhoon_set_wol, + .get_link = ethtool_op_get_link, + .get_rx_csum = typhoon_get_rx_csum, + .get_tx_csum = ethtool_op_get_tx_csum, + .set_tx_csum = ethtool_op_set_tx_csum, + .get_sg = ethtool_op_get_sg, + .set_sg = ethtool_op_set_sg, + .get_tso = ethtool_op_get_tso, + .set_tso = ethtool_op_set_tso, + .get_ringparam = typhoon_get_ringparam, +}; + static int typhoon_wait_interrupt(unsigned long ioaddr) { @@ -1756,7 +1762,7 @@ static int typhoon_poll(struct net_device *dev, int *total_budget) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct typhoon_indexes *indexes = tp->indexes; int orig_budget = *total_budget; int budget, work_done, done; @@ -2068,7 +2074,7 @@ static void typhoon_tx_timeout(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); if(typhoon_reset(dev->base_addr, WaitNoSleep) < 0) { printk(KERN_WARNING "%s: could not reset in tx timeout\n", @@ -2098,7 +2104,7 @@ static int typhoon_open(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); int err; err = typhoon_wakeup(tp, WaitSleep); @@ -2140,7 +2146,7 @@ static int typhoon_close(struct net_device *dev) { - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); netif_stop_queue(dev); @@ -2168,7 +2174,7 @@ typhoon_resume(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); /* If we're down, resume when we are upped. */ @@ -2200,7 +2206,7 @@ typhoon_suspend(struct pci_dev *pdev, u32 state) { struct net_device *dev = pci_get_drvdata(pdev); - struct typhoon *tp = (struct typhoon *) dev->priv; + struct typhoon *tp = netdev_priv(dev); struct cmd_desc xp_cmd; /* If we're down, we're already suspended. @@ -2303,17 +2309,17 @@ goto error_out_dev; } - /* If we transitioned from D3->D0 in pci_enable_device(), - * we lost our configuration and need to restore it to the - * conditions at boot. - */ - pci_restore_state(pdev, NULL); + err = pci_set_mwi(pdev); + if(err < 0) { + printk(ERR_PFX "%s: unable to set MWI\n", pci_name(pdev)); + goto error_out_disable; + } - err = pci_set_dma_mask(pdev, 0xffffffffULL); + err = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if(err < 0) { printk(ERR_PFX "%s: No usable DMA configuration\n", pci_name(pdev)); - goto error_out_dev; + goto error_out_mwi; } /* sanity checks, resource #1 is our mmio area @@ -2323,25 +2329,22 @@ "%s: region #1 not a PCI MMIO resource, aborting\n", pci_name(pdev)); err = -ENODEV; - goto error_out_dev; + goto error_out_mwi; } if(pci_resource_len(pdev, 1) < 128) { printk(ERR_PFX "%s: Invalid PCI MMIO region size, aborting\n", pci_name(pdev)); err = -ENODEV; - goto error_out_dev; + goto error_out_mwi; } err = pci_request_regions(pdev, "typhoon"); if(err < 0) { printk(ERR_PFX "%s: could not request regions\n", pci_name(pdev)); - goto error_out_dev; + goto error_out_mwi; } - pci_set_master(pdev); - pci_set_mwi(pdev); - /* map our MMIO region */ ioaddr = pci_resource_start(pdev, 1); @@ -2366,7 +2369,7 @@ } dev->irq = pdev->irq; - tp = dev->priv; + tp = netdev_priv(dev); tp->shared = (struct typhoon_shared *) shared; tp->shared_dma = shared_dma; tp->pdev = pdev; @@ -2391,6 +2394,11 @@ goto error_out_dma; } + /* Now that we've reset the 3XP and are sure it's not going to + * write all over memory, enable bus mastering. + */ + pci_set_master(pdev); + /* dev->name is not valid until we register, but we need to * use some common routines to initialize the card. So that those * routines print the right name, we keep our oun pointer to the name @@ -2460,11 +2468,11 @@ dev->set_multicast_list = typhoon_set_rx_mode; dev->tx_timeout = typhoon_tx_timeout; dev->poll = typhoon_poll; + dev->ethtool_ops = &typhoon_ethtool_ops; dev->weight = 16; dev->watchdog_timeo = TX_TIMEOUT; dev->get_stats = typhoon_get_stats; dev->set_mac_address = typhoon_set_mac_address; - dev->do_ioctl = typhoon_ioctl; dev->vlan_rx_register = typhoon_vlan_rx_register; dev->vlan_rx_kill_vid = typhoon_vlan_rx_kill_vid; @@ -2527,6 +2535,10 @@ iounmap((void *) ioaddr); error_out_regions: pci_release_regions(pdev); +error_out_mwi: + pci_clear_mwi(pdev); +error_out_disable: + pci_disable_device(pdev); error_out_dev: free_netdev(dev); error_out: @@ -2537,7 +2549,7 @@ typhoon_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct typhoon *tp = (struct typhoon *) (dev->priv); + struct typhoon *tp = netdev_priv(dev); unregister_netdev(dev); pci_set_power_state(pdev, 0); @@ -2547,6 +2559,7 @@ pci_free_consistent(pdev, sizeof(struct typhoon_shared), tp->shared, tp->shared_dma); pci_release_regions(pdev); + pci_clear_mwi(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); free_netdev(dev); From shemminger@osdl.org Fri Sep 17 11:43:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:43:21 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HIhGNT024831 for ; Fri, 17 Sep 2004 11:43:17 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8HIgnv22825; Fri, 17 Sep 2004 11:42:49 -0700 Date: Fri, 17 Sep 2004 11:42:49 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: crash in fib_hash_move Message-Id: <20040917114249.7449b9ff@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9028 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1384 Lines: 36 Current 2.6 tree is crashing on bootup in fib code. Looks like recent FIB changes problem. -------------- Unable to handle kernel paging request at virtual address 00003232 printing eip: *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ext3 jbd DAC960 aic7xxx sd_mod scsi_mod CPU: 5 EIP: 0060:[] Not tainted VLI EFLAGS: 00010206 (2.6.9-rc2) EIP is at fib_hash_move+0x90/0x146 eax: 0000322e ebx: c316b480 ecx: 00000004 edx: f6cc5630 esi: c316b380 edi: f6cc5620 ebp: 00000000 esp: f6e0cd94 ds: 007b es: 007b ss: 0068 Process ifconfig (pid: 1507, threadinfo=f6e0c000 task=f6db0550) Stack: 00000000 00000004 f6cc82e0 00000008 f6cc82e0 00000020 f6cc5620 c0279062 00000020 00000001 00000000 ffffff97 f6e0ce40 f6e0ce90 ffffffea f6e0ce40 c314a980 f6cc6ec0 c027a8cd f6e0ce14 f6e0ce80 00000000 03ccf180 ffff14ac Call Trace: [] fib_create_info+0x98/0x529 [] fn_hash_insert+0xab/0x4d1 [] fib_magic+0x104/0x129 [] fib_add_ifaddr+0x8a/0x12b [] fib_inetaddr_event+0x47/0x53 [] notifier_call_chain+0x17/0x2b [] inet_insert_ifa+0x8e/0x12b [] devinet_ioctl+0x317/0x60e [] inet_ioctl+0x5b/0x8f [] sock_ioctl+0xdb/0x25b [] fget+0x49/0x5e [] sys_ioctl+0xf5/0x24d [] sysenter_past_esp+0x52/0x71 From kumarkr@us.ibm.com Fri Sep 17 11:49:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:49:55 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HInmqu025226 for ; Fri, 17 Sep 2004 11:49:49 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8HInPcs594912; Fri, 17 Sep 2004 14:49:25 -0400 Received: from d03nm132.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8HInOOW184514; Fri, 17 Sep 2004 12:49:25 -0600 In-Reply-To: <20040917114249.7449b9ff@dell_ss3.pdx.osdl.net> Subject: Re: crash in fib_hash_move To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Krishna Kumar Date: Fri, 17 Sep 2004 11:47:00 -0700 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/17/2004 12:49:24 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809" X-archive-position: 9029 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10415 Lines: 273 --0__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809 Content-type: multipart/alternative; Boundary="1__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809" --1__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Probably the same problem checked in today by DM. See "Re: [TRIVIAL] Fi= x recent bug in fib_semantics.c". - KK = Stephen Hemminger = = To Sent by: "David S. Miller" = netdev-bounce@oss = .sgi.com = cc netdev@oss.sgi.com = Subj= ect 09/17/2004 11:42 crash in fib_hash_move = AM = = = = = = Current 2.6 tree is crashing on bootup in fib code. Looks like recent FIB changes problem. -------------- Unable to handle kernel paging request at virtual address 00003232 printing eip: *pde =3D 00000000 Oops: 0002 [#1] PREEMPT SMP Modules linked in: ext3 jbd DAC960 aic7xxx sd_mod scsi_mod CPU: 5 EIP: 0060:[] Not tainted VLI EFLAGS: 00010206 (2.6.9-rc2) EIP is at fib_hash_move+0x90/0x146 eax: 0000322e ebx: c316b480 ecx: 00000004 edx: f6cc5630 esi: c316b380 edi: f6cc5620 ebp: 00000000 esp: f6e0cd94 ds: 007b es: 007b ss: 0068 Process ifconfig (pid: 1507, threadinfo=3Df6e0c000 task=3Df6db0550) Stack: 00000000 00000004 f6cc82e0 00000008 f6cc82e0 00000020 f6cc5620 c0279062 00000020 00000001 00000000 ffffff97 f6e0ce40 f6e0ce90 ffffffea f6e0ce40 c314a980 f6cc6ec0 c027a8cd f6e0ce14 f6e0ce80 00000000 03ccf180 ffff14ac Call Trace: [] fib_create_info+0x98/0x529 [] fn_hash_insert+0xab/0x4d1 [] fib_magic+0x104/0x129 [] fib_add_ifaddr+0x8a/0x12b [] fib_inetaddr_event+0x47/0x53 [] notifier_call_chain+0x17/0x2b [] inet_insert_ifa+0x8e/0x12b [] devinet_ioctl+0x317/0x60e [] inet_ioctl+0x5b/0x8f [] sock_ioctl+0xdb/0x25b [] fget+0x49/0x5e [] sys_ioctl+0xf5/0x24d [] sysenter_past_esp+0x52/0x71 = --1__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Probably the same problem checked in today by DM. See "Re: [TRI= VIAL] Fix recent bug in fib_semantics.c".

- KK

3D"InactiveStephen Hemminger <shemminger@osdl.org&g= t;


=
          Stephen Hemminger <shemminger@osdl.org>
          Sent by: netdev-bounce@oss.sgi.com

          09/17/2004 11:42 AM

 =
3D""
To
3D""
"David S. Miller" <davem@redhat.com>
3D""
cc
3D""
netdev@oss.sgi.com
3D""
Subject
3D""
crash in fib_hash_move
=3D""3D""<= /td>

Current 2.6 tree is crashing on bootup in fib code.
Looks like recent FIB changes problem.

--------------

Unable to handle kernel paging request at virtual address 00003232
printing eip:
*pde =3D 00000000
Oops: 0002 [#1]
PREEMPT SMP
Modules linked in: ext3 jbd DAC960 aic7xxx sd_mod scsi_mod
CPU:    5
EIP:    0060:    Not tainted VLI
EFLAGS: 00010206   (2.6.9-rc2)
EIP is at fib_hash_move+0x90/0x146
eax: 0000322e   ebx: c316b480   ecx: 00000004   edx: f6c= c5630
esi: c316b380   edi: f6cc5620   ebp: 00000000   esp: f6e= 0cd94
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1507, threadinfo=3Df6e0c000 task=3Df6db0550)
= Stack: 00000000 00000004 f6cc82e0 00000008 f6cc82e0 00000020 f6cc5620 c= 0279062
      00000020 00000001 00000000 ffffff97 f6e0ce40 f6e0= ce90 ffffffea f6e0ce40
      c314a980 f6cc6ec0 c027a8cd f6e0ce14 f6e0ce80 0000= 0000 03ccf180 ffff14ac
Call Trace:
fib_create_info+0x98/0x529
fn_hash_insert+0xab/0x4d1
fib_magic+0x104/0x129
fib_add_ifaddr+0x8a/0x12b
fib_inetaddr_event+0x47/0x53
notifier_call_chain+0x17/0x2b
inet_insert_ifa+0x8e/0x12b
devinet_ioctl+0x317/0x60e
inet_ioctl+0x5b/0x8f
sock_ioctl+0xdb/0x25b
fget+0x49/0x5e
sys_ioctl+0xf5/0x24d
sysenter_past_esp+0x52/0x71


= --1__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809-- --0__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=07BBE581DFF498098f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809 Content-type: image/gif; name="pic00286.gif" Content-Disposition: inline; filename="pic00286.gif" Content-ID: <20__=07BBE581DFF498098f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <30__=07BBE581DFF498098f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBE581DFF498098f9e8a93df938690918c07BBE581DFF49809-- From garzik@havoc.gtf.org Fri Sep 17 11:51:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:51:30 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HIpNtF025446 for ; Fri, 17 Sep 2004 11:51:26 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id E1D2378C4; Fri, 17 Sep 2004 14:51:06 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8HIp645022846; Fri, 17 Sep 2004 14:51:06 -0400 Date: Fri, 17 Sep 2004 14:51:06 -0400 From: Jeff Garzik To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: crash in fib_hash_move Message-ID: <20040917185106.GA22810@havoc.gtf.org> References: <20040917114249.7449b9ff@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917114249.7449b9ff@dell_ss3.pdx.osdl.net> User-Agent: Mutt/1.4.1i X-archive-position: 9030 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 264 Lines: 11 On Fri, Sep 17, 2004 at 11:42:49AM -0700, Stephen Hemminger wrote: > Current 2.6 tree is crashing on bootup in fib code. > Looks like recent FIB changes problem. Yeah, David Gibson already posted a fix, see "[TRIVIAL] Fix recent bug in fib_semantics.c" Jeff From jgarzik@pobox.com Fri Sep 17 11:52:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 11:52:16 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HIqAHL025615 for ; Fri, 17 Sep 2004 11:52:10 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C8Npu-00035Q-Ue; Fri, 17 Sep 2004 19:51:59 +0100 Message-ID: <414B3242.4040802@pobox.com> Date: Fri, 17 Sep 2004 14:51:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Dillow CC: linux-net@vger.kernel.org, Netdev Subject: Re: [PATCH 2.6-bk] [RESEND] typhoon: PCI cleanups and ethtool_ops conversion References: <1095446240.21058.2.camel@ori.thedillows.org> In-Reply-To: <1095446240.21058.2.camel@ori.thedillows.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9031 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 199 Lines: 12 David Dillow wrote: > Jeff, please do a > > bk pull http://typhoon.bkbits.net/typhoon-2.5 > > This will update the following files: applied it last night :) bk://gkernel.bkbits.net/netdev-2.6 From davem@redhat.com Fri Sep 17 12:39:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 12:39:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HJdcHk032606 for ; Fri, 17 Sep 2004 12:39:38 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8HJdOC6025040; Fri, 17 Sep 2004 15:39:24 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8HJdJr27644; Fri, 17 Sep 2004 15:39:19 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8HJdBxu027965; Fri, 17 Sep 2004 15:39:12 -0400 Date: Fri, 17 Sep 2004 12:36:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: crash in fib_hash_move Message-Id: <20040917123614.282a55a1.davem@redhat.com> In-Reply-To: <20040917114249.7449b9ff@dell_ss3.pdx.osdl.net> References: <20040917114249.7449b9ff@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9032 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 2767 Lines: 73 On Fri, 17 Sep 2004 11:42:49 -0700 Stephen Hemminger wrote: > Current 2.6 tree is crashing on bootup in fib code. > Looks like recent FIB changes problem. Missing memset()'s on the newly allocated hash tables, fixed by the following which I just pused to Linus: Return-Path: Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i8H6XIL3028885 for ; Fri, 17 Sep 2004 02:33:18 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8H6XPr27780 for ; Fri, 17 Sep 2004 02:33:25 -0400 Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8H6XOij016918 for ; Fri, 17 Sep 2004 02:33:24 -0400 Received: by ozlabs.org (Postfix, from userid 1007) id B10E92BD6A; Fri, 17 Sep 2004 16:33:17 +1000 (EST) Date: Fri, 17 Sep 2004 16:20:42 +1000 From: David Gibson To: Andrew Morton Cc: David Miller , trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [TRIVIAL] Fix recent bug in fib_semantics.c Message-ID: <20040917062042.GE6523@zax> Mail-Followup-To: David Gibson , Andrew Morton , David Miller , trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-RedHat-Spam-Score: 0 Status: Andrew, please apply: When fib_create_info() allocates new hash tables, it neglects to initialize them. This leads to an oops during boot on at least machine I use. This patch addresses the problem. Signed-off-by: David Gibson Index: working-2.6/net/ipv4/fib_semantics.c =================================================================== --- working-2.6.orig/net/ipv4/fib_semantics.c 2004-09-17 09:20:04.000000000 +1000 +++ working-2.6/net/ipv4/fib_semantics.c 2004-09-17 16:24:42.634638304 +1000 @@ -604,8 +604,12 @@ if (!new_info_hash || !new_laddrhash) { fib_hash_free(new_info_hash, bytes); fib_hash_free(new_laddrhash, bytes); - } else + } else { + memset(new_info_hash, 0, bytes); + memset(new_laddrhash, 0, bytes); + fib_hash_move(new_info_hash, new_laddrhash, new_size); + } if (!fib_hash_size) goto failure; -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From Valdis.Kletnieks@vt.edu Fri Sep 17 13:27:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 13:27:59 -0700 (PDT) Received: from turing-police.cc.vt.edu (IDENT:root@turing-police.cc.vt.edu [128.173.14.107]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HKRmwB017574 for ; Fri, 17 Sep 2004 13:27:48 -0700 Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.13.1/8.13.1) with ESMTP id i8HKRVwY005444; Fri, 17 Sep 2004 16:27:32 -0400 Message-Id: <200409172027.i8HKRVwY005444@turing-police.cc.vt.edu> X-Mailer: exmh version 2.7.1 07/26/2004 with nmh-1.1-RC3 To: Eric Mudama Cc: David Stevens , Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design In-Reply-To: Your message of "Fri, 17 Sep 2004 00:46:59 MDT." <311601c90409162346184649eb@mail.gmail.com> From: Valdis.Kletnieks@vt.edu References: <4148991B.9050200@pobox.com> <311601c90409162346184649eb@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-239910029P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 17 Sep 2004 16:27:31 -0400 X-archive-position: 9033 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: netdev Content-Length: 1221 Lines: 34 --==_Exmh_-239910029P Content-Type: text/plain; charset=us-ascii On Fri, 17 Sep 2004 00:46:59 MDT, Eric Mudama said: > On Wed, 15 Sep 2004 14:11:04 -0600, David Stevens wrot e: > > Why don't we off-load filesystems to disks instead? > > Disks have had file systems on them since close to the beginning... No, he means "offload the processing of the filesystem to the disk itself". IBM's MVS systems basically did that - it used the disk's "Search Key" I/O opcodes to basically get the equivalent of doing namei() out on the disk itself (it did this for system catalog and PDS directory searches from the beginning, and added 'indexed VTOC' support in the mid-80s). So you'd send out a CCW (channel command word) stream that basically said "Find me the dataset USER3.ACCTING.TESTJOBS", and when the I/O completed, you'd have the DSCB (the moral equiv of an inode) ready to go. --==_Exmh_-239910029P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBS0izcC3lWbTT17ARAoKMAJ4pA1BjsPb0sbxLDbLKM9jvox5srACeMV0V ZMot5U1QnkpacHYr8pIWeJM= =zjf/ -----END PGP SIGNATURE----- --==_Exmh_-239910029P-- From david.lang@digitalinsight.com Fri Sep 17 13:36:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 13:36:54 -0700 (PDT) Received: from warden2.diginsite.com ([209.195.52.120]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8HKaj0e017998 for ; Fri, 17 Sep 2004 13:36:46 -0700 Received: from atlims01.diginsite.com by warden2.diginsite.com via smtpd (for oss.sgi.com [192.48.159.27]) with SMTP; Fri, 17 Sep 2004 13:31:09 -0700 Received: by atlexc02.diginsite.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Sep 2004 16:36:19 -0400 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvexc00.digitalinsight.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SYHQ0N6Q; Fri, 17 Sep 2004 13:34:46 -0700 From: David Lang To: Valdis.Kletnieks@vt.edu Cc: Eric Mudama , David Stevens , Netdev , leonid.grossman@s2io.com, Linux Kernel Date: Fri, 17 Sep 2004 13:36:14 -0700 (PDT) X-X-Sender: dlang@dlang.diginsite.com Subject: Re: The ultimate TOE design In-Reply-To: <200409172027.i8HKRVwY005444@turing-police.cc.vt.edu> Message-ID: References: <4148991B.9050200@pobox.com> <311601c90409162346184649eb@mail.gmail.com> <200409172027.i8HKRVwY005444@turing-police.cc.vt.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9034 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david.lang@digitalinsight.com Precedence: bulk X-list: netdev Content-Length: 1851 Lines: 40 actually the sector based access that is made to modern drives is a very primitive filesystem. if you go back to the days of the MFM and RLL drives you had the computer sending the raw bitstreams to the drives, but with SCSI and IDE this stopped and you instead a higher level logical block to the drive and it deals with the details of getting it to and from the platter. David Lang On Fri, 17 Sep 2004 Valdis.Kletnieks@vt.edu wrote: > Date: Fri, 17 Sep 2004 16:27:31 -0400 > From: Valdis.Kletnieks@vt.edu > To: Eric Mudama > Cc: David Stevens , Netdev , > leonid.grossman@s2io.com, Linux Kernel > Subject: Re: The ultimate TOE design > > On Fri, 17 Sep 2004 00:46:59 MDT, Eric Mudama said: >> On Wed, 15 Sep 2004 14:11:04 -0600, David Stevens wrot > e: >>> Why don't we off-load filesystems to disks instead? >> >> Disks have had file systems on them since close to the beginning... > > No, he means "offload the processing of the filesystem to the disk itself". > > IBM's MVS systems basically did that - it used the disk's "Search Key" I/O > opcodes to basically get the equivalent of doing namei() out on the disk itself > (it did this for system catalog and PDS directory searches from the beginning, > and added 'indexed VTOC' support in the mid-80s). So you'd send out a CCW > (channel command word) stream that basically said "Find me the dataset > USER3.ACCTING.TESTJOBS", and when the I/O completed, you'd have the DSCB (the > moral equiv of an inode) ready to go. > > -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From davem@davemloft.net Fri Sep 17 15:39:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 15:39:17 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HMdBQB020561 for ; Fri, 17 Sep 2004 15:39:11 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8RKK-0006Hi-00; Fri, 17 Sep 2004 15:35:36 -0700 Date: Fri, 17 Sep 2004 15:35:36 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent Message-Id: <20040917153536.6acec52e.davem@davemloft.net> In-Reply-To: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> References: <20040917.205038.61628907.yoshfuji@linux-ipv6.org> <20040917.231127.114842301.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8HMdBQB020561 X-archive-position: 9035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4940 Lines: 162 On Fri, 17 Sep 2004 23:11:27 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > In article (at Fri, 17 Sep 2004 22:40:52 +1000), Herbert Xu says: > > > Please provide ip_route_output_key() as an inline wrapper around > > ip_route_output_flow() so that its users don't have to change. > > No. Because I've succesfully changed all users (AFAIK), > there's no need to keep it. > And, I believe the name "ip_route_output_key()" itself was the bug. Herbert is right this time Yoshifuji-san. Now all these call sites must pass 2 more parameters when calling ip_route_output_flow() than when they called ip_route_output_key() with only 2 parameters. Let's redo this first patch, putting ip_route_output_key() into net/ipv4/route.c, and have that function pass the "NULL, 0" final 2 args to ip_route_output_flow(). I see no problem with ip_route_output_key(), you merely made a textual replacement that made no improvement of any kind as far as I can see. Instead it made the generated code larger for each of those call sites you changed (needed to pass in the extra NULL, 0 arguments). All this was merely so that you only needed to change one function in your second changeset, but you chould have achieved that by simply changing ip_route_output_key() into: int ip_route_output_key(struct rtable **rp, struct flowi *flp) { return ip_route_output_flow(rp, flp, NULL, 0); } And you therefore could have combined both efforts into one simple changeset looking like this, which is what I'm checking into my tree: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/17 15:17:53-07:00 davem@nuts.davemloft.net # [XFRM] make xfrm_lookup() fully af-independent. # # Simplified from 2 patches by Hideaki YOSHIFUJI # # # Signed-off-by: David S. Miller # # net/xfrm/xfrm_policy.c # 2004/09/17 15:16:56-07:00 davem@nuts.davemloft.net +6 -20 # [XFRM] make xfrm_lookup() fully af-independent. # # net/ipv4/route.c # 2004/09/17 15:16:56-07:00 davem@nuts.davemloft.net +13 -8 # [XFRM] make xfrm_lookup() fully af-independent. # diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c 2004-09-17 15:18:14 -07:00 +++ b/net/ipv4/route.c 2004-09-17 15:18:14 -07:00 @@ -2206,22 +2206,27 @@ return ip_route_output_slow(rp, flp); } -int ip_route_output_key(struct rtable **rp, struct flowi *flp) +int ip_route_output_flow(struct rtable **rp, struct flowi *flp, struct sock *sk, int flags) { int err; if ((err = __ip_route_output_key(rp, flp)) != 0) return err; - return flp->proto ? xfrm_lookup((struct dst_entry**)rp, flp, NULL, 0) : 0; + + if (flp->proto) { + if (!flp->fl4_src) + flp->fl4_src = (*rp)->rt_src; + if (!flp->fl4_dst) + flp->fl4_dst = (*rp)->rt_dst; + return xfrm_lookup((struct dst_entry **)rp, flp, sk, flags); + } + + return 0; } -int ip_route_output_flow(struct rtable **rp, struct flowi *flp, struct sock *sk, int flags) +int ip_route_output_key(struct rtable **rp, struct flowi *flp) { - int err; - - if ((err = __ip_route_output_key(rp, flp)) != 0) - return err; - return flp->proto ? xfrm_lookup((struct dst_entry**)rp, flp, sk, flags) : 0; + return ip_route_output_flow(rp, flp, NULL, 0); } static int rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, diff -Nru a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c --- a/net/xfrm/xfrm_policy.c 2004-09-17 15:18:14 -07:00 +++ b/net/xfrm/xfrm_policy.c 2004-09-17 15:18:14 -07:00 @@ -711,25 +711,11 @@ { struct xfrm_policy *policy; struct xfrm_state *xfrm[XFRM_MAX_DEPTH]; - struct rtable *rt = (struct rtable*)*dst_p; - struct dst_entry *dst; + struct dst_entry *dst, *dst_orig = *dst_p; int nx = 0; int err; u32 genid; - u16 family = (*dst_p)->ops->family; - - switch (family) { - case AF_INET: - if (!fl->fl4_src) - fl->fl4_src = rt->rt_src; - if (!fl->fl4_dst) - fl->fl4_dst = rt->rt_dst; - case AF_INET6: - /* Still not clear... */ - default: - /* nothing */; - } - + u16 family = dst_orig->ops->family; restart: genid = atomic_read(&flow_cache_genid); policy = NULL; @@ -738,7 +724,7 @@ if (!policy) { /* To accelerate a bit... */ - if ((rt->u.dst.flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT]) + if ((dst_orig->flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT]) return 0; policy = flow_cache_lookup(fl, family, @@ -813,7 +799,7 @@ return 0; } - dst = &rt->u.dst; + dst = dst_orig; err = xfrm_bundle_create(policy, xfrm, nx, fl, &dst, family); if (unlikely(err)) { @@ -843,12 +829,12 @@ write_unlock_bh(&policy->lock); } *dst_p = dst; - ip_rt_put(rt); + dst_release(dst_orig); xfrm_pol_put(policy); return 0; error: - ip_rt_put(rt); + dst_release(dst_orig); xfrm_pol_put(policy); *dst_p = NULL; return err; From davem@davemloft.net Fri Sep 17 15:49:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 15:49:46 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HMndup021076 for ; Fri, 17 Sep 2004 15:49:41 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8RUh-0006Ix-00; Fri, 17 Sep 2004 15:46:19 -0700 Date: Fri, 17 Sep 2004 15:46:19 -0700 From: "David S. Miller" To: pavlic@de.ibm.com Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] introducing new net device feature NETIF_F_MC_ALL Message-Id: <20040917154619.5e384c67.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9036 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1264 Lines: 45 Looks mostly fine Frank. But why don't we save you some work, we have the IP address handy therefore it's kind of silly for you to have to look it up again. Let's create a new netdev callback, something like: void (*mc_change)(struct netdev *dev, void *addr, int family, int add); Then net/ipv4/igmp.c can do something like: static void ip_mc_filter_add(struct in_device *in_dev, u32 addr) { char buf[MAX_ADDR_LEN]; struct net_device *dev = in_dev->dev; /* Checking for IFF_MULTICAST here is WRONG-WRONG-WRONG. We will get multicast token leakage, when IFF_MULTICAST is changed. This check should be done in dev->set_multicast_list routine. Something sort of: if (dev->mc_list && dev->flags&IFF_MULTICAST) { do it; } --ANK */ if (arp_mc_map(addr, buf, dev, 0) == 0) { dev_mc_add(dev,buf,dev->addr_len,0); if (dev->mc_change) dev->mc_change(dev, &addr, AF_INET, 1); } } static void ip_mc_filter_del(struct in_device *in_dev, u32 addr) { char buf[MAX_ADDR_LEN]; struct net_device *dev = in_dev->dev; if (arp_mc_map(addr, buf, dev, 0) == 0) { dev_mc_delete(dev,buf,dev->addr_len,0); if (dev->mc_change) dev->mc_change(dev, &addr, AF_INET, 0); } } And similarly for the other dev_mc_{add,delete}() call sites. From laforge@netfilter.org Fri Sep 17 16:08:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 16:08:24 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HN8JlK021776 for ; Fri, 17 Sep 2004 16:08:20 -0700 Received: from dsl-082-082-102-182.arcor-ip.net ([82.82.102.182] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C8Rpm-0008Ig-Dc; Sat, 18 Sep 2004 01:08:06 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C8Rpj-00010T-U7; Sat, 18 Sep 2004 01:08:03 +0200 Date: Sat, 18 Sep 2004 01:08:03 +0200 From: Harald Welte To: netdev@oss.sgi.com Cc: usagi-users@linux-ipv6.org Subject: 2.6.8.1 IPv6 Routing Problem Message-ID: <20040917230803.GJ2678@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8KmZJhJMEENkOiL3" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9037 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 5675 Lines: 128 --8KmZJhJMEENkOiL3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I'm experiencing some strange problems on a 2.6.8.1 vanilla kernel. I tried to reproduce it with a minimal system: 1) address configuration (just loopback, link-local and one global) /proc/sys/net/ipv6/conf # ip -6 addr show 1: eth0: mtu 1500 qlen 1000 inet6 3ffe:400:900:3001::2/64 scope global=20 valid_lft forever preferred_lft forever inet6 fe80::20d:b9ff:fe00:a88/64 scope link=20 valid_lft forever preferred_lft forever 3: lo: mtu 16436=20 inet6 ::1/128 scope host=20 valid_lft forever preferred_lft forever 2) routing table: /proc/sys/net/ipv6/conf # ip -6 route show 3ffe:400:900:3001::/64 dev eth0 metric 256=20 fe80::/64 dev eth0 metric 256=20 ff00::/8 dev eth0 metric 256=20 default dev eth0 metric 256=20 unreachable default dev lo metric -1 error -101 3) ping to localhost: (intermixed with a 'ip6tables -A OUTPUT -j LOG' and '-A INPUT -j LOG' rules for diagnostics). /proc/sys/net/ipv6/conf # ping6 ::1 PING ::1 (::1): ou IN=3D OUT=3Dlo 56 data bytes SRC=3D0000:0000:0000:0000:0000:0000:0000:0001 DST=3D0000:0000:0000:0000:000= 0:0000:0000:0001 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL=3D0 PROTO=3DICMPv6 = TYPE=3D128 CODE=3D0 ID=3D27911 SEQ=3D0=20 in IN=3Dlo OUT=3D MAC=3D00:00:00:00:00:00:00:00:00:00:00:00:86:dd SRC=3D000= 0:0000:0000:0000:0000:0000:0000:0001 DST=3D0000:0000:0000:0000:0000:0000:00= 00:0001 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL=3D0 PROTO=3DICMPv6 TYPE=3D12= 8 CODE=3D0 ID=3D27911 SEQ=3D0=20 ou IN=3D OUT=3Dlo SRC=3D0000:0000:0000:0000:0000:0000:0000:0001 DST=3D0000:= 0000:0000:0000:0000:0000:0000:0001 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D129 CODE=3D0 ID=3D27911 SEQ=3D0=20 in IN=3Dlo OUT=3D MAC=3D00:00:00:00:00:00:00:00:00:00:00:00:86:dd SRC=3D000= 0:0000:0000:0000:0000:0000:0000:0001 DST=3D0000:0000:0000:0000:0000:0000:00= 00:0001 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL=3D0 PROTO=3DICMPv6 TYPE=3D12= 9 CODE=3D0 ID=3D27911 SEQ=3D0=20 64 bytes from ::1: icmp6_seq=3D0 ttl=3D64 time=3D246.2 ms =20 4) ping to global address /proc/sys/net/ipv6/conf # ping6 3ffe:400:900:3001::2 PING 3ffe:400:90ou IN=3D OUT=3Deth0 0:3001::2 (3ffe:SRC=3D3ffe:0400:0900:30= 01:0000:0000:0000:0002 400:900:3001::2)DST=3D3ffe:0400:0900:3001:0000:0000:= 0000:0002 : 56 datLEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL=3D0=20 PROTO=3DICMPv6 TYPE=3D128 CODE=3D0 ID=3D= 28167 SEQ=3D0=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3Dff0= 2:0000:0000:0000:0000:0001:ff00:0002 LEN=3D72 TC=3D0 HOPLIMIT=3D255 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D135 CODE=3D0=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3Dff0= 2:0000:0000:0000:0000:0001:ff00:0002 LEN=3D72 TC=3D0 HOPLIMIT=3D255 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D135 CODE=3D0=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3D3ff= e:0400:0900:3001:0000:0000:0000:0002 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D128 CODE=3D0 ID=3D28167 SEQ=3D256=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3Dff0= 2:0000:0000:0000:0000:0001:ff00:0002 LEN=3D72 TC=3D0 HOPLIMIT=3D255 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D135 CODE=3D0=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3D3ff= e:0400:0900:3001:0000:0000:0000:0002 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D128 CODE=3D0 ID=3D28167 SEQ=3D512=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3D3ff= e:0400:0900:3001:0000:0000:0000:0002 LEN=3D152 TC=3D0 HOPLIMIT=3D64 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D1 CODE=3D3 [SRC=3D3ffe:0400:0900:3001:0000:0000:= 0000:0002 DST=3D3ffe:0400:0900:3001:0000:0000:0000:0002 LEN=3D104 TC=3D0 HO= PLIMIT=3D64 FLOWLBL=3D0 PROTO=3DICMPv6 TYPE=3D128 CODE=3D0 ID=3D28167 SEQ= =3D0 ]=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3Dff0= 2:0000:0000:0000:0000:0001:ff00:0002 LEN=3D72 TC=3D0 HOPLIMIT=3D255 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D135 CODE=3D0=20 ou IN=3D OUT=3Deth0 SRC=3D3ffe:0400:0900:3001:0000:0000:0000:0002 DST=3D3ff= e:0400:0900:3001:0000:0000:0000:0002 LEN=3D104 TC=3D0 HOPLIMIT=3D64 FLOWLBL= =3D0 PROTO=3DICMPv6 TYPE=3D128 CODE=3D0 ID=3D28167 SEQ=3D768=20 =20 --- 3ffe:400:900:3001::2 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss Apparently the node tries to do neighbour solicitation on itself, and then even sends an ICMPv6 destination unreachable to itself, all over the ethernet device ?!? Can anybody please explain what's going on? Thanks! --=20 - Harald Welte http://www.netfilter.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --8KmZJhJMEENkOiL3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBS25TXaXGVTD0i/8RAuo9AJ9BK1HlGkKdgXgvVF1mzSIZdOTvHACgmjJK XVZPvxaFLX/Wt8vmnInkDTo= =3jUj -----END PGP SIGNATURE----- --8KmZJhJMEENkOiL3-- From tony.p.lee@gmail.com Fri Sep 17 16:21:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 16:21:16 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HNL48J025673 for ; Fri, 17 Sep 2004 16:21:04 -0700 Received: by mproxy.gmail.com with SMTP id 73so110150rnk for ; Fri, 17 Sep 2004 16:20:53 -0700 (PDT) Received: by 10.38.13.52 with SMTP id 52mr342127rnm; Fri, 17 Sep 2004 16:20:53 -0700 (PDT) Received: by 10.38.165.50 with HTTP; Fri, 17 Sep 2004 16:20:53 -0700 (PDT) Message-ID: <470b6397040917162033bfa880@mail.gmail.com> Date: Fri, 17 Sep 2004 16:20:53 -0700 From: Tony Lee Reply-To: Tony Lee To: David Lang Subject: Re: The ultimate TOE design Cc: valdis.kletnieks@vt.edu, Eric Mudama , David Stevens , Netdev , leonid.grossman@s2io.com, Linux Kernel In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4148991B.9050200@pobox.com> <311601c90409162346184649eb@mail.gmail.com> <200409172027.i8HKRVwY005444@turing-police.cc.vt.edu> X-archive-position: 9038 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tony.p.lee@gmail.com Precedence: bulk X-list: netdev Content-Length: 1244 Lines: 36 On Fri, 17 Sep 2004 13:36:14 -0700 (PDT), David Lang wrote: > actually the sector based access that is made to modern drives is a very > primitive filesystem. if you go back to the days of the MFM and RLL drives > you had the computer sending the raw bitstreams to the drives, but with > SCSI and IDE this stopped and you instead a higher level logical block to > the drive and it deals with the details of getting it to and from the > platter. > > David Lang > Maybe next evolutionary step is to put VFS layer directory on top of RDMA -> PCI Express/Latest serial IO, etc. Similar to access file thru NFS/SMB just on a faster standardize (RDMA) transport. On the networking front, instead of TOE, it should be services offload, similar to web load balancer. Offload service base on src/dest addr port proto (tcp/udp). NSO (Network service offload.) - kind of like Apache's reverse proxy with URL rewrite, but maybe for other applications. Question for Leonid of S2io.com: Your company has an interesting card. I think it must have some kind of embedded CPU. Care to tell us what kind of CPU are they? -- -Tony Having a lot of fun with Xilinx Virtex Pro II reconfigurable HW + ppc + Linux From leonid.grossman@s2io.com Fri Sep 17 16:36:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 16:36:56 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HNajca026210 for ; Fri, 17 Sep 2004 16:36:46 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8HNaOje026071; Fri, 17 Sep 2004 19:36:24 -0400 (EDT) Received: from lgt40 ([10.16.16.152]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8HNaL39020193; Fri, 17 Sep 2004 19:36:22 -0400 (EDT) Message-Id: <200409172336.i8HNaL39020193@guinness.s2io.com> From: "Leonid Grossman" To: "'Tony Lee'" , "'David Lang'" Cc: , "'Eric Mudama'" , "'David Stevens'" , "'Netdev'" , "'Linux Kernel'" Subject: RE: The ultimate TOE design Date: Fri, 17 Sep 2004 16:36:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSdDQGWiE+zdlnGRYuf5/JqZtkuJQAAJufA In-Reply-To: <470b6397040917162033bfa880@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 9039 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 512 Lines: 24 > -----Original Message----- > From: Tony Lee [mailto:tony.p.lee@gmail.com] > Sent: Friday, September 17, 2004 4:21 PM Skipped... > Question for Leonid of S2io.com: Your company has an > interesting card. > I think it must have some kind of embedded CPU. Care to tell > us what kind of CPU are they? Hi Tony, For 10GbE card, we designed our own ASIC - embedded CPUs don't cut it at 10GbE... Leonid > -- > -Tony > Having a lot of fun with Xilinx Virtex Pro II reconfigurable > HW + ppc + Linux > From yoshfuji@linux-ipv6.org Fri Sep 17 16:43:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 16:43:13 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HNh7Pl026558 for ; Fri, 17 Sep 2004 16:43:08 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id A3AB933CE5; Sat, 18 Sep 2004 08:43:04 +0900 (JST) Date: Sat, 18 Sep 2004 08:43:04 +0900 (JST) Message-Id: <20040918.084304.75142669.yoshfuji@linux-ipv6.org> To: laforge@netfilter.org Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040917230803.GJ2678@sunbeam.de.gnumonks.org> References: <20040917230803.GJ2678@sunbeam.de.gnumonks.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9040 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 488 Lines: 16 In article <20040917230803.GJ2678@sunbeam.de.gnumonks.org> (at Sat, 18 Sep 2004 01:08:03 +0200), Harald Welte says: > I'm experiencing some strange problems on a 2.6.8.1 vanilla kernel. I > tried to reproduce it with a minimal system: : > (intermixed with a 'ip6tables -A OUTPUT -j LOG' and '-A INPUT -j LOG' > rules for diagnostics). It is not minimum with ip6tables. :-) Anyway, please try the latest bk tree. There are may fixes in it. Thanks. --yoshfuji From yoshfuji@linux-ipv6.org Fri Sep 17 16:50:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 16:50:12 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8HNo6pO026938 for ; Fri, 17 Sep 2004 16:50:07 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EC79733CE5; Sat, 18 Sep 2004 08:50:03 +0900 (JST) Date: Sat, 18 Sep 2004 08:50:03 +0900 (JST) Message-Id: <20040918.085003.77842779.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [XFRM] Make XFRM core subsystem af-independent From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040917153536.6acec52e.davem@davemloft.net> References: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> <20040917153536.6acec52e.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1562 Lines: 45 Hello. In article <20040917153536.6acec52e.davem@davemloft.net> (at Fri, 17 Sep 2004 15:35:36 -0700), "David S. Miller" says: > Now all these call sites must pass 2 more parameters when > calling ip_route_output_flow() than when they called > ip_route_output_key() with only 2 parameters. Okay, let me explain. Honestly speaking, I had (at least) 4 options. 1. change two functions (_key and _flow) - maintenancability issues 2. David's one - maintenancability will be improved - maintains exported symbols for binary-only modules. - more function call and more stack usage. 3. inlined __ip_route_output_flow() + ip_route_output_flow(), ip_route_output_key - maintenancability will be improved - breaks binary-only modules. - code size. 4. migrate completely (my one) - maintenancability will be improved - breaks binary-only modules. - best stack usage, minimum function call, code size. - changes more places. > Let's redo this first patch, putting ip_route_output_key() > into net/ipv4/route.c, and have that function pass the > "NULL, 0" final 2 args to ip_route_output_flow(). This increases function calls and uses more stack. It seemd downgrade to me. This is the reason I did not make such patch. > And you therefore could have combined both efforts into > one simple changeset looking like this, which is what I'm > checking into my tree: THANK YOU. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@davemloft.net Fri Sep 17 17:09:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:09:41 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I09Z81027574 for ; Fri, 17 Sep 2004 17:09:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8Sjv-0006Mz-00; Fri, 17 Sep 2004 17:06:07 -0700 Date: Fri, 17 Sep 2004 17:06:07 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent Message-Id: <20040917170607.2e96b58a.davem@davemloft.net> In-Reply-To: <20040918.085003.77842779.yoshfuji@linux-ipv6.org> References: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> <20040917153536.6acec52e.davem@davemloft.net> <20040918.085003.77842779.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8I09Z81027574 X-archive-position: 9042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 769 Lines: 29 On Sat, 18 Sep 2004 08:50:03 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > 2. David's one > - maintenancability will be improved > - maintains exported symbols for binary-only modules. > - more function call and more stack usage. Compiler is smarter than you think :-) The whole stack frame is eliminated, because gcc optimizes it away using tail-call optimizations. Look at the assembler output for net/ipv4/route.c:ip_route_output_key() after applying my changes. On sparc64 it looks like this: ip_route_output_key: mov 0, %o2 mov 0, %o3 or %o7, %g0, %g1 call ip_route_output_flow, 0 or %g1, %g0, %o7 No stack frame allocated at all, it basically amounts to a branch and clearing two argument registers. From herbert@gondor.apana.org.au Fri Sep 17 17:11:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:11:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0B64a027829 for ; Fri, 17 Sep 2004 17:11:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8SoQ-0004TH-00; Sat, 18 Sep 2004 10:10:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8SoO-0006qX-00; Sat, 18 Sep 2004 10:10:44 +1000 Date: Sat, 18 Sep 2004 10:10:44 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent Message-ID: <20040918001044.GA24235@gondor.apana.org.au> References: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> <20040917153536.6acec52e.davem@davemloft.net> <20040918.085003.77842779.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040918.085003.77842779.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1250 Lines: 36 On Sat, Sep 18, 2004 at 08:50:03AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > 3. inlined __ip_route_output_flow() + ip_route_output_flow(), ip_route_output_key > - maintenancability will be improved > - breaks binary-only modules. > - code size. > 4. migrate completely (my one) > - maintenancability will be improved > - breaks binary-only modules. > - best stack usage, minimum function call, code size. > - changes more places. You missed the more obvious version of 3: 5. inline ip_route_output_key() only That is exactly the same as 4 except that it doesn't cause ripple effects all over the place. However, I really don't think 16 bytes of stack usage is anything to write home about :) Actually, there is a solution to that as well: 6. Add an inline version of __ip_route_output_flow() in route.c and get ip_route_output_flow/ip_route_output_key to use that. It'll generate code slightly bigger than 2 but is vastly smaller than 4. Otherwise it has all the advantages of 2 and 4. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Sep 17 17:12:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:12:41 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0CaqD028318 for ; Fri, 17 Sep 2004 17:12:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8Spt-0004VL-00; Sat, 18 Sep 2004 10:12:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8Sps-0006r5-00; Sat, 18 Sep 2004 10:12:16 +1000 Date: Sat, 18 Sep 2004 10:12:16 +1000 To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent Message-ID: <20040918001216.GB24235@gondor.apana.org.au> References: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> <20040917153536.6acec52e.davem@davemloft.net> <20040918.085003.77842779.yoshfuji@linux-ipv6.org> <20040917170607.2e96b58a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040917170607.2e96b58a.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 470 Lines: 15 On Fri, Sep 17, 2004 at 05:06:07PM -0700, David S. Miller wrote: > > Compiler is smarter than you think :-) Sparc bigots :) Unfortunately it can't do that on architectures where the arguments are pushed onto the stack in reverse order, i.e., i386. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Fri Sep 17 17:16:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:16:20 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0GEd0028675 for ; Fri, 17 Sep 2004 17:16:14 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 943E733CE5; Sat, 18 Sep 2004 09:16:11 +0900 (JST) Date: Sat, 18 Sep 2004 09:16:11 +0900 (JST) Message-Id: <20040918.091611.13449142.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040917170607.2e96b58a.davem@davemloft.net> References: <20040917153536.6acec52e.davem@davemloft.net> <20040918.085003.77842779.yoshfuji@linux-ipv6.org> <20040917170607.2e96b58a.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9045 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 597 Lines: 17 In article <20040917170607.2e96b58a.davem@davemloft.net> (at Fri, 17 Sep 2004 17:06:07 -0700), "David S. Miller" says: > > 2. David's one > > - maintenancability will be improved > > - maintains exported symbols for binary-only modules. > > - more function call and more stack usage. > > Compiler is smarter than you think :-) > > The whole stack frame is eliminated, because gcc > optimizes it away using tail-call optimizations. Okay, thank you for explanation. I'm not sure (and have some doubt) on i386, but I am now smarter than before. :-) --yoshfuji From jonsmirl@gmail.com Fri Sep 17 17:22:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:22:12 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0M3a1029140 for ; Fri, 17 Sep 2004 17:22:04 -0700 Received: by mproxy.gmail.com with SMTP id 77so185594rnk for ; Fri, 17 Sep 2004 17:21:53 -0700 (PDT) Received: by 10.38.171.66 with SMTP id t66mr34040rne; Fri, 17 Sep 2004 17:21:52 -0700 (PDT) Received: by 10.38.163.70 with HTTP; Fri, 17 Sep 2004 17:21:51 -0700 (PDT) Message-ID: <9e47339104091717215e9be08b@mail.gmail.com> Date: Fri, 17 Sep 2004 20:21:51 -0400 From: Jon Smirl Reply-To: Jon Smirl To: "David S. Miller" Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Cc: David Gibson , akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040917112744.190f6f3e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040917062042.GE6523@zax> <20040917112744.190f6f3e.davem@davemloft.net> X-archive-position: 9046 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonsmirl@gmail.com Precedence: bulk X-list: netdev Content-Length: 1317 Lines: 41 I'm still OOPsing at boot in fib_disable_ip+21 from fib_netdev_event+63. Both e1000 and tg3 are effected. I have current linus bk as of time of this message. It only occurs when Redhat goes through the scaning for new hardware phase during boot. Is RH loading the drivers in some special way during this phase? If I load the drivers manually after I'm booted they load ok. I'm running with the drivers as modules, I'll try switching to compiled in. The change referenced in this thread is in my kernel: fib_semantics.c, 604 } else { memset(new_info_hash, 0, bytes); memset(new_laddrhash, 0, bytes); fib_hash_move(new_info_hash, new_laddrhash, new_size); } On Fri, 17 Sep 2004 11:27:44 -0700, David S. Miller wrote: > > Thanks David, I'll push this upstream asap. > > I can't believe in all the route testing I did I never > triggered this on my sparc64 boxes, must have been lucky :( > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Jon Smirl jonsmirl@gmail.com From yoshfuji@linux-ipv6.org Fri Sep 17 17:28:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:28:27 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0SLwR029493 for ; Fri, 17 Sep 2004 17:28:22 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id C3DF833CE5; Sat, 18 Sep 2004 09:28:18 +0900 (JST) Date: Sat, 18 Sep 2004 09:28:18 +0900 (JST) Message-Id: <20040918.092818.127633070.yoshfuji@linux-ipv6.org> To: laforge@netfilter.org Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: (usagi-users 03036) Re: 2.6.8.1 IPv6 Routing Problem From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040918.084304.75142669.yoshfuji@linux-ipv6.org> References: <20040917230803.GJ2678@sunbeam.de.gnumonks.org> <20040918.084304.75142669.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 9047 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 428 Lines: 12 oops, sorry for the typo. In article <20040918.084304.75142669.yoshfuji@linux-ipv6.org> (at Sat, 18 Sep 2004 08:43:04 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > > I'm experiencing some strange problems on a 2.6.8.1 vanilla kernel. I > > tried to reproduce it with a minimal system: > : > Anyway, please try the latest bk tree. > There are may fixes in it. many --yoshfuji From herbert@gondor.apana.org.au Fri Sep 17 17:28:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:28:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0Sctw029567 for ; Fri, 17 Sep 2004 17:28:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8T51-0004bM-00; Sat, 18 Sep 2004 10:27:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8T4t-0006ug-00; Sat, 18 Sep 2004 10:27:47 +1000 From: Herbert Xu To: Jon Smirl Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Cc: davem@davemloft.net, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <9e47339104091717215e9be08b@mail.gmail.com> X-Newsgroups: apana.lists.os.linux.kernel,apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sat, 18 Sep 2004 10:27:47 +1000 X-archive-position: 9048 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 453 Lines: 11 Jon Smirl wrote: > I'm still OOPsing at boot in fib_disable_ip+21 from > fib_netdev_event+63. Both e1000 and tg3 are effected. I have current > linus bk as of time of this message. Please post the complete error message. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jonsmirl@gmail.com Fri Sep 17 17:59:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:59:51 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0xhKi030588 for ; Fri, 17 Sep 2004 17:59:43 -0700 Received: by mproxy.gmail.com with SMTP id 77so196458rnk for ; Fri, 17 Sep 2004 17:59:24 -0700 (PDT) Received: by 10.38.171.66 with SMTP id t66mr57447rne; Fri, 17 Sep 2004 17:59:24 -0700 (PDT) Received: by 10.38.163.70 with HTTP; Fri, 17 Sep 2004 17:59:24 -0700 (PDT) Message-ID: <9e4733910409171759242349f0@mail.gmail.com> Date: Fri, 17 Sep 2004 20:59:24 -0400 From: Jon Smirl Reply-To: Jon Smirl To: Herbert Xu Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Cc: davem@davemloft.net, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9e47339104091717215e9be08b@mail.gmail.com> X-archive-position: 9049 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonsmirl@gmail.com Precedence: bulk X-list: netdev Content-Length: 793 Lines: 26 I have verified that compiling the drivers in avoids the problem. I'll boot again and get more of the error message. It's not making it to the logs so I am copying it by hand from the screen. On Sat, 18 Sep 2004 10:27:47 +1000, Herbert Xu wrote: > Jon Smirl wrote: > > I'm still OOPsing at boot in fib_disable_ip+21 from > > fib_netdev_event+63. Both e1000 and tg3 are effected. I have current > > linus bk as of time of this message. > > Please post the complete error message. > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- Jon Smirl jonsmirl@gmail.com From yoshfuji@linux-ipv6.org Fri Sep 17 18:24:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 18:24:13 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I1O7lv031149 for ; Fri, 17 Sep 2004 18:24:08 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9870333CE5; Sat, 18 Sep 2004 10:24:04 +0900 (JST) Date: Sat, 18 Sep 2004 10:24:04 +0900 (JST) Message-Id: <20040918.102404.30656051.yoshfuji@linux-ipv6.org> To: herbert@gondor.apana.org.au Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [XFRM] Make XFRM core subsystem af-independent From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040918001216.GB24235@gondor.apana.org.au> References: <20040918.085003.77842779.yoshfuji@linux-ipv6.org> <20040917170607.2e96b58a.davem@davemloft.net> <20040918001216.GB24235@gondor.apana.org.au> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9050 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1132 Lines: 46 In article <20040918001216.GB24235@gondor.apana.org.au> (at Sat, 18 Sep 2004 10:12:16 +1000), Herbert Xu says: > On Fri, Sep 17, 2004 at 05:06:07PM -0700, David S. Miller wrote: > > > > Compiler is smarter than you think :-) > > Sparc bigots :) > > Unfortunately it can't do that on architectures where the arguments > are pushed onto the stack in reverse order, i.e., i386. I've tested on i386. .globl ip_route_output_key .type ip_route_output_key,@function ip_route_output_key: movl 4(%esp),%edx movl 8(%esp),%eax pushl $0 pushl $0 pushl %eax pushl %edx call ip_route_output_flow addl $16,%esp ret This is not good. We, however, now have (up to 3) register parameters on i386 (CONFIG_REGPARM), and assembly code is: .globl ip_route_output_key .type ip_route_output_key,@function ip_route_output_key: pushl $0 xorl %ecx, %ecx call ip_route_output_flow popl %ecx ret This is (not good as sparc, but) not bad (well, much better than before at least). -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jonsmirl@gmail.com Fri Sep 17 18:37:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 18:37:39 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I1bVb1031557 for ; Fri, 17 Sep 2004 18:37:32 -0700 Received: by mproxy.gmail.com with SMTP id 77so207621rnk for ; Fri, 17 Sep 2004 18:37:16 -0700 (PDT) Received: by 10.38.99.13 with SMTP id w13mr472912rnb; Fri, 17 Sep 2004 18:37:16 -0700 (PDT) Received: by 10.38.163.70 with HTTP; Fri, 17 Sep 2004 18:37:15 -0700 (PDT) Message-ID: <9e473391040917183726113e91@mail.gmail.com> Date: Fri, 17 Sep 2004 21:37:15 -0400 From: Jon Smirl Reply-To: Jon Smirl To: Herbert Xu Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Cc: davem@davemloft.net, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9e47339104091717215e9be08b@mail.gmail.com> X-archive-position: 9051 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonsmirl@gmail.com Precedence: bulk X-list: netdev Content-Length: 1230 Lines: 43 Call stack at failure: e1000_exit_module ...pci calls... e1000_remove unregister_netdev unregister_netdevice notifier_call_chain fib_netdev_event fib_disable_ip error_code Rest of the info has scrolled off the screen. The problem is when RH/Fedora is doing it's modprobe/rmmod to detect what hardware is in the system since that's the only thing that would be rmmod'ing e1000. On the same system if I disable networking and boot, I can modprobe/rmmod the drivers without problem. So I'd conclude that RH is doing something special during it's probing phase, but I don't know enough about the RH init scripts to know what it is. On Sat, 18 Sep 2004 10:27:47 +1000, Herbert Xu wrote: > Jon Smirl wrote: > > I'm still OOPsing at boot in fib_disable_ip+21 from > > fib_netdev_event+63. Both e1000 and tg3 are effected. I have current > > linus bk as of time of this message. > > Please post the complete error message. > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- Jon Smirl jonsmirl@gmail.com From sfeldma@pobox.com Fri Sep 17 19:42:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 19:42:31 -0700 (PDT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I2gOlt032734 for ; Fri, 17 Sep 2004 19:42:25 -0700 Received: from [192.168.0.79] ([4.5.62.153]) by out011.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040918024214.PHIH14580.out011.verizon.net@[192.168.0.79]>; Fri, 17 Sep 2004 21:42:14 -0500 Subject: Re: [patch 2/5 2.4] e1000 - Fix MODULE_PARM, module_param and module_param_array usage From: Scott Feldman Reply-To: sfeldma@pobox.com To: Ganesh Venkatesan Cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1095475337.3496.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 17 Sep 2004 19:42:17 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [4.5.62.153] at Fri, 17 Sep 2004 21:42:13 -0500 X-archive-position: 9052 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev Content-Length: 337 Lines: 11 What's this patch really about? The only real change I see is the default ITR going from 8000 back to 1 (= dynamic mode). What's this got to do with MODULE_PARAM, etc? BTW, wasn't there a big change to go from 1 to 8000. Now this undoes that? The rest of the changes look like someone is messing up the whitespacing. Why? -scott From sfeldma@pobox.com Fri Sep 17 19:59:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 19:59:25 -0700 (PDT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I2xLT2000815 for ; Fri, 17 Sep 2004 19:59:21 -0700 Received: from [192.168.0.79] ([4.5.62.153]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040918025910.XXEJ26805.out003.verizon.net@[192.168.0.79]>; Fri, 17 Sep 2004 21:59:10 -0500 Subject: Re: [patch 3/8 2.5] e1000 - Fix MODULE_PARM, module_param and module_param_array usage From: Scott Feldman Reply-To: sfeldma@pobox.com To: Ganesh Venkatesan Cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1095476353.3496.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 17 Sep 2004 19:59:13 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [4.5.62.153] at Fri, 17 Sep 2004 21:59:09 -0500 X-archive-position: 9053 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev Content-Length: 366 Lines: 13 On Fri, 2004-09-17 at 02:57, Ganesh Venkatesan wrote: > @@ -306,5 +312,9 @@ e1000_check_options(struct e1000_adapter > "Warning: no configuration for board #%i\n", bd); > DPRINTK(PROBE, NOTICE, "Using defaults for all values\n"); > #ifndef module_param_array > - bd = E1000_MAX_NIC; > #endif > } Is that leaving an empty #ifndef/#endif ? -scott From sfeldma@pobox.com Fri Sep 17 20:05:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 20:05:24 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I35Iin001219 for ; Fri, 17 Sep 2004 20:05:18 -0700 Received: from [192.168.0.79] ([4.5.62.153]) by out001.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040918030507.OEFI24594.out001.verizon.net@[192.168.0.79]>; Fri, 17 Sep 2004 22:05:07 -0500 Subject: Re: [patch 4/8 2.5] e1000 Check value returned by from pci_enable_device From: Scott Feldman Reply-To: sfeldma@pobox.com To: Ganesh Venkatesan Cc: jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1095476710.3496.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 17 Sep 2004 20:05:10 -0700 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [4.5.62.153] at Fri, 17 Sep 2004 22:05:07 -0500 X-archive-position: 9054 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev Content-Length: 846 Lines: 22 On Fri, 2004-09-17 at 02:57, Ganesh Venkatesan wrote: > diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c > --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-09 11:17:11.000000000 -0700 > +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-09 11:17:12.000000000 -0700 > @@ -2881,9 +2881,9 @@ e1000_resume(struct pci_dev *pdev) > { > struct net_device *netdev = pci_get_drvdata(pdev); > struct e1000_adapter *adapter = netdev->priv; > - uint32_t manc; > + uint32_t manc, ret; > > - pci_enable_device(pdev); > + ret = pci_enable_device(pdev); > pci_set_power_state(pdev, 0); > pci_restore_state(pdev, adapter->pci_state); Where is the check of the return value? I just see an assignment to an automatic that gets tossed (probably by the compiler if it's paying attention). -scott From herbert@gondor.apana.org.au Fri Sep 17 21:17:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 21:17:22 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I4H60F005425 for ; Fri, 17 Sep 2004 21:17:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8WeJ-0005cf-00; Sat, 18 Sep 2004 14:16:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8WeC-0003h9-00; Sat, 18 Sep 2004 14:16:28 +1000 Date: Sat, 18 Sep 2004 14:16:28 +1000 To: Jon Smirl Cc: davem@davemloft.net, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Message-ID: <20040918041627.GA12356@gondor.apana.org.au> References: <9e47339104091717215e9be08b@mail.gmail.com> <9e473391040917183726113e91@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <9e473391040917183726113e91@mail.gmail.com> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9055 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1750 Lines: 63 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 17, 2004 at 09:37:15PM -0400, Jon Smirl wrote: > Call stack at failure: > e1000_exit_module > ...pci calls... > e1000_remove > unregister_netdev > unregister_netdevice > notifier_call_chain > fib_netdev_event > fib_disable_ip > error_code Thanks. The following bug is probably your problem. > Rest of the info has scrolled off the screen. You should be able to hit Shift-PageUp to scroll up. There is a thinko in the allocation for the devindex hash. We're only giving it 8 elements when it should be 1<<8 elements. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/fib_semantics.c 1.16 vs edited ===== --- 1.16/net/ipv4/fib_semantics.c 2004-09-18 04:11:04 +10:00 +++ edited/net/ipv4/fib_semantics.c 2004-09-18 14:08:55 +10:00 @@ -52,7 +52,8 @@ static unsigned int fib_info_cnt; #define DEVINDEX_HASHBITS 8 -static struct hlist_head fib_info_devhash[DEVINDEX_HASHBITS]; +#define DEVINDEX_HASHSIZE (1U << DEVINDEX_HASHBITS) +static struct hlist_head fib_info_devhash[DEVINDEX_HASHSIZE]; #ifdef CONFIG_IP_ROUTE_MULTIPATH @@ -229,7 +230,7 @@ static inline unsigned int fib_devindex_hashfn(unsigned int val) { - unsigned int mask = ((1U << DEVINDEX_HASHBITS) - 1); + unsigned int mask = DEVINDEX_HASHSIZE - 1; return (val ^ (val >> DEVINDEX_HASHBITS) ^ --9amGYk9869ThD9tj-- From jonsmirl@gmail.com Fri Sep 17 22:22:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 22:22:55 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I5Mmjg006441 for ; Fri, 17 Sep 2004 22:22:49 -0700 Received: by mproxy.gmail.com with SMTP id 77so277675rnk for ; Fri, 17 Sep 2004 22:22:33 -0700 (PDT) Received: by 10.38.171.66 with SMTP id t66mr206866rne; Fri, 17 Sep 2004 22:22:31 -0700 (PDT) Received: by 10.38.163.70 with HTTP; Fri, 17 Sep 2004 22:22:31 -0700 (PDT) Message-ID: <9e473391040917222253f8bf03@mail.gmail.com> Date: Sat, 18 Sep 2004 01:22:31 -0400 From: Jon Smirl Reply-To: Jon Smirl To: Herbert Xu Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Cc: davem@davemloft.net, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040918041627.GA12356@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9e47339104091717215e9be08b@mail.gmail.com> <9e473391040917183726113e91@mail.gmail.com> <20040918041627.GA12356@gondor.apana.org.au> X-archive-position: 9056 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonsmirl@gmail.com Precedence: bulk X-list: netdev Content-Length: 205 Lines: 8 Still getting the same fault with the patch. Someone else has this problem too. The full stack trace is in this thread.... [2.6.9-rc2-bk] Network-related panic on boot -- Jon Smirl jonsmirl@gmail.com From davem@davemloft.net Fri Sep 17 23:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 23:35:02 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I6YtOX007628 for ; Fri, 17 Sep 2004 23:34:56 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8YkW-0006fB-00; Fri, 17 Sep 2004 23:31:08 -0700 Date: Fri, 17 Sep 2004 23:31:08 -0700 From: "David S. Miller" To: Herbert Xu Cc: jonsmirl@gmail.com, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Message-Id: <20040917233108.561c88d6.davem@davemloft.net> In-Reply-To: <20040918041627.GA12356@gondor.apana.org.au> References: <9e47339104091717215e9be08b@mail.gmail.com> <9e473391040917183726113e91@mail.gmail.com> <20040918041627.GA12356@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9057 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 889 Lines: 29 On Sat, 18 Sep 2004 14:16:28 +1000 Herbert Xu wrote: > Thanks. The following bug is probably your problem. Good catch on this fix, but really he's hitting the BUG_ON() in fib_sync_down() (I hate i386 backtraces, it's an art to decode them properly) So if you rmmod() a device before any routes are ever created in ipv4, this triggers. I didn't think this was possible, but it is. The fix is simple enough. ===== net/ipv4/fib_semantics.c 1.16 vs edited ===== --- 1.16/net/ipv4/fib_semantics.c 2004-09-17 11:11:04 -07:00 +++ edited/net/ipv4/fib_semantics.c 2004-09-17 23:14:44 -07:00 @@ -1040,9 +1040,7 @@ if (force) scope = -1; - BUG_ON(!fib_info_laddrhash); - - if (local) { + if (local && fib_info_laddrhash) { unsigned int hash = fib_laddr_hashfn(local); struct hlist_head *head = &fib_info_laddrhash[hash]; struct hlist_node *node; From herbert@gondor.apana.org.au Sat Sep 18 03:26:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 03:26:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IAQRtR016127 for ; Sat, 18 Sep 2004 03:26:29 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8cPn-0006uY-00; Sat, 18 Sep 2004 20:25:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8cPd-0006K8-00; Sat, 18 Sep 2004 20:25:49 +1000 From: Herbert Xu To: pablo@eurodev.net (Pablo Neira) Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Cc: davem@redhat.com, linux-net@vger.kernel.org, netdev@oss.sgi.com, kaber@trash.net Organization: Core In-Reply-To: <412F1269.8090303@eurodev.net> X-Newsgroups: apana.lists.os.linux.net User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.26-1-686-smp (i686)) Message-Id: Date: Sat, 18 Sep 2004 20:25:49 +1000 X-archive-position: 9058 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2346 Lines: 85 Pablo Neira wrote: > > thanks, I fixed, I shouldn't type at 5 a.m. If any other problem, please > let me know. Sorry I should've reviewed this patch sooner. It finally caught my attention as I went to update the 2.4 IPsec backport. Firstly there is a sock leak there. The following patch fixes it. The white space damage is not mine :) Signed-off-by: Herbert Xu Secondly, I'm dubious about the patch as a whole. For instance, what exactly is the wake_up_process() bit trying to do? Surely that process would've been woken up multiple times already if its queue is full. If it can't empty the queue fast enough, what is this extra wake up going to achieve? And what is it going to do with thread groups? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/netlink/af_netlink.c 1.52 vs edited ===== --- 1.52/net/netlink/af_netlink.c 2004-08-28 10:11:04 +10:00 +++ 2.6/net/netlink/af_netlink.c 2004-09-18 20:09:20 +10:00 @@ -630,7 +630,8 @@ if (!nlwork) return -1; - + + sock_hold(sk); INIT_WORK(&nlwork->work, netlink_wq_handler, nlwork); nlwork->sk = sk; nlwork->len = skb->len; @@ -683,14 +684,13 @@ netlink_overrun(sk); /* Clone failed. Notify ALL listeners. */ failure = 1; - sock_put(sk); } else if (netlink_broadcast_deliver(sk, skb2)) { netlink_overrun(sk); - sock_put(sk); } else { delivered = 1; skb2 = NULL; } + sock_put(sk); } netlink_unlock_table(); -- ===== net/netlink/af_netlink.c 1.15 vs edited ===== --- 1.15/net/netlink/af_netlink.c 2004-08-31 10:04:34 +10:00 +++ 2.4/net/netlink/af_netlink.c 2004-09-18 20:25:29 +10:00 @@ -549,7 +549,8 @@ if (!nlwork) return -EAGAIN; - + + sock_hold(sk); INIT_TQUEUE(&nlwork->work, netlink_tq_handler, nlwork); nlwork->sk = sk; nlwork->len = skb->len; @@ -601,12 +602,11 @@ netlink_overrun(sk); /* Clone failed. Notify ALL listeners. */ failure = 1; - sock_put(sk); } else if (netlink_broadcast_deliver(sk, skb2)) { netlink_overrun(sk); - sock_put(sk); } else skb2 = NULL; + sock_put(sk); } netlink_unlock_table(); From jonsmirl@gmail.com Sat Sep 18 08:28:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 08:28:26 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IFSKQd026635 for ; Sat, 18 Sep 2004 08:28:21 -0700 Received: by mproxy.gmail.com with SMTP id 77so643183rnk for ; Sat, 18 Sep 2004 08:28:02 -0700 (PDT) Received: by 10.38.14.32 with SMTP id 32mr1106266rnn; Sat, 18 Sep 2004 08:28:01 -0700 (PDT) Received: by 10.38.163.70 with HTTP; Sat, 18 Sep 2004 08:28:00 -0700 (PDT) Message-ID: <9e47339104091808282df3dfe8@mail.gmail.com> Date: Sat, 18 Sep 2004 11:28:00 -0400 From: Jon Smirl Reply-To: Jon Smirl To: "David S. Miller" Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c Cc: Herbert Xu , david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040917233108.561c88d6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9e47339104091717215e9be08b@mail.gmail.com> <9e473391040917183726113e91@mail.gmail.com> <20040918041627.GA12356@gondor.apana.org.au> <20040917233108.561c88d6.davem@davemloft.net> X-archive-position: 9059 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonsmirl@gmail.com Precedence: bulk X-list: netdev Content-Length: 106 Lines: 5 The last patch fixes things so that I can boot. The net is working too. -- Jon Smirl jonsmirl@gmail.com From hadi@cyberus.ca Sat Sep 18 13:31:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 13:31:28 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IKVMvf007148 for ; Sat, 18 Sep 2004 13:31:23 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C8lrT-0002vW-GR for netdev@oss.sgi.com; Sat, 18 Sep 2004 16:31:11 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C8lrP-0000Qr-JV; Sat, 18 Sep 2004 16:31:07 -0400 Subject: Re: [TRIVIAL] Fix recent bug in fib_semantics.c From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Herbert Xu , jonsmirl@gmail.com, david@gibson.dropbear.id.au, akpm@osdl.org, trivial@rustcorp.com.au, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040917233108.561c88d6.davem@davemloft.net> References: <9e47339104091717215e9be08b@mail.gmail.com> <9e473391040917183726113e91@mail.gmail.com> <20040918041627.GA12356@gondor.apana.org.au> <20040917233108.561c88d6.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095539462.1043.1.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Sep 2004 16:31:03 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9060 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 353 Lines: 13 On Sat, 2004-09-18 at 02:31, David S. Miller wrote: > On Sat, 18 Sep 2004 14:16:28 +1000 > So if you rmmod() a device before any routes are ever > created in ipv4, this triggers. I didn't think this > was possible, but it is. May have been exposed by LLTX. When i turned off LLTX on e1000 before seeing your fix, the oops disapeared. cheers, jamal From laforge@gnumonks.org Sat Sep 18 15:02:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 15:02:44 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IM2bPO008536 for ; Sat, 18 Sep 2004 15:02:38 -0700 Received: from dsl-082-083-225-091.arcor-ip.net ([82.83.225.91] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C8nHh-000102-5Y; Sun, 19 Sep 2004 00:02:21 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C8nHX-0001nd-U5; Sun, 19 Sep 2004 00:02:11 +0200 Date: Sun, 19 Sep 2004 00:02:11 +0200 From: Harald Welte To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem Message-ID: <20040918220211.GI6005@sunbeam.de.gnumonks.org> References: <20040917230803.GJ2678@sunbeam.de.gnumonks.org> <20040918.084304.75142669.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="va4/JQ6j8/8uipEp" Content-Disposition: inline In-Reply-To: <20040918.084304.75142669.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9061 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 3006 Lines: 84 --va4/JQ6j8/8uipEp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2004 at 08:43:04AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ w= rote: > > I'm experiencing some strange problems on a 2.6.8.1 vanilla kernel. I > > tried to reproduce it with a minimal system: > : > > (intermixed with a 'ip6tables -A OUTPUT -j LOG' and '-A INPUT -j LOG' > > rules for diagnostics). >=20 > It is not minimum with ip6tables. :-) i just added ip6tables to get some log messages on incoming/outgoing packets (small embedded system with no tcpdump). > Anyway, please try the latest bk tree. > There are may fixes in it. In fact the problem disappeared with 2.6.9-rc2. I thought the idea of 2.6.8.x is to have real show-stopper bugfixes go into that series... and if something like this is severely broken in ipv6, I would say it rectifies a 2.6.8.2 release, don't you think? I have to admit that this is the first time that my linux ipv6 setup breaks within four years... Now I'm stuck with another issue: The interfaces suddenly no logner get any link-local addresses: /proc/net # ip -6 addr 2: eth1: mtu 1500 qlen 1000 inet6 3ffe:400:900:1100::1/64 scope global=20 valid_lft forever preferred_lft forever inet6 3ffe:400:900:1100:207:e9ff:fe09:b920/64 scope global=20 valid_lft forever preferred_lft forever 3: lo: mtu 16436=20 inet6 ::1/128 scope host=20 valid_lft forever preferred_lft forever 4: eth0.2: mtu 1500=20 inet6 3ffe:400:900:1101::1/64 scope global=20 valid_lft forever preferred_lft forever inet6 3ffe:400:900:1101:207:e9ff:fe09:b920/64 scope global=20 valid_lft forever preferred_lft forever 5: eth0.3: mtu 1500=20 inet6 3ffe:400:900:9999::1/64 scope global=20 valid_lft forever preferred_lft forever inet6 3ffe:400:900:9999:207:e9ff:fe09:b920/64 scope global=20 valid_lft forever preferred_lft forever 8: tap0: mtu 1399 qlen 1000 inet6 3ffe:400:900:3001::2/64 scope global=20 valid_lft forever preferred_lft forever /proc/net # uname -r 2.6.9-rc2 Thanks! --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --va4/JQ6j8/8uipEp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBTLBjXaXGVTD0i/8RAjE1AKCtC8gWtcWurCmUF3bslFQd/HP5/ACfcY8z fR6CakIsZ65ssMPONoQEthc= =fN3p -----END PGP SIGNATURE----- --va4/JQ6j8/8uipEp-- From romieu@fr.zoreil.com Sat Sep 18 15:03:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 15:03:48 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IM3eud008743 for ; Sat, 18 Sep 2004 15:03:41 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8IM1Nvr017717; Sun, 19 Sep 2004 00:01:23 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8IM1M39017716; Sun, 19 Sep 2004 00:01:22 +0200 Date: Sun, 19 Sep 2004 00:01:22 +0200 From: Francois Romieu To: akpm@osdl.org Cc: jgarzik@pobom.com, netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc2-mm1 1/1] 3c59x: missing pci_disable_device Message-ID: <20040918220122.GA15528@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9062 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1385 Lines: 46 It is possible to remove the device without calling pci_disable_device(). A leak can take place during the init as well. Signed-off-by: Francois Romieu diff -puN drivers/net/3c59x.c~3c59x-00 drivers/net/3c59x.c --- linux-2.6.9-rc2/drivers/net/3c59x.c~3c59x-00 2004-09-18 22:20:43.000000000 +0200 +++ linux-2.6.9-rc2-fr/drivers/net/3c59x.c 2004-09-18 22:20:43.000000000 +0200 @@ -1075,14 +1075,20 @@ static int __devinit vortex_init_one (st int rc; /* wake up and enable device */ - if (pci_enable_device (pdev)) { - rc = -EIO; - } else { - rc = vortex_probe1 (&pdev->dev, pci_resource_start (pdev, 0), - pdev->irq, ent->driver_data, vortex_cards_found); - if (rc == 0) - vortex_cards_found++; + rc = pci_enable_device (pdev); + if (rc < 0) + goto out; + + rc = vortex_probe1 (&pdev->dev, pci_resource_start (pdev, 0), + pdev->irq, ent->driver_data, vortex_cards_found); + if (rc < 0) { + pci_disable_device (pdev); + goto out; } + + vortex_cards_found++; + +out: return rc; } @@ -3163,6 +3169,7 @@ static void __devexit vortex_remove_one pci_set_power_state(VORTEX_PCI(vp), 0); /* Go active */ if (vp->pm_state_valid) pci_restore_state(VORTEX_PCI(vp), vp->power_state); + pci_disable_device(VORTEX_PCI(vp)); } /* Should really use issue_and_wait() here */ outw(TotalReset|0x14, dev->base_addr + EL3_CMD); _ From olh@suse.de Sat Sep 18 15:40:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 15:40:20 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IMeDki009657 for ; Sat, 18 Sep 2004 15:40:14 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 1FCD4C21182; Sun, 19 Sep 2004 00:38:33 +0200 (CEST) Date: Sun, 19 Sep 2004 00:38:32 +0200 From: Olaf Hering To: Andrew Morton , netdev@oss.sgi.com Subject: [PATCH] remove leading space in linux/skbuff.h Message-ID: <20040918223832.GA28730@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-archive-position: 9063 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 630 Lines: 22 unifdef complains about the leading space. Signed-off-by: Olaf Hering diff -purN linux-2.6.8/include/linux/skbuff.h linux-2.6.8.xxx/include/linux/skbuff.h --- linux-2.6.8/include/linux/skbuff.h 2004-09-19 00:11:39.094174840 +0200 +++ linux-2.6.8.xxx/include/linux/skbuff.h 2004-09-19 00:30:14.332978660 +0200 @@ -271,7 +271,7 @@ struct sk_buff { #ifdef CONFIG_NET_CLS_ACT __u32 tc_verd; /* traffic control verdict */ __u32 tc_classid; /* traffic control classid */ - #endif +#endif #endif -- USB is for mice, FireWire is for men! sUse lINUX ag, nÃœRNBERG From olh@suse.de Sat Sep 18 15:45:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 15:45:28 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8IMjNII010019 for ; Sat, 18 Sep 2004 15:45:23 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C3E12C21579; Sun, 19 Sep 2004 00:45:07 +0200 (CEST) Date: Sun, 19 Sep 2004 00:45:07 +0200 From: Olaf Hering To: Andrew Morton , netdev@oss.sgi.com Subject: Re: [PATCH] remove leading space in linux/skbuff.h Message-ID: <20040918224507.GA28794@suse.de> References: <20040918223832.GA28730@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040918223832.GA28730@suse.de> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-archive-position: 9064 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 1008 Lines: 41 On Sun, Sep 19, Olaf Hering wrote: > > unifdef complains about the leading space. maybe the whole content can be in #ifdef __KERNEL__ Signed-off-by: Olaf Hering diff -purN linux-2.6.8/include/linux/skbuff.h linux-2.6.8.xxx/include/linux/skbuff.h --- linux-2.6.8/include/linux/skbuff.h 2004-09-19 00:11:39.094174840 +0200 +++ linux-2.6.8.xxx/include/linux/skbuff.h 2004-09-19 00:42:48.187538697 +0200 @@ -13,6 +13,7 @@ #ifndef _LINUX_SKBUFF_H #define _LINUX_SKBUFF_H +#ifdef __KERNEL__ #include #include @@ -271,7 +272,7 @@ struct sk_buff { #ifdef CONFIG_NET_CLS_ACT __u32 tc_verd; /* traffic control verdict */ __u32 tc_classid; /* traffic control classid */ - #endif +#endif #endif @@ -285,7 +286,6 @@ struct sk_buff { *end; }; -#ifdef __KERNEL__ /* * Handling routines are only of interest to the kernel */ -- USB is for mice, FireWire is for men! sUse lINUX ag, nÃœRNBERG From davem@davemloft.net Sat Sep 18 18:10:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 18:10:53 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J1Af3x015294 for ; Sat, 18 Sep 2004 18:10:41 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8qAC-00005D-00; Sat, 18 Sep 2004 18:06:48 -0700 Date: Sat, 18 Sep 2004 18:06:47 -0700 From: "David S. Miller" To: Harald Welte Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem Message-Id: <20040918180647.6be57884.davem@davemloft.net> In-Reply-To: <20040918220211.GI6005@sunbeam.de.gnumonks.org> References: <20040917230803.GJ2678@sunbeam.de.gnumonks.org> <20040918.084304.75142669.yoshfuji@linux-ipv6.org> <20040918220211.GI6005@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9065 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2623 Lines: 73 On Sun, 19 Sep 2004 00:02:11 +0200 Harald Welte wrote: > Now I'm stuck with another issue: The interfaces suddenly no logner > get any link-local addresses: Probably due to this change. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/10 14:50:26-07:00 yoshfuji@linux-ipv6.org # [IPV6]: Deprecate all-on-link assumption # # If we don't have IPv6 default routes, we assume all ipv6 destinations # are on-link as specified in RFC2461. It, however, is considered harmful now; # it is problematic with IPv6-capable nodes that do not have off-link # IPv6 connectivity (eg no default routers) and such nodes will take # a few seconds until they fall back to use IPv4. # # See for details. # # From: KUNITAKE Koichi # Signed-off-by: KUNITAKE Koichi # Signed-off-by: YOSHIFUJI Hideaki # Signed-off-by: David S. Miller # # net/ipv6/addrconf.c # 2004/09/10 14:50:09-07:00 yoshfuji@linux-ipv6.org +4 -12 # [IPV6]: Deprecate all-on-link assumption # # If we don't have IPv6 default routes, we assume all ipv6 destinations # are on-link as specified in RFC2461. It, however, is considered harmful now; # it is problematic with IPv6-capable nodes that do not have off-link # IPv6 connectivity (eg no default routers) and such nodes will take # a few seconds until they fall back to use IPv4. # # See for details. # # From: KUNITAKE Koichi # Signed-off-by: KUNITAKE Koichi # Signed-off-by: YOSHIFUJI Hideaki # Signed-off-by: David S. Miller # diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2004-09-18 17:50:32 -07:00 +++ b/net/ipv6/addrconf.c 2004-09-18 17:50:32 -07:00 @@ -2108,21 +2108,13 @@ ndisc_send_rs(ifp->idev->dev, &ifp->addr, &all_routers); } else { - struct in6_rtmsg rtmsg; - spin_unlock(&ifp->lock); - + /* + * Note: we do not support deprecated "all on-link" + * assumption any longer. + */ printk(KERN_DEBUG "%s: no IPv6 routers present\n", ifp->idev->dev->name); - - memset(&rtmsg, 0, sizeof(struct in6_rtmsg)); - rtmsg.rtmsg_type = RTMSG_NEWROUTE; - rtmsg.rtmsg_metric = IP6_RT_PRIO_ADDRCONF; - rtmsg.rtmsg_flags = (RTF_ALLONLINK | RTF_DEFAULT | RTF_UP); - - rtmsg.rtmsg_ifindex = ifp->idev->dev->ifindex; - - ip6_route_add(&rtmsg, NULL, NULL); } out: From yoshfuji@linux-ipv6.org Sat Sep 18 19:11:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 19:11:50 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J2BiTY016329 for ; Sat, 18 Sep 2004 19:11:45 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0631C33CE5; Sun, 19 Sep 2004 11:11:42 +0900 (JST) Date: Sun, 19 Sep 2004 11:11:41 +0900 (JST) Message-Id: <20040919.111141.42341294.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: laforge@gnumonks.org, netdev@oss.sgi.com, usagi-users@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040918180647.6be57884.davem@davemloft.net> References: <20040918.084304.75142669.yoshfuji@linux-ipv6.org> <20040918220211.GI6005@sunbeam.de.gnumonks.org> <20040918180647.6be57884.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9066 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 691 Lines: 22 In article <20040918180647.6be57884.davem@davemloft.net> (at Sat, 18 Sep 2004 18:06:47 -0700), "David S. Miller" says: > On Sun, 19 Sep 2004 00:02:11 +0200 > Harald Welte wrote: > > > Now I'm stuck with another issue: The interfaces suddenly no logner > > get any link-local addresses: > > Probably due to this change. > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2004/09/10 14:50:26-07:00 yoshfuji@linux-ipv6.org > # [IPV6]: Deprecate all-on-link assumption I don't think so. I've run TAHI test on post-rc2 kernel, and the result is as I expected. I haven't met such issues... hmm... --yoshfuji From cranium2003@yahoo.com Sat Sep 18 19:18:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 19:18:59 -0700 (PDT) Received: from web41406.mail.yahoo.com (web41406.mail.yahoo.com [66.218.93.72]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8J2ItRQ016731 for ; Sat, 18 Sep 2004 19:18:55 -0700 Message-ID: <20040919021839.20368.qmail@web41406.mail.yahoo.com> Received: from [66.218.69.220] by web41406.mail.yahoo.com via HTTP; Sat, 18 Sep 2004 19:18:39 PDT Date: Sat, 18 Sep 2004 19:18:39 -0700 (PDT) From: cranium2003 Subject: Protocol handler question To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9067 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 362 Lines: 16 Hello, can it be possible to have two packet types to have same protocol handler? i have modified IP packet which i want to be processed by ip_rcv procedure? what changes i require for that? Regards, cranium2003. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From yoshfuji@linux-ipv6.org Sat Sep 18 19:20:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 19:20:17 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J2KBaX016944 for ; Sat, 18 Sep 2004 19:20:11 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 95BD333CE5; Sun, 19 Sep 2004 11:20:09 +0900 (JST) Date: Sun, 19 Sep 2004 11:20:09 +0900 (JST) Message-Id: <20040919.112009.92851216.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: laforge@gnumonks.org, netdev@oss.sgi.com, usagi-users@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040919.111141.42341294.yoshfuji@linux-ipv6.org> References: <20040918220211.GI6005@sunbeam.de.gnumonks.org> <20040918180647.6be57884.davem@davemloft.net> <20040919.111141.42341294.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 9068 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1227 Lines: 36 In article <20040919.111141.42341294.yoshfuji@linux-ipv6.org> (at Sun, 19 Sep 2004 11:11:41 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > In article <20040918180647.6be57884.davem@davemloft.net> (at Sat, 18 Sep 2004 18:06:47 -0700), "David S. Miller" says: > > > On Sun, 19 Sep 2004 00:02:11 +0200 > > Harald Welte wrote: > > > > > Now I'm stuck with another issue: The interfaces suddenly no logner > > > get any link-local addresses: > > > > Probably due to this change. > > > > # This is a BitKeeper generated diff -Nru style patch. > > # > > # ChangeSet > > # 2004/09/10 14:50:26-07:00 yoshfuji@linux-ipv6.org > > # [IPV6]: Deprecate all-on-link assumption > > I don't think so. And, that code was run after the link-local address assignment. What we did was: 1. Try to assign link-local address. - start DAD - wait a while 2. If DAD ends with no duplicated addresses, try to search neighbor routers. - send RS - wait a while 3. If no routers present, add "all-on-link" route. The patch deletes the last one (3). and it should not be something to do with the link-local address assignment. --yoshfuji From davem@davemloft.net Sat Sep 18 20:37:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 20:37:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J3b2OJ021386 for ; Sat, 18 Sep 2004 20:37:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C8sRz-0000ni-00 for ; Sat, 18 Sep 2004 20:33:19 -0700 Date: Sat, 18 Sep 2004 20:33:19 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Subject: [PATCH] Clean up fib_hash datastructures Message-Id: <20040918203319.24004d6e.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9069 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 30804 Lines: 1214 So, before we even think about trying new faster algorithms in net/ipv4/fib_hash.c we have to clean it up. Currently there is a lot of behavior hidden in the hash chain list ordering that could be explicitly described using better datastructures. What happens now is that, within each hash chain, entries with the same destination address key are ordered by TOS then by priority. So this patch below attempts to do two things: 1) Split fib_node to fib_node and fib_alias. The fib_node is purely a lookup object keyed on destination address and prefix only. Any new lookup algorithm we attempt will modify _only_ the code handling fib_node objects. The fib_alias, on the other hand, describes a sub-route of a fib_node that has different TOS and PRIORITY keys. Each fib_node has a list of fib_alias objects. 2) Use linux/list.h list facilities instead of by-hand list implementations. I would say that the most complicated part of the patch below is the insertion handling. If an entry exists matching the insert request, we have to check if this is an exclusive add. If so, then we error, else we append/prepend to the alias list depending upon what the user asked for. Finally we also have to check if we are doing a replace. The procfs support got slightly trickier as well. Does anyone know what this test: if (!iter->zone->fz_next) continue; in fib_get_first() is doing? I kept it there but it looks fishy. Does it prevent default routes (that is, routes with prefix zero) from being displayed in /proc/net/route? Effectively what this test does is make the last zone in the zone list not be displayed if you have nothing but default routes. Please help me review and test this patch. Thanks. ===== net/ipv4/fib_hash.c 1.19 vs edited ===== --- 1.19/net/ipv4/fib_hash.c 2004-09-15 13:54:54 -07:00 +++ edited/net/ipv4/fib_hash.c 2004-09-18 20:05:05 -07:00 @@ -43,49 +43,45 @@ #include #include -#define FTprint(a...) -/* - printk(KERN_DEBUG a) - */ - static kmem_cache_t *fn_hash_kmem; +static kmem_cache_t *fn_alias_kmem; struct fib_node { - struct fib_node *fn_next; - struct fib_info *fn_info; -#define FIB_INFO(f) ((f)->fn_info) + struct hlist_node fn_hash; + struct list_head fn_alias; u32 fn_key; - u8 fn_tos; - u8 fn_type; - u8 fn_scope; - u8 fn_state; }; -#define FN_S_ZOMBIE 1 -#define FN_S_ACCESSED 2 +struct fib_alias { + struct list_head fa_list; + struct fib_info *fa_info; + u8 fa_tos; + u8 fa_type; + u8 fa_scope; + u8 fa_state; +}; -static int fib_hash_zombies; +#define FN_S_ACCESSED 1 struct fn_zone { - struct fn_zone *fz_next; /* Next not empty zone */ - struct fib_node **fz_hash; /* Hash table pointer */ - int fz_nent; /* Number of entries */ - - int fz_divisor; /* Hash divisor */ - u32 fz_hashmask; /* (fz_divisor - 1) */ -#define FZ_HASHMASK(fz) ((fz)->fz_hashmask) - - int fz_order; /* Zone order */ - u32 fz_mask; -#define FZ_MASK(fz) ((fz)->fz_mask) + struct fn_zone *fz_next; /* Next not empty zone */ + struct hlist_head *fz_hash; /* Hash table pointer */ + int fz_nent; /* Number of entries */ + + int fz_divisor; /* Hash divisor */ + u32 fz_hashmask; /* (fz_divisor - 1) */ +#define FZ_HASHMASK(fz) ((fz)->fz_hashmask) + + int fz_order; /* Zone order */ + u32 fz_mask; +#define FZ_MASK(fz) ((fz)->fz_mask) }; /* NOTE. On fast computers evaluation of fz_hashmask and fz_mask - can be cheaper than memory lookup, so that FZ_* macros are used. + * can be cheaper than memory lookup, so that FZ_* macros are used. */ -struct fn_hash -{ +struct fn_hash { struct fn_zone *fn_zones[33]; struct fn_zone *fn_zone_list; }; @@ -105,65 +101,56 @@ return dst & FZ_MASK(fz); } -static inline struct fib_node ** fz_chain_p(u32 key, struct fn_zone *fz) -{ - return &fz->fz_hash[fn_hash(key, fz)]; -} - -static inline struct fib_node * fz_chain(u32 key, struct fn_zone *fz) -{ - return fz->fz_hash[fn_hash(key, fz)]; -} - static rwlock_t fib_hash_lock = RW_LOCK_UNLOCKED; -#define FZ_MAX_DIVISOR ((PAGE_SIZE<fn_next; - for (fp = fz_chain_p(f->fn_key, fz); - *fp && ((*fp)->fn_key <= f->fn_key); - fp = &(*fp)->fn_next) - /* NONE */; - f->fn_next = *fp; - *fp = f; + for (i = 0; i < old_divisor; i++) { + struct hlist_node *node, *n; + struct fib_node *f; + + hlist_for_each_entry_safe(f, node, n, &old_ht[i], fn_hash) { + struct hlist_head *new_head; + + hlist_del(&f->fn_hash); + + new_head = &fz->fz_hash[fn_hash(f->fn_key, fz)]; + hlist_add_head(&f->fn_hash, new_head); } } } -static void fz_hash_free(struct fib_node **hash, int divisor) +static void fz_hash_free(struct hlist_head *hash, int divisor) { if (divisor <= 1024) kfree(hash); else free_pages((unsigned long) hash, - get_order(divisor * sizeof(struct fib_node *))); + get_order(divisor * sizeof(struct hlist_head))); } static void fn_rehash_zone(struct fn_zone *fz) { - struct fib_node **ht, **old_ht; + struct hlist_head *ht, *old_ht; int old_divisor, new_divisor; u32 new_hashmask; @@ -194,7 +181,7 @@ ht = fz_hash_alloc(new_divisor); if (ht) { - memset(ht, 0, new_divisor*sizeof(struct fib_node*)); + memset(ht, 0, new_divisor * sizeof(struct hlist_head)); write_lock_bh(&fib_hash_lock); old_ht = fz->fz_hash; @@ -208,12 +195,16 @@ } } -static void fn_free_node(struct fib_node * f) +static inline void fn_free_node(struct fib_node * f) { - fib_release_info(FIB_INFO(f)); kmem_cache_free(fn_hash_kmem, f); } +static inline void fn_free_alias(struct fib_alias *fa) +{ + fib_release_info(fa->fa_info); + kmem_cache_free(fn_alias_kmem, fa); +} static struct fn_zone * fn_new_zone(struct fn_hash *table, int z) @@ -235,7 +226,7 @@ kfree(fz); return NULL; } - memset(fz->fz_hash, 0, fz->fz_divisor*sizeof(struct fib_node*)); + memset(fz->fz_hash, 0, fz->fz_divisor * sizeof(struct hlist_head *)); fz->fz_order = z; fz->fz_mask = inet_make_mask(z); @@ -266,36 +257,41 @@ read_lock(&fib_hash_lock); for (fz = t->fn_zone_list; fz; fz = fz->fz_next) { + struct hlist_head *head; + struct hlist_node *node; struct fib_node *f; u32 k = fz_key(flp->fl4_dst, fz); - for (f = fz_chain(k, fz); f; f = f->fn_next) { - if (k != f->fn_key) { - if (k <= f->fn_key) - break; - else - continue; - } -#ifdef CONFIG_IP_ROUTE_TOS - if (f->fn_tos && f->fn_tos != flp->fl4_tos) + head = &fz->fz_hash[fn_hash(k, fz)]; + hlist_for_each_entry(f, node, head, fn_hash) { + struct fib_alias *fa; + + if (f->fn_key != k) continue; + + list_for_each_entry(fa, &f->fn_alias, fa_list) { +#ifdef CONFIG_IP_ROUTE_TOS + if (fa->fa_tos && + fa->fa_tos != flp->fl4_tos) + continue; #endif - f->fn_state |= FN_S_ACCESSED; + if (fa->fa_scope < flp->fl4_scope) + continue; - if (f->fn_state&FN_S_ZOMBIE) - continue; - if (f->fn_scope < flp->fl4_scope) - continue; + fa->fa_state |= FN_S_ACCESSED; - err = fib_semantic_match(f->fn_type, FIB_INFO(f), flp, res); - if (err == 0) { - res->type = f->fn_type; - res->scope = f->fn_scope; - res->prefixlen = fz->fz_order; - goto out; + err = fib_semantic_match(fa->fa_type, + fa->fa_info, + flp, res); + if (err == 0) { + res->type = fa->fa_type; + res->scope = fa->fa_scope; + res->prefixlen = fz->fz_order; + goto out; + } + if (err < 0) + goto out; } - if (err < 0) - goto out; } } err = 1; @@ -333,6 +329,7 @@ fn_hash_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) { int order, last_idx; + struct hlist_node *node; struct fib_node *f; struct fib_info *fi = NULL; struct fib_info *last_resort; @@ -347,36 +344,41 @@ order = -1; read_lock(&fib_hash_lock); - for (f = fz->fz_hash[0]; f; f = f->fn_next) { - struct fib_info *next_fi = FIB_INFO(f); + hlist_for_each_entry(f, node, &fz->fz_hash[0], fn_hash) { + struct fib_alias *fa; - if ((f->fn_state&FN_S_ZOMBIE) || - f->fn_scope != res->scope || - f->fn_type != RTN_UNICAST) - continue; + list_for_each_entry(fa, &f->fn_alias, fa_list) { + struct fib_info *next_fi = fa->fa_info; - if (next_fi->fib_priority > res->fi->fib_priority) - break; - if (!next_fi->fib_nh[0].nh_gw || next_fi->fib_nh[0].nh_scope != RT_SCOPE_LINK) - continue; - f->fn_state |= FN_S_ACCESSED; + if (fa->fa_scope != res->scope || + fa->fa_type != RTN_UNICAST) + continue; - if (fi == NULL) { - if (next_fi != res->fi) + if (next_fi->fib_priority > res->fi->fib_priority) break; - } else if (!fib_detect_death(fi, order, &last_resort, &last_idx)) { - if (res->fi) - fib_info_put(res->fi); - res->fi = fi; - atomic_inc(&fi->fib_clntref); - fn_hash_last_dflt = order; - goto out; + if (!next_fi->fib_nh[0].nh_gw || + next_fi->fib_nh[0].nh_scope != RT_SCOPE_LINK) + continue; + fa->fa_state |= FN_S_ACCESSED; + + if (fi == NULL) { + if (next_fi != res->fi) + break; + } else if (!fib_detect_death(fi, order, &last_resort, + &last_idx)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + fn_hash_last_dflt = order; + goto out; + } + fi = next_fi; + order++; } - fi = next_fi; - order++; } - if (order<=0 || fi==NULL) { + if (order <= 0 || fi == NULL) { fn_hash_last_dflt = -1; goto out; } @@ -402,45 +404,76 @@ read_unlock(&fib_hash_lock); } -#define FIB_SCAN(f, fp) \ -for ( ; ((f) = *(fp)) != NULL; (fp) = &(f)->fn_next) +static void rtmsg_fib(int, struct fib_node *, struct fib_alias *, + int, int, + struct nlmsghdr *n, + struct netlink_skb_parms *); -#define FIB_SCAN_KEY(f, fp, key) \ -for ( ; ((f) = *(fp)) != NULL && ((f)->fn_key == (key)); (fp) = &(f)->fn_next) +/* Insert node F to FZ. */ +static inline void fib_insert_node(struct fn_zone *fz, struct fib_node *f) +{ + struct hlist_head *head = &fz->fz_hash[fn_hash(f->fn_key, fz)]; -#ifndef CONFIG_IP_ROUTE_TOS -#define FIB_SCAN_TOS(f, fp, key, tos) FIB_SCAN_KEY(f, fp, key) -#else -#define FIB_SCAN_TOS(f, fp, key, tos) \ -for ( ; ((f) = *(fp)) != NULL && ((f)->fn_key == (key)) && \ - (f)->fn_tos == (tos) ; (fp) = &(f)->fn_next) -#endif + hlist_add_head(&f->fn_hash, head); +} +/* Return the node in FZ matching KEY. */ +static struct fib_node *fib_find_node(struct fn_zone *fz, u32 key) +{ + struct hlist_head *head = &fz->fz_hash[fn_hash(key, fz)]; + struct hlist_node *node; + struct fib_node *f; -static void rtmsg_fib(int, struct fib_node*, int, int, - struct nlmsghdr *n, - struct netlink_skb_parms *); + hlist_for_each_entry(f, node, head, fn_hash) { + if (f->fn_key == key) + return f; + } + + return NULL; +} + +/* Return the first fib alias matching TOS with + * priority less than or equal to PRIO. + */ +static struct fib_alias *fib_find_alias(struct fib_node *fn, u8 tos, u32 prio) +{ + if (fn) { + struct list_head *head = &fn->fn_alias; + struct fib_alias *fa, *prev_fa; + + prev_fa = NULL; + list_for_each_entry(fa, head, fa_list) { +#ifdef CONFIG_IP_ROUTE_TOS + if (fa->fa_tos != tos) + continue; +#endif + prev_fa = fa; + if (prio <= fa->fa_info->fib_priority) + break; + } + return fa; + } + return NULL; +} static int fn_hash_insert(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, - struct nlmsghdr *n, struct netlink_skb_parms *req) + struct nlmsghdr *n, struct netlink_skb_parms *req) { - struct fn_hash *table = (struct fn_hash*)tb->tb_data; - struct fib_node *new_f, *f, **fp, **del_fp; + struct fn_hash *table = (struct fn_hash *) tb->tb_data; + struct fib_node *new_f, *f; + struct fib_alias *fa, *new_fa; struct fn_zone *fz; struct fib_info *fi; - int z = r->rtm_dst_len; int type = r->rtm_type; -#ifdef CONFIG_IP_ROUTE_TOS u8 tos = r->rtm_tos; -#endif u32 key; int err; -FTprint("tb(%d)_insert: %d %08x/%d %d %08x\n", tb->tb_id, r->rtm_type, rta->rta_dst ? -*(u32*)rta->rta_dst : 0, z, rta->rta_oif ? *rta->rta_oif : -1, -rta->rta_prefsrc ? *(u32*)rta->rta_prefsrc : 0); +#ifndef CONFIG_IP_ROUTE_TOS + tos = 0; +#endif if (z > 32) return -EINVAL; fz = table->fn_zones[z]; @@ -464,136 +497,111 @@ (z==32 || (1< fz->fz_divisor)) fn_rehash_zone(fz); - fp = fz_chain_p(key, fz); - + f = fib_find_node(fz, key); + fa = fib_find_alias(f, tos, fi->fib_priority); - /* - * Scan list to find the first route with the same destination - */ - FIB_SCAN(f, fp) { - if (key <= f->fn_key) - break; - } - -#ifdef CONFIG_IP_ROUTE_TOS - /* - * Find route with the same destination and tos. + /* Now fa, if non-NULL, points to the first fib alias + * with the same keys [prefix,tos,priority], if such key already + * exists or to the node before which we will insert new one. + * + * If fa is NULL, we will need to allocate a new one and + * insert to the head of f. + * + * If f is NULL, no fib node matched the destination key + * and we need to allocate a new one of those as well. */ - FIB_SCAN_KEY(f, fp, key) { - if (f->fn_tos <= tos) - break; - } -#endif - - del_fp = NULL; - if (f && (f->fn_state&FN_S_ZOMBIE) && -#ifdef CONFIG_IP_ROUTE_TOS - f->fn_tos == tos && -#endif - (f->fn_key == key)) { - del_fp = fp; - fp = &f->fn_next; - f = *fp; - goto create; - } - - FIB_SCAN_TOS(f, fp, key, tos) { - if (fi->fib_priority <= FIB_INFO(f)->fib_priority) - break; - } - - /* Now f==*fp points to the first node with the same - keys [prefix,tos,priority], if such key already - exists or to the node, before which we will insert new one. - */ - - if (f && -#ifdef CONFIG_IP_ROUTE_TOS - f->fn_tos == tos && -#endif - (f->fn_key == key) && - fi->fib_priority == FIB_INFO(f)->fib_priority) { - struct fib_node **ins_fp; + if (fa && + fa->fa_info->fib_priority == fi->fib_priority) { + struct fib_alias *fa_orig; err = -EEXIST; - if (n->nlmsg_flags&NLM_F_EXCL) + if (n->nlmsg_flags & NLM_F_EXCL) goto out; - if (n->nlmsg_flags&NLM_F_REPLACE) { - del_fp = fp; - fp = &f->fn_next; - f = *fp; - goto replace; - } + if (n->nlmsg_flags & NLM_F_REPLACE) { + struct fib_info *fi_drop; + u8 state; - ins_fp = fp; - err = -EEXIST; + write_lock_bh(&fib_hash_lock); + fi_drop = fa->fa_info; + fa->fa_info = fi; + fa->fa_type = type; + fa->fa_scope = r->rtm_scope; + state = fa->fa_state; + fa->fa_state &= ~FN_S_ACCESSED; + write_unlock_bh(&fib_hash_lock); - FIB_SCAN_TOS(f, fp, key, tos) { - if (fi->fib_priority != FIB_INFO(f)->fib_priority) - break; - if (f->fn_type == type && f->fn_scope == r->rtm_scope - && FIB_INFO(f) == fi) - goto out; + fib_release_info(fi_drop); + if (state & FN_S_ACCESSED) + rt_cache_flush(-1); + return 0; } - if (!(n->nlmsg_flags&NLM_F_APPEND)) { - fp = ins_fp; - f = *fp; + /* Error if we find a perfect match which + * uses the same scope, type, and nexthop + * information. + */ + fa_orig = fa; + list_for_each_entry(fa, fa->fa_list.prev, fa_list) { + if (fa->fa_info->fib_priority != fi->fib_priority) + break; + if (fa->fa_type == type && + fa->fa_scope == r->rtm_scope && + fa->fa_info == fi) + goto out; } + if (!(n->nlmsg_flags & NLM_F_APPEND)) + fa = fa_orig; } -create: err = -ENOENT; if (!(n->nlmsg_flags&NLM_F_CREATE)) goto out; -replace: err = -ENOBUFS; - new_f = kmem_cache_alloc(fn_hash_kmem, SLAB_KERNEL); - if (new_f == NULL) + new_fa = kmem_cache_alloc(fn_alias_kmem, SLAB_KERNEL); + if (new_fa == NULL) goto out; - memset(new_f, 0, sizeof(struct fib_node)); - - new_f->fn_key = key; -#ifdef CONFIG_IP_ROUTE_TOS - new_f->fn_tos = tos; -#endif - new_f->fn_type = type; - new_f->fn_scope = r->rtm_scope; - FIB_INFO(new_f) = fi; + new_f = NULL; + if (!f) { + new_f = kmem_cache_alloc(fn_hash_kmem, SLAB_KERNEL); + if (new_f == NULL) + goto out_free_new_fa; + + INIT_HLIST_NODE(&new_f->fn_hash); + INIT_LIST_HEAD(&new_f->fn_alias); + new_f->fn_key = key; + f = new_f; + } + + new_fa->fa_info = fi; + new_fa->fa_tos = tos; + new_fa->fa_type = type; + new_fa->fa_scope = r->rtm_scope; + new_fa->fa_state = 0; /* * Insert new entry to the list. */ - new_f->fn_next = f; write_lock_bh(&fib_hash_lock); - *fp = new_f; + if (new_f) + fib_insert_node(fz, new_f); + list_add(&new_fa->fa_list, + (fa ? &fa->fa_list : &f->fn_alias)); write_unlock_bh(&fib_hash_lock); - fz->fz_nent++; - if (del_fp) { - f = *del_fp; - /* Unlink replaced node */ - write_lock_bh(&fib_hash_lock); - *del_fp = f->fn_next; - write_unlock_bh(&fib_hash_lock); + if (new_f) + fz->fz_nent++; + rt_cache_flush(-1); - if (!(f->fn_state&FN_S_ZOMBIE)) - rtmsg_fib(RTM_DELROUTE, f, z, tb->tb_id, n, req); - if (f->fn_state&FN_S_ACCESSED) - rt_cache_flush(-1); - fn_free_node(f); - fz->fz_nent--; - } else { - rt_cache_flush(-1); - } - rtmsg_fib(RTM_NEWROUTE, new_f, z, tb->tb_id, n, req); + rtmsg_fib(RTM_NEWROUTE, f, new_fa, z, tb->tb_id, n, req); return 0; +out_free_new_fa: + kmem_cache_free(fn_alias_kmem, new_fa); out: fib_release_info(fi); return err; @@ -602,20 +610,19 @@ static int fn_hash_delete(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, - struct nlmsghdr *n, struct netlink_skb_parms *req) + struct nlmsghdr *n, struct netlink_skb_parms *req) { struct fn_hash *table = (struct fn_hash*)tb->tb_data; - struct fib_node **fp, **del_fp, *f; + struct fib_node *f; + struct fib_alias *fa, *fa_to_delete; int z = r->rtm_dst_len; struct fn_zone *fz; u32 key; - int matched; -#ifdef CONFIG_IP_ROUTE_TOS u8 tos = r->rtm_tos; -#endif -FTprint("tb(%d)_delete: %d %08x/%d %d\n", tb->tb_id, r->rtm_type, rta->rta_dst ? - *(u32*)rta->rta_dst : 0, z, rta->rta_oif ? *rta->rta_oif : -1); +#ifndef CONFIG_IP_ROUTE_TOS + tos = 0; +#endif if (z > 32) return -EINVAL; if ((fz = table->fn_zones[z]) == NULL) @@ -630,61 +637,48 @@ key = fz_key(dst, fz); } - fp = fz_chain_p(key, fz); - + f = fib_find_node(fz, key); + fa = fib_find_alias(f, tos, 0); + if (!fa) + return -ESRCH; - FIB_SCAN(f, fp) { - if (f->fn_key == key) - break; - if (key <= f->fn_key) - return -ESRCH; - } -#ifdef CONFIG_IP_ROUTE_TOS - FIB_SCAN_KEY(f, fp, key) { - if (f->fn_tos == tos) + fa_to_delete = NULL; + list_for_each_entry(fa, fa->fa_list.prev, fa_list) { + struct fib_info *fi = fa->fa_info; + + if ((!r->rtm_type || + fa->fa_type == r->rtm_type) && + (r->rtm_scope == RT_SCOPE_NOWHERE || + fa->fa_scope == r->rtm_scope) && + (!r->rtm_protocol || + fi->fib_protocol == r->rtm_protocol) && + fib_nh_match(r, n, rta, fi) == 0) { + fa_to_delete = fa; break; - } -#endif - - matched = 0; - del_fp = NULL; - FIB_SCAN_TOS(f, fp, key, tos) { - struct fib_info * fi = FIB_INFO(f); - - if (f->fn_state&FN_S_ZOMBIE) { - return -ESRCH; } - matched++; - - if (del_fp == NULL && - (!r->rtm_type || f->fn_type == r->rtm_type) && - (r->rtm_scope == RT_SCOPE_NOWHERE || f->fn_scope == r->rtm_scope) && - (!r->rtm_protocol || fi->fib_protocol == r->rtm_protocol) && - fib_nh_match(r, n, rta, fi) == 0) - del_fp = fp; } - if (del_fp) { - f = *del_fp; - rtmsg_fib(RTM_DELROUTE, f, z, tb->tb_id, n, req); + if (fa_to_delete) { + int kill_fn; - if (matched != 1) { - write_lock_bh(&fib_hash_lock); - *del_fp = f->fn_next; - write_unlock_bh(&fib_hash_lock); + fa = fa_to_delete; + rtmsg_fib(RTM_DELROUTE, f, fa, z, tb->tb_id, n, req); - if (f->fn_state&FN_S_ACCESSED) - rt_cache_flush(-1); + kill_fn = 0; + write_lock_bh(&fib_hash_lock); + list_del(&fa->fa_list); + if (list_empty(&f->fn_alias)) { + hlist_del(&f->fn_hash); + kill_fn = 1; + } + write_unlock_bh(&fib_hash_lock); + + if (fa->fa_state & FN_S_ACCESSED) + rt_cache_flush(-1); + fn_free_alias(fa); + if (kill_fn) { fn_free_node(f); fz->fz_nent--; - } else { - f->fn_state |= FN_S_ZOMBIE; - if (f->fn_state&FN_S_ACCESSED) { - f->fn_state &= ~FN_S_ACCESSED; - rt_cache_flush(-1); - } - if (++fib_hash_zombies > 128) - fib_flush(); } return 0; @@ -692,43 +686,53 @@ return -ESRCH; } -static inline int -fn_flush_list(struct fib_node ** fp, int z, struct fn_hash *table) +static int fn_flush_list(struct fn_zone *fz, int idx) { - int found = 0; + struct hlist_head *head = &fz->fz_hash[idx]; + struct hlist_node *node, *n; struct fib_node *f; + int found = 0; - while ((f = *fp) != NULL) { - struct fib_info *fi = FIB_INFO(f); - - if (fi && ((f->fn_state&FN_S_ZOMBIE) || (fi->fib_flags&RTNH_F_DEAD))) { - write_lock_bh(&fib_hash_lock); - *fp = f->fn_next; - write_unlock_bh(&fib_hash_lock); + hlist_for_each_entry_safe(f, node, n, head, fn_hash) { + struct fib_alias *fa, *fa_node; + int kill_f; + + kill_f = 0; + list_for_each_entry_safe(fa, fa_node, &f->fn_alias, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + write_lock_bh(&fib_hash_lock); + list_del(&fa->fa_list); + if (list_empty(&f->fn_alias)) { + hlist_del(&f->fn_hash); + kill_f = 1; + } + write_unlock_bh(&fib_hash_lock); + fn_free_alias(fa); + found++; + } + } + if (kill_f) { fn_free_node(f); - found++; - continue; + fz->fz_nent--; } - fp = &f->fn_next; } return found; } static int fn_hash_flush(struct fib_table *tb) { - struct fn_hash *table = (struct fn_hash*)tb->tb_data; + struct fn_hash *table = (struct fn_hash *) tb->tb_data; struct fn_zone *fz; int found = 0; - fib_hash_zombies = 0; for (fz = table->fn_zone_list; fz; fz = fz->fz_next) { int i; - int tmp = 0; - for (i=fz->fz_divisor-1; i>=0; i--) - tmp += fn_flush_list(&fz->fz_hash[i], fz->fz_order, table); - fz->fz_nent -= tmp; - found += tmp; + + for (i = fz->fz_divisor - 1; i >= 0; i--) + found += fn_flush_list(fz, i); } return found; } @@ -738,21 +742,36 @@ fn_hash_dump_bucket(struct sk_buff *skb, struct netlink_callback *cb, struct fib_table *tb, struct fn_zone *fz, - struct fib_node *f) + struct hlist_head *head) { + struct hlist_node *node; + struct fib_node *f; int i, s_i; s_i = cb->args[3]; - for (i=0; f; i++, f=f->fn_next) { - if (i < s_i) continue; - if (f->fn_state&FN_S_ZOMBIE) continue; - if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, - RTM_NEWROUTE, - tb->tb_id, (f->fn_state&FN_S_ZOMBIE) ? 0 : f->fn_type, f->fn_scope, - &f->fn_key, fz->fz_order, f->fn_tos, - f->fn_info) < 0) { - cb->args[3] = i; - return -1; + i = 0; + hlist_for_each_entry(f, node, head, fn_hash) { + struct fib_alias *fa; + + list_for_each_entry(fa, &f->fn_alias, fa_list) { + if (i < s_i) + continue; + + if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, + RTM_NEWROUTE, + tb->tb_id, + fa->fa_type, + fa->fa_scope, + &f->fn_key, + fz->fz_order, + fa->fa_tos, + fa->fa_info) < 0) { + cb->args[3] = i; + return -1; + } + + i++; } } cb->args[3] = i; @@ -770,10 +789,12 @@ for (h=0; h < fz->fz_divisor; h++) { if (h < s_h) continue; if (h > s_h) - memset(&cb->args[3], 0, sizeof(cb->args) - 3*sizeof(cb->args[0])); - if (fz->fz_hash == NULL || fz->fz_hash[h] == NULL) + memset(&cb->args[3], 0, + sizeof(cb->args) - 3*sizeof(cb->args[0])); + if (fz->fz_hash == NULL || + hlist_empty(&fz->fz_hash[h])) continue; - if (fn_hash_dump_bucket(skb, cb, tb, fz, fz->fz_hash[h]) < 0) { + if (fn_hash_dump_bucket(skb, cb, tb, fz, &fz->fz_hash[h])<0) { cb->args[2] = h; return -1; } @@ -793,7 +814,8 @@ for (fz = table->fn_zone_list, m=0; fz; fz = fz->fz_next, m++) { if (m < s_m) continue; if (m > s_m) - memset(&cb->args[2], 0, sizeof(cb->args) - 2*sizeof(cb->args[0])); + memset(&cb->args[2], 0, + sizeof(cb->args) - 2*sizeof(cb->args[0])); if (fn_hash_dump_zone(skb, cb, tb, fz) < 0) { cb->args[1] = m; read_unlock(&fib_hash_lock); @@ -805,7 +827,8 @@ return skb->len; } -static void rtmsg_fib(int event, struct fib_node* f, int z, int tb_id, +static void rtmsg_fib(int event, struct fib_node *f, struct fib_alias *fa, + int z, int tb_id, struct nlmsghdr *n, struct netlink_skb_parms *req) { struct sk_buff *skb; @@ -817,8 +840,9 @@ return; if (fib_dump_info(skb, pid, n->nlmsg_seq, event, tb_id, - f->fn_type, f->fn_scope, &f->fn_key, z, f->fn_tos, - FIB_INFO(f)) < 0) { + fa->fa_type, fa->fa_scope, &f->fn_key, z, + fa->fa_tos, + fa->fa_info) < 0) { kfree_skb(skb); return; } @@ -844,7 +868,14 @@ 0, SLAB_HWCACHE_ALIGN, NULL, NULL); - tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), GFP_KERNEL); + if (fn_alias_kmem == NULL) + fn_alias_kmem = kmem_cache_create("ip_fib_alias", + sizeof(struct fib_alias), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fn_hash), + GFP_KERNEL); if (tb == NULL) return NULL; @@ -865,18 +896,20 @@ struct fib_iter_state { struct fn_zone *zone; int bucket; - struct fib_node **hash; - struct fib_node *node; + struct hlist_head *hash_head; + struct fib_node *fn; + struct fib_alias *fa; }; -static inline struct fib_node *fib_get_first(struct seq_file *seq) +static struct fib_alias *fib_get_first(struct seq_file *seq) { - struct fib_iter_state* iter = seq->private; - struct fn_hash *table = (struct fn_hash *)ip_fib_main_table->tb_data; + struct fib_iter_state *iter = seq->private; + struct fn_hash *table = (struct fn_hash *) ip_fib_main_table->tb_data; - iter->bucket = 0; - iter->hash = NULL; - iter->node = NULL; + iter->bucket = 0; + iter->hash_head = NULL; + iter->fn = NULL; + iter->fa = NULL; for (iter->zone = table->fn_zone_list; iter->zone; iter->zone = iter->zone->fz_next) { @@ -885,44 +918,83 @@ if (!iter->zone->fz_next) continue; - iter->hash = iter->zone->fz_hash; + iter->hash_head = iter->zone->fz_hash; maxslot = iter->zone->fz_divisor; for (iter->bucket = 0; iter->bucket < maxslot; - ++iter->bucket, ++iter->hash) { - iter->node = *iter->hash; - - if (iter->node) - goto out; + ++iter->bucket, ++iter->hash_head) { + struct hlist_node *node; + struct fib_node *fn; + + hlist_for_each_entry(fn,node,iter->hash_head,fn_hash) { + struct fib_alias *fa; + + list_for_each_entry(fa,&fn->fn_alias,fa_list) { + iter->fn = fn; + iter->fa = fa; + goto out; + } + } } } out: - return iter->node; + return iter->fa; } -static inline struct fib_node *fib_get_next(struct seq_file *seq) +static struct fib_alias *fib_get_next(struct seq_file *seq) { - struct fib_iter_state* iter = seq->private; + struct fib_iter_state *iter = seq->private; + struct fib_node *fn; + struct fib_alias *fa; + + /* Advance FA, if any. */ + fn = iter->fn; + fa = iter->fa; + if (fa) { + BUG_ON(!fn); + list_for_each_entry_continue(fa, &fn->fn_alias, fa_list) { + iter->fa = fa; + goto out; + } + } - if (iter->node) - iter->node = iter->node->fn_next; + fa = iter->fa = NULL; - if (iter->node) - goto out; + /* Advance FN. */ + if (fn) { + struct hlist_node *node = &fn->fn_hash; + hlist_for_each_entry_continue(fn, node, fn_hash) { + iter->fn = fn; + + list_for_each_entry(fa, &fn->fn_alias, fa_list) { + iter->fa = fa; + goto out; + } + } + } + fn = iter->fn = NULL; + + /* Advance hash chain. */ if (!iter->zone) goto out; for (;;) { + struct hlist_node *node; int maxslot; maxslot = iter->zone->fz_divisor; while (++iter->bucket < maxslot) { - iter->node = *++iter->hash; + iter->hash_head++; - if (iter->node) - goto out; + hlist_for_each_entry(fn, node, iter->hash_head, fn_hash) { + list_for_each_entry(fa, &fn->fn_alias, fa_list) { + iter->fn = fn; + iter->fa = fa; + goto out; + } + } } iter->zone = iter->zone->fz_next; @@ -930,14 +1002,19 @@ if (!iter->zone) goto out; - iter->hash = iter->zone->fz_hash; iter->bucket = 0; - iter->node = *iter->hash; - if (iter->node) - break; + iter->hash_head = iter->zone->fz_hash; + + hlist_for_each_entry(fn, node, iter->hash_head, fn_hash) { + list_for_each_entry(fa, &fn->fn_alias, fa_list) { + iter->fn = fn; + iter->fa = fa; + goto out; + } + } } out: - return iter->node; + return fa; } static void *fib_seq_start(struct seq_file *seq, loff_t *pos) @@ -961,7 +1038,7 @@ read_unlock(&fib_hash_lock); } -static unsigned fib_flag_trans(int type, int dead, u32 mask, struct fib_info *fi) +static unsigned fib_flag_trans(int type, u32 mask, struct fib_info *fi) { static unsigned type2flags[RTN_MAX + 1] = { [7] = RTF_REJECT, [8] = RTF_REJECT, @@ -972,8 +1049,7 @@ flags |= RTF_GATEWAY; if (mask == 0xFFFFFFFF) flags |= RTF_HOST; - if (!dead) - flags |= RTF_UP; + flags |= RTF_UP; return flags; } @@ -985,11 +1061,12 @@ */ static int fib_seq_show(struct seq_file *seq, void *v) { - struct fib_iter_state* iter; + struct fib_iter_state *iter; char bf[128]; u32 prefix, mask; unsigned flags; struct fib_node *f; + struct fib_alias *fa; struct fib_info *fi; if (v == SEQ_START_TOKEN) { @@ -999,13 +1076,13 @@ goto out; } - f = v; - fi = FIB_INFO(f); iter = seq->private; + f = iter->fn; + fa = iter->fa; + fi = fa->fa_info; prefix = f->fn_key; mask = FZ_MASK(iter->zone); - flags = fib_flag_trans(f->fn_type, f->fn_state & FN_S_ZOMBIE, - mask, fi); + flags = fib_flag_trans(fa->fa_type, mask, fi); if (fi) snprintf(bf, sizeof(bf), "%s\t%08X\t%08X\t%04X\t%d\t%u\t%d\t%08X\t%d\t%u\t%u", From roland@topspin.com Sat Sep 18 21:08:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 21:08:55 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J48m1j022088 for ; Sat, 18 Sep 2004 21:08:48 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Sat, 18 Sep 2004 21:08:37 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 18 Sep 2004 21:08:37 -0700 Received: from roland by eddore with local (Exim 4.34) id 1C8t09-0000JJ-9L for netdev@oss.sgi.com; Sat, 18 Sep 2004 21:08:37 -0700 To: netdev@oss.sgi.com X-Message-Flag: Warning: May contain useful information From: Roland Dreier Date: Sat, 18 Sep 2004 21:08:37 -0700 Message-ID: <52fz5esxx6.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 19 Sep 2004 04:08:37.0690 (UTC) FILETIME=[56CF59A0:01C49DFE] X-archive-position: 9070 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 2674 Lines: 52 Hi, I'm looking for guidance on the "right" way to implement an IP-over-InfiniBand (IPoIB) driver for Linux. Right now, we have something that works, but we are cleaning it up for upstream submission (along with the rest of the OpenIB code). IPoIB is a network device driver (in the sense of "struct net_device"), but there are a few complications beyond the usual ethernet NIC case, which I'll described below. For full details you can look at the drafts from the IETF ipoib working group: http://ietf.org/html.charters/ipoib-charter.html If you want to look at the existing code, the best place to look is in my Subversion branch, specifically https://openib.org/svn/gen2/branches/roland-merge/src/linux-kernel/infiniband/ulp/ipoib for IPoIB code. IPoIB uses the usual ARP protocol for IPv4 (everything is analogous for IPv6 neighbor discovery but I'll focus on IPv4 for simplicity). A hardware address is 20 bytes: 1 reserved byte, 3 bytes of queue pair number (QPN) and 16 bytes of global identifier (GID). ARP works as specified in RFC 826 (with hardware type 32). The wrinkle is that while this 20 byte address is enough to uniquely identify a destination, it is not enough to actually send a packet to there. Once an ARP reply comes back, the IPoIB driver must then send a query to the IB subnet manager (which is a remote server on the IB fabric) and obtain a path to the destination GID -- a path is a 2 byte local identifier (LID) and a few other pieces of information. Once we have the path, we give that to the IB hardware and a get an address handle, which can finally be used to send a packet. This means there are a few things we would like to be able to do in the IPoIB driver. First of all, it would be good to be able to hook into the ARP code so that we add the GID->path lookup after the normal ARP (and have the kernel keep queuing packets until that lookup completes). Also, once the whole process is complete and we have an address handle, the driver doesn't actually care about the 20-byte destination address when it's getting packets to send -- it just needs the address handle. So it would be nice to have some way to stash that in struct neighbor and get that in our hard_header method (rather than having to keep our own cache mapping 20-bytes address back to address handle). It seems that some combination of clever neigh_setup and hard_header_cache/header_cache_update methods should be enough to make this work, but I don't know enough about the network stack to see how to do it. I'd really appreciate guidance on how to implement this, and I'm happy to answer any questions about the IPoIB architecture. Thanks, Roland From pablo@eurodev.net Sat Sep 18 21:35:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 21:36:03 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J4ZrWK022677 for ; Sat, 18 Sep 2004 21:35:54 -0700 Received: from eurodev.net ([217.217.175.68]) by smtp06.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919043535.GOJ11445.smtp06.retemail.es@eurodev.net>; Sun, 19 Sep 2004 06:35:35 +0200 Message-ID: <414D0CCD.90209@eurodev.net> Date: Sun, 19 Sep 2004 06:36:29 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080005010406010301040701" X-archive-position: 9071 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 3793 Lines: 146 This is a multi-part message in MIME format. --------------080005010406010301040701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Herbert, Herbert Xu wrote: >Firstly there is a sock leak there. The following patch fixes it. >The white space damage is not mine :) > >Signed-off-by: Herbert Xu > > you are right, I missed that, but I prefer the patches attached to this email. Now if netlink_broadcast_deliver function delivers correctly the packet, you decrease sock refcount and function returns 1. I think that I got confused because netlink_broadcast_deliver returns 0/-1. >Secondly, I'm dubious about the patch as a whole. For instance, what >exactly is the wake_up_process() bit trying to do? Surely that process >would've been woken up multiple times already if its queue is full. > This is what I theorically expected, but in practice if you stress a netlink socket sending a big bunch of information in a short period of time from kernel space to user space, socket overruns easily. That's why I wake up the user process to make it process information stored in the queue. Socket doesn't overrun anymore with my patch. >And what is it going to do with thread groups? > > currently broadcast sockets can still overrun. I have a set of patches that I'll submit as soon as I test them and I finish my boring exams. regards, Pablo --------------080005010406010301040701 Content-Type: text/x-patch; name="netlink-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink-fix.patch" diff -u -r1.1.1.2 af_netlink.c --- a/net/netlink/af_netlink.c 4 Sep 2004 17:34:06 -0000 1.1.1.2 +++ b/net/netlink/af_netlink.c 19 Sep 2004 03:57:20 -0000 @@ -629,18 +629,20 @@ kmalloc(sizeof(struct netlink_work), GFP_KERNEL); if (!nlwork) - return -1; + return 0; INIT_WORK(&nlwork->work, netlink_wq_handler, nlwork); nlwork->sk = sk; nlwork->len = skb->len; queue_work(netlink_wq, &nlwork->work); - } else + } else { sk->sk_data_ready(sk, skb->len); + sock_put(sock); + } - return 0; + return 1; } - return -1; + return 0; } int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, @@ -685,11 +687,11 @@ failure = 1; sock_put(sk); } else if (netlink_broadcast_deliver(sk, skb2)) { - netlink_overrun(sk); - sock_put(sk); - } else { delivered = 1; skb2 = NULL; + } else { + netlink_overrun(sk); + sock_put(sk); } } --------------080005010406010301040701 Content-Type: text/x-patch; name="netlink-fix-2.4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink-fix-2.4.patch" --- a/net/netlink/af_netlink.c 2004-09-19 06:23:22.000000000 +0200 +++ b/net/netlink/af_netlink.c 2004-09-19 06:24:48.000000000 +0200 @@ -548,19 +548,21 @@ kmalloc(sizeof(struct netlink_work), GFP_KERNEL); if (!nlwork) - return -EAGAIN; + return 0; INIT_TQUEUE(&nlwork->work, netlink_tq_handler, nlwork); nlwork->sk = sk; nlwork->len = skb->len; queue_task(&nlwork->work, &tq_netlink); wake_up(&netlink_thread_wait); - } else + } else { sk->data_ready(sk, skb->len); + sock_put(sk); + } - return 0; + return 1; } - return -1; + return 0; } void netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, @@ -602,11 +604,12 @@ /* Clone failed. Notify ALL listeners. */ failure = 1; sock_put(sk); - } else if (netlink_broadcast_deliver(sk, skb2)) { + } else if (netlink_broadcast_deliver(sk, skb2)) + skb2 = NULL; + else { netlink_overrun(sk); sock_put(sk); - } else - skb2 = NULL; + } } netlink_unlock_table(); --------------080005010406010301040701-- From pablo@eurodev.net Sat Sep 18 22:17:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 22:18:01 -0700 (PDT) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J5HsWT023541 for ; Sat, 18 Sep 2004 22:17:55 -0700 Received: from eurodev.net ([217.217.175.68]) by smtp08.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919051738.UKHA1184.smtp08.retemail.es@eurodev.net>; Sun, 19 Sep 2004 07:17:38 +0200 Message-ID: <414D16AC.1070905@eurodev.net> Date: Sun, 19 Sep 2004 07:18:36 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Pablo Neira CC: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> In-Reply-To: <414D0CCD.90209@eurodev.net> Content-Type: multipart/mixed; boundary="------------010200050301050308060704" X-archive-position: 9072 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1483 Lines: 68 This is a multi-part message in MIME format. --------------010200050301050308060704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pablo Neira wrote: > you are right, I missed that, but I prefer the patches attached to > this email. wrong 2.6 patch, consider this instead regards, Pablo --------------010200050301050308060704 Content-Type: text/x-patch; name="netlink-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink-fix.patch" diff -u -r1.1.1.2 af_netlink.c --- a/net/netlink/af_netlink.c 4 Sep 2004 17:34:06 -0000 1.1.1.2 +++ b/net/netlink/af_netlink.c 19 Sep 2004 03:57:20 -0000 @@ -629,18 +629,20 @@ kmalloc(sizeof(struct netlink_work), GFP_KERNEL); if (!nlwork) - return -1; + return 0; INIT_WORK(&nlwork->work, netlink_wq_handler, nlwork); nlwork->sk = sk; nlwork->len = skb->len; queue_work(netlink_wq, &nlwork->work); - } else + } else { sk->sk_data_ready(sk, skb->len); + sock_put(sk); + } - return 0; + return 1; } - return -1; + return 0; } int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, @@ -685,11 +687,11 @@ failure = 1; sock_put(sk); } else if (netlink_broadcast_deliver(sk, skb2)) { - netlink_overrun(sk); - sock_put(sk); - } else { delivered = 1; skb2 = NULL; + } else { + netlink_overrun(sk); + sock_put(sk); } } --------------010200050301050308060704-- From pablo@eurodev.net Sat Sep 18 22:27:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 18 Sep 2004 22:27:40 -0700 (PDT) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J5RXpH023956 for ; Sat, 18 Sep 2004 22:27:34 -0700 Received: from eurodev.net ([217.217.175.68]) by smtp07.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919052717.RDLP9737.smtp07.retemail.es@eurodev.net>; Sun, 19 Sep 2004 07:27:17 +0200 Message-ID: <414D18EF.3080207@eurodev.net> Date: Sun, 19 Sep 2004 07:28:15 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" , Herbert Xu , jamal CC: netdev@oss.sgi.com Subject: [PATCH 2.6] fix zombie netlink socket in user space Content-Type: multipart/mixed; boundary="------------000100000407020505030203" X-archive-position: 9073 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1877 Lines: 69 This is a multi-part message in MIME format. --------------000100000407020505030203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Davem, If you try to bind/connect to a non existant netlink socket, client socket gets succesfully inserted as head in the socket list. The problem is that the head can't be delete, so that socket stays in the list forever (see sk_del_node_init). If I'm missing something, please let me know. I'll submit a 2.4 version regards, Pablo --------------000100000407020505030203 Content-Type: text/x-patch; name="netlink-fix-zombie.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink-fix-zombie.patch" diff -u -r1.2 af_netlink.c --- a/net/netlink/af_netlink.c 19 Sep 2004 04:41:12 -0000 1.2 +++ b/net/netlink/af_netlink.c 19 Sep 2004 05:20:51 -0000 @@ -306,6 +306,19 @@ return 0; } +static inline int netlink_socket_exist(int protocol) +{ + /* Wanna bind to an non-existant netlink socket? */ + netlink_table_grab(); + if (!sk_head(&nl_table[protocol])) { + netlink_table_ungrab(); + return 0; + } + netlink_table_ungrab(); + + return 1; +} + static int netlink_autobind(struct socket *sock) { struct sock *sk = sock->sk; @@ -351,6 +364,9 @@ if (nladdr->nl_family != AF_NETLINK) return -EINVAL; + if (!netlink_socket_exist(sk->sk_protocol)) + return -ENOENT; + /* Only superuser is allowed to listen multicasts */ if (nladdr->nl_groups && !netlink_capable(sock, NL_NONROOT_RECV)) return -EPERM; @@ -392,6 +408,9 @@ if (addr->sa_family != AF_NETLINK) return -EINVAL; + if (!netlink_socket_exist(sk->sk_protocol)) + return -ENOENT; + /* Only superuser is allowed to send multicasts */ if (nladdr->nl_groups && !netlink_capable(sock, NL_NONROOT_SEND)) return -EPERM; --------------000100000407020505030203-- From laforge@gnumonks.org Sun Sep 19 00:46:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 00:46:28 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J7kKgq029284 for ; Sun, 19 Sep 2004 00:46:21 -0700 Received: from dsl-082-082-096-246.arcor-ip.net ([82.82.96.246] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C8wOf-0003zJ-FT; Sun, 19 Sep 2004 09:46:09 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C8wOb-0002J6-Lb; Sun, 19 Sep 2004 09:46:05 +0200 Date: Sun, 19 Sep 2004 09:46:05 +0200 From: Harald Welte To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem Message-ID: <20040919074605.GJ6005@sunbeam.de.gnumonks.org> References: <20040918.084304.75142669.yoshfuji@linux-ipv6.org> <20040918220211.GI6005@sunbeam.de.gnumonks.org> <20040918180647.6be57884.davem@davemloft.net> <20040919.111141.42341294.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUvfsPTz/SzOZDdw" Content-Disposition: inline In-Reply-To: <20040919.111141.42341294.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9074 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1622 Lines: 55 --fUvfsPTz/SzOZDdw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 19, 2004 at 11:11:41AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ w= rote: =20 > > On Sun, 19 Sep 2004 00:02:11 +0200 > > Harald Welte wrote: > >=20 > > > Now I'm stuck with another issue: The interfaces suddenly no logner > > > get any link-local addresses: > I've run TAHI test on post-rc2 kernel,=20 > and the result is as I expected. > I haven't met such issues... hmm... Apparently this happens when you=20 1) insmod ipv6 2) ifconfig your interfaces up 3) only now ifconfig 'lo' up. This happened due to a typo in my script :( If 'lo' exists prior to the other interfaces, everything seems to work as usual. Is this desired or accidential and/or documented behaviour? > --yoshfuji --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --fUvfsPTz/SzOZDdw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBTTk9XaXGVTD0i/8RAvyPAKCqMWPz0lZgNAqmFPrJ+sfaBzZ/AwCcCix/ o57zySwH07my7VMrCrOdNJg= =VIZ1 -----END PGP SIGNATURE----- --fUvfsPTz/SzOZDdw-- From herbert@gondor.apana.org.au Sun Sep 19 00:59:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 00:59:36 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J7xQDp029820 for ; Sun, 19 Sep 2004 00:59:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8wb6-0004RV-00; Sun, 19 Sep 2004 17:59:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8way-0000aH-00; Sun, 19 Sep 2004 17:58:52 +1000 From: Herbert Xu To: pablo@eurodev.net (Pablo Neira) Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Cc: herbert@gondor.apana.org.au, davem@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <414D0CCD.90209@eurodev.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 19 Sep 2004 17:58:52 +1000 X-archive-position: 9075 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2178 Lines: 49 Pablo Neira wrote: > > you are right, I missed that, but I prefer the patches attached to this > email. Now if netlink_broadcast_deliver function delivers correctly the > packet, you decrease sock refcount and function returns 1. I think that > I got confused because netlink_broadcast_deliver returns 0/-1. Unfortunately it is still wrong. You missed the exit path at the very top. And I think rather than adding all these new sock_put's, it's much better to do what you mean and add a sock_hold on the new path that you introduced. >>Secondly, I'm dubious about the patch as a whole. For instance, what >>exactly is the wake_up_process() bit trying to do? Surely that process >>would've been woken up multiple times already if its queue is full. > > This is what I theorically expected, but in practice if you stress a > netlink socket sending a big bunch of information in a short period of > time from kernel space to user space, socket overruns easily. That's why > I wake up the user process to make it process information stored in the > queue. Socket doesn't overrun anymore with my patch. Yes but your patch does a lot more than that wake_up_process. Have you reverted just the wake_up_process and seen a difference? >>And what is it going to do with thread groups? > > currently broadcast sockets can still overrun. I have a set of patches > that I'll submit as soon as I test them and I finish my boring exams. That's not what I meant. If you have a thread group where everybody's got the same pid, your code will probably wake up the wrong thread. Besides, for any netlink socket but the first for a process, they'll all have negative pid's which have nothing to do with the real pid. So I really think that the wake_up_process hunk is bogus. BTW I apologise for the few bounces that you got from my mail server. It should be fixed now. If you're still getting bounces, please let me know via the list. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 01:03:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 01:03:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8J83qXS030204 for ; Sun, 19 Sep 2004 01:03:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8weu-0004SN-00; Sun, 19 Sep 2004 18:02:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8weq-0000bD-00; Sun, 19 Sep 2004 18:02:52 +1000 From: Herbert Xu To: pablo@eurodev.net (Pablo Neira) Subject: Re: [PATCH 2.6] fix zombie netlink socket in user space Cc: davem@redhat.com, herbert@gondor.apana.org.au, hadi@cyberus.ca, netdev@oss.sgi.com Organization: Core In-Reply-To: <414D18EF.3080207@eurodev.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 19 Sep 2004 18:02:52 +1000 X-archive-position: 9076 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 559 Lines: 13 Pablo Neira wrote: > > If you try to bind/connect to a non existant netlink socket, client > socket gets succesfully inserted as head in the socket list. The problem > is that the head can't be delete, so that socket stays in the list > forever (see sk_del_node_init). Huh? Where does it say that the head can't be deleted? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 05:00:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 05:00:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JC0cwN018220 for ; Sun, 19 Sep 2004 05:00:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C90MZ-0005vX-00; Sun, 19 Sep 2004 22:00:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C90MX-0001Xl-00; Sun, 19 Sep 2004 22:00:13 +1000 Date: Sun, 19 Sep 2004 22:00:13 +1000 To: Pablo Neira Cc: davem@redhat.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919120013.GA5915@gondor.apana.org.au> References: <412DF807.2040703@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9077 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 664 Lines: 15 On Sun, Sep 19, 2004 at 09:50:58PM +1000, Herbert Xu wrote: > > Previously netlink requests had overhead comparable to that of an > ioctl. Now you've added two full context switches to it. There's > gotta be a better way to fix this dead-lock. Worse still, previously if a netlink request blocked indefinitely it only did that in the context of the calling process. Now it'll dead-lock the entire system because you're using the generic work queue. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 05:03:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 05:03:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JC3Hjn018411 for ; Sun, 19 Sep 2004 05:03:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C90P5-0005x5-00; Sun, 19 Sep 2004 22:02:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C90P3-0001Yd-00; Sun, 19 Sep 2004 22:02:49 +1000 Date: Sun, 19 Sep 2004 22:02:49 +1000 To: Pablo Neira Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919120249.GA5963@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9078 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 678 Lines: 16 On Sun, Sep 19, 2004 at 05:58:52PM +1000, Herbert Xu wrote: > > Besides, for any netlink socket but the first for a process, they'll > all have negative pid's which have nothing to do with the real pid. > So I really think that the wake_up_process hunk is bogus. Another reason why this is bogus. Most kernel users of unicast have a send timeout setting of 0. Therefore your wake_up_process() call will never happen when netlink_attachskb is called by the kernel. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 05:07:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 05:08:01 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JC7plK018907 for ; Sun, 19 Sep 2004 05:07:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C90Tb-0005xb-00; Sun, 19 Sep 2004 22:07:31 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C90Ta-0001ZJ-00; Sun, 19 Sep 2004 22:07:30 +1000 Date: Sun, 19 Sep 2004 22:07:30 +1000 To: Pablo Neira Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919120730.GA6005@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040919120249.GA5963@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9079 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1218 Lines: 30 On Sun, Sep 19, 2004 at 10:02:49PM +1000, herbert wrote: > > Another reason why this is bogus. > > Most kernel users of unicast have a send timeout setting of 0. Therefore > your wake_up_process() call will never happen when netlink_attachskb is > called by the kernel. In fact this is the reason why this whole problem is non-existant. Unless there is a kernel user that sends netlink messages with a timeout value other than 0, this patch does not resolve any dead-locks at all since there is none to start with. The reason is that the kernel will simply drop the message when the destination socket queue is full. So it looks to me as if this entire patch is simply papering over bugs in the user-space application where it either isn't processing the messages fast enough or it needs to enlarge its queue size. Here is a tip, use separate sockets for unicast and multicast messages. That way your unicast socket is very unlikely to overrun. So I'd like to see the whole thing reverted. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From vda@port.imtp.ilyichevsk.odessa.ua Sun Sep 19 10:34:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 10:34:24 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8JHYGsG027129 for ; Sun, 19 Sep 2004 10:34:17 -0700 Received: (qmail 17873 invoked by alias); 19 Sep 2004 17:34:01 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 19 Sep 2004 17:34:01 -0000 From: Denis Vlasenko To: Jeff Garzik Subject: [PATCH] reduce stack usage in ixgb_ethtool_ioctl Date: Sun, 19 Sep 2004 20:33:56 +0300 User-Agent: KMail/1.5.4 Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_EMcTBA3AeMpym9O" Message-Id: <200409192033.56716.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 9080 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 5159 Lines: 170 --Boundary-00=_EMcTBA3AeMpym9O Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Stack usage reduced from 3024 (!) to 576. Most of those 3k came from a bug: #define IXGB_REG_DUMP_LEN 136*sizeof(uint32_t) ^^^^^^^^^^^^^^^^^ ... uint32_t regs_buff[IXGB_REG_DUMP_LEN]; Bug fixed. Two large on-stack variables moved to kmalloc space. Stack usage is still high because gcc will allocate too much space for these cases: case ETHTOOL_GSET:{ struct ethtool_cmd ecmd = { ETHTOOL_GSET }; ixgb_ethtool_gset(adapter, &ecmd); if (copy_to_user(addr, &ecmd, sizeof(ecmd))) return -EFAULT; return 0; } case ETHTOOL_SSET:{ struct ethtool_cmd ecmd; if (copy_from_user(&ecmd, addr, sizeof(ecmd))) return -EFAULT; return ixgb_ethtool_sset(adapter, &ecmd); } There will be space for _two_ ecmd's on stack. Shall it be worked around with ugly union of structs or we'll just wait for better gcc? Compile-tested only. -- vda --Boundary-00=_EMcTBA3AeMpym9O Content-Type: text/x-diff; charset="koi8-r"; name="linux-2.6.9-rc2.ixgb_ethtool.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.9-rc2.ixgb_ethtool.patch" diff -urp linux-2.6.9-rc2.src/drivers/net/ixgb/ixgb_ethtool.c linux-2.6.9-rc2.ldelf/drivers/net/ixgb/ixgb_ethtool.c --- linux-2.6.9-rc2.src/drivers/net/ixgb/ixgb_ethtool.c Sat Aug 14 13:56:09 2004 +++ linux-2.6.9-rc2.ldelf/drivers/net/ixgb/ixgb_ethtool.c Sun Sep 19 20:20:12 2004 @@ -180,8 +180,8 @@ ixgb_ethtool_gdrvinfo(struct ixgb_adapte strncpy(drvinfo->fw_version, "N/A", 32); strncpy(drvinfo->bus_info, pci_name(adapter->pdev), 32); drvinfo->n_stats = IXGB_STATS_LEN; -#define IXGB_REG_DUMP_LEN 136*sizeof(uint32_t) - drvinfo->regdump_len = IXGB_REG_DUMP_LEN; +#define IXGB_REG_DUMP_CNT 136 + drvinfo->regdump_len = IXGB_REG_DUMP_CNT*sizeof(uint32_t); drvinfo->eedump_len = ixgb_eeprom_size(&adapter->hw); } @@ -459,6 +459,7 @@ int ixgb_ethtool_ioctl(struct net_device struct ixgb_adapter *adapter = netdev->priv; void __user *addr = ifr->ifr_data; uint32_t cmd; + int err; if (get_user(cmd, (uint32_t __user *) addr)) return -EFAULT; @@ -487,8 +488,8 @@ int ixgb_ethtool_ioctl(struct net_device case ETHTOOL_GSTRINGS:{ struct ethtool_gstrings gstrings = { ETHTOOL_GSTRINGS }; char *strings = NULL; - int err = 0; + err = 0; if (copy_from_user(&gstrings, addr, sizeof(gstrings))) return -EFAULT; switch (gstrings.string_set) { @@ -526,19 +527,28 @@ int ixgb_ethtool_ioctl(struct net_device } case ETHTOOL_GREGS:{ struct ethtool_regs regs = { ETHTOOL_GREGS }; - uint32_t regs_buff[IXGB_REG_DUMP_LEN]; + uint32_t *regs_buff; + err = -ENOMEM; + regs_buff = kmalloc(sizeof(*regs_buff)*IXGB_REG_DUMP_CNT, GFP_KERNEL); + if (!regs_buff) + goto ret_err; + + err = -EFAULT; if (copy_from_user(®s, addr, sizeof(regs))) - return -EFAULT; + goto ret_err; ixgb_ethtool_gregs(adapter, ®s, regs_buff); if (copy_to_user(addr, ®s, sizeof(regs))) - return -EFAULT; + goto ret_err; addr += offsetof(struct ethtool_regs, data); if (copy_to_user(addr, regs_buff, regs.len)) - return -EFAULT; + goto ret_err; + err = 0; - return 0; + ret_err: + kfree(regs_buff); + return err; } case ETHTOOL_NWAY_RST:{ if (netif_running(netdev)) { @@ -565,8 +575,8 @@ int ixgb_ethtool_ioctl(struct net_device struct ethtool_eeprom eeprom = { ETHTOOL_GEEPROM }; uint16_t eeprom_buff[IXGB_EEPROM_SIZE]; void *ptr; - int err = 0; + err = 0; if (copy_from_user(&eeprom, addr, sizeof(eeprom))) return -EFAULT; @@ -609,15 +619,20 @@ int ixgb_ethtool_ioctl(struct net_device return ixgb_ethtool_spause(adapter, &epause); } case ETHTOOL_GSTATS:{ + int i; struct { struct ethtool_stats eth_stats; uint64_t data[IXGB_STATS_LEN]; - } stats = { { - ETHTOOL_GSTATS, IXGB_STATS_LEN}}; - int i; + } *stats; + + stats = kmalloc(sizeof(*stats), GFP_KERNEL); + if (!stats) + return -ENOMEM; + stats->eth_stats.cmd = ETHTOOL_GSTATS; + stats->eth_stats.n_stats = IXGB_STATS_LEN; for (i = 0; i < IXGB_STATS_LEN; i++) - stats.data[i] = + stats->data[i] = (ixgb_gstrings_stats[i].sizeof_stat == sizeof(uint64_t)) ? *(uint64_t *) ((char *) adapter @@ -628,9 +643,11 @@ int ixgb_ethtool_ioctl(struct net_device : *(uint32_t *) ((char *)adapter + ixgb_gstrings_stats[i]. stat_offset); - if (copy_to_user(addr, &stats, sizeof(stats))) - return -EFAULT; - return 0; + err = 0; + if (copy_to_user(addr, stats, sizeof(*stats))) + err = -EFAULT; + kfree(stats); + return err; } case ETHTOOL_GRXCSUM:{ struct ethtool_value edata = { ETHTOOL_GRXCSUM }; --Boundary-00=_EMcTBA3AeMpym9O-- From dave@thedillows.org Sun Sep 19 11:25:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 11:25:11 -0700 (PDT) Received: from iasrv1.idleaire.net (NS1.idleaire.net [65.220.16.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JIP5vN028158 for ; Sun, 19 Sep 2004 11:25:05 -0700 Received: by iasrv1.idleaire.net (Postfix, from userid 300) id 62060236E83; Sun, 19 Sep 2004 14:24:49 -0400 (EDT) Received: from corp4.idleaire.com (corp4.idleaire.com [10.1.66.36]) by iasrv1.idleaire.net (Postfix) with ESMTP id 2FE35236E66; Sun, 19 Sep 2004 14:24:47 -0400 (EDT) Received: from knox.voodoobox.net ([10.1.66.124]) by corp4.idleaire.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 19 Sep 2004 14:24:47 -0400 Subject: Re: [PATCH] reduce stack usage in ixgb_ethtool_ioctl From: Dave Dillow To: Denis Vlasenko Cc: Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <200409192033.56716.vda@port.imtp.ilyichevsk.odessa.ua> References: <200409192033.56716.vda@port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain Message-Id: <1095618283.4870.0.camel@dillow.idleaire.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 19 Sep 2004 14:24:43 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2004 18:24:47.0202 (UTC) FILETIME=[F16CD420:01C49E75] X-archive-position: 9081 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 1000 Lines: 27 On Sun, 2004-09-19 at 13:33, Denis Vlasenko wrote: > Stack usage is still high because gcc will > allocate too much space for these cases: > > case ETHTOOL_GSET:{ > struct ethtool_cmd ecmd = { ETHTOOL_GSET }; > ixgb_ethtool_gset(adapter, &ecmd); > if (copy_to_user(addr, &ecmd, sizeof(ecmd))) > return -EFAULT; > return 0; > } > case ETHTOOL_SSET:{ > struct ethtool_cmd ecmd; > if (copy_from_user(&ecmd, addr, sizeof(ecmd))) > return -EFAULT; > return ixgb_ethtool_sset(adapter, &ecmd); > } > > There will be space for _two_ ecmd's on stack. > > Shall it be worked around with ugly union of structs > or we'll just wait for better gcc? You could convert it to use ethtool_ops. -- Dave Dillow From jgarzik@pobox.com Sun Sep 19 11:28:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 11:28:13 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JIS7tH028503 for ; Sun, 19 Sep 2004 11:28:07 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C96Pj-0002Ox-NS; Sun, 19 Sep 2004 19:27:55 +0100 Message-ID: <414DCF60.1070104@pobox.com> Date: Sun, 19 Sep 2004 14:26:40 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Dillow CC: Denis Vlasenko , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] reduce stack usage in ixgb_ethtool_ioctl References: <200409192033.56716.vda@port.imtp.ilyichevsk.odessa.ua> <1095618283.4870.0.camel@dillow.idleaire.com> In-Reply-To: <1095618283.4870.0.camel@dillow.idleaire.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9082 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1076 Lines: 33 Dave Dillow wrote: > On Sun, 2004-09-19 at 13:33, Denis Vlasenko wrote: > >>Stack usage is still high because gcc will >>allocate too much space for these cases: >> >> case ETHTOOL_GSET:{ >> struct ethtool_cmd ecmd = { ETHTOOL_GSET }; >> ixgb_ethtool_gset(adapter, &ecmd); >> if (copy_to_user(addr, &ecmd, sizeof(ecmd))) >> return -EFAULT; >> return 0; >> } >> case ETHTOOL_SSET:{ >> struct ethtool_cmd ecmd; >> if (copy_from_user(&ecmd, addr, sizeof(ecmd))) >> return -EFAULT; >> return ixgb_ethtool_sset(adapter, &ecmd); >> } >> >>There will be space for _two_ ecmd's on stack. >> >>Shall it be worked around with ugly union of structs >>or we'll just wait for better gcc? > > > You could convert it to use ethtool_ops. Check -mm to make sure viro hasn't already converted it to ethtool_ops... Jeff From vda@port.imtp.ilyichevsk.odessa.ua Sun Sep 19 11:47:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 11:47:52 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8JIli0T029083 for ; Sun, 19 Sep 2004 11:47:47 -0700 Received: (qmail 18291 invoked by alias); 19 Sep 2004 18:47:32 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 19 Sep 2004 18:47:32 -0000 From: Denis Vlasenko To: Jeff Garzik , Dave Dillow Subject: Re: [PATCH] reduce stack usage in ixgb_ethtool_ioctl Date: Sun, 19 Sep 2004 21:47:28 +0300 User-Agent: KMail/1.5.4 Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <200409192033.56716.vda@port.imtp.ilyichevsk.odessa.ua> <1095618283.4870.0.camel@dillow.idleaire.com> <414DCF60.1070104@pobox.com> In-Reply-To: <414DCF60.1070104@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409192147.28268.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 9083 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 1063 Lines: 28 > >> case ETHTOOL_GSET:{ > >> struct ethtool_cmd ecmd = { ETHTOOL_GSET }; > >> ixgb_ethtool_gset(adapter, &ecmd); > >> if (copy_to_user(addr, &ecmd, sizeof(ecmd))) > >> return -EFAULT; > >> return 0; > >> } > >> case ETHTOOL_SSET:{ > >> struct ethtool_cmd ecmd; > >> if (copy_from_user(&ecmd, addr, sizeof(ecmd))) > >> return -EFAULT; > >> return ixgb_ethtool_sset(adapter, &ecmd); > >> } > >> > >>There will be space for _two_ ecmd's on stack. > >> > >>Shall it be worked around with ugly union of structs > >>or we'll just wait for better gcc? > > > > You could convert it to use ethtool_ops. > > Check -mm to make sure viro hasn't already converted it to ethtool_ops... Admit it: it's a conspiracy. Whenever I take some code to hack on, somebody else takes care of it before I do ;) -- vda From pablo@eurodev.net Sun Sep 19 13:46:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 13:46:48 -0700 (PDT) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JKkf9L001829 for ; Sun, 19 Sep 2004 13:46:41 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp08.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919204625.FVBD1184.smtp08.retemail.es@eurodev.net>; Sun, 19 Sep 2004 22:46:25 +0200 Message-ID: <414DF05E.7020601@eurodev.net> Date: Sun, 19 Sep 2004 22:47:26 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------060100000600040505040403" X-archive-position: 9084 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 3385 Lines: 124 This is a multi-part message in MIME format. --------------060100000600040505040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Herbert, Herbert Xu wrote: >Unfortunately it is still wrong. You missed the exit path at the >very top. > > if netlink_broadcast_deliver returns 0, you decrease sock_put. On the other hand if it returns 1, refcount will be decreased by the workqueue handler or after calling the callback. I don't see that exit path. >And I think rather than adding all these new sock_put's, it's much >better to do what you mean and add a sock_hold on the new path that >you introduced. > > yes, it's true that all those sock_put pollutes the source code, I like your idea of add a sock_hold, please could you have a look at the patch attached? it's basically your patch plus netlink_broadcast_deliver revised return value. If you are ok with it, let me know. >Yes but your patch does a lot more than that wake_up_process. Have you >reverted just the wake_up_process and seen a difference? > > Yes, it works as well so we could remove it, but I got some extra throughput with the wake_up_process call if I send something up to 500 consecutive messages from kernel to user space. For more than 1000 I notice that throughput is similar without wake_up_process, I'll study the performance without wake_up_process if it's not a good idea using it as you think. >That's not what I meant. If you have a thread group where everybody's >got the same pid, your code will probably wake up the wrong thread. > > no, my patch doesn't wake up the user process with broadcast sockets, snipped from broadcast_deliver: if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf && !test_bit(0, &nlk->state)) { [...] } return 0; it returns zero then socket overruns. >Besides, for any netlink socket but the first for a process, they'll >all have negative pid's which have nothing to do with the real pid. >So I really think that the wake_up_process hunk is bogus. > > same reply as above, we don't wake up the user process with broadcast sockets. regards, Pablo --------------060100000600040505040403 Content-Type: text/x-patch; name="nl-fix-2.6.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nl-fix-2.6.patch" diff -u -r1.3 af_netlink.c --- a/net/netlink/af_netlink.c 19 Sep 2004 19:46:20 -0000 1.3 +++ b/net/netlink/af_netlink.c 19 Sep 2004 20:04:44 -0000 @@ -629,8 +629,9 @@ kmalloc(sizeof(struct netlink_work), GFP_KERNEL); if (!nlwork) - return -1; - + return 0; + + sock_hold(sk); INIT_WORK(&nlwork->work, netlink_wq_handler, nlwork); nlwork->sk = sk; nlwork->len = skb->len; @@ -638,9 +639,9 @@ } else sk->sk_data_ready(sk, skb->len); - return 0; + return 1; } - return -1; + return 0; } int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, @@ -683,14 +684,13 @@ netlink_overrun(sk); /* Clone failed. Notify ALL listeners. */ failure = 1; - sock_put(sk); } else if (netlink_broadcast_deliver(sk, skb2)) { - netlink_overrun(sk); - sock_put(sk); - } else { delivered = 1; skb2 = NULL; - } + } else + netlink_overrun(sk); + + sock_put(sk); } netlink_unlock_table(); --------------060100000600040505040403-- From pablo@eurodev.net Sun Sep 19 13:49:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 13:49:47 -0700 (PDT) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JKndRA002116 for ; Sun, 19 Sep 2004 13:49:40 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919204923.XDJA10464.smtp09.retemail.es@eurodev.net>; Sun, 19 Sep 2004 22:49:23 +0200 Message-ID: <414DF111.3080409@eurodev.net> Date: Sun, 19 Sep 2004 22:50:25 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> In-Reply-To: <20040919120730.GA6005@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 9085 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1200 Lines: 35 Herbert Xu wrote: >In fact this is the reason why this whole problem is non-existant. > >Unless there is a kernel user that sends netlink messages with a timeout >value other than 0, this patch does not resolve any dead-locks at all >since there is none to start with. > yes, you are totally right, but as I told you before, I'm not focusing my efforts in improving netlink sockets for tools like iproute, for those MSG_DONTWAIT is fairly ok. >So it looks to me as if this entire patch is simply papering over bugs >in the user-space application where it either isn't processing the >messages fast enough or it needs to enlarge its queue size. > > I don't agree, enlarging the queue size for applications that send a lot of information in a short period of time is just a workaround. >Here is a tip, use separate sockets for unicast and multicast messages. >That way your unicast socket is very unlikely to overrun. > >So I'd like to see the whole thing reverted. > > Herbert, I don't agree, my patch isn't related to stuff that you've mentioned. It's fairly true that most çof application use socket timeout 0, but my patch is not for those! :-) well, still disagree? regards, Pablo From pablo@eurodev.net Sun Sep 19 13:49:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 13:49:56 -0700 (PDT) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JKnoer002162 for ; Sun, 19 Sep 2004 13:49:50 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919204934.XDLJ10464.smtp09.retemail.es@eurodev.net>; Sun, 19 Sep 2004 22:49:34 +0200 Message-ID: <414DF11C.1080505@eurodev.net> Date: Sun, 19 Sep 2004 22:50:36 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> In-Reply-To: <20040919120249.GA5963@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9086 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1436 Lines: 39 Herbert Xu wrote: >On Sun, Sep 19, 2004 at 05:58:52PM +1000, Herbert Xu wrote: > > >>Besides, for any netlink socket but the first for a process, they'll >>all have negative pid's which have nothing to do with the real pid. >>So I really think that the wake_up_process hunk is bogus. >> >> > >Another reason why this is bogus. > >Most kernel users of unicast have a send timeout setting of 0. Therefore >your wake_up_process() call will never happen when netlink_attachskb is >called by the kernel. > > Yes, I didn't modify MSG_DONTWAIT + unicast behaviour and I've never wanted to. Actually my patch is not addressed to that case, my intention is improving netlink socket with when sending a lot of information from kernel to user in a short time, in this case socket overruns easily. Which are those applications? for example, netfilter modules like ip_queue and ipt_ULOG. Even more, these applications are in interrupt context and, if I'm not wrong, I realized that there's some problems using netlink sockets in this context, for example, see netlink_ack allocating a skb with GFP_KERNEL flag, it hits a bug slab. >Worse still, previously if a netlink request blocked indefinitely it >only did that in the context of the calling process. Now it'll >dead-lock the entire system because you're using the generic work >queue. > Hebert, I don't see such case, please could you detail it a bit more? regards, Pablo From pablo@eurodev.net Sun Sep 19 13:59:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:00:02 -0700 (PDT) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JKxuX4002965 for ; Sun, 19 Sep 2004 13:59:57 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919205940.XHQB10464.smtp09.retemail.es@eurodev.net>; Sun, 19 Sep 2004 22:59:40 +0200 Message-ID: <414DF37A.4070508@eurodev.net> Date: Sun, 19 Sep 2004 23:00:42 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Pablo Neira CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] fix zombie netlink socket in user space References: <414D18EF.3080207@eurodev.net> In-Reply-To: <414D18EF.3080207@eurodev.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9087 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 209 Lines: 11 Pablo Neira wrote: > If you try to bind/connect to a non existant netlink socket, client > socket gets succesfully inserted as head in the socket list. BTW oh please, forget this patch... regards, Pablo From hadi@cyberus.ca Sun Sep 19 14:03:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:03:17 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JL3BpX003307 for ; Sun, 19 Sep 2004 14:03:12 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C98po-0003t3-7Y for netdev@oss.sgi.com; Sun, 19 Sep 2004 17:03:00 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C98pl-0006CA-Dq; Sun, 19 Sep 2004 17:02:57 -0400 Subject: Re: [PATCH 2.6] fix zombie netlink socket in user space From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolous Message-Id: <1095627770.1049.0.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 17:02:51 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9088 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 721 Lines: 20 Theres also a fundamental issue in trying to control bind/connect behavior with the way this patch tries to "fix" things. Theres at least one app i know of which depends on this. Dave, whats acceptable? My thinking is this should probably be controlled by something like the SE linux path? cheers, jamal On Sun, 2004-09-19 at 04:02, Herbert Xu wrote: > Pablo Neira wrote: > > > > If you try to bind/connect to a non existant netlink socket, client > > socket gets succesfully inserted as head in the socket list. The problem > > is that the head can't be delete, so that socket stays in the list > > forever (see sk_del_node_init). > > Huh? Where does it say that the head can't be deleted? From acme@conectiva.com.br Sun Sep 19 14:04:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:04:27 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JL4JYU003655 for ; Sun, 19 Sep 2004 14:04:20 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id 90E4247539; Sun, 19 Sep 2004 18:04:07 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 44ED3474DF for ; Sun, 19 Sep 2004 18:04:07 -0300 (BRT) Received: (qmail 14125 invoked by uid 0); 19 Sep 2004 22:01:00 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 19 Sep 2004 22:01:00 -0000 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id 9165D1462B; Sun, 19 Sep 2004 18:06:40 -0300 (BRT) Date: Sun, 19 Sep 2004 18:06:40 -0300 From: Arnaldo Carvalho de Melo To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH][NET] Calculate ipv6_pinfo offset from struct proto->slab_obj_size Message-ID: <20040919210639.GA11844@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.5.1i X-Bogosity: No, tests=bogofilter, spamicity=0.496416, version=0.16.3 X-archive-position: 9089 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 5318 Lines: 190 Hi David, Please pull from: bk://kernel.bkbits.net/acme/net-2.6 Best Regards, - Arnaldo =================================================================== ChangeSet@1.1937, 2004-09-19 15:26:01-03:00, acme@conectiva.com.br [NET] Calculate ipv6_pinfo offset from struct proto->slab_obj_size With a new rule for the struct sock hierarchy descendants layout, that states that the struct ipv6_pinfo member should be last one in the struct layout (see tcp6_sock, udp6_sock, sctp6_sock, etc), we can calculate the ipv6_pinfo member offset by using struct proto->slab_obj_size. So ditch struct ipv6_sk_offset and struct proto->af_specific. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller include/linux/ipv6.h | 15 +++++++++------ include/net/sock.h | 1 - net/ipv6/af_inet6.c | 4 ++-- net/ipv6/raw.c | 5 ----- net/ipv6/tcp_ipv6.c | 5 ----- net/ipv6/udp.c | 5 ----- net/sctp/socket.c | 5 ----- 7 files changed, 11 insertions(+), 29 deletions(-) diff -Nru a/include/linux/ipv6.h b/include/linux/ipv6.h --- a/include/linux/ipv6.h Sun Sep 19 17:53:25 2004 +++ b/include/linux/ipv6.h Sun Sep 19 17:53:25 2004 @@ -182,8 +182,7 @@ as offsets from skb->nh. */ -struct inet6_skb_parm -{ +struct inet6_skb_parm { int iif; __u16 ra; __u16 hop; @@ -194,6 +193,14 @@ #define IP6CB(skb) ((struct inet6_skb_parm*)((skb)->cb)) +/** + * struct ipv6_pinfo - ipv6 private area + * + * In the struct sock hierarchy (tcp6_sock, upd6_sock, etc) + * this _must_ be the last member, so that inet6_sk_generic + * is able to calculate its offset from the base struct sock + * by using the struct proto->slab_obj_size member. -acme + */ struct ipv6_pinfo { struct in6_addr saddr; struct in6_addr rcv_saddr; @@ -281,10 +288,6 @@ { return &((struct raw6_sock *)__sk)->raw6; } - -struct ipv6_sk_offset { - int offset; -}; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) #define __ipv6_only_sock(sk) (inet6_sk(sk)->ipv6only) diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h Sun Sep 19 17:53:25 2004 +++ b/include/net/sock.h Sun Sep 19 17:53:25 2004 @@ -557,7 +557,6 @@ kmem_cache_t *slab; int slab_obj_size; - void *af_specific; char name[32]; diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c Sun Sep 19 17:53:25 2004 +++ b/net/ipv6/af_inet6.c Sun Sep 19 17:53:25 2004 @@ -107,9 +107,9 @@ static __inline__ struct ipv6_pinfo *inet6_sk_generic(struct sock *sk) { - const struct ipv6_sk_offset *offset = sk->sk_prot->af_specific; + const int offset = sk->sk_prot->slab_obj_size - sizeof(struct ipv6_pinfo); - return (struct ipv6_pinfo *)(((u8 *)sk) + offset->offset); + return (struct ipv6_pinfo *)(((u8 *)sk) + offset); } static int inet6_create(struct socket *sock, int protocol) diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c Sun Sep 19 17:53:25 2004 +++ b/net/ipv6/raw.c Sun Sep 19 17:53:25 2004 @@ -973,10 +973,6 @@ return(0); } -struct ipv6_sk_offset raw_sock_offset = { - .offset = offsetof(struct raw6_sock, inet6), -}; - struct proto rawv6_prot = { .name = "RAW", .close = rawv6_close, @@ -994,7 +990,6 @@ .hash = raw_v6_hash, .unhash = raw_v6_unhash, .slab_obj_size = sizeof(struct raw6_sock), - .af_specific = &raw_sock_offset, }; #ifdef CONFIG_PROC_FS diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c Sun Sep 19 17:53:25 2004 +++ b/net/ipv6/tcp_ipv6.c Sun Sep 19 17:53:25 2004 @@ -2120,10 +2120,6 @@ } #endif -struct ipv6_sk_offset tcp_sock_offset = { - .offset = offsetof(struct tcp6_sock, inet6), -}; - struct proto tcpv6_prot = { .name = "TCPv6", .close = tcp_close, @@ -2151,7 +2147,6 @@ .sysctl_rmem = sysctl_tcp_rmem, .max_header = MAX_TCP_HEADER, .slab_obj_size = sizeof(struct tcp6_sock), - .af_specific = &tcp_sock_offset, }; static struct inet6_protocol tcpv6_protocol = { diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c Sun Sep 19 17:53:25 2004 +++ b/net/ipv6/udp.c Sun Sep 19 17:53:25 2004 @@ -1031,10 +1031,6 @@ /* ------------------------------------------------------------------------ */ -struct ipv6_sk_offset udp_sock_offset = { - .offset = offsetof(struct udp6_sock, inet6), -}; - struct proto udpv6_prot = { .name = "UDP", .close = udpv6_close, @@ -1051,7 +1047,6 @@ .unhash = udp_v6_unhash, .get_port = udp_v6_get_port, .slab_obj_size = sizeof(struct udp6_sock), - .af_specific = &udp_sock_offset, }; extern struct proto_ops inet6_dgram_ops; diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c Sun Sep 19 17:53:25 2004 +++ b/net/sctp/socket.c Sun Sep 19 17:53:25 2004 @@ -4626,10 +4626,6 @@ }; #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) -struct ipv6_sk_offset sctp_sock_offset = { - .offset = offsetof(struct sctp6_sock, inet6), -}; - struct proto sctpv6_prot = { .name = "SCTPv6", .close = sctp_close, @@ -4650,6 +4646,5 @@ .unhash = sctp_unhash, .get_port = sctp_get_port, .slab_obj_size = sizeof(struct sctp6_sock), - .af_specific = &sctp_sock_offset, }; #endif /* defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) */ From davem@davemloft.net Sun Sep 19 14:05:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:05:36 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JL5Vvr004016 for ; Sun, 19 Sep 2004 14:05:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C98oP-00024V-00; Sun, 19 Sep 2004 14:01:33 -0700 Date: Sun, 19 Sep 2004 14:01:33 -0700 From: "David S. Miller" To: Roland Dreier Cc: netdev@oss.sgi.com Subject: Re: Advice needed on IP-over-InfiniBand driver Message-Id: <20040919140133.60ea3fb3.davem@davemloft.net> In-Reply-To: <52fz5esxx6.fsf@topspin.com> References: <52fz5esxx6.fsf@topspin.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9090 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 369 Lines: 11 You probably want to be editing net/ipv4/arp.c and testing it about Infiniband. Keep neighbour entries in the unresolved stated until both transitions are made: 1) obtain 20 byte address 2) get response from IB subnet manager Only store the destination GID in the neighbour entry, and only mark the neighbour entry as resolved once #2 above completes successfully. From luto@myrealbox.com Sun Sep 19 14:15:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:15:37 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JLFUpP004460 for ; Sun, 19 Sep 2004 14:15:30 -0700 Received: from [10.0.17.163] (ca-westla-cuda4-c9a-76.stmnca.adelphia.net [68.69.232.76]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i8JLEwQO014944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Sep 2004 14:14:59 -0700 Message-ID: <414DF773.7060402@myrealbox.com> Date: Sun, 19 Sep 2004 14:17:39 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> In-Reply-To: <20040917160151.GA29337@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9091 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Content-Length: 1283 Lines: 34 Francois Romieu wrote: > Jon Mason : > [...] > >>Before I make any sweeping comments about the performance on ppc64, I should >>probably do some more tests. I'll have to get back to you regarding that. >> >>Would you like me to run the "Config2" patch on my amd64 system? > > > Please do. If I read you correctly, 2.6.9-rc2-bkX works (more or less) > on both your ppc64 and amd64 systems, right ? No, still broken. But I don't see any change at all in 2.6.9-rc2-bk5. This is on amd64, with 32-bit slots (I think). BTW, the crash is not immediate. It takes several seconds after trying to send/recieve. I say _trying_ because I can't ping anything. I haven't had time before the crash to figure out what's wrong, but the device at the other end does flash that a packet came through the wire. FWIW, it looks like init_board is setting PCIDAC in tp->cp_cmd but that isn't updated to the card until after the rx ring is filled in r8169_open. This seems suspicious, since DMA memory is being allocated possibly in >32-bit addresses but the card hasn't been told to support that. Fixing this doesn't seem to help, though... Turning off high DMA fixes it. Maybe it just needs to be disabled until someone figures out what's going on. --Andy From hadi@cyberus.ca Sun Sep 19 14:19:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:19:42 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JLJbWg004866 for ; Sun, 19 Sep 2004 14:19:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C995h-0006VD-FR for netdev@oss.sgi.com; Sun, 19 Sep 2004 17:19:25 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C995f-0007UQ-CP; Sun, 19 Sep 2004 17:19:23 -0400 Subject: Re: Advice needed on IP-over-InfiniBand driver From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Roland Dreier , netdev@oss.sgi.com In-Reply-To: <20040919140133.60ea3fb3.davem@davemloft.net> References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095628759.1049.22.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 17:19:19 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9092 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 773 Lines: 23 On Sun, 2004-09-19 at 17:01, David S. Miller wrote: > You probably want to be editing net/ipv4/arp.c and testing > it about Infiniband. Keep neighbour entries in the unresolved > stated until both transitions are made: > > 1) obtain 20 byte address > 2) get response from IB subnet manager > > Only store the destination GID in the neighbour entry, > and only mark the neighbour entry as resolved once > #2 above completes successfully. Probably just easier to have his own private tables holding reference to neighbor entries instead of polluting the neighbor tables. Listens to ARP events - on state transition to/from reachable state he queries his remote manager. Curious though if ARP still works even when that "path" thing hasnt been resolved. cheers, jamal From herbert@gondor.apana.org.au Sun Sep 19 14:21:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:21:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JLL1mR005222 for ; Sun, 19 Sep 2004 14:21:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C996r-0000oN-00; Mon, 20 Sep 2004 07:20:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C996o-0002QF-00; Mon, 20 Sep 2004 07:20:34 +1000 Date: Mon, 20 Sep 2004 07:20:34 +1000 To: Pablo Neira Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919212033.GA9254@gondor.apana.org.au> References: <414DF05E.7020601@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414DF05E.7020601@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9093 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2236 Lines: 52 On Sun, Sep 19, 2004 at 10:47:26PM +0200, Pablo Neira wrote: > > if netlink_broadcast_deliver returns 0, you decrease sock_put. On the > other hand if it returns 1, refcount will be decreased by the workqueue > handler or after calling the callback. I don't see that exit path. I'm talking about the bits inside ifdef NL_EMULATE_DEV. > yes, it's true that all those sock_put pollutes the source code, I like > your idea of add a sock_hold, please could you have a look at the patch > attached? it's basically your patch plus netlink_broadcast_deliver > revised return value. If you are ok with it, let me know. It's OK apart from the fact that you missed the bits inside NL_EMULATE_DEV again. > Yes, it works as well so we could remove it, but I got some extra > throughput with the wake_up_process call if I send something up to 500 > consecutive messages from kernel to user space. For more than 1000 I > notice that throughput is similar without wake_up_process, I'll study > the performance without wake_up_process if it's not a good idea using it > as you think. I'm totally happy with the idea of improving the performance of netlink applications. However, let's do it properly rather than adding random wake_up calls. > >That's not what I meant. If you have a thread group where everybody's > >got the same pid, your code will probably wake up the wrong thread. > > no, my patch doesn't wake up the user process with broadcast sockets, > snipped from broadcast_deliver: You didn't understand me. You're waking up a process based on its pid. With thread groups this is simply broken. > >Besides, for any netlink socket but the first for a process, they'll > >all have negative pid's which have nothing to do with the real pid. > >So I really think that the wake_up_process hunk is bogus. > > same reply as above, we don't wake up the user process with broadcast > sockets. I know, that's exactly the reason why it's bogus. You're waking things up on a completely arbitrary basis. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From romieu@fr.zoreil.com Sun Sep 19 14:43:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:43:59 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JLhqBB005916 for ; Sun, 19 Sep 2004 14:43:53 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8JLdrvr001483; Sun, 19 Sep 2004 23:39:53 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8JLdq5U001482; Sun, 19 Sep 2004 23:39:52 +0200 Date: Sun, 19 Sep 2004 23:39:52 +0200 From: Francois Romieu To: Andy Lutomirski Cc: Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040919213952.GA32570@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414DF773.7060402@myrealbox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9094 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 961 Lines: 24 Andy Lutomirski : [...] > FWIW, it looks like init_board is setting PCIDAC in tp->cp_cmd but that > isn't updated to the card until after the rx ring is filled in > r8169_open. This seems suspicious, since DMA memory is being allocated > possibly in >32-bit addresses but the card hasn't been told to support > that. Fixing this doesn't seem to help, though... rtl8169_hw_start() writes the CPlusCmd register before the ring descriptor adresses are set. Can you elaborate why it would not be enough ? Btw the r8169 driver in 2.6.9-rcX does not advertise NETIF_F_HIGHDMA: where would a >32 bit address come from ? > Turning off high DMA fixes it. Maybe it just needs to be disabled until > someone figures out what's going on. I am cooking a patch for it (+ check for PCI error). As a side note, the r8169 chipset does not like DAC to be enabled on a 32bit system. I got the usual PCI error reported while trying it. -- Ueimor From herbert@gondor.apana.org.au Sun Sep 19 14:53:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 14:54:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JLrrhL006407 for ; Sun, 19 Sep 2004 14:53:54 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C99cj-0001Ht-00; Mon, 20 Sep 2004 07:53:33 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C99ce-0002Uv-00; Mon, 20 Sep 2004 07:53:28 +1000 Date: Mon, 20 Sep 2004 07:53:28 +1000 To: Pablo Neira Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919215328.GA9573@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> <414DF111.3080409@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414DF111.3080409@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9095 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1245 Lines: 32 On Sun, Sep 19, 2004 at 10:50:25PM +0200, Pablo Neira wrote: > > yes, you are totally right, but as I told you before, I'm not focusing > my efforts in improving netlink sockets for tools like iproute, for > those MSG_DONTWAIT is fairly ok. No I'm talking not about iproute, I'm talking the kernel callers of unicast/broadcast. They never wait. > I don't agree, enlarging the queue size for applications that send a lot > of information in a short period of time is just a workaround. Workaround for what? Please define your problem. Your original message mentioned a dead-lock, which is now obviously non-existant. > Herbert, I don't agree, my patch isn't related to stuff that you've > mentioned. It's fairly true that most ?of application use socket timeout > 0, but my patch is not for those! :-) well, still disagree? Please reread my messages. I'm not talking about user-space applications setting timeout to 0. Most of them don't. I'm talking about every single kernel netlink sender. They never wait. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 15:00:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:00:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JM0FPq006859 for ; Sun, 19 Sep 2004 15:00:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C99iG-0001JH-00; Mon, 20 Sep 2004 07:59:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C99iF-0002Vx-00; Mon, 20 Sep 2004 07:59:15 +1000 Date: Mon, 20 Sep 2004 07:59:15 +1000 To: Pablo Neira Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919215915.GB9573@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414DF11C.1080505@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9096 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1925 Lines: 45 On Sun, Sep 19, 2004 at 10:50:36PM +0200, Pablo Neira wrote: > > >Another reason why this is bogus. > > > >Most kernel users of unicast have a send timeout setting of 0. Therefore > >your wake_up_process() call will never happen when netlink_attachskb is > >called by the kernel. > > Yes, I didn't modify MSG_DONTWAIT + unicast behaviour and I've never > wanted to. Actually my patch is not addressed to that case, my intention I think this discussion might as well end here, we're obviously not communicating at all. I'm not talking about MSG_DONTWAIT, I'm talking about kernel netlink message senders. They never wait for obvious reasons. > Which are those applications? for example, netfilter modules like > ip_queue and ipt_ULOG. Even more, these applications are in interrupt > context and, if I'm not wrong, I realized that there's some problems > using netlink sockets in this context, for example, see netlink_ack > allocating a skb with GFP_KERNEL flag, it hits a bug slab. Well please define your problem more accurately. A test-case would help. I'd like to see the original patch reverted. We can then sit down and work out what the real problem is (if any). > >Worse still, previously if a netlink request blocked indefinitely it > >only did that in the context of the calling process. Now it'll > >dead-lock the entire system because you're using the generic work > >queue. > > Hebert, I don't see such case, please could you detail it a bit more? As it is since the kernel processing is done in the context of the calling process, it is allowed to sleep indefinitely (semaphore contention, etc.). Now that you've put it into keventd, sleeping indefinitely will lock up the system. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From pablo@eurodev.net Sun Sep 19 15:14:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:14:06 -0700 (PDT) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JME0Do007324 for ; Sun, 19 Sep 2004 15:14:01 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp08.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919221345.HCKS1184.smtp08.retemail.es@eurodev.net>; Mon, 20 Sep 2004 00:13:45 +0200 Message-ID: <414E04D6.5010106@eurodev.net> Date: Mon, 20 Sep 2004 00:14:46 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414DF05E.7020601@eurodev.net> <20040919212033.GA9254@gondor.apana.org.au> In-Reply-To: <20040919212033.GA9254@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9097 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 473 Lines: 20 Hi Herbert, Herbert Xu wrote: >However, let's do it properly rather than adding random wake_up calls. > > When the buffer is full, I wake up the user process and put the kernel thread to sleep to let the user process empty the queue. >You're waking up a process based on its pid. With thread groups this is simply broken. > > I didn't know about netlink applications using thread groups, in that case, submit a patch to delete that wake up call. regards, Pablo From hadi@cyberus.ca Sun Sep 19 15:39:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:39:57 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JMdqtT008246 for ; Sun, 19 Sep 2004 15:39:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C9ALN-0007sg-Jc for netdev@oss.sgi.com; Sun, 19 Sep 2004 18:39:41 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9ALK-0005Nf-GL; Sun, 19 Sep 2004 18:39:39 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040919215915.GB9573@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095633569.1047.107.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 18:39:29 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9098 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 463 Lines: 18 Theres one valuable piece in his patch. Ability to congestion control the kernel so user space can clear the socket queue. The alternative is an overun. You have shot a hole in the workqueue approach. May i also recommend we revert the patch until we have a better resolution, Dave? Pablo you really need to provide some good testcases to prove this. I have my own netlink stress testing that i havent gotten around to testing this issue. cheers, jamal From romieu@fr.zoreil.com Sun Sep 19 15:43:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:43:57 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JMhp7V008686 for ; Sun, 19 Sep 2004 15:43:52 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8JMf7vr002144; Mon, 20 Sep 2004 00:41:07 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8JMf3xe002143; Mon, 20 Sep 2004 00:41:03 +0200 Date: Mon, 20 Sep 2004 00:41:02 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Hans-Frieder Vogt , Andy Lutomirski , Jon Mason , Srihari Vijayaraghavan , netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc2 1/1] r8169: default on disabling PCIDAC Message-ID: <20040919224102.GA32577@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9099 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2350 Lines: 64 Default to disabling PCI DAC as this option appears unsafe on amd64 (original suggestion by Hans-Frieder Vogt ). The driver will typically report PCI System error when something goes wrong. The relevant interrupt is not masked any more and the driver can thus be disabled. Signed-off-by: Francois Romieu diff -puN linux-2.6.9-rc2.orig/drivers/net/r8169.c linux-2.6.9-rc2/drivers/net/r8169.c --- linux-2.6.9-rc2.orig/drivers/net/r8169.c 2004-09-19 00:17:04.000000000 +0200 +++ linux-2.6.9-rc2/drivers/net/r8169.c 2004-09-20 00:16:02.000000000 +0200 @@ -156,6 +156,7 @@ static struct pci_device_id rtl8169_pci_ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); static int rx_copybreak = 200; +static int use_dac; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ @@ -358,6 +359,8 @@ MODULE_AUTHOR("Realtek"); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); MODULE_PARM(media, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(rx_copybreak, "i"); +MODULE_PARM(use_dac, "i"); +MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot."); MODULE_LICENSE("GPL"); static int rtl8169_open(struct net_device *dev); @@ -375,7 +378,7 @@ static int rtl8169_poll(struct net_devic #endif static const u16 rtl8169_intr_mask = - LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; + SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const u16 rtl8169_napi_event = RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = @@ -984,7 +987,7 @@ rtl8169_init_board(struct pci_dev *pdev, tp->cp_cmd = PCIMulRW | RxChkSum; if ((sizeof(dma_addr_t) > 4) && - !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) + !pci_set_dma_mask(pdev, DMA_64BIT_MASK) && use_dac) tp->cp_cmd |= PCIDAC; else { rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); @@ -1761,6 +1764,15 @@ rtl8169_interrupt(int irq, void *dev_ins if (!(status & rtl8169_intr_mask)) break; + if (unlikely(status & SYSErr)) { + printk(KERN_ERR PFX "%s: PCI error (status: 0x%04x)." + " Device disabled.\n", dev->name, status); + RTL_W8(ChipCmd, 0x00); + RTL_W16(IntrMask, 0x0000); + RTL_R16(IntrMask); + break; + } + if (status & LinkChg) rtl8169_check_link_status(dev, tp, ioaddr); From romieu@fr.zoreil.com Sun Sep 19 15:43:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:44:01 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JMhsUX008691 for ; Sun, 19 Sep 2004 15:43:55 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8JMgYvr002149; Mon, 20 Sep 2004 00:42:34 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8JMgVYI002148; Mon, 20 Sep 2004 00:42:31 +0200 Date: Mon, 20 Sep 2004 00:42:31 +0200 From: Francois Romieu To: akpm@osdl.org Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc2-mm1 1/1] r8169: default on disabling PCIDAC Message-ID: <20040919224231.GB32577@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9100 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2387 Lines: 67 Default to disabling PCI DAC as this option appears unsafe on amd64 (original suggestion by Hans-Frieder Vogt ). The driver will typically report PCI System error when something goes wrong. The relevant interrupt is not masked any more and the driver can thus be disabled. Signed-off-by: Francois Romieu diff -puN drivers/net/r8169.c~r8169-145a drivers/net/r8169.c --- linux-2.6.9-rc2/drivers/net/r8169.c~r8169-145a 2004-09-19 00:17:04.000000000 +0200 +++ linux-2.6.9-rc2-fr/drivers/net/r8169.c 2004-09-20 00:16:02.000000000 +0200 @@ -171,6 +171,7 @@ static struct pci_device_id rtl8169_pci_ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); static int rx_copybreak = 200; +static int use_dac; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ @@ -405,6 +406,8 @@ MODULE_AUTHOR("Realtek"); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); MODULE_PARM(media, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(rx_copybreak, "i"); +MODULE_PARM(use_dac, "i"); +MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot."); MODULE_LICENSE("GPL"); static int rtl8169_open(struct net_device *dev); @@ -422,7 +425,7 @@ static int rtl8169_poll(struct net_devic #endif static const u16 rtl8169_intr_mask = - LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; + SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const u16 rtl8169_napi_event = RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = @@ -1162,7 +1165,8 @@ rtl8169_init_board(struct pci_dev *pdev, dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX; - if ((sizeof(dma_addr_t) > 4) && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { + if ((sizeof(dma_addr_t) > 4) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK) && use_dac) { tp->cp_cmd |= PCIDAC; dev->features |= NETIF_F_HIGHDMA; } else { @@ -2050,6 +2054,15 @@ rtl8169_interrupt(int irq, void *dev_ins if (!(status & rtl8169_intr_mask)) break; + if (unlikely(status & SYSErr)) { + printk(KERN_ERR PFX "%s: PCI error (status: 0x%04x)." + " Device disabled.\n", dev->name, status); + RTL_W8(ChipCmd, 0x00); + RTL_W16(IntrMask, 0x0000); + RTL_R16(IntrMask); + break; + } + if (status & LinkChg) rtl8169_check_link_status(dev, tp, ioaddr); _ From pablo@eurodev.net Sun Sep 19 15:48:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:48:30 -0700 (PDT) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JMmOB7009379 for ; Sun, 19 Sep 2004 15:48:24 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp07.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919224808.DILU9737.smtp07.retemail.es@eurodev.net>; Mon, 20 Sep 2004 00:48:08 +0200 Message-ID: <414E0CE6.107@eurodev.net> Date: Mon, 20 Sep 2004 00:49:10 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> <414DF111.3080409@eurodev.net> <20040919215328.GA9573@gondor.apana.org.au> In-Reply-To: <20040919215328.GA9573@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9101 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1852 Lines: 47 Hi Herbert, Sorry, if i repeat things, I'm not willing to be annoying, just clarifying. I'm always talking all the time about sending information from kernel space to user space where I found the problem. There's no problem in doing on the other way, in that case buffer never gets full. Herbert Xu wrote: >Workaround for what? Please define your problem. > > Two problems: a) if you request information via nl sockets from user space and a kernel module doesn't use the dontwait flag (I know, *nobody* is doing this at the moment, so currently broadcast/unicast never wait as you remarked). When we request info from user space (sendmsg), you execute the callback from a module which usually replies with some information (netlink_unicast). The problem happens if the size of the information is too big for the buffer. In that case, before using applying my patch, it hangs (in <2.6.9-rc1, it puts it to sleep if buffer gets full). I'm talking about using unicast/broadcast without dontwait flag. b) A module needs to send a lot of information from kernel space to user space, if buffer gets full quickly, buffer overruns and netlink_unicast/broadcast never wait, so they drop packets. Why someone could call netlink_unicast/broadcast from a module telling them to wait if necessary? if that module want to care about a possible message drop. This happens if you stress nl sockets. This way netlink sockets behave well with an important workload without dropping messages. So the user space part doesn't get that annoying -enobufs error. >Your original message mentioned a dead-lock, which is now obviously non-existant. > > it exists if you use netlink_unicast/broadcast telling them to wait, so it's not a real problem for current applications because they tell netlink_unicast/broadcast not to wait. regards, Pablo From pablo@eurodev.net Sun Sep 19 15:55:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 15:55:09 -0700 (PDT) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JMt3rs009926 for ; Sun, 19 Sep 2004 15:55:04 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp08.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040919225447.HOEN1184.smtp08.retemail.es@eurodev.net>; Mon, 20 Sep 2004 00:54:47 +0200 Message-ID: <414E0E75.30108@eurodev.net> Date: Mon, 20 Sep 2004 00:55:49 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> In-Reply-To: <1095633569.1047.107.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9102 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 602 Lines: 22 Hi Jamal, jamal wrote: >Theres one valuable piece in his patch. Ability to congestion control >the kernel so user space can clear the socket queue. The alternative is >an overun. You have shot a hole in the workqueue approach. May i also >recommend we revert the patch until we have a better resolution, Dave? > > whatever you decided I'll be ok to improve the solution >Pablo you really need to provide some good testcases to prove this. > > Jamal, I told you that I made a tool to stress netlink sockets, I think that it could help. I'll post in some hours to the maillist. regards, Pablo From hadi@cyberus.ca Sun Sep 19 16:04:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 16:04:53 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JN4mZe010407 for ; Sun, 19 Sep 2004 16:04:48 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C9AjW-0003r1-5f for netdev@oss.sgi.com; Sun, 19 Sep 2004 19:04:38 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9AjR-0008LA-4L; Sun, 19 Sep 2004 19:04:33 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Pablo Neira Cc: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <414E0E75.30108@eurodev.net> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <414E0E75.30108@eurodev.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095635068.1050.125.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 19:04:28 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9103 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 978 Lines: 36 Pablo, Please dont be discouraged by this. You have some valuable contribution it just needs to be put in proper context. I am sure Herbert will be than happy to help you clean the patch as will I when i get cycles. Post the stress tool when you get the chance. cheers, jamal On Sun, 2004-09-19 at 18:55, Pablo Neira wrote: > Hi Jamal, > > jamal wrote: > > >Theres one valuable piece in his patch. Ability to congestion control > >the kernel so user space can clear the socket queue. The alternative is > >an overun. You have shot a hole in the workqueue approach. May i also > >recommend we revert the patch until we have a better resolution, Dave? > > > > > > whatever you decided I'll be ok to improve the solution > > >Pablo you really need to provide some good testcases to prove this. > > > > > > Jamal, I told you that I made a tool to stress netlink sockets, I think > that it could help. I'll post in some hours to the maillist. > > regards, > Pablo > From herbert@gondor.apana.org.au Sun Sep 19 16:10:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 16:10:44 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JNAZia010809 for ; Sun, 19 Sep 2004 16:10:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9Aom-0001mI-00; Mon, 20 Sep 2004 09:10:04 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9Aoj-0002cj-00; Mon, 20 Sep 2004 09:10:01 +1000 Date: Mon, 20 Sep 2004 09:10:01 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919231000.GA10073@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <414E0E75.30108@eurodev.net> <1095635068.1050.125.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095635068.1050.125.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9104 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 450 Lines: 11 On Sun, Sep 19, 2004 at 07:04:28PM -0400, jamal wrote: > > Please dont be discouraged by this. You have some valuable contribution > it just needs to be put in proper context. Totally agreed. Pablo, let me thank you for working on this. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 16:18:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 16:18:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JNI8l5011169 for ; Sun, 19 Sep 2004 16:18:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9Aw7-0001nq-00; Mon, 20 Sep 2004 09:17:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9Aw2-0002dx-00; Mon, 20 Sep 2004 09:17:34 +1000 Date: Mon, 20 Sep 2004 09:17:34 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919231734.GA10124@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095633569.1047.107.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9105 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 892 Lines: 20 On Sun, Sep 19, 2004 at 06:39:29PM -0400, jamal wrote: > > Theres one valuable piece in his patch. Ability to congestion control > the kernel so user space can clear the socket queue. The alternative is > an overun. You have shot a hole in the workqueue approach. May i also Congestion control would be a good alternative to overruns. I too would love to see netlink made more reliable if possible. But hopefully without sacrificing the good bits in it like performance. However, in the scenarios that's been cited so far I can't see how it can work. For example, in the ip_queue context, the kernel really doesn't have any alternative to dropping the packet, right? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 16:31:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 16:31:56 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JNVfmm014888 for ; Sun, 19 Sep 2004 16:31:42 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9B9N-0001sX-00; Mon, 20 Sep 2004 09:31:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9B9K-0002fp-00; Mon, 20 Sep 2004 09:31:18 +1000 Date: Mon, 20 Sep 2004 09:31:18 +1000 To: Pablo Neira Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919233118.GB10124@gondor.apana.org.au> References: <414DF05E.7020601@eurodev.net> <20040919212033.GA9254@gondor.apana.org.au> <414E04D6.5010106@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414E04D6.5010106@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9106 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 888 Lines: 21 On Mon, Sep 20, 2004 at 12:14:46AM +0200, Pablo Neira wrote: > > When the buffer is full, I wake up the user process and put the kernel > thread to sleep to let the user process empty the queue. Well that sounds like a good idea but it isn't: 1) You wake up no-one or the wrong process half of the time. 2) Every time a packet is added to the queue the destination process is woken up. So by the time it's full it has been woken up many times already. If all those wake_up's didn't make a difference, then this extra one here isn't likely to either. 3) All kernel callers of this function have timeout set to zero. Therefore they won't even encounter your code. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 16:45:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 16:45:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JNj6lf015403 for ; Sun, 19 Sep 2004 16:45:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9BMP-0001wG-00; Mon, 20 Sep 2004 09:44:49 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9BML-0002hH-00; Mon, 20 Sep 2004 09:44:45 +1000 Date: Mon, 20 Sep 2004 09:44:45 +1000 To: Pablo Neira Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040919234445.GC10124@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> <414DF111.3080409@eurodev.net> <20040919215328.GA9573@gondor.apana.org.au> <414E0CE6.107@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414E0CE6.107@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9107 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2777 Lines: 68 On Mon, Sep 20, 2004 at 12:49:10AM +0200, Pablo Neira wrote: > > Sorry, if i repeat things, I'm not willing to be annoying, just clarifying. You're alright. We're on the same side :) > I'm always talking all the time about sending information from kernel > space to user space where I found the problem. There's no problem in > doing on the other way, in that case buffer never gets full. Yes I understand. > Two problems: > > a) if you request information via nl sockets from user space and a > kernel module doesn't use the dontwait flag (I know, *nobody* is doing > this at the moment, so currently broadcast/unicast never wait as you > remarked). And if anybody does that then they are buggy. So let's not slow everybody down for the sake of a non-existant buggy kernel implementation. There is no point for the kernel to wait at all. For unicast sockets used for sending commands to the kernel, you should never get overruns if you are reading your responses correctly and have set the queue size correctly. > b) A module needs to send a lot of information from kernel space to user > space, if buffer gets full quickly, buffer overruns and > netlink_unicast/broadcast never wait, so they drop packets. I agree that this may be a problem for some, but I don't see how your patch addresses it. For the case of ip_queue the kernel simply cannot wait since it just creates a queue through the backdoor. You might as well just increase your receive queue length. And if your application can't keep up with the flow of packets, then whatever we do in the kernel is not going to help. Congestion control that Jamal talked about is certainly a good idea in many situations. But it can't be applied in the situation you're in because ip_queue can't back off. > Why someone could call netlink_unicast/broadcast from a module telling > them to wait if necessary? if that module want to care about a possible > message drop. This happens if you stress nl sockets. This way netlink > sockets behave well with an important workload without dropping > messages. So the user space part doesn't get that annoying -enobufs error. I don't understand this paragraph. > >Your original message mentioned a dead-lock, which is now obviously > >non-existant. > > it exists if you use netlink_unicast/broadcast telling them to wait, so > it's not a real problem for current applications because they tell > netlink_unicast/broadcast not to wait. s/applications/kernel implementation/ As I said above, if the kernel waits then it's a bug. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From luto@stanford.edu Sun Sep 19 16:49:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 16:49:41 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8JNnZdf015766 for ; Sun, 19 Sep 2004 16:49:35 -0700 Received: from [10.0.17.163] (ca-westla-cuda4-c9a-76.stmnca.adelphia.net [68.69.232.76]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i8JNnCi5020991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 19 Sep 2004 16:49:13 -0700 Message-ID: <414E1B99.4070501@stanford.edu> Date: Sun, 19 Sep 2004 16:51:53 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Andy Lutomirski , Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> <20040919213952.GA32570@electric-eye.fr.zoreil.com> In-Reply-To: <20040919213952.GA32570@electric-eye.fr.zoreil.com> Content-Type: multipart/mixed; boundary="------------020901030109090801060303" X-archive-position: 9108 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@stanford.edu Precedence: bulk X-list: netdev Content-Length: 3376 Lines: 95 This is a multi-part message in MIME format. --------------020901030109090801060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francois Romieu wrote: > Andy Lutomirski : > [...] > >>FWIW, it looks like init_board is setting PCIDAC in tp->cp_cmd but that >>isn't updated to the card until after the rx ring is filled in >>r8169_open. This seems suspicious, since DMA memory is being allocated >>possibly in >32-bit addresses but the card hasn't been told to support >>that. Fixing this doesn't seem to help, though... > > > rtl8169_hw_start() writes the CPlusCmd register before the ring descriptor > adresses are set. Can you elaborate why it would not be enough ? Because rtl8169_init_ring() is called before rtl8169_hw_start() in rtl8169_open(). init_ring allocates the recieve buffers, and I'm assuming that r8169_alloc_rx_skb() can get >32 bits. > > Btw the r8169 driver in 2.6.9-rcX does not advertise NETIF_F_HIGHDMA: where > would a >32 bit address come from ? I was looking at 2.6.9-rc2-mm1, which has (pardon hideous line wrapping): if ((sizeof(dma_addr_t) > 4) && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { tp->cp_cmd |= PCIDAC; dev->features |= NETIF_F_HIGHDMA; ^^^^^^^^^^^^^^^ } else { rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); if (rc < 0) { printk(KERN_ERR PFX "DMA configuration failed.\n"); goto err_out_free_res; } } But I have 512MB RAM, so this probably isn't a problem for me. I'm running x86_64, BTW. > > >>Turning off high DMA fixes it. Maybe it just needs to be disabled until >>someone figures out what's going on. > > > I am cooking a patch for it (+ check for PCI error). > > As a side note, the r8169 chipset does not like DAC to be enabled on a > 32bit system. I got the usual PCI error reported while trying it. Will this be ready for 2.6.9? Otherwise it would probably be better to just disable DAC so the driver keeps working. On an unrelated note, I just took a look at the PHY timer code. It looks like the PHY timer will never reactivate once it shuts off, which means that the resetting is completely deterministic and the printk conveys no useful information. Can we just delete it (patch attached -- this computer mangles them)? What does it do, anyway? If it is necessary for someone's card (not mine) to acquire a gigabit link (which is what it seemed to do in old versions of the driver), then we're _still_ broken for the case where they drop the link and try to reacquire it. Would it make sense to remove the reset_enable stuff in -mm for awhile and see if anyone complains? --Andy --------------020901030109090801060303 Content-Type: text/plain; name="r8169-quiet.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r8169-quiet.txt" Index: 2.6.9-rc2-mm1/drivers/net/r8169.c =================================================================== --- 2.6.9-rc2-mm1.orig/drivers/net/r8169.c 2004-09-19 16:43:09.725537944 -0700 +++ 2.6.9-rc2-mm1/drivers/net/r8169.c 2004-09-19 16:50:33.900013160 -0700 @@ -1044,8 +1044,6 @@ if (tp->link_ok(ioaddr)) goto out_unlock; - printk(KERN_WARNING PFX "%s: PHY reset until link up\n", dev->name); - tp->phy_reset_enable(ioaddr); out_mod_timer: --------------020901030109090801060303-- From pablo@eurodev.net Sun Sep 19 17:30:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 17:30:53 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K0UkgT016550 for ; Sun, 19 Sep 2004 17:30:47 -0700 Received: from eurodev.net ([217.217.184.93]) by smtp06.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040920003030.OSHL11445.smtp06.retemail.es@eurodev.net>; Mon, 20 Sep 2004 02:30:30 +0200 Message-ID: <414E24E4.1020104@eurodev.net> Date: Mon, 20 Sep 2004 02:31:32 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , jamal , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> <414DF111.3080409@eurodev.net> <20040919215328.GA9573@gondor.apana.org.au> <414E0CE6.107@eurodev.net> <20040919234445.GC10124@gondor.apana.org.au> In-Reply-To: <20040919234445.GC10124@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9109 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1893 Lines: 57 Hi Herbert, Herbert Xu wrote: >On Mon, Sep 20, 2004 at 12:49:10AM +0200, Pablo Neira wrote: > > >>Sorry, if i repeat things, I'm not willing to be annoying, just clarifying. >> >> > >You're alright. We're on the same side :) > > that's fine :) >There is no point for the kernel to wait at all. For unicast sockets >used for sending commands to the kernel, you should never get overruns >if you are reading your responses correctly and have set the queue size >correctly. > > sure, not for commands. When I talk about netlink sockets, I'm not focused on commands because what they do currently is quite enough for them I think. I know that commands are the main application of netlink sockets but there are many others. >>b) A module needs to send a lot of information from kernel space to user >>space, if buffer gets full quickly, buffer overruns and >>netlink_unicast/broadcast never wait, so they drop packets. >> >> > >I agree that this may be a problem for some, but I don't see how your >patch addresses it. For the case of ip_queue the kernel simply cannot >wait since it just creates a queue through the backdoor. You might as >well just increase your receive queue length. > > I agree, ip_queue case is kind of complex. Well, think about a logging tool for packets in kernel space that sends messages via netlink when a packet matches a condition. Now, we receive 300 packets in a very very short period of time (with the default buffer size) and after that everything' gets calm again, that is, there's nothing to send to user space. In that case, netlink buffer will surely overrun, so those 300 messages will be drop because kernel didn't wait a bit. This is what happens now, I can reproduce this with my tool. Well, if system work load is high (in term of sending netlink messages), we don't have too many things to do... regards, Pablo From hadi@cyberus.ca Sun Sep 19 17:40:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 17:40:07 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K0e2Yd017023 for ; Sun, 19 Sep 2004 17:40:03 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C9CDg-0001jk-1B for netdev@oss.sgi.com; Sun, 19 Sep 2004 20:39:52 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9CDb-0002Rt-Od; Sun, 19 Sep 2004 20:39:48 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20040918203319.24004d6e.davem@davemloft.net> References: <20040918203319.24004d6e.davem@davemloft.net> Content-Type: multipart/mixed; boundary="=-3cWj/G40spLwEklC0FOz" Organization: jamalopolous Message-Id: <1095640781.1047.168.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 20:39:43 -0400 X-archive-position: 9110 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1093 Lines: 49 --=-3cWj/G40spLwEklC0FOz Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2004-09-18 at 23:33, David S. Miller wrote: > So, before we even think about trying new faster algorithms > in net/ipv4/fib_hash.c we have to clean it up. Will look at rest of patch and get back to you. Curious piece like you note: > Does anyone know what this test: > > if (!iter->zone->fz_next) > continue; > > in fib_get_first() is doing? I kept it there > but it looks fishy. Yes, it is fishy;-> patch attached. Probably one of the more interesting typos i have seen recently cheers, jamal --=-3cWj/G40spLwEklC0FOz Content-Disposition: attachment; filename=fibhash_p Content-Type: text/plain; name=fibhash_p; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/net/ipv4/fib_hash.c 2004/09/20 00:35:16 1.1 +++ b/net/ipv4/fib_hash.c 2004/09/20 00:36:16 @@ -915,7 +915,7 @@ iter->zone = iter->zone->fz_next) { int maxslot; - if (!iter->zone->fz_next) + if (!iter->zone->fz_nent) continue; iter->hash = iter->zone->fz_hash; --=-3cWj/G40spLwEklC0FOz-- From herbert@gondor.apana.org.au Sun Sep 19 18:01:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 18:01:39 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K11THL017642 for ; Sun, 19 Sep 2004 18:01:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9CYB-0002PQ-00; Mon, 20 Sep 2004 11:01:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9CY3-0002p1-00; Mon, 20 Sep 2004 11:00:55 +1000 Date: Mon, 20 Sep 2004 11:00:55 +1000 To: Pablo Neira Cc: "David S. Miller" , jamal , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040920010055.GA10793@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au> <414DF111.3080409@eurodev.net> <20040919215328.GA9573@gondor.apana.org.au> <414E0CE6.107@eurodev.net> <20040919234445.GC10124@gondor.apana.org.au> <414E24E4.1020104@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414E24E4.1020104@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9111 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1674 Lines: 39 On Mon, Sep 20, 2004 at 02:31:32AM +0200, Pablo Neira wrote: > > >There is no point for the kernel to wait at all. For unicast sockets > >used for sending commands to the kernel, you should never get overruns > >if you are reading your responses correctly and have set the queue size > >correctly. > > sure, not for commands. When I talk about netlink sockets, I'm not > focused on commands because what they do currently is quite enough for > them I think. I know that commands are the main application of netlink > sockets but there are many others. My message was in response to your problem a) which looks exactly like a command. > >>b) A module needs to send a lot of information from kernel space to user > >>space, if buffer gets full quickly, buffer overruns and > >>netlink_unicast/broadcast never wait, so they drop packets. > > In that case, netlink buffer will surely overrun, so those 300 messages > will be drop because kernel didn't wait a bit. This is what happens now, > I can reproduce this with my tool. Well I see two solutions. You either extend the receive queue or tell the kernel to stop sending. The second is not an option here because you'll lose the packets anyway. Getting the kernel to wait is NOT a solution. It's just another form of extending the receive queue, albeit an ugly one. But hang on a second, the kernel should've woken up your process after the very first message. Why isn't that happening? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Sun Sep 19 18:52:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 18:52:09 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K1q42i018429 for ; Sun, 19 Sep 2004 18:52:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C9DLN-00061v-EJ for netdev@oss.sgi.com; Sun, 19 Sep 2004 21:51:53 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9DLL-00037T-8V; Sun, 19 Sep 2004 21:51:51 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20040918203319.24004d6e.davem@davemloft.net> References: <20040918203319.24004d6e.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095645106.1048.190.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 21:51:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9112 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1626 Lines: 44 On Sat, 2004-09-18 at 23:33, David S. Miller wrote: [..] > So this patch below attempts to do two things: > > 1) Split fib_node to fib_node and fib_alias. > > The fib_node is purely a lookup object keyed > on destination address and prefix only. > Any new lookup algorithm we attempt will modify > _only_ the code handling fib_node objects. > > The fib_alias, on the other hand, describes > a sub-route of a fib_node that has different > TOS and PRIORITY keys. Each fib_node has > a list of fib_alias objects. > > 2) Use linux/list.h list facilities instead of > by-hand list implementations. I havent tested or patched. the list changes are nice. I wasnt %100 sure about the need to separate fib node into those two. It seems to complicate things. If you want to allow introduction of new algos, then fib_node itself is gonna have to go as well IMO. Its an artifact or current alg. I am actually thinking nothing at all stays of fib_hash.c for any new algorithm. Infact thats the only new piece/file that a new algorithm should write. > I would say that the most complicated part of the > patch below is the insertion handling. If an > entry exists matching the insert request, we have > to check if this is an exclusive add. If so, > then we error, else we append/prepend to the alias > list depending upon what the user asked for. Finally > we also have to check if we are doing a replace. After patching and/or testing i can give you more feedback. BTW, one thought to improve perfomance is to change the linked list in each of the buckets away from a linked list. cheers, jamal From davem@davemloft.net Sun Sep 19 19:38:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 19:38:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K2cJCf019401 for ; Sun, 19 Sep 2004 19:38:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9E0O-0002S2-00; Sun, 19 Sep 2004 19:34:16 -0700 Date: Sun, 19 Sep 2004 19:34:15 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: roland@topspin.com, netdev@oss.sgi.com Subject: Re: Advice needed on IP-over-InfiniBand driver Message-Id: <20040919193415.6dc96cab.davem@davemloft.net> In-Reply-To: <1095628759.1049.22.camel@jzny.localdomain> References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <1095628759.1049.22.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9113 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 806 Lines: 18 On 19 Sep 2004 17:19:19 -0400 jamal wrote: > Probably just easier to have his own private tables holding reference to > neighbor entries instead of polluting the neighbor tables. > Listens to ARP events - on state transition to/from reachable state he > queries his remote manager. > Curious though if ARP still works even when that "path" thing hasnt been > resolved. It sounds like a two-stage thing, the first stage lets you talk on the subnet and get to the IB subnet manager, and the second stage lets you acually speak IP. My understanding, from his description, is that once the second stage part is complete you don't need to first stage address information at all. The reason I suggested the scheme the way that I did was so that the hh_cache can work fully for IP over IB. From hadi@cyberus.ca Sun Sep 19 19:39:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 19:39:30 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K2dP3U019588 for ; Sun, 19 Sep 2004 19:39:25 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C9E5D-0003MM-H6 for netdev@oss.sgi.com; Sun, 19 Sep 2004 22:39:15 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9E57-00088u-O6; Sun, 19 Sep 2004 22:39:10 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040919231734.GA10124@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095647944.1046.206.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Sep 2004 22:39:04 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9114 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1236 Lines: 27 On Sun, 2004-09-19 at 19:17, Herbert Xu wrote: > Congestion control would be a good alternative to overruns. I too would > love to see netlink made more reliable if possible. But hopefully without > sacrificing the good bits in it like performance. Agreed. Note the fact that netlink can set the socket error flag provides it with the workings needed for reliability i.e you get to know about lost messages. If an overun occurs you (app) gets to know about it. You just have to poll, unfortunately, for everything _again_. > However, in the scenarios that's been cited so far I can't see how it can > work. For example, in the ip_queue context, the kernel really doesn't > have any alternative to dropping the packet, right? I havent paid a lot of attention to ip_queue workings. But something that will get the kernel to backoff when a certain socket threshold gets exceeded then get it going again when a below a low watermak. Dumps already have markers stored in the callbacks, maybe something a long the same line of thinking. You may have to tell user space "theres more coming". Not sure how to achieve this, just brainstorming. Essentially this is where the improvements over std overun signaling is, IMO. cheers, jamal From davem@davemloft.net Sun Sep 19 19:50:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 19:50:53 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K2omRG020163 for ; Sun, 19 Sep 2004 19:50:48 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9ECR-0002Tg-00; Sun, 19 Sep 2004 19:46:43 -0700 Date: Sun, 19 Sep 2004 19:46:42 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040919194642.11213625.davem@davemloft.net> In-Reply-To: <1095640781.1047.168.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095640781.1047.168.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9115 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 614 Lines: 22 On 19 Sep 2004 20:39:43 -0400 jamal wrote: > Will look at rest of patch and get back to you. Curious piece like you > note: > > > Does anyone know what this test: > > > > if (!iter->zone->fz_next) > > continue; > > > > in fib_get_first() is doing? I kept it there > > but it looks fishy. > > Yes, it is fishy;-> patch attached. Probably one of the more interesting > typos i have seen recently Aha, yes, if you look at the original code before this stuff was converted to use seq_file, and therefore the 2.4.x copy of this code, the typo is even more obvious. Good spotting Jamal. From jgarzik@pobox.com Sun Sep 19 19:57:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 19:57:17 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K2vCaO020664 for ; Sun, 19 Sep 2004 19:57:13 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9EMO-0006ud-UF; Mon, 20 Sep 2004 03:57:01 +0100 Message-ID: <414E46F1.9050309@pobox.com> Date: Sun, 19 Sep 2004 22:56:49 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Andy Lutomirski , Hans-Frieder Vogt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> <20040919213952.GA32570@electric-eye.fr.zoreil.com> In-Reply-To: <20040919213952.GA32570@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9116 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 273 Lines: 11 Francois Romieu wrote: > rtl8169_hw_start() writes the CPlusCmd register before the ring descriptor > adresses are set. Can you elaborate why it would not be enough ? That sounds like a bug right there... need all the addresses set up before we turn on stuff. Jeff From davem@davemloft.net Sun Sep 19 19:58:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 19:58:26 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K2wLBe020878 for ; Sun, 19 Sep 2004 19:58:21 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9EJL-0002Ua-00; Sun, 19 Sep 2004 19:53:51 -0700 Date: Sun, 19 Sep 2004 19:53:51 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040919195351.0b3560e6.davem@davemloft.net> In-Reply-To: <1095645106.1048.190.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9117 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2075 Lines: 52 On 19 Sep 2004 21:51:46 -0400 jamal wrote: > I wasnt %100 sure about the need to > separate fib node into those two. It seems to complicate things. > If you want to allow introduction of new algos, then fib_node itself is > gonna have to go as well IMO. Its an artifact or current alg. > I am actually thinking nothing at all stays of fib_hash.c for any new > algorithm. Infact thats the only new piece/file that a new algorithm > should write. There are two problems. Well, logically one, which is the seperation out of fib_node from the code. I need to expose the layout of fib_node for other reasons. If you look at Ben LaHaise's case, the issue becomes evident. Firstly, fib_semantics was not designed to scale at all, thus last weeks patches to add the hash tables. That takes care of half of his problems, the other half is because of fn_hash_flush() and is what is relevant to this discussion. fn_hash_flush() walks the entire table of routes looking for routes pointing to fib_info objects which are RTNH_F_DEAD. The simple solution is to make fib_info contain a list of fib_node objects, then when code marks a fib_info as RTNH_F_DEAD we just walk the list and kill the fib_node objects directly. But because the layout of fib_node entirely is hidden in fib_hash.c, and we want to allow pluggable lookup implementations, something has to give. So the general idea I was after was: 1) All things performing pure longest-matching prefix lookup on an ipv4 address is confined to fib_node objects and the actual lookup algorithm. 2) Everything that occurs once we have a matching fib_node object, is consolidated into a common pieces of code that does all the TOS, priority, et al. magic Anyways, we can do this differently. But at least with my patch we have the means to do _something_. > BTW, one thought to improve perfomance is to change the linked list in > each of the buckets away from a linked list. Come again? I'm a little slow today, you'll have to be a bit more explicit about what your idea is exactly :-) From herbert@gondor.apana.org.au Sun Sep 19 19:58:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 19:58:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K2wacp021045 for ; Sun, 19 Sep 2004 19:58:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9ENX-0002r8-00; Mon, 20 Sep 2004 12:58:11 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9ENP-00031Y-00; Mon, 20 Sep 2004 12:58:03 +1000 Date: Mon, 20 Sep 2004 12:58:02 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040920025802.GA11567@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095647944.1046.206.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9118 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1536 Lines: 36 On Sun, Sep 19, 2004 at 10:39:04PM -0400, jamal wrote: > > > However, in the scenarios that's been cited so far I can't see how it can > > work. For example, in the ip_queue context, the kernel really doesn't > > have any alternative to dropping the packet, right? > > I havent paid a lot of attention to ip_queue workings. But something Well the ip_queue thing is simply a pipe that redirects packets going into netfilter to user space. So we can't really stop that pipe when there is congestion. AFAICT the problem Pablo is trying to solve is packet loss due to netlink congestion. There might actually be a problem with the kernel not waking up the the user process when we tell it to. It might even be a scheduling problem. But we'll need a test-case to assess that. > that will get the kernel to backoff when a certain socket threshold gets > exceeded then get it going again when a below a low watermak. Dumps > already have markers stored in the callbacks, maybe something a long the > same line of thinking. You may have to tell user space "theres more > coming". Not sure how to achieve this, just brainstorming. > Essentially this is where the improvements over std overun signaling is, > IMO. This might work. But we really need to look at something concrete to see what the implications are. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Sun Sep 19 20:15:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 20:15:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K3FL1X021964 for ; Sun, 19 Sep 2004 20:15:22 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9Edq-0002xc-00; Mon, 20 Sep 2004 13:15:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9Edi-00033O-00; Mon, 20 Sep 2004 13:14:54 +1000 From: Herbert Xu To: hadi@cyberus.ca Subject: Re: [PATCH] Clean up fib_hash datastructures Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <1095640781.1047.168.camel@jzny.localdomain> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 20 Sep 2004 13:14:54 +1000 X-archive-position: 9119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 820 Lines: 24 jamal wrote: > > --- a/net/ipv4/fib_hash.c 2004/09/20 00:35:16 1.1 > +++ b/net/ipv4/fib_hash.c 2004/09/20 00:36:16 > @@ -915,7 +915,7 @@ > iter->zone = iter->zone->fz_next) { > int maxslot; > > - if (!iter->zone->fz_next) > + if (!iter->zone->fz_nent) > continue; Good catch. There seems to be another problem with the seq_file conversion. Why is this check only in fib_get_first(), but not in fib_get_next()? Either it's needed in fib_get_next() as well, or it can be removed here. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sun Sep 19 20:21:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 20:21:54 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K3LoRm025579 for ; Sun, 19 Sep 2004 20:21:50 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9EgK-0002cD-00; Sun, 19 Sep 2004 20:17:36 -0700 Date: Sun, 19 Sep 2004 20:17:35 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040919201735.3d9e1d6d.davem@davemloft.net> In-Reply-To: References: <1095640781.1047.168.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 891 Lines: 26 On Mon, 20 Sep 2004 13:14:54 +1000 Herbert Xu wrote: > jamal wrote: > > > > --- a/net/ipv4/fib_hash.c 2004/09/20 00:35:16 1.1 > > +++ b/net/ipv4/fib_hash.c 2004/09/20 00:36:16 > > @@ -915,7 +915,7 @@ > > iter->zone = iter->zone->fz_next) { > > int maxslot; > > > > - if (!iter->zone->fz_next) > > + if (!iter->zone->fz_nent) > > continue; > > Good catch. There seems to be another problem with the seq_file > conversion. Why is this check only in fib_get_first(), but not > in fib_get_next()? > > Either it's needed in fib_get_next() as well, or it can be removed here. It's an optimization, the hash list traversal will find no entries even if we don't do this test. It does belong in fib_get_next(), so I'll happily add it there. Thanks. From acme@conectiva.com.br Sun Sep 19 20:30:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 20:30:19 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K3UCNZ026010 for ; Sun, 19 Sep 2004 20:30:15 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id 5EC224797D; Mon, 20 Sep 2004 00:30:01 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id F3E2F47974 for ; Mon, 20 Sep 2004 00:30:00 -0300 (BRT) Received: (qmail 15290 invoked by uid 0); 20 Sep 2004 04:26:53 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 20 Sep 2004 04:26:53 -0000 Received: by oops.ghostprotocols.net (Postfix, from userid 500) id D9829755CB; Mon, 20 Sep 2004 00:32:35 -0300 (BRT) Date: Mon, 20 Sep 2004 00:32:35 -0300 From: Arnaldo Carvalho de Melo To: cranium2003 Cc: netdev@oss.sgi.com Subject: Re: Protocol handler question Message-ID: <20040920033235.GB29504@conectiva.com.br> References: <20040919021839.20368.qmail@web41406.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040919021839.20368.qmail@web41406.mail.yahoo.com> X-Url: http://advogato.org/person/acme User-Agent: Mutt/1.5.5.1i X-Bogosity: No, tests=bogofilter, spamicity=0.000590, version=0.16.3 X-archive-position: 9121 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 186 Lines: 8 Em Sat, Sep 18, 2004 at 07:18:39PM -0700, cranium2003 escreveu: > Hello, > can it be possible to have two packet types to have > same protocol handler? see net/ipx/af_ipx.c - Arnaldo From roland@topspin.com Sun Sep 19 21:43:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 21:43:15 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K4hBKX027370 for ; Sun, 19 Sep 2004 21:43:11 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Sun, 19 Sep 2004 21:43:00 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 19 Sep 2004 21:43:00 -0700 Received: from roland by eddore with local (Exim 4.34) id 1C9G0x-0000yB-Of; Sun, 19 Sep 2004 21:43:00 -0700 To: "David S. Miller" Cc: netdev@oss.sgi.com X-Message-Flag: Warning: May contain useful information References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> From: Roland Dreier Date: Sun, 19 Sep 2004 21:42:59 -0700 In-Reply-To: <20040919140133.60ea3fb3.davem@davemloft.net> (David S. Miller's message of "Sun, 19 Sep 2004 14:01:33 -0700") Message-ID: <523c1dsg8c.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 20 Sep 2004 04:43:00.0122 (UTC) FILETIME=[4E873FA0:01C49ECC] X-archive-position: 9122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 951 Lines: 25 David> You probably want to be editing net/ipv4/arp.c and testing "teaching" not "testing" I assume :) David> it about Infiniband. Keep neighbour entries in the David> unresolved stated until both transitions are made: David> 1) obtain 20 byte address 2) get response from IB subnet David> manager David> Only store the destination GID in the neighbour entry, and David> only mark the neighbour entry as resolved once #2 above David> completes successfully. Hmm... it looks like the place you're telling me to hook into is in arp_process() right before the neigh state gets set to NUD_REACHABLE. But where should I stick the path information that I get back from the subnet manager once the query finishes? And how does the path get passed into the device driver to actually send an skb? (Sorry to be so dense but I'm afraid my little brain needs things broken down into bite-sized pieces...) Thanks, Roland From roland@topspin.com Sun Sep 19 21:49:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 21:49:46 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K4nfK4027804 for ; Sun, 19 Sep 2004 21:49:41 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Sun, 19 Sep 2004 21:49:31 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 19 Sep 2004 21:49:31 -0700 Received: from roland by eddore with local (Exim 4.34) id 1C9G7B-0000yd-SG; Sun, 19 Sep 2004 21:49:31 -0700 To: hadi@cyberus.ca Cc: "David S. Miller" , netdev@oss.sgi.com X-Message-Flag: Warning: May contain useful information References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <1095628759.1049.22.camel@jzny.localdomain> From: Roland Dreier Date: Sun, 19 Sep 2004 21:49:25 -0700 In-Reply-To: <1095628759.1049.22.camel@jzny.localdomain> (jamal's message of "19 Sep 2004 17:19:19 -0400") Message-ID: <52y8j5r1d6.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 20 Sep 2004 04:49:31.0200 (UTC) FILETIME=[37A10400:01C49ECD] X-archive-position: 9123 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 853 Lines: 23 jamal> Probably just easier to have his own private tables holding jamal> reference to neighbor entries instead of polluting the jamal> neighbor tables. Listens to ARP events - on state jamal> transition to/from reachable state he queries his remote jamal> manager. This does seem neater, but I don't know how to implement it. How does one hook into ARP events? jamal> Curious though if ARP still works even when that "path" jamal> thing hasnt been resolved. ARP works because we can send broadcasts even without a path to a specific destination. (I'm leaving out the details of how IP broadcast gets mapped to InfiniBand multicast) When the system with the IP we're looking for receives a broadcast ARP, it can use the HW address in the ARP request to look up a path, so it can send an ARP reply. Thanks, Roland From roland@topspin.com Sun Sep 19 21:52:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 21:52:05 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K4q0d3028197 for ; Sun, 19 Sep 2004 21:52:00 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Sun, 19 Sep 2004 21:51:50 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 19 Sep 2004 21:51:50 -0700 Received: from roland by eddore with local (Exim 4.34) id 1C9G9V-0000yr-67; Sun, 19 Sep 2004 21:51:50 -0700 To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com X-Message-Flag: Warning: May contain useful information References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <1095628759.1049.22.camel@jzny.localdomain> <20040919193415.6dc96cab.davem@davemloft.net> From: Roland Dreier Date: Sun, 19 Sep 2004 21:51:49 -0700 In-Reply-To: <20040919193415.6dc96cab.davem@davemloft.net> (David S. Miller's message of "Sun, 19 Sep 2004 19:34:15 -0700") Message-ID: <52u0ttr196.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 20 Sep 2004 04:51:50.0138 (UTC) FILETIME=[8A7145A0:01C49ECD] X-archive-position: 9124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 848 Lines: 17 David> It sounds like a two-stage thing, the first stage lets you David> talk on the subnet and get to the IB subnet manager, and David> the second stage lets you acually speak IP. My David> understanding, from his description, is that once the David> second stage part is complete you don't need to first stage David> address information at all. Pretty much... ARP gives you a unique identifier for the port with the IP address you're looking for. Then you need to take that unique identifier and ask the subnet manager what path to use to get from your local port to that destination port. (Talking to the subnet manager uses an InfiniBand native, non-IP mechanism -- one of the first things the subnet manager does is go over the whole fabric and tell each port what path to use to send it queries) Thanks, Roland From pekkas@netcore.fi Sun Sep 19 22:09:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 22:09:23 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K59HIw028917 for ; Sun, 19 Sep 2004 22:09:18 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8K58aH23148; Mon, 20 Sep 2004 08:08:41 +0300 Date: Mon, 20 Sep 2004 08:08:36 +0300 (EEST) From: Pekka Savola To: Harald Welte cc: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , , , Subject: Re: 2.6.8.1 IPv6 Routing Problem In-Reply-To: <20040919074605.GJ6005@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 892 Lines: 25 On Sun, 19 Sep 2004, Harald Welte wrote: > Apparently this happens when you > > 1) insmod ipv6 > 2) ifconfig your interfaces up > 3) only now ifconfig 'lo' up. > > This happened due to a typo in my script :( If 'lo' exists prior to the > other interfaces, everything seems to work as usual. > > Is this desired or accidential and/or documented behaviour? AFAIK, it's not documented, but known among developers (in general): there's a lot of magic tied to the loopback interface, and lots of things (like ND) break very badly if it's not always up and running appropriately.. This has bitten people so many times that it might be useful to try to mitigate the problem somehow, if feasible... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From yoshfuji@linux-ipv6.org Sun Sep 19 23:20:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 23:20:23 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K6KGw4030391 for ; Sun, 19 Sep 2004 23:20:16 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id D1AD133CE5; Mon, 20 Sep 2004 15:20:14 +0900 (JST) Date: Mon, 20 Sep 2004 15:20:12 +0900 (JST) Message-Id: <20040920.152012.114156249.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi, davem@davemloft.net Cc: laforge@gnumonks.org, davem@davemloft.net, netdev@oss.sgi.com, usagi-users@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040919074605.GJ6005@sunbeam.de.gnumonks.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9126 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1608 Lines: 49 In article (at Mon, 20 Sep 2004 08:08:36 +0300 (EEST)), Pekka Savola says: > On Sun, 19 Sep 2004, Harald Welte wrote: > > Apparently this happens when you > > > > 1) insmod ipv6 > > 2) ifconfig your interfaces up > > 3) only now ifconfig 'lo' up. > > > > This happened due to a typo in my script :( If 'lo' exists prior to the > > other interfaces, everything seems to work as usual. > > > > Is this desired or accidential and/or documented behaviour? > > AFAIK, it's not documented, but known among developers (in general): > there's a lot of magic tied to the loopback interface, and lots of > things (like ND) break very badly if it's not always up and running > appropriately.. I agree that it is not documented. This behavior lives for years (AFAIK), and we haven't got so many reports because people usually bring loopback device first. I think the following message will help people, anyway. Signed-off-by: Hideaki YOSHIFUJI ===== net/ipv6/route.c 1.94 vs edited ===== --- 1.94/net/ipv6/route.c 2004-09-15 06:03:30 +09:00 +++ edited/net/ipv6/route.c 2004-09-20 14:59:08 +09:00 @@ -1373,6 +1373,12 @@ if (rt == NULL) return ERR_PTR(-ENOMEM); + if (!(loopback_dev.flags & IFF_UP)) { + printk(KERN_WARNING "INET6: please bring loopback device up" + "first.\n"); + return ERR_PTR(-ENETDOWN); + } + dev_hold(&loopback_dev); in6_dev_hold(idev); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From anton@ozlabs.org Sun Sep 19 23:32:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 19 Sep 2004 23:32:41 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K6WZWU030915 for ; Sun, 19 Sep 2004 23:32:35 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 2512B2BDAB; Mon, 20 Sep 2004 16:32:19 +1000 (EST) Date: Mon, 20 Sep 2004 16:30:13 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Subject: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040920063012.GL2825@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9127 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 4394 Lines: 68 Hi, I just tried latest 2.6.9-rc2-BK on a machine with an e1000 on it. With TSO off it does about 100MB/sec. With TSO on it does between 1MB/sec and 10MB/sec. Here are some tcpdumps of socklib (just a TCP bw test). The client makes the connection and the server streams bytes down the connection. client: 14:59:21.745368 IP client.32818 > server.7001: S 2966429246:2966429246(0) win 5840 14:59:21.745497 IP server.7001 > client.32818: S 3127678265:3127678265(0) ack 2966429247 win 5792 14:59:21.745511 IP client.32818 > server.7001: . ack 1 win 5840 14:59:21.746245 IP server.7001 > client.32818: . 1:1449(1448) ack 1 win 1448 14:59:21.746253 IP server.7001 > client.32818: . 1449:2897(1448) ack 1 win 1448 14:59:21.746273 IP client.32818 > server.7001: . ack 1449 win 8688 14:59:21.746284 IP client.32818 > server.7001: . ack 2897 win 11584 14:59:21.746492 IP server.7001 > client.32818: . 2897:4345(1448) ack 1 win 1448 14:59:21.746500 IP server.7001 > client.32818: P 4345:5793(1448) ack 1 win 1448 14:59:21.746515 IP client.32818 > server.7001: . ack 4345 win 14480 14:59:21.746525 IP client.32818 > server.7001: . ack 5793 win 17376 14:59:21.746742 IP server.7001 > client.32818: . 5793:7241(1448) ack 1 win 1448 14:59:21.746749 IP server.7001 > client.32818: . 7241:8689(1448) ack 1 win 1448 server.7001: . ack 13078337 win 34752 14:59:24.343367 IP server.7001 > client.32818: . 13078337:13079785(1448) ack 1 win 1448 14:59:24.343375 IP server.7001 > client.32818: . 13079785:13081233(1448) ack 1 win 1448 14:59:24.343380 IP server.7001 > client.32818: . 13081233:13082681(1448) ack 1 win 1448 14:59:24.343419 IP client.32818 > server.7001: . ack 13082681 win 34752 14:59:24.343750 IP server.7001 > client.32818: . 13082681:13084129(1448) ack 1 win 1448 14:59:24.343759 IP server.7001 > client.32818: . 13084129:13085577(1448) ack 1 win 1448 14:59:24.343765 IP server.7001 > client.32818: P 13085577:13087025(1448) ack 1 win 1448 server: 15:44:04.939695 IP client.32823 > server.7001: S 4245828116:4245828116(0) win 5840 15:44:04.939703 IP server.7001 > client.32823: S 130434711:130434711(0) ack 4245828117 win 5792 15:44:04.939899 IP client.32823 > server.7001: . ack 1 win 5840 15:44:04.940439 IP bad-len 0 15:44:04.940649 IP client.32823 > server.7001: . ack 1449 win 8688 15:44:04.940650 IP client.32823 > server.7001: . ack 2897 win 11584 15:44:04.940675 IP bad-len 0 ... This is what it looks like after things settle down. Nasty how tcpdump doesnt understand TSO bundles. Notice how we send out one TSO bundle and then wait for the ack: 15:44:05.068048 IP client.32823 > server.7001: . ack 2213993 win 34752 15:44:05.068059 IP bad-len 0 15:44:05.068298 IP client.32823 > server.7001: . ack 2218337 win 34752 15:44:05.068310 IP bad-len 0 15:44:05.068549 IP client.32823 > server.7001: . ack 2222681 win 34752 15:44:05.068565 IP bad-len 0 From the first trace we see that each TSO bundle consists of 3 packets. The application is doing 64kB sends so its surprising that we only pack 3 packets into a TSO bundle. It looks like we only think there is a 5k window on this connection when TSO is enabled. Anton From romieu@fr.zoreil.com Mon Sep 20 00:19:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 00:20:06 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K7JqRr003371 for ; Mon, 20 Sep 2004 00:19:53 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8K7Hivr007212; Mon, 20 Sep 2004 09:17:44 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8K7Hh4c007211; Mon, 20 Sep 2004 09:17:43 +0200 Date: Mon, 20 Sep 2004 09:17:43 +0200 From: Francois Romieu To: Jeff Garzik Cc: Andy Lutomirski , Hans-Frieder Vogt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040920071743.GA7115@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> <20040919213952.GA32570@electric-eye.fr.zoreil.com> <414E46F1.9050309@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414E46F1.9050309@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9129 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 364 Lines: 12 Jeff Garzik : [...] > That sounds like a bug right there... need all the addresses set up > before we turn on stuff. The description of the CPlusCmd in the 8169 datasheet includes a small note which suggests that this register should be set up early. It does not cost much to try and see if it makes a difference for DAC though. -- Ueimor From ja@ssi.bg Mon Sep 20 00:45:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 00:45:27 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K7jHuX004109 for ; Mon, 20 Sep 2004 00:45:19 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8K7k80V001803; Mon, 20 Sep 2004 10:46:11 +0300 Date: Mon, 20 Sep 2004 10:46:08 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Harald Welte cc: "David S. Miller" , netdev@oss.sgi.com, rusty@rustcorp.com.au Subject: Re: [PATCH 2.6] ip_nat_ftp - manip at the right place In-Reply-To: <20040914071241.GM8434@sunbeam.de.gnumonks.org> Message-ID: References: <20040912170323.65eadc38.davem@davemloft.net> <20040914071241.GM8434@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9130 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 413 Lines: 16 Hello, On Tue, 14 Sep 2004, Harald Welte wrote: > I agree with the change (although I didn't test it here on my systems so > far). However, as indicated in private mail to Julian, the change > should be made consistent over all helpers. No private mail received yet. But I agree, it should work for other helpers, eg. similar change can go in do_bindings instead. Regards -- Julian Anastasov From martin.bouzek@radas-atc.cz Mon Sep 20 00:47:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 00:47:35 -0700 (PDT) Received: from out.smtp.cz (peter.smtp.cz [81.95.97.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K7lR46004444 for ; Mon, 20 Sep 2004 00:47:28 -0700 Received: (qmail 4562 invoked from network); 20 Sep 2004 07:47:11 -0000 Received: from unknown (HELO ?192.168.1.100?) (staff.praha@radas-atc.cz@62.177.68.19) by peter.smtp.cz with AES256-SHA encrypted SMTP; 20 Sep 2004 07:47:10 -0000 Subject: Re: Minor IPSec bug + solution From: Martin Bouzek Reply-To: martin.bouzek@radas-atc.cz To: Herbert Xu Cc: Linux Kernel , davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <20040917102720.GA14579@gondor.apana.org.au> References: <1095413173.2708.106.camel@mabouzek> <20040917102720.GA14579@gondor.apana.org.au> Content-Type: text/plain Organization: Radas, s.r.o. Message-Id: <1095666589.2723.8.camel@mabouzek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 20 Sep 2004 09:49:49 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 9131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: martin.bouzek@radas-atc.cz Precedence: bulk X-list: netdev Content-Length: 794 Lines: 19 On Fri, 2004-09-17 at 12:27, Herbert Xu wrote: > On Fri, Sep 17, 2004 at 11:26:13AM +0200, Martin Bouzek wrote: > > > > > > function. For tunnels it returns > > > > > > > > tmpl->optional && !xfrm_state_addr_cmp(tmpl, x, family); > > > > Well, I am not expierienced with the networking kernel code, > > nevertheless I still think the check is not correct. > > If you change the && to ||, then an ESP tunnel SA marked as required > can be matched by a simple IPIP SA with the same addresses. Ok. And would it be possible to check the protocols too (eg. tmpl->id.proto == x->id.proto)? If it is realy not possible to make the IPComp/required tunnel to work, it would be nice to mention it in for example the setkey man page. It could save quite lot of time to some people. (like me :-) ). From johnpol@2ka.mipt.ru Mon Sep 20 00:57:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 00:57:08 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [194.220.215.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8K7uvJ4005999 for ; Mon, 20 Sep 2004 00:56:58 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i8K7uT2X013820; Mon, 20 Sep 2004 11:56:30 +0400 Subject: Re: Kernel connector - userspace <-> kernelspace "linker". From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: jamal Cc: netdev@oss.sgi.com In-Reply-To: <1095336548.1064.167.camel@jzny.localdomain> References: <1095331899.18219.58.camel@uganda> <1095336548.1064.167.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-m0BUYYOFNFPI9i++uPZT" Organization: MIPT Message-Id: <1095667297.15351.42.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 20 Sep 2004 12:01:37 +0400 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on dea.vocord.com X-Virus-Status: Clean X-archive-position: 9132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 19629 Lines: 299 --=-m0BUYYOFNFPI9i++uPZT Content-Type: multipart/mixed; boundary="=-TIMupFxjMR70PiTEfF2B" --=-TIMupFxjMR70PiTEfF2B Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-09-16 at 16:09, jamal wrote: > On Thu, 2004-09-16 at 06:51, Evgeniy Polyakov wrote: > > Hmm, do not know how to describe...=20 > > Kind of mega-picture can be found at=20 > > http://tservice.net.ru/~s0mbre/?section=3Dgallery&item=3Dconnector_desi= gn > >=20 > > This driver adds possibility to connect anything with anything using > > netlink based network. > > One must register callback and identificator. When driver receives > > special netlink message with appropriate identificator, appropriate > > callback will be called. > > I think that the code better explains what I'm trying to say. >=20 > I dont have time to evaluate the code right now - but will at the end of > day. Just trying to understand your concepts: >=20 > Essentially you are building a unified messaging for > userspace-userpace(i.e IPC), userspace-kernel, kernel-kernel with each > component residing in whatever spot (kernel or userland)having a unique > name and Id. Is this correct? > Clearly there could be name/Id conflicts etc. Are you addressing those?=20 > Any event and filtering capability already in or planned? Example event > I want to be notified when module with name "sean paul" comes online and > filter will be "it has to have ID in the range of 0x200-0x400". >=20 > I am still trying to wakeup but it does sound like a good idea to have a > generic messaging subsystem. Attached patch cleans it up a bit and adds notify removal mechanism. BTW, patch for cn_test.c test module is quite ugly, but it is only for test. Real users can use cn_netlink_send(). It looks like noone objects, so I will create a patch and send it to GregKH :)=20 I know at least 2 potential users - w1 and pending superio( actually it requires only connector to be included). I'm quite sure after I will write bits of documentation for this cruft it will take broader usage. Thank you. > cheers, > jamal=20 --=20 Evgeniy Polyakov Crash is better than data corruption. -- Art Grabowski --=-TIMupFxjMR70PiTEfF2B Content-Disposition: attachment; filename=connector.diff Content-Type: text/x-patch; name=connector.diff; charset=KOI8-R Content-Transfer-Encoding: base64 KiBsb29raW5nIGZvciBqb2hucG9sQDJrYS5taXB0LnJ1LTIwMDQvY29ubmVjdG9yLS1tYWluLS0w LS1wYXRjaC0xMCB0byBjb21wYXJlIHdpdGgNCiogY29tcGFyaW5nIHRvIGpvaG5wb2xAMmthLm1p cHQucnUtMjAwNC9jb25uZWN0b3ItLW1haW4tLTAtLXBhdGNoLTEwDQpNICBjbl90ZXN0LmMNCk0g IGNvbm5lY3Rvci5jDQpNICBjb25uZWN0b3IuaA0KTSAgTWFrZWZpbGUNCk0gIHVjb24uYw0KDQoq IG1vZGlmaWVkIGZpbGVzDQoNCi0tLSBvcmlnL01ha2VmaWxlDQorKysgbW9kL01ha2VmaWxlDQpA QCAtMiw3ICsyLDcgQEANCiBjbi1vYmpzCQk6PSBjbl9xdWV1ZS5vIGNvbm5lY3Rvci5vDQogDQog I0tESVIJOj0gL2xpYi9tb2R1bGVzLyQoc2hlbGwgdW5hbWUgLXIpL2J1aWxkDQotS0RJUgk6PSAv dXNyL2xvY2FsL3NyYy9saW51eC0yLjYvbGludXgtMi42LjYNCitLRElSCTo9IC91c3IvbG9jYWwv c3JjL2xpbnV4LTIuNi9saW51eC0yLjYNCiBQV0QJOj0gJChzaGVsbCBwd2QpDQogDQogZGVmYXVs dDoNCg0KDQotLS0gb3JpZy9jbl90ZXN0LmMNCisrKyBtb2QvY25fdGVzdC5jDQpAQCAtMjIsMTEg KzIyLDEzIEBADQogI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPg0KICNpbmNsdWRlIDxsaW51eC9t b2R1bGUuaD4NCiAjaW5jbHVkZSA8bGludXgvbW9kdWxlcGFyYW0uaD4NCisjaW5jbHVkZSA8bGlu dXgvc2tidWZmLmg+DQogDQogI2luY2x1ZGUgImNvbm5lY3Rvci5oIg0KIA0KIHN0YXRpYyBzdHJ1 Y3QgY2JfaWQgY25fdGVzdF9pZCA9IHsgMHgxMjMsIDB4NDU2IH07DQogc3RhdGljIGNoYXIgY25f dGVzdF9uYW1lW10gPSAiY25fdGVzdCI7DQorc3RhdGljIHN0cnVjdCBzb2NrICpubHM7DQogDQog dm9pZCBjbl90ZXN0X2NhbGxiYWNrKHZvaWQgKmRhdGEpDQogew0KQEAgLTM2LDIxICszOCwxMTIg QEANCiAJICAgICAgIF9fZnVuY19fLCBtc2ctPmlkLmlkeCwgbXNnLT5pZC52YWwsIG1zZy0+bGVu KTsNCiB9DQogDQorc3RhdGljIGludCBjbl90ZXN0X3dhbnRfbm90aWZ5KHZvaWQpDQorew0KKwlz dHJ1Y3QgY25fY3RsX21zZyAqY3RsOw0KKwlzdHJ1Y3QgY25fbm90aWZ5X3JlcSAqcmVxOw0KKwlz dHJ1Y3QgY25fbXNnICptc2cgPSBOVUxMOw0KKwlpbnQgc2l6ZSwgc2l6ZTA7DQorCXN0cnVjdCBz a19idWZmICpza2I7DQorCXN0cnVjdCBubG1zZ2hkciAqbmxoOw0KKwl1MzIgZ3JvdXAgPSAxOw0K Kw0KKwlzaXplMCA9IHNpemVvZigqbXNnKSArIHNpemVvZigqY3RsKSArIDMqc2l6ZW9mKCpyZXEp Ow0KKwkNCisJc2l6ZSA9IE5MTVNHX1NQQUNFKHNpemUwKTsNCisNCisJc2tiID0gYWxsb2Nfc2ti KHNpemUsIEdGUF9BVE9NSUMpOw0KKwlpZiAoIXNrYikgew0KKwkJcHJpbnRrKEtFUk5fRVJSICJG YWlsZWQgdG8gYWxsb2NhdGUgbmV3IHNrYiB3aXRoIHNpemU9JXUuXG4iLCBzaXplKTsNCisNCisJ CXJldHVybiAtRU5PTUVNOw0KKwl9DQorDQorCW5saCA9IE5MTVNHX1BVVChza2IsIDAsIDB4MTIz LCBOTE1TR19ET05FLCBzaXplIC0gc2l6ZW9mKCpubGgpKTsNCisNCisJbXNnID0gKHN0cnVjdCBj bl9tc2cgKilOTE1TR19EQVRBKG5saCk7DQorDQorCW1lbXNldChtc2csIDAsIHNpemUwKTsNCisN CisJbXNnLT5pZC5pZHggCT0gLTE7DQorCW1zZy0+aWQudmFsIAk9IC0xOw0KKwltc2ctPnNlcSAJ PSAweDEyMzsNCisJbXNnLT5hY2sgCT0gMHgzNDU7DQorCW1zZy0+bGVuIAk9IHNpemUwIC0gc2l6 ZW9mKCptc2cpOw0KKw0KKwljdGwgPSAoc3RydWN0IGNuX2N0bF9tc2cgKikobXNnICsgMSk7DQor DQorCWN0bC0+aWR4X25vdGlmeV9udW0gCT0gMTsNCisJY3RsLT52YWxfbm90aWZ5X251bSAJPSAy Ow0KKwljdGwtPmdyb3VwCQk9IGdyb3VwOw0KKw0KKwlyZXEgPSAoc3RydWN0IGNuX25vdGlmeV9y ZXEgKikoY3RsICsgMSk7DQorDQorCS8qDQorCSAqIElkeC4NCisJICovDQorCXJlcS0+Zmlyc3Qg PSBjbl90ZXN0X2lkLmlkeDsNCisJcmVxLT5yYW5nZSA9IDEwOw0KKw0KKwkvKg0KKwkgKiBWYWwg MC4NCisJICovDQorCXJlcSsrOw0KKwlyZXEtPmZpcnN0ID0gY25fdGVzdF9pZC52YWw7DQorCXJl cS0+cmFuZ2UgPSAxMDsNCisJDQorCS8qDQorCSAqIFZhbCAxLg0KKwkgKi8NCisJcmVxKys7DQor CXJlcS0+Zmlyc3QgPSBjbl90ZXN0X2lkLnZhbCArIDIwOw0KKwlyZXEtPnJhbmdlID0gMTA7DQor CQ0KKwlORVRMSU5LX0NCKHNrYikuZHN0X2dyb3VwcyA9IGN0bC0+Z3JvdXA7DQorCS8vbmV0bGlu a19icm9hZGNhc3QobmxzLCBza2IsIDAsIGN0bC0+Z3JvdXAsIEdGUF9BVE9NSUMpOw0KKwluZXRs aW5rX3VuaWNhc3QobmxzLCBza2IsIDAsIDApOw0KKw0KKwlwcmludGsoS0VSTl9JTkZPICJSZXF1 ZXN0IHdhcyBzZW50LiBHcm91cD0weCV4LlxuIiwgZ3JvdXApOw0KKwkJDQorCXJldHVybiAwOw0K Kw0KK25sbXNnX2ZhaWx1cmU6DQorCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIHNlbmQgJXUu JXVcbiIsIG1zZy0+c2VxLCBtc2ctPmFjayk7DQorCWtmcmVlX3NrYihza2IpOw0KKwlyZXR1cm4g LUVJTlZBTDsNCit9DQorDQogc3RhdGljIGludCBjbl90ZXN0X2luaXQodm9pZCkNCiB7DQogCWlu dCBlcnI7DQorCQ0KKwlubHMgPSBuZXRsaW5rX2tlcm5lbF9jcmVhdGUoTkVUTElOS19ORkxPRywg TlVMTCk7DQorCWlmICghbmxzKSB7DQorCQlwcmludGsoS0VSTl9FUlIgIkZhaWxlZCB0byBjcmVh dGUgbmV3IG5ldGxpbmsgc29ja2V0KCV1KS5cbiIsIE5FVExJTktfTkZMT0cpOw0KKwkJcmV0dXJu IC1FSU87DQorCX0NCisNCisJZXJyID0gY25fdGVzdF93YW50X25vdGlmeSgpOw0KKwlpZiAoZXJy KQ0KKwkJZ290byBlcnJfb3V0Ow0KIA0KIAllcnIgPSBjbl9hZGRfY2FsbGJhY2soJmNuX3Rlc3Rf aWQsIGNuX3Rlc3RfbmFtZSwgY25fdGVzdF9jYWxsYmFjayk7DQogCWlmIChlcnIpDQotCQlyZXR1 cm4gZXJyOw0KKwkJZ290byBlcnJfb3V0Ow0KIAljbl90ZXN0X2lkLnZhbCsrOw0KIAllcnIgPSBj bl9hZGRfY2FsbGJhY2soJmNuX3Rlc3RfaWQsIGNuX3Rlc3RfbmFtZSwgY25fdGVzdF9jYWxsYmFj ayk7DQogCWlmIChlcnIpIHsNCiAJCWNuX2RlbF9jYWxsYmFjaygmY25fdGVzdF9pZCk7DQotCQly ZXR1cm4gZXJyOw0KKwkJZ290byBlcnJfb3V0Ow0KIAl9DQogDQogCXJldHVybiAwOw0KKw0KK2Vy cl9vdXQ6DQorCWlmIChubHMtPnNrX3NvY2tldCkNCisJCXNvY2tfcmVsZWFzZShubHMtPnNrX3Nv Y2tldCk7DQorDQorCXJldHVybiBlcnI7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIGNuX3Rlc3RfZmlu aSh2b2lkKQ0KQEAgLTU4LDYgKzE1MSw4IEBADQogCWNuX2RlbF9jYWxsYmFjaygmY25fdGVzdF9p ZCk7DQogCWNuX3Rlc3RfaWQudmFsLS07DQogCWNuX2RlbF9jYWxsYmFjaygmY25fdGVzdF9pZCk7 DQorCWlmIChubHMtPnNrX3NvY2tldCkNCisJCXNvY2tfcmVsZWFzZShubHMtPnNrX3NvY2tldCk7 DQogfQ0KIA0KIG1vZHVsZV9pbml0KGNuX3Rlc3RfaW5pdCk7DQoNCg0KLS0tIG9yaWcvY29ubmVj dG9yLmMNCisrKyBtb2QvY29ubmVjdG9yLmMNCkBAIC0zNiw5ICszNiwxNyBAQA0KIE1PRFVMRV9E RVNDUklQVElPTigiR2VuZXJpYyB1c2Vyc3BhY2UgPC0+IGtlcm5lbHNwYWNlIGNvbm5lY3Rvci4i KTsNCiANCiBzdGF0aWMgaW50IHVuaXQgPSBORVRMSU5LX05GTE9HOw0KK3N0YXRpYyB1MzIgY25f aWR4ID0gLTE7DQorc3RhdGljIHUzMiBjbl92YWwgPSAtMTsNCisNCiBtb2R1bGVfcGFyYW0odW5p dCwgaW50LCAwKTsNCittb2R1bGVfcGFyYW0oY25faWR4LCB1aW50LCAwKTsNCittb2R1bGVfcGFy YW0oY25fdmFsLCB1aW50LCAwKTsNCisNCitzcGlubG9ja190IG5vdGlmeV9sb2NrID0gU1BJTl9M T0NLX1VOTE9DS0VEOw0KK3N0YXRpYyBMSVNUX0hFQUQobm90aWZ5X2xpc3QpOw0KIA0KLXN0cnVj dCBjbl9kZXYgY2RldjsNCitzdGF0aWMgc3RydWN0IGNuX2RldiBjZGV2Ow0KIA0KIC8qDQogICog bXNnLT5zZXEgYW5kIG1zZy0+YWNrIGFyZSB1c2VkIHRvIGRldGVybWluZSBtZXNzYWdlIGdlbmVh bG9neS4NCkBAIC01OSw3ICs2Nyw3IEBADQogICogdGhlbiBpdCBpcyBuZXcgbWVzc2FnZS4NCiAg Kg0KICAqLw0KLXZvaWQgY25fbmV0bGlua19zZW5kKHN0cnVjdCBjbl9tc2cgKm1zZykNCit2b2lk IGNuX25ldGxpbmtfc2VuZChzdHJ1Y3QgY25fbXNnICptc2csIHUzMiBfX2dyb3VwcykNCiB7DQog CXN0cnVjdCBjbl9jYWxsYmFja19lbnRyeSAqbiwgKl9fY2JxOw0KIAl1bnNpZ25lZCBpbnQgc2l6 ZTsNCkBAIC03MCwyMCArNzgsMjUgQEANCiAJdTMyIGdyb3VwcyA9IDA7DQogCWludCBmb3VuZCA9 IDA7DQogDQotCXNwaW5fbG9jaygmZGV2LT5jYmRldi0+cXVldWVfbG9jayk7DQotCWxpc3RfZm9y X2VhY2hfZW50cnlfc2FmZShfX2NicSwgbiwgJmRldi0+Y2JkZXYtPnF1ZXVlX2xpc3QsIGNhbGxi YWNrX2VudHJ5KSB7DQotCQlpZiAoY25fY2JfZXF1YWwoJl9fY2JxLT5jYi0+aWQsICZtc2ctPmlk KSkgew0KLQkJCWZvdW5kID0gMTsNCi0JCQlncm91cHMgPSBfX2NicS0+Z3JvdXA7DQorCWlmICgh X19ncm91cHMpDQorCXsNCisJCXNwaW5fbG9jaygmZGV2LT5jYmRldi0+cXVldWVfbG9jayk7DQor CQlsaXN0X2Zvcl9lYWNoX2VudHJ5X3NhZmUoX19jYnEsIG4sICZkZXYtPmNiZGV2LT5xdWV1ZV9s aXN0LCBjYWxsYmFja19lbnRyeSkgew0KKwkJCWlmIChjbl9jYl9lcXVhbCgmX19jYnEtPmNiLT5p ZCwgJm1zZy0+aWQpKSB7DQorCQkJCWZvdW5kID0gMTsNCisJCQkJZ3JvdXBzID0gX19jYnEtPmdy b3VwOw0KKwkJCX0NCiAJCX0NCi0JfQ0KLQlzcGluX3VubG9jaygmZGV2LT5jYmRldi0+cXVldWVf bG9jayk7DQorCQlzcGluX3VubG9jaygmZGV2LT5jYmRldi0+cXVldWVfbG9jayk7DQogDQotCWlm ICghZm91bmQpIHsNCi0JCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIGZpbmQgbXVsdGljYXN0 IG5ldGxpbmsgZ3JvdXAgZm9yIGNhbGxiYWNrWzB4JXguMHgleF0uIHNlcT0ldVxuIiwNCi0JCSAg ICAgICBtc2ctPmlkLmlkeCwgbXNnLT5pZC52YWwsIG1zZy0+c2VxKTsNCi0JCXJldHVybjsNCisJ CWlmICghZm91bmQpIHsNCisJCQlwcmludGsoS0VSTl9FUlIgIkZhaWxlZCB0byBmaW5kIG11bHRp Y2FzdCBuZXRsaW5rIGdyb3VwIGZvciBjYWxsYmFja1sweCV4LjB4JXhdLiBzZXE9JXVcbiIsDQor CQkJICAgICAgIG1zZy0+aWQuaWR4LCBtc2ctPmlkLnZhbCwgbXNnLT5zZXEpOw0KKwkJCXJldHVy bjsNCisJCX0NCiAJfQ0KKwllbHNlDQorCQlncm91cHMgPSBfX2dyb3VwczsNCiANCiAJc2l6ZSA9 IE5MTVNHX1NQQUNFKHNpemVvZigqbXNnKSArIG1zZy0+bGVuKTsNCiANCkBAIC0xNDcsNiArMTYw LDE1IEBADQogCXNlcSA9IG5saC0+bmxtc2dfc2VxOw0KIAlncm91cCA9IE5FVExJTktfQ0IoKHNr YikpLmdyb3VwczsNCiAJbXNnID0gKHN0cnVjdCBjbl9tc2cgKilOTE1TR19EQVRBKG5saCk7DQor DQorCWlmIChtc2ctPmxlbiAhPSBubGgtPm5sbXNnX2xlbiAtIHNpemVvZigqbXNnKSAtIHNpemVv ZigqbmxoKSkNCisJew0KKwkJcHJpbnRrKEtFUk5fRVJSICJza2IgZG9lcyBub3QgaGF2ZSBlbm91 Z2ggbGVuZ3RoOiByZXF1ZXN0ZWQgbXNnLT5sZW49JXVbJXVdLCBubGgtPm5sbXNnX2xlbj0ldVsl dV0sIHNrYi0+bGVuPSV1W211c3QgYmUgJXVdLlxuIiwgDQorCQkJCW1zZy0+bGVuLCBOTE1TR19T UEFDRShtc2ctPmxlbiksIA0KKwkJCQlubGgtPm5sbXNnX2xlbiwgbmxoLT5ubG1zZ19sZW4gLSBz aXplb2YoKm5saCksDQorCQkJCXNrYi0+bGVuLCBtc2ctPmxlbiArIHNpemVvZigqbXNnKSk7DQor CQlyZXR1cm4gLUVJTlZBTDsNCisJfQ0KICNpZiAwDQogCXByaW50ayhLRVJOX0lORk8gInBpZD0l dSwgdWlkPSV1LCBzZXE9JXUsIGdyb3VwPSV1LlxuIiwNCiAJICAgICAgIHBpZCwgdWlkLCBzZXEs IGdyb3VwKTsNCkBAIC0xODgsNyArMjEwLDcgQEANCiANCiAJCWVyciA9IF9fY25fcnhfc2tiKHNr YiwgbmxoKTsNCiAJCWlmIChlcnIpIHsNCi0JCQlpZiAoZXJyIDwgMCkNCisJCQlpZiAoZXJyIDwg MCAmJiAobmxoLT5ubG1zZ19mbGFncyAmIE5MTV9GX0FDSykpDQogCQkJCW5ldGxpbmtfYWNrKHNr YiwgbmxoLCAtZXJyKTsNCiAJCQlrZnJlZV9za2Ioc2tiKTsNCiAJCQlicmVhazsNCkBAIC0yMTAs NiArMjMyLDU5IEBADQogCQljbl9yeF9za2Ioc2tiKTsNCiB9DQogDQorc3RhdGljIHZvaWQgY25f bm90aWZ5KHN0cnVjdCBjYl9pZCAqaWQsIHUzMiBub3RpZnlfZXZlbnQpDQorew0KKwlzdHJ1Y3Qg Y25fY3RsX2VudHJ5ICplbnQ7DQorDQorCXNwaW5fbG9jaygmbm90aWZ5X2xvY2spOw0KKwlsaXN0 X2Zvcl9lYWNoX2VudHJ5KGVudCwgJm5vdGlmeV9saXN0LCBub3RpZnlfZW50cnkpDQorCXsNCisJ CWludCBpOw0KKwkJc3RydWN0IGNuX25vdGlmeV9yZXEgKnJlcTsNCisJCXN0cnVjdCBjbl9jdGxf bXNnICpjdGwgPSBlbnQtPm1zZzsNCisJCWludCBhLCBiOw0KKw0KKwkJYSA9IGIgPSAwOw0KKwkJ DQorCQlyZXEgPSAoc3RydWN0IGNuX25vdGlmeV9yZXEgKiljdGwtPmRhdGE7DQorCQlmb3IgKGk9 MDsgaTxjdGwtPmlkeF9ub3RpZnlfbnVtOyArK2ksICsrcmVxKQ0KKwkJew0KKwkJCWlmIChpZC0+ aWR4ID49IHJlcS0+Zmlyc3QgJiYgaWQtPmlkeCA8IHJlcS0+Zmlyc3QgKyByZXEtPnJhbmdlKQ0K KwkJCXsNCisJCQkJcHJpbnRrKCIrICIpOw0KKwkJCQlhID0gMTsNCisJCQkJYnJlYWs7DQorCQkJ fQ0KKwkJfQ0KKwkJDQorCQlmb3IgKGk9MDsgaTxjdGwtPnZhbF9ub3RpZnlfbnVtOyArK2ksICsr cmVxKQ0KKwkJew0KKwkJCWlmIChpZC0+dmFsID49IHJlcS0+Zmlyc3QgJiYgaWQtPnZhbCA8IHJl cS0+Zmlyc3QgKyByZXEtPnJhbmdlKQ0KKwkJCXsNCisJCQkJcHJpbnRrKCIrICIpOw0KKwkJCQli ID0gMTsNCisJCQkJYnJlYWs7DQorCQkJfQ0KKwkJfQ0KKw0KKwkJaWYgKGEgJiYgYikNCisJCXsN CisJCQlzdHJ1Y3QgY25fbXNnIG07DQorCQkJDQorCQkJcHJpbnRrKEtFUk5fSU5GTyAiTm90aWZ5 aW5nIGdyb3VwICV4IHdpdGggZXZlbnQgJXUgYWJvdXQgJXguJXguXG4iLCANCisJCQkJCWN0bC0+ Z3JvdXAsIG5vdGlmeV9ldmVudCwgDQorCQkJCQlpZC0+aWR4LCBpZC0+dmFsKTsNCisNCisJCQlt ZW1zZXQoJm0sIDAsIHNpemVvZihtKSk7DQorCQkJbS5hY2sgPSBub3RpZnlfZXZlbnQ7DQorDQor CQkJbWVtY3B5KCZtLmlkLCBpZCwgc2l6ZW9mKG0uaWQpKTsNCisJCQljbl9uZXRsaW5rX3NlbmQo Jm0sIGN0bC0+Z3JvdXApOw0KKwkJfQ0KKwl9DQorCXNwaW5fdW5sb2NrKCZub3RpZnlfbG9jayk7 DQorfQ0KKw0KIGludCBjbl9hZGRfY2FsbGJhY2soc3RydWN0IGNiX2lkICppZCwgY2hhciAqbmFt ZSwgdm9pZCAoKmNhbGxiYWNrKSAodm9pZCAqKSkNCiB7DQogCWludCBlcnI7DQpAQCAtMjM3LDYg KzMxMiw4IEBADQogCQlrZnJlZShjYik7DQogCQlyZXR1cm4gZXJyOw0KIAl9DQorCQkJDQorCWNu X25vdGlmeShpZCwgMCk7DQogDQogCXJldHVybiAwOw0KIH0NCkBAIC0yNDksMTYgKzMyNiwxNTgg QEANCiAJbGlzdF9mb3JfZWFjaF9lbnRyeV9zYWZlKF9fY2JxLCBuLCAmZGV2LT5jYmRldi0+cXVl dWVfbGlzdCwgY2FsbGJhY2tfZW50cnkpIHsNCiAJCWlmIChjbl9jYl9lcXVhbCgmX19jYnEtPmNi LT5pZCwgaWQpKSB7DQogCQkJY25fcXVldWVfZGVsX2NhbGxiYWNrKGRldi0+Y2JkZXYsIF9fY2Jx LT5jYik7DQorCQkJY25fbm90aWZ5KGlkLCAxKTsNCiAJCQlicmVhazsNCiAJCX0NCiAJfQ0KIH0N CiANCitzdGF0aWMgaW50IGNuX2N0bF9tc2dfZXF1YWxzKHN0cnVjdCBjbl9jdGxfbXNnICptMSwg c3RydWN0IGNuX2N0bF9tc2cgKm0yKQ0KK3sNCisJaW50IGk7DQorCXN0cnVjdCBjbl9ub3RpZnlf cmVxICpyZXExLCAqcmVxMjsNCisNCisJaWYgKG0xLT5pZHhfbm90aWZ5X251bSAhPSBtMi0+aWR4 X25vdGlmeV9udW0pDQorCQlyZXR1cm4gMDsNCisJDQorCWlmIChtMS0+dmFsX25vdGlmeV9udW0g IT0gbTItPnZhbF9ub3RpZnlfbnVtKQ0KKwkJcmV0dXJuIDA7DQorCQ0KKwlpZiAobTEtPmxlbiAh PSBtMi0+bGVuKQ0KKwkJcmV0dXJuIDA7DQorDQorCWlmICgobTEtPmlkeF9ub3RpZnlfbnVtICsg bTEtPnZhbF9ub3RpZnlfbnVtKSpzaXplb2YoKnJlcTEpICE9IG0xLT5sZW4pDQorCXsNCisJCXBy aW50aygiTm90aWZ5IGVudHJ5W2lkeF9udW09JXgsIHZhbF9udW09JXgsIGxlbj0ldV0gY29udGFp bnMgZ2FyYmFnZS4gUmVtb3ZpbmcuXG4iLCANCisJCQkJbTEtPmlkeF9ub3RpZnlfbnVtLCBtMS0+ dmFsX25vdGlmeV9udW0sIG0xLT5sZW4pOw0KKwkJcmV0dXJuIDE7DQorCX0NCisNCisJcmVxMSA9 IChzdHJ1Y3QgY25fbm90aWZ5X3JlcSAqKW0xLT5kYXRhOw0KKwlyZXEyID0gKHN0cnVjdCBjbl9u b3RpZnlfcmVxICopbTItPmRhdGE7DQorCQ0KKwlmb3IgKGk9MDsgaTxtMS0+aWR4X25vdGlmeV9u dW07ICsraSkNCisJew0KKwkJaWYgKG1lbWNtcChyZXExLCByZXEyLCBzaXplb2YoKnJlcTEpKSkN CisJCQlyZXR1cm4gMDsNCisNCisJCXJlcTErKzsNCisJCXJlcTIrKzsNCisJfQ0KKw0KKwlmb3Ig KGk9MDsgaTxtMS0+dmFsX25vdGlmeV9udW07ICsraSkNCisJew0KKwkJaWYgKG1lbWNtcChyZXEx LCByZXEyLCBzaXplb2YoKnJlcTEpKSkNCisJCQlyZXR1cm4gMDsNCisNCisJCXJlcTErKzsNCisJ CXJlcTIrKzsNCisJfQ0KKw0KKwlyZXR1cm4gMTsNCit9DQorDQorc3RhdGljIHZvaWQgY25fY2Fs bGJhY2sodm9pZCAqIGRhdGEpDQorew0KKwlzdHJ1Y3QgY25fbXNnICptc2cgPSAoc3RydWN0IGNu X21zZyAqKWRhdGE7DQorCXN0cnVjdCBjbl9jdGxfbXNnICpjdGw7DQorCXN0cnVjdCBjbl9jdGxf ZW50cnkgKmVudDsNCisJdTMyIHNpemU7DQorIA0KKwlpZiAobXNnLT5sZW4gPCBzaXplb2YoKmN0 bCkpDQorCXsNCisJCXByaW50ayhLRVJOX0VSUiAiV3JvbmcgY29ubmVjdG9yIHJlcXVlc3Qgc2l6 ZSAldSwgbXVzdCBiZSA+PSAldS5cbiIsIA0KKwkJCQltc2ctPmxlbiwgc2l6ZW9mKCpjdGwpKTsN CisJCXJldHVybjsNCisJfQ0KKwkNCisJY3RsID0gKHN0cnVjdCBjbl9jdGxfbXNnICopbXNnLT5k YXRhOw0KKw0KKwlzaXplID0gc2l6ZW9mKCpjdGwpICsgKGN0bC0+aWR4X25vdGlmeV9udW0gKyBj dGwtPnZhbF9ub3RpZnlfbnVtKSpzaXplb2Yoc3RydWN0IGNuX25vdGlmeV9yZXEpOw0KKw0KKwlp ZiAobXNnLT5sZW4gIT0gc2l6ZSkNCisJew0KKwkJcHJpbnRrKEtFUk5fRVJSICJXcm9uZyBjb25u ZWN0b3IgcmVxdWVzdCBzaXplICV1LCBtdXN0IGJlID09ICV1LlxuIiwgDQorCQkJCW1zZy0+bGVu LCBzaXplKTsNCisJCXJldHVybjsNCisJfQ0KKw0KKwlpZiAoY3RsLT5sZW4gKyBzaXplb2YoKmN0 bCkgIT0gbXNnLT5sZW4pDQorCXsNCisJCXByaW50ayhLRVJOX0VSUiAiV3JvbmcgbWVzc2FnZTog bXNnLT5sZW49JXUgbXVzdCBiZSBlcXVhbCB0byBpbm5lcl9sZW49JXUgWysldV0uXG4iLCANCisJ CQkJbXNnLT5sZW4sIGN0bC0+bGVuLCBzaXplb2YoKmN0bCkpOw0KKwkJcmV0dXJuOw0KKwl9DQor DQorCS8qDQorCSAqIFJlbW92ZSBub3RpZmljYXRpb24uDQorCSAqLw0KKwlpZiAoY3RsLT5ncm91 cCA9PSAwKQ0KKwl7DQorCQlzdHJ1Y3QgY25fY3RsX2VudHJ5ICpuOw0KKwkJDQorCQlzcGluX2xv Y2soJm5vdGlmeV9sb2NrKTsNCisJCWxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShlbnQsIG4sICZu b3RpZnlfbGlzdCwgbm90aWZ5X2VudHJ5KQ0KKwkJew0KKwkJCWlmIChjbl9jdGxfbXNnX2VxdWFs cyhlbnQtPm1zZywgY3RsKSkNCisJCQl7DQorCQkJCWxpc3RfZGVsKCZlbnQtPm5vdGlmeV9lbnRy eSk7DQorCQkJCWtmcmVlKGVudCk7DQorCQkJfQ0KKwkJfQ0KKwkJc3Bpbl91bmxvY2soJm5vdGlm eV9sb2NrKTsNCisNCisJCXJldHVybjsNCisJfQ0KKw0KKwlzaXplICs9IHNpemVvZigqZW50KTsN CisNCisJZW50ID0ga21hbGxvYyhzaXplLCBHRlBfQVRPTUlDKTsNCisJaWYgKCFlbnQpDQorCXsN CisJCXByaW50ayhLRVJOX0VSUiAiRmFpbGVkIHRvIGFsbG9jYXRlICVkIGJ5dGVzIGZvciBuZXcg bm90aWZ5IGVudHJ5LlxuIiwgc2l6ZSk7DQorCQlyZXR1cm47DQorCX0NCisNCisJbWVtc2V0KGVu dCwgMCwgc2l6ZSk7DQorDQorCWVudC0+bXNnID0gKHN0cnVjdCBjbl9jdGxfbXNnICopKGVudCAr IDEpOw0KKw0KKwltZW1jcHkoZW50LT5tc2csIGN0bCwgc2l6ZSAtIHNpemVvZigqZW50KSk7DQor DQorCXNwaW5fbG9jaygmbm90aWZ5X2xvY2spOw0KKwlsaXN0X2FkZCgmZW50LT5ub3RpZnlfZW50 cnksICZub3RpZnlfbGlzdCk7DQorCXNwaW5fdW5sb2NrKCZub3RpZnlfbG9jayk7DQorDQorCXsN CisJCWludCBpOw0KKwkJc3RydWN0IGNuX25vdGlmeV9yZXEgKnJlcTsNCisJDQorCQlwcmludGso Ik5vdGlmeSBncm91cCAleCBmb3IgaWR4OiAiLCBjdGwtPmdyb3VwKTsNCisNCisJCXJlcSA9IChz dHJ1Y3QgY25fbm90aWZ5X3JlcSAqKWN0bC0+ZGF0YTsNCisJCWZvciAoaT0wOyBpPGN0bC0+aWR4 X25vdGlmeV9udW07ICsraSwgKytyZXEpDQorCQl7DQorCQkJcHJpbnRrKCIldS0ldSAiLCByZXEt PmZpcnN0LCByZXEtPmZpcnN0K3JlcS0+cmFuZ2UtMSk7DQorCQl9DQorCQkNCisJCXByaW50aygi XG5Ob3RpZnkgZ3JvdXAgJXggZm9yIHZhbDogIiwgY3RsLT5ncm91cCk7DQorDQorCQlmb3IgKGk9 MDsgaTxjdGwtPnZhbF9ub3RpZnlfbnVtOyArK2ksICsrcmVxKQ0KKwkJew0KKwkJCXByaW50aygi JXUtJXUgIiwgcmVxLT5maXJzdCwgcmVxLT5maXJzdCtyZXEtPnJhbmdlLTEpOw0KKwkJfQ0KKwkJ cHJpbnRrKCJcbiIpOw0KKwl9DQorfQ0KKw0KIHN0YXRpYyBpbnQgY25faW5pdCh2b2lkKQ0KIHsN CiAJc3RydWN0IGNuX2RldiAqZGV2ID0gJmNkZXY7DQogDQogCWRldi0+aW5wdXQgPSBjbl9pbnB1 dDsNCisJZGV2LT5pZC5pZHggPSBjbl9pZHg7DQorCWRldi0+aWQudmFsID0gY25fdmFsOw0KIA0K IAlkZXYtPm5scyA9IG5ldGxpbmtfa2VybmVsX2NyZWF0ZSh1bml0LCBkZXYtPmlucHV0KTsNCiAJ aWYgKCFkZXYtPm5scykgew0KQEAgLTI3NCwxMyArNDkzLDE0IEBADQogCQlyZXR1cm4gLUVJTlZB TDsNCiAJfQ0KIA0KLQlyZXR1cm4gMDsNCisJcmV0dXJuIGNuX2FkZF9jYWxsYmFjaygmZGV2LT5p ZCwgImNvbm5lY3RvciIsICZjbl9jYWxsYmFjayk7DQogfQ0KIA0KIHN0YXRpYyB2b2lkIGNuX2Zp bmkodm9pZCkNCiB7DQogCXN0cnVjdCBjbl9kZXYgKmRldiA9ICZjZGV2Ow0KIA0KKwljbl9kZWxf Y2FsbGJhY2soJmRldi0+aWQpOw0KIAljbl9xdWV1ZV9mcmVlX2RldihkZXYtPmNiZGV2KTsNCiAJ aWYgKGRldi0+bmxzLT5za19zb2NrZXQpDQogCQlzb2NrX3JlbGVhc2UoZGV2LT5ubHMtPnNrX3Nv Y2tldCk7DQoNCg0KLS0tIG9yaWcvY29ubmVjdG9yLmgNCisrKyBtb2QvY29ubmVjdG9yLmgNCkBA IC0zNywxMiArMzcsMzUgQEANCiAJX191OAkJCWRhdGFbMF07DQogfTsNCiANCitzdHJ1Y3QgY25f bm90aWZ5X3JlcQ0KK3sNCisJX191MzIJCQlmaXJzdDsNCisJX191MzIJCQlyYW5nZTsNCit9Ow0K Kw0KK3N0cnVjdCBjbl9jdGxfbXNnDQorew0KKwlfX3UzMgkJCWlkeF9ub3RpZnlfbnVtOw0KKwlf X3UzMgkJCXZhbF9ub3RpZnlfbnVtOw0KKwlfX3UzMgkJCWdyb3VwOw0KKwlfX3UzMgkJCWxlbjsN CisJX191OAkJCWRhdGFbMF07DQorfTsNCisNCiAjaWZkZWYgX19LRVJORUxfXw0KIA0KICNpbmNs dWRlIDxuZXQvc29jay5oPg0KIA0KK3N0cnVjdCBjbl9jdGxfZW50cnkNCit7DQorCXN0cnVjdCBs aXN0X2hlYWQJbm90aWZ5X2VudHJ5Ow0KKwlzdHJ1Y3QgY25fY3RsX21zZwkqbXNnOw0KK307DQor DQogc3RydWN0IGNuX2Rldg0KIHsNCisJc3RydWN0IGNiX2lkIAkJaWQ7DQorDQogCXUzMgkJCXNl cSwgZ3JvdXBzOw0KIAlzdHJ1Y3Qgc29jayAJCSpubHM7DQogCXZvaWQgCQkJKCppbnB1dCkoc3Ry dWN0IHNvY2sgKnNrLCBpbnQgbGVuKTsNCkBAIC01Miw3ICs3NSw3IEBADQogDQogaW50IGNuX2Fk ZF9jYWxsYmFjayhzdHJ1Y3QgY2JfaWQgKiwgY2hhciAqLCB2b2lkICgqIGNhbGxiYWNrKSh2b2lk ICopKTsNCiB2b2lkIGNuX2RlbF9jYWxsYmFjayhzdHJ1Y3QgY2JfaWQgKik7DQotdm9pZCBjbl9u ZXRsaW5rX3NlbmQoc3RydWN0IGNuX21zZyAqKTsNCit2b2lkIGNuX25ldGxpbmtfc2VuZChzdHJ1 Y3QgY25fbXNnICosIHUzMik7DQogDQogI2VuZGlmIC8qIF9fS0VSTkVMX18gKi8NCiAjZW5kaWYg LyogX19DT05ORUNUT1JfSCAqLw0KDQoNCi0tLSBvcmlnL3Vjb24uYw0KKysrIG1vZC91Y29uLmMN CkBAIC0xMTgsOCArMTE4LDcgQEANCiAJbF9sb2NhbC5ubF9ncm91cHMgPSAxOw0KIAlsX2xvY2Fs Lm5sX3BpZCA9IGdldHBpZCgpOw0KIA0KLQlpZiAoYmluZChzLCAoc3RydWN0IHNvY2thZGRyICop JmxfbG9jYWwsIHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfbmwpKSA9PQ0KLQkgICAgLTEpIHsNCisJ aWYgKGJpbmQocywgKHN0cnVjdCBzb2NrYWRkciAqKSZsX2xvY2FsLCBzaXplb2Yoc3RydWN0IHNv Y2thZGRyX25sKSkgPT0gLTEpIHsNCiAJCXBlcnJvcigiYmluZCIpOw0KIAkJY2xvc2Uocyk7DQog CQlyZXR1cm4gLTE7DQoNCg0KDQo= --=-TIMupFxjMR70PiTEfF2B-- --=-m0BUYYOFNFPI9i++uPZT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBTo5hIKTPhE+8wY0RAqLFAJ9iKrwKSkVvnspHxd8mJrSDl5tAMACeJFJu +63sxs3kU/TfJCP9uLORZak= =LlNH -----END PGP SIGNATURE----- --=-m0BUYYOFNFPI9i++uPZT-- From herbert@gondor.apana.org.au Mon Sep 20 03:59:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 04:00:04 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KAxtKK008185 for ; Mon, 20 Sep 2004 03:59:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9LrU-000532-00; Mon, 20 Sep 2004 20:57:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9LrE-0003hY-00; Mon, 20 Sep 2004 20:57:20 +1000 Date: Mon, 20 Sep 2004 20:57:20 +1000 To: Martin Bouzek Cc: Linux Kernel , davem@davemloft.net, netdev@oss.sgi.com Subject: Re: Minor IPSec bug + solution Message-ID: <20040920105720.GA14214@gondor.apana.org.au> References: <1095413173.2708.106.camel@mabouzek> <20040917102720.GA14579@gondor.apana.org.au> <1095666589.2723.8.camel@mabouzek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095666589.2723.8.camel@mabouzek> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 894 Lines: 24 On Mon, Sep 20, 2004 at 09:49:49AM +0200, Martin Bouzek wrote: > > Ok. And would it be possible to check the protocols too (eg. > tmpl->id.proto == x->id.proto)? If it is realy not possible to make the Obviously not, since IPCOMP != IPIP. > IPComp/required tunnel to work, it would be nice to mention it in for > example the setkey man page. It could save quite lot of time to some > people. (like me :-) ). IPComp is the main reason why we have optional SAs at all. So IPComp/required definitely does not make sense. As to the documentation of this issue, feel free to write something up and send it to either the kernel maintainers or one of the user-space projects. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Sep 20 05:35:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 05:35:04 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KCYwi0013585 for ; Mon, 20 Sep 2004 05:35:00 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C9NNN-0008FO-0s for netdev@oss.sgi.com; Mon, 20 Sep 2004 08:34:37 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9NNA-0007Cd-6c; Mon, 20 Sep 2004 08:34:24 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040920025802.GA11567@gondor.apana.org.au> References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095683660.1047.254.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Sep 2004 08:34:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9134 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1352 Lines: 34 On Sun, 2004-09-19 at 22:58, Herbert Xu wrote: > Well the ip_queue thing is simply a pipe that redirects packets going > into netfilter to user space. So we can't really stop that pipe when > there is congestion. You can detect congestion by noticing thresholds on the socket queue. i.e high watermark to give opportunity to user space and low watermark to let kernel piece continue. To be honest you would probably need to do more (maybe borrow some ideas from lazy receiver processing)to be precise - but thats a good start if you can pull it. At the moment the high watermark is the queue-fill level (in which case an overrun happens) and low watermark is not defined. > AFAICT the problem Pablo is trying to solve is packet loss due to > netlink congestion. > > There might actually be a problem with the kernel not waking up the > the user process when we tell it to. It might even be a scheduling > problem. But we'll need a test-case to assess that. > Agreed. For a test i typically have something adding say 10K items (actions in my case, but could be ipsec policies) and then try to dump them. On my xeon i get an overrun after about 6K items are dumped. -> Note that the overrun would have been a good enough a signal if you could tell netlink "give me the rest of the stuff just before and including the overrun". cheers, jamal From hadi@cyberus.ca Mon Sep 20 06:24:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 06:24:58 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KDOopn014925 for ; Mon, 20 Sep 2004 06:24:50 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C9O9l-0007FK-TK for netdev@oss.sgi.com; Mon, 20 Sep 2004 09:24:37 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9O9i-0007cu-NP; Mon, 20 Sep 2004 09:24:34 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20040919195351.0b3560e6.davem@davemloft.net> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095686672.1049.301.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Sep 2004 09:24:32 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2673 Lines: 74 On Sun, 2004-09-19 at 22:53, David S. Miller wrote: > > There are two problems. Well, logically one, which is the seperation > out of fib_node from the code. > > I need to expose the layout of fib_node for other reasons. > > If you look at Ben LaHaise's case, the issue becomes evident. IIRC, he was having issues when 1000 devices all came up at once and all tried to add local scope routes? > Firstly, fib_semantics was not designed to scale at all, > thus last weeks patches to add the hash tables. Will have to look at those patches - already in? > That takes > care of half of his problems, the other half is because of > fn_hash_flush() and is what is relevant to this discussion. > > fn_hash_flush() walks the entire table of routes looking for > routes pointing to fib_info objects which are RTNH_F_DEAD. > > The simple solution is to make fib_info contain a list of > fib_node objects, then when code marks a fib_info as RTNH_F_DEAD > we just walk the list and kill the fib_node objects directly. I like the idea except for when enforcing that scheme to be used by other algorithms[1]. > But because the layout of fib_node entirely is hidden in > fib_hash.c, and we want to allow pluggable lookup implementations, > something has to give. Makes sense. > So the general idea I was after was: > > 1) All things performing pure longest-matching prefix > lookup on an ipv4 address is confined to fib_node objects > and the actual lookup algorithm. > > 2) Everything that occurs once we have a matching fib_node > object, is consolidated into a common pieces of code > that does all the TOS, priority, et al. magic sigh. Ok, some of the stuff in fib_node like TOS lookups are necessary for _total_ RFC1812 compliance. So i see where you are coming from although i am not a big fan of it. I will chew on it in the background. > Anyways, we can do this differently. But at least with my > patch we have the means to do _something_. > > > BTW, one thought to improve perfomance is to change the linked list in > > each of the buckets away from a linked list. > > Come again? I'm a little slow today, you'll have to be a bit > more explicit about what your idea is exactly :-) Never mind. I just realized you have plans to do binary search in the hash to replace linked lists. cheers, jamal [1] The other structures which the other algs _must_ use apart from fib_info from a quick scan are: fib_result (I think this is fair), flowi, and to a small degree fib_rule (if we continue keeping policy routing where it is right now). Seems like a very clean separation to just simply replace fib_hash.c if the TOS thing can be resolved. From hadi@cyberus.ca Mon Sep 20 06:33:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 06:33:44 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KDXaxh015669 for ; Mon, 20 Sep 2004 06:33:36 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C9OIG-0002BI-5D for netdev@oss.sgi.com; Mon, 20 Sep 2004 09:33:24 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9OIB-0000j2-9J; Mon, 20 Sep 2004 09:33:19 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Herbert Xu , netdev@oss.sgi.com In-Reply-To: <20040919201735.3d9e1d6d.davem@davemloft.net> References: <1095640781.1047.168.camel@jzny.localdomain> <20040919201735.3d9e1d6d.davem@davemloft.net> Content-Type: multipart/mixed; boundary="=-lVFenb7vPWL3xlal4mf9" Organization: jamalopolous Message-Id: <1095687197.1048.310.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Sep 2004 09:33:17 -0400 X-archive-position: 9136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2192 Lines: 77 --=-lVFenb7vPWL3xlal4mf9 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2004-09-19 at 23:17, David S. Miller wrote: > On Mon, 20 Sep 2004 13:14:54 +1000 > Herbert Xu wrote: > > > jamal wrote: > > > > > > --- a/net/ipv4/fib_hash.c 2004/09/20 00:35:16 1.1 > > > +++ b/net/ipv4/fib_hash.c 2004/09/20 00:36:16 > > > @@ -915,7 +915,7 @@ > > > iter->zone = iter->zone->fz_next) { > > > int maxslot; > > > > > > - if (!iter->zone->fz_next) > > > + if (!iter->zone->fz_nent) > > > continue; > > > > Good catch. There seems to be another problem with the seq_file > > conversion. Why is this check only in fib_get_first(), but not > > in fib_get_next()? > > > > Either it's needed in fib_get_next() as well, or it can be removed here. > > It's an optimization, the hash list traversal will find no entries > even if we don't do this test. > > It does belong in fib_get_next(), so I'll happily add it there. > Thanks. Seems like get_first just populates the fib_iter_state with the first valid entry and fib_get_next gets the next valid one - Sorry never paid attention when patches for these were going in. In which case the check for zero entries is missing from fib_get_next making it ineeficient (but not buggy). A more complete patch (untested, uncompiled) attached. cheers, jamal --=-lVFenb7vPWL3xlal4mf9 Content-Disposition: attachment; filename=fibhash_p_2 Content-Type: text/plain; name=fibhash_p_2; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- a/net/ipv4/fib_hash.c 2004/09/20 00:35:16 1.1 +++ b/net/ipv4/fib_hash.c 2004/09/20 13:30:56 @@ -915,7 +915,7 @@ iter->zone = iter->zone->fz_next) { int maxslot; - if (!iter->zone->fz_next) + if (!iter->zone->fz_nent) continue; iter->hash = iter->zone->fz_hash; @@ -958,10 +958,13 @@ goto out; } +get_next_zone: iter->zone = iter->zone->fz_next; if (!iter->zone) goto out; + if (!iter->zone->fz_nent) + goto get_next_zone; iter->hash = iter->zone->fz_hash; iter->bucket = 0; --=-lVFenb7vPWL3xlal4mf9-- From laforge@gnumonks.org Mon Sep 20 07:10:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 07:10:51 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KEAh65017520 for ; Mon, 20 Sep 2004 07:10:44 -0700 Received: from dsl-082-082-097-127.arcor-ip.net ([82.82.97.127] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9OsB-0006J2-AA for netdev@oss.sgi.com; Mon, 20 Sep 2004 16:10:31 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9OsA-0001dG-Bk for netdev@oss.sgi.com; Mon, 20 Sep 2004 16:10:30 +0200 Date: Mon, 20 Sep 2004 16:10:30 +0200 From: Harald Welte To: netdev@oss.sgi.com Subject: [PATCH 2.6] natsemi.c NAPI Message-ID: <20040920141030.GV1307@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7a4X6VOqfbl9xMrG" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 11182 Lines: 381 --7a4X6VOqfbl9xMrG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! As announced before, here is the NAPI-patch for natsemi.c My 266 MHz National Geode SC1100 (http://www.pcengines.ch/wrap.htm) with two natsemi chips can now forward 32kpps at (64bytes, 148kpps, single flow UDP input). Any comments welcome, just like inclusion of this patch :) Signed-off-by: Harald Welte diff -Nru linux-2.6.9-rc1-plain/drivers/net/Kconfig linux-2.6.9-rc1-natsemi= -napi/drivers/net/Kconfig --- linux-2.6.9-rc1-plain/drivers/net/Kconfig 2004-08-31 20:24:39.000000000= +0200 +++ linux-2.6.9-rc1-natsemi-napi/drivers/net/Kconfig 2004-09-14 22:10:29.00= 0000000 +0200 @@ -1534,6 +1534,22 @@ and others, including the 83815 chip. More specific information and updates are available from . +config NATSEMI_NAPI + bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" + depends on NATSEMI && EXPERIMENTAL + help + NAPI is a new driver API designed to reduce CPU and interrupt load + when the driver is receiving lots of packets from the card. It is + still somewhat experimental and thus not yet enabled by default. + + If your estimated Rx load is 10kpps or more, or if the card will be + deployed on potentially unfriendly networks (e.g. in a firewall), + then say Y here. + + See for more + information. + + If in doubt, say N. =20 config NE2K_PCI tristate "PCI NE2000 and clones support (see help)" diff -Nru linux-2.6.9-rc1-plain/drivers/net/natsemi.c linux-2.6.9-rc1-natse= mi-napi/drivers/net/natsemi.c --- linux-2.6.9-rc1-plain/drivers/net/natsemi.c 2004-08-31 20:24:39.0000000= 00 +0200 +++ linux-2.6.9-rc1-natsemi-napi/drivers/net/natsemi.c 2004-09-18 14:09:59.= 000000000 +0200 @@ -3,6 +3,7 @@ Written/copyright 1999-2001 by Donald Becker. Portions copyright (c) 2001,2002 Sun Microsystems (thockin@sun.com) Portions copyright 2001,2002 Manfred Spraul (manfred@colorfullife.com) + Portions copyright 2004 Harald Welte =20 This software may be used and distributed according to the terms of the GNU General Public License (GPL), incorporated herein by reference. @@ -133,10 +134,12 @@ * comments update (Manfred) * do the right thing on a phy-reset (Manfred and Tim) =20 + version 1.0.18: + * Make use of NAPI (Harald Welte) + TODO: * big endian support with CFG:BEM instead of cpu_to_le32 * support for an external PHY - * NAPI */ =20 #include @@ -166,8 +169,8 @@ #include =20 #define DRV_NAME "natsemi" -#define DRV_VERSION "1.07+LK1.0.17" -#define DRV_RELDATE "Sep 27, 2002" +#define DRV_VERSION "1.07+LK1.0.18" +#define DRV_RELDATE "Sep 18, 2004" =20 #define RX_OFFSET 2 =20 @@ -183,8 +186,6 @@ NETIF_MSG_TX_ERR) static int debug =3D -1; =20 -/* Maximum events (Rx packets, etc.) to handle at each interrupt. */ -static int max_interrupt_work =3D 20; static int mtu; =20 /* Maximum number of multicast addresses to filter (vs. rx-all-multicast). @@ -251,14 +252,11 @@ MODULE_DESCRIPTION("National Semiconductor DP8381x series PCI Ethernet dri= ver"); MODULE_LICENSE("GPL"); =20 -MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM(mtu, "i"); MODULE_PARM(debug, "i"); MODULE_PARM(rx_copybreak, "i"); MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); -MODULE_PARM_DESC(max_interrupt_work,=20 - "DP8381x maximum events handled per interrupt"); MODULE_PARM_DESC(mtu, "DP8381x MTU (all boards)"); MODULE_PARM_DESC(debug, "DP8381x default debug level"); MODULE_PARM_DESC(rx_copybreak,=20 @@ -416,8 +414,12 @@ StatsCtrl =3D 0x5C, StatsData =3D 0x60, RxPktErrs =3D 0x60, - RxMissed =3D 0x68, RxCRCErrs =3D 0x64, + RxMissed =3D 0x68, + RxFAErrors =3D 0x6C, + RxSymbolErrors =3D 0x70, + RxFrameTooLong =3D 0x74, + TxSQEErrors =3D 0x78, BasicControl =3D 0x80, BasicStatus =3D 0x84, AnegAdv =3D 0x90, @@ -769,6 +771,20 @@ static int netdev_get_regs(struct net_device *dev, u8 *buf); static int netdev_get_eeprom(struct net_device *dev, u8 *buf); =20 +static inline void natsemi_irq_enable(struct netdev_private *np) +{ + /* Enable interrupts by setting the interrupt mask. */ + writel(DEFAULT_INTR, np->base_addr + IntrMask); + writel(1, np->base_addr + IntrEnable); + mb(); +} + +static inline void natsemi_irq_disable(struct netdev_private *np) +{ + writel(0, np->base_addr + IntrEnable); + mb(); +} + static void move_int_phy(struct net_device *dev, int addr) { struct netdev_private *np =3D netdev_priv(dev); @@ -923,6 +939,11 @@ dev->do_ioctl =3D &netdev_ioctl; dev->tx_timeout =3D &tx_timeout; dev->watchdog_timeo =3D TX_TIMEOUT; +#ifdef CONFIG_NATSEMI_NAPI + dev->poll =3D natsemi_clean; + dev->weight =3D 64; +#endif + #ifdef CONFIG_NET_POLL_CONTROLLER dev->poll_controller =3D &natsemi_poll_controller; #endif @@ -2135,6 +2156,62 @@ } } =20 +/* the second half of the interrupt handler, used for NAPI and non-NAPI pa= th */ +#ifdef CONFIG_NATSEMI_NAPI +static int intr_handler2(struct net_device *dev, int *work_done, int work_= to_do) +#else +static int intr_handler2(struct net_device *dev) +#endif +{ + struct netdev_private *np =3D netdev_priv(dev); + long ioaddr =3D dev->base_addr; + int boguscnt =3D max_interrupt_work; + + /* Reading automatically acknowledges all int sources. */ + u32 intr_status =3D readl(ioaddr + IntrStatus); + + if (np->hands_off) + return 0; + + if (intr_status =3D=3D 0) + return 0; + + if (netif_msg_intr(np)) + printk(KERN_DEBUG + "%s: Interrupt, status %#08x, mask %#08x.\n", + dev->name, intr_status, + readl(ioaddr + IntrMask)); + + /* Abnormal error summary/uncommon events handlers. */ + if (intr_status & IntrAbnormalSummary) + netdev_error(dev, intr_status); + + if (intr_status & + (IntrTxDone | IntrTxIntr | IntrTxIdle | IntrTxErr)) { + spin_lock(&np->lock); + netdev_tx_done(dev); + spin_unlock(&np->lock); + } + + if (intr_status & + (IntrRxDone | IntrRxIntr | RxStatusFIFOOver | + IntrRxErr | IntrRxOverrun)) { +#ifdef CONFIG_NATSEMI_NAPI + netdev_rx(dev, work_done, work_to_do); +#else + netdev_rx(dev); +#endif + } + /* FIXME: if quota not yet fulfilled, read status and restart + * from top if non-null */ + + if (netif_msg_intr(np)) + printk(KERN_DEBUG "%s: exiting interrupt.\n", dev->name); + + return 1; +} + + /* The interrupt handler does all of the Rx thread work and cleans up after the Tx thread. */ static irqreturn_t intr_handler(int irq, void *dev_instance, struct pt_reg= s *rgs) @@ -2143,60 +2220,55 @@ struct netdev_private *np =3D netdev_priv(dev); long ioaddr =3D dev->base_addr; int boguscnt =3D max_interrupt_work; - unsigned int handled =3D 0; =20 - if (np->hands_off) +#ifdef CONFIG_NATSEMI_NAPI + if (n->hands_off)=20 return IRQ_NONE; - do { - /* Reading automatically acknowledges all int sources. */ - u32 intr_status =3D readl(ioaddr + IntrStatus); =20 - if (netif_msg_intr(np)) - printk(KERN_DEBUG - "%s: Interrupt, status %#08x, mask %#08x.\n", - dev->name, intr_status, - readl(ioaddr + IntrMask)); - - if (intr_status =3D=3D 0) - break; - handled =3D 1; - - if (intr_status & - (IntrRxDone | IntrRxIntr | RxStatusFIFOOver | - IntrRxErr | IntrRxOverrun)) { - netdev_rx(dev); - } + /* We cannot read IntrStatus since this would acknowledge + * all interrupt sources. Thus we just blindly assume that + * the interrupt really was for us -HW! */ + + if (netif_schedule_prep(dev)) { + /* Disable interrupts and register for poll */ + natsemi_irq_disable(np); + __netif_rx_schedule(dev); + } + /* FIXME: IRQ_NONE since we're not sure whether it was for us ? */=20 + return IRQ_HANDLED; +#else + return IRQ_RETVAL(intr_handler2(dev)); +#endif +} =20 - if (intr_status & - (IntrTxDone | IntrTxIntr | IntrTxIdle | IntrTxErr)) { - spin_lock(&np->lock); - netdev_tx_done(dev); - spin_unlock(&np->lock); - } +#ifdef CONFIG_NATSEMI_NAPI +static int natsemi_clean(struct net_device *dev, int *budget) +{ + struct netdev_private *np =3D netdev_priv(dev); + int work_to_do =3D min(*budget, dev->quota); + int work_done =3D 0; +=09 + intr_handler2(dev, &work_done, work_to_do); =20 - /* Abnormal error summary/uncommon events handlers. */ - if (intr_status & IntrAbnormalSummary) - netdev_error(dev, intr_status); - - if (--boguscnt < 0) { - if (netif_msg_intr(np)) - printk(KERN_WARNING - "%s: Too much work at interrupt, " - "status=3D%#08x.\n", - dev->name, intr_status); - break; - } - } while (1); + *budget -=3D work_done; + dev->quota -=3D work_done; =20 - if (netif_msg_intr(np)) - printk(KERN_DEBUG "%s: exiting interrupt.\n", dev->name); + if (work_done < work_to_do || !netif_running(dev)) { + netif_rx_complete(dev); + natsemi_irq_enable(np); + } =20 - return IRQ_RETVAL(handled); + return (work_done >=3D work_to_do); } +#endif =20 /* This routine is logically part of the interrupt handler, but separated for clarity and better register allocation. */ +#ifdef CONFIG_NATSEMI_NAPI +static void netdev_rx(struct net_device *dev, int *work_done, int work_to_= do) +#else static void netdev_rx(struct net_device *dev) +#endif { struct netdev_private *np =3D netdev_priv(dev); int entry =3D np->cur_rx % RX_RING_SIZE; @@ -2213,6 +2285,14 @@ entry, desc_status); if (--boguscnt < 0) break; + +#ifdef CONFIG_NATSEMI_NAPI + if (*work_done >=3D work_to_do) + break; + + (*work_done)++; +#endif + pkt_len =3D (desc_status & DescSizeMask) - 4; if ((desc_status&(DescMore|DescPktOK|DescRxLong)) !=3D DescPktOK){ if (desc_status & DescMore) { @@ -2269,7 +2349,11 @@ np->rx_skbuff[entry] =3D NULL; } skb->protocol =3D eth_type_trans(skb, dev); +#ifdef CONFIG_NATSEMI_NAPI + netif_receive_skb(skb); +#else netif_rx(skb); +#endif dev->last_rx =3D jiffies; np->stats.rx_packets++; np->stats.rx_bytes +=3D pkt_len; @@ -2355,6 +2439,7 @@ /* The chip only need report frame silently dropped. */ np->stats.rx_crc_errors +=3D readl(ioaddr + RxCRCErrs); np->stats.rx_missed_errors +=3D readl(ioaddr + RxMissed); + np->stats.tx_heartbeat_errors +=3D readl(ioaddr + TxSQEErrors); } =20 static struct net_device_stats *get_stats(struct net_device *dev) --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --7a4X6VOqfbl9xMrG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBTuTWXaXGVTD0i/8RAhnyAKCASZMtVXewYeVhx2D6mVNzY3EeAwCfVmk5 4TwUC422cPGaPMzYamdEzFI= =pegq -----END PGP SIGNATURE----- --7a4X6VOqfbl9xMrG-- From niv@us.ibm.com Mon Sep 20 08:54:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 08:54:42 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KFsaNB027455 for ; Mon, 20 Sep 2004 08:54:36 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8KFsJRK614154; Mon, 20 Sep 2004 11:54:19 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8KFtWeW163684; Mon, 20 Sep 2004 11:55:33 -0400 Message-ID: <414EFD2A.5000805@us.ibm.com> Date: Mon, 20 Sep 2004 08:54:18 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anton Blanchard CC: netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: <20040920063012.GL2825@krispykreme> In-Reply-To: <20040920063012.GL2825@krispykreme> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9138 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 415 Lines: 15 Anton Blanchard wrote: > Hi, > > I just tried latest 2.6.9-rc2-BK on a machine with an e1000 on it. With > TSO off it does about 100MB/sec. With TSO on it does between 1MB/sec and > 10MB/sec. Hey Anton, yep, I was just debugging this. TSO mainline reworked implementation is still not cooked. Don't worry, final state won't be this bad :). Could you echo 0 > /proc/sys/net/ipv4/tcp_bic and redo test, please? From jdmason@us.ibm.com Mon Sep 20 09:06:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 09:06:49 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KG6h2l028725 for ; Mon, 20 Sep 2004 09:06:43 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8KG6Ccs631610; Mon, 20 Sep 2004 12:06:12 -0400 Received: from dyn94194162.austin.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8KG6B4D078038; Mon, 20 Sep 2004 10:06:12 -0600 From: Jon Mason Organization: IBM To: Andy Lutomirski Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Date: Mon, 20 Sep 2004 11:06:06 -0500 User-Agent: KMail/1.6.2 Cc: Francois Romieu , Hans-Frieder Vogt , linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com References: <200409130035.50823.hfvogt@arcor.de> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> In-Reply-To: <414DF773.7060402@myrealbox.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409201106.06363.jdmason@us.ltcfwd.linux.ibm.com> X-archive-position: 9139 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 287 Lines: 11 Andy, Your setup sounds very similar to mine, and I am not hitting the error. I am running Gentoo on AMD Athlon(tm) 64 Processor 3200+ with 512MB RAM. My r8169 adapter (8110 chipset) is integrated in my MoBo. How is your setup different? Thanks, -- Jon Mason jdmason@us.ibm.com From cd@cdaniel.de Mon Sep 20 10:08:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 10:08:24 -0700 (PDT) Received: from kampfzwerg.cdaniel.de (kampfzwerg.cdaniel.de [62.134.51.207]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KH8DE4029986 for ; Mon, 20 Sep 2004 10:08:16 -0700 Received: from localhost (localhost [127.0.0.1]) by kampfzwerg.cdaniel.de (Postfix) with ESMTP id 5203B4B48C for ; Mon, 20 Sep 2004 19:07:57 +0200 (CEST) Received: from kampfzwerg.cdaniel.de ([127.0.0.1]) by localhost (kampfzwerg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25972-01 for ; Mon, 20 Sep 2004 19:07:44 +0200 (CEST) Received: from [10.254.2.2] (localhost [127.0.0.1]) by kampfzwerg.cdaniel.de (Postfix) with ESMTP id 7C7B44B48B for ; Mon, 20 Sep 2004 19:07:44 +0200 (CEST) From: Christian Daniel To: netdev@oss.sgi.com Subject: "dst cache overflow" Date: Mon, 20 Sep 2004 19:07:43 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200409201907.43317.cd@cdaniel.de> X-Virus-Scanned: by Kampfzwerg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8KH8DE4029986 X-archive-position: 9140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cd@cdaniel.de Precedence: bulk X-list: netdev Content-Length: 19821 Lines: 383 Hello everybody, I'm running Linux 2.6.8.1+pom20040621+imq+... as a firewall and router on a 2MBit/s leased line to our ISP. After about 24 hours I get loads of "dst cache overflow" messages and extreme packet loss occurs on all routed connections - bridges continue to work. Sep 20 15:23:05 sylvaner kernel: printk: 717 messages suppressed. Sep 20 15:23:05 sylvaner kernel: dst cache overflow Sep 20 15:23:10 sylvaner kernel: printk: 720 messages suppressed. Sep 20 15:23:10 sylvaner kernel: dst cache overflow Sep 20 15:23:15 sylvaner kernel: printk: 767 messages suppressed. Sep 20 15:23:15 sylvaner kernel: dst cache overflow rtstat over several hours: size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot mc GC:tot ignore gmiss dstof HLS:in out 10501 593 339 0 0 0 0 0 250 24 0 362 360 2 0 229 48 10483 541 337 0 0 0 0 0 247 27 0 363 361 2 0 183 72 10491 639 400 0 0 1 0 0 275 39 0 437 435 2 0 245 81 10529 649 385 0 0 0 0 0 276 28 0 413 411 2 0 264 71 10515 619 417 0 0 1 0 0 256 20 0 335 333 2 0 257 93 10496 474 293 0 0 0 0 0 194 20 0 311 309 2 0 193 60 [... after about four hours] 15032 729 441 0 0 0 0 0 365 31 0 471 469 2 0 268 102 15034 804 439 0 0 0 0 0 400 11 0 448 446 2 0 247 128 15054 593 411 0 0 0 0 0 321 25 0 434 432 2 0 213 95 15016 826 361 0 0 0 0 0 393 12 0 371 369 2 0 235 84 15068 1011 498 0 0 0 0 0 444 13 0 429 427 2 0 293 110 (I modified rtstat to display garbage-collection statistics as well - patch is submitted to iproute2 maintainer) Latest Slabinfo looks like this: slabinfo - version: 2.0 # name : tunables : slabdata ip_conntrack_expect 7 62 128 31 1 : tunables 120 60 0 : slabdata 2 2 0 ip_conntrack 6132 9096 320 12 1 : tunables 54 27 0 : slabdata 758 758 0 ip_fib_hash 125 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0 bridge_fdb_cache 31 61 64 61 1 : tunables 120 60 0 : slabdata 1 1 0 uhci_urb_priv 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0 unix_sock 164 200 384 10 1 : tunables 54 27 0 : slabdata 20 20 0 tcp_tw_bucket 8 41 96 41 1 : tunables 120 60 0 : slabdata 1 1 0 tcp_bind_bucket 10 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0 tcp_open_request 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 inet_peer_cache 214 305 64 61 1 : tunables 120 60 0 : slabdata 5 5 0 secpath_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 xfrm_dst_cache 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 ip_dst_cache 15300 15420 256 15 1 : tunables 120 60 0 : slabdata 1028 1028 0 arp_cache 294 341 128 31 1 : tunables 120 60 0 : slabdata 11 11 0 raw4_sock 0 0 480 8 1 : tunables 54 27 0 : slabdata 0 0 0 udp_sock 8 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0 tcp_sock 125 152 1024 4 1 : tunables 54 27 0 : slabdata 38 38 0 flow_cache 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 journal_handle 61 135 28 135 1 : tunables 120 60 0 : slabdata 1 1 0 journal_head 29 162 48 81 1 : tunables 120 60 0 : slabdata 2 2 0 revoke_table 6 290 12 290 1 : tunables 120 60 0 : slabdata 1 1 0 revoke_record 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0 ext3_inode_cache 47326 49473 448 9 1 : tunables 54 27 0 : slabdata 5497 5497 0 ext3_xattr 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0 eventpoll_pwq 0 0 36 107 1 : tunables 120 60 0 : slabdata 0 0 0 eventpoll_epi 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 kioctx 0 0 160 25 1 : tunables 120 60 0 : slabdata 0 0 0 kiocb 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 dnotify_cache 0 0 20 185 1 : tunables 120 60 0 : slabdata 0 0 0 file_lock_cache 38 86 92 43 1 : tunables 120 60 0 : slabdata 2 2 0 fasync_cache 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0 shmem_inode_cache 8 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0 posix_timers_cache 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 uid_cache 2 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0 cfq_pool 64 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0 crq_pool 0 0 36 107 1 : tunables 120 60 0 : slabdata 0 0 0 deadline_drq 0 0 48 81 1 : tunables 120 60 0 : slabdata 0 0 0 as_arq 17 65 60 65 1 : tunables 120 60 0 : slabdata 1 1 0 blkdev_ioc 22 185 20 185 1 : tunables 120 60 0 : slabdata 1 1 0 blkdev_queue 1 9 448 9 1 : tunables 54 27 0 : slabdata 1 1 0 blkdev_requests 8 26 152 26 1 : tunables 120 60 0 : slabdata 1 1 0 biovec-(256) 256 256 3072 2 2 : tunables 24 12 0 : slabdata 128 128 0 biovec-128 256 260 1536 5 2 : tunables 24 12 0 : slabdata 52 52 0 biovec-64 256 260 768 5 1 : tunables 54 27 0 : slabdata 52 52 0 biovec-16 256 260 192 20 1 : tunables 120 60 0 : slabdata 13 13 0 biovec-4 256 305 64 61 1 : tunables 120 60 0 : slabdata 5 5 0 biovec-1 260 452 16 226 1 : tunables 120 60 0 : slabdata 2 2 0 bio 272 305 64 61 1 : tunables 120 60 0 : slabdata 5 5 0 sock_inode_cache 305 352 352 11 1 : tunables 54 27 0 : slabdata 32 32 0 skbuff_head_cache 760 1060 192 20 1 : tunables 120 60 0 : slabdata 53 53 0 sock 6 12 320 12 1 : tunables 54 27 0 : slabdata 1 1 0 proc_inode_cache 889 1008 320 12 1 : tunables 54 27 0 : slabdata 84 84 0 sigqueue 3 27 148 27 1 : tunables 120 60 0 : slabdata 1 1 0 radix_tree_node 2361 5152 276 14 1 : tunables 54 27 0 : slabdata 368 368 0 bdev_cache 6 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0 mnt_cache 20 41 96 41 1 : tunables 120 60 0 : slabdata 1 1 0 inode_cache 4306 4466 288 14 1 : tunables 54 27 0 : slabdata 319 319 0 dentry_cache 47234 54376 140 28 1 : tunables 120 60 0 : slabdata 1942 1942 0 filp 1382 1625 160 25 1 : tunables 120 60 0 : slabdata 65 65 0 names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0 idr_layer_cache 112 145 136 29 1 : tunables 120 60 0 : slabdata 5 5 0 buffer_head 17913 21141 48 81 1 : tunables 120 60 0 : slabdata 261 261 0 mm_struct 133 133 512 7 1 : tunables 54 27 0 : slabdata 19 19 0 vm_area_struct 2386 2914 84 47 1 : tunables 120 60 0 : slabdata 62 62 0 fs_cache 107 238 32 119 1 : tunables 120 60 0 : slabdata 2 2 0 files_cache 108 126 416 9 1 : tunables 54 27 0 : slabdata 14 14 0 signal_cache 123 164 96 41 1 : tunables 120 60 0 : slabdata 4 4 0 sighand_cache 120 129 1312 3 1 : tunables 24 12 0 : slabdata 43 43 0 task_struct 124 145 1424 5 2 : tunables 24 12 0 : slabdata 29 29 0 anon_vma 1286 1628 8 407 1 : tunables 120 60 0 : slabdata 4 4 0 pgd 109 109 4096 1 1 : tunables 24 12 0 : slabdata 109 109 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 124 124 8192 1 2 : tunables 8 4 0 : slabdata 124 124 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 0 : slabdata 0 0 0 size-4096 115 115 4096 1 1 : tunables 24 12 0 : slabdata 115 115 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 0 : slabdata 0 0 0 size-2048 206 214 2048 2 1 : tunables 24 12 0 : slabdata 107 107 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 0 : slabdata 0 0 0 size-1024 136 136 1024 4 1 : tunables 54 27 0 : slabdata 34 34 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 0 : slabdata 0 0 0 size-512 308 552 512 8 1 : tunables 54 27 0 : slabdata 69 69 0 size-256(DMA) 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 size-256 765 900 256 15 1 : tunables 120 60 0 : slabdata 60 60 0 size-192(DMA) 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0 size-192 200 200 192 20 1 : tunables 120 60 0 : slabdata 10 10 0 size-128(DMA) 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 size-128 399 465 128 31 1 : tunables 120 60 0 : slabdata 15 15 0 size-96(DMA) 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 size-96 2138 2378 96 41 1 : tunables 120 60 0 : slabdata 58 58 0 size-64(DMA) 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 size-64 1221 1342 64 61 1 : tunables 120 60 0 : slabdata 22 22 0 size-32(DMA) 0 0 32 119 1 : tunables 120 60 0 : slabdata 0 0 0 size-32 1487 1666 32 119 1 : tunables 120 60 0 : slabdata 14 14 0 kmem_cache 124 124 128 31 1 : tunables 120 60 0 : slabdata 4 4 0 /proc/sys/net/ipv4/route/max_size is 16384 By increasing that value I can delay the moment the machine starts to drop packets - but it will happen anyways. One thing that astonishes me is that "ip route ls cache" shows only about 350 entries. Shouldn't that be more like 15000 as rtstat tells? The rest of the mail shows the excact setup of the machine - I bet it is one of the more complex firewalls around :-) - Machine has four ethernet devices - Several ppp devices for PPTP tunnels - one PPP device for DSL (second ISP connection, used to route P2P-Traffic via MASQ, Packets are marked via fwmark 0x10) - several tun devices for OpenVPN tunnels - several tap devices... sylvaner:~# brctl show bridge name bridge id STP enabled interfaces br50 8000.0060972ce1d2 no eth0 eth2 eth3 br51 8000.000000000000 no <- bridge without dev brwave 8000.00a0243878ed no eth1 tap0 Routing is done between br50, brwave, ppp-dsl and the different pptp tunnel ends. sylvaner:~# ip route show 62.134.51.225 dev ppp8 proto kernel scope link src 62.134.51.254 62.134.51.230 dev ppp18 proto kernel scope link src 62.134.51.254 62.134.51.201 via 10.254.1.10 dev tun0 62.134.51.203 dev ppp14 proto kernel scope link src 62.134.51.254 62.134.51.202 dev ppp15 proto kernel scope link src 62.134.51.254 62.134.51.207 dev tun2 proto kernel scope link src 62.134.51.254 62.134.51.206 dev ppp11 proto kernel scope link src 62.134.51.254 62.134.51.221 dev ppp29 proto kernel scope link src 62.134.51.254 62.134.51.208 dev ppp24 proto kernel scope link src 62.134.51.254 62.134.51.210 via 10.254.1.14 dev tun5 62.134.51.212 dev ppp16 proto kernel scope link src 62.134.51.254 194.94.249.251 via 217.5.98.56 dev ppp3 217.5.98.56 dev ppp3 proto kernel scope link src 80.133.233.158 62.134.51.43 dev ppp34 proto kernel scope link src 62.134.51.254 62.134.51.40 dev ppp22 proto kernel scope link src 62.134.51.254 62.134.51.41 dev ppp40 proto kernel scope link src 62.134.51.254 62.134.51.38 dev ppp36 proto kernel scope link src 62.134.51.254 62.134.51.39 dev ppp35 proto kernel scope link src 62.134.51.254 62.134.51.36 dev ppp38 proto kernel scope link src 62.134.51.254 62.134.51.37 dev ppp33 proto kernel scope link src 62.134.51.254 62.134.51.35 dev ppp37 proto kernel scope link src 62.134.51.254 62.134.51.32 dev ppp32 proto kernel scope link src 62.134.51.254 62.134.51.33 dev ppp1 proto kernel scope link src 62.134.51.254 10.254.1.14 dev tun5 proto kernel scope link src 10.254.1.13 10.254.1.12 dev tun4 proto kernel scope link src 10.254.1.11 10.254.1.10 dev tun0 proto kernel scope link src 10.254.1.9 10.254.1.4 dev tun3 proto kernel scope link src 10.254.1.3 10.254.1.2 dev tun1 proto kernel scope link src 10.254.1.1 62.134.51.15 dev ppp12 proto kernel scope link src 62.134.51.254 62.134.51.14 dev ppp30 proto kernel scope link src 62.134.51.254 62.134.51.12 dev ppp19 proto kernel scope link src 62.134.51.254 62.134.51.10 dev ppp17 proto kernel scope link src 62.134.51.254 62.134.51.9 dev ppp10 proto kernel scope link src 62.134.51.254 62.134.51.8 dev ppp23 proto kernel scope link src 62.134.51.254 62.134.51.6 dev ppp5 proto kernel scope link src 62.134.51.254 62.134.51.5 dev ppp2 proto kernel scope link src 62.134.51.254 62.134.51.4 dev ppp7 proto kernel scope link src 62.134.51.254 62.134.51.3 dev ppp31 proto kernel scope link src 62.134.51.254 62.134.51.2 dev ppp6 proto kernel scope link src 62.134.51.254 62.134.51.31 dev ppp39 proto kernel scope link src 62.134.51.254 62.134.51.30 dev ppp20 proto kernel scope link src 62.134.51.254 62.134.51.29 dev ppp25 proto kernel scope link src 62.134.51.254 62.134.51.28 dev ppp9 proto kernel scope link src 62.134.51.254 62.134.51.27 dev ppp27 proto kernel scope link src 62.134.51.254 62.134.51.26 dev ppp42 proto kernel scope link src 62.134.51.254 62.134.51.25 dev ppp41 proto kernel scope link src 62.134.51.254 62.134.51.24 dev ppp0 proto kernel scope link src 62.134.51.254 62.134.51.23 dev ppp21 proto kernel scope link src 62.134.51.254 62.134.51.21 dev ppp28 proto kernel scope link src 62.134.51.254 62.134.51.18 dev ppp13 proto kernel scope link src 62.134.51.254 62.134.51.17 dev ppp26 proto kernel scope link src 62.134.51.254 10.1.12.0/24 via 10.1.1.241 dev brwave 10.1.13.0/24 via 10.1.1.241 dev brwave 10.1.14.0/24 via 10.1.1.241 dev brwave 10.1.8.0/24 via 10.1.1.241 dev brwave 10.1.9.0/24 via 10.1.1.241 dev brwave 10.1.10.0/24 via 10.1.1.241 dev brwave 10.1.11.0/24 via 10.1.1.241 dev brwave 10.254.2.0/24 via 10.254.1.4 dev tun3 10.1.4.0/24 via 10.1.1.241 dev brwave blackhole 10.1.5.0/24 10.1.6.0/24 via 10.1.1.241 dev brwave 10.1.7.0/24 via 10.1.1.241 dev brwave 62.134.50.0/24 dev br50 proto kernel scope link src 62.134.50.253 10.1.1.0/24 dev brwave proto kernel scope link src 10.1.1.254 62.134.51.0/24 dev br51 proto kernel scope link src 62.134.51.254 10.1.2.0/24 via 10.1.1.240 dev brwave 10.1.3.0/24 via 10.1.1.240 dev brwave 10.2.0.0/16 via 10.1.1.241 dev brwave blackhole 10.3.0.0/16 10.4.0.0/16 via 10.1.1.241 dev brwave 10.5.0.0/16 via 10.1.1.241 dev brwave default via 62.134.50.254 dev br50 sylvaner:~# ip rule show 0: from all lookup local 32765: from all fwmark 10 lookup 200 32766: from all lookup main 32767: from all lookup default sylvaner:~# ip route show table 200 default via 217.5.98.56 dev ppp3 Perhaps somebody knows what's wrong? Kernel bug or PEBKAC? I'm eager to deliver more info when asked to :-) Thanks, Christian -- +-------------------------------------------------------+ | Christian Daniel | | Drechselblick 5 Mariannhillstraße 6 / App. 220 | | D-97816 Lohr am Main D-97074 Würzburg | +-----------------------+---------------+---------------+ | http://www.cdaniel.de | cd@cdaniel.de | ICQ: 95896119 | +-----------------------+---------------+---------------+ From shemminger@osdl.org Mon Sep 20 10:48:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 10:48:14 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KHm8Df000585 for ; Mon, 20 Sep 2004 10:48:09 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8KHlbv27588; Mon, 20 Sep 2004 10:47:37 -0700 Date: Mon, 20 Sep 2004 10:45:35 -0700 From: Stephen Hemminger To: Jes Sorensen , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (2/4) acenic - eliminate MAX_SKB_FRAGS #if Message-Id: <20040920104535.4c6ce363@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9144 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1510 Lines: 68 Since MAX_SKB_FRAGS is defined in both 2.4 and 2.6, it makes sense to eliminate this old #if code. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-09-20 10:46:46 -07:00 +++ b/drivers/net/acenic.c 2004-09-20 10:46:46 -07:00 @@ -2523,10 +2523,7 @@ if (tx_ring_full(ap, ap->tx_ret_csm, idx)) goto overflow; -#if MAX_SKB_FRAGS - if (!skb_shinfo(skb)->nr_frags) -#endif - { + if (!skb_shinfo(skb)->nr_frags) { dma_addr_t mapping; u32 vlan_tag = 0; @@ -2548,9 +2545,7 @@ flagsize |= BD_FLG_COAL_NOW; ace_load_tx_bd(ap, desc, mapping, flagsize, vlan_tag); - } -#if MAX_SKB_FRAGS - else { + } else { dma_addr_t mapping; u32 vlan_tag = 0; int i, len = 0; @@ -2605,7 +2600,6 @@ ace_load_tx_bd(ap, desc, mapping, flagsize, vlan_tag); } } -#endif wmb(); ap->tx_prd = idx; diff -Nru a/drivers/net/acenic.h b/drivers/net/acenic.h --- a/drivers/net/acenic.h 2004-09-20 10:46:46 -07:00 +++ b/drivers/net/acenic.h 2004-09-20 10:46:46 -07:00 @@ -10,11 +10,6 @@ */ #define USE_TX_COAL_NOW 0 -#ifndef MAX_SKB_FRAGS -#define MAX_SKB_FRAGS 0 -#endif - - /* * Addressing: * @@ -712,13 +707,7 @@ } #define tx_free(ap) tx_space((ap)->tx_ret_csm, (ap)->tx_prd, ap) - -#if MAX_SKB_FRAGS #define tx_ring_full(ap, csm, prd) (tx_space(ap, csm, prd) <= TX_RESERVED) -#else -#define tx_ring_full 0 -#endif - static inline void set_aceaddr(aceaddr *aa, dma_addr_t addr) { From shemminger@osdl.org Mon Sep 20 10:48:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 10:48:10 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KHm1Ep000569 for ; Mon, 20 Sep 2004 10:48:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8KHlbv27592; Mon, 20 Sep 2004 10:47:37 -0700 Date: Mon, 20 Sep 2004 10:47:24 -0700 From: Stephen Hemminger To: Jes Sorensen , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (4/4) acenic - don't spin forever in hard_start_xmit Message-Id: <20040920104724.2a5d2b47@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1037 Lines: 43 If driver is stuck due to ring full and hardware or link error, don't spin forever in the hard_start_xmit routine. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-09-20 10:47:22 -07:00 +++ b/drivers/net/acenic.c 2004-09-20 10:47:22 -07:00 @@ -2499,6 +2499,7 @@ struct ace_regs __iomem *regs = ap->regs; struct tx_desc *desc; u32 idx, flagsize; + unsigned long maxjiff = jiffies + 3*HZ; restart: idx = ap->tx_prd; @@ -2602,7 +2603,7 @@ } dev->trans_start = jiffies; - return 0; + return NETDEV_TX_OK; overflow: /* @@ -2621,8 +2622,15 @@ * Alternative is to return with 1 not throttling queue. In this * case loop becomes longer, no more useful effects. */ - barrier(); - goto restart; + if (time_before(jiffies, maxjiff)) { + barrier(); + cpu_relax(); + goto restart; + } + + /* The ring is stuck full. */ + printk(KERN_WARNING "%s: Transmit ring stuck full\n", dev->name); + return NETDEV_TX_BUSY; } From shemminger@osdl.org Mon Sep 20 10:48:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 10:48:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KHm14K000568 for ; Mon, 20 Sep 2004 10:48:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8KHlav27584; Mon, 20 Sep 2004 10:47:36 -0700 Date: Mon, 20 Sep 2004 10:44:55 -0700 From: Stephen Hemminger To: Jes Sorensen , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (1/4) acenic - use netdev_priv Message-Id: <20040920104455.6cb37915@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9142 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1133 Lines: 37 Trivial, use netdev_priv Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-09-20 10:46:22 -07:00 +++ b/drivers/net/acenic.c 2004-09-20 10:46:22 -07:00 @@ -1618,7 +1618,7 @@ static void ace_tasklet(unsigned long dev) { - struct ace_private *ap = ((struct net_device *)dev)->priv; + struct ace_private *ap = netdev_priv((struct net_device *)dev); int cur_size; cur_size = atomic_read(&ap->cur_rx_bufs); diff -Nru a/drivers/net/acenic.h b/drivers/net/acenic.h --- a/drivers/net/acenic.h 2004-09-20 10:46:22 -07:00 +++ b/drivers/net/acenic.h 2004-09-20 10:46:22 -07:00 @@ -750,7 +750,7 @@ static inline void ace_mask_irq(struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; if (ACE_IS_TIGON_I(ap)) @@ -764,7 +764,7 @@ static inline void ace_unmask_irq(struct net_device *dev) { - struct ace_private *ap = dev->priv; + struct ace_private *ap = netdev_priv(dev); struct ace_regs *regs = ap->regs; if (ACE_IS_TIGON_I(ap)) From shemminger@osdl.org Mon Sep 20 10:48:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 10:48:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KHm18w000570 for ; Mon, 20 Sep 2004 10:48:01 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8KHlav27580; Mon, 20 Sep 2004 10:47:36 -0700 Date: Mon, 20 Sep 2004 10:44:31 -0700 From: Stephen Hemminger To: Jes Sorensen , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] (3/4) acenic - __iomem warnings cleanup Message-Id: <20040920104431.0a96d6c1@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 12583 Lines: 457 This cleans all the compile warnings and most of the sparse warnings for the acenic driver relating to io memory space. Remaining warnings are because tx_ring can be either in i/o or not depending on the version of the card. Not tested on old TIGON card. Signed-off-by: Stephen Hemminger diff -Nru a/drivers/net/acenic.c b/drivers/net/acenic.c --- a/drivers/net/acenic.c 2004-09-20 10:47:00 -07:00 +++ b/drivers/net/acenic.c 2004-09-20 10:47:00 -07:00 @@ -539,7 +539,7 @@ * addresses but who gives a damn. */ dev->base_addr = pci_resource_start(pdev, 0); - ap->regs = (struct ace_regs *)ioremap(dev->base_addr, 0x4000); + ap->regs = ioremap(dev->base_addr, 0x4000); if (!ap->regs) { printk(KERN_ERR "%s: Unable to map I/O register, " "AceNIC %i will be disabled.\n", @@ -632,7 +632,7 @@ { struct net_device *dev = pci_get_drvdata(pdev); struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; short i; unregister_netdev(dev); @@ -885,7 +885,7 @@ /* * Commands are considered to be slow. */ -static inline void ace_issue_cmd(struct ace_regs *regs, struct cmd *cmd) +static inline void ace_issue_cmd(struct ace_regs __iomem *regs, struct cmd *cmd) { u32 idx; @@ -901,7 +901,7 @@ static int __init ace_init(struct net_device *dev) { struct ace_private *ap; - struct ace_regs *regs; + struct ace_regs __iomem *regs; struct ace_info *info = NULL; struct pci_dev *pdev; unsigned long myjif; @@ -1319,11 +1319,10 @@ writel(TX_RING_BASE, ®s->WinBase); if (ACE_IS_TIGON_I(ap)) { - ap->tx_ring = (struct tx_desc *)regs->Window; - for (i = 0; i < (TIGON_I_TX_RING_ENTRIES * - sizeof(struct tx_desc) / 4); i++) { - writel(0, (unsigned long)ap->tx_ring + i * 4); - } + ap->tx_ring = (struct tx_desc *) regs->Window; + for (i = 0; i < (TIGON_I_TX_RING_ENTRIES + * sizeof(struct tx_desc)) / sizeof(u32); i++) + writel(0, (void __iomem *)ap->tx_ring + i * 4); set_aceaddr(&info->tx_ctrl.rngptr, TX_RING_BASE); } else { @@ -1550,14 +1549,9 @@ static void ace_set_rxtx_parms(struct net_device *dev, int jumbo) { - struct ace_private *ap; - struct ace_regs *regs; - int board_idx; - - ap = netdev_priv(dev); - regs = ap->regs; - - board_idx = ap->board_idx; + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; + int board_idx = ap->board_idx; if (board_idx >= 0) { if (!jumbo) { @@ -1595,7 +1589,7 @@ { struct net_device *dev = data; struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; /* * We haven't received a stats update event for more than 2.5 @@ -1676,10 +1670,9 @@ */ static void ace_load_std_rx_ring(struct ace_private *ap, int nr_bufs) { - struct ace_regs *regs; + struct ace_regs __iomem *regs = ap->regs; short i, idx; - - regs = ap->regs; + prefetchw(&ap->cur_rx_bufs); @@ -1740,11 +1733,9 @@ static void ace_load_mini_rx_ring(struct ace_private *ap, int nr_bufs) { - struct ace_regs *regs; + struct ace_regs __iomem *regs = ap->regs; short i, idx; - regs = ap->regs; - prefetchw(&ap->cur_mini_bufs); idx = ap->rx_mini_skbprd; @@ -1799,11 +1790,9 @@ */ static void ace_load_jumbo_rx_ring(struct ace_private *ap, int nr_bufs) { - struct ace_regs *regs; + struct ace_regs __iomem *regs = ap->regs; short i, idx; - regs = ap->regs; - idx = ap->rx_jumbo_skbprd; for (i = 0; i < nr_bufs; i++) { @@ -2083,8 +2072,7 @@ * the 12.3.x Firmware - my Tigon I NICs seem to disagree! */ if (ACE_IS_TIGON_I(ap)) { - struct ace_regs *regs = ap->regs; - writel(idx, ®s->RxRetCsm); + writel(idx, &ap->regs->RxRetCsm); } ap->cur_rx = idx; @@ -2164,16 +2152,13 @@ static irqreturn_t ace_interrupt(int irq, void *dev_id, struct pt_regs *ptregs) { - struct ace_private *ap; - struct ace_regs *regs; struct net_device *dev = (struct net_device *)dev_id; + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; u32 idx; u32 txcsm, rxretcsm, rxretprd; u32 evtcsm, evtprd; - ap = netdev_priv(dev); - regs = ap->regs; - /* * In case of PCI shared interrupts or spurious interrupts, * we want to make sure it is actually our interrupt before @@ -2326,13 +2311,10 @@ static int ace_open(struct net_device *dev) { - struct ace_private *ap; - struct ace_regs *regs; + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; struct cmd cmd; - ap = netdev_priv(dev); - regs = ap->regs; - if (!(ap->fw_running)) { printk(KERN_WARNING "%s: Firmware not running!\n", dev->name); return -EBUSY; @@ -2384,8 +2366,8 @@ static int ace_close(struct net_device *dev) { - struct ace_private *ap; - struct ace_regs *regs; + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; struct cmd cmd; unsigned long flags; short i; @@ -2397,9 +2379,7 @@ */ netif_stop_queue(dev); - ap = netdev_priv(dev); - regs = ap->regs; - + if (ap->promisc) { cmd.evt = C_SET_PROMISC_MODE; cmd.code = C_C_PROMISC_DISABLE; @@ -2434,9 +2414,11 @@ if (mapping) { if (ACE_IS_TIGON_I(ap)) { - writel(0, &ap->tx_ring[i].addr.addrhi); - writel(0, &ap->tx_ring[i].addr.addrlo); - writel(0, &ap->tx_ring[i].flagsize); + struct tx_desc __iomem *tx + = (struct tx_desc __iomem *) &ap->tx_ring[i]; + writel(0, &tx->addr.addrhi); + writel(0, &tx->addr.addrlo); + writel(0, &tx->flagsize); } else memset(ap->tx_ring + i, 0, sizeof(struct tx_desc)); @@ -2493,11 +2475,12 @@ #endif if (ACE_IS_TIGON_I(ap)) { - writel(addr >> 32, &desc->addr.addrhi); - writel(addr & 0xffffffff, &desc->addr.addrlo); - writel(flagsize, &desc->flagsize); + struct tx_desc __iomem *io = (struct tx_desc __iomem *) desc; + writel(addr >> 32, &io->addr.addrhi); + writel(addr & 0xffffffff, &io->addr.addrlo); + writel(flagsize, &io->flagsize); #if ACENIC_DO_VLAN - writel(vlan_tag, &desc->vlanres); + writel(vlan_tag, &io->vlanres); #endif } else { desc->addr.addrhi = addr >> 32; @@ -2513,7 +2496,7 @@ static int ace_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; struct tx_desc *desc; u32 idx, flagsize; @@ -2646,7 +2629,7 @@ static int ace_change_mtu(struct net_device *dev, int new_mtu) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; if (new_mtu > ACE_JUMBO_MTU) return -EINVAL; @@ -2683,7 +2666,7 @@ static int ace_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; u32 link; memset(ecmd, 0, sizeof(struct ethtool_cmd)); @@ -2736,7 +2719,7 @@ static int ace_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; u32 link, speed; link = readl(®s->GigLnkState); @@ -2816,8 +2799,9 @@ */ static int ace_set_mac_addr(struct net_device *dev, void *p) { + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; struct sockaddr *addr=p; - struct ace_regs *regs; u8 *da; struct cmd cmd; @@ -2828,7 +2812,6 @@ da = (u8 *)dev->dev_addr; - regs = ((struct ace_private *)netdev_priv(dev))->regs; writel(da[0] << 8 | da[1], ®s->MacAddrHi); writel((da[2] << 24) | (da[3] << 16) | (da[4] << 8) | da[5], ®s->MacAddrLo); @@ -2845,7 +2828,7 @@ static void ace_set_multicast_list(struct net_device *dev) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; struct cmd cmd; if ((dev->flags & IFF_ALLMULTI) && !(ap->mcast_all)) { @@ -2899,8 +2882,8 @@ static struct net_device_stats *ace_get_stats(struct net_device *dev) { struct ace_private *ap = netdev_priv(dev); - struct ace_mac_stats *mac_stats = - (struct ace_mac_stats *)ap->regs->Stats; + struct ace_mac_stats __iomem *mac_stats = + (struct ace_mac_stats __iomem *)ap->regs->Stats; ap->stats.rx_missed_errors = readl(&mac_stats->drop_space); ap->stats.multicast = readl(&mac_stats->kept_mc); @@ -2910,10 +2893,10 @@ } -static void __init ace_copy(struct ace_regs *regs, void *src, +static void __init ace_copy(struct ace_regs __iomem *regs, void *src, u32 dest, int size) { - unsigned long tdest; + void __iomem *tdest; u32 *wsrc; short tsize, i; @@ -2923,7 +2906,7 @@ while (size > 0) { tsize = min_t(u32, ((~dest & (ACE_WINDOW_SIZE - 1)) + 1), min_t(u32, size, ACE_WINDOW_SIZE)); - tdest = (unsigned long)®s->Window + + tdest = (void __iomem *) ®s->Window + (dest & (ACE_WINDOW_SIZE - 1)); writel(dest & ~(ACE_WINDOW_SIZE - 1), ®s->WinBase); /* @@ -2943,9 +2926,9 @@ } -static void __init ace_clear(struct ace_regs *regs, u32 dest, int size) +static void __init ace_clear(struct ace_regs __iomem *regs, u32 dest, int size) { - unsigned long tdest; + void __iomem *tdest; short tsize = 0, i; if (size <= 0) @@ -2954,7 +2937,7 @@ while (size > 0) { tsize = min_t(u32, ((~dest & (ACE_WINDOW_SIZE - 1)) + 1), min_t(u32, size, ACE_WINDOW_SIZE)); - tdest = (unsigned long)®s->Window + + tdest = (void __iomem *) ®s->Window + (dest & (ACE_WINDOW_SIZE - 1)); writel(dest & ~(ACE_WINDOW_SIZE - 1), ®s->WinBase); @@ -2978,11 +2961,8 @@ */ int __init ace_load_firmware(struct net_device *dev) { - struct ace_private *ap; - struct ace_regs *regs; - - ap = netdev_priv(dev); - regs = ap->regs; + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; if (!(readl(®s->CpuCtrl) & CPU_HALTED)) { printk(KERN_ERR "%s: trying to download firmware while the " @@ -3030,7 +3010,7 @@ * Thanks to Stevarino Webinski for helping tracking down the bugs in the * code i2c readout code by beta testing all my hacks. */ -static void __init eeprom_start(struct ace_regs *regs) +static void __init eeprom_start(struct ace_regs __iomem *regs) { u32 local; @@ -3059,7 +3039,7 @@ } -static void __init eeprom_prep(struct ace_regs *regs, u8 magic) +static void __init eeprom_prep(struct ace_regs __iomem *regs, u8 magic) { short i; u32 local; @@ -3096,7 +3076,7 @@ } -static int __init eeprom_check_ack(struct ace_regs *regs) +static int __init eeprom_check_ack(struct ace_regs __iomem *regs) { int state; u32 local; @@ -3124,7 +3104,7 @@ } -static void __init eeprom_stop(struct ace_regs *regs) +static void __init eeprom_stop(struct ace_regs __iomem *regs) { u32 local; @@ -3162,8 +3142,8 @@ static int __init read_eeprom_byte(struct net_device *dev, unsigned long offset) { - struct ace_private *ap; - struct ace_regs *regs; + struct ace_private *ap = netdev_priv(dev); + struct ace_regs __iomem *regs = ap->regs; unsigned long flags; u32 local; int result = 0; @@ -3174,9 +3154,6 @@ result = -ENODEV; goto out; } - - ap = netdev_priv(dev); - regs = ap->regs; /* * Don't take interrupts on this CPU will bit banging diff -Nru a/drivers/net/acenic.h b/drivers/net/acenic.h --- a/drivers/net/acenic.h 2004-09-20 10:47:00 -07:00 +++ b/drivers/net/acenic.h 2004-09-20 10:47:00 -07:00 @@ -633,7 +633,7 @@ struct ace_private { struct ace_info *info; - struct ace_regs *regs; /* register base */ + struct ace_regs __iomem *regs; /* register base */ struct ace_skb *skb; dma_addr_t info_dma; /* 32/64 bit */ @@ -718,7 +718,7 @@ } -static inline void ace_set_txprd(struct ace_regs *regs, +static inline void ace_set_txprd(struct ace_regs __iomem *regs, struct ace_private *ap, u32 value) { #ifdef INDEX_DEBUG @@ -740,7 +740,7 @@ static inline void ace_mask_irq(struct net_device *dev) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; if (ACE_IS_TIGON_I(ap)) writel(1, ®s->MaskInt); @@ -754,7 +754,7 @@ static inline void ace_unmask_irq(struct net_device *dev) { struct ace_private *ap = netdev_priv(dev); - struct ace_regs *regs = ap->regs; + struct ace_regs __iomem *regs = ap->regs; if (ACE_IS_TIGON_I(ap)) writel(0, ®s->MaskInt); From jgarzik@pobox.com Mon Sep 20 10:56:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 10:56:10 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KHu5Gf002104 for ; Mon, 20 Sep 2004 10:56:06 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9SOG-0000pJ-Os; Mon, 20 Sep 2004 18:55:53 +0100 Message-ID: <414F199B.3090806@pobox.com> Date: Mon, 20 Sep 2004 13:55:39 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] (3/4) acenic - __iomem warnings cleanup References: <20040920104431.0a96d6c1@dell_ss3.pdx.osdl.net> In-Reply-To: <20040920104431.0a96d6c1@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9145 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 263 Lines: 11 Stephen Hemminger wrote: > Remaining warnings are because tx_ring can be either in i/o or not > depending on the version of the card. Where is this code? I don't see any {in,out}[bwl] calls? If this were true, we should use io{read,write}{8,16,32}... Jeff From jgarzik@pobox.com Mon Sep 20 11:00:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:00:09 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KI03XK002452 for ; Mon, 20 Sep 2004 11:00:03 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9SS8-0000v5-DO; Mon, 20 Sep 2004 18:59:52 +0100 Message-ID: <414F1A8C.10803@pobox.com> Date: Mon, 20 Sep 2004 13:59:40 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Andy Lutomirski , Hans-Frieder Vogt , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> <20040919213952.GA32570@electric-eye.fr.zoreil.com> <414E46F1.9050309@pobox.com> <20040920071743.GA7115@electric-eye.fr.zoreil.com> In-Reply-To: <20040920071743.GA7115@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9146 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 435 Lines: 19 Francois Romieu wrote: > Jeff Garzik : > [...] > >>That sounds like a bug right there... need all the addresses set up >>before we turn on stuff. > > > The description of the CPlusCmd in the 8169 datasheet includes a small note > which suggests that this register should be set up early. > > It does not cost much to try and see if it makes a difference for DAC though. Let me know what happens :) Jeff From jgarzik@pobox.com Mon Sep 20 11:05:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:05:41 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KI5aZA002911 for ; Mon, 20 Sep 2004 11:05:36 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9SXV-000151-Fe; Mon, 20 Sep 2004 19:05:25 +0100 Message-ID: <414F1BD9.7000407@pobox.com> Date: Mon, 20 Sep 2004 14:05:13 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) acenic - use netdev_priv References: <20040920104455.6cb37915@dell_ss3.pdx.osdl.net> In-Reply-To: <20040920104455.6cb37915@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 162 Lines: 4 regardless of comments, I applied these to netdev-2.6 so that they can get further review and testing (netdev-2.6 is automatically propagated to the -mm tree) From jgarzik@pobox.com Mon Sep 20 11:14:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:14:51 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIEiO5003548 for ; Mon, 20 Sep 2004 11:14:45 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9SgL-0001Lw-8L; Mon, 20 Sep 2004 19:14:33 +0100 Message-ID: <414F1DFD.9030008@pobox.com> Date: Mon, 20 Sep 2004 14:14:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Hans-Frieder Vogt , Andy Lutomirski , Jon Mason , Srihari Vijayaraghavan , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2 1/1] r8169: default on disabling PCIDAC References: <20040919224102.GA32577@electric-eye.fr.zoreil.com> In-Reply-To: <20040919224102.GA32577@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 409 Lines: 14 Francois Romieu wrote: > Default to disabling PCI DAC as this option appears unsafe on amd64 > (original suggestion by Hans-Frieder Vogt ). > > The driver will typically report PCI System error when something goes > wrong. The relevant interrupt is not masked any more and the driver > can thus be disabled. Can this interrupt be used at runtime to detect that DAC isn't working? Jeff From pablo@eurodev.net Mon Sep 20 11:14:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:14:09 -0700 (PDT) Received: from smtp08.retemail.es (smtp08.auna.com [62.81.186.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIE0JI003397 for ; Mon, 20 Sep 2004 11:14:01 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp08.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040920181343.XMVA1184.smtp08.retemail.es@eurodev.net>; Mon, 20 Sep 2004 20:13:43 +0200 Message-ID: <414F1E12.6010808@eurodev.net> Date: Mon, 20 Sep 2004 20:14:42 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414D0CCD.90209@eurodev.net> <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> In-Reply-To: <1095683660.1047.254.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9148 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1190 Lines: 41 Hi, jamal wrote: >On Sun, 2004-09-19 at 22:58, Herbert Xu wrote: > > >>AFAICT the problem Pablo is trying to solve is packet loss due to >>netlink congestion. >> >>There might actually be a problem with the kernel not waking up the >>the user process when we tell it to. It might even be a scheduling >>problem. But we'll need a test-case to assess that. >> >> >> > >Agreed. >For a test i typically have something adding say 10K items (actions in >my case, but could be ipsec policies) and then try to dump them. On my >xeon i get an overrun after about 6K items are dumped. > > yes, this is exactly what I've observed. Here a link to the tool that I use to stress netlink sockets. http://eurodev.net/~pablo/netlinkbench-unicast-1.0.tar.gz We've set a webpage at the university: http://perso.ens-lyon.fr/laurent.lefevre/software/netlinkbench/ but the link to download the tool is broken, it will be up soon. I've make also a version for broadcast sockets but it's basically a copy and paste of the unicast tool, I can also send you another link with it. In nlbench-unicast.c there's a macro to set/unset MSG_DONTWAIT flag to make it hit my code or not. regards, Pablo From jgarzik@pobox.com Mon Sep 20 11:17:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:17:18 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIHDKW004081 for ; Mon, 20 Sep 2004 11:17:13 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9Sik-0001QZ-By; Mon, 20 Sep 2004 19:17:02 +0100 Message-ID: <414F1E92.4020406@pobox.com> Date: Mon, 20 Sep 2004 14:16:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2-mm1 1/1] 3c59x: missing pci_disable_device References: <20040918220122.GA15528@electric-eye.fr.zoreil.com> In-Reply-To: <20040918220122.GA15528@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 95 Lines: 9 Andrew, Are you picking up this 3c59x patch, or should I stick it into netdev-2.6? Jeff From garzik@havoc.gtf.org Mon Sep 20 11:33:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:33:19 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIX9tc013020 for ; Mon, 20 Sep 2004 11:33:12 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 85BF07753; Mon, 20 Sep 2004 14:32:52 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8KIWq4k014045; Mon, 20 Sep 2004 14:32:52 -0400 Date: Mon, 20 Sep 2004 14:32:52 -0400 From: Jeff Garzik To: Andrew Morton , Linus Torvalds Cc: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6.x-rc net driver updates Message-ID: <20040920183252.GA14037@havoc.gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 9151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 14541 Lines: 460 Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.6 This will update the following files: drivers/ieee1394/eth1394.c | 2 drivers/net/Kconfig | 4 - drivers/net/r8169.c | 16 ++++- drivers/net/wireless/airo.c | 139 +++++++++++++++++++++++++------------------- 4 files changed, 97 insertions(+), 64 deletions(-) through these ChangeSets: (04/09/20 1.1928) [PATCH] Compatibility fixes for different card versions (04/09/20 1.1927) [PATCH] r8169: default on disabling PCIDAC Default to disabling PCI DAC as this option appears unsafe on amd64 (original suggestion by Hans-Frieder Vogt ). The driver will typically report PCI System error when something goes wrong. The relevant interrupt is not masked any more and the driver can thus be disabled. Signed-off-by: Francois Romieu (04/09/17 1.1926) [PATCH] fix driver name in eth1394 as returned by ETHTOOL_GDRVINFO From: Thierry Vignaud The GDRVINFO command of the ETHTOOL ioctl returns a bogus driver name. Signed-off-by: Andrew Morton (04/09/16 1.1925) [PATCH] mark mace and bmac as ppc32 only mace and bmac are only used in "oldworld" PowerMacs. Mark them as ppc32 only. diff -Nru a/drivers/ieee1394/eth1394.c b/drivers/ieee1394/eth1394.c --- a/drivers/ieee1394/eth1394.c 2004-09-20 14:31:50 -04:00 +++ b/drivers/ieee1394/eth1394.c 2004-09-20 14:31:50 -04:00 @@ -132,7 +132,7 @@ }; /* Our ieee1394 highlevel driver */ -#define ETH1394_DRIVER_NAME "ip1394" +#define ETH1394_DRIVER_NAME "eth1394" static const char driver_name[] = ETH1394_DRIVER_NAME; static kmem_cache_t *packet_task_cache; diff -Nru a/drivers/net/Kconfig b/drivers/net/Kconfig --- a/drivers/net/Kconfig 2004-09-20 14:31:50 -04:00 +++ b/drivers/net/Kconfig 2004-09-20 14:31:50 -04:00 @@ -200,7 +200,7 @@ config MACE tristate "MACE (Power Mac ethernet) support" - depends on NET_ETHERNET && PPC_PMAC + depends on NET_ETHERNET && PPC_PMAC && PPC32 select CRC32 help Power Macintoshes and clones with Ethernet built-in on the @@ -223,7 +223,7 @@ config BMAC tristate "BMAC (G3 ethernet) support" - depends on NET_ETHERNET && PPC_PMAC + depends on NET_ETHERNET && PPC_PMAC && PPC32 select CRC32 help Say Y for support of BMAC Ethernet interfaces. These are used on G3 diff -Nru a/drivers/net/r8169.c b/drivers/net/r8169.c --- a/drivers/net/r8169.c 2004-09-20 14:31:50 -04:00 +++ b/drivers/net/r8169.c 2004-09-20 14:31:50 -04:00 @@ -156,6 +156,7 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl); static int rx_copybreak = 200; +static int use_dac; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ @@ -358,6 +359,8 @@ MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); MODULE_PARM(media, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(rx_copybreak, "i"); +MODULE_PARM(use_dac, "i"); +MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot."); MODULE_LICENSE("GPL"); static int rtl8169_open(struct net_device *dev); @@ -375,7 +378,7 @@ #endif static const u16 rtl8169_intr_mask = - LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; + SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const u16 rtl8169_napi_event = RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = @@ -984,7 +987,7 @@ tp->cp_cmd = PCIMulRW | RxChkSum; if ((sizeof(dma_addr_t) > 4) && - !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) + !pci_set_dma_mask(pdev, DMA_64BIT_MASK) && use_dac) tp->cp_cmd |= PCIDAC; else { rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); @@ -1760,6 +1763,15 @@ if (!(status & rtl8169_intr_mask)) break; + + if (unlikely(status & SYSErr)) { + printk(KERN_ERR PFX "%s: PCI error (status: 0x%04x)." + " Device disabled.\n", dev->name, status); + RTL_W8(ChipCmd, 0x00); + RTL_W16(IntrMask, 0x0000); + RTL_R16(IntrMask); + break; + } if (status & LinkChg) rtl8169_check_link_status(dev, tp, ioaddr); diff -Nru a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c --- a/drivers/net/wireless/airo.c 2004-09-20 14:31:50 -04:00 +++ b/drivers/net/wireless/airo.c 2004-09-20 14:31:50 -04:00 @@ -1816,7 +1816,8 @@ if (!test_bit (FLAG_COMMIT, &ai->flags)) return SUCCESS; - clear_bit (FLAG_COMMIT | FLAG_RESET, &ai->flags); + clear_bit (FLAG_COMMIT, &ai->flags); + clear_bit (FLAG_RESET, &ai->flags); checkThrottle(ai); cfgr = ai->config; @@ -1980,9 +1981,6 @@ ai->txfids[0].tx_desc.eoc = 1; ai->txfids[0].tx_desc.len =len+sizeof(WifiHdr); - memcpy((char *)ai->txfids[0].card_ram_off, - (char *)&ai->txfids[0].tx_desc, sizeof(TxFid)); - /* * Magic, the cards firmware needs a length count (2 bytes) in the host buffer * right after TXFID_HDR.The TXFID_HDR contains the status short so payloadlen @@ -2012,6 +2010,7 @@ return ERROR; *payloadLen = cpu_to_le16(len-sizeof(etherHead)+sizeof(pMic)); + ai->txfids[0].tx_desc.len += sizeof(pMic); /* copy data into airo dma buffer */ memcpy (sendbuf, buffer, sizeof(etherHead)); buffer += sizeof(etherHead); @@ -2030,6 +2029,9 @@ memcpy(sendbuf, buffer, len); } + memcpy((char *)ai->txfids[0].card_ram_off, + (char *)&ai->txfids[0].tx_desc, sizeof(TxFid)); + OUT4500(ai, EVACK, 8); dev_kfree_skb_any(skb); @@ -2184,6 +2186,12 @@ struct airo_info *priv = dev->priv; u32 *fids = priv->fids; + if (test_bit(FLAG_MPI, &priv->flags)) { + /* Not implemented yet for MPI350 */ + netif_stop_queue(dev); + return -ENETDOWN; + } + if ( skb == NULL ) { printk( KERN_ERR "airo: skb == NULL!!!\n" ); return 0; @@ -2249,12 +2257,14 @@ { struct airo_info *local = dev->priv; - /* Get stats out of the card if available */ - if (down_trylock(&local->sem) != 0) { - set_bit(JOB_STATS, &local->flags); - wake_up_interruptible(&local->thr_wait); - } else - airo_read_stats(local); + if (!test_bit(JOB_STATS, &local->flags)) { + /* Get stats out of the card if available */ + if (down_trylock(&local->sem) != 0) { + set_bit(JOB_STATS, &local->flags); + wake_up_interruptible(&local->thr_wait); + } else + airo_read_stats(local); + } return &local->stats; } @@ -2340,6 +2350,9 @@ void stop_airo_card( struct net_device *dev, int freeres ) { struct airo_info *ai = dev->priv; + + set_bit(FLAG_RADIO_DOWN, &ai->flags); + disable_MAC(ai, 1); disable_interrupts(ai); free_irq( dev->irq, dev ); takedown_proc_entry( dev, ai ); @@ -3406,13 +3419,8 @@ } static void enable_interrupts( struct airo_info *ai ) { - /* Reset the status register */ - u16 status = IN4500( ai, EVSTAT ); - OUT4500( ai, EVACK, status ); /* Enable the interrupts */ OUT4500( ai, EVINTEN, STATUS_INTS ); - /* Note there is a race condition between the last two lines that - I don't know how to get rid of right now... */ } static void disable_interrupts( struct airo_info *ai ) { @@ -3460,7 +3468,7 @@ memcpy(buffer + ETH_ALEN * 2, ai->rxfids[0].virtual_host_addr + ETH_ALEN * 2 + off, len - ETH_ALEN * 2 - off); - if (decapsulate (ai, &micbuf, (etherHead*)buffer, len - off)) { + if (decapsulate (ai, &micbuf, (etherHead*)buffer, len - off - ETH_ALEN * 2)) { badmic: dev_kfree_skb_irq (skb); goto badrx; @@ -3670,18 +3678,6 @@ status = readCapabilityRid(ai, &cap_rid, lock); if ( status != SUCCESS ) return ERROR; - /* - * This driver supports MPI350 firmwares up to, and - * including 5.30.17 - */ - if (test_bit(FLAG_MPI, &ai->flags) && - strncmp (cap_rid.prodVer, "5.00.", 5) && - strncmp (cap_rid.prodVer, "5b00.", 5) && - strncmp (cap_rid.prodVer, "5.02.", 5) && - strncmp (cap_rid.prodVer, "5.20.", 5) && - strncmp (cap_rid.prodVer, "5.30.", 5)) - printk(KERN_ERR "airo: Firmware version %s is not supported. Use it at your own risk!\n", cap_rid.prodVer); - status = PC4500_readrid(ai,RID_RSSI,&rssi_rid,sizeof(rssi_rid),lock); if ( status == SUCCESS ) { if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL)) != NULL) @@ -3716,9 +3712,9 @@ /* Check to see if there are any insmod configured rates to add */ - if ( rates ) { + if ( rates[0] ) { int i = 0; - if ( rates[0] ) memset(ai->config.rates,0,sizeof(ai->config.rates)); + memset(ai->config.rates,0,sizeof(ai->config.rates)); for( i = 0; i < 8 && rates[i]; i++ ) { ai->config.rates[i] = rates[i]; } @@ -3785,7 +3781,6 @@ static u16 issuecommand(struct airo_info *ai, Cmd *pCmd, Resp *pRsp) { // Im really paranoid about letting it run forever! int max_tries = 600000; - u16 cmd; if (IN4500(ai, EVSTAT) & EV_CMD) OUT4500(ai, EVACK, EV_CMD); @@ -3794,26 +3789,23 @@ OUT4500(ai, PARAM1, pCmd->parm1); OUT4500(ai, PARAM2, pCmd->parm2); OUT4500(ai, COMMAND, pCmd->cmd); - while ( max_tries-- && (IN4500(ai, EVSTAT) & EV_CMD) == 0 && - (cmd = IN4500(ai, COMMAND)) != 0 ) - if (cmd == pCmd->cmd) - // PC4500 didn't notice command, try again - OUT4500(ai, COMMAND, pCmd->cmd); - if ( max_tries == -1 ) { - printk( KERN_ERR - "airo: Max tries exceeded when issueing command\n" ); - return ERROR; - } while (max_tries-- && (IN4500(ai, EVSTAT) & EV_CMD) == 0) { + if ((IN4500(ai, COMMAND)) == pCmd->cmd) + // PC4500 didn't notice command, try again + OUT4500(ai, COMMAND, pCmd->cmd); if (!in_atomic() && (max_tries & 255) == 0) schedule(); } + if ( max_tries == -1 ) { printk( KERN_ERR - "airo: Max tries exceeded waiting for command\n" ); - return ERROR; + "airo: Max tries exceeded when issueing command\n" ); + if (IN4500(ai, COMMAND) & COMMAND_BUSY) + OUT4500(ai, EVACK, EV_CLEARCOMMANDBUSY); + return ERROR; } + // command completed pRsp->status = IN4500(ai, STATUS); pRsp->rsp0 = IN4500(ai, RESP0); @@ -4509,8 +4501,6 @@ len = priv->readlen - pos; if (copy_to_user(buffer, priv->rbuffer + pos, len)) return -EFAULT; - if (pos + len > priv->writelen) - priv->writelen = pos + len; *offset = pos + len; return len; } @@ -5521,7 +5511,6 @@ mpi_init_descriptors(ai); setup_card(ai, dev->dev_addr, 0); clear_bit(FLAG_RADIO_OFF, &ai->flags); - clear_bit(FLAG_RADIO_DOWN, &ai->flags); clear_bit(FLAG_PENDING_XMIT, &ai->flags); } else { OUT4500(ai, EVACK, EV_AWAKEN); @@ -5606,6 +5595,30 @@ * would not work at all... - Jean II */ +static int airo_get_quality (StatusRid *status_rid, CapabilityRid *cap_rid) +{ + int quality = 0; + + if ((status_rid->mode & 0x3f) == 0x3f && (cap_rid->hardCap & 8)) { + if (memcmp(cap_rid->prodName, "350", 3)) + if (status_rid->signalQuality > 0x20) + quality = 0; + else + quality = 0x20 - status_rid->signalQuality; + else + if (status_rid->signalQuality > 0xb0) + quality = 0; + else if (status_rid->signalQuality < 0x10) + quality = 0xa0; + else + quality = 0xb0 - status_rid->signalQuality; + } + return quality; +} + +#define airo_get_max_quality(cap_rid) (memcmp((cap_rid)->prodName, "350", 3) ? 0x20 : 0xa0) +#define airo_get_avg_quality(cap_rid) (memcmp((cap_rid)->prodName, "350", 3) ? 0x10 : 0x50); + /*------------------------------------------------------------------*/ /* * Wireless Handler : get protocol name @@ -6293,7 +6306,8 @@ readCapabilityRid(local, &cap_rid, 1); if (vwrq->disabled) { - set_bit (FLAG_RADIO_OFF | FLAG_COMMIT, &local->flags); + set_bit (FLAG_RADIO_OFF, &local->flags); + set_bit (FLAG_COMMIT, &local->flags); return -EINPROGRESS; /* Call commit handler */ } if (vwrq->flags != IW_TXPOW_MWATT) { @@ -6432,7 +6446,7 @@ range->num_frequency = k; /* Hum... Should put the right values there */ - range->max_qual.qual = 10; + range->max_qual.qual = airo_get_max_quality(&cap_rid); range->max_qual.level = 0x100 - 120; /* -120 dBm */ range->max_qual.noise = 0; range->sensitivity = 65535; @@ -6499,7 +6513,7 @@ /* Experimental measurements - boundary 11/5.5 Mb/s */ /* Note : with or without the (local->rssi), results * are somewhat different. - Jean II */ - range->avg_qual.qual = 6; + range->avg_qual.qual = airo_get_avg_quality(&cap_rid); if (local->rssi) range->avg_qual.level = 186; /* -70 dBm */ else @@ -7113,6 +7127,7 @@ { StatusRid status_rid; StatsRid stats_rid; + CapabilityRid cap_rid; u32 *vals = stats_rid.vals; /* Get stats out of the card */ @@ -7121,6 +7136,7 @@ up(&local->sem); return; } + readCapabilityRid(local, &cap_rid, 0); readStatusRid(local, &status_rid, 0); readStatsRid(local, &stats_rid, RID_STATS, 0); up(&local->sem); @@ -7129,7 +7145,7 @@ local->wstats.status = status_rid.mode; /* Signal quality and co. But where is the noise level ??? */ - local->wstats.qual.qual = status_rid.signalQuality; + local->wstats.qual.qual = airo_get_quality(&status_rid, &cap_rid); if (local->rssi) local->wstats.qual.level = 0x100 - local->rssi[status_rid.sigQuality].rssidBm; else @@ -7156,12 +7172,14 @@ { struct airo_info *local = dev->priv; - /* Get stats out of the card if available */ - if (down_trylock(&local->sem) != 0) { - set_bit(JOB_WSTATS, &local->flags); - wake_up_interruptible(&local->thr_wait); - } else - airo_read_wireless_stats(local); + if (!test_bit(JOB_WSTATS, &local->flags)) { + /* Get stats out of the card if available */ + if (down_trylock(&local->sem) != 0) { + set_bit(JOB_WSTATS, &local->flags); + wake_up_interruptible(&local->thr_wait); + } else + airo_read_wireless_stats(local); + } return &local->wstats; } @@ -7188,9 +7206,11 @@ { case AIROGCAP: ridcode = RID_CAPABILITIES; break; case AIROGCFG: ridcode = RID_CONFIG; - disable_MAC (ai, 1); - writeConfigRid (ai, 1); - enable_MAC (ai, &rsp, 1); + if (test_bit(FLAG_COMMIT, &ai->flags)) { + disable_MAC (ai, 1); + writeConfigRid (ai, 1); + enable_MAC (ai, &rsp, 1); + } break; case AIROGSLIST: ridcode = RID_SSID; break; case AIROGVLIST: ridcode = RID_APLIST; break; @@ -7270,6 +7290,7 @@ case AIROPCAP: ridcode = RID_CAPABILITIES; break; case AIROPAPLIST: ridcode = RID_APLIST; break; case AIROPCFG: ai->config.len = 0; + clear_bit(FLAG_COMMIT, &ai->flags); ridcode = RID_CONFIG; break; case AIROPWEPKEYNV: ridcode = RID_WEP_PERM; break; case AIROPLEAPUSR: ridcode = RID_LEAPUSERNAME; break; From shemminger@osdl.org Mon Sep 20 11:33:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:33:31 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIXL34013025 for ; Mon, 20 Sep 2004 11:33:21 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8KIWwv03013; Mon, 20 Sep 2004 11:32:58 -0700 Date: Mon, 20 Sep 2004 11:32:57 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: Jes Sorensen , netdev@oss.sgi.com Subject: Re: [PATCH] (3/4) acenic - __iomem warnings cleanup Message-Id: <20040920113257.44b9bd7a@dell_ss3.pdx.osdl.net> In-Reply-To: <414F199B.3090806@pobox.com> References: <20040920104431.0a96d6c1@dell_ss3.pdx.osdl.net> <414F199B.3090806@pobox.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 47659 Lines: 602 On Mon, 20 Sep 2004 13:55:39 -0400 Jeff Garzik wrote: > Stephen Hemminger wrote: > > Remaining warnings are because tx_ring can be either in i/o or not > > depending on the version of the card. > > Where is this code? I don't see any {in,out}[bwl] calls? > > If this were true, we should use io{read,write}{8,16,32}... > > Jeff It is because of new __iomem attributes of readl/writel. Here are the warnings from the old driver (sparse and gcc) CHECK drivers/net/acenic.c drivers/net/acenic.c:542:14: warning: cast removes address space of expression drivers/net/acenic.c:640:16: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:640:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:640:16: got unsigned int [addressable] * drivers/net/acenic.c:640:44: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:640:44: expected void volatile [noderef] *addr drivers/net/acenic.c:640:44: got unsigned int [addressable] * drivers/net/acenic.c:642:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:642:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:642:17: got unsigned int [addressable] * drivers/net/acenic.c:642:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:642:46: expected void volatile [noderef] *addr drivers/net/acenic.c:642:46: got unsigned int [addressable] * drivers/net/acenic.c:647:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:647:13: expected void volatile [noderef] *addr drivers/net/acenic.c:647:13: got unsigned int [addressable] * drivers/net/acenic.c:648:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:648:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:648:9: got unsigned int [addressable] * drivers/net/acenic.c:881:12: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:881:12: expected void volatile [noderef] *addr drivers/net/acenic.c:881:12: got struct ace_regs *regs drivers/net/acenic.c:924:39: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:924:39: expected void volatile [noderef] *addr drivers/net/acenic.c:924:39: got unsigned int [addressable] * drivers/net/acenic.c:925:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:925:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:925:9: got unsigned int [addressable] * drivers/net/acenic.c:940:10: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:940:10: expected void volatile [noderef] *addr drivers/net/acenic.c:940:10: got unsigned int [addressable] * drivers/net/acenic.c:942:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:942:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:942:9: got unsigned int [addressable] * drivers/net/acenic.c:947:16: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:947:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:947:16: got unsigned int [addressable] * drivers/net/acenic.c:947:44: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:947:44: expected void volatile [noderef] *addr drivers/net/acenic.c:947:44: got unsigned int [addressable] * drivers/net/acenic.c:948:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:948:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:948:9: got unsigned int [addressable] * drivers/net/acenic.c:949:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:949:13: expected void volatile [noderef] *addr drivers/net/acenic.c:949:13: got unsigned int [addressable] * drivers/net/acenic.c:951:19: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:951:19: expected void const volatile [noderef] *addr drivers/net/acenic.c:951:19: got unsigned int [addressable] * drivers/net/acenic.c:960:14: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:960:14: expected void volatile [noderef] *addr drivers/net/acenic.c:960:14: got unsigned int [addressable] * drivers/net/acenic.c:969:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:969:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:969:17: got unsigned int [addressable] * drivers/net/acenic.c:969:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:969:46: expected void volatile [noderef] *addr drivers/net/acenic.c:969:46: got unsigned int [addressable] * drivers/net/acenic.c:970:10: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:970:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:970:10: got unsigned int [addressable] * drivers/net/acenic.c:976:27: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:976:27: expected void volatile [noderef] *addr drivers/net/acenic.c:976:27: got unsigned int [addressable] * drivers/net/acenic.c:977:29: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:977:29: expected void volatile [noderef] *addr drivers/net/acenic.c:977:29: got unsigned int [addressable] * drivers/net/acenic.c:1000:48: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1000:48: expected void volatile [noderef] *addr drivers/net/acenic.c:1000:48: got unsigned int [addressable] * drivers/net/acenic.c:1002:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1002:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:1002:9: got unsigned int [addressable] * drivers/net/acenic.c:1025:16: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1025:16: expected void volatile [noderef] *addr drivers/net/acenic.c:1025:16: got unsigned int [addressable] * drivers/net/acenic.c:1026:16: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1026:16: expected void volatile [noderef] *addr drivers/net/acenic.c:1026:16: got unsigned int [addressable] * drivers/net/acenic.c:1060:21: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1060:21: expected void const volatile [noderef] *addr drivers/net/acenic.c:1060:21: got unsigned int [addressable] * drivers/net/acenic.c:1146:15: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1146:15: expected void volatile [noderef] *addr drivers/net/acenic.c:1146:15: got unsigned int [addressable] * drivers/net/acenic.c:1222:25: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1222:25: expected void volatile [noderef] *addr drivers/net/acenic.c:1222:25: got unsigned int [addressable] * drivers/net/acenic.c:1223:32: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1223:32: expected void volatile [noderef] *addr drivers/net/acenic.c:1223:32: got unsigned int [addressable] * drivers/net/acenic.c:1233:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1233:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1233:13: got unsigned int [addressable] * drivers/net/acenic.c:1240:26: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1240:26: expected void volatile [noderef] *addr drivers/net/acenic.c:1240:26: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:1242:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1242:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1242:13: got unsigned int [addressable] * drivers/net/acenic.c:1243:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1243:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1243:13: got unsigned int [addressable] * drivers/net/acenic.c:1319:24: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1319:24: expected void volatile [noderef] *addr drivers/net/acenic.c:1319:24: got unsigned int [addressable] * drivers/net/acenic.c:1325:41: warning: incorrect type in argument 2 (different base types) drivers/net/acenic.c:1325:41: expected void volatile [noderef] *addr drivers/net/acenic.c:1325:41: got unsigned long drivers/net/acenic.c:1358:25: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1358:25: expected void volatile [noderef] *addr drivers/net/acenic.c:1358:25: got unsigned int [addressable] * drivers/net/acenic.c:1359:25: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1359:25: expected void volatile [noderef] *addr drivers/net/acenic.c:1359:25: got unsigned int [addressable] * drivers/net/acenic.c:1362:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1362:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1362:13: got unsigned int [addressable] * drivers/net/acenic.c:1363:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1363:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1363:13: got unsigned int [addressable] * drivers/net/acenic.c:1372:20: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1372:20: expected void volatile [noderef] *addr drivers/net/acenic.c:1372:20: got unsigned int [addressable] * drivers/net/acenic.c:1373:21: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1373:21: expected void volatile [noderef] *addr drivers/net/acenic.c:1373:21: got unsigned int [addressable] * drivers/net/acenic.c:1384:12: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1384:12: expected void volatile [noderef] *addr drivers/net/acenic.c:1384:12: got unsigned int [addressable] * drivers/net/acenic.c:1386:36: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1386:36: expected void volatile [noderef] *addr drivers/net/acenic.c:1386:36: got unsigned int [addressable] * drivers/net/acenic.c:1390:12: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1390:12: expected void volatile [noderef] *addr drivers/net/acenic.c:1390:12: got unsigned int [addressable] * drivers/net/acenic.c:1392:36: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1392:36: expected void volatile [noderef] *addr drivers/net/acenic.c:1392:36: got unsigned int [addressable] * drivers/net/acenic.c:1395:30: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1395:30: expected void volatile [noderef] *addr drivers/net/acenic.c:1395:30: got unsigned int [addressable] * drivers/net/acenic.c:1398:33: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1398:33: expected void volatile [noderef] *addr drivers/net/acenic.c:1398:33: got unsigned int [addressable] * drivers/net/acenic.c:1451:15: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1451:15: expected void volatile [noderef] *addr drivers/net/acenic.c:1451:15: got unsigned int [addressable] * drivers/net/acenic.c:1453:16: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1453:16: expected void volatile [noderef] *addr drivers/net/acenic.c:1453:16: got unsigned int [addressable] * drivers/net/acenic.c:1456:29: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1456:29: expected void volatile [noderef] *addr drivers/net/acenic.c:1456:29: got unsigned int [addressable] * drivers/net/acenic.c:1458:30: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1458:30: expected void volatile [noderef] *addr drivers/net/acenic.c:1458:30: got unsigned int [addressable] * drivers/net/acenic.c:1460:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1460:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1460:13: got unsigned int [addressable] * drivers/net/acenic.h:745:17: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.h:745:17: expected void volatile [noderef] *addr drivers/net/acenic.h:745:17: got unsigned int [addressable] * drivers/net/acenic.c:1473:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1473:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1473:13: got unsigned int [addressable] * drivers/net/acenic.c:1486:19: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1486:19: expected void volatile [noderef] *addr drivers/net/acenic.c:1486:19: got unsigned int [addressable] * drivers/net/acenic.c:1491:16: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1491:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:1491:16: got unsigned int [addressable] * drivers/net/acenic.c:1491:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1491:57: expected void volatile [noderef] *addr drivers/net/acenic.c:1491:57: got unsigned int [addressable] * drivers/net/acenic.c:1492:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1492:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:1492:9: got unsigned int [addressable] * drivers/net/acenic.c:1505:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1505:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:1505:17: got unsigned int [addressable] * drivers/net/acenic.c:1505:45: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1505:45: expected void volatile [noderef] *addr drivers/net/acenic.c:1505:45: got unsigned int [addressable] * drivers/net/acenic.c:1506:10: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1506:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:1506:10: got unsigned int [addressable] * drivers/net/acenic.c:1518:18: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1518:18: expected void const volatile [noderef] *addr drivers/net/acenic.c:1518:18: got unsigned int [addressable] * drivers/net/acenic.c:1519:12: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1519:12: expected void volatile [noderef] *addr drivers/net/acenic.c:1519:12: got unsigned int [addressable] * drivers/net/acenic.c:1520:14: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1520:14: expected void volatile [noderef] *addr drivers/net/acenic.c:1520:14: got unsigned int [addressable] * drivers/net/acenic.c:1521:10: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1521:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:1521:10: got unsigned int [addressable] * drivers/net/acenic.c:1565:26: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1565:26: expected void volatile [noderef] *addr drivers/net/acenic.c:1565:26: got unsigned int [addressable] * drivers/net/acenic.c:1567:30: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1567:30: expected void volatile [noderef] *addr drivers/net/acenic.c:1567:30: got unsigned int [addressable] * drivers/net/acenic.c:1569:26: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1569:26: expected void volatile [noderef] *addr drivers/net/acenic.c:1569:26: got unsigned int [addressable] * drivers/net/acenic.c:1571:30: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1571:30: expected void volatile [noderef] *addr drivers/net/acenic.c:1571:30: got unsigned int [addressable] * drivers/net/acenic.c:1573:27: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1573:27: expected void volatile [noderef] *addr drivers/net/acenic.c:1573:27: got unsigned int [addressable] * drivers/net/acenic.c:1577:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1577:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1577:13: got unsigned int [addressable] * drivers/net/acenic.c:1580:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1580:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1580:13: got unsigned int [addressable] * drivers/net/acenic.c:1583:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1583:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1583:13: got unsigned int [addressable] * drivers/net/acenic.c:1586:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1586:13: expected void volatile [noderef] *addr drivers/net/acenic.c:1586:13: got unsigned int [addressable] * drivers/net/acenic.c:1588:33: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1588:33: expected void volatile [noderef] *addr drivers/net/acenic.c:1588:33: got unsigned int [addressable] * drivers/net/acenic.c:1607:42: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1607:42: expected void const volatile [noderef] *addr drivers/net/acenic.c:1607:42: got unsigned int [addressable] * drivers/net/acenic.c:892:15: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:1726:16: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1726:16: expected void volatile [noderef] *addr drivers/net/acenic.c:1726:16: got unsigned int [addressable] * drivers/net/acenic.c:1783:15: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1783:15: expected void volatile [noderef] *addr drivers/net/acenic.c:1783:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:1847:16: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1847:16: expected void volatile [noderef] *addr drivers/net/acenic.c:1847:16: got unsigned int [addressable] * drivers/net/acenic.c:1889:26: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:1889:26: expected void const volatile [noderef] *addr drivers/net/acenic.c:1889:26: got unsigned int [addressable] * drivers/net/acenic.c:892:15: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:1950:21: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:1950:21: expected void volatile [noderef] *addr drivers/net/acenic.c:1950:21: got unsigned int [addressable] * drivers/net/acenic.c:2087:16: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:2087:16: expected void volatile [noderef] *addr drivers/net/acenic.c:2087:16: got unsigned int [addressable] * drivers/net/acenic.c:2182:15: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:2182:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:2182:15: got unsigned int [addressable] * drivers/net/acenic.c:2193:13: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:2193:13: expected void volatile [noderef] *addr drivers/net/acenic.c:2193:13: got unsigned int [addressable] * drivers/net/acenic.c:2194:9: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:2194:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:2194:9: got unsigned int [addressable] * drivers/net/acenic.c:2224:18: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:2224:18: expected void const volatile [noderef] *addr drivers/net/acenic.c:2224:18: got unsigned int [addressable] * drivers/net/acenic.c:2229:19: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:2229:19: expected void volatile [noderef] *addr drivers/net/acenic.c:2229:19: got unsigned int [addressable] * drivers/net/acenic.c:2341:35: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:2341:35: expected void volatile [noderef] *addr drivers/net/acenic.c:2341:35: got unsigned int [addressable] * drivers/net/acenic.c:892:15: warning: incorrect type in argument 1 (different address spaces) drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: warning: too many warnings drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.h:757:14: expected void volatile [noderef] *addr drivers/net/acenic.h:757:14: got unsigned int [addressable] * drivers/net/acenic.h:759:17: expected void const volatile [noderef] *addr drivers/net/acenic.h:759:17: got unsigned int [addressable] * drivers/net/acenic.h:759:47: expected void volatile [noderef] *addr drivers/net/acenic.h:759:47: got unsigned int [addressable] * drivers/net/acenic.c:2437:27: expected void volatile [noderef] *addr drivers/net/acenic.c:2437:27: got unsigned int [addressable] * drivers/net/acenic.c:2438:27: expected void volatile [noderef] *addr drivers/net/acenic.c:2438:27: got unsigned int [addressable] * drivers/net/acenic.c:2439:27: expected void volatile [noderef] *addr drivers/net/acenic.c:2439:27: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.h:771:14: expected void volatile [noderef] *addr drivers/net/acenic.h:771:14: got unsigned int [addressable] * drivers/net/acenic.h:773:17: expected void const volatile [noderef] *addr drivers/net/acenic.h:773:17: got unsigned int [addressable] * drivers/net/acenic.h:773:48: expected void volatile [noderef] *addr drivers/net/acenic.h:773:48: got unsigned int [addressable] * drivers/net/acenic.c:2496:23: expected void volatile [noderef] *addr drivers/net/acenic.c:2496:23: got unsigned int [addressable] * drivers/net/acenic.c:2497:30: expected void volatile [noderef] *addr drivers/net/acenic.c:2497:30: got unsigned int [addressable] * drivers/net/acenic.c:2498:21: expected void volatile [noderef] *addr drivers/net/acenic.c:2498:21: got unsigned int [addressable] * drivers/net/acenic.c:2496:23: expected void volatile [noderef] *addr drivers/net/acenic.c:2496:23: got unsigned int [addressable] * drivers/net/acenic.c:2497:30: expected void volatile [noderef] *addr drivers/net/acenic.c:2497:30: got unsigned int [addressable] * drivers/net/acenic.c:2498:21: expected void volatile [noderef] *addr drivers/net/acenic.c:2498:21: got unsigned int [addressable] * drivers/net/acenic.c:2496:23: expected void volatile [noderef] *addr drivers/net/acenic.c:2496:23: got unsigned int [addressable] * drivers/net/acenic.c:2497:30: expected void volatile [noderef] *addr drivers/net/acenic.c:2497:30: got unsigned int [addressable] * drivers/net/acenic.c:2498:21: expected void volatile [noderef] *addr drivers/net/acenic.c:2498:21: got unsigned int [addressable] * drivers/net/acenic.h:745:17: expected void volatile [noderef] *addr drivers/net/acenic.h:745:17: got unsigned int [addressable] * drivers/net/acenic.c:2660:34: expected void volatile [noderef] *addr drivers/net/acenic.c:2660:34: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:2705:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:2705:16: got unsigned int [addressable] * drivers/net/acenic.c:2709:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:2709:17: got unsigned int [addressable] * drivers/net/acenic.c:2736:26: expected void const volatile [noderef] *addr drivers/net/acenic.c:2736:26: got unsigned int [addressable] * drivers/net/acenic.c:2737:26: expected void const volatile [noderef] *addr drivers/net/acenic.c:2737:26: got unsigned int [addressable] * drivers/net/acenic.c:2748:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:2748:16: got unsigned int [addressable] * drivers/net/acenic.c:2752:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:2752:17: got unsigned int [addressable] * drivers/net/acenic.c:2791:17: expected void volatile [noderef] *addr drivers/net/acenic.c:2791:17: got unsigned int [addressable] * drivers/net/acenic.c:2793:18: expected void volatile [noderef] *addr drivers/net/acenic.c:2793:18: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:2838:30: expected void volatile [noderef] *addr drivers/net/acenic.c:2838:30: got unsigned int [addressable] * drivers/net/acenic.c:2840:10: expected void volatile [noderef] *addr drivers/net/acenic.c:2840:10: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:892:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:892:15: got unsigned int [addressable] * drivers/net/acenic.c:894:37: expected void volatile [noderef] *addr drivers/net/acenic.c:894:37: got unsigned int [addressable] [usertype] * drivers/net/acenic.c:897:15: expected void volatile [noderef] *addr drivers/net/acenic.c:897:15: got unsigned int [addressable] * drivers/net/acenic.c:2911:38: expected void const volatile [noderef] *addr drivers/net/acenic.c:2911:38: got unsigned int [addressable] * drivers/net/acenic.c:2912:31: expected void const volatile [noderef] *addr drivers/net/acenic.c:2912:31: got unsigned int [addressable] * drivers/net/acenic.c:2913:32: expected void const volatile [noderef] *addr drivers/net/acenic.c:2913:32: got unsigned int [addressable] * drivers/net/acenic.c:2934:42: expected void volatile [noderef] *addr drivers/net/acenic.c:2934:42: got unsigned int [addressable] * drivers/net/acenic.c:2941:26: expected void volatile [noderef] *addr drivers/net/acenic.c:2941:26: got unsigned long drivers/net/acenic.c:2965:42: expected void volatile [noderef] *addr drivers/net/acenic.c:2965:42: got unsigned int [addressable] * drivers/net/acenic.c:2968:20: expected void volatile [noderef] *addr drivers/net/acenic.c:2968:20: got unsigned long drivers/net/acenic.c:2993:15: expected void const volatile [noderef] *addr drivers/net/acenic.c:2993:15: got unsigned int [addressable] * drivers/net/acenic.c:3043:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3043:9: got unsigned int [addressable] * drivers/net/acenic.c:3045:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:3045:17: got unsigned int [addressable] * drivers/net/acenic.c:3047:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3047:17: got unsigned int [addressable] * drivers/net/acenic.c:3048:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3048:9: got unsigned int [addressable] * drivers/net/acenic.c:3052:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3052:17: got unsigned int [addressable] * drivers/net/acenic.c:3053:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3053:9: got unsigned int [addressable] * drivers/net/acenic.c:3057:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3057:17: got unsigned int [addressable] * drivers/net/acenic.c:3058:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3058:9: got unsigned int [addressable] * drivers/net/acenic.c:3062:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3062:17: got unsigned int [addressable] * drivers/net/acenic.c:3063:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3063:9: got unsigned int [addressable] * drivers/net/acenic.c:3074:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:3074:17: got unsigned int [addressable] * drivers/net/acenic.c:3077:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3077:17: got unsigned int [addressable] * drivers/net/acenic.c:3078:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3078:9: got unsigned int [addressable] * drivers/net/acenic.c:3087:18: expected void volatile [noderef] *addr drivers/net/acenic.c:3087:18: got unsigned int [addressable] * drivers/net/acenic.c:3088:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:3088:10: got unsigned int [addressable] * drivers/net/acenic.c:3093:18: expected void volatile [noderef] *addr drivers/net/acenic.c:3093:18: got unsigned int [addressable] * drivers/net/acenic.c:3094:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:3094:10: got unsigned int [addressable] * drivers/net/acenic.c:3098:18: expected void volatile [noderef] *addr drivers/net/acenic.c:3098:18: got unsigned int [addressable] * drivers/net/acenic.c:3099:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:3099:10: got unsigned int [addressable] * drivers/net/acenic.c:3110:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:3110:17: got unsigned int [addressable] * drivers/net/acenic.c:3112:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3112:17: got unsigned int [addressable] * drivers/net/acenic.c:3113:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3113:9: got unsigned int [addressable] * drivers/net/acenic.c:3117:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3117:17: got unsigned int [addressable] * drivers/net/acenic.c:3118:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3118:9: got unsigned int [addressable] * drivers/net/acenic.c:3122:18: expected void const volatile [noderef] *addr drivers/net/acenic.c:3122:18: got unsigned int [addressable] * drivers/net/acenic.c:3125:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:3125:16: got unsigned int [addressable] * drivers/net/acenic.c:3125:53: expected void volatile [noderef] *addr drivers/net/acenic.c:3125:53: got unsigned int [addressable] * drivers/net/acenic.c:3126:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3126:9: got unsigned int [addressable] * drivers/net/acenic.c:3138:17: expected void const volatile [noderef] *addr drivers/net/acenic.c:3138:17: got unsigned int [addressable] * drivers/net/acenic.c:3140:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3140:17: got unsigned int [addressable] * drivers/net/acenic.c:3141:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3141:9: got unsigned int [addressable] * drivers/net/acenic.c:3145:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3145:17: got unsigned int [addressable] * drivers/net/acenic.c:3146:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3146:9: got unsigned int [addressable] * drivers/net/acenic.c:3150:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3150:17: got unsigned int [addressable] * drivers/net/acenic.c:3151:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3151:9: got unsigned int [addressable] * drivers/net/acenic.c:3155:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3155:17: got unsigned int [addressable] * drivers/net/acenic.c:3156:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3156:9: got unsigned int [addressable] * drivers/net/acenic.c:3160:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3160:17: got unsigned int [addressable] * drivers/net/acenic.c:3232:18: expected void const volatile [noderef] *addr drivers/net/acenic.c:3232:18: got unsigned int [addressable] * drivers/net/acenic.c:3234:18: expected void volatile [noderef] *addr drivers/net/acenic.c:3234:18: got unsigned int [addressable] * drivers/net/acenic.c:3235:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:3235:10: got unsigned int [addressable] * drivers/net/acenic.c:3239:18: expected void volatile [noderef] *addr drivers/net/acenic.c:3239:18: got unsigned int [addressable] * drivers/net/acenic.c:3240:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:3240:10: got unsigned int [addressable] * drivers/net/acenic.c:3245:13: expected void const volatile [noderef] *addr drivers/net/acenic.c:3245:13: got unsigned int [addressable] * drivers/net/acenic.c:3248:18: expected void const volatile [noderef] *addr drivers/net/acenic.c:3248:18: got unsigned int [addressable] * drivers/net/acenic.c:3250:18: expected void volatile [noderef] *addr drivers/net/acenic.c:3250:18: got unsigned int [addressable] * drivers/net/acenic.c:3251:10: expected void const volatile [noderef] *addr drivers/net/acenic.c:3251:10: got unsigned int [addressable] * drivers/net/acenic.c:3256:19: expected void volatile [noderef] *addr drivers/net/acenic.c:3256:19: got unsigned int [addressable] * drivers/net/acenic.c:3257:11: expected void const volatile [noderef] *addr drivers/net/acenic.c:3257:11: got unsigned int [addressable] * drivers/net/acenic.c:3264:17: expected void volatile [noderef] *addr drivers/net/acenic.c:3264:17: got unsigned int [addressable] * drivers/net/acenic.c:3265:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3265:9: got unsigned int [addressable] * drivers/net/acenic.c:3268:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:3268:16: got unsigned int [addressable] * drivers/net/acenic.c:3268:52: expected void volatile [noderef] *addr drivers/net/acenic.c:3268:52: got unsigned int [addressable] * drivers/net/acenic.c:3269:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3269:9: got unsigned int [addressable] * drivers/net/acenic.c:3271:16: expected void const volatile [noderef] *addr drivers/net/acenic.c:3271:16: got unsigned int [addressable] * drivers/net/acenic.c:3271:53: expected void volatile [noderef] *addr drivers/net/acenic.c:3271:53: got unsigned int [addressable] * drivers/net/acenic.c:3272:9: expected void const volatile [noderef] *addr drivers/net/acenic.c:3272:9: got unsigned int [addressable] * CC [M] drivers/net/acenic.o drivers/net/acenic.c: In function `ace_init': drivers/net/acenic.c:1325: warning: passing arg 2 of `writel' makes pointer from integer without a cast drivers/net/acenic.c: In function `ace_copy': drivers/net/acenic.c:2941: warning: passing arg 2 of `writel' makes pointer from integer without a cast drivers/net/acenic.c: In function `ace_clear': drivers/net/acenic.c:2968: warning: passing arg 2 of `writel' makes pointer from integer without a cast From akpm@osdl.org Mon Sep 20 11:38:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:38:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIcIBb013717 for ; Mon, 20 Sep 2004 11:38:18 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8KIbxv04177; Mon, 20 Sep 2004 11:37:59 -0700 Date: Mon, 20 Sep 2004 11:35:58 -0700 From: Andrew Morton To: Jeff Garzik Cc: romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2-mm1 1/1] 3c59x: missing pci_disable_device Message-Id: <20040920113558.7b5144ad.akpm@osdl.org> In-Reply-To: <414F1E92.4020406@pobox.com> References: <20040918220122.GA15528@electric-eye.fr.zoreil.com> <414F1E92.4020406@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 150 Lines: 9 Jeff Garzik wrote: > > Are you picking up this 3c59x patch, I did so. > or should I stick it into netdev-2.6? That works, too. From jgarzik@pobox.com Mon Sep 20 11:39:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:39:47 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIdgLK014040 for ; Mon, 20 Sep 2004 11:39:42 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9T4V-0001zL-4O; Mon, 20 Sep 2004 19:39:31 +0100 Message-ID: <414F23D4.5040208@pobox.com> Date: Mon, 20 Sep 2004 14:39:16 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: romieu@fr.zoreil.com, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2-mm1 1/1] 3c59x: missing pci_disable_device References: <20040918220122.GA15528@electric-eye.fr.zoreil.com> <414F1E92.4020406@pobox.com> <20040920113558.7b5144ad.akpm@osdl.org> In-Reply-To: <20040920113558.7b5144ad.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 229 Lines: 15 Andrew Morton wrote: > Jeff Garzik wrote: > >>Are you picking up this 3c59x patch, > > > I did so. Since I am always eager to hand off 3c59x patches, I'll leave it out of netdev-2.6 then... :) Jeff From jgarzik@pobox.com Mon Sep 20 11:42:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:42:08 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIg4Fd014362 for ; Mon, 20 Sep 2004 11:42:04 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9T6n-00023L-9d; Mon, 20 Sep 2004 19:41:53 +0100 Message-ID: <414F2465.2010005@pobox.com> Date: Mon, 20 Sep 2004 14:41:41 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniele Venzano CC: netdev@oss.sgi.com Subject: Re: [PATCH] whitespace and CodingStyle fixes for sis900 References: <20040829103902.GE5168@gateway.milesteg.arr> In-Reply-To: <20040829103902.GE5168@gateway.milesteg.arr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 23 Lines: 2 applied to netdev-2.6 From davem@davemloft.net Mon Sep 20 11:45:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:45:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIjrwD014750 for ; Mon, 20 Sep 2004 11:45:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9TA8-0001TO-00; Mon, 20 Sep 2004 11:45:20 -0700 Date: Mon, 20 Sep 2004 11:45:20 -0700 From: "David S. Miller" To: Jeff Garzik Cc: shemminger@osdl.org, jes@wildopensource.com, netdev@oss.sgi.com Subject: Re: [PATCH] (3/4) acenic - __iomem warnings cleanup Message-Id: <20040920114520.5bca1e56.davem@davemloft.net> In-Reply-To: <414F199B.3090806@pobox.com> References: <20040920104431.0a96d6c1@dell_ss3.pdx.osdl.net> <414F199B.3090806@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1117 Lines: 41 On Mon, 20 Sep 2004 13:55:39 -0400 Jeff Garzik wrote: > Stephen Hemminger wrote: > > Remaining warnings are because tx_ring can be either in i/o or not > > depending on the version of the card. > > Where is this code? I don't see any {in,out}[bwl] calls? > > If this were true, we should use io{read,write}{8,16,32}... The driver uses a single pointer that either goes to DMA descriptors or I/O memory space. See the assignment and usage of ap->tx_ring if (!ACE_IS_TIGON_I(ap)) { size = (sizeof(struct tx_desc) * MAX_TX_RING_ENTRIES); ap->tx_ring = pci_alloc_consistent(ap->pdev, size, &ap->tx_ring_dma); if (ap->tx_ring == NULL) goto fail; } ... if (ACE_IS_TIGON_I(ap)) { ap->tx_ring = (struct tx_desc *)regs->Window; for (i = 0; i < (TIGON_I_TX_RING_ENTRIES * sizeof(struct tx_desc) / 4); i++) { writel(0, (unsigned long)ap->tx_ring + i * 4); } set_aceaddr(&info->tx_ctrl.rngptr, TX_RING_BASE); } else { memset(ap->tx_ring, 0, MAX_TX_RING_ENTRIES * sizeof(struct tx_desc)); set_aceaddr(&info->tx_ctrl.rngptr, ap->tx_ring_dma); } From davem@davemloft.net Mon Sep 20 11:47:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:47:23 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIlICG015073 for ; Mon, 20 Sep 2004 11:47:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9TBD-0001Tm-00; Mon, 20 Sep 2004 11:46:27 -0700 Date: Mon, 20 Sep 2004 11:46:27 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jes@wildopensource.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] (4/4) acenic - don't spin forever in hard_start_xmit Message-Id: <20040920114627.4968a4fa.davem@davemloft.net> In-Reply-To: <20040920104724.2a5d2b47@dell_ss3.pdx.osdl.net> References: <20040920104724.2a5d2b47@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9157 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 302 Lines: 9 On Mon, 20 Sep 2004 10:47:24 -0700 Stephen Hemminger wrote: > + /* The ring is stuck full. */ > + printk(KERN_WARNING "%s: Transmit ring stuck full\n", dev->name); > + return NETDEV_TX_BUSY; OK, but only because it's a long timeout and the kernel log gets a reasonable message. From jgarzik@pobox.com Mon Sep 20 11:48:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:48:25 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KImKo2015406 for ; Mon, 20 Sep 2004 11:48:20 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9TCr-0002Dj-4X; Mon, 20 Sep 2004 19:48:09 +0100 Message-ID: <414F25DD.4070406@pobox.com> Date: Mon, 20 Sep 2004 14:47:57 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] eepro100 - module_param and cleanup References: <20040806152532.25cdebeb@dell_ss3.pdx.osdl.net> In-Reply-To: <20040806152532.25cdebeb@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 rediff? From jgarzik@pobox.com Mon Sep 20 11:57:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:57:38 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIvX39015929 for ; Mon, 20 Sep 2004 11:57:33 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9TLl-0002Pj-RT; Mon, 20 Sep 2004 19:57:21 +0100 Message-ID: <414F2806.2070709@pobox.com> Date: Mon, 20 Sep 2004 14:57:10 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ganesh.venkatesan@intel.com CC: netdev@oss.sgi.com Subject: Re: [PATCH 1/1 2.4] e100 - upgrade 2.4 tree to include 3.0.x version of e100 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 56 Lines: 2 would you please resend this against the latest 2.4.x? From davem@davemloft.net Mon Sep 20 11:58:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 11:58:23 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KIwHGD016263 for ; Mon, 20 Sep 2004 11:58:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9TMA-0001VO-00; Mon, 20 Sep 2004 11:57:46 -0700 Date: Mon, 20 Sep 2004 11:57:46 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] natsemi.c NAPI Message-Id: <20040920115746.7ccbfb45.davem@davemloft.net> In-Reply-To: <20040920141030.GV1307@sunbeam.de.gnumonks.org> References: <20040920141030.GV1307@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9160 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 848 Lines: 30 On Mon, 20 Sep 2004 16:10:30 +0200 Harald Welte wrote: > +static inline void natsemi_irq_enable(struct netdev_private *np) > +{ > + /* Enable interrupts by setting the interrupt mask. */ > + writel(DEFAULT_INTR, np->base_addr + IntrMask); > + writel(1, np->base_addr + IntrEnable); > + mb(); > +} > + > +static inline void natsemi_irq_disable(struct netdev_private *np) > +{ > + writel(0, np->base_addr + IntrEnable); > + mb(); > +} Kill the mb(), try using: readl(np->base_addr + IntrEnable); in it's place. This driver (before the NAPI patch) is a bit buggy, it does no RX processing SMP locking. So if one one cpu you're doing RX interrupt processing, and on another cpu tx_timeout() runs we're totally screwed. This is not caused by Harald's patch, but there are implications for his NAPI patch once it is fixed. From romieu@fr.zoreil.com Mon Sep 20 12:03:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:04:00 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJ3r0L016765 for ; Mon, 20 Sep 2004 12:03:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8KJ2rvr016765; Mon, 20 Sep 2004 21:02:53 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8KJ2q34016764; Mon, 20 Sep 2004 21:02:52 +0200 Date: Mon, 20 Sep 2004 21:02:52 +0200 From: Francois Romieu To: Jeff Garzik Cc: Hans-Frieder Vogt , Andy Lutomirski , Jon Mason , Srihari Vijayaraghavan , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2 1/1] r8169: default on disabling PCIDAC Message-ID: <20040920190252.GA16429@electric-eye.fr.zoreil.com> References: <20040919224102.GA32577@electric-eye.fr.zoreil.com> <414F1DFD.9030008@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F1DFD.9030008@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9161 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 208 Lines: 10 Jeff Garzik : [...] > Can this interrupt be used at runtime to detect that DAC isn't working? Experiment suggests that. Errr... Do you really want to hot-reinit the device ? -- Ueimor From jgarzik@pobox.com Mon Sep 20 12:04:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:04:23 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJ4HJ5016858 for ; Mon, 20 Sep 2004 12:04:17 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9TSF-0002bZ-J2; Mon, 20 Sep 2004 20:04:03 +0100 Message-ID: <414F2997.9030901@pobox.com> Date: Mon, 20 Sep 2004 15:03:51 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: netdev@oss.sgi.com Subject: Re: Resend: [NETDRV] Merge register_netdev calls References: <20040701111914.GA11120@gondor.apana.org.au> In-Reply-To: <20040701111914.GA11120@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9162 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1138 Lines: 42 Herbert Xu wrote: > On Fri, Jun 11, 2004 at 12:08:55PM +1000, herbert wrote: > >>In fact it's really making these ISA/MCA probe() functions more >>like the ones we have for PCI. > > > To illustrate this, let's take the first driver touched by 4/x. > In 3c503, the function init_module() essentially does > > for each ioaddr > if (do_el2_probe(ioaddr) == 0) > return 0 > > And do_el2_probe() just calls el2_probe1() which is similar > to your average PCI probe function except that the first thing > it does is to make sure that the device exists at ioaddr. > > This is not that different from PCI where it would look > like > > for each PCI device matching the vendor/product numbers > if (do_el2_probe(device) == 0) > return 0 > > Now before my patch, register_netdev was being called just > after do_el2_probe() returns. My patch simply moves it to > the end of el2_probe1() which is exactly what would happen > if this were a PCI driver. > > I've rediffed it against your net-drivers-2.6 tree. so, there was a lot of churn and I held off on this patch. could you be convinced to rediff and resend (again)? Jeff From garzik@havoc.gtf.org Mon Sep 20 12:08:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:08:10 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJ83AH017471 for ; Mon, 20 Sep 2004 12:08:04 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id 67E7577EF; Mon, 20 Sep 2004 15:07:47 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8KJ7ke0017344; Mon, 20 Sep 2004 15:07:46 -0400 Date: Mon, 20 Sep 2004 15:07:46 -0400 From: Jeff Garzik To: "David S. Miller" Cc: Harald Welte , netdev@oss.sgi.com Subject: Re: [PATCH 2.6] natsemi.c NAPI Message-ID: <20040920190746.GA17210@havoc.gtf.org> References: <20040920141030.GV1307@sunbeam.de.gnumonks.org> <20040920115746.7ccbfb45.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920115746.7ccbfb45.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 9163 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 445 Lines: 14 On Mon, Sep 20, 2004 at 11:57:46AM -0700, David S. Miller wrote: > This driver (before the NAPI patch) is a bit buggy, it does > no RX processing SMP locking. So if one one cpu you're doing > RX interrupt processing, and on another cpu tx_timeout() runs > we're totally screwed. RX processing in current natsemi only happens in irq, and the natsemi driver properly disables irqs when it needs to, AFAICS, using enable/disable_irq(). Jeff From davem@davemloft.net Mon Sep 20 12:11:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:12:02 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJBsu4017975 for ; Mon, 20 Sep 2004 12:11:55 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9TZL-0001Xv-00; Mon, 20 Sep 2004 12:11:23 -0700 Date: Mon, 20 Sep 2004 12:11:23 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040920121123.70baf895.davem@davemloft.net> In-Reply-To: <1095686672.1049.301.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9165 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 3323 Lines: 90 On 20 Sep 2004 09:24:32 -0400 jamal wrote: > On Sun, 2004-09-19 at 22:53, David S. Miller wrote: > > > > There are two problems. Well, logically one, which is the seperation > > out of fib_node from the code. > > > > I need to expose the layout of fib_node for other reasons. > > > > If you look at Ben LaHaise's case, the issue becomes evident. > > IIRC, he was having issues when 1000 devices all came up at once and all > tried to add local scope routes? Furthermore, once you have 1000 devices the algorithms in net/ipv4/fib_semantics.c fall apart. The code in fib_semantics.c was written assuming that next hop information composed of a small set of unique entries. So even if your routing tables were huge, those routing entries pointed to a small group of unique next-hop objects (which is what fib_info represents). So all of that code was using a singly linked list of all fib_info's to do lookups. Therefore once you have a couple thousand entries, even the simplest event processing becomes expensive. > > Firstly, fib_semantics was not designed to scale at all, > > thus last weeks patches to add the hash tables. > > Will have to look at those patches - already in? Yes, current 2.6.x tree has the new fib_semantics.c code. > I like the idea except for when enforcing that scheme to be used > by other algorithms[1]. It is the core issue. I read from this statement that it is envisioned that some fib_node lookup algorithm could, in a different way, find all fib_nodes corresponding to a given fib_info. I ask you to provide what that mechanism might be before I am willing to be concerned about this possibility :-) > > So the general idea I was after was: > > > > 1) All things performing pure longest-matching prefix > > lookup on an ipv4 address is confined to fib_node objects > > and the actual lookup algorithm. > > > > 2) Everything that occurs once we have a matching fib_node > > object, is consolidated into a common pieces of code > > that does all the TOS, priority, et al. magic > > sigh. Ok, some of the stuff in fib_node like TOS lookups are > necessary for _total_ RFC1812 compliance. So i see where you are coming > from although i am not a big fan of it. I will chew on it in the > background. Jamal and others, while I have your brains active in this area I have a question. I tried very hard to preserve existing behavior wrt. TOS handling wrt. the setting of CONFIG_IP_ROUTE_TOS. Basically, the r->rtm_tos is ignored when adding routes, and treated as zero. I believe I was successful in preserving existing behavior, but I wonder if it makes sense any longer. CONFIG_IP_ROUTE_TOS changes not one data structure. It does exactly: 1) Controls the presence of a TOS comparison in fib_rules.c:fib_lookup() 2) Controls, in fib_hash.c: a) TOS comparison in fn_hash_lookup() b) whether TOS is paid attention to in fn_hash_insert c) similarly in fn_hash_delete() In the TOS comparison changes, the TOS test treats zero TOS values as "any TOS". Therefore unless the user explicitly tried to add a non-zero TOS route, TOS makes no difference in behavior both with and without CONFIG_IP_ROUTE_TOS set. Therefore, I think it behooves us just kill off this config value. It saves a mere 6 or 7 lines of code and no data space. From jgarzik@pobox.com Mon Sep 20 12:11:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:11:41 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJBZOR017907 for ; Mon, 20 Sep 2004 12:11:36 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9TZM-0002mK-5e; Mon, 20 Sep 2004 20:11:24 +0100 Message-ID: <414F2B4F.3080606@pobox.com> Date: Mon, 20 Sep 2004 15:11:11 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Hans-Frieder Vogt , Andy Lutomirski , Jon Mason , Srihari Vijayaraghavan , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2 1/1] r8169: default on disabling PCIDAC References: <20040919224102.GA32577@electric-eye.fr.zoreil.com> <414F1DFD.9030008@pobox.com> <20040920190252.GA16429@electric-eye.fr.zoreil.com> In-Reply-To: <20040920190252.GA16429@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9164 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 390 Lines: 19 Francois Romieu wrote: > Jeff Garzik : > [...] > >>Can this interrupt be used at runtime to detect that DAC isn't working? > > > Experiment suggests that. > > Errr... Do you really want to hot-reinit the device ? It's only a one-time operation that occurs on weird 64-bit boxes :) I applied the using_dac stuff, but do think there is _some_ better way. Jeff From davem@davemloft.net Mon Sep 20 12:13:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:13:14 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJDAPb018555 for ; Mon, 20 Sep 2004 12:13:10 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9Taa-0001YA-00; Mon, 20 Sep 2004 12:12:40 -0700 Date: Mon, 20 Sep 2004 12:12:39 -0700 From: "David S. Miller" To: Jeff Garzik Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] natsemi.c NAPI Message-Id: <20040920121239.2a615c58.davem@davemloft.net> In-Reply-To: <20040920190746.GA17210@havoc.gtf.org> References: <20040920141030.GV1307@sunbeam.de.gnumonks.org> <20040920115746.7ccbfb45.davem@davemloft.net> <20040920190746.GA17210@havoc.gtf.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9166 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 549 Lines: 14 On Mon, 20 Sep 2004 15:07:46 -0400 Jeff Garzik wrote: > On Mon, Sep 20, 2004 at 11:57:46AM -0700, David S. Miller wrote: > > This driver (before the NAPI patch) is a bit buggy, it does > > no RX processing SMP locking. So if one one cpu you're doing > > RX interrupt processing, and on another cpu tx_timeout() runs > > we're totally screwed. > > RX processing in current natsemi only happens in irq, and the natsemi > driver properly disables irqs when it needs to, AFAICS, using > enable/disable_irq(). Aha, ok that works. From Robert.Olsson@data.slu.se Mon Sep 20 12:44:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:44:58 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJiqGA022471 for ; Mon, 20 Sep 2004 12:44:53 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8KJid9Y000811; Mon, 20 Sep 2004 21:44:39 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 60FE590265; Mon, 20 Sep 2004 21:44:39 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16719.13095.369830.547715@robur.slu.se> Date: Mon, 20 Sep 2004 21:44:39 +0200 To: cd@cdaniel.de Cc: netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: "dst cache overflow" X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 610 Lines: 20 Hello! size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot mc GC:tot ignore gmiss dstof HLS:in out 10501 593 339 0 0 0 0 0 250 24 0 362 360 2 0 229 48 The number of packets that hits the route hash is about the same as the number of packets that misses it. (hit/tot) Either your route hash is so small in that case increase rhash_entries. Or you are receiving a DoS attack. I've sent a new version rtstat to Stepfen Hemminger. ftp://robur.slu.se/pub/Linux/net-development/rt_cache_stat/rtstat.c --ro From garzik@havoc.gtf.org Mon Sep 20 12:49:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 12:49:15 -0700 (PDT) Received: from havoc.gtf.org ([69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KJmxoZ022830 for ; Mon, 20 Sep 2004 12:49:00 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id A1EB7776E; Mon, 20 Sep 2004 15:48:42 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i8KJmgxS021828; Mon, 20 Sep 2004 15:48:42 -0400 Date: Mon, 20 Sep 2004 15:48:42 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: netdev-2.6 queue updated Message-ID: <20040920194842.GA21782@havoc.gtf.org> Reply-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.1i X-archive-position: 9168 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 8987 Lines: 230 BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.9-rc2-bk6-netdev1.patch.bz2 This will update the following files: arch/cris/arch-v10/drivers/ethernet.c | 140 ++---- drivers/ieee1394/eth1394.c | 95 +--- drivers/media/dvb/dvb-core/dvb_net.c | 9 drivers/net/3c509.c | 151 ++----- drivers/net/8139cp.c | 80 ++- drivers/net/8139too.c | 14 drivers/net/Kconfig | 21 - drivers/net/acenic.c | 163 +++---- drivers/net/acenic.h | 23 - drivers/net/amd8111e.c | 248 +++++------ drivers/net/atp.c | 2 drivers/net/b44.c | 102 ++-- drivers/net/b44.h | 113 ----- drivers/net/defxx.c | 144 +++--- drivers/net/defxx.h | 2 drivers/net/dl2k.c | 267 +++++------- drivers/net/e100.c | 12 drivers/net/e1000/e1000.h | 2 drivers/net/e1000/e1000_ethtool.c | 6 drivers/net/e1000/e1000_hw.c | 115 +++++ drivers/net/e1000/e1000_main.c | 41 - drivers/net/e1000/e1000_osdep.h | 6 drivers/net/eepro100.c | 425 +++++++++----------- drivers/net/ewrk3.c | 326 +++++++-------- drivers/net/forcedeth.c | 111 +---- drivers/net/hamachi.c | 157 +++---- drivers/net/hamradio/hdlcdrv.c | 2 drivers/net/ibmlana.c | 9 drivers/net/iseries_veth.c | 81 +-- drivers/net/ixgb/ixgb_ethtool.c | 494 +++++++---------------- drivers/net/ixgb/ixgb_main.c | 24 - drivers/net/mac8390.c | 4 drivers/net/meth.c | 26 - drivers/net/natsemi.c | 273 +++++-------- drivers/net/ne2k-pci.c | 31 + drivers/net/ns83820.c | 61 -- drivers/net/pcmcia/smc91c92_cs.c | 181 ++++---- drivers/net/r8169.c | 606 +++++++++++++++++++++------- drivers/net/sis900.c | 258 ++++++------ drivers/net/sk_mca.c | 9 drivers/net/smc91x.h | 43 ++ drivers/net/starfire.c | 191 ++++----- drivers/net/sundance.c | 187 ++++---- drivers/net/tulip/de4x5.c | 2 drivers/net/tulip/tulip_core.c | 34 - drivers/net/tulip/winbond-840.c | 2 drivers/net/tulip/xircom_tulip_cb.c | 194 ++++----- drivers/net/typhoon.c | 245 +++++------ drivers/net/wan/lmc/lmc_main.c | 9 drivers/net/wireless/airo.c | 45 +- drivers/net/wireless/netwave_cs.c | 12 drivers/net/wireless/prism54/isl_38xx.c | 15 drivers/net/wireless/prism54/isl_38xx.h | 4 drivers/net/wireless/prism54/isl_ioctl.c | 629 ++++++++++++++++++++++++++---- drivers/net/wireless/prism54/isl_ioctl.h | 2 drivers/net/wireless/prism54/isl_oid.h | 9 drivers/net/wireless/prism54/islpci_dev.c | 35 - drivers/net/wireless/prism54/islpci_dev.h | 4 drivers/net/wireless/prism54/islpci_eth.c | 5 drivers/net/wireless/prism54/oid_mgt.c | 121 +++++ drivers/net/wireless/prism54/oid_mgt.h | 3 drivers/net/wireless/wavelan.c | 19 drivers/net/wireless/wavelan.p.h | 3 drivers/net/wireless/wavelan_cs.c | 181 +++----- drivers/net/wireless/wavelan_cs.p.h | 3 drivers/net/wireless/wl3501_cs.c | 53 -- drivers/net/yellowfin.c | 62 +- drivers/usb/gadget/ether.c | 73 +-- drivers/usb/net/catc.c | 122 +---- drivers/usb/net/kaweth.c | 34 - drivers/usb/net/pegasus.c | 297 +++++--------- drivers/usb/net/rtl8150.c | 186 +++----- include/linux/netdevice.h | 4 include/linux/wireless.h | 64 ++- include/net/iw_handler.h | 60 ++ net/core/dev.c | 2 net/core/wireless.c | 212 ++++++---- net/irda/irlan/irlan_client.c | 2 78 files changed, 4075 insertions(+), 3927 deletions(-) through these ChangeSets: : o eepro100.c iomap conversion : o [netdrvr b44] clean up SiliconBackplane definitions/functions o [netdrvr b44] ignore carrier lost errors Alexander Viro: o (27/27) catc ethtool conversion o (26/27) kaweth ethtool conversion o (25/27) pegasus ethtool conversion o (24/27) rtl8150 ethtool conversion o (23/27) gadget ethtool conversion o (22/27) amd8111e ethtool conversion o (21/27) dl2k ethtool conversion o (20/27) eepro100 ethtool conversion o (19/27) ewrk3 ethtool conversion o (18/27) forcedeth ethtool conversion o (17/27) hamachi ethtool conversion o (16/27) veth ethtool conversion o (15/27) natsemi ethtool conversion o (14/27) ns83820 ethtool conversion o (13/27) starfire ethtool conversion o (12/27) sundance ethtool conversion o (11/27) typhoon ethtool conversion o (10/27) yellowfin ethtool conversion o (9/27) wl3501_cs ethtool conversion o (8/27) wavelan ethtool conversion o (7/27) xircom ethtool conversion o (6/27) tulip ethtool conversion o (5/27) smc91c92_cs ethtool conversion o (4/27) 3c509 ethtool conversion o (3/27) ixgb ethtool conversion o (2/27) cris ethtool conversion o (1/27) eth1394 ethtool conversion o [netdrvr starfire] use netdev_priv o [netdrvr starfire] fix unregister_netdev call site o [netdrvr] use netdev_priv in dl2k, hamachi o [netdrvr] netdev_priv for sundance, typhoon, yellowfin o [netdrvr] netdev_priv for ewrk3, xircom_tulip_cb, wavelan_cs o [netdrvr usb] use netdev_priv o [netdrvr eth1394] use netdev_priv Andrew Morton: o pegasus.c fixes o de4x5 warning fix Daniele Venzano: o [netdrvr sis900] whitespace and codingstyle updates David Dillow: o PCI cleanups and convert to ethtool_ops François Romieu: o via-velocity: wrong module name in Kconfig documentation o r8169: default on disabling PCIDAC o r8169: Mac identifier extracted from Realtek's driver v2.2 o r8169: TSO support o r8169: hint for Tx flow control o r8169: miscalculation of available Tx descriptors o 8139cp: SG support fixes o r8169: vlan support o r8169: Rx checksum support o r8169: advertise DMA to high memory o r8169: Tx checksum offload o r8169: comment a gcc 2.95.x bug o r8169: sync the names of a few bits with the 8139cp driver o r8169: bump version number o r8169: enable MWI o r8169: code cleanup o r8169: per device receive buffer size o r8169: add ethtool_ops.{get_regs_len/get_regs} Ganesh Venkatesan: o e1000 - Ethtool -- 82545 do not support WoL o e1000 - Polarity reversal workaround for 10F/10H links o e1000 - Fix VLAN filter setup errors (while running on PPC) o e1000 Check value returned by from pci_enable_device o e1000 - Removed support for advanced TCO features o e1000 - use pci_device_name for syslog messages till registering netdevice. o e100 driver version number update o e100 - use NET_IP_ALIGN to set rx data buffer alignment o e100 - Use pci_device_name for syslog messages till registering netdevice Jean Tourrilhes: o wireless-drivers-update-for-we-17.patch o wireless-extension-v17-for-linus.patch Jeff Garzik: o [netdrvr eepro100] fix pci_iomap() args and info msg that follows o [netdrvr b44] update MODULE_AUTHORS o [netdrvr 8139cp] TSO support o [netdev] Remove no-op in-driver implementations of ->set_config() Kenji Kaneshige: o add missing pci_disable_device for e1000 Maciej W. Rozycki: o defxx device name fixes o defxx trivial updates Marc Singer: o adding smc91x ethernet to lpd7a40x Margit Schubert-While: o prism54 fix wpa_supplicant frequency parsing o prism54 initial WPA support o prism54 add WE17 support o prism54 remove module params o prism54 Code cleanup Mika Kukkonen: o sparse: fix warnings in net/irda/* Olaf Hering: o remove old version check from mac8390 Pavel Machek: o swsuspend for ne2k-pci cards Pekka Pietikäinen: o b44: use bounce buffers to workaround chip DMA bug/limitations Ralf Bächle: o Stop queue on close in hdlcdrv Rene Herman: o 8139too Interframe Gap Time Roger Luethi: o mc_filter on big-endian arch Stephen Hemminger: o 8139cp - module_param o (4/4) acenic - don't spin forever in hard_start_xmit o (3/4) acenic - __iomem warnings cleanup o (2/4) acenic - eliminate MAX_SKB_FRAGS #if o (1/4) acenic - use netdev_priv From arekm@pld-linux.org Mon Sep 20 13:15:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 13:15:10 -0700 (PDT) Received: from smtp.sys.beep.pl (exim@smtp.sys.beep.pl [195.245.198.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KKF0on023436 for ; Mon, 20 Sep 2004 13:15:03 -0700 Received: from gucio.beep.pl ([195.245.198.2] ident=exim) by maja.beep.pl with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.42) id 1C9UOV-0001p1-3t for netdev@oss.sgi.com; Mon, 20 Sep 2004 22:04:15 +0200 Received: from [83.27.21.89] (helo=mobarm.localnet) by gucio.beep.pl with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42) id 1C9UYh-0001rb-G1 for netdev@oss.sgi.com; Mon, 20 Sep 2004 22:14:47 +0200 From: Arkadiusz Miskiewicz Organization: SelfOrganizing To: netdev@oss.sgi.com Subject: Re: netdev-2.6 queue updated Date: Mon, 20 Sep 2004 22:14:45 +0200 User-Agent: KMail/1.7 References: <20040920194842.GA21782@havoc.gtf.org> In-Reply-To: <20040920194842.GA21782@havoc.gtf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Disposition: inline Message-Id: <200409202214.45202.arekm@pld-linux.org> X-Authenticated-Id: arekm Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8KKF0on023436 X-archive-position: 9169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arekm@pld-linux.org Precedence: bulk X-list: netdev Content-Length: 407 Lines: 13 On Monday 20 of September 2004 21:48, Jeff Garzik wrote: > Pavel Machek: > o swsuspend for ne2k-pci cards I was always wondering what these changelogs are saying ? For example Pavel is not author for this change - Éric Brunet is. It seems that bk changelog quite often lies. -- Arkadiusz Mi¶kiewicz PLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ From ak@suse.de Mon Sep 20 13:30:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 13:30:46 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KKUcx3023999 for ; Mon, 20 Sep 2004 13:30:41 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 675A7C367A5; Mon, 20 Sep 2004 22:30:22 +0200 (CEST) Date: Mon, 20 Sep 2004 22:30:21 +0200 From: Andi Kleen To: Anton Blanchard Cc: netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040920203021.GD4242@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920063012.GL2825@krispykreme> X-archive-position: 9170 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 428 Lines: 13 On Mon, Sep 20, 2004 at 04:30:13PM +1000, Anton Blanchard wrote: > > Hi, > > I just tried latest 2.6.9-rc2-BK on a machine with an e1000 on it. With > TSO off it does about 100MB/sec. With TSO on it does between 1MB/sec and > 10MB/sec. I see the same problem here, but it's even worse. I only get 150-200KB/s sending data with scp from a fast machine with e1000 with a gigabit link. netperf also gives only 250KB/s. -Andi From jgarzik@pobox.com Mon Sep 20 13:31:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 13:32:00 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KKVpmX024331 for ; Mon, 20 Sep 2004 13:31:52 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9Up1-0004n4-9T; Mon, 20 Sep 2004 21:31:39 +0100 Message-ID: <414F3E1D.8070106@pobox.com> Date: Mon, 20 Sep 2004 16:31:25 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arkadiusz Miskiewicz CC: netdev@oss.sgi.com Subject: Re: netdev-2.6 queue updated References: <20040920194842.GA21782@havoc.gtf.org> <200409202214.45202.arekm@pld-linux.org> In-Reply-To: <200409202214.45202.arekm@pld-linux.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 9171 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 300 Lines: 11 Arkadiusz Miskiewicz wrote: > For example Pavel is not author for this change - Éric Brunet is. > > It seems that bk changelog quite often lies. ChangeSet@1.1923.1.4, 2004-09-20 14:34:45-04:00, pavel@ucw.cz [PATCH] swsuspend for ne2k-pci cards Author: Éric Brunet From arekm@pld-linux.org Mon Sep 20 13:38:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 13:38:41 -0700 (PDT) Received: from smtp.sys.beep.pl (exim@smtp.sys.beep.pl [195.245.198.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KKcW2T024742 for ; Mon, 20 Sep 2004 13:38:35 -0700 Received: from gucio.beep.pl ([195.245.198.2] ident=exim) by maja.beep.pl with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.42) id 1C9UlF-0002ti-PI; Mon, 20 Sep 2004 22:27:45 +0200 Received: from [83.27.21.89] (helo=mobarm.localnet) by gucio.beep.pl with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.42) id 1C9UvS-0004EF-HL; Mon, 20 Sep 2004 22:38:18 +0200 From: Arkadiusz Miskiewicz Organization: SelfOrganizing To: Jeff Garzik Subject: Re: netdev-2.6 queue updated Date: Mon, 20 Sep 2004 22:38:16 +0200 User-Agent: KMail/1.7 Cc: netdev@oss.sgi.com References: <20040920194842.GA21782@havoc.gtf.org> <200409202214.45202.arekm@pld-linux.org> <414F3E1D.8070106@pobox.com> In-Reply-To: <414F3E1D.8070106@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Disposition: inline Message-Id: <200409202238.16750.arekm@pld-linux.org> X-Authenticated-Id: arekm Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8KKcW2T024742 X-archive-position: 9172 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arekm@pld-linux.org Precedence: bulk X-list: netdev Content-Length: 740 Lines: 20 On Monday 20 of September 2004 22:31, Jeff Garzik wrote: > Arkadiusz Miskiewicz wrote: > > For example Pavel is not author for this change - Éric Brunet is. > > > > It seems that bk changelog quite often lies. > > ChangeSet@1.1923.1.4, 2004-09-20 14:34:45-04:00, pavel@ucw.cz > [PATCH] swsuspend for ne2k-pci cards > > Author: Éric Brunet Thanks, now it's clear to me what the changelogs say. (anyway it would be better to put author in these changelogs instead of commiter because usually people want to contact with the one who made the changes not the one who commited them). -- Arkadiusz Mi¶kiewicz PLD/Linux Team http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/ From Kai.Makisara@kolumbus.fi Mon Sep 20 13:53:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 13:53:33 -0700 (PDT) Received: from fep32-app.kolumbus.fi (fep32-0.kolumbus.fi [193.229.0.63]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KKrRe0025175 for ; Mon, 20 Sep 2004 13:53:28 -0700 Received: from kai.makisara.local ([80.186.76.126]) by fep32-app.kolumbus.fi with ESMTP id <20040920205315.GLIA29325.fep32-app.kolumbus.fi@kai.makisara.local>; Mon, 20 Sep 2004 23:53:15 +0300 Date: Mon, 20 Sep 2004 23:53:15 +0300 (EEST) From: Kai Makisara X-X-Sender: makisara@kai.makisara.local To: netdev@oss.sgi.com cc: ganesh.venkatesan@intel.com Subject: e1000 lockup in linux 2.6.9-rc2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9173 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Kai.Makisara@kolumbus.fi Precedence: bulk X-list: netdev Content-Length: 1909 Lines: 44 When I started large data transfers in 100 Mb/s network, my computer very soon locked totally (i.e., not responding to network, keyboard and mouse dead). This had not happened for several days with 2.6.9-rc2 when the network activity had been light (1 Mb/s DSL). Some experimentation showed that the lockups were caused by this patch fragment in 2.6.9-rc2: diff -u b/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- b/drivers/net/e1000/e1000_main.c 2004-08-24 00:04:05 -07:00 +++ b/drivers/net/e1000/e1000_main.c 2004-09-12 22:34:24 -07:00 @@ -499,7 +499,9 @@ if(pci_using_dac) netdev->features |= NETIF_F_HIGHDMA; - + /* hard_start_xmit is safe against parallel locking */ + netdev->features |= NETIF_F_LLTX; + adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw); /* before reading the EEPROM, reset the controller to The computer has Intel D875PBZLK motherboard with 1 GB memory and 2.6 GHz Pentium4 (HT). An SMP kernel has been used. lspci -vv gives the following information about the NIC: 0000:02:01.0 Ethernet controller: Intel Corp. 82547EI Gigabit Ethernet Controller (LOM) Subsystem: Intel Corp.: Unknown device 3025 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- ; Mon, 20 Sep 2004 13:56:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9VCg-0000LK-00; Mon, 20 Sep 2004 13:56:06 -0700 Date: Mon, 20 Sep 2004 13:56:06 -0700 From: "David S. Miller" To: Kai Makisara Cc: netdev@oss.sgi.com, ganesh.venkatesan@intel.com Subject: Re: e1000 lockup in linux 2.6.9-rc2 Message-Id: <20040920135606.7a0885df.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9174 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2002 Lines: 61 On Mon, 20 Sep 2004 23:53:15 +0300 (EEST) Kai Makisara wrote: > When I started large data transfers in 100 Mb/s network, my computer very > soon locked totally (i.e., not responding to network, keyboard and mouse > dead). This had not happened for several days with 2.6.9-rc2 when the > network activity had been light (1 Mb/s DSL). > > Some experimentation showed that the lockups were caused by this patch > fragment in 2.6.9-rc2: Please make sure you have this patch in your tree, it should fix your problem: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/13 12:58:04-07:00 ak@muc.de # [NET]: Fix missing spin lock in lltx path. # # This fixes a silly missing spin lock in the relock path. For some # reason it seems to still work when you don't have spinlock debugging # enabled. # # Please apply. # # Thanks to Arjan's spinlock debug kernel for finding it. # # Signed-off-by: Andi Kleen # Signed-off-by: David S. Miller # # net/sched/sch_generic.c # 2004/09/13 12:57:46-07:00 ak@muc.de +3 -1 # [NET]: Fix missing spin lock in lltx path. # # This fixes a silly missing spin lock in the relock path. For some # reason it seems to still work when you don't have spinlock debugging # enabled. # # Please apply. # # Thanks to Arjan's spinlock debug kernel for finding it. # # Signed-off-by: Andi Kleen # Signed-off-by: David S. Miller # diff -Nru a/net/sched/sch_generic.c b/net/sched/sch_generic.c --- a/net/sched/sch_generic.c 2004-09-20 13:36:19 -07:00 +++ b/net/sched/sch_generic.c 2004-09-20 13:36:19 -07:00 @@ -148,8 +148,10 @@ spin_lock(&dev->queue_lock); return -1; } - if (ret == NETDEV_TX_LOCKED && nolock) + if (ret == NETDEV_TX_LOCKED && nolock) { + spin_lock(&dev->queue_lock); goto collision; + } } /* NETDEV_TX_BUSY - we need to requeue */ From jchapman@katalix.com Mon Sep 20 14:12:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 14:12:06 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KLBwY9026204 for ; Mon, 20 Sep 2004 14:12:00 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1C9VRo-0007dF-Vb; Mon, 20 Sep 2004 16:11:45 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Mon, 20 Sep 2004 22:11:44 +0100 Message-ID: <1095714704.414f4790cd168@www.katalix.com> Date: Mon, 20 Sep 2004 22:11:44 +0100 From: James Chapman To: netdev@oss.sgi.com Cc: Martijn van Oosterhout , mostrows@styx.uwaterloo.ca Subject: PPP-over-L2TP kernel support, new patch for review MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1095714704f29a8d8a0a03d7f3fed328bf7615d061" User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 110141 Lines: 1468 This message is in MIME format. ---MOQ1095714704f29a8d8a0a03d7f3fed328bf7615d061 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Attached is a revised version of the new PPP over L2TP support for review. Thanks DaveM and Herbert for comments so far. The following comments have been addressed in this new version: - use Linux list macros for all lists - split sockaddr_pppox into separate sockaddr_pppoe and sockaddr_pppol2tp structs I've split the patch into 3 diffs: 1. sockaddr_pppoe.diff - fix sockaddr_pppox issue 2. if_pppox.h_ws.diff - fixup whitespace formatting 3. pppol2tp-2.diff - add PPPoL2TP Please also check the following FIXMEs in pppol2tp.c. If these aren't issues, I'll remove the FIXMEs and submit a new patch. - pppol2tp_data_ready() lock the socket when walking sk->sk_receive_queue? - pppol2tp_build_l2tp_header() unaligned accesses? - pppol2tp_xmit() handle skb fragments? - pppol2tp_create() sk_set_owner() - what is the real problem here? - pppol2tp_session_setsockopt() change ppp channel's hdrlen on the fly? Also, since submitting the previous version, I've made a few internal L2TP changes which are included in the pppol2tp patch. Most relevant is the addition of a using_ipsec flag - I'm trying to return a read-only indicator to userspace whether the L2TP tunnel is protected by IPSEC. Is this the right way to do it? /james ---MOQ1095714704f29a8d8a0a03d7f3fed328bf7615d061 Content-Type: application/octet-stream; name="sockaddr_pppoe.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sockaddr_pppoe.diff" ZGlmZiAtTmF1ciBsaW51eC0yLjYuOC4xLm9yaWcvZHJpdmVycy9uZXQvcHBwb2UuYyBsaW51eC0y LjYuOC4xL2RyaXZlcnMvbmV0L3BwcG9lLmMKLS0tIGxpbnV4LTIuNi44LjEub3JpZy9kcml2ZXJz L25ldC9wcHBvZS5jCTIwMDQtMDgtMTQgMTE6NTU6MzUuMDAwMDAwMDAwICswMTAwCisrKyBsaW51 eC0yLjYuOC4xL2RyaXZlcnMvbmV0L3BwcG9lLmMJMjAwNC0wOS0yMCAxMDo1MjoxNC4wMDAwMDAw MDAgKzAxMDAKQEAgLTIwMSw5ICsyMDEsOSBAQAogCXJldHVybiBwbzsKIH0KIAotc3RhdGljIGlu bGluZSBzdHJ1Y3QgcHBwb3hfb3B0ICpnZXRfaXRlbV9ieV9hZGRyKHN0cnVjdCBzb2NrYWRkcl9w cHBveCAqc3ApCitzdGF0aWMgaW5saW5lIHN0cnVjdCBwcHBveF9vcHQgKmdldF9pdGVtX2J5X2Fk ZHIoc3RydWN0IHNvY2thZGRyX3BwcG9lICpzcCkKIHsKLQlyZXR1cm4gZ2V0X2l0ZW0oc3AtPnNh X2FkZHIucHBwb2Uuc2lkLCBzcC0+c2FfYWRkci5wcHBvZS5yZW1vdGUpOworCXJldHVybiBnZXRf aXRlbShzcC0+cHBwb2Uuc2lkLCBzcC0+cHBwb2UucmVtb3RlKTsKIH0KIAogc3RhdGljIGlubGlu ZSBpbnQgc2V0X2l0ZW0oc3RydWN0IHBwcG94X29wdCAqcG8pCkBAIC01NzIsNyArNTcyLDcgQEAK IHsKIAlzdHJ1Y3Qgc29jayAqc2sgPSBzb2NrLT5zazsKIAlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 ID0gTlVMTDsKLQlzdHJ1Y3Qgc29ja2FkZHJfcHBwb3ggKnNwID0gKHN0cnVjdCBzb2NrYWRkcl9w cHBveCAqKSB1c2VydmFkZHI7CisJc3RydWN0IHNvY2thZGRyX3BwcG9lICpzcCA9IChzdHJ1Y3Qg c29ja2FkZHJfcHBwb2UgKikgdXNlcnZhZGRyOwogCXN0cnVjdCBwcHBveF9vcHQgKnBvID0gcHBw b3hfc2soc2spOwogCWludCBlcnJvcjsKIApAQCAtNTg0LDEyICs1ODQsMTIgQEAKIAogCS8qIENo ZWNrIGZvciBhbHJlYWR5IGJvdW5kIHNvY2tldHMgKi8KIAllcnJvciA9IC1FQlVTWTsKLQlpZiAo KHNrLT5za19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkgJiYgc3AtPnNhX2FkZHIucHBwb2Uuc2lk KQorCWlmICgoc2stPnNrX3N0YXRlICYgUFBQT1hfQ09OTkVDVEVEKSAmJiBzcC0+cHBwb2Uuc2lk KQogCQlnb3RvIGVuZDsKIAogCS8qIENoZWNrIGZvciBhbHJlYWR5IGRpc2Nvbm5lY3RlZCBzb2Nr ZXRzLCBvbiBhdHRlbXB0cyB0byBkaXNjb25uZWN0ICovCiAJZXJyb3IgPSAtRUFMUkVBRFk7Ci0J aWYgKChzay0+c2tfc3RhdGUgJiBQUFBPWF9ERUFEKSAmJiAhc3AtPnNhX2FkZHIucHBwb2Uuc2lk ICkKKwlpZiAoKHNrLT5za19zdGF0ZSAmIFBQUE9YX0RFQUQpICYmICFzcC0+cHBwb2Uuc2lkICkK IAkJZ290byBlbmQ7CiAKIAllcnJvciA9IDA7CkBAIC02MDksOCArNjA5LDggQEAKIAl9CiAKIAkv KiBEb24ndCByZS1iaW5kIGlmIHNpZD09MCAqLwotCWlmIChzcC0+c2FfYWRkci5wcHBvZS5zaWQg IT0gMCkgewotCQlkZXYgPSBkZXZfZ2V0X2J5X25hbWUoc3AtPnNhX2FkZHIucHBwb2UuZGV2KTsK KwlpZiAoc3AtPnBwcG9lLnNpZCAhPSAwKSB7CisJCWRldiA9IGRldl9nZXRfYnlfbmFtZShzcC0+ cHBwb2UuZGV2KTsKIAogCQllcnJvciA9IC1FTk9ERVY7CiAJCWlmICghZGV2KQpAQCAtNjIyLDcg KzYyMiw3IEBACiAJCQlnb3RvIGVycl9wdXQ7CiAKIAkJbWVtY3B5KCZwby0+cHBwb2VfcGEsCi0J CSAgICAgICAmc3AtPnNhX2FkZHIucHBwb2UsCisJCSAgICAgICAmc3AtPnBwcG9lLAogCQkgICAg ICAgc2l6ZW9mKHN0cnVjdCBwcHBvZV9hZGRyKSk7CiAKIAkJZXJyb3IgPSBzZXRfaXRlbShwbyk7 CkBAIC02NDIsNyArNjQyLDcgQEAKIAkJc2stPnNrX3N0YXRlID0gUFBQT1hfQ09OTkVDVEVEOwog CX0KIAotCXBvLT5udW0gPSBzcC0+c2FfYWRkci5wcHBvZS5zaWQ7CisJcG8tPm51bSA9IHNwLT5w cHBvZS5zaWQ7CiAKICBlbmQ6CiAJcmVsZWFzZV9zb2NrKHNrKTsKQEAgLTY1OSwxMiArNjU5LDEy IEBACiBzdGF0aWMgaW50IHBwcG9lX2dldG5hbWUoc3RydWN0IHNvY2tldCAqc29jaywgc3RydWN0 IHNvY2thZGRyICp1YWRkciwKIAkJICBpbnQgKnVzb2NrYWRkcl9sZW4sIGludCBwZWVyKQogewot CWludCBsZW4gPSBzaXplb2Yoc3RydWN0IHNvY2thZGRyX3BwcG94KTsKLQlzdHJ1Y3Qgc29ja2Fk ZHJfcHBwb3ggc3A7CisJaW50IGxlbiA9IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfcHBwb2UpOwor CXN0cnVjdCBzb2NrYWRkcl9wcHBvZSBzcDsKIAogCXNwLnNhX2ZhbWlseQk9IEFGX1BQUE9YOwog CXNwLnNhX3Byb3RvY29sCT0gUFhfUFJPVE9fT0U7Ci0JbWVtY3B5KCZzcC5zYV9hZGRyLnBwcG9l LCAmcHBwb3hfc2soc29jay0+c2spLT5wcHBvZV9wYSwKKwltZW1jcHkoJnNwLnBwcG9lLCAmcHBw b3hfc2soc29jay0+c2spLT5wcHBvZV9wYSwKIAkgICAgICAgc2l6ZW9mKHN0cnVjdCBwcHBvZV9h ZGRyKSk7CiAKIAltZW1jcHkodWFkZHIsICZzcCwgbGVuKTsKQEAgLTc0MCw3ICs3NDAsNyBAQAog CQllcnIgPSAtRUZBVUxUOwogCQlpZiAoY29weV9mcm9tX3VzZXIoJnBvLT5wcHBvZV9yZWxheSwK IAkJCQkgICAodm9pZCBfX3VzZXIgKilhcmcsCi0JCQkJICAgc2l6ZW9mKHN0cnVjdCBzb2NrYWRk cl9wcHBveCkpKQorCQkJCSAgIHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfcHBwb2UpKSkKIAkJCWJy ZWFrOwogCiAJCWVyciA9IC1FSU5WQUw7CmRpZmYgLU5hdXIgbGludXgtMi42LjguMS5vcmlnL2lu Y2x1ZGUvbGludXgvaWZfcHBwb3guaCBsaW51eC0yLjYuOC4xL2luY2x1ZGUvbGludXgvaWZfcHBw b3guaAotLS0gbGludXgtMi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvaWZfcHBwb3guaAkyMDA0 LTA4LTE0IDExOjU0OjUwLjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9pbmNsdWRl L2xpbnV4L2lmX3BwcG94LmgJMjAwNC0wOS0yMCAxMjoxOToyNC4wMDAwMDAwMDAgKzAxMDAKQEAg LTUxLDE1ICs1MSwyNiBAQAogICovIAogI2RlZmluZSBQWF9QUk9UT19PRSAgICAwIC8qIEN1cnJl bnRseSBqdXN0IFBQUG9FICovCiAjZGVmaW5lIFBYX01BWF9QUk9UTyAgIDEJCi0gCisKKy8qIFRo ZSB1c2Ugb2YgYSB1bmlvbiBpc24ndCB2aWFibGUgYmVjYXVzZSB0aGUgc2l6ZSBvZiB0aGlzIHN0 cnVjdAorICogbXVzdCBzdGF5IGZpeGVkIG92ZXIgdGltZSAtLSBhcHBsaWNhdGlvbnMgdXNlIHNp emVvZihzdHJ1Y3QKKyAqIHNvY2thZGRyX3BwcG94KSB0byBmaWxsIGl0LiBVc2UgcHJvdG9jb2wg c3BlY2lmaWMgc29ja2FkZHIgdHlwZXMKKyAqIGluc3RlYWQuCisgKi8gCiBzdHJ1Y3Qgc29ja2Fk ZHJfcHBwb3ggeyAKICAgICAgICBzYV9mYW1pbHlfdCAgICAgc2FfZmFtaWx5OyAgICAgICAgICAg IC8qIGFkZHJlc3MgZmFtaWx5LCBBRl9QUFBPWCAqLyAKICAgICAgICB1bnNpZ25lZCBpbnQgICAg c2FfcHJvdG9jb2w7ICAgICAgICAgIC8qIHByb3RvY29sIGlkZW50aWZpZXIgKi8gCiAgICAgICAg dW5pb257IAogICAgICAgICAgICAgICAgc3RydWN0IHBwcG9lX2FkZHIgICAgICAgcHBwb2U7IAog ICAgICAgIH1zYV9hZGRyOyAKLX1fX2F0dHJpYnV0ZV9fICgocGFja2VkKSk7IAorfV9fYXR0cmli dXRlX18gKChwYWNrZWQpKSBfX2RlcHJlY2F0ZWQ7IAogCisvKiBNdXN0IGJlIGJpbmFyeS1jb21w YXRpYmxlIHdpdGggc29ja2FkZHJfcHBwb3ggZm9yIGJhY2t3YXJkcyBjb21wYXRhYmlsdHkgKi8K K3N0cnVjdCBzb2NrYWRkcl9wcHBvZSB7IAorCXNhX2ZhbWlseV90ICAgICBzYV9mYW1pbHk7CS8q IGFkZHJlc3MgZmFtaWx5LCBBRl9QUFBPWCAqLyAKKwl1bnNpZ25lZCBpbnQgICAgc2FfcHJvdG9j b2w7ICAgIC8qIHByb3RvY29sIGlkZW50aWZpZXIgKi8gCisJc3RydWN0IHBwcG9lX2FkZHIgcHBw b2U7IAorfV9fYXR0cmlidXRlX18gKChwYWNrZWQpKTsgCiAKIC8qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAqCkBA IC0xMTUsNyArMTI2LDcgQEAKIHN0cnVjdCBwcHBvZV9vcHQgewogCXN0cnVjdCBuZXRfZGV2aWNl ICAgICAgKmRldjsJICAvKiBkZXZpY2UgYXNzb2NpYXRlZCB3aXRoIHNvY2tldCovCiAJc3RydWN0 IHBwcG9lX2FkZHIJcGE7CSAgLyogd2hhdCB0aGlzIHNvY2tldCBpcyBib3VuZCB0byovCi0Jc3Ry dWN0IHNvY2thZGRyX3BwcG94CXJlbGF5OwkgIC8qIHdoYXQgc29ja2V0IGRhdGEgd2lsbCBiZQor CXN0cnVjdCBzb2NrYWRkcl9wcHBvZQlyZWxheTsJICAvKiB3aGF0IHNvY2tldCBkYXRhIHdpbGwg YmUKIAkJCQkJICAgICByZWxheWVkIHRvIChQUFBvRSByZWxheWluZykgKi8KIH07CiAK ---MOQ1095714704f29a8d8a0a03d7f3fed328bf7615d061 Content-Type: application/octet-stream; name="if_pppox.h_ws.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="if_pppox.h_ws.diff" ZGlmZiAtTmF1ciBsaW51eC0yLjYuOC4xLm9yaWcvaW5jbHVkZS9saW51eC9pZl9wcHBveC5oIGxp bnV4LTIuNi44LjEud3MvaW5jbHVkZS9saW51eC9pZl9wcHBveC5oCi0tLSBsaW51eC0yLjYuOC4x Lm9yaWcvaW5jbHVkZS9saW51eC9pZl9wcHBveC5oCTIwMDQtMDktMjAgMTM6MTk6NTAuMDAwMDAw MDAwICswMTAwCisrKyBsaW51eC0yLjYuOC4xLndzL2luY2x1ZGUvbGludXgvaWZfcHBwb3guaAky MDA0LTA5LTIwIDEzOjE4OjIwLjAwMDAwMDAwMCArMDEwMApAQCAtMSw2ICsxLDYgQEAKIC8qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioKICAqIExpbnV4IFBQUCBvdmVyIFggLSBHZW5lcmljIFBQUCB0cmFuc3Bv cnQgbGF5ZXIgc29ja2V0cwotICogTGludXggUFBQIG92ZXIgRXRoZXJuZXQgKFBQUG9FKSBTb2Nr ZXQgSW1wbGVtZW50YXRpb24gKFJGQyAyNTE2KSAKKyAqIExpbnV4IFBQUCBvdmVyIEV0aGVybmV0 IChQUFBvRSkgU29ja2V0IEltcGxlbWVudGF0aW9uIChSRkMgMjUxNikKICAqCiAgKiBUaGlzIGZp bGUgc3VwcGxpZXMgZGVmaW5pdGlvbnMgcmVxdWlyZWQgYnkgdGhlIFBQUCBvdmVyIEV0aGVybmV0 IGRyaXZlcgogICogKHBwcG94LmMpLiAgQWxsIHZlcnNpb24gaW5mb3JtYXRpb24gd3J0IHRoaXMg ZmlsZSBpcyBsb2NhdGVkIGluIHBwcG94LmMKQEAgLTIwLDcgKzIwLDcgQEAKICNpbmNsdWRlIDxh c20vdHlwZXMuaD4KICNpbmNsdWRlIDxhc20vYnl0ZW9yZGVyLmg+CiAKLSNpZmRlZiAgX19LRVJO RUxfXworI2lmZGVmCV9fS0VSTkVMX18KICNpbmNsdWRlIDxsaW51eC9pZl9ldGhlci5oPgogI2lu Y2x1ZGUgPGxpbnV4L2lmLmg+CiAjaW5jbHVkZSA8bGludXgvbmV0ZGV2aWNlLmg+CkBAIC0zNiw0 MSArMzYsNDEgQEAKICNkZWZpbmUgUEZfUFBQT1gJQUZfUFBQT1gKICNlbmRpZiAvKiAhKEFGX1BQ UE9YKSAqLwogCi0vKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqIAotICogUFBQb0UgYWRkcmVzc2luZyBkZWZpbml0 aW9uIAotICovIAotdHlwZWRlZiBfX3UxNiBzaWRfdDsgCi1zdHJ1Y3QgcHBwb2VfYWRkcnsgCi0g ICAgICAgc2lkX3QgICAgICAgICAgIHNpZDsgICAgICAgICAgICAgICAgICAgIC8qIFNlc3Npb24g aWRlbnRpZmllciAqLyAKLSAgICAgICB1bnNpZ25lZCBjaGFyICAgcmVtb3RlW0VUSF9BTEVOXTsg ICAgICAgLyogUmVtb3RlIGFkZHJlc3MgKi8gCi0gICAgICAgY2hhciAgICAgICAgICAgIGRldltJ Rk5BTVNJWl07ICAgICAgICAgIC8qIExvY2FsIGRldmljZSB0byB1c2UgKi8gCi19OyAKLSAKLS8q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKiogCi0gKiBQcm90b2NvbHMgc3VwcG9ydGVkIGJ5IEFGX1BQUE9YIAotICov IAotI2RlZmluZSBQWF9QUk9UT19PRSAgICAwIC8qIEN1cnJlbnRseSBqdXN0IFBQUG9FICovCi0j ZGVmaW5lIFBYX01BWF9QUk9UTyAgIDEJCisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBQUFBvRSBhZGRy ZXNzaW5nIGRlZmluaXRpb24KKyAqLwordHlwZWRlZiBfX3UxNiBzaWRfdDsKK3N0cnVjdCBwcHBv ZV9hZGRyIHsKKwlzaWRfdAkJc2lkOwkJCS8qIFNlc3Npb24gaWRlbnRpZmllciAqLworCXVuc2ln bmVkIGNoYXIJcmVtb3RlW0VUSF9BTEVOXTsJLyogUmVtb3RlIGFkZHJlc3MgKi8KKwljaGFyCQlk ZXZbSUZOQU1TSVpdOwkJLyogTG9jYWwgZGV2aWNlIHRvIHVzZSAqLworfTsKKworLyoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgorICogUHJvdG9jb2xzIHN1cHBvcnRlZCBieSBBRl9QUFBPWAorICovCisjZGVmaW5l IFBYX1BST1RPX09FCTAgLyogQ3VycmVudGx5IGp1c3QgUFBQb0UgKi8KKyNkZWZpbmUgUFhfTUFY X1BST1RPCTEKIAogLyogVGhlIHVzZSBvZiBhIHVuaW9uIGlzbid0IHZpYWJsZSBiZWNhdXNlIHRo ZSBzaXplIG9mIHRoaXMgc3RydWN0CiAgKiBtdXN0IHN0YXkgZml4ZWQgb3ZlciB0aW1lIC0tIGFw cGxpY2F0aW9ucyB1c2Ugc2l6ZW9mKHN0cnVjdAogICogc29ja2FkZHJfcHBwb3gpIHRvIGZpbGwg aXQuIFVzZSBwcm90b2NvbCBzcGVjaWZpYyBzb2NrYWRkciB0eXBlcwogICogaW5zdGVhZC4KLSAq LyAKLXN0cnVjdCBzb2NrYWRkcl9wcHBveCB7IAotICAgICAgIHNhX2ZhbWlseV90ICAgICBzYV9m YW1pbHk7ICAgICAgICAgICAgLyogYWRkcmVzcyBmYW1pbHksIEFGX1BQUE9YICovIAotICAgICAg IHVuc2lnbmVkIGludCAgICBzYV9wcm90b2NvbDsgICAgICAgICAgLyogcHJvdG9jb2wgaWRlbnRp ZmllciAqLyAKLSAgICAgICB1bmlvbnsgCi0gICAgICAgICAgICAgICBzdHJ1Y3QgcHBwb2VfYWRk ciAgICAgICBwcHBvZTsgCi0gICAgICAgfXNhX2FkZHI7IAotfV9fYXR0cmlidXRlX18gKChwYWNr ZWQpKSBfX2RlcHJlY2F0ZWQ7IAorICovCitzdHJ1Y3Qgc29ja2FkZHJfcHBwb3ggeworCXNhX2Zh bWlseV90CXNhX2ZhbWlseTsJCS8qIGFkZHJlc3MgZmFtaWx5LCBBRl9QUFBPWCAqLworCXVuc2ln bmVkIGludAlzYV9wcm90b2NvbDsJCS8qIHByb3RvY29sIGlkZW50aWZpZXIgKi8KKwl1bmlvbiB7 CisJCXN0cnVjdCBwcHBvZV9hZGRyCXBwcG9lOworCX0gc2FfYWRkcjsKK31fX2F0dHJpYnV0ZV9f ICgocGFja2VkKSkgX19kZXByZWNhdGVkOwogCiAvKiBNdXN0IGJlIGJpbmFyeS1jb21wYXRpYmxl IHdpdGggc29ja2FkZHJfcHBwb3ggZm9yIGJhY2t3YXJkcyBjb21wYXRhYmlsdHkgKi8KLXN0cnVj dCBzb2NrYWRkcl9wcHBvZSB7IAotCXNhX2ZhbWlseV90ICAgICBzYV9mYW1pbHk7CS8qIGFkZHJl c3MgZmFtaWx5LCBBRl9QUFBPWCAqLyAKLQl1bnNpZ25lZCBpbnQgICAgc2FfcHJvdG9jb2w7ICAg IC8qIHByb3RvY29sIGlkZW50aWZpZXIgKi8gCi0Jc3RydWN0IHBwcG9lX2FkZHIgcHBwb2U7IAot fV9fYXR0cmlidXRlX18gKChwYWNrZWQpKTsgCitzdHJ1Y3Qgc29ja2FkZHJfcHBwb2UgeworCXNh X2ZhbWlseV90CXNhX2ZhbWlseTsJLyogYWRkcmVzcyBmYW1pbHksIEFGX1BQUE9YICovCisJdW5z aWduZWQgaW50CXNhX3Byb3RvY29sOwkvKiBwcm90b2NvbCBpZGVudGlmaWVyICovCisJc3RydWN0 IHBwcG9lX2FkZHIgcHBwb2U7Cit9X19hdHRyaWJ1dGVfXyAoKHBhY2tlZCkpOwogCiAvKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqCiAgKgpAQCAtMTAwLDExICsxMDAsMTEgQEAKICNkZWZpbmUgUFRUX0FDX05BTUUJX19j b25zdGFudF9odG9ucygweDAxMDIpCiAjZGVmaW5lIFBUVF9IT1NUX1VOSVEJX19jb25zdGFudF9o dG9ucygweDAxMDMpCiAjZGVmaW5lIFBUVF9BQ19DT09LSUUJX19jb25zdGFudF9odG9ucygweDAx MDQpCi0jZGVmaW5lIFBUVF9WRU5ET1IgCV9fY29uc3RhbnRfaHRvbnMoMHgwMTA1KQorI2RlZmlu ZSBQVFRfVkVORE9SCV9fY29uc3RhbnRfaHRvbnMoMHgwMTA1KQogI2RlZmluZSBQVFRfUkVMQVlf U0lECV9fY29uc3RhbnRfaHRvbnMoMHgwMTEwKQotI2RlZmluZSBQVFRfU1JWX0VSUiAgICAgX19j b25zdGFudF9odG9ucygweDAyMDEpCi0jZGVmaW5lIFBUVF9TWVNfRVJSICAJX19jb25zdGFudF9o dG9ucygweDAyMDIpCi0jZGVmaW5lIFBUVF9HRU5fRVJSICAJX19jb25zdGFudF9odG9ucygweDAy MDMpCisjZGVmaW5lIFBUVF9TUlZfRVJSCV9fY29uc3RhbnRfaHRvbnMoMHgwMjAxKQorI2RlZmlu ZSBQVFRfU1lTX0VSUglfX2NvbnN0YW50X2h0b25zKDB4MDIwMikKKyNkZWZpbmUgUFRUX0dFTl9F UlIJX19jb25zdGFudF9odG9ucygweDAyMDMpCiAKIHN0cnVjdCBwcHBvZV9oZHIgewogI2lmIGRl ZmluZWQoX19MSVRUTEVfRU5ESUFOX0JJVEZJRUxEKQpAQCAtMTI0LDcgKzEyNCw3IEBACiAKICNp ZmRlZiBfX0tFUk5FTF9fCiBzdHJ1Y3QgcHBwb2Vfb3B0IHsKLQlzdHJ1Y3QgbmV0X2RldmljZSAg ICAgICpkZXY7CSAgLyogZGV2aWNlIGFzc29jaWF0ZWQgd2l0aCBzb2NrZXQqLworCXN0cnVjdCBu ZXRfZGV2aWNlCSpkZXY7CSAgLyogZGV2aWNlIGFzc29jaWF0ZWQgd2l0aCBzb2NrZXQqLwogCXN0 cnVjdCBwcHBvZV9hZGRyCXBhOwkgIC8qIHdoYXQgdGhpcyBzb2NrZXQgaXMgYm91bmQgdG8qLwog CXN0cnVjdCBzb2NrYWRkcl9wcHBvZQlyZWxheTsJICAvKiB3aGF0IHNvY2tldCBkYXRhIHdpbGwg YmUKIAkJCQkJICAgICByZWxheWVkIHRvIChQUFBvRSByZWxheWluZykgKi8KQEAgLTE2MiwxMiAr MTYyLDEyIEBACiAKIC8qIFBQUG9YIHNvY2tldCBzdGF0ZXMgKi8KIGVudW0gewotICAgIFBQUE9Y X05PTkUJCT0gMCwgIC8qIGluaXRpYWwgc3RhdGUgKi8KLSAgICBQUFBPWF9DT05ORUNURUQJPSAx LCAgLyogY29ubmVjdGlvbiBlc3RhYmxpc2hlZCA9PVRDUF9FU1RBQkxJU0hFRCAqLwotICAgIFBQ UE9YX0JPVU5ECQk9IDIsICAvKiBib3VuZCB0byBwcHAgZGV2aWNlICovCi0gICAgUFBQT1hfUkVM QVkJCT0gNCwgIC8qIGZvcndhcmRpbmcgaXMgZW5hYmxlZCAqLwotICAgIFBQUE9YX1pPTUJJRQk9 IDgsICAvKiBkZWFkLCBidXQgc3RpbGwgYm91bmQgdG8gcHBwIGRldmljZSAqLwotICAgIFBQUE9Y X0RFQUQJCT0gMTYgIC8qIGRlYWQsIHVzZWxlc3MsIHBsZWFzZSBjbGVhbiBtZSB1cCEqLworCVBQ UE9YX05PTkUJPSAwLCAgLyogaW5pdGlhbCBzdGF0ZSAqLworCVBQUE9YX0NPTk5FQ1RFRAk9IDEs ICAvKiBjb25uZWN0aW9uIGVzdGFibGlzaGVkID09VENQX0VTVEFCTElTSEVEICovCisJUFBQT1hf Qk9VTkQJPSAyLCAgLyogYm91bmQgdG8gcHBwIGRldmljZSAqLworCVBQUE9YX1JFTEFZCT0gNCwg IC8qIGZvcndhcmRpbmcgaXMgZW5hYmxlZCAqLworCVBQUE9YX1pPTUJJRQk9IDgsICAvKiBkZWFk LCBidXQgc3RpbGwgYm91bmQgdG8gcHBwIGRldmljZSAqLworCVBQUE9YX0RFQUQJPSAxNiAgLyog ZGVhZCwgdXNlbGVzcywgcGxlYXNlIGNsZWFuIG1lIHVwISovCiB9OwogCiAjZW5kaWYgLyogX19L RVJORUxfXyAqLwo= ---MOQ1095714704f29a8d8a0a03d7f3fed328bf7615d061 Content-Type: application/octet-stream; name="pppol2tp-2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pppol2tp-2.diff" ZGlmZiAtTmF1ciBsaW51eC0yLjYuOC4xLm9yaWcvZHJpdmVycy9uZXQvS2NvbmZpZyBsaW51eC0y LjYuOC4xL2RyaXZlcnMvbmV0L0tjb25maWcKLS0tIGxpbnV4LTIuNi44LjEub3JpZy9kcml2ZXJz L25ldC9LY29uZmlnCTIwMDQtMDgtMTQgMTE6NTY6MDAuMDAwMDAwMDAwICswMTAwCisrKyBsaW51 eC0yLjYuOC4xL2RyaXZlcnMvbmV0L0tjb25maWcJMjAwNC0wOS0yMCAxMToxODoxMy4wMDAwMDAw MDAgKzAxMDAKQEAgLTI0ODEsNiArMjQ4MSwxOSBAQAogCSAgd2hpY2ggY2FuIGxlYWQgdG8gYmFk IHJlc3VsdHMgaWYgdGhlIEFUTSBwZWVyIGxvc2VzIHN0YXRlIGFuZAogCSAgY2hhbmdlcyBpdHMg ZW5jYXBzdWxhdGlvbiB1bmlsYXRlcmFsbHkuCiAKK2NvbmZpZyBQUFBPTDJUUAorCXRyaXN0YXRl ICJQUFAgb3ZlciBMMlRQIChFWFBFUklNRU5UQUwpIgorCWRlcGVuZHMgb24gRVhQRVJJTUVOVEFM ICYmIFBQUAorCWhlbHAKKwkgIFN1cHBvcnQgZm9yIFBQUC1vdmVyLUwyVFAgc29ja2V0IGZhbWls eS4gTDJUUCBpcyBhIHByb3RvY29sCisJICB1c2VkIGJ5IElTUHMgYW5kIGVudGVycHJpc2VzIHRv IHR1bm5lbCBQUFAgdHJhZmZpYyBvdmVyIFVEUAorCSAgdHVubmVscy4gTDJUUCBpcyByZXBsYWNp bmcgUFBUUCBmb3IgVlBOIHVzZXMuCisKKwkgIFRoaXMga2VybmVsIGNvbXBvbmVudCBoYW5kbGVz IG9ubHkgTDJUUCBkYXRhIHBhY2tldHM6IGEKKwkgIHVzZXJsYW5kIGRhZW1vbiBoYW5kbGVzIEwy VFAgdGhlIGNvbnRyb2wgcHJvdG9jb2wgKHR1bm5lbAorCSAgYW5kIHNlc3Npb24gc2V0dXApLiBP bmUgc3VjaCBkYWVtb24gaXMgT3BlbkwyVFAKKwkgIChodHRwOi8vb3BlbmwydHAuc291cmNlZm9y Z2UubmV0LykuCisKIGNvbmZpZyBTTElQCiAJdHJpc3RhdGUgIlNMSVAgKHNlcmlhbCBsaW5lKSBz dXBwb3J0IgogCWRlcGVuZHMgb24gTkVUREVWSUNFUwpkaWZmIC1OYXVyIGxpbnV4LTIuNi44LjEu b3JpZy9kcml2ZXJzL25ldC9NYWtlZmlsZSBsaW51eC0yLjYuOC4xL2RyaXZlcnMvbmV0L01ha2Vm aWxlCi0tLSBsaW51eC0yLjYuOC4xLm9yaWcvZHJpdmVycy9uZXQvTWFrZWZpbGUJMjAwNC0wOC0x NCAxMTo1NTowOS4wMDAwMDAwMDAgKzAxMDAKKysrIGxpbnV4LTIuNi44LjEvZHJpdmVycy9uZXQv TWFrZWZpbGUJMjAwNC0wOS0yMCAxMToxNzo0Ny4wMDAwMDAwMDAgKzAxMDAKQEAgLTEwMSw2ICsx MDEsNyBAQAogb2JqLSQoQ09ORklHX1BQUF9ERUZMQVRFKSArPSBwcHBfZGVmbGF0ZS5vCiBvYmot JChDT05GSUdfUFBQX0JTRENPTVApICs9IGJzZF9jb21wLm8KIG9iai0kKENPTkZJR19QUFBPRSkg Kz0gcHBwb3gubyBwcHBvZS5vCitvYmotJChDT05GSUdfUFBQT0wyVFApICs9IHBwcG94Lm8gcHBw b2wydHAubwogCiBvYmotJChDT05GSUdfU0xJUCkgKz0gc2xpcC5vCiBpZmVxICgkKENPTkZJR19T TElQX0NPTVBSRVNTRUQpLHkpCmRpZmYgLU5hdXIgbGludXgtMi42LjguMS5vcmlnL2RyaXZlcnMv bmV0L3BwcG9sMnRwLmMgbGludXgtMi42LjguMS9kcml2ZXJzL25ldC9wcHBvbDJ0cC5jCi0tLSBs aW51eC0yLjYuOC4xLm9yaWcvZHJpdmVycy9uZXQvcHBwb2wydHAuYwkxOTcwLTAxLTAxIDAxOjAw OjAwLjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9kcml2ZXJzL25ldC9wcHBvbDJ0 cC5jCTIwMDQtMDktMjAgMTE6Mzc6NTguMDAwMDAwMDAwICswMTAwCkBAIC0wLDAgKzEsMjI3NSBA QAorLyoqIC0qLSBsaW51eC1jIC0qLSAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgorICogTGludXggUFBQIG92ZXIgTDJUUCAoUFBQb1gv UFBQb0wyVFApIFNvY2tldHMKKyAqCisgKiBQUFBvWCAgICAtLS0gR2VuZXJpYyBQUFAgZW5jYXBz dWxhdGlvbiBzb2NrZXQgZmFtaWx5CisgKiBQUFBvTDJUUCAtLS0gUFBQIG92ZXIgTDJUUCAoUkZD IDI2NjEpCisgKgorICoKKyAqIFZlcnNpb246ICAgIDAuMy4wCisgKgorICogMjUxMDAzIDoJQ29w aWVkIGZyb20gcHBwb2UuYyB2ZXJzaW9uIDAuNi45LgorICoKKyAqIEF1dGhvcjoJTWFydGlqbiB2 YW4gT29zdGVyaG91dCA8a2xlcHRvZ0BzdmFuYS5vcmc+CisgKiBDb250cmlidXRvcnM6CisgKgkJ TWljaGFsIE9zdHJvd3NraSA8bW9zdHJvd3NAc3BlYWtlYXN5Lm5ldD4KKyAqCQlBcm5hbGRvIENh cnZhbGhvIGRlIE1lbG8gPGFjbWVAeGNvbmVjdGl2YS5jb20uYnI+CisgKgkJRGF2aWQgUy4gTWls bGVyIChkYXZlbUByZWRoYXQuY29tKQorICoJCUphbWVzIENoYXBtYW4gKGpjaGFwbWFuQGthdGFs aXguY29tKQorICoKKyAqIExpY2Vuc2U6CisgKgkJVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdh cmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgorICoJCW1vZGlmeSBpdCB1bmRlciB0 aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKgkJYXMgcHVibGlz aGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uCisgKgkJ MiBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4K KyAqCisgKi8KKworLyogVGhpcyBkcml2ZXIgaGFuZGxlcyBvbmx5IEwyVFAgZGF0YSBmcmFtZXM7 IGNvbnRyb2wgZnJhbWVzIGFyZSBoYW5kbGVkIGJ5IGEKKyAqIHVzZXJzcGFjZSBhcHBsaWNhdGlv bi4KKyAqCisgKiBUbyBzZW5kIGRhdGEgaW4gYW4gTDJUUCBzZXNzaW9uLCB1c2Vyc3BhY2Ugb3Bl bnMgYSBQUFBvTDJUUCBzb2NrZXQgYW5kCisgKiBhdHRhY2hlcyBpdCB0byBhIGJvdW5kIFVEUCBz b2NrZXQgd2l0aCBsb2NhbCB0dW5uZWxfaWQgLyBzZXNzaW9uX2lkIGFuZAorICogcGVlciB0dW5u ZWxfaWQgLyBzZXNzaW9uX2lkIHNldC4gRGF0YSBjYW4gdGhlbiBiZSBzZW50IG9yIHJlY2VpdmVk IHVzaW5nCisgKiByZWd1bGFyIHNvY2tldCBzZW5kbXNnKCkgLyByZWN2bXNnKCkgY2FsbHMuIEtl cm5lbCBwYXJhbWV0ZXJzIG9mIHRoZSBzb2NrZXQKKyAqIGNhbiBiZSByZWFkIG9yIG1vZGlmaWVk IHVzaW5nIGlvY3RsKCkgb3IgW2dzXWV0c29ja29wdCgpIGNhbGxzLgorICoKKyAqIFdoZW4gYSBQ UFBvTDJUUCBzb2NrZXQgaXMgY29ubmVjdGVkIHdpdGggbG9jYWwgYW5kIHBlZXIgc2Vzc2lvbl9p ZCB2YWx1ZXMKKyAqIHplcm8sIHRoZSBzb2NrZXQgaXMgdHJlYXRlZCBhcyBhIHNwZWNpYWwgdHVu bmVsIG1hbmFnZW1lbnQgc29ja2V0LgorICoKKyAqIEhlcmUncyBleGFtcGxlIHVzZXJzcGFjZSBj b2RlIHRvIGNyZWF0ZSBhIHNvY2tldCBmb3Igc2VuZGluZy9yZWNlaXZpbmcgZGF0YQorICogb3Zl ciBhbiBMMlRQIHNlc3Npb246LQorICoKKyAqCXN0cnVjdCBzb2NrYWRkcl9wcHBvbDJ0cCBzYXg7 CisgKglpbnQgZmQ7CisgKglpbnQgc2Vzc2lvbl9mZDsKKyAqCQorICoJZmQgPSBzb2NrZXQoQUZf UFBQT1gsIFNPQ0tfREdSQU0sIFBYX1BST1RPX09MMlRQKTsKKyAqCisgKglzYXguc2FfZmFtaWx5 ID0gQUZfUFBQT1g7CisgKglzYXguc2FfcHJvdG9jb2wgPSBQWF9QUk9UT19PTDJUUDsKKyAqCXNh eC5wcHBvbDJ0cC5mZCA9IHR1bm5lbF9mZDsgLy8gYm91bmQgVURQIHNvY2tldAorICoJc2F4LnBw cG9sMnRwLmFkZHIuc2luX2FkZHIuc19hZGRyID0gYWRkci0+c2luX2FkZHIuc19hZGRyOworICoJ c2F4LnBwcG9sMnRwLmFkZHIuc2luX3BvcnQgPSBhZGRyLT5zaW5fcG9ydDsKKyAqCXNheC5wcHBv bDJ0cC5hZGRyLnNpbl9mYW1pbHkgPSBBRl9JTkVUOworICoJc2F4LnBwcG9sMnRwLnNfdHVubmVs ICA9IHR1bm5lbF9pZDsKKyAqCXNheC5wcHBvbDJ0cC5zX3Nlc3Npb24gPSBzZXNzaW9uX2lkOwor ICoJc2F4LnBwcG9sMnRwLmRfdHVubmVsICA9IHBlZXJfdHVubmVsX2lkOworICoJc2F4LnBwcG9s MnRwLmRfc2Vzc2lvbiA9IHBlZXJfc2Vzc2lvbl9pZDsKKyAqICAKKyAqCXNlc3Npb25fZmQgPSBj b25uZWN0KGZkLCAoc3RydWN0IHNvY2thZGRyICopJnNheCwgc2l6ZW9mKHNheCkpOworICoKKyAq LworCisjaW5jbHVkZSA8bGludXgvc3RyaW5nLmg+CisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+ CisjaW5jbHVkZSA8bGludXgvdmVyc2lvbi5oPgorCisjaW5jbHVkZSA8YXNtL3VhY2Nlc3MuaD4K KworI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L3NjaGVkLmg+Cisj aW5jbHVkZSA8bGludXgvc2xhYi5oPgorI2luY2x1ZGUgPGxpbnV4L2Vycm5vLmg+CisKKyNpbmNs dWRlIDxsaW51eC9uZXRkZXZpY2UuaD4KKyNpbmNsdWRlIDxsaW51eC9uZXQuaD4KKyNpbmNsdWRl IDxsaW51eC9pbmV0ZGV2aWNlLmg+CisjaW5jbHVkZSA8bGludXgvc2tidWZmLmg+CisjaW5jbHVk ZSA8bGludXgvaW5pdC5oPgorI2luY2x1ZGUgPGxpbnV4L3VkcC5oPgorI2luY2x1ZGUgPGxpbnV4 L2lmX3BwcG94Lmg+CisjaW5jbHVkZSA8bmV0L3NvY2suaD4KKyNpbmNsdWRlIDxsaW51eC9wcHBf Y2hhbm5lbC5oPgorI2luY2x1ZGUgPGxpbnV4L3BwcF9kZWZzLmg+CisjaW5jbHVkZSA8bGludXgv aWZfcHBwLmg+CisjaW5jbHVkZSA8bGludXgvZmlsZS5oPgorI2luY2x1ZGUgPGxpbnV4L2hhc2gu aD4KKyNpbmNsdWRlIDxsaW51eC9wcm9jX2ZzLmg+CisjaW5jbHVkZSA8bmV0L2RzdC5oPgorCisj aW5jbHVkZSA8YXNtL2J5dGVvcmRlci5oPgorI2luY2x1ZGUgPGFzbS9hdG9taWMuaD4KKworI2Rl ZmluZSBQUFBPTDJUUF9EUlZfVkVSU0lPTgkiVjAuNSIKKworLyogRGV2ZWxvcGVyIGRlYnVnIGNv ZGUuICovCisjaWYgMAorI2RlZmluZSBERUJVRwkvKiBEZWZpbmUgdG8gY29tcGlsZSBpbiB2ZXJ5 IHZlcmJvc2UgZGV2ZWxvcGVyIGRlYnVnICovCisjZW5kaWYKKworLyogVGltZW91dHMgYXJlIHNw ZWNpZmllZCBpbiBtaWxsaXNlY29uZHMgdG8vZnJvbSB1c2Vyc3BhY2UgKi8KKyNkZWZpbmUgSklG RklFU19UT19NUyh0KSAoKHQpICogMTAwMCAvIEhaKQorI2RlZmluZSBNU19UT19KSUZGSUVTKGop ICgoaiAqIEhaKSAvIDEwMDApCisKKy8qIEwyVFAgaGVhZGVyIGNvbnN0YW50cyAqLworI2RlZmlu ZSBMMlRQX0hEUkZMQUdfVAkgICAweDgwMDAKKyNkZWZpbmUgTDJUUF9IRFJGTEFHX0wJICAgMHg0 MDAwCisjZGVmaW5lIEwyVFBfSERSRkxBR19TCSAgIDB4MDgwMAorI2RlZmluZSBMMlRQX0hEUkZM QUdfTwkgICAweDAyMDAKKyNkZWZpbmUgTDJUUF9IRFJGTEFHX1AJICAgMHgwMTAwCisKKyNkZWZp bmUgTDJUUF9IRFJfVkVSX01BU0sgIDB4MDAwRgorI2RlZmluZSBMMlRQX0hEUl9WRVIJICAgMHgw MDAyCisKKy8qIFNwYWNlIGZvciBVRFAsIEwyVFAgYW5kIFBQUCBoZWFkZXJzLCBwbHVzIHNvbWUg c2xhY2sgKi8KKyNkZWZpbmUgUFBQT0wyVFBfSEVBREVSX09WRVJIRUFECTQwCisKKy8qIEp1c3Qg c29tZSByYW5kb20gbnVtYmVycyAqLworI2RlZmluZSBMMlRQX1RVTk5FTF9NQUdJQyAgIDB4NDIx MTREREEKKyNkZWZpbmUgTDJUUF9TRVNTSU9OX01BR0lDICAweDBDMDRFQjdECisKKyNkZWZpbmUg UFBQT0wyVFBfSEFTSF9CSVRTIDQKKyNkZWZpbmUgUFBQT0wyVFBfSEFTSF9TSVpFICgxIDw8IFBQ UE9MMlRQX0hBU0hfQklUUykKKworLyogRGVmYXVsdCB0cmFjZSBmbGFncyAqLworI2lmZGVmIERF QlVHCisjZGVmaW5lIFBQUE9MMlRQX0RFRkFVTFRfREVCVUdfRkxBR1MJLTEKKyNlbHNlCisjZGVm aW5lIFBQUE9MMlRQX0RFRkFVTFRfREVCVUdfRkxBR1MJMAorI2VuZGlmCisKKworLyogRGVidWcg a2VybmVsIG1lc3NhZ2UgY29udHJvbC4KKyAqIFZlcmJvc2UgZGVidWcgbWVzc2FnZXMgKEwyVFBf TVNHX0RFQlVHIGZsYWcpIGFyZSBvcHRpb25hbGx5IGNvbXBpbGVkIGluLgorICovCisjaWZkZWYg REVCVUcKKyNkZWZpbmUgRFBSSU5USyhfbWFzaywgX2ZtdCwgYXJncy4uLikJCQkJCVwKKwlkbyB7 CQkJCQkJCQlcCisJCWlmICgoX21hc2spICYgUFBQT0wyVFBfTVNHX0RFQlVHKQkJCVwKKwkJCXBy aW50ayhLRVJOX0RFQlVHICJQUFBPTDJUUCAlczogIiBfZm10LAkJXAorCQkJICAgICAgIF9fRlVO Q1RJT05fXywgIyNhcmdzKTsJCQlcCisJfSB3aGlsZSgwKQorI2Vsc2UKKyNkZWZpbmUgRFBSSU5U SyhfbWFzaywgc3Jncy4uLikgZG8geyB9IHdoaWxlKDApCisjZW5kaWYgLyogREVCVUcgKi8KKwor I2RlZmluZSBQUklOVEsoX21hc2ssIF90eXBlLCBfbHZsLCBfZm10LCBhcmdzLi4uKQkJCVwKKwlk byB7CQkJCQkJCQlcCisJCWlmICgoX21hc2spICYgKF90eXBlKSkJCQkJCVwKKwkJCXByaW50ayhf bHZsICJQUFBPTDJUUDogIiBfZm10LCAjI2FyZ3MpOwkJXAorCX0gd2hpbGUoMCkKKworLyogRXh0 cmEgZHJpdmVyIGRlYnVnLiBTaG91bGQgb25seSBiZSBlbmFibGVkIGJ5IGRldmVsb3BlcnMgd29y a2luZyBvbgorICogdGhpcyBkcml2ZXIuIAorICovCisjaWZkZWYgREVCVUcKKyNkZWZpbmUgRU5U RVJfRlVOQ1RJT04JIHByaW50ayhLRVJOX0RFQlVHICJQUFBPTDJUUDogLS0+ICVzXG4iLCBfX0ZV TkNUSU9OX18pCisjZGVmaW5lIEVYSVRfRlVOQ1RJT04JIHByaW50ayhLRVJOX0RFQlVHICJQUFBP TDJUUDogPC0tICVzXG4iLCBfX0ZVTkNUSU9OX18pCisjZWxzZQorI2RlZmluZSBFTlRFUl9GVU5D VElPTgkgZG8geyB9IHdoaWxlKDApCisjZGVmaW5lIEVYSVRfRlVOQ1RJT04JIGRvIHsgfSB3aGls ZSgwKQorI2VuZGlmCisKK3N0cnVjdCBwcHBvbDJ0cF90dW5uZWw7CisKKy8qIERlc2NyaWJlcyBh IHNlc3Npb24uIEl0IGlzIHRoZSBza191c2VyX2RhdGEgZmllbGQgaW4gdGhlIFBQUG9MMlRQCisg KiBzb2NrZXQuIENvbnRhaW5zIGluZm9ybWF0aW9uIHRvIGRldGVybWluZSBpbmNvbWluZyBwYWNr ZXRzIGFuZCB0cmFuc21pdAorICogb3V0Z29pbmcgb25lcy4KKyAqLworc3RydWN0IHBwcG9sMnRw X3Nlc3Npb24KK3sKKwlpbnQJCQltYWdpYzsJCS8qIHNob3VsZCBiZSAKKwkJCQkJCSAqIEwyVFBf U0VTU0lPTl9NQUdJQyAqLworCWludAkJCW93bmVyOwkJLyogcGlkIHRoYXQgb3BlbmVkIHRoZSBz b2NrZXQgKi8KKwkKKwlzdHJ1Y3Qgc29jawkJKnNvY2s7CQkvKiBQb2ludGVyIHRvIHRoZSBzZXNz aW9uCisJCQkJCQkgKiBQUFBvWCBzb2NrZXQgKi8KKwlzdHJ1Y3Qgc29jawkJKnR1bm5lbF9zb2Nr OwkvKiBQb2ludGVyIHRvIHRoZSB0dW5uZWwgVURQIAorCQkJCQkJICogc29ja2V0ICovCisJCisJ c3RydWN0IHBwcG9sMnRwX2FkZHIJdHVubmVsX2FkZHI7CS8qIERlc2NyaXB0aW9uIG9mIHR1bm5l bCAqLworCisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbAkqdHVubmVsOwkvKiBiYWNrIHBvaW50ZXIg dG8gdHVubmVsIAorCQkJCQkJICogY29udGV4dCAqLworCQorCWNoYXIJCQluYW1lWzIwXTsJLyog InNlc3MgeHh4eHgveXl5eXkiLCB3aGVyZSAKKwkJCQkJCSAqIHg9dHVubmVsX2lkLCB5PXNlc3Np b25faWQgKi8KKwlpbnQJCQltdHU7CisJaW50CQkJbXJ1OworCWludAkJCWZsYWdzOwkJLyogYWNj ZXNzZWQgYnkgUFBQSU9DR0ZMQUdTLiAKKwkJCQkJCSAqIFVudXNlZC4gKi8KKwlpbnQJCQlyZWN2 X3NlcToxOwkvKiBleHBlY3QgcmVjZWl2ZSBwYWNrZXRzIHdpdGggCisJCQkJCQkgKiBzZXF1ZW5j ZSBudW1iZXJzPyAqLworCWludAkJCXNlbmRfc2VxOjE7CS8qIHNlbmQgcGFja2V0cyB3aXRoIHNl cXVlbmNlIAorCQkJCQkJICogbnVtYmVycz8gKi8KKwlpbnQJCQlsbnNfbW9kZToxOwkvKiBiZWhh dmUgYXMgTE5TPyBMQUMgZW5hYmxlcyAKKwkJCQkJCSAqIHNlcXVlbmNlIG51bWJlcnMgdW5kZXIg CisJCQkJCQkgKiBjb250cm9sIG9mIExOUy4gKi8KKwlpbnQJCQlkZWJ1ZzsJCS8qIGJpdG1hc2sg b2YgZGVidWcgbWVzc2FnZSAKKwkJCQkJCSAqIGNhdGVnb3JpZXMgKi8KKwlpbnQJCQlyZW9yZGVy X3RpbWVvdXQ7IC8qIGNvbmZpZ3VyZWQgcmVvcmRlciB0aW1lb3V0IAorCQkJCQkJICAqIChpbiBq aWZmaWVzKSAqLworCXUxNgkJCW5yOwkJLyogc2Vzc2lvbiBOUiBzdGF0ZSAocmVjZWl2ZSkgKi8K Kwl1MTYJCQluczsJCS8qIHNlc3Npb24gTlIgc3RhdGUgKHNlbmQpICovCisJc3RydWN0IHBwcG9s MnRwX2lvY19zdGF0cyBzdGF0czsKKwlzdHJ1Y3QgaGxpc3Rfbm9kZQlobGlzdDsJCS8qIEhhc2gg bGlzdCBub2RlICovCit9OworCisvKiBUaGUgc2tfdXNlcl9kYXRhIGZpZWxkIG9mIHRoZSB0dW5u ZWwncyBVRFAgc29ja2V0LiBJdCBjb250YWlucyBpbmZvIHRvIHRyYWNrCisgKiBhbGwgdGhlIGFz c29jaWF0ZWQgc2Vzc2lvbnMgc28gaW5jb21pbmcgcGFja2V0cyBjYW4gYmUgc29ydGVkIG91dAor ICovCitzdHJ1Y3QgcHBwb2wydHBfdHVubmVsCit7CisJaW50CQkJbWFnaWM7CQkvKiBTaG91bGQg YmUgTDJUUF9UVU5ORUxfTUFHSUMgKi8KKwkKKwlzdHJ1Y3QgcHJvdG8JCW9sZF9wcm90bzsJLyog b3JpZ2luYWwgcHJvdG8gKi8KKwlzdHJ1Y3QgcHJvdG8JCWwydHBfcHJvdG87CS8qIEwyVFAgcHJv dG8gKi8KKwlyd2xvY2tfdAkJaGxpc3RfbG9jazsJLyogcHJvdGVjdCBzZXNzaW9uX2hsaXN0ICov CisJc3RydWN0IGhsaXN0X2hlYWQJc2Vzc2lvbl9obGlzdFtQUFBPTDJUUF9IQVNIX1NJWkVdOyAK KwkJCQkJCS8qIGhhc2hlZCBsaXN0IG9mIHNlc3Npb25zLCAKKwkJCQkJCSAqIGhhc2hlZCBieSBp ZCAqLworCWludAkJCWRlYnVnOwkJLyogYml0bWFzayBvZiBkZWJ1ZyBtZXNzYWdlIAorCQkJCQkJ ICogY2F0ZWdvcmllcyAqLworCWNoYXIJCQluYW1lWzEyXTsJLyogInR1bmwgeHh4eHgiICovCisJ c3RydWN0IHBwcG9sMnRwX2lvY19zdGF0cyBzdGF0czsKKwkKKwl2b2lkICgqb2xkX2RhdGFfcmVh ZHkpKHN0cnVjdCBzb2NrICosIGludCk7CisJdm9pZCAoKm9sZF9za19kZXN0cnVjdCkoc3RydWN0 IHNvY2sgKik7CisKKwlzdHJ1Y3Qgc29jawkJKnNvY2s7CQkvKiBQYXJlbnQgc29ja2V0ICovCQor CXN0cnVjdCBsaXN0X2hlYWQJbGlzdDsJCS8qIEtlZXAgYSBsaXN0IG9mIGFsbCBvcGVuIAorCQkJ CQkJICogcHJlcGFyZWQgc29ja2V0cyAqLworCisJYXRvbWljX3QJCXNlc3Npb25fY291bnQ7Cit9 OworCisvKiBOdW1iZXIgb2YgYnl0ZXMgdG8gYnVpbGQgdHJhbnNtaXQgTDJUUCBoZWFkZXJzLgor ICogVW5mb3J0dW5hdGVseSB0aGUgc2l6ZSBpcyBkaWZmZXJlbnQgZGVwZW5kaW5nIG9uIHdoZXRo ZXIgc2VxdWVuY2UgbnVtYmVycworICogYXJlIGVuYWJsZWQuCisgKi8KKyNkZWZpbmUgUFBQT0wy VFBfTDJUUF9IRFJfU0laRV9TRVEJCTEwCisjZGVmaW5lIFBQUE9MMlRQX0wyVFBfSERSX1NJWkVf Tk9TRVEJCTYKKworCitzdGF0aWMgaW50IHBwcG9sMnRwX3htaXQoc3RydWN0IHBwcF9jaGFubmVs ICpjaGFuLCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiKTsKKworc3RhdGljIHN0cnVjdCBwcHBfY2hhbm5l bF9vcHMgcHBwb2wydHBfY2hhbl9vcHMgPSB7IHBwcG9sMnRwX3htaXQgLCBOVUxMIH07CitzdGF0 aWMgc3RydWN0IHByb3RvX29wcyBwcHBvbDJ0cF9vcHM7CitzdGF0aWMgTElTVF9IRUFEKHBwcG9s MnRwX3R1bm5lbF9saXN0KTsKKworLyogTWFjcm9zIHRvIGRlcml2ZSBzZXNzaW9uL3R1bm5lbCBj b250ZXh0IHBvaW50ZXJzIGZyb20gYSBzb2NrZXQuICovCisjZGVmaW5lIFNPQ0tfMl9TRVNTSU9O KHNvY2ssIHNlc3Npb24sIGVyciwgZXJydmFsLCBsYWJlbCwgcXVpZXQpIFwKKwlzZXNzaW9uID0g KHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICopKChzb2NrKS0+c2tfdXNlcl9kYXRhKTsgIFwKKwlp ZiAoIXNlc3Npb24gfHwgc2Vzc2lvbi0+bWFnaWMgIT0gTDJUUF9TRVNTSU9OX01BR0lDKSB7CSAg ICAgICBcCisJCWlmICghcXVpZXQpIFwKKwkJCXByaW50ayhLRVJOX0VSUiAiJXM6ICVzOiVkOiBC QUQgU0VTU0lPTiBNQUdJQyAiIFwKKwkJCSAgICAgICAiKCIgI3NvY2sgIj0lcCkgc2Vzc2lvbj0l cCBtYWdpYz0leFxuIiwgXAorCQkJICAgICAgIF9fRlVOQ1RJT05fXywgX19GSUxFX18sIF9fTElO RV9fLCBzb2NrLCBcCisJCQkgICAgICAgc2Vzc2lvbiwgc2Vzc2lvbiA/IHNlc3Npb24tPm1hZ2lj IDogMCk7IFwKKwkJZXJyID0gZXJydmFsOyBcCisJCWdvdG8gbGFiZWw7IFwKKwl9CisJCisjZGVm aW5lIFNPQ0tfMl9UVU5ORUwoc29jaywgdHVubmVsLCBlcnIsIGVycnZhbCwgbGFiZWwsIHF1aWV0 KSBcCisJdHVubmVsID0gKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKikoKHNvY2spLT5za191c2Vy X2RhdGEpOwkgXAorCWlmICghdHVubmVsIHx8IHR1bm5lbC0+bWFnaWMgIT0gTDJUUF9UVU5ORUxf TUFHSUMpIHsJICAgICBcCisJCWlmICghcXVpZXQpIFwKKwkJCXByaW50ayhLRVJOX0VSUiAiJXM6 ICVzOiVkOiBCQUQgVFVOTkVMIE1BR0lDICIgXAorCQkJICAgICAgICIoIiAjc29jayAiPSVwKSB0 dW5uZWw9JXAgbWFnaWM9JXhcbiIsIFwKKwkJCSAgICAgICBfX0ZVTkNUSU9OX18sIF9fRklMRV9f LCBfX0xJTkVfXywgc29jaywgXAorCQkJICAgICAgIHR1bm5lbCwgdHVubmVsID8gdHVubmVsLT5t YWdpYyA6IDApOyBcCisJCWVyciA9IGVycnZhbDsgXAorCQlnb3RvIGxhYmVsOyBcCisJfQorCisv KiBTZXNzaW9uIGhhc2ggbGlzdC4KKyAqIFRoZSBzZXNzaW9uX2lkIFNIT1VMRCBiZSByYW5kb20g YWNjb3JkaW5nIHRvIFJGQzI2NjEsIGJ1dCBzZXZlcmFsCisgKiBMMlRQIGltcGxlbWVudGF0aW9u cyAoQ2lzY28gYW5kIE1pY3Jvc29mdCkgdXNlIGluY3JlbWVudGluZworICogc2Vzc2lvbl9pZHMu ICBTbyB3ZSBkbyBhIHJlYWwgaGFzaCBvbiB0aGUgc2Vzc2lvbl9pZCwgcmF0aGVyIHRoYW4gYQor ICogc2ltcGxlIGJpdG1hc2suCisgKi8KK3N0YXRpYyBpbmxpbmUgc3RydWN0IGhsaXN0X2hlYWQg KgorcHBwb2wydHBfc2Vzc2lvbl9pZF9oYXNoKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5l bCwgdTE2IHNlc3Npb25faWQpCit7CisJdW5zaWduZWQgbG9uZyBoYXNoX3ZhbCA9ICh1bnNpZ25l ZCBsb25nKSBzZXNzaW9uX2lkOworCXJldHVybiAmdHVubmVsLT5zZXNzaW9uX2hsaXN0W2hhc2hf bG9uZyhoYXNoX3ZhbCwgUFBQT0wyVFBfSEFTSF9CSVRTKV07Cit9CisKKy8qIExvb2t1cCBhIHNl c3Npb24gYnkgaWQKKyAqLworc3RhdGljIHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICoKK3BwcG9s MnRwX3Nlc3Npb25fZmluZChzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWwsIHUxNiBzZXNz aW9uX2lkKQoreworCXN0cnVjdCBobGlzdF9oZWFkICpzZXNzaW9uX2xpc3QgPSAKKwkJcHBwb2wy dHBfc2Vzc2lvbl9pZF9oYXNoKHR1bm5lbCwgc2Vzc2lvbl9pZCk7CisJc3RydWN0IGhsaXN0X25v ZGUgKnRtcDsKKwlzdHJ1Y3QgaGxpc3Rfbm9kZSAqd2FsazsKKwlzdHJ1Y3QgcHBwb2wydHBfc2Vz c2lvbiAqc2Vzc2lvbjsKKworCWhsaXN0X2Zvcl9lYWNoX3NhZmUod2FsaywgdG1wLCBzZXNzaW9u X2xpc3QpIHsKKwkJc2Vzc2lvbiA9IGhsaXN0X2VudHJ5KHdhbGssIHN0cnVjdCBwcHBvbDJ0cF9z ZXNzaW9uLCBobGlzdCk7CisJCWlmIChzZXNzaW9uLT50dW5uZWxfYWRkci5zX3Nlc3Npb24gPT0g c2Vzc2lvbl9pZCkgeworCQkJcmV0dXJuIHNlc3Npb247CisJCX0KKwl9CisKKwlyZXR1cm4gTlVM TDsKK30KKworLyogRWFzeSB3YXkgdG8gbG9jYXRlIGZlYXR1cmVzIG5vdCB5ZXQgaW1wbGVtZW50 ZWQgCisgKi8KK3N0YXRpYyB2b2lkIHBwcG9sMnRwX3dhcm5fbm90X3lldF9pbXBsZW1lbnRlZChp bnQgZGVidWdfbWFzaywgY29uc3QgY2hhciAqd2hhdCkKK3sKKwlQUklOVEsoZGVidWdfbWFzaywg UFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fV0FSTklORywgCisJICAgICAgICJmZWF0dXJlICVz IG5vdCB5ZXQgaW1wbGVtZW50ZWRcbiIsIHdoYXQpOworfQorCisvKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKKyAqIFJlY2VpdmUgZGF0YSBoYW5kbGluZworICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworCisv KiBJbnRlcm5hbCByZWNlaXZlIGZyYW1lLiBEbyB0aGUgcmVhbCB3b3JrIG9mIHJlY2VpdmluZyBh biBMMlRQIGRhdGEgZnJhbWUKKyAqIGhlcmUuCisgKiBSZXR1cm5zIDAgaWYgdGhlIHBhY2tldCB3 YXMgYSBkYXRhIHBhY2tldCBhbmQgd2FzIHN1Y2Nlc3NmdWxseSBwYXNzZWQgb24uCisgKiBSZXR1 cm5zIDEgaWYgdGhlIHBhY2tldCB3YXMgbm90IGEgZ29vZCBkYXRhIHBhY2tldCBhbmQgY291bGQg bm90IGJlCisgKiBmb3J3YXJkZWQuICBBbGwgc3VjaCBwYWNrZXRzIGFyZSBwYXNzZWQgdXAgdG8g dXNlcnNwYWNlIHRvIGRlYWwgd2l0aC4KKyAqLworc3RhdGljIGludCBwcHBvbDJ0cF9yZWN2X2Nv cmUoc3RydWN0IHNvY2sgKnNvY2ssIHN0cnVjdCBza19idWZmICpza2IpCit7CisJc3RydWN0IHBw cG94X29wdCAqcG87CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24gPSBOVUxMOwor CWludCBlcnJvciA9IDA7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCXN0cnVj dCBzb2NrICpzZXNzaW9uX3NvY2sgPSBOVUxMOworCXVuc2lnbmVkIGNoYXIgKnB0cjsKKwl1MTYg aGRyZmxhZ3M7CisJdTE2IHR1bm5lbF9pZCwgc2Vzc2lvbl9pZDsKKwlpbnQgbGVuZ3RoOworCWlu dCByZXN1bHQ7CisKKwlFTlRFUl9GVU5DVElPTjsKKworCVNPQ0tfMl9UVU5ORUwoc29jaywgdHVu bmVsLCBlcnJvciwgMSwgZW5kLCAwKTsKKworCS8qIFNob3J0IHBhY2tldD8gKi8KKwlpZiAoc2ti LT5sZW4gPCBzaXplb2Yoc3RydWN0IHVkcGhkcikpIHsKKwkJUFJJTlRLKHR1bm5lbC0+ZGVidWcs IFBQUE9MMlRQX01TR19EQVRBLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiByZWN2IHNob3J0 IHBhY2tldCAobGVuPSVkKVxuIiwgdHVubmVsLT5uYW1lLCBza2ItPmxlbik7CisJCWdvdG8gZW5k OworCX0KKworCS8qIFBvaW50IHRvIEwyVFAgaGVhZGVyICovCisJcHRyID0gc2tiLT5kYXRhICsg c2l6ZW9mKHN0cnVjdCB1ZHBoZHIpOworCisJLyogR2V0IEwyVFAgaGVhZGVyIGZsYWdzICovCisJ aGRyZmxhZ3MgPSBudG9ocygqKHUxNiopcHRyKTsKKworCS8qIFRyYWNlIHBhY2tldCBjb250ZW50 cywgaWYgZW5hYmxlZCAqLworCWlmICh0dW5uZWwtPmRlYnVnICYgUFBQT0wyVFBfTVNHX0RBVEEp IHsKKwkJcHJpbnRrKEtFUk5fREVCVUcgIiVzOiByZWN2OiAiIEtFUk5fREVCVUcsIHR1bm5lbC0+ bmFtZSk7CisKKwkJZm9yIChsZW5ndGggPSAwOyBsZW5ndGggPCAxNjsgbGVuZ3RoKyspCisJCQlw cmludGsoIiAlMDJYIiwgcHRyW2xlbmd0aF0pOworCQlwcmludGsoIlxuIik7CisJfQorCisJLyog R2V0IGxlbmd0aCBvZiBMMlRQIHBhY2tldCAqLworCWxlbmd0aCA9IG50b2hzKHNrYi0+aC51aC0+ bGVuKSAtIHNpemVvZihzdHJ1Y3QgdWRwaGRyKTsKKwkKKwkvKiBUb28gc2hvcnQ/ICovCisJaWYg KGxlbmd0aCA8IDEyKSB7CisJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQUFBPTDJUUF9NU0dfREFU QSwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogcmVjdiBzaG9ydCBMMlRQIHBhY2tldCAobGVu PSVkKVxuIiwgdHVubmVsLT5uYW1lLCBsZW5ndGgpOworCQlnb3RvIGVuZDsKKwl9CisJCisJLyog SWYgdHlwZSBpcyBjb250cm9sIHBhY2tldCwgaXQgaXMgaGFuZGxlZCBieSB1c2Vyc3BhY2UuICov CisJaWYgKGhkcmZsYWdzICYgTDJUUF9IRFJGTEFHX1QpIHsgCisJCVBSSU5USyh0dW5uZWwtPmRl YnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6IHJlY3Yg Y29udHJvbCBwYWNrZXQsIGxlbj0lZFxuIiwgdHVubmVsLT5uYW1lLCBsZW5ndGgpOworCQlnb3Rv IGVuZDsKKwl9CisKKwkvKiBTa2lwIGZsYWdzICovCisJcHRyICs9IDI7CisJCisJLyogSWYgbGVu Z3RoIGlzIHByZXNlbnQsIHNraXAgaXQgKi8KKwlpZiAoaGRyZmxhZ3MgJiBMMlRQX0hEUkZMQUdf TCkKKwkJcHRyICs9IDI7CisKKwkvKiBFeHRyYWN0IHR1bm5lbCBhbmQgc2Vzc2lvbiBJRCAqLwor CXR1bm5lbF9pZCA9IG50b2hzKCoodTE2ICopIHB0cik7CisJcHRyICs9IDI7CisJc2Vzc2lvbl9p ZCA9IG50b2hzKCoodTE2ICopIHB0cik7CisJcHRyICs9IDI7CisKKwkvKiBGaW5kIHRoZSBzZXNz aW9uIGNvbnRleHQgKi8KKwlzZXNzaW9uID0gcHBwb2wydHBfc2Vzc2lvbl9maW5kKHR1bm5lbCwg c2Vzc2lvbl9pZCk7CisJaWYgKCFzZXNzaW9uKSB7CisJCS8qIE5vdCBmb3VuZD8gUGFzcyB0byB1 c2Vyc3BhY2UgdG8gZGVhbCB3aXRoICovCisJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQUFBPTDJU UF9NU0dfREFUQSwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogbm8gc29ja2V0IGZvdW5kICgl aHUvJWh1KS4gUGFzc2luZyB1cC5cbiIsIAorCQkgICAgICAgdHVubmVsLT5uYW1lLCB0dW5uZWxf aWQsIHNlc3Npb25faWQpOworCQlnb3RvIGVuZDsKKwl9CisJc29ja19ob2xkKHNlc3Npb24tPnNv Y2spOworCisJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgIiVzOiBzb2NrZXQgcmN2YnVmIGFsbG9j PSVkXG4iLCAKKwkJc2Vzc2lvbi0+bmFtZSwgYXRvbWljX3JlYWQoJnNvY2stPnNrX3JtZW1fYWxs b2MpKTsKKworCS8qIFRoZSByZWYgY291bnQgb24gdGhlIHNvY2tldCB3YXMgaW5jcmVhc2VkIGJ5 IHRoZSBhYm92ZSBjYWxsIHNpbmNlCisJICogd2Ugbm93IGhvbGQgYSBwb2ludGVyIHRvIHRoZSBz ZXNzaW9uLiBUYWtlIGNhcmUgdG8gZG8gc29ja19wdXQoKQorCSAqIHdoZW4gZXhpdGluZyB0aGlz IGZ1bmN0aW9uIGZyb20gbm93IG9uLi4uCisJICovCisKKwkvKiBIYW5kbGUgdGhlIG9wdGlvbmFs IHNlcXVlbmNlIG51bWJlcnMuICBJZiB3ZSBhcmUgdGhlIExBQywKKwkgKiBlbmFibGUvZGlzYWJs ZSBzZXF1ZW5jZSBudW1iZXJzIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBMTlMuICBJZgorCSAq IG5vIHNlcXVlbmNlIG51bWJlcnMgcHJlc2VudCBidXQgd2Ugd2VyZSBleHBlY3RpbmcgdGhlbSwg ZGlzY2FyZAorCSAqIGZyYW1lLgorCSAqLworCWlmIChoZHJmbGFncyAmIEwyVFBfSERSRkxBR19T KSB7CisJCXUxNiBucywgbnI7CisJCW5zID0gbnRvaHMoKih1MTYgKikgcHRyKTsKKwkJcHRyICs9 IDI7CisJCW5yID0gbnRvaHMoKih1MTYgKikgcHRyKTsKKwkJcHRyICs9IDI7CisKKwkJLyogUmVj ZWl2ZWQgYSBwYWNrZXQgd2l0aCBzZXF1ZW5jZSBudW1iZXJzLiBJZiB3ZSdyZSB0aGUgTE5TLAor CQkgKiBjaGVjayBpZiB3ZSBzcmUgc2VuZGluZyBzZXF1ZW5jZSBudW1iZXJzIGFuZCBpZiBub3Qs CisJCSAqIGNvbmZpZ3VyZSBpdCBzby4KKwkJICovCisJCWlmICgoIXNlc3Npb24tPmxuc19tb2Rl KSAmJiAoIXNlc3Npb24tPnNlbmRfc2VxKSkgeworCQkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQ UFBPTDJUUF9NU0dfU0VRLCBLRVJOX0lORk8sIAorCQkJICAgICAgICIlczogcmVxdWVzdGVkIHRv IGVuYWJsZSBzZXEgbnVtYmVycyBieSBMTlNcbiIsIAorCQkJICAgICAgIHNlc3Npb24tPm5hbWUp OworCQkJc2Vzc2lvbi0+c2VuZF9zZXEgPSAtMTsKKwkJfQorCisJCVBSSU5USyhzZXNzaW9uLT5k ZWJ1ZywgUFBQT0wyVFBfTVNHX1NFUSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6IHJlY3Yg ZGF0YSBucz0laHUsIG5yPSVodSwgc2Vzc2lvbiBucj0laHVcbiIsIAorCQkgICAgICAgc2Vzc2lv bi0+bmFtZSwgbnMsIG5yLCBzZXNzaW9uLT5ucik7CisKKwkJLyogRGlzY2FyZCBvdXQtb2Ytc2Vx dWVuY2UgcGFja2V0cyAqLworCQlpZiAobnMgIT0gc2Vzc2lvbi0+bnIpIHsKKwkJCXNlc3Npb24t PnN0YXRzLnJ4X29vc19wYWNrZXRzKys7CisJCQlzZXNzaW9uLT5zdGF0cy5yeF9lcnJvcnMrKzsK KwkJCWdvdG8gZGlzY2FyZDsKKwkJfQorCisJCS8qIEJ1bXAgb3VyIE5yICovCisJCXNlc3Npb24t Pm5yKys7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX1NFUSwgS0VSTl9E RUJVRywgCisJCSAgICAgICAiJXM6IHVwZGF0ZWQgbnIgdG8gJWh1XG4iLCBzZXNzaW9uLT5uYW1l LCBzZXNzaW9uLT5ucik7CisJfSBlbHNlIHsKKwkJLyogTm8gc2VxdWVuY2UgbnVtYmVycy4KKwkJ ICogSWYgdXNlciBoYXMgY29uZmlndXJlZCBtYW5kYXRvcnkgc2VxdWVuY2UgbnVtYmVycywgZGlz Y2FyZC4KKwkJICovCisJCWlmIChzZXNzaW9uLT5yZWN2X3NlcSkgeworCQkJUFJJTlRLKHNlc3Np b24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfU0VRLCBLRVJOX1dBUk5JTkcsIAorCQkJICAgICAgICIl czogcmVjdiBkYXRhIGhhcyBubyBzZXEgbnVtYmVycyB3aGVuIHJlcXVpcmVkLiAiCisJCQkgICAg ICAgIkRpc2NhcmRpbmdcbiIsIHNlc3Npb24tPm5hbWUpOworCQkJc2Vzc2lvbi0+c3RhdHMucnhf c2VxX2Rpc2NhcmRzKys7CisJCQlzZXNzaW9uLT5zdGF0cy5yeF9lcnJvcnMrKzsKKwkJCWdvdG8g ZGlzY2FyZDsKKwkJfQorCisJCS8qIElmIHdlJ3JlIHRoZSBMQUMgYW5kIHdlJ3JlIHNlbmRpbmcg c2VxdWVuY2UgbnVtYmVycywgdGhlCisJCSAqIExOUyBoYXMgcmVxdWVzdGVkIHRoYXQgd2Ugbm8g bG9uZ2VyIHNlbmQgc2VxdWVuY2UgbnVtYmVycy4KKwkJICogSWYgd2UncmUgdGhlIExOUyBhbmQg d2UncmUgc2VuZGluZyBzZXF1ZW5jZSBudW1iZXJzLCB0aGUKKwkJICogTEFDIGlzIGJyb2tlbi4g RGlzY2FyZCB0aGUgZnJhbWUuCisJCSAqLworCQlpZiAoKCFzZXNzaW9uLT5sbnNfbW9kZSkgJiYg KHNlc3Npb24tPnNlbmRfc2VxKSkgeworCQkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJU UF9NU0dfU0VRLCBLRVJOX0lORk8sIAorCQkJICAgICAgICIlczogcmVxdWVzdGVkIHRvIGRpc2Fi bGUgc2VxIG51bWJlcnMgYnkgTE5TXG4iLCAKKwkJCSAgICAgICBzZXNzaW9uLT5uYW1lKTsKKwkJ CXNlc3Npb24tPnNlbmRfc2VxID0gMDsKKwkJfSBlbHNlIGlmIChzZXNzaW9uLT5zZW5kX3NlcSkg eworCQkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfU0VRLCBLRVJOX1dBUk5J TkcsIAorCQkJICAgICAgICIlczogcmVjdiBkYXRhIGhhcyBubyBzZXEgbnVtYmVycyB3aGVuIHJl cXVpcmVkLiAiCisJCQkgICAgICAgIkRpc2NhcmRpbmdcbiIsIHNlc3Npb24tPm5hbWUpOworCQkJ c2Vzc2lvbi0+c3RhdHMucnhfc2VxX2Rpc2NhcmRzKys7CisJCQlzZXNzaW9uLT5zdGF0cy5yeF9l cnJvcnMrKzsKKwkJCWdvdG8gZGlzY2FyZDsKKwkJfQorCX0KKwkJCisJLyogSWYgb2Zmc2V0IGJp dCBzZXQsIHNraXAgaXQuICovCisJaWYgKGhkcmZsYWdzICYgTDJUUF9IRFJGTEFHX08pCisJCXB0 ciArPSAyICsgbnRvaHMoKih1MTYgKikgcHRyKTsKKworCXNrYl9wdWxsKHNrYiwgcHRyIC0gc2ti LT5kYXRhKTsKKworCS8qIFNraXAgUFBQIGhlYWRlciwgaWYgcHJlc2VudC4JIEluIHRlc3Rpbmcs IE1pY3Jvc29mdCBMMlRQIGNsaWVudHMKKwkgKiBkb24ndCBzZW5kIHRoZSBQUFAgaGVhZGVyIChQ UFAgaGVhZGVyIGNvbXByZXNzaW9uIGVuYWJsZWQpLCBidXQKKwkgKiBvdGhlciBjbGllbnRzIGNh biBpbmNsdWRlIHRoZSBoZWFkZXIuIFNvIHdlIGNvcGUgd2l0aCBib3RoIGNhc2VzCisJICogaGVy ZS4gVGhlIFBQUCBoZWFkZXIgaXMgYWx3YXlzIEZGMDMgd2hlbiB1c2luZyBMMlRQLgorCSAqCisJ ICogTm90ZSB0aGF0IHNrYi0+ZGF0YVtdIGlzbid0IGRlcmVmZXJlbmNlZCBmcm9tIGEgdTE2IHB0 ciBoZXJlIHNpbmNlCisJICogdGhlIGZpZWxkIG1heSBiZSB1bmFsaWduZWQuCisJICovCisJaWYg KChza2ItPmRhdGFbMF0gPT0gMHhmZikgJiYgKHNrYi0+ZGF0YVsxXSA9PSAweDAzKSkKKwkJc2ti X3B1bGwoc2tiLCAyKTsKKworCS8qIFdlJ3JlIGFib3V0IHRvIHJlcXVldWUgdGhlIHNrYiwgc28g dW5saW5rIGl0IGFuZCByZXR1cm4gcmVzb3VyY2VzCisJICogdG8gaXRzIGN1cnJlbnQgb3duZXIg KGEgc29ja2V0IHJlY2VpdmUgYnVmZmVyKS4gQWxzbyByZWxlYXNlIHRoZQorCSAqIGRzdCB0byBm b3JjZSBhIHJvdXRlIGxvb2t1cCBvbiB0aGUgaW5uZXIgSVAgcGFja2V0IHNpbmNlIHNrYi0+ZHN0 CisJICogY3VycmVudGx5IHBvaW50cyB0byB0aGUgZHN0IG9mIHRoZSBVRFAgdHVubmVsLgorCSAq LworCXNrYl91bmxpbmsoc2tiKTsKKwlza2Jfb3JwaGFuKHNrYik7CisJZHN0X3JlbGVhc2Uoc2ti LT5kc3QpOworCXNrYi0+ZHN0ID0gTlVMTDsKKworCXR1bm5lbC0+c3RhdHMucnhfcGFja2V0cysr OworCXR1bm5lbC0+c3RhdHMucnhfYnl0ZXMgKz0gbGVuZ3RoOworCXNlc3Npb24tPnN0YXRzLnJ4 X3BhY2tldHMrKzsKKwlzZXNzaW9uLT5zdGF0cy5yeF9ieXRlcyArPSBsZW5ndGg7CisKKwkvKiBJ ZiB0aGUgc29ja2V0IGlzIGJvdW5kLCBzZW5kIGl0IGluIHRvIFBQUCdzIGlucHV0IHF1ZXVlLiAg T3RoZXJ3aXNlCisJICogcXVldWUgaXQgb24gdGhlIHNvY2tldC4KKwkgKi8KKwlzZXNzaW9uX3Nv Y2sgPSBzZXNzaW9uLT5zb2NrOworCWlmIChzZXNzaW9uX3NvY2stPnNrX3N0YXRlICYgUFBQT1hf Qk9VTkQpIHsKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VS Tl9ERUJVRywgCisJCSAgICAgICAiJXM6IHJlY3YgJWQgYnl0ZSBkYXRhIGZyYW1lLCBwYXNzaW5n IHRvIHBwcFxuIiwgCisJCSAgICAgICBzZXNzaW9uLT5uYW1lLCBsZW5ndGgpOworCQlwbyA9IHBw cG94X3NrKHNlc3Npb25fc29jayk7CisJCXBwcF9pbnB1dCgmcG8tPmNoYW4sIHNrYik7CisJfSBl bHNlIHsKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9J TkZPLCAKKwkJICAgICAgICIlczogc29ja2V0IG5vdCBib3VuZFxuIiwgc2Vzc2lvbi0+bmFtZSk7 CisJCS8qIE5vdCBib3VuZC4gUXVldWUgaXQgbm93ICovCisJCXNvY2tfcXVldWVfcmN2X3NrYihz ZXNzaW9uX3NvY2ssIHNrYik7CisJfQorCisJcmVzdWx0ID0gMDsKKworb3V0OgorCURQUklOVEso c2Vzc2lvbi0+ZGVidWcsICJjYWxsaW5nIHNvY2tfcHV0OyByZWZjbnQ9JWRcbiIsIAorCQlzZXNz aW9uLT5zb2NrLT5za19yZWZjbnQuY291bnRlcik7CisJc29ja19wdXQoc2Vzc2lvbi0+c29jayk7 CisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm4gcmVzdWx0OworCitkaXNjYXJkOgorCURQUklOVEso c2Vzc2lvbi0+ZGVidWcsICJkaXNjYXJkaW5nIHNrYiwgbGVuPSVkXG4iLCBza2ItPmxlbik7CisJ c2tiX3VubGluayhza2IpOworCWtmcmVlX3NrYihza2IpOworCXJlc3VsdCA9IDA7CisJZ290byBv dXQ7CisKK2VuZDoKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiAxOworfQorCisvKiBUaGUgZGF0 YV9yZWFkeSBob29rIG9uIHRoZSBVRFAgc29ja2V0LiBTY2FuIHRoZSBpbmNvbWluZyBwYWNrZXQg bGlzdCBmb3IKKyAqIHBhY2tldHMgdG8gcHJvY2VzcworICovCitzdGF0aWMgdm9pZCBwcHBvbDJ0 cF9kYXRhX3JlYWR5KHN0cnVjdCBzb2NrICpzaywgaW50IGxlbikKK3sKKwlpbnQgZXJyOworCXN0 cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbDsKKwlzdHJ1Y3Qgc2tfYnVmZiAqc2tiOworCWlu dCBwcm9jZXNzZWQgPSAwOworCQorCUVOVEVSX0ZVTkNUSU9OOworCVNPQ0tfMl9UVU5ORUwoc2ss IHR1bm5lbCwgZXJyLCAtRUJBREYsIGVuZCwgMCk7CisJCisJUFJJTlRLKHR1bm5lbC0+ZGVidWcs IFBQUE9MMlRQX01TR19EQVRBLCBLRVJOX0RFQlVHLCAKKwkgICAgICAgIiVzOiByZWNlaXZlZCAl ZCBieXRlc1xuIiwgdHVubmVsLT5uYW1lLCBsZW4pOworCQorCS8qIEZJWE1FOiBEbyB3ZSBuZWVk IHRvIGxvY2sgdGhlIHNvY2tldCBoZXJlPyAqLworCXNrYl9xdWV1ZV93YWxrKCZzay0+c2tfcmVj ZWl2ZV9xdWV1ZSwgc2tiKSB7CisJCWlmIChwcHBvbDJ0cF9yZWN2X2NvcmUoc2ssIHNrYikpIHsK KwkJCS8qIHNrYiB3YXMgcGFzc2VkIHRvIHVzZXJzcGFjZSAqLworCQkJcHJvY2Vzc2VkID0gMTsK KwkJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywg CisJCQkgICAgICAgIiVzOiBwYWNrZXQgcGFzc2VkIHRvIHVzZXJzcGFjZVxuIiwgCisJCQkgICAg ICAgdHVubmVsLT5uYW1lKTsKKwkJfSBlbHNlIHsKKwkJCVBSSU5USyh0dW5uZWwtPmRlYnVnLCBQ UFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywgCisJCQkgICAgICAgIiVzOiBkYXRhIHBhY2tl dCBhY2NlcHRlZFxuIiwgdHVubmVsLT5uYW1lKTsKKwkJCS8qIElmIHRoZSBwYWNrZXQgaGFzIGJl ZW4gYWNjZXB0ZWQgaXQgaXMgdGhlCisJCQkgKiByZXNwb25zaWJpbGl0eSBvZiB0aGUgcmVjZWl2 ZXIgKGVpdGhlciBzb2NrZXQgb3IKKwkJCSAqIHBwcCBkZXZpY2UpIHRvIGRpc3Bvc2Ugb2YgaXQu CisJCQkgKgorCQkJICogQWxzbywgc2luY2UgcmVjdl9jb3JlIGhhcyByZXF1ZXVlZCB0aGUgcGFj a2V0CisJCQkgKiBlbHNld2hlcmUsIGl0J3Mgbm90IHNhZmUgdG8gY29udGludWUgdGhpcyBsb29w LCBzbworCQkJICogd2UgYnJlYWsKKwkJCSAqLworCQkJYnJlYWs7CisJCX0KKwl9CisJaWYgKHBy b2Nlc3NlZCkgeworCQlEUFJJTlRLKHR1bm5lbC0+ZGVidWcsICIlczogY2FsbGluZyBvbGQgb2xk X2RhdGFfcmVhZHlcbiIsIAorCQkJdHVubmVsLT5uYW1lKTsKKwkJdHVubmVsLT5vbGRfZGF0YV9y ZWFkeShzaywgbGVuKTsKKwl9CitlbmQ6CisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm47Cit9CisK Ky8qIFJlY2VpdmUgbWVzc2FnZS4gVGhpcyBpcyB0aGUgcmVjdm1zZyBmb3IgdGhlIFBQUG9MMlRQ IHNvY2tldC4KKyAqLworc3RhdGljIGludCBwcHBvbDJ0cF9yZWN2bXNnKHN0cnVjdCBraW9jYiAq aW9jYiwgc3RydWN0IHNvY2tldCAqc29jaywgCisJCQkgICAgc3RydWN0IG1zZ2hkciAqbXNnLCBz aXplX3QgbGVuLAorCQkJICAgIGludCBmbGFncykKK3sKKwlpbnQgZXJyID0gMDsKKwlzdHJ1Y3Qg c2tfYnVmZiAqc2tiID0gTlVMTDsKKwlzdHJ1Y3Qgc29jayAqc2sgPSBzb2NrLT5zazsKKworCUVO VEVSX0ZVTkNUSU9OOworCisJZXJyID0gLUVJTzsKKwlpZiAoc29jay0+c3RhdGUgJiBQUFBPWF9C T1VORCkKKwkJZ290byBlcnJvcjsKKwkJCQorCW1zZy0+bXNnX25hbWVsZW4gPSAwOworCQorCXNr Yj1za2JfcmVjdl9kYXRhZ3JhbShzaywgZmxhZ3MgJiB+TVNHX0RPTlRXQUlULAorCQkJICAgICAg ZmxhZ3MgJiBNU0dfRE9OVFdBSVQsICZlcnIpOworCWlmIChza2IpIHsKKwkJZXJyID0gbWVtY3B5 X3RvaW92ZWMobXNnLT5tc2dfaW92LCAodW5zaWduZWQgY2hhciAqKSBza2ItPmRhdGEsCisJCQkJ ICAgICBza2ItPmxlbik7CisJCWlmIChlcnIgPCAwKQorCQkJZ290byBkb19za2JfZnJlZTsKKwkJ ZXJyID0gc2tiLT5sZW47CisJfQorZG9fc2tiX2ZyZWU6CisJaWYgKHNrYikKKwkJa2ZyZWVfc2ti KHNrYik7CitlcnJvcjoKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiBlcnI7Cit9CisKKy8qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioKKyAqIFRyYW5zbWl0IGhhbmRsaW5nCisgKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCisKKy8q IEludGVybmFsIFVEUCBzb2NrZXQgdHJhbnNtaXNzaW9uCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wy dHBfdWRwX3NvY2tfc2VuZChzdHJ1Y3Qga2lvY2IgKmlvY2IsCisJCQkJICBzdHJ1Y3QgcHBwb2wy dHBfc2Vzc2lvbiAqc2Vzc2lvbiwgCisJCQkJICBzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5u ZWwsCisJCQkJICBzdHJ1Y3QgbXNnaGRyICptc2csIGludCB0b3RhbF9sZW4pCit7CisJbW1fc2Vn bWVudF90IGZzOworCWludCBlcnJvcjsKKworCUVOVEVSX0ZVTkNUSU9OOworCisJRFBSSU5USyhz ZXNzaW9uLT5kZWJ1ZywgIiVzOiB1ZHBfc2VuZG1zZyBjYWxsLi4uXG4iLCBzZXNzaW9uLT5uYW1l KTsKKworCS8qIFNldCB0byB1c2Vyc3BhY2UgZGF0YSBzZWdtZW50IHdoaWxlIHdlIGRvIGEgc2Vu ZG1zZygpIGNhbGwuCVdlJ3JlCisJICogYWN0dWFsbHkgY2FsbGluZyBhIHVzZXJzcGFjZSBBUEkg ZnJvbSB0aGUga2VybmVsIGhlcmUuLi4KKwkgKi8KKwlmcyA9IGdldF9mcygpOworCXNldF9mcyhn ZXRfZHMoKSk7CisKKwkvKiBUaGUgYWN0dWFsIHNlbmRtc2coKSBjYWxsLi4uICovCisJZXJyb3Ig PSB0dW5uZWwtPm9sZF9wcm90by5zZW5kbXNnKGlvY2IsIHNlc3Npb24tPnR1bm5lbF9zb2NrLCBt c2csIHRvdGFsX2xlbik7CisJaWYgKGVycm9yID09IC1FSU9DQlFVRVVFRCkKKwkJZXJyb3IgPSB3 YWl0X29uX3N5bmNfa2lvY2IoaW9jYik7CisKKwkvKiBCYWNrIHRvIGtlcm5lbCBzcGFjZSAqLwor CXNldF9mcyhmcyk7CisKKwlpZiAoZXJyb3IgPj0gMCkgeworCQl0dW5uZWwtPnN0YXRzLnR4X3Bh Y2tldHMrKzsKKwkJdHVubmVsLT5zdGF0cy50eF9ieXRlcyArPSBlcnJvcjsKKwkJc2Vzc2lvbi0+ c3RhdHMudHhfcGFja2V0cysrOworCQlzZXNzaW9uLT5zdGF0cy50eF9ieXRlcyArPSBlcnJvcjsK Kwl9IGVsc2UgeworCQl0dW5uZWwtPnN0YXRzLnR4X2Vycm9ycysrOworCQlzZXNzaW9uLT5zdGF0 cy50eF9lcnJvcnMrKzsKKwl9CisKKwlEUFJJTlRLKHNlc3Npb24tPmRlYnVnLCAiJXM6ICVzOiBy ZXR1cm5pbmcgcmVzdWx0ICVkXG4iLCBfX0ZVTkNUSU9OX18sIAorCQlzZXNzaW9uLT5uYW1lLCBl cnJvcik7CisJa2ZyZWUobXNnLT5tc2dfaW92KTsKKwlrZnJlZShtc2cpOworCQorCUVYSVRfRlVO Q1RJT047CisJcmV0dXJuIGVycm9yOworfQorCisvKiBCdWlsZCBhbiBMMlRQIGhlYWRlciBmb3Ig dGhlIHNlc3Npb24gaW50byB0aGUgYnVmZmVyIHByb3ZpZGVkLgorICovCitzdGF0aWMgaW50IHBw cG9sMnRwX2J1aWxkX2wydHBfaGVhZGVyKHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9u LCAKKwkJCQkgICAgICB2b2lkICpidWYpCit7CisJdTE2ICpidWZwID0gYnVmOworCXUxNiBmbGFn cyA9IEwyVFBfSERSX1ZFUjsKKworCWlmIChzZXNzaW9uLT5zZW5kX3NlcSkgeworCQlmbGFncyB8 PSBMMlRQX0hEUkZMQUdfUzsKKwl9CisKKwkvKiBTZXR1cCBMMlRQIGhlYWRlci4KKwkgKiBGSVhN RTogQ2FuIHRoaXMgZXZlciBiZSB1bmFsaWduZWQ/IElzIGRpcmVjdCBkZXJlZmVyZW5jaW5nIG9m CisJICogMTYtYml0IGhlYWRlciBmaWVsZHMgc2FmZSBoZXJlIGZvciBhbGwgYXJjaGl0ZWN0dXJl cz8KKwkgKi8JCisJKmJ1ZnArKyA9IGh0b25zKGZsYWdzKTsKKwkqYnVmcCsrID0gaHRvbnMoc2Vz c2lvbi0+dHVubmVsX2FkZHIuZF90dW5uZWwpOworCSpidWZwKysgPSBodG9ucyhzZXNzaW9uLT50 dW5uZWxfYWRkci5kX3Nlc3Npb24pOworCWlmIChzZXNzaW9uLT5zZW5kX3NlcSkgeworCQkqYnVm cCsrID0gaHRvbnMoc2Vzc2lvbi0+bnMpOworCQkqYnVmcCsrID0gMDsKKwkJc2Vzc2lvbi0+bnMr KzsKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfU0VRLCBLRVJOX0RFQlVH LCAKKwkJICAgICAgICIlczogdXBkYXRlZCBucyB0byAlaHVcbiIsIHNlc3Npb24tPm5hbWUsIHNl c3Npb24tPm5zKTsKKwl9CisKKwlyZXR1cm4gKCh2b2lkICopIGJ1ZnApIC0gYnVmOworfQorCisv KiBUaGlzIGlzIHRoZSBzZW5kbXNnIGZvciB0aGUgUFBQb0wyVFAgcHBwb2wydHBfc2Vzc2lvbiBz b2NrZXQuICBXZSBjb21lIGhlcmUKKyAqIHdoZW4gYSB1c2VyIGFwcGxpY2F0aW9uIGRvZXMgYSBz ZW5kbXNnKCkgb24gdGhlIHNlc3Npb24gc29ja2V0LiBMMlRQIGFuZAorICogUFBQIGhlYWRlcnMg bXVzdCBiZSBpbnNlcnRlZCBpbnRvIHRoZSB1c2VyJ3MgZGF0YS4KKyAqLworc3RhdGljIGludCBw cHBvbDJ0cF9zZW5kbXNnKHN0cnVjdCBraW9jYiAqaW9jYiwgc3RydWN0IHNvY2tldCAqc29jaywg c3RydWN0IG1zZ2hkciAqbSwKKwkJCSAgICBzaXplX3QgdG90YWxfbGVuKQoreworCXN0YXRpYyB1 bnNpZ25lZCBjaGFyIHBwcGhbMl0gPSB7IDB4ZmYsIDB4MDMgfTsKKwlzdHJ1Y3Qgc29jayAqc2sg PSBzb2NrLT5zazsKKwlpbnQgZXJyb3IgPSAwOworCXU4IGhkcltQUFBPTDJUUF9MMlRQX0hEUl9T SVpFX1NFUV07CisJaW50IGhkcl9sZW47CisJc3RydWN0IG1zZ2hkciAqbXNnOworCXN0cnVjdCBw cHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5l bDsKKworCUVOVEVSX0ZVTkNUSU9OOworCisJaWYgKHNvY2tfZmxhZyhzaywgU09DS19ERUFEKSB8 fCAhKHNrLT5za19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpIHsKKwkJZXJyb3IgPSAtRU5PVENP Tk47CisJCWdvdG8gZW5kOworCX0KKworCS8qIEdldCBzZXNzaW9uIGFuZCB0dW5uZWwgY29udGV4 dHMgKi8KKwlTT0NLXzJfU0VTU0lPTihzaywgc2Vzc2lvbiwgZXJyb3IsIC1FQkFERiwgZW5kLCAw KTsKKwlTT0NLXzJfVFVOTkVMKHNlc3Npb24tPnR1bm5lbF9zb2NrLCB0dW5uZWwsIGVycm9yLCAt RUJBREYsIGVuZCwgMCk7CisKKwkvKiBTZXR1cCBMMlRQIGhlYWRlciAqLwkKKwloZHJfbGVuID0g cHBwb2wydHBfYnVpbGRfbDJ0cF9oZWFkZXIoc2Vzc2lvbiwgJmhkcik7CisKKwlpZiAoc2Vzc2lv bi0+c2VuZF9zZXEpCisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0RBVEEs IEtFUk5fREVCVUcsIAorCQkgICAgICAgIiVzOiBzZW5kICVkIGJ5dGVzLCBucz0laHVcbiIsIHNl c3Npb24tPm5hbWUsIAorCQkgICAgICAgdG90YWxfbGVuLCBzZXNzaW9uLT5ucyAtIDEpOworCWVs c2UKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfREFUQSwgS0VSTl9ERUJV RywgCisJCSAgICAgICAiJXM6IHNlbmQgJWQgYnl0ZXNcbiIsIHNlc3Npb24tPm5hbWUsIHRvdGFs X2xlbik7CisKKwkvKiBVbmZvcnR1bmF0ZWx5LCB0aGVyZSBpcyBubyBkaXJlY3Qgd2F5IGZvciB1 cyB0byBwYXNzIGFuIHNrYiB0byB0aGUKKwkgKiBVRFAgbGF5ZXIsIHdlIGhhdmUgdG8gcHJldGVu ZCB0byBiZSBzZW5kaW5nIG9yZGluYXJ5IGRhdGEgYW5kIHVzZQorCSAqIHNlbmRtc2cuCisJICoK KwkgKiBXZSBhZGQgdGhlIEwyVFAgYW5kIFBQUCBoZWFkZXJzIGhlcmUuIFRvIGRvIHNvLCB3ZSBj cmVhdGUgYSBuZXcKKwkgKiBzdHJ1Y3QgbXNnaGRyIGFuZCBpbnNlcnQgdGhlIGhlYWRlcnMgYXMg dGhlIGZpcnN0IGlvdmVjcy4KKwkgKi8KKwltc2cgPSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgbXNn aGRyKSwgR0ZQX0FUT01JQyk7CisJaWYgKG1zZyA9PSBOVUxMKSB7CisJCWVycm9yID0gLUVOT0JV RlM7CisJCXR1bm5lbC0+c3RhdHMudHhfZXJyb3JzKys7CisJCXNlc3Npb24tPnN0YXRzLnR4X2Vy cm9ycysrOworCQlnb3RvIGVuZDsKKwl9CisKKwltc2ctPm1zZ19pb3YgPSBrbWFsbG9jKChtLT5t c2dfaW92bGVuICsgMikgKiBzaXplb2Yoc3RydWN0IGlvdmVjKSwgCisJCQkgICAgICAgR0ZQX0FU T01JQyk7CisJaWYgKG1zZy0+bXNnX2lvdiA9PSBOVUxMKSB7CisJCWVycm9yID0gLUVOT0JVRlM7 CisJCXR1bm5lbC0+c3RhdHMudHhfZXJyb3JzKys7CisJCXNlc3Npb24tPnN0YXRzLnR4X2Vycm9y cysrOworCQlrZnJlZShtc2cpOworCQlnb3RvIGVuZDsKKwl9CisKKwltc2ctPm1zZ19pb3ZbMF0u aW92X2Jhc2UgPSAmaGRyOworCW1zZy0+bXNnX2lvdlswXS5pb3ZfbGVuCSA9IGhkcl9sZW47CisJ bXNnLT5tc2dfaW92WzFdLmlvdl9iYXNlID0gJnBwcGg7CisJbXNnLT5tc2dfaW92WzFdLmlvdl9s ZW4JID0gc2l6ZW9mKHBwcGgpOworCW1lbWNweSgmbXNnLT5tc2dfaW92WzJdLCAmbS0+bXNnX2lv dlswXSwgCisJICAgICAgIG0tPm1zZ19pb3ZsZW4gKiBzaXplb2Yoc3RydWN0IGlvdmVjKSk7CisJ bXNnLT5tc2dfaW92bGVuID0gbS0+bXNnX2lvdmxlbiArIDI7CisJCisJLyogSWYgdGhlIHVzZXIg Y2FsbHMgc2VuZHRvKCkgdGhhdCdzIGp1c3QgdG9vIGJhZCAqLworCW1zZy0+bXNnX25hbWUJID0g JnNlc3Npb24tPnR1bm5lbF9hZGRyLmFkZHI7CisJbXNnLT5tc2dfbmFtZWxlbiA9IHNpemVvZihz ZXNzaW9uLT50dW5uZWxfYWRkci5hZGRyKTsKKwkKKwltc2ctPm1zZ19jb250cm9sICAgID0gbS0+ bXNnX2NvbnRyb2w7CisJbXNnLT5tc2dfY29udHJvbGxlbiA9IG0tPm1zZ19jb250cm9sbGVuOwor CW1zZy0+bXNnX2ZsYWdzCSAgICA9IG0tPm1zZ19mbGFnczsKKworCS8qIERvIHRoZSByZWFsIHdv cmsuIFRoaXMgYWx3YXlzIGZyZWVzIG1zZywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyCisJICogdGhl cmUgd2FzIGFuIGVycm9yCisJICovCisJZXJyb3IgPSBwcHBvbDJ0cF91ZHBfc29ja19zZW5kKGlv Y2IsIHNlc3Npb24sIHR1bm5lbCwgbXNnLCAKKwkJCQkgICAgICAgdG90YWxfbGVuICsgaGRyX2xl biArIHNpemVvZihwcHBoKSk7CisKK2VuZDoKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiBlcnJv cjsKK30KKworCisvKiBUcmFuc21pdCBmdW5jdGlvbiBjYWxsZWQgYnkgZ2VuZXJpYyBQUFAgZHJp dmVyLiAgU2VuZHMgUFBQIGZyYW1lIG92ZXIKKyAqIFBQUG9MMlRQIHNvY2tldC4KKyAqCisgKiBU aGlzIGlzIGFsbW9zdCB0aGUgc2FtZSBhcyBwcHBvbDJ0cF9zZW5kbXNnKCksIGJ1dCByYXRoZXIg dGhhbiBiZWluZyBjYWxsZWQKKyAqIHdpdGggYSBtc2doZHIgZnJvbSB1c2Vyc3BhY2UsIGl0IGlz IGNhbGxlZCB3aXRoIGEgc2tiIGZyb20gdGhlIGtlcm5lbC4KKyAqLworc3RhdGljIGludCBwcHBv bDJ0cF94bWl0KHN0cnVjdCBwcHBfY2hhbm5lbCAqY2hhbiwgc3RydWN0IHNrX2J1ZmYgKnNrYikK K3sKKwlzdHJ1Y3Qgc29jayAqc2sgPSAoc3RydWN0IHNvY2sgKikgY2hhbi0+cHJpdmF0ZTsKKwlp bnQgZXJyb3IgPSAwOworCXU4IGhkcltQUFBPTDJUUF9MMlRQX0hEUl9TSVpFX1NFUV07CisJaW50 IGhkcl9sZW47CisJc3RydWN0IG1zZ2hkciAqbXNnOworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9u ICpzZXNzaW9uOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbDsKKwlzdHJ1Y3Qga2lv Y2IgaW9jYjsKKwlzdHJ1Y3Qgc29ja19pb2NiIHNpb2NiOworCQorCUVOVEVSX0ZVTkNUSU9OOwor CQorCWlmIChzb2NrX2ZsYWcoc2ssIFNPQ0tfREVBRCkgfHwgIShzay0+c2tfc3RhdGUgJiBQUFBP WF9DT05ORUNURUQpKSB7CisJCURQUklOVEsoLTEsICJkZWFkPSVkIHN0YXRlPSV4XG4iLCBzb2Nr X2ZsYWcoc2ssIFNPQ0tfREVBRCksIHNrLT5za19zdGF0ZSk7CisJCWVycm9yID0gLUVOT1RDT05O OworCQlnb3RvIGVuZDsKKwl9CisKKwkvKiBHZXQgc2Vzc2lvbiBhbmQgdHVubmVsIGNvbnRleHRz IGZyb20gdGhlIHNvY2tldCAqLworCVNPQ0tfMl9TRVNTSU9OKHNrLCBzZXNzaW9uLCBlcnJvciwg LUVCQURGLCBlbmQsIDApOworCVNPQ0tfMl9UVU5ORUwoc2Vzc2lvbi0+dHVubmVsX3NvY2ssIHR1 bm5lbCwgZXJyb3IsIC1FQkFERiwgZW5kLCAwKTsKKworCS8qIFNldHVwIEwyVFAgaGVhZGVyICov CQorCWhkcl9sZW4gPSBwcHBvbDJ0cF9idWlsZF9sMnRwX2hlYWRlcihzZXNzaW9uLCAmaGRyKTsK KworCWlmIChzZXNzaW9uLT5zZW5kX3NlcSkKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBP TDJUUF9NU0dfREFUQSwgS0VSTl9ERUJVRywgCisJCSAgICAgICAiJXM6IHNlbmQgJWQgYnl0ZXMs IG5zPSVodVxuIiwgCisJCSAgICAgICBzZXNzaW9uLT5uYW1lLCBza2ItPmxlbiwgc2Vzc2lvbi0+ bnMgLSAxKTsKKwllbHNlCisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0RB VEEsIEtFUk5fREVCVUcsIAorCQkgICAgICAgIiVzOiBzZW5kICVkIGJ5dGVzXG4iLCBzZXNzaW9u LT5uYW1lLCBza2ItPmxlbik7CisKKwkvKiBVbmZvcnR1bmF0bHkgdGhlcmUgZG9lc24ndCBhcHBl YXIgdG8gYmUgYSB3YXkgZm9yIHVzIHRvIHBhc3MgYW4gc2tiCisJICogdG8gdGhlIFVEUCBsYXll ciwgd2UgaGF2ZSB0byBwcmV0ZW5kIHRvIGJlIHNlbmRpbmcgb3JkaW5hcnkgZGF0YQorCSAqIGFu ZCB1c2Ugc2VuZG1zZworCSAqLworCW1zZyA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBtc2doZHIp LCBHRlBfQVRPTUlDKTsKKwlpZiAobXNnID09IE5VTEwpIHsKKwkJZXJyb3IgPSAtRU5PQlVGUzsK KwkJdHVubmVsLT5zdGF0cy50eF9lcnJvcnMrKzsKKwkJc2Vzc2lvbi0+c3RhdHMudHhfZXJyb3Jz Kys7CisJCWdvdG8gZW5kOworCX0KKwkKKwltc2ctPm1zZ19pb3YgPSBrbWFsbG9jKDIgKiBzaXpl b2Yoc3RydWN0IGlvdmVjKSwgR0ZQX0FUT01JQyk7CisJaWYgKG1zZy0+bXNnX2lvdiA9PSBOVUxM KSB7CisJCWVycm9yID0gLUVOT0JVRlM7CisJCXR1bm5lbC0+c3RhdHMudHhfZXJyb3JzKys7CisJ CXNlc3Npb24tPnN0YXRzLnR4X2Vycm9ycysrOworCQlrZnJlZShtc2cpOworCQlnb3RvIGVuZDsK Kwl9CisJbXNnLT5tc2dfaW92WzBdLmlvdl9iYXNlID0gJmhkcjsKKwltc2ctPm1zZ19pb3ZbMF0u aW92X2xlbgkgPSBoZHJfbGVuOworCS8qIEZJWE1FOiBkbyB3ZSBuZWVkIHRvIGhhbmRsZSBza2Ig ZnJhZ21lbnRzIGhlcmU/ICovCisJbXNnLT5tc2dfaW92WzFdLmlvdl9iYXNlID0gc2tiLT5kYXRh OworCW1zZy0+bXNnX2lvdlsxXS5pb3ZfbGVuCSA9IHNrYi0+bGVuOworCW1zZy0+bXNnX2lvdmxl biA9IDI7CisJCisJLyogSWYgdGhlIHVzZXIgY2FsbHMgc2VuZHRvKCkgdGhhdCdzIGp1c3QgdG9v IGJhZCAqLworCW1zZy0+bXNnX25hbWUJID0gJnNlc3Npb24tPnR1bm5lbF9hZGRyLmFkZHI7CisJ bXNnLT5tc2dfbmFtZWxlbiA9IHNpemVvZihzZXNzaW9uLT50dW5uZWxfYWRkci5hZGRyKTsKKwkK Kwltc2ctPm1zZ19jb250cm9sICAgID0gTlVMTDsKKwltc2ctPm1zZ19jb250cm9sbGVuID0gMDsK Kwltc2ctPm1zZ19mbGFncwkgICAgPSBNU0dfRE9OVFdBSVQ7CS8qIE5lZWQgdGhpcyB0byBwcmV2 ZW50IGJsb2NraW5nICovCisKKwkvKiBEbyB0aGUgcmVhbCB3b3JrLiBUaGlzIGFsd2F5cyBmcmVl cyBtc2csIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlcgorCSAqIHRoZXJlIHdhcyBhbiBlcnJvcgorCSAq LworCWluaXRfc3luY19raW9jYigmaW9jYiwgTlVMTCk7CisJaW9jYi5wcml2YXRlID0gJnNpb2Ni OworCWVycm9yID0gcHBwb2wydHBfdWRwX3NvY2tfc2VuZCgmaW9jYiwgc2Vzc2lvbiwgdHVubmVs LCBtc2csIAorCQkJCSAgICAgICBza2ItPmxlbiArIGhkcl9sZW4pOworCisJa2ZyZWVfc2tiKHNr Yik7CisKK2VuZDoKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiBlcnJvcjsKK30KKworLyoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCisgKiBTZXNzaW9uIChhbmQgdHVubmVsIGNvbnRyb2wpIHNvY2tldCBj cmVhdGUvZGVzdHJveS4KKyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKworLyogV2hlbiB0aGUgdHVu bmVsIFVEUCBzb2NrZXQgaXMgY2xvc2VkLCBhbGwgdGhlIGF0dGFjaGVkIHNvY2tldHMgbmVlZCB0 byBnbworICogdG9vLiBUaGlzIGhhbmRsZXMgdGhhdC4KKyAqLworc3RhdGljIHZvaWQgcHBwb2wy dHBfdHVubmVsX2Nsb3NlYWxsKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbCkKK3sKKwlp bnQgaGFzaDsKKwlzdHJ1Y3QgaGxpc3Rfbm9kZSAqd2FsazsKKwlzdHJ1Y3QgaGxpc3Rfbm9kZSAq dG1wOworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uOworCXN0cnVjdCBzb2NrICpz azsKKworCUVOVEVSX0ZVTkNUSU9OOworCQorCWlmICh0dW5uZWwgPT0gTlVMTCkKKwkJQlVHKCk7 CisKKwlQUklOVEsodHVubmVsLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5G TywgCisJICAgICAgICIlczogY2xvc2luZyBhbGwgc2Vzc2lvbnMuLi5cbiIsIHR1bm5lbC0+bmFt ZSk7CisKKwlmb3IgKGhhc2ggPSAwOyBoYXNoIDwgUFBQT0wyVFBfSEFTSF9TSVpFOyBoYXNoKysp IHsKKwkJaGxpc3RfZm9yX2VhY2hfc2FmZSh3YWxrLCB0bXAsICZ0dW5uZWwtPnNlc3Npb25faGxp c3RbaGFzaF0pIHsKKwkJCXNlc3Npb24gPSBobGlzdF9lbnRyeSh3YWxrLCBzdHJ1Y3QgcHBwb2wy dHBfc2Vzc2lvbiwgaGxpc3QpOworCisJCQlzayA9IHNlc3Npb24tPnNvY2s7CisKKwkJCVBSSU5U SyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywKKwkJCSAg ICAgICAiJXM6IGNsb3Npbmcgc2Vzc2lvblxuIiwgc2Vzc2lvbi0+bmFtZSk7CisKKwkJCXdyaXRl X2xvY2tfYmgoJnR1bm5lbC0+aGxpc3RfbG9jayk7CisJCQlobGlzdF9kZWxfaW5pdCgmc2Vzc2lv bi0+aGxpc3QpOworCQkJd3JpdGVfdW5sb2NrX2JoKCZ0dW5uZWwtPmhsaXN0X2xvY2spOworCisJ CQlzb2NrX2hvbGQoc2spOworCisJCQlsb2NrX3NvY2soc2spOworCisJCQlpZiAoc2stPnNrX3N0 YXRlICYgKFBQUE9YX0NPTk5FQ1RFRCB8IFBQUE9YX0JPVU5EKSkgeworCQkJCXBwcG94X3VuYmlu ZF9zb2NrKHNrKTsKKwkJCQlzay0+c2tfc3RhdGUgPSBQUFBPWF9ERUFEOworCQkJCXNrLT5za19z dGF0ZV9jaGFuZ2Uoc2spOworCQkJfQorCisJCQkvKiBQdXJnZSBhbnkgcXVldWVkIGRhdGEgKi8K KwkJCXNrYl9xdWV1ZV9wdXJnZSgmc2stPnNrX3JlY2VpdmVfcXVldWUpOworCQkJc2tiX3F1ZXVl X3B1cmdlKCZzay0+c2tfd3JpdGVfcXVldWUpOworCisJCQlyZWxlYXNlX3NvY2soc2spOworCisJ CQlEUFJJTlRLKHNlc3Npb24tPmRlYnVnLCAiY2FsbGluZyBzb2NrX3B1dDsgcmVmY250PSVkXG4i LAorCQkJCXNrLT5za19yZWZjbnQuY291bnRlcik7CisJCQlzb2NrX3B1dChzayk7CisJCX0KKwl9 CisKKwlFWElUX0ZVTkNUSU9OOworfQorCisvKiBSZWFsbHkga2lsbCB0aGUgdHVubmVsLgorICog Q29tZSBoZXJlIG9ubHkgd2hlbiBhbGwgc2Vzc2lvbnMgaGF2ZSBiZWVuIGNsZWFyZWQgZnJvbSB0 aGUgdHVubmVsLgorICovCitzdGF0aWMgdm9pZCBwcHBvbDJ0cF90dW5uZWxfZnJlZShzdHJ1Y3Qg cHBwb2wydHBfdHVubmVsICp0dW5uZWwpCit7CisJRU5URVJfRlVOQ1RJT047CisKKwkvKiBSZW1v dmUgZnJvbSBzb2NrZXQgbGlzdCAqLworCWxpc3RfZGVsKCZ0dW5uZWwtPmxpc3QpOworCisJRFBS SU5USyh0dW5uZWwtPmRlYnVnLCAiJXM6IE1PRF9ERUNfVVNFX0NPVU5UXG4iLCB0dW5uZWwtPm5h bWUpOworCWtmcmVlKHR1bm5lbCk7CisKKwlFWElUX0ZVTkNUSU9OOworfQorCisvKiBUdW5uZWwg VURQIHNvY2tldCBkZXN0cnVjdCBob29rLgorICogVGhlIHR1bm5lbCBjb250ZXh0IGlzIGRlbGV0 ZWQgb25seSB3aGVuIGFsbCBzZXNzaW9uIHNvY2tldHMgaGF2ZSBiZWVuCisgKiBjbG9zZWQuCisg Ki8KK3N0YXRpYyB2b2lkIHBwcG9sMnRwX3R1bm5lbF9kZXN0cnVjdChzdHJ1Y3Qgc29jayAqc2sp Cit7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCWludCBlcnJvciA9IDA7CisJ RU5URVJfRlVOQ1RJT047CisJCisJU09DS18yX1RVTk5FTChzaywgdHVubmVsLCBlcnJvciwgLUVC QURGLCBlbmQsIDApOworCisJUFJJTlRLKHR1bm5lbC0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05U Uk9MLCBLRVJOX0lORk8sIAorCSAgICAgICAiJXM6IGNsb3NpbmcuLi5cbiIsIHR1bm5lbC0+bmFt ZSk7IAorCQorCXBwcG9sMnRwX3R1bm5lbF9jbG9zZWFsbCh0dW5uZWwpOworCitlbmQ6CisJRVhJ VF9GVU5DVElPTjsKKwlyZXR1cm47Cit9CisKKy8qIFJlYWxseSBraWxsIHRoZSBzb2NrZXQuIChD YWxsZWQgZnJvbSBzb2NrX3B1dCBpZiByZWZjbnQgPT0gMC4pCisgKi8KK3N0YXRpYyB2b2lkIHBw cG9sMnRwX3Nlc3Npb25fZGVzdHJ1Y3Qoc3RydWN0IHNvY2sgKnNrKQoreworCXN0cnVjdCBwcHBv eF9vcHQgKnBvID0gcHBwb3hfc2soc2spOworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNz aW9uID0gTlVMTDsKKwlpbnQgZXJyb3IgPSAwOworCisJRU5URVJfRlVOQ1RJT047CisJCisJaWYg KHNrLT5za191c2VyX2RhdGEgIT0gTlVMTCkgeworCQlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0 dW5uZWw7CisKKwkJU09DS18yX1NFU1NJT04oc2ssIHNlc3Npb24sIGVycm9yLCAtRUJBREYsIG91 dCwgMCk7CisKKwkJLyogRG9uJ3QgdXNlIFNPQ0tfMl9UVU5ORUwoKSBoZXJlIHRvIGdldCB0aGUg dHVubmVsIGNvbnRleHQKKwkJICogYmVjYXVzZSB0aGUgdHVubmVsIHNvY2tldCBtaWdodCBoYXZl IGFscmVhZHkgYmVlbiBjbG9zZWQKKwkJICogKGl0cyBzay0+c2tfdXNlcl9kYXRhIHdpbGwgYmUg TlVMTCkgc28gdXNlIHRoZSBzZXNzaW9uJ3MKKwkJICogcHJpdmF0ZSB0dW5uZWwgcHRyIGluc3Rl YWQuCisJCSAqLworCQl0dW5uZWwgPSBzZXNzaW9uLT50dW5uZWw7CisJCWlmICh0dW5uZWwgIT0g TlVMTCkgeworCQkJaWYgKHR1bm5lbC0+bWFnaWMgIT0gTDJUUF9UVU5ORUxfTUFHSUMpIHsKKwkJ CQlwcmludGsoS0VSTl9FUlIgIiVzOiAlczolZDogQkFEIFRVTk5FTCBNQUdJQyAiCisJCQkJICAg ICAgICIoIHR1bm5lbD0lcCBtYWdpYz0leCApXG4iLAorCQkJCSAgICAgICBfX0ZVTkNUSU9OX18s IF9fRklMRV9fLCBfX0xJTkVfXywgCisJCQkJICAgICAgIHR1bm5lbCwgdHVubmVsLT5tYWdpYyk7 CisJCQkJZ290byBvdXQ7CisJCQl9CisJCX0KKworCQkvKiBEZWxldGUgdHVubmVsIGNvbnRleHQg aWYgdGhpcyB3YXMgdGhlIGxhc3Qgc2Vzc2lvbiBvbiB0aGUKKwkJICogdHVubmVsLiAgVGhpcyB3 YXMgYWxsb2NhdGVkIHdoZW4gdGhlIGZpcnN0IHNlc3Npb24gd2FzCisJCSAqIGNyZWF0ZWQgb24g dGhlIHR1bm5lbC4gU2VlCisJCSAqIHBwcG9sMnRwX3ByZXBhcmVfdHVubmVsX3NvY2tldCgpLgor CQkgKi8KKwkJRFBSSU5USyh0dW5uZWwtPmRlYnVnLCAiJXM6IHNlc3Npb25fY291bnQ9JWRcbiIs IAorCQkJdHVubmVsLT5uYW1lLCBhdG9taWNfcmVhZCgmdHVubmVsLT5zZXNzaW9uX2NvdW50KSk7 CisJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZ0dW5uZWwtPnNlc3Npb25fY291bnQpKSB7CisJ CQlwcHBvbDJ0cF90dW5uZWxfZnJlZSh0dW5uZWwpOworCQl9CisJfQorCisJaWYgKHBvKQorCQlr ZnJlZShwbyk7CisKKwlpZiAoc2Vzc2lvbiAhPSBOVUxMKQorCQlrZnJlZShzZXNzaW9uKTsKKwor b3V0OgorCUVYSVRfRlVOQ1RJT047Cit9CisKKy8qIENhbGxlZCB3aGVuIHRoZSBQUFBvWCBzb2Nr ZXQgKHNlc3Npb24pIGlzIGNsb3NlZC4KKyAqLworc3RhdGljIGludCBwcHBvbDJ0cF9yZWxlYXNl KHN0cnVjdCBzb2NrZXQgKnNvY2spCit7CisJc3RydWN0IHNvY2sgKnNrID0gc29jay0+c2s7CisJ c3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24gPSBOVUxMOworCXN0cnVjdCBwcHBvbDJ0 cF90dW5uZWwgKnR1bm5lbDsKKwlpbnQgZXJyb3IgPSAwOworCUVOVEVSX0ZVTkNUSU9OOworCisJ aWYgKCFzaykKKwkJcmV0dXJuIDA7CisKKwlpZiAoc29ja19mbGFnKHNrLCBTT0NLX0RFQUQpICE9 IDApCisJCXJldHVybiAtRUJBREY7CisKKwlpZiAoc2stPnNrX3VzZXJfZGF0YSkgewkgICAgLyog V2FzIHRoaXMgc29ja2V0IGFjdHVhbGx5IGNvbm5lY3RlZD8gKi8KKwkJU09DS18yX1NFU1NJT04o c2ssIHNlc3Npb24sIGVycm9yLCAtRUJBREYsIGVuZCwgMCk7CisKKwkJLyogRG9uJ3QgdXNlIFNP Q0tfMl9UVU5ORUwoKSBoZXJlIHRvIGdldCB0aGUgdHVubmVsIGNvbnRleHQKKwkJICogYmVjYXVz ZSB0aGUgdHVubmVsIHNvY2tldCBtaWdodCBoYXZlIGFscmVhZHkgYmVlbiBjbG9zZWQKKwkJICog KGl0cyBzay0+c2tfdXNlcl9kYXRhIHdpbGwgYmUgTlVMTCkgc28gdXNlIHRoZSBzZXNzaW9uJ3MK KwkJICogcHJpdmF0ZSB0dW5uZWwgcHRyIGluc3RlYWQuCisJCSAqLworCQl0dW5uZWwgPSBzZXNz aW9uLT50dW5uZWw7CisJCWlmICh0dW5uZWwgIT0gTlVMTCkgeworCQkJaWYgKHR1bm5lbC0+bWFn aWMgPT0gTDJUUF9UVU5ORUxfTUFHSUMpIHsKKwkJCQkvKiBEZWxldGUgdGhlIHNlc3Npb24gc29j a2V0IGZyb20gdGhlIGhhc2ggKi8KKwkJCQl3cml0ZV9sb2NrX2JoKCZ0dW5uZWwtPmhsaXN0X2xv Y2spOworCQkJCWhsaXN0X2RlbF9pbml0KCZzZXNzaW9uLT5obGlzdCk7CisJCQkJd3JpdGVfdW5s b2NrX2JoKCZ0dW5uZWwtPmhsaXN0X2xvY2spOworCQkJfSBlbHNlIHsKKwkJCQlwcmludGsoS0VS Tl9FUlIgIiVzOiAlczolZDogQkFEIFRVTk5FTCBNQUdJQyAiCisJCQkJICAgICAgICIoIHR1bm5l bD0lcCBtYWdpYz0leCApXG4iLAorCQkJCSAgICAgICBfX0ZVTkNUSU9OX18sIF9fRklMRV9fLCBf X0xJTkVfXywgCisJCQkJICAgICAgIHR1bm5lbCwgdHVubmVsLT5tYWdpYyk7CisJCQkJZ290byBl bmQ7CisJCQl9CisJCX0KKwl9CisKKwlsb2NrX3NvY2soc2spOworCisJaWYgKHNrLT5za19zdGF0 ZSAmIChQUFBPWF9DT05ORUNURUQgfCBQUFBPWF9CT1VORCkpCisJCXBwcG94X3VuYmluZF9zb2Nr KHNrKTsKKworCS8qIFNpZ25hbCB0aGUgZGVhdGggb2YgdGhlIHNvY2tldC4gKi8KKwlzay0+c2tf c3RhdGUgPSBQUFBPWF9ERUFEOworCXNvY2tfb3JwaGFuKHNrKTsKKwlzb2NrLT5zayA9IE5VTEw7 CisKKwkvKiBQdXJnZSBhbnkgcXVldWVkIGRhdGEgKi8KKwlza2JfcXVldWVfcHVyZ2UoJnNrLT5z a19yZWNlaXZlX3F1ZXVlKTsKKwlza2JfcXVldWVfcHVyZ2UoJnNrLT5za193cml0ZV9xdWV1ZSk7 CisKKwlyZWxlYXNlX3NvY2soc2spOworCisJaWYgKHNlc3Npb24gIT0gTlVMTCkKKwkJRFBSSU5U SyhzZXNzaW9uLT5kZWJ1ZywgImNhbGxpbmcgc29ja19wdXQ7IHJlZmNudD0lZFxuIiwgCisJCQlz ZXNzaW9uLT5zb2NrLT5za19yZWZjbnQuY291bnRlcik7CisJc29ja19wdXQoc2spOworCitlbmQ6 CisJRVhJVF9GVU5DVElPTjsKKwlyZXR1cm4gZXJyb3I7Cit9CisKKy8qIEludGVybmFsIGZ1bmN0 aW9uIHRvIHByZXBhcmUgYSB0dW5uZWwgKFVEUCkgc29ja2V0IHRvIGhhdmUgUFBQb1ggc29ja2V0 cworICogYXR0YWNoZWQgdG8gaXQKKyAqLworc3RhdGljIHN0cnVjdCBzb2NrICpwcHBvbDJ0cF9w cmVwYXJlX3R1bm5lbF9zb2NrZXQoaW50IGZkLCB1MTYgdHVubmVsX2lkLCAKKwkJCQkJCSAgIGlu dCAqZXJyb3IpCit7CisJaW50IGVycjsKKwlzdHJ1Y3Qgc29ja2V0ICpzb2NrID0gTlVMTDsKKwlz dHJ1Y3Qgc29jayAqc2s7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCXN0cnVj dCBzb2NrICpyZXQgPSBOVUxMOworCisJRU5URVJfRlVOQ1RJT047CisJCisJLyogR2V0IHRoZSBz b2NrZXQgZnJvbSB0aGUgZmQgKi8KKwllcnIgPSAtRUJBREY7CisJc29jayA9IHNvY2tmZF9sb29r dXAoZmQsICZlcnIpOworCWlmICghc29jaykgeworCQlQUklOVEsoLTEsIFBQUE9MMlRQX01TR19D T05UUk9MLCBLRVJOX0VSUiwgCisJCSAgICAgICAidHVubCAlaHU6IHNvY2tmZF9sb29rdXAoZmQ9 JWQpIHJldHVybmVkICVkXG4iLCAKKwkJICAgICAgIHR1bm5lbF9pZCwgZmQsIGVycik7CisJCWdv dG8gZXJyOworCX0KKworCS8qIFF1aWNrIHNhbml0eSBjaGVja3MgKi8KKwllcnIgPSAtRVNPQ0tU Tk9TVVBQT1JUOworCWlmIChzb2NrLT50eXBlICE9IFNPQ0tfREdSQU0pIHsKKwkJUFJJTlRLKC0x LCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9FUlIsIAorCQkgICAgICAgInR1bmwgJWh1OiBm ZCAlZCB3cm9uZyB0eXBlLCBnb3QgJWQsIGV4cGVjdGVkICVkXG4iLCAKKwkJICAgICAgIHR1bm5l bF9pZCwgZmQsIHNvY2stPnR5cGUsIFNPQ0tfREdSQU0pOworCQlnb3RvIGVycjsKKwl9CisJZXJy ID0gLUVBRk5PU1VQUE9SVDsKKwlpZiAoc29jay0+b3BzLT5mYW1pbHkhPUFGX0lORVQpIHsKKwkJ UFJJTlRLKC0xLCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9FUlIsIAorCQkgICAgICAgInR1 bmwgJWh1OiBmZCAlZCB3cm9uZyBmYW1pbHksIGdvdCAlZCwgZXhwZWN0ZWQgJWRcbiIsIAorCQkg ICAgICAgdHVubmVsX2lkLCBmZCwgc29jay0+b3BzLT5mYW1pbHksIEFGX0lORVQpOworCQlnb3Rv IGVycjsKKwl9CisKKwllcnIgPSAtRU5PVENPTk47CisJc2sgPSBzb2NrLT5zazsKKwkKKwkvKiBD aGVjayBpZiB0aGlzIHNvY2tldCBoYXMgYWxyZWFkeSBiZWVuIHByZXBwZWQgKi8KKwl0dW5uZWwg PSAoc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqKXNrLT5za191c2VyX2RhdGE7CisJaWYgKHR1bm5l bCAhPSBOVUxMKSB7CisJCS8qIFVzZXItZGF0YSBmaWVsZCBhbHJlYWR5IHNldCAqLworCQllcnIg PSAtRUJVU1k7CisJCWlmICh0dW5uZWwtPm1hZ2ljICE9IEwyVFBfVFVOTkVMX01BR0lDKSB7CisJ CQlwcmludGsoS0VSTl9FUlIgIiVzOiAlczolZDogQkFEIFRVTk5FTCBNQUdJQyAiCisJCQkgICAg ICAgIiggdHVubmVsPSVwIG1hZ2ljPSV4IClcbiIsCisJCQkgICAgICAgX19GVU5DVElPTl9fLCBf X0ZJTEVfXywgX19MSU5FX18sIAorCQkJICAgICAgIHR1bm5lbCwgdHVubmVsLT5tYWdpYyk7CisJ CQlnb3RvIGVycjsKKwkJfQorCisJCS8qIFRoaXMgc29ja2V0IGhhcyBhbHJlYWR5IGJlZW4gcHJl cHBlZCAqLworCQlyZXQgPSB0dW5uZWwtPnNvY2s7CisJCWdvdG8gb3V0OworCX0KKworCS8qIFRo aXMgc29ja2V0IGlzIGF2YWlsYWJsZSBhbmQgbmVlZHMgcHJlcHBpbmcuIENyZWF0ZSBhbmV3IHR1 bm5lbAorCSAqIGNvbnRleHQgYW5kIGluaXQgaXQuCisJICovCisJc2stPnNrX3VzZXJfZGF0YSA9 IHR1bm5lbCA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwpLCBHRlBfS0VS TkVMKTsKKwlpZiAoc2stPnNrX3VzZXJfZGF0YSA9PSBOVUxMKSB7CisJCWVyciA9IC1FTk9NRU07 CisJCWdvdG8gZXJyOworCX0KKworCW1lbXNldCh0dW5uZWwsIDAsIHNpemVvZihzdHJ1Y3QgcHBw b2wydHBfdHVubmVsKSk7CisJCisJdHVubmVsLT5tYWdpYyA9IEwyVFBfVFVOTkVMX01BR0lDOwor CXNwcmludGYoJnR1bm5lbC0+bmFtZVswXSwgInR1bmwgJWh1IiwgdHVubmVsX2lkKTsKKworCXR1 bm5lbC0+c3RhdHMudHVubmVsX2lkID0gdHVubmVsX2lkOworCisJdHVubmVsLT5kZWJ1ZyA9IFBQ UE9MMlRQX0RFRkFVTFRfREVCVUdfRkxBR1M7CisKKwlEUFJJTlRLKHR1bm5lbC0+ZGVidWcsICJ0 dW5sICVodTogYWxsb2NhdGVkIHR1bm5lbD0lcCwgc2s9JXAsIHNvY2s9JXBcbiIsIAorCQl0dW5u ZWxfaWQsIHR1bm5lbCwgc2ssIHNvY2spOworCisJLyogU2V0dXAgdGhlIG5ldyBwcm90b2NvbCBz dHVmZiAqLworCXR1bm5lbC0+b2xkX3Byb3RvICA9ICpzay0+c2tfcHJvdDsKKwl0dW5uZWwtPmwy dHBfcHJvdG8gPSAqc2stPnNrX3Byb3Q7CisJCisJc2stPnNrX3Byb3QgPSAmdHVubmVsLT5sMnRw X3Byb3RvOworCQorCXR1bm5lbC0+b2xkX2RhdGFfcmVhZHkgPSBzay0+c2tfZGF0YV9yZWFkeTsK Kwlzay0+c2tfZGF0YV9yZWFkeQkgICAgICAgPSAmcHBwb2wydHBfZGF0YV9yZWFkeTsKKworCXR1 bm5lbC0+b2xkX3NrX2Rlc3RydWN0ID0gc2stPnNrX2Rlc3RydWN0OworCXNrLT5za19kZXN0cnVj dAkJPSAmcHBwb2wydHBfdHVubmVsX2Rlc3RydWN0OworCisJdHVubmVsLT5zb2NrICAgPSBzazsK Kwlzay0+c2tfYWxsb2NhdGlvbiA9IEdGUF9BVE9NSUM7CisKKwlyd2xvY2tfaW5pdCgmdHVubmVs LT5obGlzdF9sb2NrKTsKKworCS8qIEFkZCB0dW5uZWwgdG8gb3VyIGxpc3QgKi8KKwlJTklUX0xJ U1RfSEVBRCgmdHVubmVsLT5saXN0KTsKKwlsaXN0X2FkZCgmdHVubmVsLT5saXN0LCAmcHBwb2wy dHBfdHVubmVsX2xpc3QpOworCQorCXJldCA9IHR1bm5lbC0+c29jazsKKwkKKwkqZXJyb3IgPSAw Oworb3V0OgorCWlmIChzb2NrKQorCQlzb2NrZmRfcHV0KHNvY2spOworCUVYSVRfRlVOQ1RJT047 CisKKwlyZXR1cm4gcmV0OworCitlcnI6CisJKmVycm9yID0gZXJyOworCWdvdG8gb3V0OworfQor CisvKiBzb2NrZXQoKSBoYW5kbGVyLiBJbml0aWFsaXplIGEgbmV3IHN0cnVjdCBzb2NrLgorICov CitzdGF0aWMgaW50IHBwcG9sMnRwX2NyZWF0ZShzdHJ1Y3Qgc29ja2V0ICpzb2NrKQoreworCWlu dCBlcnJvciA9IDA7CisJc3RydWN0IHNvY2sgKnNrOworCXN0cnVjdCBwcHBveF9vcHQgKnBvOwor CisJRU5URVJfRlVOQ1RJT047CisJRFBSSU5USygtMSwgInNvY2s9JXBcbiIsIHNvY2spOworCisJ c2sgPSBza19hbGxvYyhQRl9QUFBPWCwgR0ZQX0tFUk5FTCwgMSwgTlVMTCk7CisJaWYgKCFzaykK KwkJcmV0dXJuIC1FTk9NRU07CisKKwlzb2NrX2luaXRfZGF0YShzb2NrLCBzayk7CisKKwkvKiBG SVhNRTogTm90IHN1cmUgd2h5IHRoZSBtb2R1bGUgdXNlIGNvdW50ZXIgaXMgemVybyB3aGVuIHdl CisJICogZ2V0IGhlcmUuICBTaW1pbGFyIHNvY2tldCBjb2RlIGRvZXNuJ3Qgc2VlbSB0byBidW1w IGl0cworCSAqIG1vZHVsZSB1c2UgY291bnQgYmVmb3JlIGNhbGxpbmcgc2tfc2V0X293bmVyKCks IHNvIHdoeQorCSAqIHBwcG9sMnRwPworCSAqLworCWlmICh0cnlfbW9kdWxlX2dldChUSElTX01P RFVMRSkpIHsKKwkJc2tfc2V0X293bmVyKHNrLCBUSElTX01PRFVMRSk7CisJCW1vZHVsZV9wdXQo VEhJU19NT0RVTEUpOworCX0KKworCXNvY2stPnN0YXRlICA9IFNTX1VOQ09OTkVDVEVEOworCXNv Y2stPm9wcyAgICA9ICZwcHBvbDJ0cF9vcHM7CisKKwlzay0+c2tfYmFja2xvZ19yY3YgPSBwcHBv bDJ0cF9yZWN2X2NvcmU7CisJc2stPnNrX3Byb3RvY29sICAgID0gUFhfUFJPVE9fT0wyVFA7CisJ c2stPnNrX2ZhbWlseSAgICAgID0gUEZfUFBQT1g7CisJc2stPnNrX3N0YXRlICAgICAgID0gUFBQ T1hfTk9ORTsKKwlzay0+c2tfdHlwZSAgICAgICAgPSBTT0NLX1NUUkVBTTsKKwlzay0+c2tfZGVz dHJ1Y3QgICAgPSBwcHBvbDJ0cF9zZXNzaW9uX2Rlc3RydWN0OworCisJcG8gPSBzay0+c2tfcHJv dGluZm8gPSBrbWFsbG9jKHNpemVvZihzdHJ1Y3QgcHBwb3hfb3B0KSwgR0ZQX0tFUk5FTCk7CisJ aWYgKCFwbykgeworCQllcnJvciA9IC1FTk9NRU07CisJCWdvdG8gZnJlZV9zazsKKwl9CisKKwlt ZW1zZXQoKHZvaWQgKikgcG8sIDAsIHNpemVvZigqcG8pKTsKKwlwby0+c2sgPSBzazsKKworCXNv Y2stPnNrID0gc2s7CisKKwlFWElUX0ZVTkNUSU9OOworCXJldHVybiAwOworCitmcmVlX3NrOgor CXNrX2ZyZWUoc2spOworCUVYSVRfRlVOQ1RJT047CisJcmV0dXJuIGVycm9yOworfQorCisvKiBj b25uZWN0KCkgaGFuZGxlci4uCUF0dGFjaCBhIFBQUG9YIHNvY2tldCB0byBhIHR1bm5lbCBVRFAg c29ja2V0CisgKi8KK2ludCBwcHBvbDJ0cF9jb25uZWN0KHN0cnVjdCBzb2NrZXQgKnNvY2ssIHN0 cnVjdCBzb2NrYWRkciAqdXNlcnZhZGRyLAorCQkgICAgIGludCBzb2NrYWRkcl9sZW4sIGludCBm bGFncykKK3sKKwlzdHJ1Y3Qgc29jayAqc2sgPSBzb2NrLT5zazsKKwlzdHJ1Y3Qgc29ja2FkZHJf cHBwb2wydHAgKnNwID0gKHN0cnVjdCBzb2NrYWRkcl9wcHBvbDJ0cCAqKSB1c2VydmFkZHI7CisJ c3RydWN0IHBwcG94X29wdCAqcG8gPSBwcHBveF9zayhzayk7CisJc3RydWN0IHNvY2sgKnR1bm5l bF9zb2NrID0gTlVMTDsKKwlzdHJ1Y3QgcHBwb2wydHBfc2Vzc2lvbiAqc2Vzc2lvbiA9IE5VTEw7 CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsOworCXN0cnVjdCBkc3RfZW50cnkgKmRz dDsKKwlpbnQgZXJyb3IgPSAwOworCisJRU5URVJfRlVOQ1RJT047CisJCisJRFBSSU5USygtMSwg InNvY2s9JXAsIHVzZXJ2YWRkcj0lcCwgc29ja2FkZHJfbGVuPSVkLCBmbGFncz0lZFxuIiwgCisJ CXNvY2ssIHVzZXJ2YWRkciwgc29ja2FkZHJfbGVuLCBmbGFncyk7CisJbG9ja19zb2NrKHNrKTsK KworCWVycm9yID0gLUVJTlZBTDsKKwlpZiAoc3AtPnNhX3Byb3RvY29sICE9IFBYX1BST1RPX09M MlRQKQorCQlnb3RvIGVuZDsKKworCS8qIENoZWNrIGZvciBhbHJlYWR5IGJvdW5kIHNvY2tldHMg Ki8KKwllcnJvciA9IC1FQlVTWTsKKwlpZiAoc2stPnNrX3N0YXRlICYgUFBQT1hfQ09OTkVDVEVE KQorCQlnb3RvIGVuZDsKKworCS8qIFdlIGRvbid0IHN1cHBvcnRpbmcgcmViaW5kaW5nIGFueXdh eSAqLwkJCisJaWYgKHNrLT5za191c2VyX2RhdGEpCisJCWdvdG8gZW5kOyAvKiBzb2NrZXQgaXMg YWxyZWFkeSBhdHRhY2hlZCAqLworCisJLyogRG9uJ3QgYmluZCBpZiBzX3R1bm5lbCBpcyAwICov CisJZXJyb3IgPSAtRUlOVkFMOworCWlmIChzcC0+cHBwb2wydHAuc190dW5uZWwgPT0gMCkKKwkJ Z290byBlbmQ7CisKKwkvKiBUaGlzIGxvb2tzIHVwIHRoZSB0dW5uZWwgc29ja2V0IGFuZCBjb25m aWd1cmVzIGl0IGlmIG5lY2Vzc2FyeSAqLworCXR1bm5lbF9zb2NrID0gCisJCXBwcG9sMnRwX3By ZXBhcmVfdHVubmVsX3NvY2tldChzcC0+cHBwb2wydHAuZmQsIAorCQkJCQkgICAgICAgc3AtPnBw cG9sMnRwLnNfdHVubmVsLCAKKwkJCQkJICAgICAgICZlcnJvcik7CisJaWYgKHR1bm5lbF9zb2Nr ID09IE5VTEwpCisJCWdvdG8gZW5kOworCXR1bm5lbCA9IHR1bm5lbF9zb2NrLT5za191c2VyX2Rh dGE7CisKKwkvKiBBbGxvY2F0ZSBhbmQgaW5pdGlhbGl6ZSBhIG5ldyBzZXNzaW9uIGNvbnRleHQu CisJICovCisJc2Vzc2lvbiA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9u KSwgR0ZQX0tFUk5FTCk7CisJaWYgKHNlc3Npb24gPT0gTlVMTCkgeworCQllcnJvciA9IC1FTk9N RU07CisJCWdvdG8gZW5kOworCX0KKworCW1lbXNldChzZXNzaW9uLCAwLCBzaXplb2Yoc3RydWN0 IHBwcG9sMnRwX3Nlc3Npb24pKTsKKworCXNlc3Npb24tPm1hZ2ljCSAgICAgPSBMMlRQX1NFU1NJ T05fTUFHSUM7CisJc2Vzc2lvbi0+b3duZXIJICAgICA9IGN1cnJlbnQtPnBpZDsKKwlzZXNzaW9u LT5zb2NrCSAgICAgPSBzazsKKwlzZXNzaW9uLT50dW5uZWwJICAgICA9IHR1bm5lbDsKKwlzZXNz aW9uLT50dW5uZWxfc29jayA9IHR1bm5lbF9zb2NrOworCXNlc3Npb24tPnR1bm5lbF9hZGRyID0g c3AtPnBwcG9sMnRwOworCXNwcmludGYoJnNlc3Npb24tPm5hbWVbMF0sICJzZXNzICVodS8laHUi LCAKKwkJc2Vzc2lvbi0+dHVubmVsX2FkZHIuc190dW5uZWwsIAorCQlzZXNzaW9uLT50dW5uZWxf YWRkci5zX3Nlc3Npb24pOworCisJc2Vzc2lvbi0+c3RhdHMudHVubmVsX2lkICA9IHNlc3Npb24t PnR1bm5lbF9hZGRyLnNfdHVubmVsOworCXNlc3Npb24tPnN0YXRzLnNlc3Npb25faWQgPSBzZXNz aW9uLT50dW5uZWxfYWRkci5zX3Nlc3Npb247CisKKwlJTklUX0hMSVNUX05PREUoJnNlc3Npb24t PmhsaXN0KTsKKworCXNlc3Npb24tPmRlYnVnID0gUFBQT0wyVFBfREVGQVVMVF9ERUJVR19GTEFH UzsKKworCS8qIERlZmF1bHQgTVRVIG11c3QgYWxsb3cgc3BhY2UgZm9yIFVEUC9MMlRQL1BQUAor CSAqIGhlYWRlcnMuIExlYXZlIHNvbWUgc2xhY2suIAorCSAqLworCXNlc3Npb24tPm10dSA9IHNl c3Npb24tPm1ydSA9IDE1MDAgLSBQUFBPTDJUUF9IRUFERVJfT1ZFUkhFQUQ7CisKKwkvKiBJZiBQ TVRVIGRpc2NvdmVyeSB3YXMgZW5hYmxlZCwgdXNlIHRoZSBNVFUgdGhhdCB3YXMgZGlzY292ZXJl ZCAqLworCWRzdCA9IHNrX2RzdF9nZXQoc2spOworCWlmIChkc3QgIT0gTlVMTCkgeworCQl1MzIg cG10dSA9IGRzdF9wbXR1KF9fc2tfZHN0X2dldChzaykpOworCQlpZiAocG10dSAhPSAwKSB7CisJ CQlzZXNzaW9uLT5tdHUgPSBzZXNzaW9uLT5tcnUgPSBwbXR1IC0gCisJCQkJUFBQT0wyVFBfSEVB REVSX09WRVJIRUFEOworCQkJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgCisJCQkJIiVzOiBNVFUg c2V0IGJ5IFBhdGggTVRVIGRpc2NvdmVyeTogbXR1PSVkXG4iLAorCQkJCXNlc3Npb24tPm5hbWUs IHNlc3Npb24tPm10dSk7CisJCX0KKwkJZHN0X3JlbGVhc2UoZHN0KTsKKwl9CisKKwkvKiBTcGVj aWFsIGNhc2U6IGlmIHNvdXJjZSAmIGRlc3Qgc2Vzc2lvbl9pZCA9PSAweDAwMDAsIHRoaXMgc29j a2V0IGlzCisJICogYmVpbmcgY3JlYXRlZCB0byBtYW5hZ2UgdGhlIHR1bm5lbC4gRG9uJ3QgYWRk IHRoZSBzZXNzaW9uIHRvIHRoZQorCSAqIHNlc3Npb24gaGFzaCBsaXN0LCBqdXN0IHNldCB1cCB0 aGUgaW50ZXJuYWwgY29udGV4dCBmb3IgdXNlIGJ5CisJICogaW9jdGwoKSBhbmQgc29ja29wdCgp IGhhbmRsZXJzLgorCSAqLworCWlmICgoc2Vzc2lvbi0+dHVubmVsX2FkZHIuc19zZXNzaW9uID09 IDApICYmCisJICAgIChzZXNzaW9uLT50dW5uZWxfYWRkci5kX3Nlc3Npb24gPT0gMCkpIHsKKwkJ ZXJyb3IgPSAwOworCQlEUFJJTlRLKHNlc3Npb24tPmRlYnVnLCAKKwkJCSJ0dW5sICVodTogc29j a2V0IGNyZWF0ZWQgZm9yIHR1bm5lbCBtZ210IG9wc1xuIiwgCisJCQlzZXNzaW9uLT50dW5uZWxf YWRkci5zX3R1bm5lbCk7CisJCXNrLT5za191c2VyX2RhdGEgPSBzZXNzaW9uOworCQlnb3RvIG91 dF9ub19wcHA7CisJfQorCisJRFBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgIiVzOiBhbGxvY2F0ZWQg c2Vzc2lvbj0lcCwgc29jaz0lcCwgb3duZXI9JWRcbiIsIAorCQlzZXNzaW9uLT5uYW1lLCBzZXNz aW9uLCBzaywgc2Vzc2lvbi0+b3duZXIpOworCisJLyogQWRkIHNlc3Npb24gdG8gdGhlIHR1bm5l bCdzIGhhc2ggbGlzdCAqLworCVNPQ0tfMl9UVU5ORUwodHVubmVsX3NvY2ssIHR1bm5lbCwgZXJy b3IsIC1FQkFERiwgZW5kLCAwKTsKKwl3cml0ZV9sb2NrX2JoKCZ0dW5uZWwtPmhsaXN0X2xvY2sp OworCWhsaXN0X2FkZF9oZWFkKCZzZXNzaW9uLT5obGlzdCwgCisJCSAgICAgICBwcHBvbDJ0cF9z ZXNzaW9uX2lkX2hhc2godHVubmVsLCAKKwkJCQkJCXNlc3Npb24tPnR1bm5lbF9hZGRyLnNfc2Vz c2lvbikpOworCXdyaXRlX3VubG9ja19iaCgmdHVubmVsLT5obGlzdF9sb2NrKTsKKwkKKwkvKiBU aGlzIGlzIGhvdyB3ZSBnZXQgdGhlIHNlc3Npb24gY29udGV4dCBmcm9tIHRoZSBzb2NrZXQuICov CisJc2stPnNrX3VzZXJfZGF0YSA9IHNlc3Npb247CisJCQorCS8qIFdlIGRvbid0IHN0b3JlIGFu eSBtb3JlIG9wdGlvbnMgaW4gdGhlIHBwcG94X29wdCwgZXZlcnl0aGluZyBpcyBpbgorCSAqIHVz ZXJfZGF0YSAoc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24pCisJICovCisJcG8tPnNrID0gc2s7CisK KwkvKiBSaWdodCBub3csIGJlY2F1c2Ugd2UgZG9uJ3QgaGF2ZSBhIHdheSB0byBwdXNoIHRoZSBp bmNvbWluZyBza2IncworCSAqIHN0cmFpZ2h0IHRocm91Z2ggdGhlIFVEUCBsYXllciwgdGhlIG9u bHkgaGVhZGVyIHdlIG5lZWQgdG8gd29ycnkKKwkgKiBhYm91dCBpcyB0aGUgTDJUUCBoZWFkZXIu IFRoaXMgc2l6ZSBpcyBkaWZmZXJlbnQgZGVwZW5kaW5nIG9uCisJICogd2hldGhlciBzZXF1ZW5j ZSBudW1iZXJzIGFyZSBlbmFibGVkIGZvciB0aGUgZGF0YSBjaGFubmVsLgorCSAqLworCXBvLT5j aGFuLmhkcmxlbiA9IFBQUE9MMlRQX0wyVFBfSERSX1NJWkVfTk9TRVE7CisKKwlwby0+Y2hhbi5w cml2YXRlID0gc2s7CisJcG8tPmNoYW4ub3BzCSA9ICZwcHBvbDJ0cF9jaGFuX29wczsKKworCWVy cm9yID0gcHBwX3JlZ2lzdGVyX2NoYW5uZWwoJnBvLT5jaGFuKTsKKwlpZiAoZXJyb3IpCisJCWdv dG8gZW5kOworCitvdXRfbm9fcHBwOgorCWF0b21pY19pbmMoJnR1bm5lbC0+c2Vzc2lvbl9jb3Vu dCk7CisJc2stPnNrX3N0YXRlID0gUFBQT1hfQ09OTkVDVEVEOworCVBSSU5USyhzZXNzaW9uLT5k ZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJICAgICAgICIlczogY3Jl YXRlZFxuIiwgc2Vzc2lvbi0+bmFtZSk7CisKK2VuZDoKKwlyZWxlYXNlX3NvY2soc2spOworCisJ aWYgKGVycm9yICE9IDApCisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NP TlRST0wsIEtFUk5fV0FSTklORywgCisJCSAgICAgICAiJXM6IGNvbm5lY3QgZmFpbGVkOiAlZFxu Iiwgc2Vzc2lvbi0+bmFtZSwgZXJyb3IpOworCisJRVhJVF9GVU5DVElPTjsKKworCXJldHVybiBl cnJvcjsKK30KKworLyogZ2V0bmFtZSgpIHN1cHBvcnQuCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wy dHBfZ2V0bmFtZShzdHJ1Y3Qgc29ja2V0ICpzb2NrLCBzdHJ1Y3Qgc29ja2FkZHIgKnVhZGRyLAor CQkJICAgIGludCAqdXNvY2thZGRyX2xlbiwgaW50IHBlZXIpCit7CisJaW50IGxlbiA9IHNpemVv ZihzdHJ1Y3Qgc29ja2FkZHJfcHBwb2wydHApOworCXN0cnVjdCBzb2NrYWRkcl9wcHBvbDJ0cCBz cDsKKwlpbnQgZXJyb3IgPSAwOworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uOwor CisJRU5URVJfRlVOQ1RJT047CisJCisJZXJyb3IgPSAtRU5PVENPTk47CisJaWYgKHNvY2stPnNr LT5za19zdGF0ZSAhPSBQUFBPWF9DT05ORUNURUQpCisJCWdvdG8gZW5kOworCQorCVNPQ0tfMl9T RVNTSU9OKHNvY2stPnNrLCBzZXNzaW9uLCBlcnJvciwgLUVCQURGLCBlbmQsIDApOworCQorCXNw LnNhX2ZhbWlseQk9IEFGX1BQUE9YOworCXNwLnNhX3Byb3RvY29sCT0gUFhfUFJPVE9fT0wyVFA7 CisJbWVtY3B5KCZzcC5wcHBvbDJ0cCwgJnNlc3Npb24tPnR1bm5lbF9hZGRyLAorCSAgICAgICBz aXplb2Yoc3RydWN0IHBwcG9sMnRwX2FkZHIpKTsKKworCW1lbWNweSh1YWRkciwgJnNwLCBsZW4p OworCisJKnVzb2NrYWRkcl9sZW4gPSBsZW47CisKKwllcnJvciA9IDA7CitlbmQ6CisJRVhJVF9G VU5DVElPTjsKKwlyZXR1cm4gZXJyb3I7Cit9CisKKy8qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCisgKiBp b2N0bCgpIGhhbmRsZXJzLgorICoKKyAqIFRoZSBQUFBvWCBzb2NrZXQgaXMgY3JlYXRlZCBmb3Ig TDJUUCBzZXNzaW9uczogdHVubmVscyBoYXZlIHRoZWlyIG93biBVRFAKKyAqIHNvY2tldHMuIEhv d2V2ZXIsIGluIG9yZGVyIHRvIGNvbnRyb2wga2VybmVsIHR1bm5lbCBmZWF0dXJlcywgd2UgYWxs b3cKKyAqIHVzZXJzcGFjZSB0byBjcmVhdGUgYSBzcGVjaWFsICJ0dW5uZWwiIFBQUG9YIHNvY2tl dCB3aGljaCBpcyB1c2VkIGZvcgorICogY29udHJvbCBvbmx5LiAgVHVubmVsIFBQUG9YIHNvY2tl dHMgaGF2ZSBzZXNzaW9uX2lkID09IDAgYW5kIHNpbXBseSBhbGxvdworICogdGhlIHVzZXIgYXBw bGljYXRpb24gdG8gaXNzdWUgTDJUUCBzZXRzb2Nrb3B0KCksIGdldHNvY2tvcHQoKSBhbmQgaW9j dGwoKQorICogY2FsbHMuCisgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKworLyogU2Vzc2lvbiBpb2N0 bCBoZWxwZXIuCisgKi8KK3N0YXRpYyBpbnQgcHBwb2wydHBfc2Vzc2lvbl9pb2N0bChzdHJ1Y3Qg cHBwb2wydHBfc2Vzc2lvbiAqc2Vzc2lvbiwgCisJCQkJICB1bnNpZ25lZCBpbnQgY21kLCB1bnNp Z25lZCBsb25nIGFyZykKK3sKKwlzdHJ1Y3QgaWZyZXEgaWZyOworCWludCBlcnIgPSAwOworCXN0 cnVjdCBzb2NrICpzayA9IHNlc3Npb24tPnNvY2s7CisJaW50IHZhbCA9IChpbnQpIGFyZzsKKwor CXNvY2tfaG9sZChzayk7CisKKwlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19D T05UUk9MLCBLRVJOX0RFQlVHLCAKKwkgICAgICAgIiVzOiBwcHBvbDJ0cF9zZXNzaW9uX2lvY3Rs KGNtZD0lI3gsIGFyZz0lI2x4KVxuIiwgCisJICAgICAgIHNlc3Npb24tPm5hbWUsIGNtZCwgYXJn KTsKKwkKKwlzd2l0Y2ggKGNtZCkgeworCWNhc2UgU0lPQ0dJRk1UVToKKwkJZXJyID0gLUVOWElP OworCQlpZiAoIShzay0+c2tfc3RhdGUgJiBQUFBPWF9DT05ORUNURUQpKQorCQkJYnJlYWs7CisK KwkJZXJyID0gLUVGQVVMVDsKKwkJaWYgKGNvcHlfZnJvbV91c2VyKCZpZnIsICh2b2lkIF9fdXNl ciAqKSBhcmcsIHNpemVvZihzdHJ1Y3QgaWZyZXEpKSkKKwkJCWJyZWFrOworCQlpZnIuaWZyX210 dSA9IHNlc3Npb24tPm10dTsKKwkJaWYgKGNvcHlfdG9fdXNlcigodm9pZCBfX3VzZXIgKikgYXJn LCAmaWZyLCBzaXplb2Yoc3RydWN0IGlmcmVxKSkpCisJCQlicmVhazsKKworCQlQUklOVEsoc2Vz c2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAgICAg IiVzOiBnZXQgbXR1PSVkXG4iLCBzZXNzaW9uLT5uYW1lLCBzZXNzaW9uLT5tdHUpOworCQllcnIg PSAwOworCQlicmVhazsKKworCWNhc2UgU0lPQ1NJRk1UVToKKwkJZXJyID0gLUVOWElPOworCQlp ZiAoIShzay0+c2tfc3RhdGUgJiBQUFBPWF9DT05ORUNURUQpKQorCQkJYnJlYWs7CisKKwkJZXJy ID0gLUVGQVVMVDsKKwkJaWYgKGNvcHlfZnJvbV91c2VyKCZpZnIsICh2b2lkIF9fdXNlciAqKSBh cmcsIHNpemVvZihzdHJ1Y3QgaWZyZXEpKSkKKwkJCWJyZWFrOworCisJCXNlc3Npb24tPm10dSA9 IGlmci5pZnJfbXR1OworOworCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19D T05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiBzZXQgbXR1PSVkXG4iLCBzZXNzaW9u LT5uYW1lLCBzZXNzaW9uLT5tdHUpOworCQllcnIgPSAwOworCQlicmVhazsKKworCWNhc2UgUFBQ SU9DR01SVToKKwkJZXJyID0gLUVOWElPOworCQlpZiAoIShzay0+c2tfc3RhdGUgJiBQUFBPWF9D T05ORUNURUQpKQorCQkJYnJlYWs7CisKKwkJZXJyID0gLUVGQVVMVDsKKwkJaWYgKHB1dF91c2Vy KHNlc3Npb24tPm1ydSwgKGludCBfX3VzZXIgKikgYXJnKSkKKwkJCWJyZWFrOworCisJCVBSSU5U SyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAg ICAgICAiJXM6IGdldCBtcnU9JWRcbiIsIHNlc3Npb24tPm5hbWUsIHNlc3Npb24tPm1ydSk7CisJ CWVyciA9IDA7CisJCWJyZWFrOworCisJY2FzZSBQUFBJT0NTTVJVOgorCQllcnIgPSAtRU5YSU87 CisJCWlmICghKHNrLT5za19zdGF0ZSAmIFBQUE9YX0NPTk5FQ1RFRCkpCisJCQlicmVhazsKKwor CQllcnIgPSAtRUZBVUxUOworCQlpZiAoZ2V0X3VzZXIodmFsLChpbnQgX191c2VyICopIGFyZykp CisJCQlicmVhazsKKworCQlzZXNzaW9uLT5tcnUgPSB2YWw7CisJCVBSSU5USyhzZXNzaW9uLT5k ZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IHNl dCBtcnU9JWRcbiIsIHNlc3Npb24tPm5hbWUsIHNlc3Npb24tPm1ydSk7CisJCWVyciA9IDA7CisJ CWJyZWFrOworCisJY2FzZSBQUFBJT0NHRkxBR1M6CisJCWVyciA9IC1FRkFVTFQ7CisJCWlmIChw dXRfdXNlcihzZXNzaW9uLT5mbGFncywgKGludCBfX3VzZXIgKikgYXJnKSkKKwkJCWJyZWFrOwor CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5G TywgCisJCSAgICAgICAiJXM6IGdldCBmbGFncz0lZFxuIiwgc2Vzc2lvbi0+bmFtZSwgc2Vzc2lv bi0+ZmxhZ3MpOworCQllcnIgPSAwOworCQlicmVhazsKKworCWNhc2UgUFBQSU9DU0ZMQUdTOgor CQllcnIgPSAtRUZBVUxUOworCQlpZiAoZ2V0X3VzZXIodmFsLCAoaW50IF9fdXNlciAqKSBhcmcp KQorCQkJYnJlYWs7CisJCXNlc3Npb24tPmZsYWdzID0gdmFsOworCQlQUklOVEsoc2Vzc2lvbi0+ ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiBz ZXQgZmxhZ3M9JWRcbiIsIHNlc3Npb24tPm5hbWUsIHNlc3Npb24tPmZsYWdzKTsKKwkJZXJyID0g MDsKKwkJYnJlYWs7CisKKwljYXNlIFBQUElPQ0dMMlRQU1RBVFM6CisJCWVyciA9IC1FTlhJTzsK KworCQlpZiAoIShzay0+c2tfc3RhdGUgJiBQUFBPWF9DT05ORUNURUQpKQorCQkJYnJlYWs7CisK KwkJaWYgKGNvcHlfdG9fdXNlcigodm9pZCBfX3VzZXIgKikgYXJnLCAmc2Vzc2lvbi0+c3RhdHMs IAorCQkJCSBzaXplb2Yoc2Vzc2lvbi0+c3RhdHMpKSkKKwkJCWJyZWFrOworCQlQUklOVEsoc2Vz c2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAgICAg IiVzOiBnZXQgTDJUUCBzdGF0c1xuIiwgc2Vzc2lvbi0+bmFtZSk7CisJCWVyciA9IDA7CisJCWJy ZWFrOworCisJZGVmYXVsdDoKKwkJZXJyID0gLUVOT1NZUzsKKwkJYnJlYWs7CisJfQorCisJc29j a19wdXQoc2spOworCisJcmV0dXJuIGVycjsKK30KKworLyogVHVubmVsIGlvY3RsIGhlbHBlci4K KyAqCisgKiBOb3RlIHRoZSBzcGVjaWFsIGhhbmRsaW5nIGZvciBQUFBJT0NHTDJUUFNUQVRTIGJl bG93LiBJZiB0aGUgaW9jdGwgZGF0YQorICogc3BlY2lmaWVzIGEgc2Vzc2lvbl9pZCwgdGhlIHNl c3Npb24gaW9jdGwgaGFuZGxlciBpcyBjYWxsZWQuIFRoaXMgYWxsb3dzIGFuCisgKiBhcHBsaWNh dGlvbiB0byByZXRyaWV2ZSBzZXNzaW9uIHN0YXRzIHZpYSBhIHR1bm5lbCBzb2NrZXQuCisgKi8K K3N0YXRpYyBpbnQgcHBwb2wydHBfdHVubmVsX2lvY3RsKHN0cnVjdCBwcHBvbDJ0cF90dW5uZWwg KnR1bm5lbCwgCisJCQkJIHVuc2lnbmVkIGludCBjbWQsIHVuc2lnbmVkIGxvbmcgYXJnKQorewor CWludCBlcnIgPSAwOworCXN0cnVjdCBzb2NrICpzayA9IHR1bm5lbC0+c29jazsKKwlzdHJ1Y3Qg cHBwb2wydHBfaW9jX3N0YXRzIHN0YXRzX3JlcTsKKworCXNvY2tfaG9sZChzayk7CisKKwlQUklO VEsodHVubmVsLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fREVCVUcsIAorCSAg ICAgICAiJXM6IHBwcG9sMnRwX3R1bm5lbF9pb2N0bChjbWQ9JSN4LCBhcmc9JSNseClcbiIsIHR1 bm5lbC0+bmFtZSwgCisJICAgICAgIGNtZCwgYXJnKTsKKworCXN3aXRjaCAoY21kKSB7CisJY2Fz ZSBQUFBJT0NHTDJUUFNUQVRTOgorCQllcnIgPSAtRU5YSU87CisKKwkJaWYgKCEoc2stPnNrX3N0 YXRlICYgUFBQT1hfQ09OTkVDVEVEKSkKKwkJCWJyZWFrOworCisJCWlmIChjb3B5X2Zyb21fdXNl cigmc3RhdHNfcmVxLCAodm9pZCBfX3VzZXIgKikgYXJnLCAKKwkJCQkgICBzaXplb2Yoc3RhdHNf cmVxKSkpIHsKKwkJCWVyciA9IC1FRkFVTFQ7CisJCQlicmVhazsKKwkJfQorCQlpZiAoc3RhdHNf cmVxLnNlc3Npb25faWQgIT0gMCkgeworCQkJLyogcmVzZW5kIHRvIHNlc3Npb24gaW9jdGwgaGFu ZGxlciAqLworCQkJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24gPSAKKwkJCQlwcHBv bDJ0cF9zZXNzaW9uX2ZpbmQodHVubmVsLCBzdGF0c19yZXEuc2Vzc2lvbl9pZCk7CisJCQlpZiAo c2Vzc2lvbiAhPSBOVUxMKQorCQkJCWVyciA9IHBwcG9sMnRwX3Nlc3Npb25faW9jdGwoc2Vzc2lv biwgY21kLCBhcmcpOworCQkJZWxzZQorCQkJCWVyciA9IC1FQkFEUjsKKwkJCWJyZWFrOworCQl9 CisjaWZkZWYgQ09ORklHX1hGUk0KKwkJdHVubmVsLT5zdGF0cy51c2luZ19pcHNlYyA9IChzay0+ c2tfcG9saWN5WzBdIHx8IHNrLT5za19wb2xpY3lbMV0pID8gMSA6IDA7CisjZW5kaWYKKwkJaWYg KGNvcHlfdG9fdXNlcigodm9pZCBfX3VzZXIgKikgYXJnLCAmdHVubmVsLT5zdGF0cywgCisJCQkJ IHNpemVvZih0dW5uZWwtPnN0YXRzKSkpIHsKKwkJCWVyciA9IC1FRkFVTFQ7CisJCQlicmVhazsK KwkJfQorCQlQUklOVEsodHVubmVsLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5f SU5GTywgCisJCSAgICAgICAiJXM6IGdldCBMMlRQIHN0YXRzXG4iLCB0dW5uZWwtPm5hbWUpOwor CQllcnIgPSAwOworCQlicmVhazsKKworCWRlZmF1bHQ6CisJCWVyciA9IC1FTk9TWVM7CisJCWJy ZWFrOworCX0KKworCXNvY2tfcHV0KHNrKTsKKworCXJldHVybiBlcnI7Cit9CisKKy8qIE1haW4g aW9jdGwoKSBoYW5kbGVyLgorICogRGlzcGF0Y2ggdG8gdHVubmVsIG9yIHNlc3Npb24gaGVscGVy cyBkZXBlbmRpbmcgb24gdGhlIHNvY2tldC4KKyAqLworc3RhdGljIGludCBwcHBvbDJ0cF9pb2N0 bChzdHJ1Y3Qgc29ja2V0ICpzb2NrLCB1bnNpZ25lZCBpbnQgY21kLAorCQkJICAgIHVuc2lnbmVk IGxvbmcgYXJnKQoreworCXN0cnVjdCBzb2NrICpzayA9IHNvY2stPnNrOworCXN0cnVjdCBwcHBv bDJ0cF9zZXNzaW9uICpzZXNzaW9uOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbDsK KwlpbnQgZXJyID0gMDsKKworCUVOVEVSX0ZVTkNUSU9OOworCQorCWlmICghc2spCisJCXJldHVy biAwOworCisJaWYgKHNvY2tfZmxhZyhzaywgU09DS19ERUFEKSAhPSAwKQorCQlyZXR1cm4gLUVC QURGOworCisJaWYgKChzay0+c2tfdXNlcl9kYXRhID09IE5VTEwpIHx8IAorCSAgICAoIShzay0+ c2tfc3RhdGUgJiAoUFBQT1hfQ09OTkVDVEVEIHwgUFBQT1hfQk9VTkQpKSkpIHsKKwkJZXJyID0g LUVOT1RDT05OOworCQlEUFJJTlRLKC0xLCAiaW9jdGw6IHNvY2tldCAlcCBub3QgY29ubmVjdGVk LlxuIiwgc2spOworCQlnb3RvIGVuZDsKKwl9CisKKwlTT0NLXzJfU0VTU0lPTihzaywgc2Vzc2lv biwgZXJyLCAtRUJBREYsIGVuZCwgMCk7CisJU09DS18yX1RVTk5FTChzZXNzaW9uLT50dW5uZWxf c29jaywgdHVubmVsLCBlcnIsIC1FQkFERiwgZW5kLCAxKTsKKworCS8qIFNwZWNpYWwgY2FzZTog aWYgc2Vzc2lvbidzIHNlc3Npb25faWQgaXMgemVybywgdHJlYXQgaW9jdGwgYXMgYQorCSAqIHR1 bm5lbCBpb2N0bAorCSAqLworCWlmICgoc2Vzc2lvbi0+dHVubmVsX2FkZHIuc19zZXNzaW9uID09 IDApICYmCisJICAgIChzZXNzaW9uLT50dW5uZWxfYWRkci5kX3Nlc3Npb24gPT0gMCkpIHsKKwkJ ZXJyID0gcHBwb2wydHBfdHVubmVsX2lvY3RsKHR1bm5lbCwgY21kLCBhcmcpOworCQlnb3RvIGVu ZDsKKwl9CisKKwllcnIgPSBwcHBvbDJ0cF9zZXNzaW9uX2lvY3RsKHNlc3Npb24sIGNtZCwgYXJn KTsKKworZW5kOgorCUVYSVRfRlVOQ1RJT047CisJcmV0dXJuIGVycjsKK30KKworLyoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqCisgKiBzZXRzb2Nrb3B0KCkgLyBnZXRzb2Nrb3B0KCkgc3VwcG9ydC4KKyAq CisgKiBUaGUgUFBQb1ggc29ja2V0IGlzIGNyZWF0ZWQgZm9yIEwyVFAgc2Vzc2lvbnM6IHR1bm5l bHMgaGF2ZSB0aGVpciBvd24gVURQCisgKiBzb2NrZXRzLiBJbiBvcmRlciB0byBjb250cm9sIGtl cm5lbCB0dW5uZWwgZmVhdHVyZXMsIHdlIGFsbG93IHVzZXJzcGFjZSB0bworICogY3JlYXRlIGEg c3BlY2lhbCAidHVubmVsIiBQUFBvWCBzb2NrZXQgd2hpY2ggaXMgdXNlZCBmb3IgY29udHJvbCBv bmx5LgorICogVHVubmVsIFBQUG9YIHNvY2tldHMgaGF2ZSBzZXNzaW9uX2lkID09IDAgYW5kIHNp bXBseSBhbGxvdyB0aGUgdXNlcgorICogYXBwbGljYXRpb24gdG8gaXNzdWUgTDJUUCBzZXRzb2Nr b3B0KCksIGdldHNvY2tvcHQoKSBhbmQgaW9jdGwoKSBjYWxscy4KKyAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKi8KKworLyogVHVubmVsIHNldHNvY2tvcHQoKSBoZWxwZXIuCisgKi8KK3N0YXRpYyBpbnQg cHBwb2wydHBfdHVubmVsX3NldHNvY2tvcHQoc3RydWN0IHNvY2sgKnNrLAorCQkJCSAgICAgIHN0 cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbCwgCisJCQkJICAgICAgaW50IG9wdG5hbWUsIGlu dCB2YWwpCit7CisJaW50IGVyciA9IDA7CisKKwlzd2l0Y2ggKG9wdG5hbWUpIHsKKwljYXNlIFBQ UE9MMlRQX1NPX0RFQlVHOgorCQl0dW5uZWwtPmRlYnVnID0gdmFsOworCQlQUklOVEsodHVubmVs LT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6 IHNldCBkZWJ1Zz0leFxuIiwgdHVubmVsLT5uYW1lLCB0dW5uZWwtPmRlYnVnKTsKKwkJYnJlYWs7 CisKKwlkZWZhdWx0OgorCQllcnIgPSAtRU5PUFJPVE9PUFQ7CisJCWJyZWFrOworCX0KKwkKKwly ZXR1cm4gZXJyOworfQorCisvKiBTZXNzaW9uIHNldHNvY2tvcHQgaGVscGVyLgorICovCitzdGF0 aWMgaW50IHBwcG9sMnRwX3Nlc3Npb25fc2V0c29ja29wdChzdHJ1Y3Qgc29jayAqc2ssCisJCQkJ ICAgICAgIHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uLCAKKwkJCQkgICAgICAgaW50 IG9wdG5hbWUsIGludCB2YWwpCit7CisJaW50IGVyciA9IDA7CisKKwlzd2l0Y2ggKG9wdG5hbWUp IHsKKwljYXNlIFBQUE9MMlRQX1NPX1JFQ1ZTRVE6CisJCWlmICgodmFsICE9IDApICYmICh2YWwg IT0gMSkpIHsKKwkJCWVyciA9IC1FSU5WQUw7CisJCQlicmVhazsKKwkJfQorCQlzZXNzaW9uLT5y ZWN2X3NlcSA9IHZhbCA/IC0xIDogMDsKKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJU UF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogc2V0IHJlY3Zfc2VxPSVk XG4iLCBzZXNzaW9uLT5uYW1lLCAKKwkJICAgICAgIHNlc3Npb24tPnJlY3Zfc2VxKTsKKwkJYnJl YWs7CisKKwljYXNlIFBQUE9MMlRQX1NPX1NFTkRTRVE6CisJCWlmICgodmFsICE9IDApICYmICh2 YWwgIT0gMSkpIHsKKwkJCWVyciA9IC1FSU5WQUw7CisJCQlicmVhazsKKwkJfQorCQlzZXNzaW9u LT5zZW5kX3NlcSA9IHZhbCA/IC0xIDogMDsKKwkJeworCQkJLyogRklYTUU6IGlzIGl0IHNhZmUg dG8gY2hhbmdlIHRoZSBwcHAgY2hhbm5lbCdzCisJCQkgKiBoZHJsZW4gb24gdGhlIGZseT8KKwkJ CSAqLworCQkJc3RydWN0IHNvY2sgKnNrCSAgICAgPSBzZXNzaW9uLT5zb2NrOworCQkJc3RydWN0 IHBwcG94X29wdCAqcG8gPSBwcHBveF9zayhzayk7CisJCQlwby0+Y2hhbi5oZHJsZW4gPSB2YWwg PyBQUFBPTDJUUF9MMlRQX0hEUl9TSVpFX1NFUSA6IAorCQkJCVBQUE9MMlRQX0wyVFBfSERSX1NJ WkVfTk9TRVE7CisJCX0KKwkJUFJJTlRLKHNlc3Npb24tPmRlYnVnLCBQUFBPTDJUUF9NU0dfQ09O VFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIlczogc2V0IHNlbmRfc2VxPSVkXG4iLCBzZXNz aW9uLT5uYW1lLCBzZXNzaW9uLT5zZW5kX3NlcSk7CisJCWJyZWFrOworCisJY2FzZSBQUFBPTDJU UF9TT19MTlNNT0RFOgorCQlpZiAoKHZhbCAhPSAwKSAmJiAodmFsICE9IDEpKSB7CisJCQllcnIg PSAtRUlOVkFMOworCQkJYnJlYWs7CisJCX0KKwkJc2Vzc2lvbi0+bG5zX21vZGUgPSB2YWwgPyAt MSA6IDA7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtF Uk5fSU5GTywgCisJCSAgICAgICAiJXM6IHNldCBsbnNfbW9kZT0lZFxuIiwgc2Vzc2lvbi0+bmFt ZSwgCisJCSAgICAgICBzZXNzaW9uLT5sbnNfbW9kZSk7CisJCWJyZWFrOworCisJY2FzZSBQUFBP TDJUUF9TT19ERUJVRzoKKwkJc2Vzc2lvbi0+ZGVidWcgPSB2YWw7CisJCVBSSU5USyhzZXNzaW9u LT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6 IHNldCBkZWJ1Zz0leFxuIiwgc2Vzc2lvbi0+bmFtZSwgc2Vzc2lvbi0+ZGVidWcpOworCQlicmVh azsKKworCWNhc2UgUFBQT0wyVFBfU09fUkVPUkRFUlRPOgorCQlzZXNzaW9uLT5yZW9yZGVyX3Rp bWVvdXQgPSBNU19UT19KSUZGSUVTKHZhbCk7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQ T0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IHNldCByZW9yZGVy X3RpbWVvdXQ9JWRcbiIsIHNlc3Npb24tPm5hbWUsIAorCQkgICAgICAgc2Vzc2lvbi0+cmVvcmRl cl90aW1lb3V0KTsKKwkJaWYgKHNlc3Npb24tPnJlb3JkZXJfdGltZW91dCAhPSAwKQorCQkJcHBw b2wydHBfd2Fybl9ub3RfeWV0X2ltcGxlbWVudGVkKHNlc3Npb24tPmRlYnVnLCAiU09fUkVPUkRF UlRPIik7CisJCWJyZWFrOworCisJZGVmYXVsdDoKKwkJZXJyID0gLUVOT1BST1RPT1BUOworCQli cmVhazsKKwl9CisKKwlyZXR1cm4gZXJyOworfQorCisvKiBNYWluIHNldHNvY2tvcHQoKSBlbnRy eSBwb2ludC4KKyAqIERvZXMgQVBJIGNoZWNrcywgdGhlbiBjYWxscyBlaXRoZXIgdGhlIHR1bm5l bCBvciBzZXNzaW9uIHNldHNvY2tvcHQKKyAqIGhhbmRsZXIsIGFjY29yZGluZyB0byB3aGV0aGVy IHRoZSBQUFBvTDJUUCBzb2NrZXQgaXMgYSBmb3IgYSByZWd1bGFyCisgKiBzZXNzaW9uIG9yIHRo ZSBzcGVjaWFsIHR1bm5lbCB0eXBlLgorICovCitzdGF0aWMgaW50IHBwcG9sMnRwX3NldHNvY2tv cHQoc3RydWN0IHNvY2tldCAqc29jaywgaW50IGxldmVsLCBpbnQgb3B0bmFtZSwgCisJCQkgICAg ICAgY2hhciAqb3B0dmFsLCBpbnQgb3B0bGVuKQoreworCXN0cnVjdCBzb2NrICpzayA9IHNvY2st PnNrOworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uID0gc2stPnNrX3VzZXJfZGF0 YTsKKwlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWw7CisJaW50IHZhbDsKKwlpbnQgZXJy ID0gMDsKKworCWlmIChsZXZlbCAhPSBTT0xfUFBQT0wyVFApCisJCXJldHVybiAtRVNPQ0tUTk9T VVBQT1JUOworCisJaWYgKG9wdGxlbjxzaXplb2YoaW50KSkKKwkJcmV0dXJuIC1FSU5WQUw7CisK KwlpZiAoZ2V0X3VzZXIodmFsLCAoaW50IF9fdXNlciAqKW9wdHZhbCkpCisJCXJldHVybiAtRUZB VUxUOworCisJaWYgKHNrLT5za191c2VyX2RhdGEgPT0gTlVMTCkgeworCQllcnIgPSAtRU5PVENP Tk47CisJCURQUklOVEsoLTEsICJzZXRzb2Nrb3B0OiBzb2NrZXQgJXAgbm90IGNvbm5lY3RlZC5c biIsIHNrKTsKKwkJZ290byBlbmQ7CisJfQorCisJU09DS18yX1NFU1NJT04oc2ssIHNlc3Npb24s IGVyciwgLUVCQURGLCBlbmQsIDApOworCVNPQ0tfMl9UVU5ORUwoc2Vzc2lvbi0+dHVubmVsX3Nv Y2ssIHR1bm5lbCwgZXJyLCAtRUJBREYsIGVuZCwgMSk7CisKKwlsb2NrX3NvY2soc2spOworCisJ LyogU3BlY2lhbCBjYXNlOiBpZiBzZXNzaW9uX2lkID09IDB4MDAwMCwgdHJlYXQgYXMgb3BlcmF0 aW9uIG9uIHR1bm5lbAorCSAqLworCWlmICgoc2Vzc2lvbi0+dHVubmVsX2FkZHIuc19zZXNzaW9u ID09IDApICYmCisJICAgIChzZXNzaW9uLT50dW5uZWxfYWRkci5kX3Nlc3Npb24gPT0gMCkpCisJ CWVyciA9IHBwcG9sMnRwX3R1bm5lbF9zZXRzb2Nrb3B0KHNrLCB0dW5uZWwsIG9wdG5hbWUsIHZh bCk7CisJZWxzZQorCQllcnIgPSBwcHBvbDJ0cF9zZXNzaW9uX3NldHNvY2tvcHQoc2ssIHNlc3Np b24sIG9wdG5hbWUsIHZhbCk7CisJCisJcmVsZWFzZV9zb2NrKHNrKTsKK2VuZDoKKwlyZXR1cm4g ZXJyOworfQorCisvKiBUdW5uZWwgZ2V0c29ja29wdCBoZWxwZXIuCisgKi8KK3N0YXRpYyBpbnQg cHBwb2wydHBfdHVubmVsX2dldHNvY2tvcHQoc3RydWN0IHNvY2sgKnNrLAorCQkJCSAgICAgIHN0 cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbCwgCisJCQkJICAgICAgaW50IG9wdG5hbWUsIGlu dCAqdmFsKQoreworCWludCBlcnIgPSAwOworCisJc3dpdGNoIChvcHRuYW1lKSB7CisJY2FzZSBQ UFBPTDJUUF9TT19ERUJVRzoKKwkJKnZhbCA9IHR1bm5lbC0+ZGVidWc7CisJCVBSSU5USyh0dW5u ZWwtPmRlYnVnLCBQUFBPTDJUUF9NU0dfQ09OVFJPTCwgS0VSTl9JTkZPLCAKKwkJICAgICAgICIl czogZ2V0IGRlYnVnPSV4XG4iLCB0dW5uZWwtPm5hbWUsIHR1bm5lbC0+ZGVidWcpOworCQlicmVh azsKKworCWRlZmF1bHQ6CisJCWVyciA9IC1FTk9QUk9UT09QVDsKKwkJYnJlYWs7CisJfQorCQor CXJldHVybiBlcnI7Cit9CisKKy8qIFNlc3Npb24gZ2V0c29ja29wdCBoZWxwZXIuCisgKi8KK3N0 YXRpYyBpbnQgcHBwb2wydHBfc2Vzc2lvbl9nZXRzb2Nrb3B0KHN0cnVjdCBzb2NrICpzaywgCisJ CQkJICAgICAgIHN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uLCAKKwkJCQkgICAgICAg aW50IG9wdG5hbWUsIGludCAqdmFsKQoreworCWludCBlcnIgPSAwOworCisJc3dpdGNoIChvcHRu YW1lKSB7CisJY2FzZSBQUFBPTDJUUF9TT19SRUNWU0VROgorCQkqdmFsID0gc2Vzc2lvbi0+cmVj dl9zZXE7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtF Uk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCByZWN2X3NlcT0lZFxuIiwgc2Vzc2lvbi0+bmFt ZSwgKnZhbCk7CisJCWJyZWFrOworCisJY2FzZSBQUFBPTDJUUF9TT19TRU5EU0VROgorCQkqdmFs ID0gc2Vzc2lvbi0+c2VuZF9zZXE7CisJCVBSSU5USyhzZXNzaW9uLT5kZWJ1ZywgUFBQT0wyVFBf TVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdldCBzZW5kX3NlcT0lZFxu Iiwgc2Vzc2lvbi0+bmFtZSwgKnZhbCk7CisJCWJyZWFrOworCisJY2FzZSBQUFBPTDJUUF9TT19M TlNNT0RFOgorCQkqdmFsID0gc2Vzc2lvbi0+bG5zX21vZGU7CisJCVBSSU5USyhzZXNzaW9uLT5k ZWJ1ZywgUFBQT0wyVFBfTVNHX0NPTlRST0wsIEtFUk5fSU5GTywgCisJCSAgICAgICAiJXM6IGdl dCBsbnNfbW9kZT0lZFxuIiwgc2Vzc2lvbi0+bmFtZSwgKnZhbCk7CisJCWJyZWFrOworCisJY2Fz ZSBQUFBPTDJUUF9TT19ERUJVRzoKKwkJKnZhbCA9IHNlc3Npb24tPmRlYnVnOworCQlQUklOVEso c2Vzc2lvbi0+ZGVidWcsIFBQUE9MMlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAg ICAgIiVzOiBnZXQgZGVidWc9JWRcbiIsIHNlc3Npb24tPm5hbWUsICp2YWwpOworCQlicmVhazsK KworCWNhc2UgUFBQT0wyVFBfU09fUkVPUkRFUlRPOgorCQkqdmFsID0gSklGRklFU19UT19NUyhz ZXNzaW9uLT5yZW9yZGVyX3RpbWVvdXQpOworCQlQUklOVEsoc2Vzc2lvbi0+ZGVidWcsIFBQUE9M MlRQX01TR19DT05UUk9MLCBLRVJOX0lORk8sIAorCQkgICAgICAgIiVzOiBnZXQgcmVvcmRlcl90 aW1lb3V0PSVkXG4iLCBzZXNzaW9uLT5uYW1lLCAqdmFsKTsKKwkJYnJlYWs7CisKKwlkZWZhdWx0 OgorCQllcnIgPSAtRU5PUFJPVE9PUFQ7CisJfQorCisJcmV0dXJuIGVycjsKK30KKworLyogTWFp biBnZXRzb2Nrb3B0KCkgZW50cnkgcG9pbnQuCisgKiBEb2VzIEFQSSBjaGVja3MsIHRoZW4gY2Fs bHMgZWl0aGVyIHRoZSB0dW5uZWwgb3Igc2Vzc2lvbiBnZXRzb2Nrb3B0CisgKiBoYW5kbGVyLCBh Y2NvcmRpbmcgdG8gd2hldGhlciB0aGUgUFBQb1ggc29ja2V0IGlzIGEgZm9yIGEgcmVndWxhciBz ZXNzaW9uCisgKiBvciB0aGUgc3BlY2lhbCB0dW5uZWwgdHlwZS4KKyAqLworc3RhdGljIGludCBw cHBvbDJ0cF9nZXRzb2Nrb3B0KHN0cnVjdCBzb2NrZXQgKnNvY2ssIGludCBsZXZlbCwgCisJCQkg ICAgICAgaW50IG9wdG5hbWUsIGNoYXIgKm9wdHZhbCwgaW50ICpvcHRsZW4pCit7CisJc3RydWN0 IHNvY2sgKnNrID0gc29jay0+c2s7CisJc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24gKnNlc3Npb24g PSBzay0+c2tfdXNlcl9kYXRhOworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbDsKKwlp bnQgdmFsLCBsZW47CisJaW50IGVyciA9IDA7CisKKwlpZiAobGV2ZWwgIT0gU09MX1BQUE9MMlRQ KQorCQlyZXR1cm4gLUVTT0NLVE5PU1VQUE9SVDsKKworCWlmIChnZXRfdXNlcihsZW4sIChpbnQg X191c2VyICopIG9wdGxlbikpCisJCXJldHVybiAtRUZBVUxUOworCisJbGVuID0gbWluX3QodW5z aWduZWQgaW50LCBsZW4sIHNpemVvZihpbnQpKTsKKwkKKwlpZiAobGVuIDwgMCkKKwkJcmV0dXJu IC1FSU5WQUw7CisKKwlpZiAoc2stPnNrX3VzZXJfZGF0YSA9PSBOVUxMKSB7CisJCWVyciA9IC1F Tk9UQ09OTjsKKwkJRFBSSU5USygtMSwgImdldHNvY2tvcHQ6IHNvY2tldCAlcCBub3QgY29ubmVj dGVkLlxuIiwgc2spOworCQlnb3RvIGVuZDsKKwl9CisKKwkvKiBHZXQgdGhlIHNlc3Npb24gYW5k IHR1bm5lbCBjb250ZXh0cyAqLworCVNPQ0tfMl9TRVNTSU9OKHNrLCBzZXNzaW9uLCBlcnIsIC1F QkFERiwgZW5kLCAwKTsKKwlTT0NLXzJfVFVOTkVMKHNlc3Npb24tPnR1bm5lbF9zb2NrLCB0dW5u ZWwsIGVyciwgLUVCQURGLCBlbmQsIDEpOworCisJLyogU3BlY2lhbCBjYXNlOiBpZiBzZXNzaW9u X2lkID09IDB4MDAwMCwgdHJlYXQgYXMgb3BlcmF0aW9uIG9uIHR1bm5lbCAqLworCWlmICgoc2Vz c2lvbi0+dHVubmVsX2FkZHIuc19zZXNzaW9uID09IDApICYmCisJICAgIChzZXNzaW9uLT50dW5u ZWxfYWRkci5kX3Nlc3Npb24gPT0gMCkpCisJCWVyciA9IHBwcG9sMnRwX3R1bm5lbF9nZXRzb2Nr b3B0KHNrLCB0dW5uZWwsIG9wdG5hbWUsICZ2YWwpOworCWVsc2UKKwkJZXJyID0gcHBwb2wydHBf c2Vzc2lvbl9nZXRzb2Nrb3B0KHNrLCBzZXNzaW9uLCBvcHRuYW1lLCAmdmFsKTsKKwkKKworCWlm IChwdXRfdXNlcihsZW4sIChpbnQgX191c2VyICopIG9wdGxlbikpCisJCXJldHVybiAtRUZBVUxU OworCisJaWYgKGNvcHlfdG9fdXNlcigodm9pZCBfX3VzZXIgKikgb3B0dmFsLCAmdmFsLCBsZW4p KQorCQlyZXR1cm4gLUVGQVVMVDsKKworZW5kOgorCXJldHVybiBlcnI7Cit9CisKKy8qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKgorICogL3Byb2MgZmlsZXN5c3RlbSBmb3IgZGVidWcKKyAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKi8KKworI2lmZGVmIENPTkZJR19QUk9DX0ZTCisKKyNpbmNsdWRlIDxsaW51eC9z ZXFfZmlsZS5oPgorCitzdGF0aWMgaW50IHBwcG9sMnRwX3Byb2Nfb3BlbihzdHJ1Y3QgaW5vZGUg Kmlub2RlLCBzdHJ1Y3QgZmlsZSAqZmlsZSk7CitzdGF0aWMgdm9pZCAqcHBwb2wydHBfcHJvY19z dGFydChzdHJ1Y3Qgc2VxX2ZpbGUgKm0sIGxvZmZfdCAqX3Bvcyk7CitzdGF0aWMgdm9pZCAqcHBw b2wydHBfcHJvY19uZXh0KHN0cnVjdCBzZXFfZmlsZSAqcCwgdm9pZCAqdiwgbG9mZl90ICpwb3Mp Oworc3RhdGljIHZvaWQgcHBwb2wydHBfcHJvY19zdG9wKHN0cnVjdCBzZXFfZmlsZSAqcCwgdm9p ZCAqdik7CitzdGF0aWMgaW50IHBwcG9sMnRwX3Byb2Nfc2hvdyhzdHJ1Y3Qgc2VxX2ZpbGUgKm0s IHZvaWQgKnYpOworCitzdGF0aWMgc3RydWN0IHByb2NfZGlyX2VudHJ5ICpwcHBvbDJ0cF9wcm9j OworCitzdGF0aWMgc3RydWN0IHNlcV9vcGVyYXRpb25zIHBwcG9sMnRwX3Byb2Nfb3BzID0gewor CS5zdGFydAkJPSBwcHBvbDJ0cF9wcm9jX3N0YXJ0LAorCS5uZXh0CQk9IHBwcG9sMnRwX3Byb2Nf bmV4dCwKKwkuc3RvcAkJPSBwcHBvbDJ0cF9wcm9jX3N0b3AsCisJLnNob3cJCT0gcHBwb2wydHBf cHJvY19zaG93LAorfTsKKworc3RhdGljIHN0cnVjdCBmaWxlX29wZXJhdGlvbnMgcHBwb2wydHBf cHJvY19mb3BzID0geworCS5vd25lcgkJPSBUSElTX01PRFVMRSwKKwkub3BlbgkJPSBwcHBvbDJ0 cF9wcm9jX29wZW4sCisJLnJlYWQJCT0gc2VxX3JlYWQsCisJLmxsc2VlawkJPSBzZXFfbHNlZWss CisJLnJlbGVhc2UJPSBzZXFfcmVsZWFzZSwKK307CisKK3N0YXRpYyBpbnQgcHBwb2wydHBfcHJv Y19vcGVuKHN0cnVjdCBpbm9kZSAqaW5vZGUsIHN0cnVjdCBmaWxlICpmaWxlKQoreworCXN0cnVj dCBzZXFfZmlsZSAqbTsKKwlpbnQgcmV0ID0gMDsKKworCUVOVEVSX0ZVTkNUSU9OOworCXJldCA9 IHNlcV9vcGVuKGZpbGUsICZwcHBvbDJ0cF9wcm9jX29wcyk7CisJaWYgKHJldCA8IDApCisJCWdv dG8gb3V0OworCisJbQkgICA9IGZpbGUtPnByaXZhdGVfZGF0YTsKKwltLT5wcml2YXRlID0gUERF KGlub2RlKS0+ZGF0YTsKKworb3V0OgorCUVYSVRfRlVOQ1RJT047CisJcmV0dXJuIHJldDsKK30K Kworc3RhdGljIHZvaWQgKnBwcG9sMnRwX3Byb2Nfc3RhcnQoc3RydWN0IHNlcV9maWxlICptLCBs b2ZmX3QgKl9wb3MpCit7CisJc3RydWN0IHBwcG9sMnRwX3R1bm5lbCAqdHVubmVsID0gTlVMTDsK Kwlsb2ZmX3QgcG9zID0gKl9wb3M7CisJc3RydWN0IGxpc3RfaGVhZCAqd2FsazsKKwlzdHJ1Y3Qg bGlzdF9oZWFkICp0bXA7CisKKwlFTlRFUl9GVU5DVElPTjsKKworCS8qIGFsbG93IGZvciB0aGUg aGVhZGVyIGxpbmUgKi8KKwlpZiAoIXBvcykgeworCQl0dW5uZWwgPSAodm9pZCAqKTE7CisJCWdv dG8gb3V0OworCX0KKwlwb3MtLTsKKworCS8qIGZpbmQgdGhlIG4ndGggZWxlbWVudCBpbiB0aGUg bGlzdCAqLworCWxpc3RfZm9yX2VhY2hfc2FmZSh3YWxrLCB0bXAsICZwcHBvbDJ0cF90dW5uZWxf bGlzdCkgewkKKwkJdHVubmVsID0gbGlzdF9lbnRyeSh3YWxrLCBzdHJ1Y3QgcHBwb2wydHBfdHVu bmVsLCBsaXN0KTsKKwkJaWYgKCFwb3MtLSkgeworCQkJc29ja19ob2xkKHR1bm5lbC0+c29jayk7 CisJCQlnb3RvIG91dDsKKwkJfQorCX0KKwl0dW5uZWwgPSBOVUxMOworCitvdXQ6CisJRVhJVF9G VU5DVElPTjsKKworCXJldHVybiB0dW5uZWw7Cit9CisKK3N0YXRpYyB2b2lkICpwcHBvbDJ0cF9w cm9jX25leHQoc3RydWN0IHNlcV9maWxlICpwLCB2b2lkICp2LCBsb2ZmX3QgKnBvcykKK3sKKwlz dHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5uZWwgPSB2OworCXN0cnVjdCBsaXN0X2hlYWQgKnRt cDsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpsaXN0OworCisJRU5URVJfRlVOQ1RJT047CisKKwkoKnBv cykrKzsKKworCWlmICh2ID09ICh2b2lkICopMSkKKwkJbGlzdCA9ICZwcHBvbDJ0cF90dW5uZWxf bGlzdDsKKwllbHNlCisJCWxpc3QgPSAmdHVubmVsLT5saXN0OworCisJdG1wID0gbGlzdC0+bmV4 dDsKKwlpZiAodG1wID09ICZwcHBvbDJ0cF90dW5uZWxfbGlzdCkKKwkJdHVubmVsID0gTlVMTDsK KwllbHNlCisJCXR1bm5lbCA9IGxpc3RfZW50cnkodG1wLCBzdHJ1Y3QgcHBwb2wydHBfdHVubmVs LCBsaXN0KTsKKworCUVYSVRfRlVOQ1RJT047CisKKwlyZXR1cm4gdHVubmVsOworfQorCitzdGF0 aWMgdm9pZCBwcHBvbDJ0cF9wcm9jX3N0b3Aoc3RydWN0IHNlcV9maWxlICpwLCB2b2lkICp2KQor eworCXN0cnVjdCBwcHBvbDJ0cF90dW5uZWwgKnR1bm5lbCA9IHY7CisKKwlFTlRFUl9GVU5DVElP TjsKKworCWlmICh0dW5uZWwgIT0gTlVMTCkKKwkJc29ja19wdXQodHVubmVsLT5zb2NrKTsKKwor CUVYSVRfRlVOQ1RJT047Cit9CisKK3N0YXRpYyBpbnQgcHBwb2wydHBfcHJvY19zaG93KHN0cnVj dCBzZXFfZmlsZSAqbSwgdm9pZCAqdikKK3sKKwlzdHJ1Y3QgcHBwb2wydHBfdHVubmVsICp0dW5u ZWwgPSB2OworCXN0cnVjdCBwcHBvbDJ0cF9zZXNzaW9uICpzZXNzaW9uOworCXN0cnVjdCBobGlz dF9ub2RlICp3YWxrOworCXN0cnVjdCBobGlzdF9ub2RlICp0bXA7CisJaW50IGk7CisKKwlFTlRF Ul9GVU5DVElPTjsKKworCS8qIGRpc3BsYXkgaGVhZGVyIG9uIGxpbmUgMSAqLworCWlmICh2ID09 ICh2b2lkICopMSkgeworCQlzZXFfcHV0cyhtLCAiUFBQb0wyVFAgZHJpdmVyIGluZm8sICIgUFBQ T0wyVFBfRFJWX1ZFUlNJT04gIlxuIik7CisJCXNlcV9wdXRzKG0sICJUVU5ORUwgbmFtZSwgdXNl ci1kYXRhLW9rICIKKwkJCSAic2Vzc2lvbi1jb3VudCBtYWdpYy1va1xuIik7CisJCXNlcV9wdXRz KG0sICIgZGVidWcgdHgtcGt0cy9ieXRlcy9lcnJzIHJ4LXBrdHMvYnl0ZXMvZXJyc1xuIik7CisJ CXNlcV9wdXRzKG0sICIgIFNFU1NJT04gbmFtZSwgYWRkci9wb3J0IHNyYy10aWQvc2lkICIKKwkJ CSAiZGVzdC10aWQvc2lkIHN0YXRlIHVzZXItZGF0YS1vayBtYWdpYy1va1xuIik7CisJCXNlcV9w dXRzKG0sICIgICBtdHUvbXJ1L3JjdnNlcS9zZW5kc2VxL2xucyBkZWJ1ZyByZW9yZGVydG9cbiIp OworCQlzZXFfcHV0cyhtLCAiICAgbnIvbnMgdHgtcGt0cy9ieXRlcy9lcnJzIHJ4LXBrdHMvYnl0 ZXMvZXJyc1xuIik7CisJCWdvdG8gb3V0OworCX0KKworCXNlcV9wcmludGYobSwgIlRVTk5FTCAn JXMnLCAlYyAlZCBNQUdJQyAlc1xuIiwgCisJCSAgIHR1bm5lbC0+bmFtZSwKKwkJICAgKHR1bm5l bCA9PSB0dW5uZWwtPnNvY2stPnNrX3VzZXJfZGF0YSkgPyAnWSc6J04nLAorCQkgICBhdG9taWNf cmVhZCgmdHVubmVsLT5zZXNzaW9uX2NvdW50KSwKKwkJICAgKHR1bm5lbC0+bWFnaWMgPT0gTDJU UF9UVU5ORUxfTUFHSUMpID8gIk9LIiA6ICJCQUQiKTsKKwlzZXFfcHJpbnRmKG0sICIgJTA4eCAl dS8ldS8ldSAldS8ldS8ldVxuIiwKKwkJICAgdHVubmVsLT5kZWJ1ZywKKwkJICAgdHVubmVsLT5z dGF0cy50eF9wYWNrZXRzLCB0dW5uZWwtPnN0YXRzLnR4X2J5dGVzLCAKKwkJICAgdHVubmVsLT5z dGF0cy50eF9lcnJvcnMsCisJCSAgIHR1bm5lbC0+c3RhdHMucnhfcGFja2V0cywgdHVubmVsLT5z dGF0cy5yeF9ieXRlcywgCisJCSAgIHR1bm5lbC0+c3RhdHMucnhfZXJyb3JzKTsKKworCWlmICh0 dW5uZWwtPm1hZ2ljICE9IEwyVFBfVFVOTkVMX01BR0lDKSB7CisJCXNlcV9wdXRzKG0sICIqKiog QWJvcnRpbmcgKioqXG4iKTsKKwkJZ290byBvdXQ7CisJfQorCisJZm9yIChpID0gMDsgaSA8IFBQ UE9MMlRQX0hBU0hfU0laRTsgaSsrKSB7CisJCWhsaXN0X2Zvcl9lYWNoX3NhZmUod2FsaywgdG1w LCAmdHVubmVsLT5zZXNzaW9uX2hsaXN0W2ldKSB7CisJCQlzZXNzaW9uID0gaGxpc3RfZW50cnko d2Fsaywgc3RydWN0IHBwcG9sMnRwX3Nlc3Npb24sIGhsaXN0KTsKKwkJCXNlcV9wcmludGYobSwg IiAgU0VTU0lPTiAnJXMnICUwOFgvJWQgJTA0WC8lMDRYIC0+ICIKKwkJCQkgICAiJTA0WC8lMDRY ICVkICVjIE1BR0lDICVzXG4iLAorCQkJCSAgIHNlc3Npb24tPm5hbWUsCisJCQkJICAgaHRvbmwo c2Vzc2lvbi0+dHVubmVsX2FkZHIuYWRkci5zaW5fYWRkci5zX2FkZHIpLAorCQkJCSAgIGh0b25z KHNlc3Npb24tPnR1bm5lbF9hZGRyLmFkZHIuc2luX3BvcnQpLAorCQkJCSAgIHNlc3Npb24tPnR1 bm5lbF9hZGRyLnNfdHVubmVsLCAKKwkJCQkgICBzZXNzaW9uLT50dW5uZWxfYWRkci5zX3Nlc3Np b24sCisJCQkJICAgc2Vzc2lvbi0+dHVubmVsX2FkZHIuZF90dW5uZWwsIAorCQkJCSAgIHNlc3Np b24tPnR1bm5lbF9hZGRyLmRfc2Vzc2lvbiwKKwkJCQkgICBzZXNzaW9uLT5zb2NrLT5za19zdGF0 ZSwKKwkJCQkgICAoc2Vzc2lvbiA9PSBzZXNzaW9uLT5zb2NrLT5za191c2VyX2RhdGEpID8gCisJ CQkJICAgJ1knIDogJ04nLAorCQkJCSAgIChzZXNzaW9uLT5tYWdpYyA9PSBMMlRQX1NFU1NJT05f TUFHSUMpID8gCisJCQkJICAgIk9LIiA6ICJCQUQiKTsKKworCQkJc2VxX3ByaW50ZihtLCAiICAg JWQvJWQvJWMvJWMvJXMgJTA4eCAlZFxuIiwKKwkJCQkgICBzZXNzaW9uLT5tdHUsIHNlc3Npb24t Pm1ydSwgCisJCQkJICAgc2Vzc2lvbi0+cmVjdl9zZXEgPyAnUicgOiAnLScsCisJCQkJICAgc2Vz c2lvbi0+c2VuZF9zZXEgPyAnUycgOiAnLScsCisJCQkJICAgc2Vzc2lvbi0+bG5zX21vZGUgPyAi TE5TIiA6ICJMQUMiLAorCQkJCSAgIHNlc3Npb24tPmRlYnVnLAorCQkJCSAgIEpJRkZJRVNfVE9f TVMoc2Vzc2lvbi0+cmVvcmRlcl90aW1lb3V0KSk7CisJCQlzZXFfcHJpbnRmKG0sICIgICAlaHUv JWh1ICV1LyV1LyV1ICV1LyV1LyV1XG4iLAorCQkJCSAgIHNlc3Npb24tPm5yLCBzZXNzaW9uLT5u cywKKwkJCQkgICBzZXNzaW9uLT5zdGF0cy50eF9wYWNrZXRzLCAKKwkJCQkgICBzZXNzaW9uLT5z dGF0cy50eF9ieXRlcywgCisJCQkJICAgc2Vzc2lvbi0+c3RhdHMudHhfZXJyb3JzLAorCQkJCSAg IHNlc3Npb24tPnN0YXRzLnJ4X3BhY2tldHMsIAorCQkJCSAgIHNlc3Npb24tPnN0YXRzLnJ4X2J5 dGVzLCAKKwkJCQkgICBzZXNzaW9uLT5zdGF0cy5yeF9lcnJvcnMpOworCisJCQlpZiAoc2Vzc2lv bi0+bWFnaWMgIT0gTDJUUF9TRVNTSU9OX01BR0lDKSB7CisJCQkJc2VxX3B1dHMobSwgIioqKiBB Ym9ydGluZyAqKipcbiIpOworCQkJCWdvdG8gb3V0OworCQkJfQkKKwkJfQorCX0KK291dDoKKwlz ZXFfcHV0cyhtLCAiXG4iKTsKKworCUVYSVRfRlVOQ1RJT047CisKKwlyZXR1cm4gMDsKK30KKwor I2VuZGlmIC8qIENPTkZJR19QUk9DX0ZTICovCisKKy8qKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorICog SW5pdCBhbmQgY2xlYW51cAorICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworCitzdGF0aWMgc3RydWN0 IHByb3RvX29wcyBwcHBvbDJ0cF9vcHMgPSB7CisJLmZhbWlseQkJPSBBRl9QUFBPWCwKKwkub3du ZXIJCT0gVEhJU19NT0RVTEUsCisJLnJlbGVhc2UJPSBwcHBvbDJ0cF9yZWxlYXNlLAorCS5iaW5k CQk9IHNvY2tfbm9fYmluZCwKKwkuY29ubmVjdAk9IHBwcG9sMnRwX2Nvbm5lY3QsCisJLnNvY2tl dHBhaXIJPSBzb2NrX25vX3NvY2tldHBhaXIsCisJLmFjY2VwdAkJPSBzb2NrX25vX2FjY2VwdCwK KwkuZ2V0bmFtZQk9IHBwcG9sMnRwX2dldG5hbWUsCisJLnBvbGwJCT0gZGF0YWdyYW1fcG9sbCwK KwkubGlzdGVuCQk9IHNvY2tfbm9fbGlzdGVuLAorCS5zaHV0ZG93bgk9IHNvY2tfbm9fc2h1dGRv d24sCisJLnNldHNvY2tvcHQJPSBwcHBvbDJ0cF9zZXRzb2Nrb3B0LAorCS5nZXRzb2Nrb3B0CT0g cHBwb2wydHBfZ2V0c29ja29wdCwKKwkuc2VuZG1zZwk9IHBwcG9sMnRwX3NlbmRtc2csCisJLnJl Y3Ztc2cJPSBwcHBvbDJ0cF9yZWN2bXNnLAorCS5tbWFwCQk9IHNvY2tfbm9fbW1hcAorfTsKKwor c3RydWN0IHBwcG94X3Byb3RvIHBwcG9sMnRwX3Byb3RvID0geworCS5jcmVhdGUJCT0gcHBwb2wy dHBfY3JlYXRlLAorCS5pb2N0bAkJPSBwcHBvbDJ0cF9pb2N0bAorfTsKKworaW50IF9faW5pdCBw cHBvbDJ0cF9pbml0KHZvaWQpCit7CisJaW50IGVyciA9IHJlZ2lzdGVyX3BwcG94X3Byb3RvKFBY X1BST1RPX09MMlRQLCAmcHBwb2wydHBfcHJvdG8pOworCisJaWYgKGVyciA9PSAwKSB7CisjaWZk ZWYgQ09ORklHX1BST0NfRlMKKwkJcHBwb2wydHBfcHJvYyA9IGNyZWF0ZV9wcm9jX2VudHJ5KCJw cHBvbDJ0cCIsIDAsIHByb2NfbmV0KTsKKwkJaWYgKCFwcHBvbDJ0cF9wcm9jKSB7CisJCQlyZXR1 cm4gLUVOT01FTTsKKwkJfQorCQlwcHBvbDJ0cF9wcm9jLT5wcm9jX2ZvcHMgPSAmcHBwb2wydHBf cHJvY19mb3BzOworI2VuZGlmIC8qIENPTkZJR19QUk9DX0ZTICovCisJCXByaW50ayhLRVJOX0lO Rk8gIlBQUG9MMlRQIGtlcm5lbCBkcml2ZXIsICVzXG4iLAorCQkgICAgICAgUFBQT0wyVFBfRFJW X1ZFUlNJT04pOworCX0KKworCXJldHVybiBlcnI7Cit9CisKK3ZvaWQgX19leGl0IHBwcG9sMnRw X2V4aXQodm9pZCkKK3sKKwl1bnJlZ2lzdGVyX3BwcG94X3Byb3RvKFBYX1BST1RPX09MMlRQKTsK KyNpZmRlZiBDT05GSUdfUFJPQ19GUworCXJlbW92ZV9wcm9jX2VudHJ5KCJwcHBvbDJ0cCIsIHBy b2NfbmV0KTsKKyNlbmRpZgorfQorCittb2R1bGVfaW5pdChwcHBvbDJ0cF9pbml0KTsKK21vZHVs ZV9leGl0KHBwcG9sMnRwX2V4aXQpOworCitNT0RVTEVfQVVUSE9SKCJNYXJ0aWpuIHZhbiBPb3N0 ZXJob3V0IDxrbGVwdG9nQHN2YW5hLm9yZz4iKTsKK01PRFVMRV9ERVNDUklQVElPTigiUFBQIG92 ZXIgTDJUUCBvdmVyIFVEUCwgIiBQUFBPTDJUUF9EUlZfVkVSU0lPTik7CitNT0RVTEVfTElDRU5T RSgiR1BMIik7CmRpZmYgLU5hdXIgbGludXgtMi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvaWZf cHBwLmggbGludXgtMi42LjguMS9pbmNsdWRlL2xpbnV4L2lmX3BwcC5oCi0tLSBsaW51eC0yLjYu OC4xLm9yaWcvaW5jbHVkZS9saW51eC9pZl9wcHAuaAkyMDA0LTA4LTE0IDExOjU2OjIyLjAwMDAw MDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9pbmNsdWRlL2xpbnV4L2lmX3BwcC5oCTIwMDQt MDktMjAgMTI6MTI6MjguMDAwMDAwMDAwICswMTAwCkBAIC0xMDcsNiArMTA3LDIxIEBACiAJc3Ry dWN0IHBwcF9jb21wX3N0YXRzIHN0YXRzOwogfTsKIAorLyogRm9yIFBQUElPQ0dMMlRQU1RBVFMg Ki8KK3N0cnVjdCBwcHBvbDJ0cF9pb2Nfc3RhdHMgeworCV9fdTE2CXR1bm5lbF9pZDsJLyogcmVk dW5kYW50ICovCisJX191MTYJc2Vzc2lvbl9pZDsJLyogaWYgemVybywgZ2V0IHR1bm5lbCBzdGF0 cyAqLworCV9fdTMyCXR4X3BhY2tldHM7CisJX191MzIJdHhfYnl0ZXM7CisJX191MzIJdHhfZXJy b3JzOworCV9fdTMyCXJ4X3BhY2tldHM7CisJX191MzIJcnhfYnl0ZXM7CisJX191MzIJcnhfc2Vx X2Rpc2NhcmRzOworCV9fdTMyCXJ4X29vc19wYWNrZXRzOworCV9fdTMyCXJ4X2Vycm9yczsKKwlp bnQJdXNpbmdfaXBzZWM7CS8qIHZhbGlkIG9ubHkgZm9yIHNlc3Npb25faWQgPT0gMCAqLworfTsK KwogI2RlZmluZSBpZnJfX25hbWUgICAgICAgYi5pZnJfaWZybi5pZnJuX25hbWUKICNkZWZpbmUg c3RhdHNfcHRyICAgICAgIGIuaWZyX2lmcnUuaWZydV9kYXRhCiAKQEAgLTE0Myw2ICsxNTgsNyBA QAogI2RlZmluZSBQUFBJT0NESVNDT05OCV9JTygndCcsIDU3KQkJLyogZGlzY29ubmVjdCBjaGFu bmVsICovCiAjZGVmaW5lIFBQUElPQ0FUVENIQU4JX0lPVygndCcsIDU2LCBpbnQpCS8qIGF0dGFj aCB0byBwcHAgY2hhbm5lbCAqLwogI2RlZmluZSBQUFBJT0NHQ0hBTglfSU9SKCd0JywgNTUsIGlu dCkJLyogZ2V0IHBwcCBjaGFubmVsIG51bWJlciAqLworI2RlZmluZQlQUFBJT0NHTDJUUFNUQVRT IF9JT1IoJ3QnLCA1NCwgc3RydWN0IHBwcG9sMnRwX2lvY19zdGF0cykKIAogI2RlZmluZSBTSU9D R1BQUFNUQVRTICAgKFNJT0NERVZQUklWQVRFICsgMCkKICNkZWZpbmUgU0lPQ0dQUFBWRVIgICAg IChTSU9DREVWUFJJVkFURSArIDEpCS8qIE5FVkVSIGNoYW5nZSB0aGlzISEgKi8KZGlmZiAtTmF1 ciBsaW51eC0yLjYuOC4xLm9yaWcvaW5jbHVkZS9saW51eC9pZl9wcHBvbDJ0cC5oIGxpbnV4LTIu Ni44LjEvaW5jbHVkZS9saW51eC9pZl9wcHBvbDJ0cC5oCi0tLSBsaW51eC0yLjYuOC4xLm9yaWcv aW5jbHVkZS9saW51eC9pZl9wcHBvbDJ0cC5oCTE5NzAtMDEtMDEgMDE6MDA6MDAuMDAwMDAwMDAw ICswMTAwCisrKyBsaW51eC0yLjYuOC4xL2luY2x1ZGUvbGludXgvaWZfcHBwb2wydHAuaAkyMDA0 LTA5LTIwIDEyOjA3OjU5LjAwMDAwMDAwMCArMDEwMApAQCAtMCwwICsxLDY1IEBACisvKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqCisgKiBMaW51eCBQUFAgb3ZlciBMMlRQIChQUFBvTDJUUCkgU29ja2V0IElt cGxlbWVudGF0aW9uIChSRkMgMjY2MSkgCisgKgorICogVGhpcyBmaWxlIHN1cHBsaWVzIGRlZmlu aXRpb25zIHJlcXVpcmVkIGJ5IHRoZSBQUFAgb3ZlciBMMlRQIGRyaXZlcgorICogKHBwcG9sMnRw LmMpLiAgQWxsIHZlcnNpb24gaW5mb3JtYXRpb24gd3J0IHRoaXMgZmlsZSBpcyBsb2NhdGVkIGlu IHBwcG9sMnRwLmMKKyAqCisgKiBMaWNlbnNlOgorICoJCVRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IKKyAqCQltb2RpZnkgaXQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICoJCWFzIHB1 Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVyc2lvbgor ICoJCTIgb2YgdGhlIExpY2Vuc2UsIG9yIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNp b24uCisgKgorICovCisKKyNpZm5kZWYgX19MSU5VWF9JRl9QUFBPTDJUUF9ICisjZGVmaW5lIF9f TElOVVhfSUZfUFBQT0wyVFBfSAorCisjaW5jbHVkZSA8YXNtL3R5cGVzLmg+CisKKyNpZmRlZiBf X0tFUk5FTF9fCisjaW5jbHVkZSA8bGludXgvaW4uaD4KKyNlbmRpZgorCisvKiBTdHJ1Y3R1cmUg dXNlZCB0byBiaW5kKCkgdGhlIHNvY2tldCB0byBhIHBhcnRpY3VsYXIgc29ja2V0ICYgdHVubmVs ICovCitzdHJ1Y3QgcHBwb2wydHBfYWRkcgoreworCWludAlmZDsJCSAvKiBGRCBvZiBVRFAgc29j a2V0IHRvIHVzZSAqLworCQorCXN0cnVjdCBzb2NrYWRkcl9pbiBhZGRyOyAvKiBJUCBhZGRyZXNz IGFuZCBwb3J0IHRvIHNlbmQgdG8gKi8KKwkKKwlfX3UxNiBzX3R1bm5lbCwgc19zZXNzaW9uOyAg ICAvKiBGb3IgbWF0Y2hpbmcgaW5jb21pbmcgcGFja2V0cyAqLworCV9fdTE2IGRfdHVubmVsLCBk X3Nlc3Npb247ICAgIC8qIEZvciBzZW5kaW5nIG91dGdvaW5nIHBhY2tldHMgKi8KK307CisKKy8q IFNvY2tldCBvcHRpb25zOgorICogREVCVUcJLSBiaXRtYXNrIG9mIGRlYnVnIG1lc3NhZ2UgY2F0 ZWdvcmllcworICogU0VORFNFUQktIDAgPT4gZG9uJ3Qgc2VuZCBwYWNrZXRzIHdpdGggc2VxdWVu Y2UgbnVtYmVycworICoJCSAgMSA9PiBzZW5kIHBhY2tldHMgd2l0aCBzZXF1ZW5jZSBudW1iZXJz CisgKiBSRUNWU0VRCS0gMCA9PiByZWNlaXZlIHBhY2tldCBzZXF1ZW5jZSBudW1iZXJzIGFyZSBv cHRpb25hbAorICoJCSAgMSA9PiBkcm9wIHJlY2VpdmUgcGFja2V0cyB3aXRob3V0IHNlcXVlbmNl IG51bWJlcnMKKyAqIExOU01PREUJLSAwID0+IGFjdCBhcyBMQUMuCisgKgkJICAxID0+IGFjdCBh cyBMTlMuCisgKiBSRU9SREVSVE8JLSByZW9yZGVyIHRpbWVvdXQgKGluIG1pbGxpc2VjcykuIElm IDAsIGRvbid0IHRyeSB0byByZW9yZGVyLgorICovCitlbnVtIHsKKwlQUFBPTDJUUF9TT19ERUJV Rwk9IDEsCisJUFBQT0wyVFBfU09fUkVDVlNFUQk9IDIsCisJUFBQT0wyVFBfU09fU0VORFNFUQk9 IDMsCisJUFBQT0wyVFBfU09fTE5TTU9ERQk9IDQsCisJUFBQT0wyVFBfU09fUkVPUkRFUlRPCT0g NSwKK307CisKKy8qIERlYnVnIG1lc3NhZ2UgY2F0ZWdvcmllcyBmb3IgdGhlIERFQlVHIHNvY2tl dCBvcHRpb24gKi8KK2VudW0geworCVBQUE9MMlRQX01TR19ERUJVRwk9ICgxIDw8IDApLAkvKiB2 ZXJib3NlIGRlYnVnIChpZgorCQkJCQkJICogY29tcGlsZWQgaW4pICovIAorCVBQUE9MMlRQX01T R19DT05UUk9MCT0gKDEgPDwgMSksCS8qIHVzZXJzcGFjZSAtIGtlcm5lbAorCQkJCQkJICogaW50 ZXJmYWNlICovCisJUFBQT0wyVFBfTVNHX1NFUQk9ICgxIDw8IDIpLAkvKiBzZXF1ZW5jZSBudW1i ZXJzICovCisJUFBQT0wyVFBfTVNHX0RBVEEJPSAoMSA8PCAzKSwJLyogZGF0YSBwYWNrZXRzICov Cit9OworCisKKworI2VuZGlmCmRpZmYgLU5hdXIgbGludXgtMi42LjguMS5vcmlnL2luY2x1ZGUv bGludXgvaWZfcHBwb3guaCBsaW51eC0yLjYuOC4xL2luY2x1ZGUvbGludXgvaWZfcHBwb3guaAot LS0gbGludXgtMi42LjguMS5vcmlnL2luY2x1ZGUvbGludXgvaWZfcHBwb3guaAkyMDA0LTA5LTIw IDEyOjQ1OjIwLjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9pbmNsdWRlL2xpbnV4 L2lmX3BwcG94LmgJMjAwNC0wOS0yMCAxMjo0Njo0Ni4wMDAwMDAwMDAgKzAxMDAKQEAgLTI3LDYg KzI3LDcgQEAKICNpbmNsdWRlIDxhc20vc2VtYXBob3JlLmg+CiAjaW5jbHVkZSA8bGludXgvcHBw X2NoYW5uZWwuaD4KICNlbmRpZiAvKiBfX0tFUk5FTF9fICovCisjaW5jbHVkZSA8bGludXgvaWZf cHBwb2wydHAuaD4KIAogLyogRm9yIHVzZXItc3BhY2UgcHJvZ3JhbXMgdG8gcGljayB1cCB0aGVz ZSBkZWZpbml0aW9ucwogICogd2hpY2ggdGhleSB3b3VsZG4ndCBnZXQgb3RoZXJ3aXNlIHdpdGhv dXQgZGVmaW5pbmcgX19LRVJORUxfXwpAQCAtNTAsNyArNTEsOCBAQAogICogUHJvdG9jb2xzIHN1 cHBvcnRlZCBieSBBRl9QUFBPWAogICovCiAjZGVmaW5lIFBYX1BST1RPX09FCTAgLyogQ3VycmVu dGx5IGp1c3QgUFBQb0UgKi8KLSNkZWZpbmUgUFhfTUFYX1BST1RPCTEKKyNkZWZpbmUgUFhfUFJP VE9fT0wyVFAJMSAvKiBOb3cgTDJUUCBhbHNvICovCisjZGVmaW5lIFBYX01BWF9QUk9UTwkyCiAK IC8qIFRoZSB1c2Ugb2YgYSB1bmlvbiBpc24ndCB2aWFibGUgYmVjYXVzZSB0aGUgc2l6ZSBvZiB0 aGlzIHN0cnVjdAogICogbXVzdCBzdGF5IGZpeGVkIG92ZXIgdGltZSAtLSBhcHBsaWNhdGlvbnMg dXNlIHNpemVvZihzdHJ1Y3QKQEAgLTcyLDYgKzc0LDEyIEBACiAJc3RydWN0IHBwcG9lX2FkZHIg cHBwb2U7CiB9X19hdHRyaWJ1dGVfXyAoKHBhY2tlZCkpOwogCitzdHJ1Y3Qgc29ja2FkZHJfcHBw b2wydHAgeworCXNhX2ZhbWlseV90CXNhX2ZhbWlseTsJLyogYWRkcmVzcyBmYW1pbHksIEFGX1BQ UE9YICovCisJdW5zaWduZWQgaW50CXNhX3Byb3RvY29sOwkvKiBwcm90b2NvbCBpZGVudGlmaWVy ICovCisJc3RydWN0IHBwcG9sMnRwX2FkZHIgcHBwb2wydHA7Cit9X19hdHRyaWJ1dGVfXyAoKHBh Y2tlZCkpOworCiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqCiAgKgogICogaW9jdGwgaW50ZXJmYWNlIGZvciBkZWZp bmluZyBmb3J3YXJkaW5nIG9mIGNvbm5lY3Rpb25zCmRpZmYgLU5hdXIgbGludXgtMi42LjguMS5v cmlnL2luY2x1ZGUvbGludXgvc29ja2V0LmggbGludXgtMi42LjguMS9pbmNsdWRlL2xpbnV4L3Nv Y2tldC5oCi0tLSBsaW51eC0yLjYuOC4xLm9yaWcvaW5jbHVkZS9saW51eC9zb2NrZXQuaAkyMDA0 LTA4LTE0IDExOjU1OjU5LjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi42LjguMS9pbmNsdWRl L2xpbnV4L3NvY2tldC5oCTIwMDQtMDktMDEgMTc6Mzc6NTUuMDAwMDAwMDAwICswMTAwCkBAIC0y NjgsNiArMjY4LDcgQEAKICNkZWZpbmUgU09MX0lSREEgICAgICAgIDI2NgogI2RlZmluZSBTT0xf TkVUQkVVSQkyNjcKICNkZWZpbmUgU09MX0xMQwkJMjY4CisjZGVmaW5lIFNPTF9QUFBPTDJUUAky NjkKIAogLyogSVBYIG9wdGlvbnMgKi8KICNkZWZpbmUgSVBYX1RZUEUJMQpkaWZmIC1OYXVyIGxp bnV4LTIuNi44LjEub3JpZy9NQUlOVEFJTkVSUyBsaW51eC0yLjYuOC4xL01BSU5UQUlORVJTCi0t LSBsaW51eC0yLjYuOC4xLm9yaWcvTUFJTlRBSU5FUlMJMjAwNC0wOC0xNCAxMTo1NTozNC4wMDAw MDAwMDAgKzAxMDAKKysrIGxpbnV4LTIuNi44LjEvTUFJTlRBSU5FUlMJMjAwNC0wOS0yMCAxMToy Mzo0Mi4wMDAwMDAwMDAgKzAxMDAKQEAgLTE2OTQsNiArMTY5NCwxMSBAQAogTToJbW9zdHJvd3NA c3R5eC51d2F0ZXJsb28uY2EKIFM6CU1haW50YWluZWQKIAorUFBQIE9WRVIgTDJUUAorUDoJTWFy dGlqbiB2YW4gT29zdGVyaG91dAorTToJa2xlcHRvZ0BzdmFuYS5vcmcKK1M6CU1haW50YWluZWQK KwogUFJFRU1QVElCTEUgS0VSTkVMCiBQOglSb2JlcnQgTG92ZQogTToJcm1sQHRlY2g5Lm5ldAo= ---MOQ1095714704f29a8d8a0a03d7f3fed328bf7615d061-- From romieu@fr.zoreil.com Mon Sep 20 14:16:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 14:16:08 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KLFxSD026537 for ; Mon, 20 Sep 2004 14:16:02 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8KLF9vr019407; Mon, 20 Sep 2004 23:15:09 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8KLF2aI019405; Mon, 20 Sep 2004 23:15:02 +0200 Date: Mon, 20 Sep 2004 23:15:02 +0200 From: Francois Romieu To: Jeff Garzik Cc: Andy Lutomirski , Hans-Frieder Vogt , Jon Mason , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc1-bk11+ and 2.6.9-rc1-mm3,4 r8169: freeze during boot (FIX included) Message-ID: <20040920211500.GA15946@electric-eye.fr.zoreil.com> References: <200409130035.50823.hfvogt@arcor.de> <20040916070211.GA32592@electric-eye.fr.zoreil.com> <200409161320.16526.jdmason@us.ltcfwd.linux.ibm.com> <200409171043.21772.jdmason@us.ltcfwd.linux.ibm.com> <20040917160151.GA29337@electric-eye.fr.zoreil.com> <414DF773.7060402@myrealbox.com> <20040919213952.GA32570@electric-eye.fr.zoreil.com> <414E46F1.9050309@pobox.com> <20040920071743.GA7115@electric-eye.fr.zoreil.com> <414F1A8C.10803@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F1A8C.10803@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9176 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2515 Lines: 80 Jeff Garzik : [...] > Let me know what happens :) Nothing conclusive so far. I applied patch below on my 32bit system on top of current 2.6.9-rc2-mm1 + patch issued yesterday + extra hack to force PCI DAC on 32 bit system. It does not help if I force PCI DAC. It does not change anything if PCI DAC is not enabled. diff -puN drivers/net/r8169.c~r8169-145b-4 drivers/net/r8169.c --- linux-2.6.9-rc2/drivers/net/r8169.c~r8169-145b-4 2004-09-20 21:39:20.000000000 +0200 +++ linux-2.6.9-rc2-fr/drivers/net/r8169.c 2004-09-20 21:39:20.000000000 +0200 @@ -1483,6 +1483,11 @@ rtl8169_hw_start(struct net_device *dev) void *ioaddr = tp->mmio_addr; u32 i; + RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32)); + RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32)); + /* Soft reset the chip. */ RTL_W8(ChipCmd, CmdReset); @@ -1494,7 +1499,6 @@ rtl8169_hw_start(struct net_device *dev) } RTL_W8(Cfg9346, Cfg9346_Unlock); - RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); // For gigabit rtl8169 @@ -1509,24 +1513,9 @@ rtl8169_hw_start(struct net_device *dev) RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << TxInterFrameGapShift)); - tp->cp_cmd |= RTL_R16(CPlusCmd); - RTL_W16(CPlusCmd, tp->cp_cmd); - - if (tp->mac_version == RTL_GIGA_MAC_VER_D) { - dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " - "Bit-3 and bit-14 MUST be 1\n"); - tp->cp_cmd |= (1 << 14) | PCIMulRW; - RTL_W16(CPlusCmd, tp->cp_cmd); - } - tp->cur_rx = 0; - RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK)); - RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32)); - RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK)); - RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32)); RTL_W8(Cfg9346, Cfg9346_Lock); - udelay(10); RTL_W32(RxMissed, 0); @@ -1538,6 +1527,17 @@ rtl8169_hw_start(struct net_device *dev) /* Enable all known interrupts by setting the interrupt mask. */ RTL_W16(IntrMask, rtl8169_intr_mask); + tp->cp_cmd |= RTL_R16(CPlusCmd); + + if (tp->mac_version == RTL_GIGA_MAC_VER_D) { + dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " + "Bit-3 and bit-14 MUST be 1\n"); + tp->cp_cmd |= (1 << 14) | PCIMulRW; + } + + RTL_W16(CPlusCmd, tp->cp_cmd); + RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); + netif_start_queue(dev); } _ From davem@davemloft.net Mon Sep 20 14:17:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 14:17:27 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KLHKG9026874 for ; Mon, 20 Sep 2004 14:17:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9VWz-0000JD-00; Mon, 20 Sep 2004 14:17:05 -0700 Date: Mon, 20 Sep 2004 14:17:04 -0700 From: "David S. Miller" To: James Chapman , bcrl@kvack.org Cc: netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review Message-Id: <20040920141704.16085067.davem@davemloft.net> In-Reply-To: <1095714704.414f4790cd168@www.katalix.com> References: <1095714704.414f4790cd168@www.katalix.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 571 Lines: 16 On Mon, 20 Sep 2004 22:11:44 +0100 James Chapman wrote: > Attached is a revised version of the new PPP over L2TP support for > review. Thanks DaveM and Herbert for comments so far. The following > comments have been addressed in this new version: What relation does your work have to the L2TP implementation being worked on by Ben LaHaise? See: http://marc.theaimsgroup.com/?l=linux-netdev&m=109375044707414&w=2 Do we have two people working on this thing. :-/ Ben didn't post any pointers to his work so I couldn't do the comparison myself. From pp@ee.oulu.fi Mon Sep 20 14:25:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 14:25:11 -0700 (PDT) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KLP5BY027320 for ; Mon, 20 Sep 2004 14:25:06 -0700 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.13.1/8.13.1) with ESMTP id i8KLOr5j010163 for ; Tue, 21 Sep 2004 00:24:53 +0300 (EEST) Received: (from pp@localhost) by tk28.oulu.fi (8.13.0/8.13.0/Submit) id i8KLOr2Q015751 for netdev@oss.sgi.com; Tue, 21 Sep 2004 00:24:53 +0300 (EEST) Date: Tue, 21 Sep 2004 00:24:53 +0300 From: Pekka Pietikainen To: netdev@oss.sgi.com Subject: unregister_netdevice: waiting for tun6to4 to become free. Message-ID: <20040920212453.GA15392@ee.oulu.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.2i X-archive-position: 9178 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev Content-Length: 645 Lines: 15 Hiya When trying to do /etc/init.d/network stop (or reboot) my fc3test-all-updated-so-kernel-is-2.6.9-rc2-bk5ish, the thing hangs with a "unregister_netdevice: waiting for tun6to4 to become free. Usage count = 1". The 6to4 tunnel is over the kernel PPPoE tunnel in case that makes a difference What it's trying to do is /sbin/ip tunnel del tun6to4, which works just fine when run by itself, when looking at /proc/net/dev the device is no longer there at that point. I think the situation where it breaks if the ppp device it's running on top of goes down just before. Just a guess tho :-) Any obvious explanations or should I poke further? From Kai.Makisara@kolumbus.fi Mon Sep 20 14:25:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 14:25:52 -0700 (PDT) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KLPi0b027538 for ; Mon, 20 Sep 2004 14:25:45 -0700 Received: from kai.makisara.local ([80.186.76.126]) by fep06-app.kolumbus.fi with ESMTP id <20040920212532.GICX23657.fep06-app.kolumbus.fi@kai.makisara.local>; Tue, 21 Sep 2004 00:25:32 +0300 Date: Tue, 21 Sep 2004 00:25:32 +0300 (EEST) From: Kai Makisara X-X-Sender: makisara@kai.makisara.local To: "David S. Miller" cc: netdev@oss.sgi.com, ganesh.venkatesan@intel.com Subject: Re: e1000 lockup in linux 2.6.9-rc2 In-Reply-To: <20040920135606.7a0885df.davem@davemloft.net> Message-ID: References: <20040920135606.7a0885df.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9179 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Kai.Makisara@kolumbus.fi Precedence: bulk X-list: netdev Content-Length: 723 Lines: 22 On Mon, 20 Sep 2004, David S. Miller wrote: > On Mon, 20 Sep 2004 23:53:15 +0300 (EEST) > Kai Makisara wrote: > > > When I started large data transfers in 100 Mb/s network, my computer very > > soon locked totally (i.e., not responding to network, keyboard and mouse > > dead). This had not happened for several days with 2.6.9-rc2 when the > > network activity had been light (1 Mb/s DSL). > > > > Some experimentation showed that the lockups were caused by this patch > > fragment in 2.6.9-rc2: > > Please make sure you have this patch in your > tree, it should fix your problem: > I did not have this patch. Installed it and I can confirm that it fixes the problem. Thanks, -- Kai From herbert@gondor.apana.org.au Mon Sep 20 15:01:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 15:01:22 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KM1EBJ030907 for ; Mon, 20 Sep 2004 15:01:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9WCb-00029N-00; Tue, 21 Sep 2004 08:00:05 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9WBe-0006qD-00; Tue, 21 Sep 2004 07:59:06 +1000 Date: Tue, 21 Sep 2004 07:59:06 +1000 To: Pablo Neira Cc: hadi@cyberus.ca, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040920215906.GA26266@gondor.apana.org.au> References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F1E12.6010808@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9180 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 916 Lines: 27 On Mon, Sep 20, 2004 at 08:14:42PM +0200, Pablo Neira wrote: > > jamal wrote: > > >Agreed. > >For a test i typically have something adding say 10K items (actions in > >my case, but could be ipsec policies) and then try to dump them. On my > >xeon i get an overrun after about 6K items are dumped. Good. That's something we can look at easily. Dumping is meant to be self-controlling as each packet naturally stops the next one from being sent until the user has done a recvmsg. > yes, this is exactly what I've observed. > > Here a link to the tool that I use to stress netlink sockets. > > http://eurodev.net/~pablo/netlinkbench-unicast-1.0.tar.gz Thanks for the link. I'll take a look. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From laforge@gnumonks.org Mon Sep 20 15:51:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 15:52:03 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KMptZJ032125 for ; Mon, 20 Sep 2004 15:51:56 -0700 Received: from dsl-082-082-097-127.arcor-ip.net ([82.82.97.127] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9X0Y-0008QI-Vs; Tue, 21 Sep 2004 00:51:43 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9X0W-0001uG-PL; Tue, 21 Sep 2004 00:51:40 +0200 Date: Tue, 21 Sep 2004 00:51:40 +0200 From: Harald Welte To: Linux Netdev List Subject: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040920225140.GH1307@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hEi834+foqWOL7fK" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9181 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 17803 Lines: 574 --hEi834+foqWOL7fK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've recently had some problems with the neighbour cache on systems which have large layer-2 networks (such as 10/12 ethernet interfaces, most of them attached to networks with a /16 netmaks). Yes, I know, networks of that size is a bad design anyway. But at the same time there are people using such strange setups ... The current garbage collection mechanism's ultimate goal is to prevent ARP floods. It therefore never expires INCOMPLETE entries from the neighbour cache. I've seen systems in a state which is what I believe beign completely starved of neighbour cache entries, while gc is unable to evict anything =3D> increasing gc_thesh2/gc_thresh3 to large values. As a result, on systems with large networks (think of even less than 16 bit netmasks!) the neighbour table can grow quite significantly, especially if some jerk runs pktgen with random destinations, and we start expiring 'real' neighbours in favour of incomplete ones. =20 This large number of ncache entries is distributed over only 32 buckets, which is quite unsatisfactory. Especially if we consider that the distribution within the hash has been reported to be quite sub-optimal[1] Tim Gardner has already sent two patches for 2.4.x on this some time ago [1], [2] adressing this issue - but none of them was integrated. I've now ported [2] to 2.6.9-rc2-bk6, and dropped [1]. Furthermore, I've added: - neigh_hash_bits boot parameter (if not specified, auto-sizing hash based on system ram) - jenkins hash for ARP hash function, like Dave indicated [3] - make number of buckets readable via /proc/ The patch is not yet intende for mainline inclusion, since I want to have feedback on 1) should I try to use jhash for ipv6, too? 2) Dave has indicated that there should be an upper limit for hash buckets. What is considered a reasonable upper bound, even for very large systems? 3) What do you think about removing gc_interval in favour of the dynamic interval calculation, combined with the 'one bucket per gc run' approach that Tim selected? 4) Shouldn't we set gc_thresh3 automatically based on the netmassk of the interfaces we have IFF_RUNNING? =20 5) What is the proposed solution for IPv6, when you have /48 or /64 bit prefixes and systems become even more vulnerable to neighbour cache attacks? =20 6) Since everybody agrees the current scheme of bucket-sizing based on memory only is a bad idea, do we want to unify this bucket sizing code, so people have one single knob (boot option) which they can use to give the system some metrics on how large it should scale all the network hash tables? [1] http://oss.sgi.com/projects/netdev/archive/2004-03/msg00265.html [2] http://oss.sgi.com/projects/netdev/archive/2004-03/msg00250.html [3] http://oss.sgi.com/projects/netdev/archive/2004-03/msg00279.html diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/net/atm/clip.c linux-2.6.9-rc2-bk6-ncache/net/atm/clip.c --- linux-2.6.9-rc2-bk6/net/atm/clip.c 2004-09-21 00:23:16.000000000 +0200 +++ linux-2.6.9-rc2-bk6-ncache/net/atm/clip.c 2004-09-20 20:25:48.000000000= +0200 @@ -130,7 +130,7 @@ =20 /*DPRINTK("idle_timer_check\n");*/ write_lock(&clip_tbl.lock); - for (i =3D 0; i <=3D NEIGH_HASHMASK; i++) { + for (i =3D 0; i < clip_tbl.num_hash_buckets; i++) { struct neighbour **np; =20 for (np =3D &clip_tbl.hash_buckets[i]; *np;) { @@ -341,6 +341,7 @@ return 0; } =20 +static struct neigh_table clip_tbl; static u32 clip_hash(const void *pkey, const struct net_device *dev) { u32 hash_val; @@ -349,7 +350,7 @@ hash_val ^=3D (hash_val>>16); hash_val ^=3D hash_val>>8; hash_val ^=3D hash_val>>3; - hash_val =3D (hash_val^dev->ifindex)&NEIGH_HASHMASK; + hash_val =3D (hash_val^dev->ifindex)&(clip_tbl.num_hash_buckets-1); =20 return hash_val; } @@ -894,7 +895,7 @@ { void *v =3D NULL; =20 - for (; state->bucket <=3D NEIGH_HASHMASK; state->bucket++) { + for (; state->bucket < clip_tbl.num_hash_buckets; state->bucket++) { for (; state->n; state->n =3D state->n->next) { v =3D arp_vcc_walk(state, NEIGH2ENTRY(state->n), &l); if (v) diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/net/core/neighbour.c linux-2.6.9-rc2-bk6-ncache/net/core/neigh= bour.c --- linux-2.6.9-rc2-bk6/net/core/neighbour.c 2004-09-21 00:23:16.000000000 = +0200 +++ linux-2.6.9-rc2-bk6-ncache/net/core/neighbour.c 2004-09-20 22:13:56.000= 000000 +0200 @@ -12,6 +12,10 @@ * * Fixes: * Vitaly E. Lavrov releasing NULL neighbor in neigh_add. + * + * Changes: + * 2004-09-17: Make cache size dynamically sized + configurable=20 + * (Tim Gardner & Harald Welte ) */ =20 #include @@ -47,6 +51,9 @@ #define NEIGH_PRINTK2 NEIGH_PRINTK #endif =20 +static unsigned int neigh_hash_bits; +module_param(neigh_hash_bits, int, 0400); + static void neigh_timer_handler(unsigned long arg); #ifdef CONFIG_ARPD static void neigh_app_notify(struct neighbour *n); @@ -113,7 +120,7 @@ int shrunk =3D 0; int i; =20 - for (i =3D 0; i <=3D NEIGH_HASHMASK; i++) { + for (i =3D 0; i < tbl->num_hash_buckets; i++) { struct neighbour *n, **np; =20 np =3D &tbl->hash_buckets[i]; @@ -177,7 +184,7 @@ =20 write_lock_bh(&tbl->lock); =20 - for (i=3D0; i <=3D NEIGH_HASHMASK; i++) { + for (i=3D0; i < tbl->num_hash_buckets; i++) { struct neighbour *n, **np; =20 np =3D &tbl->hash_buckets[i]; @@ -204,7 +211,7 @@ =20 write_lock_bh(&tbl->lock); =20 - for (i =3D 0; i <=3D NEIGH_HASHMASK; i++) { + for (i =3D 0; i < tbl->num_hash_buckets; i++) { struct neighbour *n, **np =3D &tbl->hash_buckets[i]; =20 while ((n =3D *np) !=3D NULL) { @@ -545,9 +552,8 @@ static void neigh_periodic_timer(unsigned long arg) { struct neigh_table *tbl =3D (struct neigh_table *)arg; + struct neighbour *n, **np; unsigned long now =3D jiffies; - int i; - =20 write_lock(&tbl->lock); =20 @@ -563,41 +569,44 @@ neigh_rand_reach_time(p->base_reachable_time); } =20 - for (i =3D 0; i <=3D NEIGH_HASHMASK; i++) { - struct neighbour *n, **np; + tbl->curr_hash_bucket &=3D (tbl->num_hash_buckets-1); + np =3D &tbl->hash_buckets[tbl->curr_hash_bucket++]; =20 - np =3D &tbl->hash_buckets[i]; - while ((n =3D *np) !=3D NULL) { - unsigned state; + while ((n =3D *np) !=3D NULL) { + unsigned state; =20 - write_lock(&n->lock); + write_lock(&n->lock); =20 - state =3D n->nud_state; - if (state & (NUD_PERMANENT | NUD_IN_TIMER)) { - write_unlock(&n->lock); - goto next_elt; - } + state =3D n->nud_state; + if (state & (NUD_PERMANENT | NUD_IN_TIMER)) { + write_unlock(&n->lock); + goto next_elt; + } =20 - if (time_before(n->used, n->confirmed)) - n->used =3D n->confirmed; + if (time_before(n->used, n->confirmed)) + n->used =3D n->confirmed; =20 - if (atomic_read(&n->refcnt) =3D=3D 1 && - (state =3D=3D NUD_FAILED || - time_after(now, n->used + n->parms->gc_staletime))) { - *np =3D n->next; - n->dead =3D 1; - write_unlock(&n->lock); - neigh_release(n); - continue; - } + if (atomic_read(&n->refcnt) =3D=3D 1 && + (state =3D=3D NUD_FAILED || + time_after(now, n->used + n->parms->gc_staletime))) { + *np =3D n->next; + n->dead =3D 1; write_unlock(&n->lock); + neigh_release(n); + continue; + } + write_unlock(&n->lock); =20 next_elt: - np =3D &n->next; - } + np =3D &n->next; } - - mod_timer(&tbl->gc_timer, now + tbl->gc_interval); + /* Cycle through all hash buckets every base_reachable_time/2 ticks. + * ARP entry timeouts range from 1/2 base_reachable_time to 3/2 + * base_reachable_time. */ +=20 + mod_timer(&tbl->gc_timer, now +=20 + ((tbl->parms.base_reachable_time>>1)/(tbl->num_hash_buckets))); +=20 write_unlock(&tbl->lock); } =20 @@ -1205,6 +1214,37 @@ void neigh_table_init(struct neigh_table *tbl) { unsigned long now =3D jiffies; + unsigned int goal =3D neigh_hash_bits; + + /* Allocate a power of 2 hash buckets for each power of 2 MB of RAM. */ + if (!goal) { + unsigned int ram_mb =3D (num_physpages*PAGE_SIZE) / (1024*1024); + goal =3D 31; + while ((1< ram_mb) + { + goal--; + } + } + + tbl->hash_buckets =3D NULL; + while (goal && (!tbl->hash_buckets)) { + tbl->num_hash_buckets =3D (1<hash_buckets =3D kmalloc(sizeof(struct neighbour *) + *tbl->num_hash_buckets, GFP_ATOMIC); + goal--; + } + + if (tbl->hash_buckets =3D=3D NULL) + panic("%s: Could not allocate memory for hash buckets " + "of table %s.\n", tbl->id, __FUNCTION__); + memset(tbl->hash_buckets, 0, + sizeof(struct neighbour *)*tbl->num_hash_buckets); + + if (neigh_hash_bits &&=20 + (tbl->num_hash_buckets !=3D ((1<num_hash_buckets); =20 atomic_set(&tbl->parms.refcnt, 1); INIT_RCU_HEAD(&tbl->parms.rcu_head); @@ -1224,8 +1264,7 @@ init_timer(&tbl->gc_timer); tbl->gc_timer.data =3D (unsigned long)tbl; tbl->gc_timer.function =3D neigh_periodic_timer; - tbl->gc_timer.expires =3D now + tbl->gc_interval + - tbl->parms.reachable_time; + tbl->gc_timer.expires =3D now + 1; add_timer(&tbl->gc_timer); =20 init_timer(&tbl->proxy_timer); @@ -1439,7 +1478,7 @@ int rc, h, s_h =3D cb->args[1]; int idx, s_idx =3D idx =3D cb->args[2]; =20 - for (h =3D 0; h <=3D NEIGH_HASHMASK; h++) { + for (h =3D 0; h < tbl->num_hash_buckets; h++) { if (h < s_h) continue; if (h > s_h) @@ -1628,14 +1667,6 @@ .proc_handler =3D &proc_dointvec_userhz_jiffies, }, { - .ctl_name =3D NET_NEIGH_GC_INTERVAL, - .procname =3D "gc_interval", - .maxlen =3D sizeof(int), - .mode =3D 0644, - .proc_handler =3D &proc_dointvec_jiffies, - .strategy =3D &sysctl_jiffies, - }, - { .ctl_name =3D NET_NEIGH_GC_THRESH1, .procname =3D "gc_thresh1", .maxlen =3D sizeof(int), @@ -1656,6 +1687,13 @@ .mode =3D 0644, .proc_handler =3D &proc_dointvec, }, + { + .ctl_name =3D NET_NEIGH_NUM_HASH_BUCKETS, + .procname =3D "hash_buckets", + .maxlen =3D sizeof(int), + .mode =3D 0400, + .proc_handler =3D &proc_dointvec, + }, }, .neigh_dev =3D { { @@ -1719,10 +1757,13 @@ t->neigh_dev[0].ctl_name =3D dev->ifindex; memset(&t->neigh_vars[12], 0, sizeof(ctl_table)); } else { + /* If you listen carefully, you can actually hear this + * code suck */ t->neigh_vars[12].data =3D (int *)(p + 1); t->neigh_vars[13].data =3D (int *)(p + 1) + 1; t->neigh_vars[14].data =3D (int *)(p + 1) + 2; t->neigh_vars[15].data =3D (int *)(p + 1) + 3; + t->neigh_vars[16].data =3D (int *)(p + 1) + 4; } =20 dev_name =3D net_sysctl_strdup(dev_name_source); diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/net/decnet/dn_neigh.c linux-2.6.9-rc2-bk6-ncache/net/decnet/dn= _neigh.c --- linux-2.6.9-rc2-bk6/net/decnet/dn_neigh.c 2004-09-13 07:32:55.000000000= +0200 +++ linux-2.6.9-rc2-bk6-ncache/net/decnet/dn_neigh.c 2004-09-20 20:25:48.00= 0000000 +0200 @@ -128,7 +128,7 @@ hash_val ^=3D (hash_val >> 10); hash_val ^=3D (hash_val >> 3); =20 - return hash_val & NEIGH_HASHMASK; + return hash_val & (dn_neigh_table.num_hash_buckets-1); } =20 static int dn_neigh_construct(struct neighbour *neigh) @@ -526,7 +526,7 @@ =20 read_lock_bh(&tbl->lock); =20 - for(i =3D 0; i < NEIGH_HASHMASK; i++) { + for(i =3D 0; i < tbl->num_hash_buckets; i++) { for(neigh =3D tbl->hash_buckets[i]; neigh !=3D NULL; neigh =3D neigh->ne= xt) { if (neigh->dev !=3D dev) continue; @@ -567,7 +567,7 @@ struct neighbour *n =3D NULL; =20 for(state->bucket =3D 0; - state->bucket <=3D NEIGH_HASHMASK; + state->bucket < dn_neigh_table.num_hash_buckets; ++state->bucket) { n =3D dn_neigh_table.hash_buckets[state->bucket]; if (n) @@ -586,7 +586,7 @@ try_again: if (n) goto out; - if (++state->bucket > NEIGH_HASHMASK) + if (++state->bucket >=3D dn_neigh_table.num_hash_buckets) goto out; n =3D dn_neigh_table.hash_buckets[state->bucket]; goto try_again; diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/net/ipv4/arp.c linux-2.6.9-rc2-bk6-ncache/net/ipv4/arp.c --- linux-2.6.9-rc2-bk6/net/ipv4/arp.c 2004-09-21 00:23:16.000000000 +0200 +++ linux-2.6.9-rc2-bk6-ncache/net/ipv4/arp.c 2004-09-20 20:31:21.000000000= +0200 @@ -71,6 +71,7 @@ * arp_xmit so intermediate drivers like * bonding can change the skb before * sending (e.g. insert 8021q tag). + * Harald Welte : convert to make use of jenkins hash */ =20 #include @@ -97,6 +98,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -124,6 +126,9 @@ =20 #include =20 +static u32 arp_hash_rnd; +static int arp_hash_rnd_initted; + /* * Interface to generic neighbour cache. */ @@ -194,7 +199,6 @@ .proxy_qlen =3D 64, .locktime =3D 1 * HZ, }, - .gc_interval =3D 30 * HZ, .gc_thresh1 =3D 128, .gc_thresh2 =3D 512, .gc_thresh3 =3D 1024, @@ -223,15 +227,13 @@ =20 static u32 arp_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val =3D *(u32*)pkey; - hash_val ^=3D (hash_val>>16); - hash_val ^=3D hash_val>>8; - hash_val ^=3D hash_val>>3; - hash_val =3D (hash_val^dev->ifindex)&NEIGH_HASHMASK; + if (unlikely(!arp_hash_rnd_initted)) { + get_random_bytes(&arp_hash_rnd, 4); + arp_hash_rnd_initted =3D 1; + } =20 - return hash_val; + return (jhash_2words(*(u32 *)pkey, dev->ifindex, + arp_hash_rnd) & arp_tbl.num_hash_buckets-1); } =20 static int arp_constructor(struct neighbour *neigh) @@ -1281,7 +1283,7 @@ state->is_pneigh =3D 0; =20 for (state->bucket =3D 0; - state->bucket <=3D NEIGH_HASHMASK; + state->bucket < arp_tbl.num_hash_buckets; ++state->bucket) { n =3D arp_tbl.hash_buckets[state->bucket]; while (n && !(n->nud_state & ~NUD_NOARP)) @@ -1307,7 +1309,7 @@ =20 if (n) goto out; - if (++state->bucket > NEIGH_HASHMASK) + if (++state->bucket >=3D arp_tbl.num_hash_buckets) goto out; n =3D arp_tbl.hash_buckets[state->bucket]; goto try_again; diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/net/ipv6/ndisc.c linux-2.6.9-rc2-bk6-ncache/net/ipv6/ndisc.c --- linux-2.6.9-rc2-bk6/net/ipv6/ndisc.c 2004-09-21 00:23:16.000000000 +0200 +++ linux-2.6.9-rc2-bk6-ncache/net/ipv6/ndisc.c 2004-09-20 20:25:48.0000000= 00 +0200 @@ -147,7 +147,6 @@ .proxy_delay =3D (8 * HZ) / 10, .proxy_qlen =3D 64, }, - .gc_interval =3D 30 * HZ, .gc_thresh1 =3D 128, .gc_thresh2 =3D 512, .gc_thresh3 =3D 1024, @@ -276,7 +275,7 @@ hash_val ^=3D (hash_val>>16); hash_val ^=3D hash_val>>8; hash_val ^=3D hash_val>>3; - hash_val =3D (hash_val^dev->ifindex)&NEIGH_HASHMASK; + hash_val =3D (hash_val^dev->ifindex)&(nd_tbl.num_hash_buckets-1); =20 return hash_val; } diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/include/net/neighbour.h linux-2.6.9-rc2-bk6-ncache/include/net= /neighbour.h --- linux-2.6.9-rc2-bk6/include/net/neighbour.h 2004-09-21 00:23:16.0000000= 00 +0200 +++ linux-2.6.9-rc2-bk6-ncache/include/net/neighbour.h 2004-09-20 22:12:50.= 000000000 +0200 @@ -139,7 +139,6 @@ u8 key[0]; }; =20 -#define NEIGH_HASHMASK 0x1F #define PNEIGH_HASHMASK 0xF =20 /* @@ -160,11 +159,12 @@ void (*proxy_redo)(struct sk_buff *skb); char *id; struct neigh_parms parms; - /* HACK. gc_* shoul follow parms without a gap! */ - int gc_interval; + /* UGLY HACK. gc_* and num_hash_buckets must follow parms without a + * gap! */ int gc_thresh1; int gc_thresh2; int gc_thresh3; + int num_hash_buckets; unsigned long last_flush; struct timer_list gc_timer; struct timer_list proxy_timer; @@ -175,7 +175,8 @@ struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; struct neigh_statistics stats; - struct neighbour *hash_buckets[NEIGH_HASHMASK+1]; + struct neighbour **hash_buckets; + int curr_hash_bucket; /* For GC */ struct pneigh_entry *phash_buckets[PNEIGH_HASHMASK+1]; }; =20 diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.6= =2E9-rc2-bk6/include/linux/sysctl.h linux-2.6.9-rc2-bk6-ncache/include/linu= x/sysctl.h --- linux-2.6.9-rc2-bk6/include/linux/sysctl.h 2004-09-13 07:32:48.00000000= 0 +0200 +++ linux-2.6.9-rc2-bk6-ncache/include/linux/sysctl.h 2004-09-20 22:14:47.0= 00000000 +0200 @@ -494,7 +494,8 @@ NET_NEIGH_GC_INTERVAL=3D13, NET_NEIGH_GC_THRESH1=3D14, NET_NEIGH_GC_THRESH2=3D15, - NET_NEIGH_GC_THRESH3=3D16 + NET_NEIGH_GC_THRESH3=3D16, + NET_NEIGH_NUM_HASH_BUCKETS=3D17 }; =20 /* /proc/sys/net/ipx */ --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --hEi834+foqWOL7fK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBT178XaXGVTD0i/8RAt5LAKC0ORGeV/O5bRU/nmlkqiloqsSWwgCgrukz pJ65zugvm9UyKhBO6phUXMI= =BfqU -----END PGP SIGNATURE----- --hEi834+foqWOL7fK-- From romieu@fr.zoreil.com Mon Sep 20 16:39:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 16:40:04 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8KNdrqN003970 for ; Mon, 20 Sep 2004 16:39:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8KNaJvr021736; Tue, 21 Sep 2004 01:36:19 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8KNaASk021735; Tue, 21 Sep 2004 01:36:10 +0200 Date: Tue, 21 Sep 2004 01:36:10 +0200 From: Francois Romieu To: Jeff Garzik Cc: Hans-Frieder Vogt , Andy Lutomirski , Jon Mason , Srihari Vijayaraghavan , netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2 1/1] r8169: default on disabling PCIDAC Message-ID: <20040920233610.GB15760@electric-eye.fr.zoreil.com> References: <20040919224102.GA32577@electric-eye.fr.zoreil.com> <414F1DFD.9030008@pobox.com> <20040920190252.GA16429@electric-eye.fr.zoreil.com> <414F2B4F.3080606@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F2B4F.3080606@pobox.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9182 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 4118 Lines: 125 Jeff Garzik : [...] > It's only a one-time operation that occurs on weird 64-bit boxes :) > > I applied the using_dac stuff, but do think there is _some_ better way. Chainsaw coded patch below. It seems to be able to recover on my 32 bit system (the 'dtc' thing is not really needed). On real 64 bit host, people will have to disable NETIF_F_HIGHDMA, set an adequate dma mask and probably reallocate Tx and Rx rings (from irq context: joy and happyness). May be it would make sense to prevent allocating the rings on high memory from the start. Btw, the adapter apparently quiesce if the following sequence is not used: + tp->cp_cmd &= ~PCIDAC; + RTL_W16(CPlusCmd, tp->cp_cmd); + RTL_W8(ChipCmd, CmdReset | CmdTxEnb | CmdRxEnb); diff -puN drivers/net/r8169.c~r8169-145b-6 drivers/net/r8169.c --- linux-2.6.9-rc2/drivers/net/r8169.c~r8169-145b-6 2004-09-21 01:00:17.000000000 +0200 +++ linux-2.6.9-rc2-fr/drivers/net/r8169.c 2004-09-21 01:04:04.000000000 +0200 @@ -1483,6 +1483,11 @@ rtl8169_hw_start(struct net_device *dev) void *ioaddr = tp->mmio_addr; u32 i; + RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32)); + RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32)); + /* Soft reset the chip. */ RTL_W8(ChipCmd, CmdReset); @@ -1494,7 +1499,6 @@ rtl8169_hw_start(struct net_device *dev) } RTL_W8(Cfg9346, Cfg9346_Unlock); - RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); RTL_W8(EarlyTxThres, EarlyTxThld); // For gigabit rtl8169 @@ -1509,24 +1513,9 @@ rtl8169_hw_start(struct net_device *dev) RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << TxInterFrameGapShift)); - tp->cp_cmd |= RTL_R16(CPlusCmd); - RTL_W16(CPlusCmd, tp->cp_cmd); - - if (tp->mac_version == RTL_GIGA_MAC_VER_D) { - dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " - "Bit-3 and bit-14 MUST be 1\n"); - tp->cp_cmd |= (1 << 14) | PCIMulRW; - RTL_W16(CPlusCmd, tp->cp_cmd); - } - tp->cur_rx = 0; - RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK)); - RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32)); - RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK)); - RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32)); RTL_W8(Cfg9346, Cfg9346_Lock); - udelay(10); RTL_W32(RxMissed, 0); @@ -1538,6 +1527,17 @@ rtl8169_hw_start(struct net_device *dev) /* Enable all known interrupts by setting the interrupt mask. */ RTL_W16(IntrMask, rtl8169_intr_mask); + tp->cp_cmd |= RTL_R16(CPlusCmd); + + if (tp->mac_version == RTL_GIGA_MAC_VER_D) { + dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " + "Bit-3 and bit-14 MUST be 1\n"); + tp->cp_cmd |= (1 << 14) | PCIMulRW; + } + + RTL_W16(CPlusCmd, tp->cp_cmd); + RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb); + netif_start_queue(dev); } @@ -2056,11 +2056,31 @@ rtl8169_interrupt(int irq, void *dev_ins break; if (unlikely(status & SYSErr)) { - printk(KERN_ERR PFX "%s: PCI error (status: 0x%04x)." - " Device disabled.\n", dev->name, status); - RTL_W8(ChipCmd, 0x00); - RTL_W16(IntrMask, 0x0000); - RTL_R16(IntrMask); + struct pci_dev *pdev = tp->pci_dev; + static int dtc = 0; + u16 pci_status, pci_cmd; + + pci_read_config_word(pdev, PCI_COMMAND, &pci_cmd); + pci_write_config_word(pdev, PCI_COMMAND, 0x0157); + pci_read_config_word(pdev, PCI_STATUS, &pci_status); + pci_write_config_word(pdev, PCI_STATUS, + pci_status & 0xf800); + printk(KERN_ERR PFX + "%s: PCI error (cmd:status=0x%04x:%04x)\n", + dev->name, pci_cmd, pci_status); + + tp->cp_cmd &= ~PCIDAC; + RTL_W16(CPlusCmd, tp->cp_cmd); + RTL_W8(ChipCmd, CmdReset | CmdTxEnb | CmdRxEnb); + + if (dtc++ > 128) { + printk(KERN_ERR PFX + "%s: disabled (status: 0x%04x)\n", + dev->name, status); + RTL_W8(ChipCmd, 0x00); + RTL_W16(IntrMask, 0x0000); + RTL_R16(IntrMask); + } break; } _ From jgarzik@pobox.com Mon Sep 20 17:59:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 17:59:34 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L0xSXj009222 for ; Mon, 20 Sep 2004 17:59:29 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1C9Z00-0003WP-Sf; Tue, 21 Sep 2004 01:59:17 +0100 Message-ID: <414F7CD9.3090008@pobox.com> Date: Mon, 20 Sep 2004 20:59:05 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Pietikainen CC: netdev@oss.sgi.com Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. References: <20040920212453.GA15392@ee.oulu.fi> In-Reply-To: <20040920212453.GA15392@ee.oulu.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9183 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 506 Lines: 19 Pekka Pietikainen wrote: > Hiya > > When trying to do /etc/init.d/network stop (or reboot) my > fc3test-all-updated-so-kernel-is-2.6.9-rc2-bk5ish, the thing hangs with a > "unregister_netdevice: waiting for tun6to4 to become free. Usage count = 1". > The 6to4 tunnel is over the kernel PPPoE tunnel in case that makes a > difference I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6 router). No idea why it went away, I just assumed a more recent kernel fixed something. Jeff From herbert@gondor.apana.org.au Mon Sep 20 18:36:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 18:36:52 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L1aikl010859 for ; Mon, 20 Sep 2004 18:36:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9ZZo-0003hg-00; Tue, 21 Sep 2004 11:36:16 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9ZZM-0007Cm-00; Tue, 21 Sep 2004 11:35:48 +1000 Date: Tue, 21 Sep 2004 11:35:48 +1000 To: "David S. Miller" , netdev@oss.sgi.com, coreteam@netfilter.org Subject: [NETFILTER] Fix comment typo in ip_nat_helper Message-ID: <20040921013548.GA27679@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1116 Lines: 37 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: Here's a trivial comment fix that I noticed while tracking down an FTP/NAT issue. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/netfilter/ip_nat_helper.c 1.22 vs edited ===== --- 1.22/net/ipv4/netfilter/ip_nat_helper.c 2004-08-26 13:19:30 +10:00 +++ edited/net/ipv4/netfilter/ip_nat_helper.c 2004-09-21 11:14:52 +10:00 @@ -73,7 +73,7 @@ LOCK_BH(&ip_nat_seqofs_lock); - /* SYN adjust. If it's uninitialized, of this is after last + /* SYN adjust. If it's uninitialized, or this is after last * correction, record it: we don't handle more than one * adjustment in the window, but do deal with common case of a * retransmit */ --tKW2IUtsqtDRztdT-- From herbert@gondor.apana.org.au Mon Sep 20 20:44:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 20:44:37 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L3iQtw016729 for ; Mon, 20 Sep 2004 20:44:28 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9bYk-00043t-00; Tue, 21 Sep 2004 13:43:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9bXg-0007Pe-00; Tue, 21 Sep 2004 13:42:12 +1000 Date: Tue, 21 Sep 2004 13:42:12 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-ID: <20040921034212.GA28462@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920121123.70baf895.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 593 Lines: 15 On Mon, Sep 20, 2004 at 07:11:23PM +0000, David S. Miller wrote: > > I believe I was successful in preserving existing behavior, but > I wonder if it makes sense any longer. CONFIG_IP_ROUTE_TOS > changes not one data structure. It does exactly: Yes CONFIG_IP_ROUTE_TOS has out-lived its usefulness. It has always seemed half-hearted compared to CONFIG_IP_ROUTE_FWMARK. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Paul.Hampson@anu.edu.au Mon Sep 20 23:08:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 23:08:46 -0700 (PDT) Received: from smtp.bu.net.au (obitoo.bu.net.au [203.194.23.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L68du5022341 for ; Mon, 20 Sep 2004 23:08:40 -0700 Received: from localhost (obitoo [127.0.0.1]) by smtp.bu.net.au (Postfix) with ESMTP id D02C22F004C for ; Tue, 21 Sep 2004 16:08:26 +1000 (EST) Received: from smtp.bu.net.au ([127.0.0.1]) by localhost (obitoo [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30661-01-2 for ; Tue, 21 Sep 2004 16:08:26 +1000 (EST) Received: from keitarou (unknown [IPv6:2001:388:f000::2d]) by smtp.bu.net.au (Postfix) with ESMTP id 68E1D2F0035 for ; Tue, 21 Sep 2004 16:08:25 +1000 (EST) Received: from localhost (keitarou [127.0.0.1]) by keitarou (Postfix) with ESMTP id E262125F82F for ; Tue, 21 Sep 2004 16:08:24 +1000 (EST) Received: from keitarou ([127.0.0.1]) by localhost (keitarou [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14601-08 for ; Tue, 21 Sep 2004 16:08:24 +1000 (EST) Received: by keitarou (Postfix, from userid 1000) id 530B225F869; Tue, 21 Sep 2004 16:08:24 +1000 (EST) Date: Tue, 21 Sep 2004 16:08:24 +1000 To: netdev@oss.sgi.com Subject: Kernel Oops (sig11) near vlan_dev_ioctl in 2.6.8.1 Message-ID: <20040921060824.GA14840@keitarou.bubblesworth.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i From: Paul.Hampson@anu.edu.au (Paul Hampson) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at queanbeyan.bubblesworth.net X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at bu.net.au X-archive-position: 9186 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Paul.Hampson@anu.edu.au Precedence: bulk X-list: netdev Content-Length: 4687 Lines: 106 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I recently tried to upgrade my PowerPC machine (NewWorld G4) to 2.6.8.1 from 2.6.5. I am seeing a Kernel Oops (as detailed below) during the init.d stage of the boot sequence. The kernel is 2.6.8.1 + usagi-linux26-s20040816-2.6.8.1.diff.bz2 + CONNMARK + imq supprt (none of which touch vlan or sungem as I can see.) w/CONFIG_VLAN support and a sungem e1000 NIC. My initial thought was the change in buffer size for sungem from ETH_FRAME_LEN to max(mtu + ETH_HLEN + VLAN_HLEN, VLAN_ETH_FRAME_LEN) but I've satisfied myself that's not it as my mtu is 1500 so the new buffer size is _bigger_ than the old one. The VLans have an mtu of 1496 which should the same buffer size as in 2.6.5. (These mtu settings are from the 2.6.5 kernel, but I expect they came out the same when I booted 2.6.8.1) Hence, I expected it's the addition of vlan_dev_ioctl. It's hard for me to debug as the machine is a production server and I _hate_ taking it down for more than the few minutes a reboot seems to take. However, upon closer inspection, that seems to be fine too. A brief glance at snmpd's code appears to be calling either SIOCGMIIPHY or SIOCGMIIREG. So I'm left looking at the call to down() at sungem.c:2521... This's the point where I get left behind, and decided to punt to a mailing list. I'm not _positive_ it's a netdev bug, but someone else reported an oops with 2.6.8.1 last week, with the e1000 driver, also upon recipt of an ioctl that gets to vlan_dev_ioctl, and Ben Greer said that there were locking changes in the VLAN code which broke and then someone subsequently fixed, but didn't say if the fix had made it into any -rc versions or otherwise. I don't see anything immediately useful in 2.6.9-rc2. >_< (http://oss.sgi.com/archives/netdev/2004-09/msg00428.html) Anyway, here's the oops. I'm not subscribed to netdev, so please CC me on any discussion, and feel free to ask me difficult questions about my setup or anything else I've not included sufficiently in this email. I've never reported a kernel oops before, usually someone else hits it first and fixes it before I get this far. ^_^ Sep 14 02:21:08 obiwan kernel: Oops: kernel access of bad area, sig: 11 [#1] Sep 14 02:21:08 obiwan kernel: NIP: C0019D3C LR: C01C9A80 SP: D9C47D80 REGS= : d9c47cd0 TRAP: 0300 Not tainted Sep 14 02:21:08 obiwan kernel: MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR:= 11 Sep 14 02:21:08 obiwan kernel: DAR: 00000000, DSISR: 42000000 Sep 14 02:21:08 obiwan kernel: TASK =3D dba17320[1860] 'snmpd' THREAD: d9c4= 6000Last syscall: 54 Sep 14 02:21:08 obiwan kernel: GPR00: 00001032 D9C47D80 DBA17320 DB2B3240 D= 9C47D9C 00008947 65B4CB56 00000000 Sep 14 02:21:08 obiwan kernel: GPR08: 00000000 00009032 00000004 00000000 2= 8002482 1001E368 00000000 100C0000 Sep 14 02:21:08 obiwan kernel: GPR16: 00000000 7FFFEA88 100D20A8 0FF1A184 0= FF1A138 00000000 0FF1A138 00000000 Sep 14 02:21:08 obiwan kernel: GPR24: 00989680 D9C47E20 D9C47D90 D9C47E20 D= B2B3240 DBA17320 DB2B323C DB2B323C Sep 14 02:21:08 obiwan kernel: NIP [c0019d3c] add_wait_queue_exclusive+0x28= /0x38 Sep 14 02:21:08 obiwan kernel: LR [c01c9a80] __down+0x54/0xe8 Sep 14 02:21:08 obiwan kernel: Call trace: Sep 14 02:21:08 obiwan kernel: [de1a3610] gem_ioctl+0x144/0x148 [sungem] Sep 14 02:21:08 obiwan kernel: [c01c9258] vlan_dev_ioctl+0xb4/0xd4 Sep 14 02:21:08 obiwan kernel: [c013bfac] dev_ifsioc+0x390/0x400 Sep 14 02:21:08 obiwan kernel: [c013c1e8] dev_ioctl+0x1cc/0x3ac Sep 14 02:21:08 obiwan kernel: [c0180224] inet_ioctl+0xb8/0xcc Sep 14 02:21:08 obiwan kernel: [c01304f4] sock_ioctl+0xd8/0x2e0 Sep 14 02:21:08 obiwan kernel: [c006f730] sys_ioctl+0xdc/0x2f4 Sep 14 02:21:08 obiwan kernel: [c0007ce0] ret_from_syscall+0x0/0x44 --=20 ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Anu.edu.au "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. ----------------------------------------------------------- --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBT8VYexDuohKLFuARAii0AKCRBIwhHi/yT2jI5lBETcHxOjdtTgCgniaG Cbj22KK3AGNDiXDK4akgRpQ= =85Df -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From andre@tomt.net Mon Sep 20 23:22:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 23:22:53 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L6MmJJ022833 for ; Mon, 20 Sep 2004 23:22:49 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 1BA53229A1; Tue, 21 Sep 2004 08:22:37 +0200 (CEST) Message-ID: <414FC92F.6090009@tomt.net> Date: Tue, 21 Sep 2004 08:24:47 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik Cc: Pekka Pietikainen , netdev@oss.sgi.com Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. References: <20040920212453.GA15392@ee.oulu.fi> <414F7CD9.3090008@pobox.com> In-Reply-To: <414F7CD9.3090008@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 2642 Lines: 62 Jeff Garzik wrote: > I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6 > router). > > No idea why it went away, I just assumed a more recent kernel fixed > something. We've been seeing this all the time on 2.6.8.1 + "critical fixes". Pretty much anytime a router with tunneling interfaces is taken down for shutdown or reboot, it hangs spinning waiting for the tunnel devices to get freed, as ifdown gets run. It also happens when ifdown'ing them by themselfes. It's rather annoying, as doing a sysrq-boot is pretty much the only way out. Not good at all on a router :-) I'm having some problems getting this reproduced in the lab setup, but I did get a sysrq-t out of one of the affected production routers: | Sep 18 00:53:36 ed-gw1 kernel: ip S C0350720 0 1725 1723 (NOTLB) | Sep 18 00:53:36 ed-gw1: dd02ceb4 00000082 dd678190 c0350720 0000007c dec44400 dd02c000 e00fddae | Sep 18 00:53:36 ed-gw1 kernel: e25ac5eb 0000007c c14b36f0 00000199 0f055c16 0000007d dd678338 000351bf | Sep 18 00:53:36 ed-gw1 kernel: dd02cec8 dec44400 dd02c000 c026cb73 dd02cec8 000351bf e0038d9c c0356380 | Sep 18 00:53:36 ed-gw1 kernel: Call Trace: | Sep 18 00:53:36 ed-gw1 kernel: [pg0+534273454/1070096384] addrconf_ifdown+0x3e/0x250 [ipv6] | Sep 18 00:53:36 ed-gw1 kernel: [schedule_timeout+99/192] schedule_timeout+0x63/0xc0 | Sep 18 00:53:36 ed-gw1 kernel: [process_timeout+0/16] process_timeout+0x0/0x10 | Sep 18 00:53:36 ed-gw1 kernel: [netdev_wait_allrefs+85/288] netdev_wait_allrefs+0x55/0x120 | Sep 18 00:53:36 ed-gw1 kernel: [netdev_run_todo+237/512] netdev_run_todo+0xed/0x200 | Sep 18 00:53:36 ed-gw1 kernel: [dev_ioctl+438/752] dev_ioctl+0x1b6/0x2f0 | Sep 18 00:53:36 ed-gw1 kernel: [sock_ioctl+544/560] sock_ioctl+0x220/0x230 | Sep 18 00:53:36 ed-gw1 kernel: [sys_ioctl+201/576] sys_ioctl+0xc9/0x240 | Sep 18 00:53:36 ed-gw1 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 The tunnel is defined like this in /etc/network/interfaces (Debian Sarge) | auto vid | iface vid inet6 v4tunnel | address 2001:730:f:ffff::11 | netmask 126 | endpoint | local | up /sbin/ip -6 route add 2001:730:f:12::/64 dev vid metric 1 | up /sbin/ip -6 tunnel change vid ttl 255 Next time I'm doing anything I'll be sure I run ifdown in verbose mode, but my best guess is it failing at "ip tunnel del %iface%" The kernel does not have NAT and/or connection tracking loaded on this router. Connection tracking is available as modules, but not loaded. NAT is not enabled at all. From davem@davemloft.net Mon Sep 20 23:28:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 23:28:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L6S2lB023272 for ; Mon, 20 Sep 2004 23:28:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9dyX-0000tQ-00; Mon, 20 Sep 2004 23:18:05 -0700 Date: Mon, 20 Sep 2004 23:18:05 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040920231805.3f18479c.davem@davemloft.net> In-Reply-To: <20040921034212.GA28462@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 503 Lines: 13 On Tue, 21 Sep 2004 13:42:12 +1000 Herbert Xu wrote: > On Mon, Sep 20, 2004 at 07:11:23PM +0000, David S. Miller wrote: > > > > I believe I was successful in preserving existing behavior, but > > I wonder if it makes sense any longer. CONFIG_IP_ROUTE_TOS > > changes not one data structure. It does exactly: > > Yes CONFIG_IP_ROUTE_TOS has out-lived its usefulness. It has > always seemed half-hearted compared to CONFIG_IP_ROUTE_FWMARK. Ok, then I'm gonna nuke it. From davem@davemloft.net Mon Sep 20 23:29:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 23:29:33 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L6TTP3023606 for ; Mon, 20 Sep 2004 23:29:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9e98-0000uW-00; Mon, 20 Sep 2004 23:29:02 -0700 Date: Mon, 20 Sep 2004 23:29:02 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-Id: <20040920232902.620c157b.davem@davemloft.net> In-Reply-To: <20040920225140.GH1307@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 131 Lines: 5 Thanks Harald. I have some ideas about how we might refine your approach, and I'll work on that and report back to you tomorrow. From davem@davemloft.net Mon Sep 20 23:35:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 20 Sep 2004 23:35:08 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L6Z3xD024081 for ; Mon, 20 Sep 2004 23:35:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9eEa-0000vM-00; Mon, 20 Sep 2004 23:34:40 -0700 Date: Mon, 20 Sep 2004 23:34:40 -0700 From: "David S. Miller" To: Paul.Hampson@anu.edu.au (Paul Hampson) Cc: netdev@oss.sgi.com Subject: Re: Kernel Oops (sig11) near vlan_dev_ioctl in 2.6.8.1 Message-Id: <20040920233440.4aa52a81.davem@davemloft.net> In-Reply-To: <20040921060824.GA14840@keitarou.bubblesworth.net> References: <20040921060824.GA14840@keitarou.bubblesworth.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9190 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 27 Lines: 2 Has been fixed in 2.6.9-X From andre@tomt.net Tue Sep 21 00:02:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 00:02:23 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L72IbQ024921 for ; Tue, 21 Sep 2004 00:02:19 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 5F2EC229A1; Tue, 21 Sep 2004 09:02:07 +0200 (CEST) Message-ID: <414FD272.6010309@tomt.net> Date: Tue, 21 Sep 2004 09:04:18 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Welte Cc: Linux Netdev List Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> In-Reply-To: <20040920225140.GH1307@sunbeam.de.gnumonks.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 533 Lines: 10 Harald Welte wrote: > As a result, on systems with large networks (think of even less than 16 > bit netmasks!) the neighbour table can grow quite significantly, > especially if some jerk runs pktgen with random destinations, and we > start expiring 'real' neighbours in favour of incomplete ones. Or just regular worms/viruses traversing the Internet. Usually in setups I've seen, the arp cache overflows within seconds even on "smaller" prefixes like /21. The networks did get redesigned properly as a result of this however. From Robert.Olsson@data.slu.se Tue Sep 21 00:37:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 00:37:23 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L7bGwo029174 for ; Tue, 21 Sep 2004 00:37:17 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8L7b49Y032228; Tue, 21 Sep 2004 09:37:04 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id A44B890265; Tue, 21 Sep 2004 09:37:04 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16719.55840.448757.506472@robur.slu.se> Date: Tue, 21 Sep 2004 09:37:04 +0200 To: Harald Welte Cc: Linux Netdev List Subject: [PATCH + RFC] neighbour/ARP cache scalability In-Reply-To: <20040920225140.GH1307@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9192 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 278 Lines: 11 Harald Welte writes: > 5) What is the proposed solution for IPv6, when you have /48 or /64 bit > prefixes and systems become even more vulnerable to neighbour cache > attacks? Yep. Was asking the Ipv6-designers about this. A hell lot of filters or? --ro From yoshfuji@linux-ipv6.org Tue Sep 21 01:15:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 01:15:25 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L8FIfG030189 for ; Tue, 21 Sep 2004 01:15:18 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E611933CE7; Tue, 21 Sep 2004 17:15:17 +0900 (JST) Date: Tue, 21 Sep 2004 17:15:17 +0900 (JST) Message-Id: <20040921.171517.213149358.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] Fix help text From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9193 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 990 Lines: 25 Hello. Documentation/networking/tulip.txt is referred even though it is unavailable. Signed-off-by: Hideaki YOSHIFUJI ===== drivers/net/tulip/Kconfig 1.11 vs edited ===== --- 1.11/drivers/net/tulip/Kconfig 2004-06-05 00:16:07 +09:00 +++ edited/drivers/net/tulip/Kconfig 2004-09-21 17:05:00 +09:00 @@ -40,9 +40,7 @@ (smc9332dst), you can also try the driver for "Generic DECchip" cards, above. However, most people with a network card of this type will say Y here.) Do read the Ethernet-HOWTO, available from - . More specific - information is contained in - . + . To compile this driver as a module, choose M here and read . The module will -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ak@suse.de Tue Sep 21 01:58:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 01:58:42 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L8waQh031359 for ; Tue, 21 Sep 2004 01:58:37 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id F0E54C39353; Tue, 21 Sep 2004 10:58:15 +0200 (CEST) Date: Tue, 21 Sep 2004 10:58:09 +0200 From: Andi Kleen To: Harald Welte Cc: Linux Netdev List Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040921085809.GD8058@wotan.suse.de> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920225140.GH1307@sunbeam.de.gnumonks.org> X-archive-position: 9194 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 554 Lines: 12 > 6) Since everybody agrees the current scheme of bucket-sizing based on > memory only is a bad idea, do we want to unify this bucket sizing > code, so people have one single knob (boot option) which they can use > to give the system some metrics on how large it should scale all the > network hash tables? I think this is the right way to go. In fact I would go one step farther and add a single knob for all hash tables. This requires to put all the cut'n'pasted hash table setup code into a single utility function that does this. -Andi From ak@suse.de Tue Sep 21 02:04:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 02:04:47 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L94gX4031824 for ; Tue, 21 Sep 2004 02:04:43 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D9045C3D153; Tue, 21 Sep 2004 11:04:26 +0200 (CEST) Date: Tue, 21 Sep 2004 11:04:23 +0200 From: Andi Kleen To: "David S. Miller" Cc: Herbert Xu , hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-ID: <20040921090423.GE8058@wotan.suse.de> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920231805.3f18479c.davem@davemloft.net> X-archive-position: 9195 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 914 Lines: 26 On Mon, Sep 20, 2004 at 11:18:05PM -0700, David S. Miller wrote: > On Tue, 21 Sep 2004 13:42:12 +1000 > Herbert Xu wrote: > > > On Mon, Sep 20, 2004 at 07:11:23PM +0000, David S. Miller wrote: > > > > > > I believe I was successful in preserving existing behavior, but > > > I wonder if it makes sense any longer. CONFIG_IP_ROUTE_TOS > > > changes not one data structure. It does exactly: > > > > Yes CONFIG_IP_ROUTE_TOS has out-lived its usefulness. It has > > always seemed half-hearted compared to CONFIG_IP_ROUTE_FWMARK. > > Ok, then I'm gonna nuke it. Hmm, are you removing TOS support completely or just remove the CONFIG and always enable the code? [Somehow it looks to me like you and Herbert are miscommunicating ;-] I think you should remove the TOS support completely because it's obsolete with fwmark. And maybe remove it will allow some tuning later. -Andi From andreas@xss.co.at Tue Sep 21 02:14:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 02:14:50 -0700 (PDT) Received: from camus.xss.co.at (camus.xss.co.at [194.152.162.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L9Eifl032311 for ; Tue, 21 Sep 2004 02:14:45 -0700 Received: from xss.co.at (ws1.intern.xss.co.at [192.168.162.51]) by camus.xss.co.at (8.12.10/8.12.10) with ESMTP id i8L9EJbg000692; Tue, 21 Sep 2004 11:14:20 +0200 Message-ID: <414FF0EB.6020505@xss.co.at> Date: Tue, 21 Sep 2004 11:14:19 +0200 From: Andreas Haumer Organization: xS+S User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcelo Tosatti CC: "linux-kernel@vger.kernel.org" , netdev@oss.sgi.com, andrewm@uow.edu.au Subject: [PATCH][2.4.28-pre3] 3c59x builtin NIC on Asus Pundit-R X-Enigmail-Version: 0.74.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040209090006020707080303" X-archive-position: 9196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andreas@xss.co.at Precedence: bulk X-list: netdev Content-Length: 7336 Lines: 158 This is a multi-part message in MIME format. --------------040209090006020707080303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marcelo! (Sorry for crossposting, but contact adresses in driver documentation and MAINTAINERS file look a little bit outdated and I wanted the right persons to receive this mail. Methinks the maintainer infos could use some update, too... :-) The Asus Pundit-R is a nice barebone system useful to build small and compact desktop workstations. It uses an Asus P4R8L motherboard which has an ATI chipsed on board. root@install:~ {589} $ lspci 00:00.0 Host bridge: ATI Technologies Inc Radeon 9100 IGP Host Bridge (rev 02) 00:01.0 PCI bridge: ATI Technologies Inc Radeon 9100 IGP AGP Bridge 00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4347 (rev 01) 00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4348 (rev 01) 00:13.2 USB Controller: ATI Technologies Inc: Unknown device 4345 (rev 01) 00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 18) 00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4349 00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c 00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon 9100 IGP 02:08.0 Ethernet controller: 3Com Corporation 3Com 3C920B-EMB-WNM Integrated Fast Ethernet Controller (rev 40) 02:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 02:0c.0 CardBus bridge: ENE Technology Inc CB710 Cardbus Controller (rev 02) 02:0c.1 FLASH memory: ENE Technology Inc CB710 Memory Card Reader Controller With a standard Linux 2.4.x kernel (tested with x >= 26), every hardware component(*) works fine, except the built-in ethernet controller. As you can see, lspci tells us that this is an 3Com 3c920 integrated NIC. The standard 3c59x driver does not recognise this piece of hardware. But with a small patch applied, it does, and the network interface driver works without problems! root@install:~ {602} $ ifconfig eth0 Link encap:Ethernet HWaddr 00:0E:A6:C3:5A:76 inet addr:192.168.162.99 Bcast:192.168.162.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7879510 errors:0 dropped:0 overruns:1 frame:0 TX packets:7220166 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4193721321 (3999.4 Mb) TX bytes:496933951 (473.9 Mb) Interrupt:18 Base address:0xec00 root@install:~ {604} $ mii-tool -v eth0: negotiated 100baseTx-FD, link ok product info: vendor 00:00:20, model 32 rev 1 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control dmesg output: [...] 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 02:08.0: 3Com PCI 3c920B-EMB-WNM (ATI Radeon 9100 IGP) at 0xec00. Vers LK1.1.18-ac 00:0e:a6:c3:5a:76, IRQ 18 product code f800 rev 00.0 date 00-04-02 Internal config register is 1600000, transceivers 0x40. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 1, status 786d. Enabling bus-master transmits and whole-frame receives. 02:08.0: scatter/gather enabled. h/w checksums enabled [...] Detailled PCI infos about this device: [...] 02:08.0 Class 0200: 10b7:9202 (rev 40) Subsystem: 1043:8108 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- ; Tue, 21 Sep 2004 02:33:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9h19-0005U6-00; Tue, 21 Sep 2004 19:32:59 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9h12-0008TB-00; Tue, 21 Sep 2004 19:32:52 +1000 Date: Tue, 21 Sep 2004 19:32:52 +1000 To: Andi Kleen Cc: "David S. Miller" , hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-ID: <20040921093252.GA32545@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040921090423.GE8058@wotan.suse.de> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 537 Lines: 13 On Tue, Sep 21, 2004 at 11:04:23AM +0200, Andi Kleen wrote: > > I think you should remove the TOS support completely because > it's obsolete with fwmark. And maybe remove it will allow > some tuning later. If we were doing this from scratch then we should do that. But as it is we must keep the TOS code for compatibility. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dada1@cosmosbay.com Tue Sep 21 02:48:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 02:48:05 -0700 (PDT) Received: from gw1.cosmosbay.com (gw1.cosmosbay.com [62.23.185.226]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L9lx3Y002797 for ; Tue, 21 Sep 2004 02:48:00 -0700 Received: from [172.16.0.131] (edumazet-port [172.16.0.131]) (authenticated bits=0) by gw1.cosmosbay.com (8.12.9/8.12.9) with ESMTP id i8L9lgju023445 for ; Tue, 21 Sep 2004 11:47:43 +0200 Message-ID: <414FF8BF.4070302@cosmosbay.com> Date: Tue, 21 Sep 2004 11:47:43 +0200 From: Eric Dumazet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Three way TCP handshake : can we avoid the third packet ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dada1@cosmosbay.com Precedence: bulk X-list: netdev Content-Length: 821 Lines: 29 Hi I discovered today that some TCP stackes are able to initiate TCP sockets with 2 packets "only". The third packet (ACK packet) is just delayed and integrated into the data packet. 11:07:15.551507 host1.11906 > host2.80: S 1522618044:1522618044(0) win 64240 (DF) 11:07:15.551523 host2.80 > host1.11906: S 751859039:751859039(0) ack 1522618045 win 5840 (DF) 11:07:16.112451 host1.11906 > host2.80: P 1:92(91) ack 1 win 65340 11:07:16.151800 host2.80 > host1.11906: . ack 92 win 5840 (DF) It seems to be valid (host2 is linux in this tcpdump output), and saves one packet. Is it possible to achieve the same thing with linux 2.4/2.6 ? A magical setsockopt() thing like TCP_CORK, TCP_QUICKACK, after the socket() call and before the connect() ? Thank you Eric Dumazet From jchapman@katalix.com Tue Sep 21 02:55:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 02:55:50 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8L9tjYJ003249 for ; Tue, 21 Sep 2004 02:55:45 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1C9hMr-0003tG-L8; Tue, 21 Sep 2004 04:55:25 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Tue, 21 Sep 2004 10:55:25 +0100 Message-ID: <1095760525.414ffa8d111a1@www.katalix.com> Date: Tue, 21 Sep 2004 10:55:25 +0100 From: James Chapman To: "David S. Miller" , bcrl@kvack.org Cc: netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review References: <1095714704.414f4790cd168@www.katalix.com> <20040920141704.16085067.davem@davemloft.net> In-Reply-To: <20040920141704.16085067.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 3079 Lines: 83 Quoting "David S. Miller" : > On Mon, 20 Sep 2004 22:11:44 +0100 > James Chapman wrote: > > > Attached is a revised version of the new PPP over L2TP support for > > review. Thanks DaveM and Herbert for comments so far. The following > > comments have been addressed in this new version: > > What relation does your work have to the L2TP implementation > being worked on by Ben LaHaise? See: > > http://marc.theaimsgroup.com/?l=linux-netdev&m=109375044707414&w=2 > > Do we have two people working on this thing. :-/ > > Ben didn't post any pointers to his work so I couldn't do the > comparison myself. > Ben and I are working on separate projects. I was unaware of his work until I saw his netdev post a few weeks ago and mailed him privately to find out more. He's using the old Babylon (Spellcaster) proprietary PPP stack that has now been GPL'd. Unfortunately I haven't seen Ben's code yet either so I can't give a direct comparison. Ben? I did have a look at the Babylon stuff (1.6-pre3), although I've no idea how much of it Ben has changed. Here's a summary, fyi. Babylon:- - Architecture seems to be using char devices for communication with the kernel and all the PPP datapath is handled by custom virtual net_devices; the generic PPP kernel code isn't used as far as I can tell. Unfortunately it is very old (linux-2.0 era I think) but Ben has probably updated it. - Some form of L2TP support is there but it is very basic. Userspace sends data through char devices (read()/write() which the kernel char driver converts to skbs and passes on. Nasty. - PPP stack supports multiple PPP sessions in one daemon (unlike pppd). - Unlikely to integrate with the new native IPSEC stuff. OpenL2TP:- - Communication with kernel is through a new PPPoL2TP socket family. There's one socket per L2TP session so MAX_FILES limits max sessions. Works with the new native IPSEC kernel code. - Comprehensive userspace L2TP protocol implementation written from scratch, targetted specifically for enterprise VPN and embedded networking products. Efficient kernel datapath was deemed essential for this environment. - Plugin architecture allows different PPP implementations to be used. Only pppd supported so far (limits max sessions still further due to process overhead) but I'm working on a daemon to support multiple sessions -- still early stages, evaluating alternatives. Babylon or hacking pppd or start again... rp-l2tp:- - No kernel datapath (all data copied into userspace through ptys). However, it could be modified to use the socket based kernel driver. I think for general Linux L2TP support, a socket architecture makes more sense. But maybe I'm biased... :) If you want to find out more about OpenL2TP, checkout the online man pages at http://openl2tp.sourceforge.net/. BTW, I asked on linux-ppp if anyone was working on a single daemon PPP to handle multiple sessions but got zero response. Anyone on this list know of any work in this area? I hope this was useful. /james From hadi@cyberus.ca Tue Sep 21 04:03:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 04:04:07 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LB3xNu005449 for ; Tue, 21 Sep 2004 04:03:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C9iQy-0001vA-W3 for netdev@oss.sgi.com; Tue, 21 Sep 2004 07:03:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9iQy-0006OK-4W; Tue, 21 Sep 2004 07:03:44 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Andi Kleen , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040921093252.GA32545@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095764621.1049.14.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 07:03:41 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 371 Lines: 13 On Tue, 2004-09-21 at 05:32, Herbert Xu wrote: > If we were doing this from scratch then we should do that. But as it > is we must keep the TOS code for compatibility. Important for marketing to be able to claim _full_ RFC 1812 compliance. Kepp the TOS! I know it sounds silly, but there are a lot more foolish people out there addicted to glossyware. cheers, jamal From pekkas@netcore.fi Tue Sep 21 04:20:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 04:20:38 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LBKLCp009203 for ; Tue, 21 Sep 2004 04:20:23 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8LBJqc02880; Tue, 21 Sep 2004 14:19:57 +0300 Date: Tue, 21 Sep 2004 14:19:52 +0300 (EEST) From: Pekka Savola To: Harald Welte cc: Linux Netdev List Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability In-Reply-To: <20040920225140.GH1307@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1579 Lines: 37 On Tue, 21 Sep 2004, Harald Welte wrote: > 1) should I try to use jhash for ipv6, too? > > 2) Dave has indicated that there should be an upper limit for hash > buckets. What is considered a reasonable upper bound, even for very > large systems? [...] > 5) What is the proposed solution for IPv6, when you have /48 or /64 bit > prefixes and systems become even more vulnerable to neighbour cache > attacks? The situation with IPv6 is not much different than with IPv4. It's better in the sense that nobody will be portscanning the whole address space or subnets as a means to look for nodes. So, the viruses, worms, exploits etc. will need to use other techniques, so the practical need is lower. [and those nodes which try and fall over from resource exhaustion .. well, they deserve it ;-)] It's worse in the sense that there is more space in each subnet for doing aggressive probing -- but this may not be a big issue with a good algorithm and a threshold. In short, I don't think there needs to be anything special for IPv6. Just the same mechanisms as for IPv4 -- at some threshold, start garbage collecting more aggressively, using a "least-recently-used" algorithm (or the like). To constraint remote resource exhaustion exploits please make sure that the algorithm is sufficiently can also deal with the threat described at RFC 3756 section 4.3.2. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From hadi@cyberus.ca Tue Sep 21 04:36:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 04:36:22 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LBaDFq009778 for ; Tue, 21 Sep 2004 04:36:14 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C9iwA-0001ux-Oz for netdev@oss.sgi.com; Tue, 21 Sep 2004 07:35:58 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9iw8-0000fZ-Pb; Tue, 21 Sep 2004 07:35:57 -0400 Subject: Re: Advice needed on IP-over-InfiniBand driver From: jamal Reply-To: hadi@cyberus.ca To: Roland Dreier Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <52y8j5r1d6.fsf@topspin.com> References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <1095628759.1049.22.camel@jzny.localdomain> <52y8j5r1d6.fsf@topspin.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095766554.1049.49.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 07:35:54 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1278 Lines: 33 On Mon, 2004-09-20 at 00:49, Roland Dreier wrote: > jamal> Probably just easier to have his own private tables holding > jamal> reference to neighbor entries instead of polluting the > jamal> neighbor tables. Listens to ARP events - on state > jamal> transition to/from reachable state he queries his remote > jamal> manager. > > This does seem neater, but I don't know how to implement it. How does > one hook into ARP events? Are you doing the path manager from user space or kernel? Its easy to generate netlink events to user space; you could then have the manager create path from user space. > jamal> Curious though if ARP still works even when that "path" > jamal> thing hasnt been resolved. > > ARP works because we can send broadcasts even without a path to a > specific destination. (I'm leaving out the details of how IP > broadcast gets mapped to InfiniBand multicast) When the system with > the IP we're looking for receives a broadcast ARP, it can use the HW > address in the ARP request to look up a path, so it can send an ARP > reply. So the sending broadcast path is essentially existent already. Like i said above, depending on how you do this remote manager; in kernel would be a little more involved. cheers, jamal From hadi@cyberus.ca Tue Sep 21 04:48:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 04:48:08 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LBm26D011037 for ; Tue, 21 Sep 2004 04:48:02 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C9j7c-0007h1-MP for netdev@oss.sgi.com; Tue, 21 Sep 2004 07:47:48 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9j7b-0001ik-Nc; Tue, 21 Sep 2004 07:47:47 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040920215906.GA26266@gondor.apana.org.au> References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040920215906.GA26266@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095767265.1049.58.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 07:47:45 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 945 Lines: 25 On Mon, 2004-09-20 at 17:59, Herbert Xu wrote: > > jamal wrote: > > > > >Agreed. > > >For a test i typically have something adding say 10K items (actions in > > >my case, but could be ipsec policies) and then try to dump them. On my > > >xeon i get an overrun after about 6K items are dumped. > > Good. That's something we can look at easily. Dumping is meant to > be self-controlling as each packet naturally stops the next one from > being sent until the user has done a recvmsg. A get which results in a huge response (cant think of anything that fits there - I have some stuff i havent released yet which applies) will also have the same. Note by "large" implies it will overflow socket buffer (and a setsock to increase the size will delay the problem from happening). Note, that an overrun in a dump results in lost messages. Maybe we can detect that and reset the cb pointers appropriately? Have to look at the code. cheers, jamal From ak@suse.de Tue Sep 21 05:08:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 05:08:18 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LC8DxV011848 for ; Tue, 21 Sep 2004 05:08:14 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id A1E20C3E96A; Tue, 21 Sep 2004 14:07:56 +0200 (CEST) Date: Tue, 21 Sep 2004 14:07:53 +0200 From: Andi Kleen To: jamal Cc: Herbert Xu , Andi Kleen , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-ID: <20040921120753.GA20236@wotan.suse.de> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095764621.1049.14.camel@jzny.localdomain> X-archive-position: 9204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 833 Lines: 23 On Tue, Sep 21, 2004 at 07:03:41AM -0400, jamal wrote: > On Tue, 2004-09-21 at 05:32, Herbert Xu wrote: > > > If we were doing this from scratch then we should do that. But as it > > is we must keep the TOS code for compatibility. > > Important for marketing to be able to claim _full_ RFC 1812 compliance. > Kepp the TOS! > I know it sounds silly, but there are a lot more foolish people out > there addicted to glossyware. I didn't know you were addicted to glossyware, jamal ;-) You could still do routing by TOS, all you would need to do is to set up a netfilter rule that checks the TOS and set an fwmark, then route based on that. The only thing you lose is ICMP redirect routes per TOS. I'm not sure it is worth keeping. And making the FIB scale better would likely look far better in the glossyware than that. -Andi From herbert@gondor.apana.org.au Tue Sep 21 05:10:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 05:10:26 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LCAHix012208 for ; Tue, 21 Sep 2004 05:10:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9jSv-0006SB-00; Tue, 21 Sep 2004 22:09:49 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9jSj-0002qH-00; Tue, 21 Sep 2004 22:09:37 +1000 From: Herbert Xu To: hadi@cyberus.ca Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Cc: herbert@gondor.apana.org.au, pablo@eurodev.net, davem@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <1095767265.1049.58.camel@jzny.localdomain> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 21 Sep 2004 22:09:37 +1000 X-archive-position: 9205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1362 Lines: 31 jamal wrote: > > A get which results in a huge response (cant think of anything that > fits there - I have some stuff i havent released yet which applies) will > also have the same. Note by "large" implies it will overflow socket > buffer (and a setsock to increase the size will delay the problem from > happening). But congestion control doesn't help you there. We have no concept of fragmentation for netlink so the queue size has to accomodate the biggest response packet. Seriously if a single response is going to overflow your entire queue there's gotta be something wrong :) > Note, that an overrun in a dump results in lost messages. Maybe we can > detect that and reset the cb pointers appropriately? Have to look at the > code. Dumping should never result in overruns unless the application is buggy. We always allocate a one-page skb and fill it up before sending it to the user. We never start filling in the next one until the user has received the first skb and that the receive queue is less than half full. So I'm intrigued about this problem that Pablo is seeing. Let me have a play with it first. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Tue Sep 21 05:23:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 05:23:06 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LCN1VP012744 for ; Tue, 21 Sep 2004 05:23:01 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C9jfT-0003W3-KB for netdev@oss.sgi.com; Tue, 21 Sep 2004 08:22:47 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9jfS-0005CM-9Z; Tue, 21 Sep 2004 08:22:46 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040921120753.GA20236@wotan.suse.de> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> <20040921120753.GA20236@wotan.suse.de> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095769363.1048.110.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 08:22:43 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1042 Lines: 30 On Tue, 2004-09-21 at 08:07, Andi Kleen wrote: > I didn't know you were addicted to glossyware, jamal ;-) Not me, but i have the unfortunate luck (is there such a thing?) to deal with foolish people everyday ;-> Theres a lot of glossyware out there that claims they are more 1812 compliant than Linux. They specifically mention Linux. Think of a midlevel manager (who just read network magazine) and now armed with a check list;-> I know a "marketing" arguement is a weak one - but having been victimized i thought id share it. > You could still do routing by TOS, all you would need to do is to > set up a netfilter rule that checks the TOS and set an fwmark, then > route based on that. > > The only thing you lose is ICMP redirect routes per TOS. > I'm not sure it is worth keeping. And making the FIB scale > better would likely look far better in the glossyware than > that. I think FIB scalaing is first priority. In the past you could selectively turn off TOS checking at compile. Why cant we do it that way? cheers, jamal From root@chaos.analogic.com Tue Sep 21 05:55:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 05:55:54 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LCtnvF013710 for ; Tue, 21 Sep 2004 05:55:50 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i8LCswi03341; Tue, 21 Sep 2004 08:54:58 -0400 Date: Tue, 21 Sep 2004 08:54:54 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Evgeniy Polyakov cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Kernel connector - userspace <-> kernelspace "linker". In-Reply-To: <20040921124623.GA6942@uganda.factory.vocord.ru> Message-ID: References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 414 Lines: 13 Hello, This looks like a thinly veiled attempt to provide kernel hooks so that non-GPL user-mode code can execute within the kernel and trash it. I think the kernel developers are smart enough so they won't allow any priviliged kernel-mode 'callback' to user code. Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips). Note 96.31% of all statistics are fiction. From alan@lxorguk.ukuu.org.uk Tue Sep 21 06:25:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 06:25:14 -0700 (PDT) Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LDP9OC015504 for ; Tue, 21 Sep 2004 06:25:09 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i8LCMee7031095; Tue, 21 Sep 2004 13:22:40 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i8LCMcCt031094; Tue, 21 Sep 2004 13:22:38 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Kernel connector - userspace <-> kernelspace "linker". From: Alan Cox To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <20040921124623.GA6942@uganda.factory.vocord.ru> References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1095769354.30743.64.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 21 Sep 2004 13:22:35 +0100 X-archive-position: 9208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: netdev Content-Length: 509 Lines: 15 On Maw, 2004-09-21 at 13:46, Evgeniy Polyakov wrote: > Connector driver adds possibility to connect various agents using > netlink based network. > One must register callback and identificator. When driver receives > special netlink message with appropriate identificator, appropriate > callback will be called. Looks sane enough to me - and it seems to fit the mentality d-bus and HAL want to have. Alan ps: only trivial item (and really trivial) is that the printk messages should be "waiting for %s". From laforge@gnumonks.org Tue Sep 21 06:49:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 06:49:41 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LDnYh7016305 for ; Tue, 21 Sep 2004 06:49:35 -0700 Received: from dsl-082-082-103-103.arcor-ip.net ([82.82.103.103] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9l1G-0001Se-8G; Tue, 21 Sep 2004 15:49:22 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9l1C-0002Zt-HJ; Tue, 21 Sep 2004 15:49:18 +0200 Date: Tue, 21 Sep 2004 15:49:18 +0200 From: Harald Welte To: Pekka Savola Cc: Linux Netdev List Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040921134918.GK1307@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRyyN4gAPkNkeCwp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9209 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 3861 Lines: 101 --wRyyN4gAPkNkeCwp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 02:19:52PM +0300, Pekka Savola wrote: > On Tue, 21 Sep 2004, Harald Welte wrote: > > 1) should I try to use jhash for ipv6, too? > >=20 > > 2) Dave has indicated that there should be an upper limit for hash > > buckets. What is considered a reasonable upper bound, even for very > > large systems? > [...] > > 5) What is the proposed solution for IPv6, when you have /48 or /64 bit > > prefixes and systems become even more vulnerable to neighbour cache > > attacks? =20 >=20 > The situation with IPv6 is not much different than with IPv4. I disagree (see below). > It's better in the sense that nobody will be portscanning the whole=20 > address space or subnets as a means to look for nodes. =20 I agree, but people will do it as a means to DoS the routers... > So, the viruses, worms, exploits etc. will need to use other > techniques, so the practical need is lower. >=20 Just because worms cannot use this mechanism anymore doesn't mean that it will not happen, initiated manually by somebody who wants to DoS your routers. > It's worse in the sense that there is more space in each subnet for > doing aggressive probing -- but this may not be a big issue with a > good algorithm and a threshold. So what is that 'good algorithm'. The current Linux algorithm is from my point of view (only tested with ipv4) not very good when it comes to high numbers of neighbours. > In short, I don't think there needs to be anything special for IPv6. =20 > Just the same mechanisms as for IPv4 -- at some threshold, start=20 > garbage collecting more aggressively, using a "least-recently-used"=20 > algorithm (or the like).=20 Yes, but let's assume somebody floods you with 100MBit wirespeed, that's 148kpps, meaning you will have to have a limit of at least 148.800 plus the number of 'real' hosts directly attached to your system in order to cope with this. Otherwise you will end up having all your neighbour cache entries filled with INCOMPLETE entries, whose retrans_time of 1HZ is not reached yet. To do some quick calculations, this would require some 23.8 MByte RAM on a 32bit platform(!) Now what if you have multiple interfaces, or you start thinking about gigabit ethernet... > To constraint remote resource exhaustion exploits please make sure=20 > that the algorithm is sufficiently can also deal with the threat=20 > described at RFC 3756 section 4.3.2. Isn't that exactly what we're talking about? To quote from that RFC: In a way, this problem is fairly similar to the TCP SYN flooding problem. For example, rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management may be applied. So they encourage limiting the number of unresolved solicitations. We don't do that at this point, and allow all of the neighbour cache be filled with them... > Pekka Savola "You each name yourselves king, yet the --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --wRyyN4gAPkNkeCwp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUDFeXaXGVTD0i/8RAm7dAKCgTXhCF1A3RLEoL/KDizf47mRSUQCgqzAP pRV+fw0QhMDn2SLp92D+ASw= =6GBo -----END PGP SIGNATURE----- --wRyyN4gAPkNkeCwp-- From johnpol@2ka.mipt.ru Tue Sep 21 07:08:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 07:08:51 -0700 (PDT) Received: from mailer.campus.mipt.ru (mailer.campus.mipt.ru [194.85.82.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LE8gUW017065 for ; Tue, 21 Sep 2004 07:08:43 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by mailer.campus.mipt.ru (8.13.1/8.13.1) with SMTP id i8LE8gJw002093; Tue, 21 Sep 2004 18:08:42 +0400 Date: Tue, 21 Sep 2004 18:23:23 +0400 From: Evgeniy Polyakov To: root@chaos.analogic.com Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Kernel connector - userspace <-> kernelspace "linker". Message-Id: <20040921182323.45a3c9a2@zanzibar.2ka.mipt.ru> In-Reply-To: References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1549 Lines: 62 On Tue, 21 Sep 2004 08:54:54 -0400 (EDT) "Richard B. Johnson" wrote: > > Hello, > This looks like a thinly veiled attempt to provide kernel > hooks so that non-GPL user-mode code can execute within > the kernel and trash it. I think the kernel developers > are smart enough so they won't allow any priviliged > kernel-mode 'callback' to user code. Bugha-gha, I like you :) It _is_ the way to use GPL only work_queues and to put trojan horses. You've cracked me. Btw, do you know, that ioctl is the way to call "any priviliged kernel-mode 'callback' to user code" too? Actually one can implement it in it's binary only driver by itself, it just requres some netlink/skbuff knowledge. Since binary-only modules do not implement the same low level protocol twice(that's why they are binary _only_), it will not cost too much for their authors. And, last ironic note: extern void (*private_binary_only_callback)(void *); int day_of_the_hell = HZ; module_param(day_of_the_hell, int, 0); int bi() { init_timer(&bt); bt.function = private_binary_only_callback; bt.expires = jiffies + day_of_the_hell; bt.data = NULL; add_timer(&bt); } void fi() { del_timer_sync(&bt); } module_init(bi); module_exit(fi); or something... Sigh, and noone abolished EXPORT_SYMBOL_GPL(); > Cheers, > Dick Johnson > Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips). > Note 96.31% of all statistics are fiction. Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From pekkas@netcore.fi Tue Sep 21 07:11:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 07:11:17 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LEB81D017453 for ; Tue, 21 Sep 2004 07:11:09 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8LEAkk07213; Tue, 21 Sep 2004 17:10:47 +0300 Date: Tue, 21 Sep 2004 17:10:46 +0300 (EEST) From: Pekka Savola To: Harald Welte cc: Linux Netdev List Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability In-Reply-To: <20040921134918.GK1307@sunbeam.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 4777 Lines: 107 On Tue, 21 Sep 2004, Harald Welte wrote: > > The situation with IPv6 is not much different than with IPv4. > > I disagree (see below). OK, I agree that there are more significant differentes wrt. router DoS attacks because the number of routers which have /64 subnets, vulnerable to an attack, is probably larger. > > It's better in the sense that nobody will be portscanning the whole > > address space or subnets as a means to look for nodes. > > I agree, but people will do it as a means to DoS the routers... OK, if we talk about this solely from the perspective of router DoS attack, then we have slightly different constraints as if we looked only at the "host" perspective, or both from the host and router perspective. > > It's worse in the sense that there is more space in each subnet for > > doing aggressive probing -- but this may not be a big issue with a > > good algorithm and a threshold. > > So what is that 'good algorithm'. The current Linux algorithm is from > my point of view (only tested with ipv4) not very good when it comes to > high numbers of neighbours. True. > > In short, I don't think there needs to be anything special for IPv6. > > Just the same mechanisms as for IPv4 -- at some threshold, start > > garbage collecting more aggressively, using a "least-recently-used" > > algorithm (or the like). > > Yes, but let's assume somebody floods you with 100MBit wirespeed, that's > 148kpps, meaning you will have to have a limit of at least 148.800 plus > the number of 'real' hosts directly attached to your system in order to > cope with this. Otherwise you will end up having all your neighbour > cache entries filled with INCOMPLETE entries, whose retrans_time of 1HZ > is not reached yet. > > To do some quick calculations, this would require some 23.8 MByte RAM on > a 32bit platform(!) > > Now what if you have multiple interfaces, or you start thinking about > gigabit ethernet... I may be in the minority, but I don't think 24 MB is a big deal. :) Remember that the same box will need to be able to sustain 150 kpps in any case -- and the low-end boxes probably can't do it. If you get DoS'ed with that kind of flood, you're pretty much out of luck, unless someone comes up with a nice algorithm to mitigate this problem. I don't know if such has been found yet. One possibility might be keeping track of the ingress interface, and restricting ARP/ND messages to N (e.g., 100 or 1000/sec by default) per ingress interface. That would allow "internal" ND lookups to work even under an external attack. A more complex alternative might be purposefully delaying [at least on untrusted interfaces] ARP/ND requests [e.g., by 1 or 2 seconds] which request an address which does not already have any ARP/ND state at the router, then check out how many new messages have arrived during that delay period (and do some rate-limiting magic based on that). Read: store the "known valid" ND state for as long as possible, and when you get hit by the flood, you could de-prefer or ignore those requests which pertain to addresses which haven't communicated with the router in the last X [timevalue]. Another variation of the above might be two algorithms: just do every lookup as normal until a "potential attack threshold" (e.g., 1000 entries, excluding those packets allowed by the restriction below). Then, restrict ARP/ND requests to X pps (e.g., 100 pps) which do not relate to an address that already exists in the cache. This should keep ND/ARP operational under an attack for the legitimate hosts, while allowing some amount of ND traffic. There are probably other ways of mitigating the problem in a way that it does the least feasible amount of damage to the by-standers. One might look at what (if anything) others do under these circumstances, e.g., BSD's. > > To constraint remote resource exhaustion exploits please make sure > > that the algorithm is sufficiently can also deal with the threat > > described at RFC 3756 section 4.3.2. > > Isn't that exactly what we're talking about? > To quote from that RFC: > > In a way, this problem is fairly similar to the TCP SYN flooding > problem. For example, rate limiting Neighbor Solicitations, > restricting the amount of state reserved for unresolved > solicitations, and clever cache management may be applied. > > So they encourage limiting the number of unresolved solicitations. We > don't do that at this point, and allow all of the neighbour cache be > filled with them... Agreed, if we are restricting to this particular problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From johnpol@2ka.mipt.ru Tue Sep 21 07:19:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 07:19:05 -0700 (PDT) Received: from mailer.campus.mipt.ru (mailer.campus.mipt.ru [194.85.82.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LEIxlh017987 for ; Tue, 21 Sep 2004 07:19:00 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by mailer.campus.mipt.ru (8.13.1/8.13.1) with SMTP id i8LEECBt002661; Tue, 21 Sep 2004 18:14:12 +0400 Date: Tue, 21 Sep 2004 18:28:53 +0400 From: Evgeniy Polyakov To: Alan Cox Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: Kernel connector - userspace <-> kernelspace "linker". Message-Id: <20040921182853.6a104f87@zanzibar.2ka.mipt.ru> In-Reply-To: <1095769354.30743.64.camel@localhost.localdomain> References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <1095769354.30743.64.camel@localhost.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 751 Lines: 24 On Tue, 21 Sep 2004 13:22:35 +0100 Alan Cox wrote: > On Maw, 2004-09-21 at 13:46, Evgeniy Polyakov wrote: > > Connector driver adds possibility to connect various agents using > > netlink based network. > > One must register callback and identificator. When driver receives > > special netlink message with appropriate identificator, appropriate > > callback will be called. > > Looks sane enough to me - and it seems to fit the mentality d-bus and > HAL want to have. > > Alan > > ps: only trivial item (and really trivial) is that the printk messages > should be "waiting for %s". :) Sure. If it will be in the kernel, it will not contain errors. Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From buddy.lucas@gmail.com Tue Sep 21 07:21:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 07:21:44 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LELZ57018338 for ; Tue, 21 Sep 2004 07:21:35 -0700 Received: by mproxy.gmail.com with SMTP id 73so1282620rnk for ; Tue, 21 Sep 2004 07:21:18 -0700 (PDT) Received: by 10.38.2.75 with SMTP id 75mr2196590rnb; Tue, 21 Sep 2004 07:21:18 -0700 (PDT) Received: by 10.38.72.37 with HTTP; Tue, 21 Sep 2004 07:21:18 -0700 (PDT) Message-ID: <5d6b65750409210721123b0e9e@mail.gmail.com> Date: Tue, 21 Sep 2004 16:21:18 +0200 From: Buddy Lucas Reply-To: Buddy Lucas To: Alan Cox Subject: Re: Kernel connector - userspace <-> kernelspace "linker". Cc: Evgeniy Polyakov , netdev@oss.sgi.com, Linux Kernel Mailing List In-Reply-To: <1095769354.30743.64.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <1095769354.30743.64.camel@localhost.localdomain> X-archive-position: 9213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buddy.lucas@gmail.com Precedence: bulk X-list: netdev Content-Length: 1148 Lines: 37 On Tue, 21 Sep 2004 13:22:35 +0100, Alan Cox wrote: > On Maw, 2004-09-21 at 13:46, Evgeniy Polyakov wrote: > > Connector driver adds possibility to connect various agents using > > netlink based network. > > One must register callback and identificator. When driver receives > > special netlink message with appropriate identificator, appropriate > > callback will be called. > > Looks sane enough to me - and it seems to fit the mentality d-bus and > HAL want to have. > > Alan > > ps: only trivial item (and really trivial) is that the printk messages > should be "waiting for %s". > Actually, it should be "waiting for %s to become", not "became". ;-) Also -- yes, I'm really nitpicking but Evgeniy asked for it ;-) -- brace after for() should not be on a new line. And s/allocte/allocate/. That's it for me, nice one, Evgeniy. ;-) Cheers, Buddy > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From yoshfuji@linux-ipv6.org Tue Sep 21 08:14:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:14:54 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFEmun027802 for ; Tue, 21 Sep 2004 08:14:49 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8939B33CE7; Wed, 22 Sep 2004 00:14:48 +0900 (JST) Date: Wed, 22 Sep 2004 00:14:48 +0900 (JST) Message-Id: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> To: laforge@gnumonks.org Cc: pekkas@netcore.fi, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040921134918.GK1307@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> <20040921134918.GK1307@sunbeam.de.gnumonks.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1085 Lines: 30 In article <20040921134918.GK1307@sunbeam.de.gnumonks.org> (at Tue, 21 Sep 2004 15:49:18 +0200), Harald Welte says: > > The situation with IPv6 is not much different than with IPv4. > > I disagree (see below). agreed (to harald). > > It's worse in the sense that there is more space in each subnet for > > doing aggressive probing -- but this may not be a big issue with a > > good algorithm and a threshold. > > So what is that 'good algorithm'. The current Linux algorithm is from > my point of view (only tested with ipv4) not very good when it comes to > high numbers of neighbours. Well, of course, we should limit number of total entries. If we have enough memory for usual use, we should not purge the "probably reachable" routes (REACHABLE, STALE, DELAY, and PROBE) neighbours. Probably, we should split neighbour entries to two parts. - INCOMPLETE - REACHABLE, STALE, DELAY and PROBE Which means, we should NOT purge "known" entries by unknown entries. If we don't have enough memory for usual use, hmm??? Probably (weighed) LFU. --yoshfuji From roland@topspin.com Tue Sep 21 08:23:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:23:49 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFNhFD031494 for ; Tue, 21 Sep 2004 08:23:44 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Sep 2004 08:23:16 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Sep 2004 08:23:16 -0700 Received: from roland by eddore with local (Exim 4.34) id 1C9mU7-0002E1-RO; Tue, 21 Sep 2004 08:23:16 -0700 To: hadi@cyberus.ca Cc: "David S. Miller" , netdev@oss.sgi.com X-Message-Flag: Warning: May contain useful information References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <1095628759.1049.22.camel@jzny.localdomain> <52y8j5r1d6.fsf@topspin.com> <1095766554.1049.49.camel@jzny.localdomain> From: Roland Dreier Date: Tue, 21 Sep 2004 08:23:15 -0700 In-Reply-To: <1095766554.1049.49.camel@jzny.localdomain> (jamal's message of "21 Sep 2004 07:35:54 -0400") Message-ID: <523c1br6ho.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 21 Sep 2004 15:23:16.0181 (UTC) FILETIME=[EAB26850:01C49FEE] X-archive-position: 9215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 1188 Lines: 26 jamal> Are you doing the path manager from user space or kernel? jamal> Its easy to generate netlink events to user space; you jamal> could then have the manager create path from user space. The subnet manager (== big application that assigns paths to everyone on a fabric, etc) will be in user space running on a single node. But I would prefer to have the IPoIB driver be contained within the kernel to avoid complications like needing to start a userspace helper from an initrd for NFS root, etc. Sending path queries to the subnet manager is pretty simple so I don't think there's an issue with having that piece of code in the kernel. Also, if the path record lookup is done in userspace, it seems the driver will be passed 20-byte hardware addresses and need to look up the path in some shadow ARP table for every packet, which doesn't seem very efficient. I'd like to understand David's approach better, since it seems he knows how to avoid that. Unfortunately I don't understand the hard_header_cache() etc. methods well enough for his original explanation to make sense to me. Hopefully he'll have time to explain in a little more detail... Thanks, Roland From Robert.Olsson@data.slu.se Tue Sep 21 08:36:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:36:31 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFaPFg031969 for ; Tue, 21 Sep 2004 08:36:26 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8LFa89Y009218; Tue, 21 Sep 2004 17:36:09 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 2106790265; Tue, 21 Sep 2004 17:36:09 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <16720.19049.100640.24977@robur.slu.se> Date: Tue, 21 Sep 2004 17:36:09 +0200 To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: laforge@gnumonks.org, pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability In-Reply-To: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> <20040921134918.GK1307@sunbeam.de.gnumonks.org> <20040922.001448.73843048.yoshfuji@linux-ipv6.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 346 Lines: 16 YOSHIFUJI Hideaki / $B5HF#1QL@(B writes: > > > The situation with IPv6 is not much different than with IPv4. > > > > I disagree (see below). > > agreed (to harald). Hello! Remember we discussed this with at OLS? Asking for my solution.I said ask at IETF as you were going there. I guess it was not discussed? Cheers. --ro From pavlic@de.ibm.com Tue Sep 21 08:53:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:53:15 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFr9rj032637 for ; Tue, 21 Sep 2004 08:53:11 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8LFqrLi148746; Tue, 21 Sep 2004 15:52:53 GMT Received: from d12ml068.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8LFqrYi069418; Tue, 21 Sep 2004 17:52:53 +0200 In-Reply-To: <20040917154619.5e384c67.davem@davemloft.net> To: netdev@oss.sgi.com, linux-net@vger.kernel.org MIME-Version: 1.0 Subject: Re: [PATCH] introducing new net device feature NETIF_F_MC_ALL X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Frank Pavlic Message-ID: Date: Tue, 21 Sep 2004 17:52:47 +0200 X-MIMETrack: Serialize by Router on D12ML068/12/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 21/09/2004 17:52:53, Serialize complete at 21/09/2004 17:52:53 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 9217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pavlic@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 2346 Lines: 85 Dave, your suggested solution would be great for me ... I'm on the way to make a new patch introducing your proposal ... Thank you ... Frank "David S. Miller" Sent by: linux-net-owner@vger.kernel.org 18.09.2004 00:46 To Frank Pavlic/Germany/IBM@IBMDE cc netdev@oss.sgi.com, linux-net@vger.kernel.org Subject Re: [PATCH] introducing new net device feature NETIF_F_MC_ALL Looks mostly fine Frank. But why don't we save you some work, we have the IP address handy therefore it's kind of silly for you to have to look it up again. Let's create a new netdev callback, something like: void (*mc_change)(struct netdev *dev, void *addr, int family, int add); Then net/ipv4/igmp.c can do something like: static void ip_mc_filter_add(struct in_device *in_dev, u32 addr) { char buf[MAX_ADDR_LEN]; struct net_device *dev = in_dev->dev; /* Checking for IFF_MULTICAST here is WRONG-WRONG-WRONG. We will get multicast token leakage, when IFF_MULTICAST is changed. This check should be done in dev->set_multicast_list routine. Something sort of: if (dev->mc_list && dev->flags&IFF_MULTICAST) { do it; } --ANK */ if (arp_mc_map(addr, buf, dev, 0) == 0) { dev_mc_add(dev,buf,dev->addr_len,0); if (dev->mc_change) dev->mc_change(dev, &addr, AF_INET, 1); } } static void ip_mc_filter_del(struct in_device *in_dev, u32 addr) { char buf[MAX_ADDR_LEN]; struct net_device *dev = in_dev->dev; if (arp_mc_map(addr, buf, dev, 0) == 0) { dev_mc_delete(dev,buf,dev->addr_len,0); if (dev->mc_change) dev->mc_change(dev, &addr, AF_INET, 0); } } And similarly for the other dev_mc_{add,delete}() call sites. - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From andre@tomt.net Tue Sep 21 08:53:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:53:34 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFrSrM032686 for ; Tue, 21 Sep 2004 08:53:29 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 3D7CD229A1 for ; Tue, 21 Sep 2004 17:53:17 +0200 (CEST) Message-ID: <41504EF0.4050208@tomt.net> Date: Tue, 21 Sep 2004 17:55:28 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: tg3 link state detection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 1004 Lines: 17 With 2.6.8(.1)+the add_pin_to_irq fix we're seeing problem with link state detection using tg3 devices. The network in question has a severe case of cable monkeys, so the link is a bit jumpy. From time to time the tg3's do not detect that the link is up again, and thus has to be rebooted (ifdown/up has not been tested due to triggerhappy non-technical on-site monkeys.) Is this a known problem? > tg3.c:v3.8 (July 14, 2004) > ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 185 > eth0: Tigon3 [partno(BCM95704A6) rev 2002 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:56:fe:4f:e7 > eth0: HostTXDS[1] RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[1] TSOcap[1] > ACPI: PCI interrupt 0000:02:00.1[B] -> GSI 17 (level, low) -> IRQ 193 > eth1: Tigon3 [partno(BCM95704A6) rev 2002 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:56:fe:4f:e8 > eth1: HostTXDS[1] RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[1] TSOcap[1] From andre@tomt.net Tue Sep 21 08:56:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:56:37 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFuWkF000959 for ; Tue, 21 Sep 2004 08:56:32 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 295BA229A1 for ; Tue, 21 Sep 2004 17:56:21 +0200 (CEST) Message-ID: <41504FA7.60400@tomt.net> Date: Tue, 21 Sep 2004 17:58:31 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: tg3 link state detection References: <41504EF0.4050208@tomt.net> In-Reply-To: <41504EF0.4050208@tomt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 1202 Lines: 25 Andre Tomt wrote: > With 2.6.8(.1)+the add_pin_to_irq fix we're seeing problem with link > state detection using tg3 devices. The network in question has a severe > case of cable monkeys, so the link is a bit jumpy. > > From time to time the tg3's do not detect that the link is up again, > and thus has to be rebooted (ifdown/up has not been tested due to > triggerhappy non-technical on-site monkeys.) > > Is this a known problem? > >> tg3.c:v3.8 (July 14, 2004) >> ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 185 >> eth0: Tigon3 [partno(BCM95704A6) rev 2002 PHY(5704)] >> (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:56:fe:4f:e7 >> eth0: HostTXDS[1] RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] >> WireSpeed[1] TSOcap[1] >> ACPI: PCI interrupt 0000:02:00.1[B] -> GSI 17 (level, low) -> IRQ 193 >> eth1: Tigon3 [partno(BCM95704A6) rev 2002 PHY(5704)] >> (PCIX:133MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:56:fe:4f:e8 >> eth1: HostTXDS[1] RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] >> WireSpeed[1] TSOcap[1] I forgot to mention, these are copper tg3 nic's, not fibre (I know the fibre negatioation code has recieved some attention post-2.6.8) From pekkas@netcore.fi Tue Sep 21 08:58:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:58:36 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFwUh6001311 for ; Tue, 21 Sep 2004 08:58:30 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8LFw5509959; Tue, 21 Sep 2004 18:58:06 +0300 Date: Tue, 21 Sep 2004 18:58:05 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: laforge@gnumonks.org, Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability In-Reply-To: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 9220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1290 Lines: 29 On Wed, 22 Sep 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > > > It's worse in the sense that there is more space in each subnet for > > > doing aggressive probing -- but this may not be a big issue with a > > > good algorithm and a threshold. > > > > So what is that 'good algorithm'. The current Linux algorithm is from > > my point of view (only tested with ipv4) not very good when it comes to > > high numbers of neighbours. > > Well, of course, we should limit number of total entries. > > If we have enough memory for usual use, > we should not purge the "probably reachable" routes > (REACHABLE, STALE, DELAY, and PROBE) neighbours. > Probably, we should split neighbour entries to two parts. > - INCOMPLETE > - REACHABLE, STALE, DELAY and PROBE > Which means, we should NOT purge "known" entries by unknown entries. This still doesn't take a stance on rate-limiting the ND/ARP packets, in case that there still is enough memory, but some kind of attack is clearly underway. Should it still be done? Consider 100Kpps of router-generated ARP/ND probes -- not good! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From yoshfuji@linux-ipv6.org Tue Sep 21 08:59:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 08:59:56 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LFxo8p001635 for ; Tue, 21 Sep 2004 08:59:50 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9A3FE33CE7; Wed, 22 Sep 2004 00:59:50 +0900 (JST) Date: Wed, 22 Sep 2004 00:59:45 +0900 (JST) Message-Id: <20040922.005945.93612032.yoshfuji@linux-ipv6.org> To: Robert.Olsson@data.slu.se Cc: laforge@gnumonks.org, pekkas@netcore.fi, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <16720.19049.100640.24977@robur.slu.se> References: <20040921134918.GK1307@sunbeam.de.gnumonks.org> <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <16720.19049.100640.24977@robur.slu.se> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 466 Lines: 12 In article <16720.19049.100640.24977@robur.slu.se> (at Tue, 21 Sep 2004 17:36:09 +0200), Robert Olsson says: > Remember we discussed this with at OLS? Asking for my solution.I said > ask at IETF as you were going there. I guess it was not discussed? Yes, I remember. I talked with KAME (*BSD) developers. I don't think that the BSD's behavior is good enough against the threats. So, I think we should find by ourselves. --yoshfuji From anton@ozlabs.org Tue Sep 21 09:00:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 09:00:18 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LG0CJ2001695 for ; Tue, 21 Sep 2004 09:00:13 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 462282BDA6; Wed, 22 Sep 2004 01:59:56 +1000 (EST) Date: Wed, 22 Sep 2004 01:55:16 +1000 From: Anton Blanchard To: Nivedita Singhvi Cc: netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040921155516.GY2825@krispykreme> References: <20040920063012.GL2825@krispykreme> <414EFD2A.5000805@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414EFD2A.5000805@us.ibm.com> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 279 Lines: 15 Hi Niv, > Hey Anton, yep, I was just debugging this. TSO mainline reworked > implementation is still not cooked. Don't worry, final state won't > be this bad :). Cool :) > Could you echo 0 > /proc/sys/net/ipv4/tcp_bic and redo test, > please? It didnt seem to help. Anton From yoshfuji@linux-ipv6.org Tue Sep 21 09:04:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 09:04:34 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LG4SQN002355 for ; Tue, 21 Sep 2004 09:04:28 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E37F333CE7; Wed, 22 Sep 2004 01:04:28 +0900 (JST) Date: Wed, 22 Sep 2004 01:04:28 +0900 (JST) Message-Id: <20040922.010428.104988024.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: laforge@gnumonks.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 766 Lines: 16 In article (at Tue, 21 Sep 2004 18:58:05 +0300 (EEST)), Pekka Savola says: > This still doesn't take a stance on rate-limiting the ND/ARP packets, > in case that there still is enough memory, but some kind of attack is > clearly underway. Should it still be done? Consider 100Kpps of > router-generated ARP/ND probes -- not good! Right. We need to do this, of course. Probably, per-ingress interface. (I mean, incoming interface which invokes NS.) Note: I think similar idea (limiting per interface) was arose during chat with Robert, Halard et. al at OLS. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From timg@tpi.com Tue Sep 21 09:39:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 09:39:48 -0700 (PDT) Received: from mail.tpi.com (mail.tpi.com [198.107.51.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LGdfdH003431 for ; Tue, 21 Sep 2004 09:39:41 -0700 Received: from [10.0.2.3] (unknown [10.0.2.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.tpi.com (Postfix) with ESMTP id E686B2DF24; Tue, 21 Sep 2004 09:57:47 -0700 (PDT) Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: Tim Gardner Reply-To: timg@tpi.com To: YOSHIFUJI Hideaki / =?UTF-8?Q?=E5=90=89=E8=97=A4=E8=8B=B1?= =?UTF-8?Q?=E6=98=8E?= Cc: pekkas@netcore.fi, laforge@gnumonks.org, netdev@oss.sgi.com In-Reply-To: <20040922.010428.104988024.yoshfuji@linux-ipv6.org> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8 Organization: TriplePoint, Inc. Message-Id: <1095784761.3934.52.camel@tim.rtg.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 10:39:21 -0600 Content-Transfer-Encoding: 8bit X-archive-position: 9224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: timg@tpi.com Precedence: bulk X-list: netdev Content-Length: 1519 Lines: 32 On Tue, 2004-09-21 at 10:04, YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article (at Tue, 21 Sep 2004 18:58:05 +0300 (EEST)), Pekka Savola says: > > > This still doesn't take a stance on rate-limiting the ND/ARP packets, > > in case that there still is enough memory, but some kind of attack is > > clearly underway. Should it still be done? Consider 100Kpps of > > router-generated ARP/ND probes -- not good! > Detecting an attack would require some kind of heuristic in the core router code. I believe that logic is better suited for an iptables filter. Why burden well guarded machines that are unikely to experience this kind of attack? I think the only thing NUD should do is limit the absolute number of NUD entries that it can create. Give it a sysctl knob for large networks, but make the default something reasonable (like 2K). I've developed a variant of the Port Scan Detector (PSD) iptables filter that combats this very problem. It only allows so many destination IP/Port pairs from a given address to be opened over time. This limits the rate at which connections can be opened as well as the absolute number. For example, on my edge routers I set the policy that no single IP source address can create more then 64 connections within a 30 second sliding window. This has made a huge impact on the ARP storms that our network used to experience. rtg -- timg@tpi.com http://www.tpi.com 406-443-5357(MT) 503-601-0234(OR) From ak@suse.de Tue Sep 21 10:36:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 10:36:53 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LHak4I005171 for ; Tue, 21 Sep 2004 10:36:47 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C3768C411A9; Tue, 21 Sep 2004 19:31:40 +0200 (CEST) Date: Tue, 21 Sep 2004 19:31:34 +0200 From: Andi Kleen To: Tim Gardner Cc: YOSHIFUJI Hideaki / ???????????? , pekkas@netcore.fi, laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040921173134.GC12132@wotan.suse.de> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> <1095784761.3934.52.camel@tim.rtg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095784761.3934.52.camel@tim.rtg.net> X-archive-position: 9225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 718 Lines: 14 > I've developed a variant of the Port Scan Detector (PSD) iptables filter > that combats this very problem. It only allows so many destination > IP/Port pairs from a given address to be opened over time. This limits > the rate at which connections can be opened as well as the absolute > number. For example, on my edge routers I set the policy that no single > IP source address can create more then 64 connections within a 30 second > sliding window. This has made a huge impact on the ARP storms that our > network used to experience. But also allows an easy DOS. Someone just has to spoof a lot of connections attempts with the source address of your primary name server or some other important service. -Andi From timg@tpi.com Tue Sep 21 10:58:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 10:58:52 -0700 (PDT) Received: from mail.tpi.com (mail.tpi.com [198.107.51.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LHwjaG006256 for ; Tue, 21 Sep 2004 10:58:45 -0700 Received: from [10.0.2.3] (unknown [10.0.2.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.tpi.com (Postfix) with ESMTP id 2D88F2DA37; Tue, 21 Sep 2004 11:16:53 -0700 (PDT) Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: Tim Gardner Reply-To: timg@tpi.com To: Andi Kleen Cc: YOSHIFUJI Hideaki / ???????????? , pekkas@netcore.fi, laforge@gnumonks.org, netdev@oss.sgi.com In-Reply-To: <20040921173134.GC12132@wotan.suse.de> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> <1095784761.3934.52.camel@tim.rtg.net> <20040921173134.GC12132@wotan.suse.de> Content-Type: text/plain Organization: TriplePoint, Inc. Message-Id: <1095789507.3934.69.camel@tim.rtg.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 11:58:27 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 9226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: timg@tpi.com Precedence: bulk X-list: netdev Content-Length: 480 Lines: 16 On Tue, 2004-09-21 at 11:31, Andi Kleen wrote: > But also allows an easy DOS. Someone just has to spoof a lot of connections > attempts with the source address of your primary name server or > some other important service. > That is what other iptables rules and filters are for. I get thousands of source address spoofs from my Internet connection every day. Network security is a layered approach. rtg -- timg@tpi.com http://www.tpi.com 406-443-5357(MT) 503-601-0234(OR) From ak@suse.de Tue Sep 21 11:15:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 11:15:54 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LIFmwC006916 for ; Tue, 21 Sep 2004 11:15:49 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 26F4AC423DD; Tue, 21 Sep 2004 20:15:32 +0200 (CEST) Date: Tue, 21 Sep 2004 20:15:25 +0200 From: Andi Kleen To: Tim Gardner Cc: Andi Kleen , YOSHIFUJI Hideaki / ???????????? , pekkas@netcore.fi, laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040921181525.GB18938@wotan.suse.de> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> <1095784761.3934.52.camel@tim.rtg.net> <20040921173134.GC12132@wotan.suse.de> <1095789507.3934.69.camel@tim.rtg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095789507.3934.69.camel@tim.rtg.net> X-archive-position: 9227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 856 Lines: 21 On Tue, Sep 21, 2004 at 11:58:27AM -0600, Tim Gardner wrote: > On Tue, 2004-09-21 at 11:31, Andi Kleen wrote: > > > But also allows an easy DOS. Someone just has to spoof a lot of connections > > attempts with the source address of your primary name server or > > some other important service. > > > > That is what other iptables rules and filters are for. I get thousands > of source address spoofs from my Internet connection every day. Network > security is a layered approach. I don't think you can eliminate the problem with more filters. Even when you can eliminate spoofing for some services you use you cannot eliminate it for all possible services your user use (unless you get rid of spoofing in the whole internet or you never talk to any services outside your network) And certainly the solution wouldn't work as a Linux default. -Andi From chas@cmf.nrl.navy.mil Tue Sep 21 13:27:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 13:27:31 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LKRKpn020292 for ; Tue, 21 Sep 2004 13:27:23 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8LKR2Ja010520; Tue, 21 Sep 2004 16:27:02 -0400 (EDT) Message-Id: <200409212027.i8LKR2Ja010520@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH][ATM]: [drivers] fix warnings related to readl/writel changes Reply-To: chas3@users.sourceforge.net Date: Tue, 21 Sep 2004 16:27:03 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 7659 Lines: 231 dave, this patch gets rid of warnings from some of the atm drivers related to the recent readl/writel changes. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/17 19:50:46-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [drivers] fix warnings related to readl/writel changes # # diff -Nru a/drivers/atm/firestream.c b/drivers/atm/firestream.c --- a/drivers/atm/firestream.c 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/firestream.c 2004-09-21 12:47:06 -04:00 @@ -1667,7 +1667,7 @@ dev->hw_base = pci_resource_start(pci_dev, 0); - dev->base = (ulong) ioremap(dev->hw_base, 0x1000); + dev->base = ioremap(dev->hw_base, 0x1000); reset_chip (dev); diff -Nru a/drivers/atm/firestream.h b/drivers/atm/firestream.h --- a/drivers/atm/firestream.h 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/firestream.h 2004-09-21 12:47:06 -04:00 @@ -477,7 +477,7 @@ struct timer_list timer; unsigned long hw_base; /* mem base address */ - unsigned long base; /* Mapping of base address */ + void *base; /* Mapping of base address */ int channo; unsigned long channel_mask; diff -Nru a/drivers/atm/he.c b/drivers/atm/he.c --- a/drivers/atm/he.c 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/he.c 2004-09-21 12:47:06 -04:00 @@ -1007,6 +1007,7 @@ { struct he_dev *he_dev; struct pci_dev *pci_dev; + unsigned long membase; u16 command; u32 gen_cntl_0, host_cntl, lb_swap; @@ -1019,8 +1020,8 @@ he_dev = HE_DEV(dev); pci_dev = he_dev->pci_dev; - he_dev->membase = pci_dev->resource[0].start; - HPRINTK("membase = 0x%lx irq = %d.\n", he_dev->membase, pci_dev->irq); + membase = pci_resource_start(pci_dev, 0); + HPRINTK("membase = 0x%lx irq = %d.\n", membase, pci_dev->irq); /* * pci bus controller initialization @@ -1080,7 +1081,7 @@ hprintk("can't set latency timer to %d\n", timer); } - if (!(he_dev->membase = (unsigned long) ioremap(he_dev->membase, HE_REGMAP_SIZE))) { + if (!(he_dev->membase = ioremap(membase, HE_REGMAP_SIZE))) { hprintk("can't set up page mapping\n"); return -EINVAL; } diff -Nru a/drivers/atm/he.h b/drivers/atm/he.h --- a/drivers/atm/he.h 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/he.h 2004-09-21 12:47:06 -04:00 @@ -265,7 +265,7 @@ struct he_dev { unsigned int number; unsigned int irq; - unsigned long membase; + void *membase; char prod_id[30]; char mac_addr[6]; diff -Nru a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c --- a/drivers/atm/idt77252.c 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/idt77252.c 2004-09-21 12:47:06 -04:00 @@ -3164,7 +3164,7 @@ for (i = 0; i < 4; i++) { if (card->fbq[i]) - iounmap((void *) card->fbq[i]); + iounmap(card->fbq[i]); } if (card->membase) @@ -3722,7 +3722,7 @@ card->tst_timer.function = tst_timer; /* Do the I/O remapping... */ - card->membase = (unsigned long) ioremap(membase, 1024); + card->membase = ioremap(membase, 1024); if (!card->membase) { printk("%s: can't ioremap() membase\n", card->name); err = -EIO; @@ -3756,8 +3756,7 @@ card->sramsize = probe_sram(card); for (i = 0; i < 4; i++) { - card->fbq[i] = (unsigned long) - ioremap(srambase | 0x200000 | (i << 18), 4); + card->fbq[i] = ioremap(srambase | 0x200000 | (i << 18), 4); if (!card->fbq[i]) { printk("%s: can't ioremap() FBQ%d\n", card->name, i); err = -EIO; diff -Nru a/drivers/atm/idt77252.h b/drivers/atm/idt77252.h --- a/drivers/atm/idt77252.h 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/idt77252.h 2004-09-21 12:47:06 -04:00 @@ -355,9 +355,9 @@ struct pci_dev *pcidev; /* PCI handle (desriptor) */ struct atm_dev *atmdev; /* ATM device desriptor */ - unsigned long membase; /* SAR's memory base address */ + void *membase; /* SAR's memory base address */ unsigned long srambase; /* SAR's sram base address */ - unsigned long fbq[4]; /* FBQ fill addresses */ + void *fbq[4]; /* FBQ fill addresses */ struct semaphore mutex; spinlock_t cmd_lock; /* for r/w utility/sram */ diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/lanai.c 2004-09-21 12:47:06 -04:00 @@ -191,7 +191,7 @@ #define LANAI_EEPROM_SIZE (128) typedef int vci_t; -typedef unsigned long bus_addr_t; +typedef void *bus_addr_t; /* DMA buffer in host memory for TX, RX, or service list. */ struct lanai_buffer { @@ -471,7 +471,7 @@ static inline bus_addr_t reg_addr(const struct lanai_dev *lanai, enum lanai_register reg) { - return lanai->base + (bus_addr_t) reg; + return lanai->base + reg; } static inline u32 reg_read(const struct lanai_dev *lanai, @@ -651,7 +651,7 @@ { u32 val; APRINTK(lvcc->vbase != 0, "cardvcc_read: unbound vcc!\n"); - val= readl(lvcc->vbase + (bus_addr_t) offset); + val= readl(lvcc->vbase + offset); RWDEBUG("VR vci=%04d 0x%02X = 0x%08X\n", lvcc->vci, (int) offset, val); return val; @@ -666,7 +666,7 @@ (unsigned int) val, lvcc->vci, (unsigned int) offset); RWDEBUG("VW vci=%04d 0x%02X > 0x%08X\n", lvcc->vci, (unsigned int) offset, (unsigned int) val); - writel(val, lvcc->vbase + (bus_addr_t) offset); + writel(val, lvcc->vbase + offset); } /* -------------------- COMPUTE SIZE OF AN AAL5 PDU: */ @@ -2177,7 +2177,7 @@ /* 3.2: PCI initialization */ if ((result = lanai_pci_start(lanai)) != 0) goto error; - raw_base = (bus_addr_t) lanai->pci->resource[0].start; + raw_base = lanai->pci->resource[0].start; lanai->base = (bus_addr_t) ioremap(raw_base, LANAI_MAPPING_SIZE); if (lanai->base == 0) { printk(KERN_ERR DEV_LABEL ": couldn't remap I/O space\n"); diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/nicstar.c 2004-09-21 12:47:06 -04:00 @@ -467,6 +467,7 @@ u32 u32d[4]; u32 ns_cfg_rctsize; int bcount; + unsigned long membase; error = 0; @@ -494,8 +495,8 @@ card->index = i; card->atmdev = NULL; card->pcidev = pcidev; - card->membase = pci_resource_start(pcidev, 1); - card->membase = (unsigned long) ioremap(card->membase, NS_IOREMAP_SIZE); + membase = pci_resource_start(pcidev, 1); + card->membase = ioremap(membase, NS_IOREMAP_SIZE); if (card->membase == 0) { printk("nicstar%d: can't ioremap() membase.\n",i); diff -Nru a/drivers/atm/nicstar.h b/drivers/atm/nicstar.h --- a/drivers/atm/nicstar.h 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/nicstar.h 2004-09-21 12:47:06 -04:00 @@ -763,7 +763,7 @@ { int index; /* Card ID to the device driver */ int sram_size; /* In k x 32bit words. 32 or 128 */ - unsigned long membase; /* Card's memory base address */ + void *membase; /* Card's memory base address */ unsigned long max_pcr; int rct_size; /* Number of entries */ int vpibits; diff -Nru a/drivers/atm/nicstarmac.c b/drivers/atm/nicstarmac.c --- a/drivers/atm/nicstarmac.c 2004-09-21 12:47:06 -04:00 +++ b/drivers/atm/nicstarmac.c 2004-09-21 12:47:06 -04:00 @@ -162,7 +162,7 @@ */ static u_int8_t -read_eprom_byte(u_int32_t base, u_int8_t offset) +read_eprom_byte(virt_addr_t base, u_int8_t offset) { u_int32_t val = 0; int i,j=0; diff -Nru a/drivers/atm/nicstarmac.h b/drivers/atm/nicstarmac.h --- a/drivers/atm/nicstarmac.h 2004-09-21 12:47:05 -04:00 +++ b/drivers/atm/nicstarmac.h 2004-09-21 12:47:05 -04:00 @@ -7,7 +7,7 @@ ******************************************************************************/ -typedef unsigned int virt_addr_t; +typedef void * virt_addr_t; u_int32_t nicstar_read_eprom_status( virt_addr_t base ); void nicstar_init_eprom( virt_addr_t base ); From chas@cmf.nrl.navy.mil Tue Sep 21 13:29:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 13:29:42 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LKTaZR020561 for ; Tue, 21 Sep 2004 13:29:36 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8LKTINv010576; Tue, 21 Sep 2004 16:29:18 -0400 (EDT) Message-Id: <200409212029.i8LKTINv010576@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com, Nishanth Aravamudan , kernel-janitors@lists.osdl.org Subject: [PATCH][ATM]: [drivers] use msleep() instead of schedule_timeout() (from Nishanth Aravamudan ) Reply-To: chas3@users.sourceforge.net Date: Tue, 21 Sep 2004 16:29:19 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2183 Lines: 77 dave, this patch (from nacc@us.ibm.com) replaces assorted schedule_timeout()'s with msleep()'s. please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/17 20:30:30-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [drivers] use msleep() instead of schedule_timeout() (from Nishanth Aravamudan ) # diff -Nru a/drivers/atm/firestream.c b/drivers/atm/firestream.c --- a/drivers/atm/firestream.c 2004-09-21 12:48:17 -04:00 +++ b/drivers/atm/firestream.c 2004-09-21 12:48:17 -04:00 @@ -1704,8 +1704,7 @@ } /* Try again after 10ms. */ - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout ((HZ+99)/100); + msleep(10); } if (!to) { diff -Nru a/drivers/atm/he.c b/drivers/atm/he.c --- a/drivers/atm/he.c 2004-09-21 12:48:17 -04:00 +++ b/drivers/atm/he.c 2004-09-21 12:48:17 -04:00 @@ -2596,9 +2596,8 @@ while (((tx_inuse = atomic_read(&vcc->sk->sk_wmem_alloc)) > 0) && (retry < MAX_RETRY)) { - set_current_state(TASK_UNINTERRUPTIBLE); - (void) schedule_timeout(sleep); - if (sleep < HZ) + msleep(sleep); + if (sleep < 250) sleep = sleep * 2; ++retry; diff -Nru a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c --- a/drivers/atm/idt77252.c 2004-09-21 12:48:17 -04:00 +++ b/drivers/atm/idt77252.c 2004-09-21 12:48:17 -04:00 @@ -2516,7 +2516,7 @@ struct vc_map *vc = vcc->dev_data; unsigned long flags; unsigned long addr; - int timeout; + unsigned long timeout; down(&card->mutex); @@ -2566,9 +2566,9 @@ } spin_unlock_irqrestore(&vc->lock, flags); - timeout = 5 * HZ; + timeout = 5 * 1000; while (atomic_read(&vc->scq->used) > 0) { - timeout = schedule_timeout(timeout); + timeout = msleep_interruptible(timeout); if (!timeout) break; } diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2004-09-21 12:48:17 -04:00 +++ b/drivers/atm/lanai.c 2004-09-21 12:48:17 -04:00 @@ -813,7 +813,7 @@ DPRINTK("read, write = %d, %d\n", read, write); break; } - schedule_timeout(HZ / 25); + msleep(4); } /* 15.2.2 - clear out all tx registers */ cardvcc_write(lvcc, 0, vcc_txreadptr); From chas@cmf.nrl.navy.mil Tue Sep 21 13:30:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 13:30:54 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LKUk3D020867 for ; Tue, 21 Sep 2004 13:30:47 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8LKUMug010619; Tue, 21 Sep 2004 16:30:22 -0400 (EDT) Message-Id: <200409212030.i8LKUMug010619@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com, Domen Puncer Subject: [PATCH] [ATM]: [he] make code more readable with list_for_each_entry (from Domen Puncer ) Reply-To: chas3@users.sourceforge.net Date: Tue, 21 Sep 2004 16:30:23 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1108 Lines: 37 dave, please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/17 21:09:56-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [he] make code more readable with list_for_each_entry (from Domen Puncer ) # # drivers/atm/he.c # 2004/09/17 21:08:45-04:00 chas@relax.cmf.nrl.navy.mil +2 -3 # diff -Nru a/drivers/atm/he.c b/drivers/atm/he.c --- a/drivers/atm/he.c 2004-09-21 13:48:06 -04:00 +++ b/drivers/atm/he.c 2004-09-21 13:48:06 -04:00 @@ -1963,7 +1963,7 @@ struct he_tpd *tpd; int slot, updated = 0; #ifdef USE_TPD_POOL - struct list_head *p; + struct he_tpd *__tpd; #endif /* 2.1.6 transmit buffer return queue */ @@ -1978,8 +1978,7 @@ TBRQ_MULTIPLE(he_dev->tbrq_head) ? " MULTIPLE" : ""); #ifdef USE_TPD_POOL tpd = NULL; - list_for_each(p, &he_dev->outstanding_tpds) { - struct he_tpd *__tpd = list_entry(p, struct he_tpd, entry); + list_for_each_entry(__tpd, &he_dev->outstanding_tpds, entry) { if (TPD_ADDR(__tpd->status) == TBRQ_TPD(he_dev->tbrq_head)) { tpd = __tpd; list_del(&__tpd->entry); From laforge@gnumonks.org Tue Sep 21 13:34:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 13:34:25 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LKYKOm021338 for ; Tue, 21 Sep 2004 13:34:21 -0700 Received: from dsl-082-082-103-103.arcor-ip.net ([82.82.103.103] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9rKy-0001Tw-5G; Tue, 21 Sep 2004 22:34:08 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9rKu-0000qX-Q9; Tue, 21 Sep 2004 22:34:04 +0200 Date: Tue, 21 Sep 2004 22:34:04 +0200 From: Harald Welte To: Andi Kleen Cc: Tim Gardner , YOSHIFUJI Hideaki / ???????????? , pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040921203404.GA3236@sunbeam.de.gnumonks.org> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> <1095784761.3934.52.camel@tim.rtg.net> <20040921173134.GC12132@wotan.suse.de> <1095789507.3934.69.camel@tim.rtg.net> <20040921181525.GB18938@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20040921181525.GB18938@wotan.suse.de> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 2099 Lines: 59 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 08:15:25PM +0200, Andi Kleen wrote: > On Tue, Sep 21, 2004 at 11:58:27AM -0600, Tim Gardner wrote: > > On Tue, 2004-09-21 at 11:31, Andi Kleen wrote: > >=20 > > > But also allows an easy DOS. Someone just has to spoof a lot of conne= ctions > > > attempts with the source address of your primary name server or=20 > > > some other important service. > > >=20 > >=20 > > That is what other iptables rules and filters are for. I get thousands > > of source address spoofs from my Internet connection every day. Network > > security is a layered approach. >=20 > I don't think you can eliminate the problem with more filters. I agree with Andi, and I think we're just being lazy if we say 'well, the neighbour cache has this problem, but the solution has to be manually implemented by the administrator'. Also, we cannot put complex heuristics code in place, unless we can prove that it again doesn't provide new possibilitis for DoS. My personal (simplistic) favourite is still a simple threshold (absolute value / percentage) for incomplete neighbour entries. This way we make sure that we cannot starve 'real' (fully resolved) entries at the cost of incomplete ones. > -Andi --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUJA8XaXGVTD0i/8RAuWdAJwP29sfuwAMjEDkYQ6BMCj0J/+Y4gCfQvBB vq47lhzPY+1MaCBVgX6xgR0= =WPtw -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From timg@tpi.com Tue Sep 21 13:58:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 13:59:00 -0700 (PDT) Received: from mail.tpi.com (mail.tpi.com [198.107.51.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LKwsss022031 for ; Tue, 21 Sep 2004 13:58:54 -0700 Received: from [10.0.2.3] (unknown [10.0.2.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.tpi.com (Postfix) with ESMTP id F39682AD8C; Tue, 21 Sep 2004 14:17:03 -0700 (PDT) Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: Tim Gardner Reply-To: timg@tpi.com To: Harald Welte Cc: Andi Kleen , YOSHIFUJI Hideaki / ???????????? , pekkas@netcore.fi, netdev@oss.sgi.com In-Reply-To: <20040921203404.GA3236@sunbeam.de.gnumonks.org> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> <1095784761.3934.52.camel@tim.rtg.net> <20040921173134.GC12132@wotan.suse.de> <1095789507.3934.69.camel@tim.rtg.net> <20040921181525.GB18938@wotan.suse.de> <20040921203404.GA3236@sunbeam.de.gnumonks.org> Content-Type: text/plain Organization: TriplePoint, Inc. Message-Id: <1095800316.3934.88.camel@tim.rtg.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 14:58:37 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 9232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: timg@tpi.com Precedence: bulk X-list: netdev Content-Length: 485 Lines: 17 > My personal (simplistic) favourite is still a simple threshold (absolute > value / percentage) for incomplete neighbour entries. This way we make > sure that we cannot starve 'real' (fully resolved) entries at the cost > of incomplete ones. > > > -Andi It's not like NUD doesn't already have an overflow policy. neigh_forced_gc() performs a cleanup on NUD_INCOMPLETE entries when gc_thresh3 is exceeded. rtg -- timg@tpi.com http://www.tpi.com 406-443-5357(MT) 503-601-0234(OR) From bcrl@kvack.org Tue Sep 21 14:04:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 14:04:55 -0700 (PDT) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LL4mWC022412 for ; Tue, 21 Sep 2004 14:04:48 -0700 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Tue, 21 Sep 2004 17:04:27 -0400 Date: Tue, 21 Sep 2004 17:04:27 -0400 From: Benjamin LaHaise To: James Chapman Cc: "David S. Miller" , netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review Message-ID: <20040921210427.GB19575@kvack.org> References: <1095714704.414f4790cd168@www.katalix.com> <20040920141704.16085067.davem@davemloft.net> <1095760525.414ffa8d111a1@www.katalix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095760525.414ffa8d111a1@www.katalix.com> User-Agent: Mutt/1.4.1i X-archive-position: 9233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 2107 Lines: 47 On Tue, Sep 21, 2004 at 10:55:25AM +0100, James Chapman wrote: > Unfortunately I haven't seen Ben's code yet either so I can't give a > direct comparison. Ben? I did have a look at the Babylon stuff > (1.6-pre3), although I've no idea how much of it Ben has > changed. Here's a summary, fyi. > > Babylon:- > > - Architecture seems to be using char devices for communication with > the kernel and all the PPP datapath is handled by custom virtual > net_devices; the generic PPP kernel code isn't used as far as I can > tell. Unfortunately it is very old (linux-2.0 era I think) but Ben > has probably updated it. I've updated it. The current build is at http://www.kvack.org/~bcrl/babylon/ and is 1.6-pre3-bcrl8. The L2TP support is approaching beta, with the only real todo items being proper retransmit with congestion control, plus the kernel side of multihop support, and some locking fixes for smp and preempt. Plus the api needs to be made into something more paletable (it abuses a mix of ioctl, bind & connect to create l2tp sessions). No flames please, but patches that keep the scaling characteristics and make the interface more paletable gladly accepted. > - Some form of L2TP support is there but it is very basic. Userspace > sends data through char devices (read()/write() which the kernel > char driver converts to skbs and passes on. Nasty. That old code was completely tossed. > - PPP stack supports multiple PPP sessions in one daemon (unlike pppd). > > - Unlikely to integrate with the new native IPSEC stuff. L2TP over IPSEC? Are you insane? You'd not be able to terminate more than a couple of dozen connections over it. =-) > I think for general Linux L2TP support, a socket architecture makes > more sense. But maybe I'm biased... :) The current babylon code is using sockets. The l2tp sockets passes all packets for a given tunnel through a single file descriptor. This seems like the best tradeoff for being able to scale to decent numbers of sessions. -ben -- "Time is what keeps everything from happening all at once." -- John Wheeler From bcrl@kvack.org Tue Sep 21 14:11:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 14:11:34 -0700 (PDT) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LLBTZl022854 for ; Tue, 21 Sep 2004 14:11:29 -0700 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Tue, 21 Sep 2004 17:11:03 -0400 Date: Tue, 21 Sep 2004 17:11:03 -0400 From: Benjamin LaHaise To: "David S. Miller" Cc: James Chapman , netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review Message-ID: <20040921211103.GC19575@kvack.org> References: <1095714704.414f4790cd168@www.katalix.com> <20040920141704.16085067.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920141704.16085067.davem@davemloft.net> User-Agent: Mutt/1.4.1i X-archive-position: 9234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 736 Lines: 22 On Mon, Sep 20, 2004 at 02:17:04PM -0700, David S. Miller wrote: > Ben didn't post any pointers to his work so I couldn't do the > comparison myself. It's still alpha and ugly, but... See src/mkifaces.cc for the microbench that shows the scaling issues with lots of interfaces. I'd hoped to have time to test it on the weekend, but other stuff got in the way. The quick guide to setup is: ./configure --with-l2tp make insmod kernel/kern.o insmod drivers/l2tp/l2tp_k.o make -C src mkifaces src/mkifaces Although I'm not sure if this works on 2.6 in this build as most of my development was done on 2.4 over the summer. Cheers, -ben -- "Time is what keeps everything from happening all at once." -- John Wheeler From kirbyb@us.ibm.com Tue Sep 21 14:22:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 14:22:38 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LLMRuD023309 for ; Tue, 21 Sep 2004 14:22:34 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8LLM4bw692028; Tue, 21 Sep 2004 17:22:04 -0400 Received: from d27ml101.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8LLNISw098944; Tue, 21 Sep 2004 17:23:18 -0400 To: Cc: MIME-Version: 1.0 Subject: forcedeth HELP! X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Kirby Bakken Date: Tue, 21 Sep 2004 16:22:03 -0500 X-MIMETrack: Serialize by Router on d27ml101/27/M/IBM(Release 6.5.2|June 01, 2004) at 09/21/2004 04:22:04 PM, Serialize complete at 09/21/2004 04:22:04 PM Content-Type: multipart/alternative; boundary="=_alternative 007560A086256F16_=" X-archive-position: 9235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kirbyb@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2996 Lines: 75 This is a multipart message in MIME format. --=_alternative 007560A086256F16_= Content-Type: text/plain; charset="US-ASCII" Please excuse my ignorance... and hopefully having done that, point me to the forum, mailing list, or whatever so I can figure this out (most likely with help.... ) :-) I'm running a Nvidia Nforce2 MB (Biostar M7NCG 400). When I boot with gentoo and a 2.4 kernel, eth0 works fine. When I boot with a 2.6.7 kernel, eth0 does not work. When booted with the 2.6.7 kernel, an 'lsmod' shows forcedeth with a size of 12160, and a 'used by' of '0' (I'm so dumb, I'm not even sure if that means its just not used by anybody else, OR if the kernel isn't even using it, even though its loaded). A look at /proc/net/dev is pretty much 0's, except for a 'drop' of 4 bytes.... I've read that I can turn on 'generous' debug output by changing the #if 0 in forcedeth.c from to a '1'... But how then do I compile that? A 'make forcedeth.o' produces a ton of errors.... And given that I CAN get that to compile, where does the debug output show up. Thanks in advance :-) ======================= Kirby Bakken ESW Build Architect Rochester, MN email: kirbyb@us.ibm.com ezpage:kirbyb 507-253-4549 / Tie: 553-4549 Fax: 507-253-3495 ......one more straw can't possibly matter.... --=_alternative 007560A086256F16_= Content-Type: text/html; charset="US-ASCII"
Please excuse my ignorance...  and hopefully having done that, point me to the forum, mailing list, or whatever so I can figure this out (most likely with help....  )  :-)

I'm running a Nvidia Nforce2 MB (Biostar M7NCG 400).  When I boot with gentoo and a 2.4 kernel, eth0 works fine.  When I boot with a 2.6.7 kernel, eth0 does not work.  When booted with the 2.6.7 kernel,  an 'lsmod' shows forcedeth with a size of 12160, and a 'used by' of '0' (I'm so dumb, I'm not even sure if that means its just not used by anybody else, OR if the kernel isn't even using it, even though its loaded).

A look at /proc/net/dev is pretty much 0's, except for a 'drop' of 4 bytes....

I've read that I can turn on 'generous' debug output by changing the #if 0 in forcedeth.c from to a '1'...  But how then do I compile that?  A 'make forcedeth.o' produces a ton of errors....  And given that I CAN get that to compile,  where does the debug output show up.

Thanks in advance  :-)

=======================
Kirby Bakken
ESW Build Architect
Rochester, MN
email: kirbyb@us.ibm.com
ezpage:kirbyb
507-253-4549 / Tie:  553-4549
Fax:  507-253-3495

......one more straw can't possibly matter....
 --=_alternative 007560A086256F16_=-- From davem@davemloft.net Tue Sep 21 14:50:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 14:50:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LLo3vh023993 for ; Tue, 21 Sep 2004 14:50:04 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9sVk-0007fO-00; Tue, 21 Sep 2004 14:49:20 -0700 Date: Tue, 21 Sep 2004 14:49:20 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH][ATM]: [drivers] fix warnings related to readl/writel changes Message-Id: <20040921144920.7e62ca9e.davem@davemloft.net> In-Reply-To: <200409212027.i8LKR2Ja010520@ginger.cmf.nrl.navy.mil> References: <200409212027.i8LKR2Ja010520@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4303 Lines: 125 On Tue, 21 Sep 2004 16:27:03 -0400 "chas williams (contractor)" wrote: > this patch gets rid of warnings from some of the atm drivers related to > the recent readl/writel changes. > > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2004/09/17 19:50:46-04:00 chas@relax.cmf.nrl.navy.mil > # [ATM]: [drivers] fix warnings related to readl/writel changes Applied, then I added a further patch on top of this one which uses the correct "void __iomem *" for these things, as follows. Thanks. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/21 14:28:56-07:00 davem@nuts.davemloft.net # [ATM]: Use __iomem where appropriate. # # Signed-off-by: David S. Miller # # drivers/atm/nicstarmac.h # 2004/09/21 14:28:23-07:00 davem@nuts.davemloft.net +1 -1 # [ATM]: Use __iomem where appropriate. # # drivers/atm/nicstar.h # 2004/09/21 14:28:23-07:00 davem@nuts.davemloft.net +1 -1 # [ATM]: Use __iomem where appropriate. # # drivers/atm/lanai.c # 2004/09/21 14:28:23-07:00 davem@nuts.davemloft.net +1 -1 # [ATM]: Use __iomem where appropriate. # # drivers/atm/idt77252.h # 2004/09/21 14:28:23-07:00 davem@nuts.davemloft.net +2 -2 # [ATM]: Use __iomem where appropriate. # # drivers/atm/he.h # 2004/09/21 14:28:23-07:00 davem@nuts.davemloft.net +1 -1 # [ATM]: Use __iomem where appropriate. # # drivers/atm/firestream.h # 2004/09/21 14:28:23-07:00 davem@nuts.davemloft.net +1 -1 # [ATM]: Use __iomem where appropriate. # diff -Nru a/drivers/atm/firestream.h b/drivers/atm/firestream.h --- a/drivers/atm/firestream.h 2004-09-21 14:29:53 -07:00 +++ b/drivers/atm/firestream.h 2004-09-21 14:29:53 -07:00 @@ -477,7 +477,7 @@ struct timer_list timer; unsigned long hw_base; /* mem base address */ - void *base; /* Mapping of base address */ + void __iomem *base; /* Mapping of base address */ int channo; unsigned long channel_mask; diff -Nru a/drivers/atm/he.h b/drivers/atm/he.h --- a/drivers/atm/he.h 2004-09-21 14:29:53 -07:00 +++ b/drivers/atm/he.h 2004-09-21 14:29:53 -07:00 @@ -265,7 +265,7 @@ struct he_dev { unsigned int number; unsigned int irq; - void *membase; + void __iomem *membase; char prod_id[30]; char mac_addr[6]; diff -Nru a/drivers/atm/idt77252.h b/drivers/atm/idt77252.h --- a/drivers/atm/idt77252.h 2004-09-21 14:29:53 -07:00 +++ b/drivers/atm/idt77252.h 2004-09-21 14:29:53 -07:00 @@ -355,9 +355,9 @@ struct pci_dev *pcidev; /* PCI handle (desriptor) */ struct atm_dev *atmdev; /* ATM device desriptor */ - void *membase; /* SAR's memory base address */ + void __iomem *membase; /* SAR's memory base address */ unsigned long srambase; /* SAR's sram base address */ - void *fbq[4]; /* FBQ fill addresses */ + void __iomem *fbq[4]; /* FBQ fill addresses */ struct semaphore mutex; spinlock_t cmd_lock; /* for r/w utility/sram */ diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2004-09-21 14:29:53 -07:00 +++ b/drivers/atm/lanai.c 2004-09-21 14:29:53 -07:00 @@ -191,7 +191,7 @@ #define LANAI_EEPROM_SIZE (128) typedef int vci_t; -typedef void *bus_addr_t; +typedef void __iomem *bus_addr_t; /* DMA buffer in host memory for TX, RX, or service list. */ struct lanai_buffer { diff -Nru a/drivers/atm/nicstar.h b/drivers/atm/nicstar.h --- a/drivers/atm/nicstar.h 2004-09-21 14:29:53 -07:00 +++ b/drivers/atm/nicstar.h 2004-09-21 14:29:53 -07:00 @@ -763,7 +763,7 @@ { int index; /* Card ID to the device driver */ int sram_size; /* In k x 32bit words. 32 or 128 */ - void *membase; /* Card's memory base address */ + void __iomem *membase; /* Card's memory base address */ unsigned long max_pcr; int rct_size; /* Number of entries */ int vpibits; diff -Nru a/drivers/atm/nicstarmac.h b/drivers/atm/nicstarmac.h --- a/drivers/atm/nicstarmac.h 2004-09-21 14:29:53 -07:00 +++ b/drivers/atm/nicstarmac.h 2004-09-21 14:29:53 -07:00 @@ -7,7 +7,7 @@ ******************************************************************************/ -typedef void * virt_addr_t; +typedef void __iomem *virt_addr_t; u_int32_t nicstar_read_eprom_status( virt_addr_t base ); void nicstar_init_eprom( virt_addr_t base ); From laforge@gnumonks.org Tue Sep 21 14:55:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 14:55:22 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LLtGon024447 for ; Tue, 21 Sep 2004 14:55:17 -0700 Received: from dsl-082-082-103-103.arcor-ip.net ([82.82.103.103] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9sbH-00036b-TW; Tue, 21 Sep 2004 23:55:04 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9sbG-0000tx-0z; Tue, 21 Sep 2004 23:55:02 +0200 Date: Tue, 21 Sep 2004 23:55:02 +0200 From: Harald Welte To: Robert Olsson Cc: cd@cdaniel.de, netdev@oss.sgi.com Subject: Re: "dst cache overflow" Message-ID: <20040921215501.GE3236@sunbeam.de.gnumonks.org> References: <16719.13095.369830.547715@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C1iGAkRnbeBonpVg" Content-Disposition: inline In-Reply-To: <200409201907.43317.cd@cdaniel.de> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 2734 Lines: 79 --C1iGAkRnbeBonpVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 09:44:39PM +0200, Robert Olsson wrote: > Hello! >=20 > size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot = mc=20 > GC:tot ignore gmiss dstof HLS:in out > 10501 593 339 0 0 0 0 0 250 24 = 0 > 362 360 2 0 229 48 >=20 >=20 > The number of packets that hits the route hash is about the same as the > number of packets that misses it. (hit/tot) >=20 > Either your route hash is so small in that case increase rhash_entries.= =20 > Or you are receiving a DoS attack. Neither is the case. I have now logged into that box and did some further analysis. There definitely is a dst_entry leak somewhere in the kernel. the number of entries in ip_dst_cache slab is constantly increasing, now just before rebooting the box it had approached about 65k. At least when you manuall flush the cache, the number of allocated ip_dst_entries from slab should decrease... After the reboot (uptime 4 hours at this point): according to /proc/slabinfo, there's 7530 entries allocated If you cat /proc/net/rt_cache, you see about 1990 entries. =20 I've added a patch to export the number of dst_entries that are sitting in the dst_garbage_list, it's 5549. This value is increasing constantly over time. Coincidentially, if we subtract 7530-1990 we get almost exactly this number. I bet that something inside the kernel forgets dst_release().. IMQ is just compiled, not used (so I don't see how it should come from this). Any comments, suggestions? If nothing else helps, I will add a seq_file interface to dst_garbage_list and try to find some similarity betwen the stale entries in order to get a clue about what's going on. > --ro btw: The system was runnign 2.4.x until about two weeks ago... with no dst_cache problems. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --C1iGAkRnbeBonpVg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUKM1XaXGVTD0i/8RAl+JAJ9HjSeB1oEetTpk/E8oWeDUPRzt7gCfYPRI ddwsY5RCQLDjf5pJsgg/gpA= =FUUp -----END PGP SIGNATURE----- --C1iGAkRnbeBonpVg-- From chas@cmf.nrl.navy.mil Tue Sep 21 15:03:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:03:26 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LM3LkU024871 for ; Tue, 21 Sep 2004 15:03:22 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8LM35TG012489; Tue, 21 Sep 2004 18:03:05 -0400 (EDT) Message-Id: <200409212203.i8LM35TG012489@ginger.cmf.nrl.navy.mil> To: "David S. Miller" cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH][ATM]: [drivers] fix warnings related to readl/writel changes In-Reply-To: Message from "David S. Miller" of "Tue, 21 Sep 2004 14:49:20 PDT." <20040921144920.7e62ca9e.davem@davemloft.net> Date: Tue, 21 Sep 2004 18:03:06 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 242 Lines: 7 thanks! i missed that bit. In message <20040921144920.7e62ca9e.davem@davemloft.net>,"David S. Miller" writ es: >Applied, then I added a further patch on top of this >one which uses the correct "void __iomem *" for these >things, as follows. From davem@davemloft.net Tue Sep 21 15:18:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:18:55 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LMIgt9025406 for ; Tue, 21 Sep 2004 15:18:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9sxV-0002vV-00; Tue, 21 Sep 2004 15:18:01 -0700 Date: Tue, 21 Sep 2004 15:18:01 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, davem@redhat.com, nacc@us.ibm.com, kernel-janitors@lists.osdl.org Subject: Re: [PATCH][ATM]: [drivers] use msleep() instead of schedule_timeout() (from Nishanth Aravamudan ) Message-Id: <20040921151801.3ccd21cd.davem@davemloft.net> In-Reply-To: <200409212029.i8LKTINv010576@ginger.cmf.nrl.navy.mil> References: <200409212029.i8LKTINv010576@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 248 Lines: 7 On Tue, 21 Sep 2004 16:29:19 -0400 "chas williams (contractor)" wrote: > this patch (from nacc@us.ibm.com) replaces assorted schedule_timeout()'s > with msleep()'s. please apply to 2.6. Applied, thanks Chas and Nishanth. From davem@davemloft.net Tue Sep 21 15:19:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:19:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LMJYJZ025611 for ; Tue, 21 Sep 2004 15:19:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9syM-0002vy-00; Tue, 21 Sep 2004 15:18:54 -0700 Date: Tue, 21 Sep 2004 15:18:54 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, davem@redhat.com, domen@coderock.org Subject: Re: [PATCH] [ATM]: [he] make code more readable with list_for_each_entry (from Domen Puncer ) Message-Id: <20040921151854.7f080f8f.davem@davemloft.net> In-Reply-To: <200409212030.i8LKUMug010619@ginger.cmf.nrl.navy.mil> References: <200409212030.i8LKUMug010619@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 137 Lines: 6 On Tue, 21 Sep 2004 16:30:23 -0400 "chas williams (contractor)" wrote: > please apply to 2.6. Applied, thanks. From davem@davemloft.net Tue Sep 21 15:24:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:24:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LMOrBc026143 for ; Tue, 21 Sep 2004 15:24:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9t3U-0002wZ-00; Tue, 21 Sep 2004 15:24:12 -0700 Date: Tue, 21 Sep 2004 15:24:11 -0700 From: "David S. Miller" To: Harald Welte Cc: Robert.Olsson@data.slu.se, cd@cdaniel.de, netdev@oss.sgi.com Subject: Re: "dst cache overflow" Message-Id: <20040921152411.72b4092e.davem@davemloft.net> In-Reply-To: <20040921215501.GE3236@sunbeam.de.gnumonks.org> References: <16719.13095.369830.547715@robur.slu.se> <20040921215501.GE3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 753 Lines: 22 On Tue, 21 Sep 2004 23:55:02 +0200 Harald Welte wrote: > I bet that something inside the kernel forgets dst_release().. IMQ is > just compiled, not used (so I don't see how it should come from this). > > Any comments, suggestions? Most likely it is a leak like that, yes. Here is my suggstion for debugging this: 1) Boot with profile=2 or similar. 2) Disable the platform code that bumps the profiling counters at the timer interrupt. 3) Make every piece of which gets or puts a dst entry reference pass it's PC to some function which increments the profile buffer entry. (use current_text_addr()) Then after running for some time use readprofile to figure out what subsystem or area is causing the references. From tgraf@suug.ch Tue Sep 21 15:41:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:41:26 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LMfJR7026639 for ; Tue, 21 Sep 2004 15:41:20 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 67FD181; Wed, 22 Sep 2004 00:40:45 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 527401C0E8; Wed, 22 Sep 2004 00:41:27 +0200 (CEST) Date: Wed, 22 Sep 2004 00:41:27 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6 NET] Fix ifmap alignment issues over rtnetlink Message-ID: <20040921224127.GM566@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 9242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 2253 Lines: 77 Introduces a fixed size variant for ifmap for rtnetlink. Fixes issues with address size mismatch between kernel and userspace. I couldn't find a better solution than using 64bit for memory addresses and cast them in the kernel. Obviously this will fail if userspace provides an address greater than 32bit. Signed-off-by: Thomas Graf Is it actually worth to keep trying to do this or should we just declare that it's only possible via ethtool? Providing the settings over rtnetlink is definitely a good thing in my eyes. --- linux-2.6.9-rc2-bk7.orig/include/linux/rtnetlink.h 2004-09-21 23:26:54.000000000 +0200 +++ linux-2.6.9-rc2-bk7/include/linux/rtnetlink.h 2004-09-21 23:52:06.000000000 +0200 @@ -577,6 +577,17 @@ __u32 tx_compressed; }; +/* The struct should be in sync with struct ifmap */ +struct rtnl_link_ifmap +{ + __u64 mem_start; + __u64 mem_end; + __u64 base_addr; + __u16 irq; + __u8 dma; + __u8 port; +}; + enum { IFLA_UNSPEC, --- linux-2.6.9-rc2-bk7.orig/net/core/rtnetlink.c 2004-09-21 23:27:28.000000000 +0200 +++ linux-2.6.9-rc2-bk7/net/core/rtnetlink.c 2004-09-22 00:27:29.000000000 +0200 @@ -182,7 +182,7 @@ } if (1) { - struct ifmap map = { + struct rtnl_link_ifmap map = { .mem_start = dev->mem_start, .mem_end = dev->mem_end, .base_addr = dev->base_addr, @@ -277,6 +277,9 @@ dev_change_flags(dev, ifm->ifi_flags); if (ida[IFLA_MAP - 1]) { + struct rtnl_link_ifmap *u_map; + struct ifmap k_map; + if (!dev->set_config) { err = -EOPNOTSUPP; goto out; @@ -287,11 +290,19 @@ goto out; } - if (ida[IFLA_MAP - 1]->rta_len != RTA_LENGTH(sizeof(struct ifmap))) + if (ida[IFLA_MAP - 1]->rta_len != RTA_LENGTH(sizeof(*u_map))) goto out; - - err = dev->set_config(dev, (struct ifmap *) - RTA_DATA(ida[IFLA_MAP - 1])); + + u_map = RTA_DATA(ida[IFLA_MAP - 1]); + + k_map.mem_start = (unsigned long) u_map->mem_start; + k_map.mem_end = (unsigned long) u_map->mem_end; + k_map.base_addr = (unsigned short) u_map->base_addr; + k_map.irq = (unsigned char) u_map->irq; + k_map.dma = (unsigned char) u_map->dma; + k_map.port = (unsigned char) u_map->port; + + err = dev->set_config(dev, (struct ifmap *) &k_map); if (err) goto out; From kaber@trash.net Tue Sep 21 15:50:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:50:11 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LMo67H027093 for ; Tue, 21 Sep 2004 15:50:07 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1C9tYU-0004lp-00; Wed, 22 Sep 2004 00:56:14 +0200 Message-ID: <4150B00C.7010305@trash.net> Date: Wed, 22 Sep 2004 00:49:48 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Christian Daniel CC: netdev@oss.sgi.com Subject: Re: "dst cache overflow" References: <200409201907.43317.cd@cdaniel.de> In-Reply-To: <200409201907.43317.cd@cdaniel.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 365 Lines: 16 Christian Daniel wrote: >Hello everybody, > >I'm running Linux 2.6.8.1+pom20040621+imq+... as a firewall and router on a >2MBit/s leased line to our ISP. After about 24 hours I get loads of "dst >cache overflow" messages and extreme packet loss occurs on all routed >connections - bridges continue to work. > > Have you tried without imq ? Regards Patrick From davem@davemloft.net Tue Sep 21 15:59:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 15:59:18 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LMxCnT027649 for ; Tue, 21 Sep 2004 15:59:12 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9tal-00030b-00; Tue, 21 Sep 2004 15:58:35 -0700 Date: Tue, 21 Sep 2004 15:58:35 -0700 From: "David S. Miller" To: Andi Kleen Cc: anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040921155835.18aee381.davem@davemloft.net> In-Reply-To: <20040920203021.GD4242@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1922 Lines: 61 On Mon, 20 Sep 2004 22:30:21 +0200 Andi Kleen wrote: > I see the same problem here, but it's even worse. I only get 150-200KB/s > sending data with scp from a fast machine with e1000 with a gigabit link. > netperf also gives only 250KB/s. So I re-enabled TSO support in the loopback driver to try and reproduce this, but I can't. There has been a lot of churn in this area so please make sure you are using the latest sources, all of my current TSO fixes are in Linus's BK tree. And, take the patch below and do a loopback bandwidth test before and after the patch is applied. Do things slow down when loopback has TSO enabled just as it does for your gigabit interfaces? (If you want to use the ethtool bits included here, you'll have to first recompile the ethtool utility with the non-sense "eth" and "usb" device name checks removed...) ===== drivers/net/loopback.c 1.17 vs edited ===== --- 1.17/drivers/net/loopback.c 2004-06-22 14:07:33 -07:00 +++ edited/drivers/net/loopback.c 2004-09-21 15:33:04 -07:00 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include #include /* For the statistics structure. */ @@ -183,6 +184,17 @@ return stats; } +u32 loopback_get_link(struct net_device *dev) +{ + return 1; +} + +static struct ethtool_ops loopback_ethtool_ops = { + .get_link = loopback_get_link, + .get_tso = ethtool_op_get_tso, + .set_tso = ethtool_op_set_tso, +}; + struct net_device loopback_dev = { .name = "lo", .mtu = (16 * 1024) + 20 + 20 + 12, @@ -198,7 +210,9 @@ .flags = IFF_LOOPBACK, .features = NETIF_F_SG|NETIF_F_FRAGLIST |NETIF_F_NO_CSUM|NETIF_F_HIGHDMA + |NETIF_F_TSO |NETIF_F_LLTX, + .ethtool_ops = &loopback_ethtool_ops, }; /* Setup and register the of the LOOPBACK device. */ From herbert@gondor.apana.org.au Tue Sep 21 16:07:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 16:07:51 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LN7eMo028117 for ; Tue, 21 Sep 2004 16:07:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9tjB-0003EH-00; Wed, 22 Sep 2004 09:07:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9tj0-0003KE-00; Wed, 22 Sep 2004 09:07:06 +1000 From: Herbert Xu To: bcrl@kvack.org (Benjamin LaHaise) Subject: Re: PPP-over-L2TP kernel support, new patch for review Cc: jchapman@katalix.com, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Organization: Core In-Reply-To: <20040921210427.GB19575@kvack.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 22 Sep 2004 09:07:06 +1000 X-archive-position: 9245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 522 Lines: 15 Benjamin LaHaise wrote: > >> - Unlikely to integrate with the new native IPSEC stuff. > > L2TP over IPSEC? Are you insane? You'd not be able to terminate more than > a couple of dozen connections over it. =-) Why not? L2TP over IPsec is the only reason I'm looking at L2TP at all. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From slblake@petri-meat.com Tue Sep 21 16:39:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 16:39:22 -0700 (PDT) Received: from server26.totalchoicehosting.com (server26.totalchoicehosting.com [209.152.177.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LNdHh9032199 for ; Tue, 21 Sep 2004 16:39:17 -0700 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1C9uDu-0005WX-Hl; Tue, 21 Sep 2004 19:39:02 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: Steven Blake To: hadi@cyberus.ca Cc: netdev@oss.sgi.com In-Reply-To: <1095764621.1049.14.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1095809938.2340.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 21 Sep 2004 19:38:58 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 9246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: slblake@petri-meat.com Precedence: bulk X-list: netdev Content-Length: 540 Lines: 17 On Tue, 2004-09-21 at 07:03, jamal wrote: > Important for marketing to be able to claim _full_ RFC 1812 compliance. > Kepp the TOS! > I know it sounds silly, but there are a lot more foolish people out > there addicted to glossyware. RFC 1812 was written before TOS routes were pulled out of OSPFv2 (due to too fee independent implementations). No one implements FIB lookup as described in RFC 1812 in the core. What people do implement is PBR, as well as DSCP-based nexthop selection for MPLS DIFF-TE (RFC 3564). Regards, // Steve From davem@davemloft.net Tue Sep 21 16:58:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 16:58:16 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8LNwBCM000450 for ; Tue, 21 Sep 2004 16:58:11 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9uVq-00036U-00; Tue, 21 Sep 2004 16:57:34 -0700 Date: Tue, 21 Sep 2004 16:57:33 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fix ifmap alignment issues over rtnetlink Message-Id: <20040921165733.3e0d31d8.davem@davemloft.net> In-Reply-To: <20040921224127.GM566@postel.suug.ch> References: <20040921224127.GM566@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 488 Lines: 14 On Wed, 22 Sep 2004 00:41:27 +0200 Thomas Graf wrote: > + k_map.mem_start = (unsigned long) u_map->mem_start; > + k_map.mem_end = (unsigned long) u_map->mem_end; > + k_map.base_addr = (unsigned short) u_map->base_addr; > + k_map.irq = (unsigned char) u_map->irq; > + k_map.dma = (unsigned char) u_map->dma; > + k_map.port = (unsigned char) u_map->port; Please cast to the actual types that struct ifmap uses, otherwise the change is OK. Thanks for catching this. From mcr@sandelman.ottawa.on.ca Tue Sep 21 17:03:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 17:03:18 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M03BeO000833 for ; Tue, 21 Sep 2004 17:03:13 -0700 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8M02bW23813 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 21 Sep 2004 20:02:38 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i8M08c607019 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 21 Sep 2004 20:08:43 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i8M00kfN030614; Tue, 21 Sep 2004 20:00:46 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i8M004KI030602; Tue, 21 Sep 2004 20:00:09 -0400 To: Herbert Xu cc: bcrl@kvack.org (Benjamin LaHaise), jchapman@katalix.com, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review In-Reply-To: Message from Herbert Xu of "Wed, 22 Sep 2004 09:07:06 +1000." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Sep 2004 20:00:04 -0400 Message-ID: <30601.1095811204@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-archive-position: 9248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcr@sandelman.ottawa.on.ca Precedence: bulk X-list: netdev Content-Length: 1208 Lines: 31 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Herbert" == Herbert Xu writes: >>> - Unlikely to integrate with the new native IPSEC stuff. >> L2TP over IPSEC? Are you insane? You'd not be able to terminate >> more than a couple of dozen connections over it. =-) Herbert> Why not? L2TP over IPsec is the only reason I'm looking at Herbert> L2TP at all. Stupidly, it is the only way for a Microsoft XP native stack to be "auto-configured". Sad. sad stupid crap that I wish could be thrown out. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQVDAg4qHRg3pndX9AQElfQP/aSfT8/pNvtwaYQyAgin9vI9eAEQmI1uk VlhrzJB8SajEiYg9oQxuiBTqhxjUhG1/9Cp8m3NEofeW9D1YLZwv6TEhN/M+TLrI cIG8H4qvu+//L64Zxa8P+X7ZsM3+5tFkpu+QFE374VuoGaiEMUCMl4WLTTST1YnJ VEpnvhotGSs= =8O9W -----END PGP SIGNATURE----- From tgraf@suug.ch Tue Sep 21 17:03:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 17:03:25 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M03IV9000839 for ; Tue, 21 Sep 2004 17:03:18 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 622AB81; Wed, 22 Sep 2004 02:02:44 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 2E30E1C0E8; Wed, 22 Sep 2004 02:03:25 +0200 (CEST) Date: Wed, 22 Sep 2004 02:03:25 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fix ifmap alignment issues over rtnetlink Message-ID: <20040922000325.GN566@postel.suug.ch> References: <20040921224127.GM566@postel.suug.ch> <20040921165733.3e0d31d8.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040921165733.3e0d31d8.davem@davemloft.net> X-archive-position: 9249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 600 Lines: 15 * David S. Miller <20040921165733.3e0d31d8.davem@davemloft.net> 2004-09-21 16:57 > On Wed, 22 Sep 2004 00:41:27 +0200 > Thomas Graf wrote: > > > + k_map.mem_start = (unsigned long) u_map->mem_start; > > + k_map.mem_end = (unsigned long) u_map->mem_end; > > + k_map.base_addr = (unsigned short) u_map->base_addr; > > + k_map.irq = (unsigned char) u_map->irq; > > + k_map.dma = (unsigned char) u_map->dma; > > + k_map.port = (unsigned char) u_map->port; > > Please cast to the actual types that struct ifmap uses, > otherwise the change is OK. It is or am I missing something? From herbert@gondor.apana.org.au Tue Sep 21 17:05:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 17:05:48 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M05blt001539 for ; Tue, 21 Sep 2004 17:05:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9udG-0003RB-00; Wed, 22 Sep 2004 10:05:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9ud5-0003RZ-00; Wed, 22 Sep 2004 10:05:03 +1000 Date: Wed, 22 Sep 2004 10:05:03 +1000 To: Pablo Neira Cc: hadi@cyberus.ca, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040922000503.GA13218@gondor.apana.org.au> References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <414F1E12.6010808@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 928 Lines: 25 On Mon, Sep 20, 2004 at 08:14:42PM +0200, Pablo Neira wrote: > > Here a link to the tool that I use to stress netlink sockets. > > http://eurodev.net/~pablo/netlinkbench-unicast-1.0.tar.gz Thanks for the link. I'm afraid that your kernel module is simply buggy. First of all as I explained before the kernel must never wait. It has exactly the same effect as extending the receive queue length. Secondly each of your user-space messages is producing a number of replies. This should be done as a dump operation. If you do it as a dump operation, then you will never get overruns because the kernel never sends more than the user can handle. I'm happy to help you work on this if you have questions. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue Sep 21 17:22:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 17:22:08 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M0M3V0002117 for ; Tue, 21 Sep 2004 17:22:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9usw-00039g-00; Tue, 21 Sep 2004 17:21:26 -0700 Date: Tue, 21 Sep 2004 17:21:26 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fix ifmap alignment issues over rtnetlink Message-Id: <20040921172126.02e0006e.davem@davemloft.net> In-Reply-To: <20040922000325.GN566@postel.suug.ch> References: <20040921224127.GM566@postel.suug.ch> <20040921165733.3e0d31d8.davem@davemloft.net> <20040922000325.GN566@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 869 Lines: 25 On Wed, 22 Sep 2004 02:03:25 +0200 Thomas Graf wrote: > * David S. Miller <20040921165733.3e0d31d8.davem@davemloft.net> 2004-09-21 16:57 > > On Wed, 22 Sep 2004 00:41:27 +0200 > > Thomas Graf wrote: > > > > > + k_map.mem_start = (unsigned long) u_map->mem_start; > > > + k_map.mem_end = (unsigned long) u_map->mem_end; > > > + k_map.base_addr = (unsigned short) u_map->base_addr; > > > + k_map.irq = (unsigned char) u_map->irq; > > > + k_map.dma = (unsigned char) u_map->dma; > > > + k_map.port = (unsigned char) u_map->port; > > > > Please cast to the actual types that struct ifmap uses, > > otherwise the change is OK. > > It is or am I missing something? I'm retarded and I was looking at the wrong structure definition, sorry. Please resend your patch to me via private email and I'll add it to my tree, thanks Thomas. From pablo@eurodev.net Tue Sep 21 17:23:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 17:24:04 -0700 (PDT) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M0Nuqv002443 for ; Tue, 21 Sep 2004 17:23:57 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp07.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040922002340.XFVN9737.smtp07.retemail.es@eurodev.net>; Wed, 22 Sep 2004 02:23:40 +0200 Message-ID: <4150C64E.80900@eurodev.net> Date: Wed, 22 Sep 2004 02:24:46 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: hadi@cyberus.ca, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> In-Reply-To: <20040922000503.GA13218@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 857 Lines: 33 Hi Herbert, Herbert Xu wrote: >On Mon, Sep 20, 2004 at 08:14:42PM +0200, Pablo Neira wrote: > > >>Here a link to the tool that I use to stress netlink sockets. >> >>http://eurodev.net/~pablo/netlinkbench-unicast-1.0.tar.gz >> >> > >Thanks for the link. I'm afraid that your kernel module is simply >buggy. > >First of all as I explained before the kernel must never wait. It has >exactly the same effect as extending the receive queue length. > >Secondly each of your user-space messages is producing a number of >replies. This should be done as a dump operation. If you do it as >a dump operation, then you will never get overruns because the kernel >never sends more than the user can handle. > > I'll adapt the module to use dump, I still think that I can reproduce the problem. thanks for the review, please stay tuned. regards, Pablo From bcrl@kvack.org Tue Sep 21 18:14:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 18:14:52 -0700 (PDT) Received: from kanga.kvack.org (kanga.kvack.org [66.96.29.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M1ElGK004126 for ; Tue, 21 Sep 2004 18:14:47 -0700 Received: (from localhost user: 'bcrl' uid#63042 fake: STDIN (bcrl@kanga.kvack.org)) by kvack.org id ; Tue, 21 Sep 2004 21:14:22 -0400 Date: Tue, 21 Sep 2004 21:14:21 -0400 From: Benjamin LaHaise To: Herbert Xu Cc: jchapman@katalix.com, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review Message-ID: <20040922011421.GE19575@kvack.org> References: <20040921210427.GB19575@kvack.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 9255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 806 Lines: 18 On Wed, Sep 22, 2004 at 09:07:06AM +1000, Herbert Xu wrote: > Benjamin LaHaise wrote: > > > >> - Unlikely to integrate with the new native IPSEC stuff. > > > > L2TP over IPSEC? Are you insane? You'd not be able to terminate more than > > a couple of dozen connections over it. =-) > > Why not? L2TP over IPsec is the only reason I'm looking at L2TP at all. CPU load. The main reason I was forced to revisit L2TP (imo, it's a horrible protocol that suffers from too many bad decisions) was in its role for terminating DSL. In this case one expects to be able to have tens of thousands of connections terminated by a single box, which means pushing hundreds of megabits of traffic. The overhead of crypto operations in such a scenario makes it a far too costly choice. -ben From laforge@gnumonks.org Tue Sep 21 18:14:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 18:14:23 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M1EIks004020 for ; Tue, 21 Sep 2004 18:14:19 -0700 Received: from dsl-082-082-103-103.arcor-ip.net ([82.82.103.103] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9vht-00079P-8g; Wed, 22 Sep 2004 03:14:05 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9vhq-00014n-5c; Wed, 22 Sep 2004 03:14:02 +0200 Date: Wed, 22 Sep 2004 03:14:01 +0200 From: Harald Welte To: Tim Gardner Cc: Andi Kleen , YOSHIFUJI Hideaki / ???????????? , pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040922011401.GK3236@sunbeam.de.gnumonks.org> References: <20040922.001448.73843048.yoshfuji@linux-ipv6.org> <20040922.010428.104988024.yoshfuji@linux-ipv6.org> <1095784761.3934.52.camel@tim.rtg.net> <20040921173134.GC12132@wotan.suse.de> <1095789507.3934.69.camel@tim.rtg.net> <20040921181525.GB18938@wotan.suse.de> <20040921203404.GA3236@sunbeam.de.gnumonks.org> <1095800316.3934.88.camel@tim.rtg.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4oF+6Ged69J0+4/e" Content-Disposition: inline In-Reply-To: <1095800316.3934.88.camel@tim.rtg.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1859 Lines: 54 --4oF+6Ged69J0+4/e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 02:58:37PM -0600, Tim Gardner wrote: >=20 > > My personal (simplistic) favourite is still a simple threshold (absolute > > value / percentage) for incomplete neighbour entries. This way we make > > sure that we cannot starve 'real' (fully resolved) entries at the cost > > of incomplete ones. > >=20 > > > -Andi >=20 > It's not like NUD doesn't already have an overflow policy. > neigh_forced_gc() performs a cleanup on NUD_INCOMPLETE entries when > gc_thresh3 is exceeded. No, that's not what it does. neigh_forced_gc explicitly only elects INCOMPLETE entries that exist for at least n->parms_retrans_time in order to avoid flooding the network with too many arp/neighbour requests (since we could delete an incomplete one before the reply arrives, and could do this for quite some time over and over again). That's been my point all over this discussion... > rtg > timg@tpi.com http://www.tpi.com > 406-443-5357(MT) 503-601-0234(OR) --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --4oF+6Ged69J0+4/e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUNHZXaXGVTD0i/8RAlkMAJ9mvfHWw3RXZPVGOpP3kfaKIftRfQCgrCnl pucwnLRJR1ReHlM2HlcPrfM= =smO9 -----END PGP SIGNATURE----- --4oF+6Ged69J0+4/e-- From laforge@gnumonks.org Tue Sep 21 18:20:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 18:20:29 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M1KOxi004744 for ; Tue, 21 Sep 2004 18:20:25 -0700 Received: from dsl-082-082-103-103.arcor-ip.net ([82.82.103.103] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1C9vnp-0007Ew-Cc; Wed, 22 Sep 2004 03:20:13 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1C9vnn-00015I-VT; Wed, 22 Sep 2004 03:20:12 +0200 Date: Wed, 22 Sep 2004 03:20:11 +0200 From: Harald Welte To: Patrick McHardy Cc: Christian Daniel , netdev@oss.sgi.com Subject: Re: "dst cache overflow" Message-ID: <20040922012011.GL3236@sunbeam.de.gnumonks.org> References: <200409201907.43317.cd@cdaniel.de> <4150B00C.7010305@trash.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n1iI6MeELQa9IOaF" Content-Disposition: inline In-Reply-To: <4150B00C.7010305@trash.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1605 Lines: 51 --n1iI6MeELQa9IOaF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2004 at 12:49:48AM +0200, Patrick McHardy wrote: > Christian Daniel wrote: >=20 > >Hello everybody, > > > >I'm running Linux 2.6.8.1+pom20040621+imq+... as a firewall and router o= n=20 > >a 2MBit/s leased line to our ISP. After about 24 hours I get loads of "d= st=20 > >cache overflow" messages and extreme packet loss occurs on all routed=20 > >connections - bridges continue to work. >=20 > Have you tried without imq ? as stated in my other mail, imq is actually patched in the source, but not used on the running system. Since no imq code is executed, and I cannot see any place where imq changes core networking code, I doubt it has any relation to this problem. > Regards > Patrick --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --n1iI6MeELQa9IOaF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUNNLXaXGVTD0i/8RAvEAAJ9i5CQpoe9qsDfKVSIcBFWm2x03XwCeIQCw AjcE0BqJ0WoVnzFmrvUXgKE= =kxzE -----END PGP SIGNATURE----- --n1iI6MeELQa9IOaF-- From herbert@gondor.apana.org.au Tue Sep 21 19:07:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:08:07 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M27vhC006402 for ; Tue, 21 Sep 2004 19:07:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9wXg-0004Hk-00; Wed, 22 Sep 2004 12:07:36 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9wXZ-0003f3-00; Wed, 22 Sep 2004 12:07:29 +1000 Date: Wed, 22 Sep 2004 12:07:29 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-ID: <20040922020729.GA14062@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20040920231805.3f18479c.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1836 Lines: 47 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 20, 2004 at 11:18:05PM -0700, David S. Miller wrote: > > > Yes CONFIG_IP_ROUTE_TOS has out-lived its usefulness. It has > > always seemed half-hearted compared to CONFIG_IP_ROUTE_FWMARK. > > Ok, then I'm gonna nuke it. Here is a follow-up patch to get rid of the remaining Kconfig references. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/Kconfig 1.18 vs edited ===== --- 1.18/net/ipv4/Kconfig 2004-09-22 06:35:25 +10:00 +++ edited/net/ipv4/Kconfig 2004-09-22 11:47:08 +10:00 @@ -60,12 +60,8 @@ Normally, a router decides what to do with a received packet based solely on the packet's final destination address. If you say Y here, the Linux router will also be able to take the packet's source - address into account. Furthermore, if you also say Y to "Use TOS - value as routing key" below, the TOS (Type-Of-Service) field of the - packet can be used for routing decisions as well. In addition, if - you say Y here and to "Fast network address translation" below, - the router will also be able to modify source and destination - addresses of forwarded packets. + address into account. Furthermore, the TOS (Type-Of-Service) field + of the packet can be used for routing decisions as well. If you are interested in this, please see the preliminary documentation at --MGYHOYXEY6WxJCY8-- From herbert@gondor.apana.org.au Tue Sep 21 19:19:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:19:10 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2J19I006853 for ; Tue, 21 Sep 2004 19:19:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9wiM-0004MD-00; Wed, 22 Sep 2004 12:18:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9wiC-0003gJ-00; Wed, 22 Sep 2004 12:18:28 +1000 From: Herbert Xu To: tgraf@suug.ch (Thomas Graf) Subject: Re: [PATCH 2.6 NET] Fix ifmap alignment issues over rtnetlink Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040921224127.GM566@postel.suug.ch> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 22 Sep 2004 12:18:28 +1000 X-archive-position: 9259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 703 Lines: 24 Thomas Graf wrote: > > @@ -277,6 +277,9 @@ > dev_change_flags(dev, ifm->ifi_flags); > > if (ida[IFLA_MAP - 1]) { > + struct rtnl_link_ifmap *u_map; > + struct ifmap k_map; > + > if (!dev->set_config) { > err = -EOPNOTSUPP; > goto out; > @@ -287,11 +290,19 @@ > + err = dev->set_config(dev, (struct ifmap *) &k_map); What's this cast for? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue Sep 21 19:39:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:39:41 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2daX6007551 for ; Tue, 21 Sep 2004 19:39:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9x20-0003NW-00; Tue, 21 Sep 2004 19:38:56 -0700 Date: Tue, 21 Sep 2004 19:38:56 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Fix help text Message-Id: <20040921193856.744626e8.davem@davemloft.net> In-Reply-To: <20040921.171517.213149358.yoshfuji@linux-ipv6.org> References: <20040921.171517.213149358.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8M2daX6007551 X-archive-position: 9260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 211 Lines: 8 On Tue, 21 Sep 2004 17:15:17 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Documentation/networking/tulip.txt is referred even though it is > unavailable. Applied, thanks. From davem@davemloft.net Tue Sep 21 19:42:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:42:48 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2ghaU007918 for ; Tue, 21 Sep 2004 19:42:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9wvr-0003Lq-00; Tue, 21 Sep 2004 19:32:35 -0700 Date: Tue, 21 Sep 2004 19:32:34 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040921193234.1c5b09a1.davem@davemloft.net> In-Reply-To: <20040922020729.GA14062@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040922020729.GA14062@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1479 Lines: 46 On Wed, 22 Sep 2004 12:07:29 +1000 Herbert Xu wrote: > On Mon, Sep 20, 2004 at 11:18:05PM -0700, David S. Miller wrote: > > > > > Yes CONFIG_IP_ROUTE_TOS has out-lived its usefulness. It has > > > always seemed half-hearted compared to CONFIG_IP_ROUTE_FWMARK. > > > > Ok, then I'm gonna nuke it. > > Here is a follow-up patch to get rid of the remaining Kconfig references. > > Signed-off-by: Herbert Xu I'll apply this, thanks Herbert. Dang, right after pushing the fib_hash.c cleanup to Linus I spotted this bug :-/ # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/21 16:32:41-07:00 davem@nuts.davemloft.net # [IPV4]: Fix list traversal in fn_hash_insert(). # # Could create an endless loop during route # replace operations. # # Signed-off-by: David S. Miller # # net/ipv4/fib_hash.c # 2004/09/21 16:31:48-07:00 davem@nuts.davemloft.net +1 -1 # [IPV4]: Fix list traversal in fn_hash_insert(). # diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c --- a/net/ipv4/fib_hash.c 2004-09-21 19:11:44 -07:00 +++ b/net/ipv4/fib_hash.c 2004-09-21 19:11:44 -07:00 @@ -536,7 +536,7 @@ * information. */ fa_orig = fa; - list_for_each_entry(fa, fa->fa_list.prev, fa_list) { + list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { if (fa->fa_info->fib_priority != fi->fib_priority) break; if (fa->fa_type == type && From davem@davemloft.net Tue Sep 21 19:46:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:46:33 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2kSOn008282 for ; Tue, 21 Sep 2004 19:46:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9wzU-0003Mm-00; Tue, 21 Sep 2004 19:36:20 -0700 Date: Tue, 21 Sep 2004 19:36:20 -0700 From: "David S. Miller" To: Herbert Xu Cc: tgraf@suug.ch, netdev@oss.sgi.com Subject: Re: [PATCH 2.6 NET] Fix ifmap alignment issues over rtnetlink Message-Id: <20040921193620.705e033c.davem@davemloft.net> In-Reply-To: References: <20040921224127.GM566@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 259 Lines: 11 On Wed, 22 Sep 2004 12:18:28 +1000 Herbert Xu wrote: > > + err = dev->set_config(dev, (struct ifmap *) &k_map); > > What's this cast for? Good catch, I deleted the cast when I applied his patch. Thanks Herbert. From pablo@eurodev.net Tue Sep 21 19:47:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:47:22 -0700 (PDT) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2lGv4008477 for ; Tue, 21 Sep 2004 19:47:17 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040922024700.UJIV10464.smtp09.retemail.es@eurodev.net>; Wed, 22 Sep 2004 04:47:00 +0200 Message-ID: <4150E7E5.2000001@eurodev.net> Date: Wed, 22 Sep 2004 04:48:05 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: hadi@cyberus.ca, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> In-Reply-To: <20040922000503.GA13218@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9263 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1121 Lines: 32 Hi Herbert, We are thinking in two different things: a) You think about netlink sockets as a method to pass information to kernel space via command line, in that case dump is ok. b) I'm thinking about netlink sockets as a method to generate event notifications. My benchmark tool just want to emulate that N events happen in a *very* short period of time (worst case), that implies sending N messages. So, forget that my tool sends previously a message to generate those N messages. But I'm intrigued about something jamal wrote: >For a test i typically have something adding say 10K items (actions in >my case, but could be ipsec policies) and then try to dump them. On my >xeon i get an overrun after about 6K items are dumped. > Jamal, you're getting an overrun dumping ipsec policies. If I'm not wrong, that tool is doing that as dump operation, but that this shouldn't happen by using dump. Am I missing something? I would like to have a way to send notifications via netlink sockets without losing congestion control ability, that is, without losing messages because of an overrun. regards, Pablo From davem@davemloft.net Tue Sep 21 19:52:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:52:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2qNiA009012 for ; Tue, 21 Sep 2004 19:52:23 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9x5C-0003O7-00; Tue, 21 Sep 2004 19:42:14 -0700 Date: Tue, 21 Sep 2004 19:42:14 -0700 From: "David S. Miller" To: Benjamin LaHaise Cc: herbert@gondor.apana.org.au, jchapman@katalix.com, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review Message-Id: <20040921194214.51d6b500.davem@davemloft.net> In-Reply-To: <20040922011421.GE19575@kvack.org> References: <20040921210427.GB19575@kvack.org> <20040922011421.GE19575@kvack.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1102 Lines: 25 On Tue, 21 Sep 2004 21:14:21 -0400 Benjamin LaHaise wrote: > On Wed, Sep 22, 2004 at 09:07:06AM +1000, Herbert Xu wrote: > > Benjamin LaHaise wrote: > > > > > >> - Unlikely to integrate with the new native IPSEC stuff. > > > > > > L2TP over IPSEC? Are you insane? You'd not be able to terminate more than > > > a couple of dozen connections over it. =-) > > > > Why not? L2TP over IPsec is the only reason I'm looking at L2TP at all. > > CPU load. The main reason I was forced to revisit L2TP (imo, it's a > horrible protocol that suffers from too many bad decisions) was in its > role for terminating DSL. In this case one expects to be able to have > tens of thousands of connections terminated by a single box, which > means pushing hundreds of megabits of traffic. The overhead of crypto > operations in such a scenario makes it a far too costly choice. I've heard of usage of both types described by Herbert and yourself, and both are valid. Therefore it's great that your scheme scales so well Ben, but it has to support IPSEC properly as well. From hadi@cyberus.ca Tue Sep 21 19:54:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:54:08 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2s3C9009475 for ; Tue, 21 Sep 2004 19:54:03 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1C9xGU-0007ln-GD for netdev@oss.sgi.com; Tue, 21 Sep 2004 22:53:54 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9xGQ-00054e-1H; Tue, 21 Sep 2004 22:53:50 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Pablo Neira Cc: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <4150E7E5.2000001@eurodev.net> References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095821624.1045.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 22:53:44 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1064 Lines: 30 On Tue, 2004-09-21 at 22:48, Pablo Neira wrote: > jamal wrote: > > >For a test i typically have something adding say 10K items (actions in > >my case, but could be ipsec policies) and then try to dump them. On my > >xeon i get an overrun after about 6K items are dumped. > > > > Jamal, you're getting an overrun dumping ipsec policies. If I'm not > wrong, that tool is doing that as dump operation, but that this > shouldn't happen by using dump. Am I missing something? Its not ipsec policies, rather tc actions - but i expect the same to happen to ipsec policies being dumped.. > I would like to have a way to send notifications via netlink sockets > without losing congestion control ability, that is, without losing > messages because of an overrun. This is a legit requirement. It is also legit to be able to do so for just a basic get request (not a dump). Nothing in the semantics of netlink says that it should work in one way or the other only. cheers, jamal BTW, I was never able to dload your code; i think you might have taken it offline? From davem@davemloft.net Tue Sep 21 19:56:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:56:15 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2uAj2009856 for ; Tue, 21 Sep 2004 19:56:10 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9xI1-0003QJ-00; Tue, 21 Sep 2004 19:55:29 -0700 Date: Tue, 21 Sep 2004 19:55:29 -0700 From: "David S. Miller" To: Olaf Hering Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] remove leading space in linux/skbuff.h Message-Id: <20040921195529.0f355491.davem@davemloft.net> In-Reply-To: <20040918223832.GA28730@suse.de> References: <20040918223832.GA28730@suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 170 Lines: 6 Olaf, please resend your patches as attachments or something like that, there are "=20" all over your patch when I save the email and try to use it as a patch. Thanks. From hadi@cyberus.ca Tue Sep 21 19:57:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:57:50 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2vjTd010202 for ; Tue, 21 Sep 2004 19:57:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C9xK2-0000f4-4F for netdev@oss.sgi.com; Tue, 21 Sep 2004 22:57:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9xJy-0005Kr-QP; Tue, 21 Sep 2004 22:57:31 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040922000503.GA13218@gondor.apana.org.au> References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095821845.1047.9.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 22:57:26 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 495 Lines: 16 On Tue, 2004-09-21 at 20:05, Herbert Xu wrote: > Secondly each of your user-space messages is producing a number of > replies. This should be done as a dump operation. If you do it as > a dump operation, then you will never get overruns because the kernel > never sends more than the user can handle. This is not accurate. You will get overruns. Try adding a few thousand ipsec policies and then dumping them. Perhaps we can have the cb reset in case of overrun detection. cheers, jamal From davem@davemloft.net Tue Sep 21 19:58:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 19:58:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M2wi4m010535 for ; Tue, 21 Sep 2004 19:58:44 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9xKK-0003R0-00; Tue, 21 Sep 2004 19:57:52 -0700 Date: Tue, 21 Sep 2004 19:57:52 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: pekkas@netcore.fi, laforge@gnumonks.org, netdev@oss.sgi.com, usagi-users@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem Message-Id: <20040921195752.015e3d1d.davem@davemloft.net> In-Reply-To: <20040920.152012.114156249.yoshfuji@linux-ipv6.org> References: <20040919074605.GJ6005@sunbeam.de.gnumonks.org> <20040920.152012.114156249.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8M2wi4m010535 X-archive-position: 9268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 494 Lines: 16 On Mon, 20 Sep 2004 15:20:12 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > This behavior lives for years (AFAIK), > and we haven't got so many reports > because people usually bring loopback device first. > > I think the following message will help people, anyway. If ipv6 has a dependency upon this, why doesn't it just bring the device up itself at this moment if necessary? It is kind of silly to force this device up ordering upon people anyways. From davem@davemloft.net Tue Sep 21 20:00:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:01:03 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M30wGX010961 for ; Tue, 21 Sep 2004 20:00:58 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9xDM-0003PH-00; Tue, 21 Sep 2004 19:50:40 -0700 Date: Tue, 21 Sep 2004 19:50:40 -0700 From: "David S. Miller" To: Pablo Neira Cc: herbert@gondor.apana.org.au, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040921195040.483eaead.davem@davemloft.net> In-Reply-To: <4150E7E5.2000001@eurodev.net> References: <20040919120249.GA5963@gondor.apana.org.au> <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 582 Lines: 17 I think you should manage your "events" in your own data structure. Perhaps a circular buffer of some sort. Then provide ->dump() operation which fishes the events out of the circular buffer. That way you don't have to spam user space with a bunch of quick transactions, you just wake him up once and several events may be consumed and processed at once. You can make your own buffering policies that way, and therefore there is no need to complicate netlink for this purpose. Meanwhile, I'm going to revert Pablo's original netlink optimization until this is all sorted out. From hadi@cyberus.ca Tue Sep 21 20:04:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:04:05 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M340TL011317 for ; Tue, 21 Sep 2004 20:04:00 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C9xQ5-00034O-Vz for netdev@oss.sgi.com; Tue, 21 Sep 2004 23:03:49 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9xQ4-00063p-1O; Tue, 21 Sep 2004 23:03:48 -0400 Subject: Re: PPP-over-L2TP kernel support, new patch for review From: jamal Reply-To: hadi@cyberus.ca To: Benjamin LaHaise Cc: Herbert Xu , jchapman@katalix.com, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca In-Reply-To: <20040922011421.GE19575@kvack.org> References: <20040921210427.GB19575@kvack.org> <20040922011421.GE19575@kvack.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095822222.1046.16.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 23:03:42 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 756 Lines: 20 On Tue, 2004-09-21 at 21:14, Benjamin LaHaise wrote: > On Wed, Sep 22, 2004 at 09:07:06AM +1000, Herbert Xu wrote: > CPU load. > The main reason I was forced to revisit L2TP (imo, it's a > horrible protocol that suffers from too many bad decisions) was in its > role for terminating DSL. In this case one expects to be able to have > tens of thousands of connections terminated by a single box, which > means pushing hundreds of megabits of traffic. The overhead of crypto > operations in such a scenario makes it a far too costly choice. Bad excuse ;-> So use a crypto chip or do less connections and scale by distributing etc. I have a feeling tehres nothing inherent in your code that stops you from intergrating into ipsec. cheers, jamal From yoshfuji@linux-ipv6.org Tue Sep 21 20:06:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:06:35 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M36UDF011709 for ; Tue, 21 Sep 2004 20:06:30 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6B0EF33CE7; Wed, 22 Sep 2004 12:06:30 +0900 (JST) Date: Wed, 22 Sep 2004 12:06:30 +0900 (JST) Message-Id: <20040922.120630.96674716.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: pekkas@netcore.fi, laforge@gnumonks.org, netdev@oss.sgi.com, usagi-users@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: Re: 2.6.8.1 IPv6 Routing Problem From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040921195752.015e3d1d.davem@davemloft.net> References: <20040920.152012.114156249.yoshfuji@linux-ipv6.org> <20040921195752.015e3d1d.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 628 Lines: 17 In article <20040921195752.015e3d1d.davem@davemloft.net> (at Tue, 21 Sep 2004 19:57:52 -0700), "David S. Miller" says: > On Mon, 20 Sep 2004 15:20:12 +0900 (JST) > YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > This behavior lives for years (AFAIK), > > and we haven't got so many reports > > because people usually bring loopback device first. > > > > I think the following message will help people, anyway. > > If ipv6 has a dependency upon this, why doesn't it just > bring the device up itself at this moment if necessary? Okay, I'll make a patch for this. --yoshfuji From hadi@cyberus.ca Tue Sep 21 20:10:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:10:59 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3AtbQ012113 for ; Tue, 21 Sep 2004 20:10:55 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1C9xWm-0005pn-1N for netdev@oss.sgi.com; Tue, 21 Sep 2004 23:10:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9xWk-0006Oy-M0; Tue, 21 Sep 2004 23:10:42 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: Steve Blake Cc: netdev@oss.sgi.com In-Reply-To: <1095809938.2340.19.camel@localhost.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> <1095809938.2340.19.camel@localhost.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095822637.1048.23.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 23:10:38 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 491 Lines: 14 On Tue, 2004-09-21 at 19:38, Steven Blake wrote: > RFC 1812 was written before TOS routes were pulled out of OSPFv2 (due to > too fee independent implementations). No one implements FIB lookup as > described in RFC 1812 in the core. What people do implement is PBR, as > well as DSCP-based nexthop selection for MPLS DIFF-TE (RFC 3564). What about edge? The PBR nh selection is a post routing policy though. Do you see it valuable to have DSCP replace TOS for lookup? cheers, jamal From hadi@cyberus.ca Tue Sep 21 20:30:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:30:33 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3URe1015986 for ; Tue, 21 Sep 2004 20:30:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1C9xpg-0003jO-H9 for netdev@oss.sgi.com; Tue, 21 Sep 2004 23:30:16 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1C9xpd-00006w-SS; Tue, 21 Sep 2004 23:30:14 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <20040920121123.70baf895.davem@davemloft.net> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095823808.1045.40.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Sep 2004 23:30:09 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2925 Lines: 83 On Mon, 2004-09-20 at 15:11, David S. Miller wrote: > On 20 Sep 2004 09:24:32 -0400 > jamal wrote: > > > On Sun, 2004-09-19 at 22:53, David S. Miller wrote: Sorry missed this (that what happens with reading email backwards). > Furthermore, once you have 1000 devices the algorithms in > net/ipv4/fib_semantics.c fall apart. Yikes - I just looked. fib_sync_down and up are horrible. I think its at least 0(n^2). Yes, I can see what would happen when you suddenly bring down 1000 devices. > The code in fib_semantics.c was written assuming that next > hop information composed of a small set of unique entries. > So even if your routing tables were huge, those routing > entries pointed to a small group of unique next-hop objects > (which is what fib_info represents). > yep - i see it. > So all of that code was using a singly linked list of all > fib_info's to do lookups. Therefore once you have a couple > thousand entries, even the simplest event processing becomes > expensive. Good cleanup in -bk7 with the hashes. > > I like the idea except for when enforcing that scheme to be used > > by other algorithms[1]. > > It is the core issue. > > I read from this statement that it is envisioned that some > fib_node lookup algorithm could, in a different way, find > all fib_nodes corresponding to a given fib_info. I ask you > to provide what that mechanism might be before I am willing > to be concerned about this possibility :-) The way i see it is any new alg will have a fib_info at the end of its lookup but not fib_node. fib_semantics only cares about fib_info. Hence my comment above (my worry being you are breaking this relationship - in particular now that you are thrwoing out TOS) BTW, dont see the code in -bk7. > Jamal and others, while I have your brains active in this area > I have a question. > > I tried very hard to preserve existing behavior wrt. TOS > handling wrt. the setting of CONFIG_IP_ROUTE_TOS. Basically, > the r->rtm_tos is ignored when adding routes, and treated as > zero. > > I believe I was successful in preserving existing behavior, but > I wonder if it makes sense any longer. CONFIG_IP_ROUTE_TOS > changes not one data structure. It does exactly: > > 1) Controls the presence of a TOS comparison in > fib_rules.c:fib_lookup() > > 2) Controls, in fib_hash.c: > a) TOS comparison in fn_hash_lookup() > b) whether TOS is paid attention to in fn_hash_insert > c) similarly in fn_hash_delete() > > In the TOS comparison changes, the TOS test treats zero > TOS values as "any TOS". Therefore unless the user explicitly > tried to add a non-zero TOS route, TOS makes no difference > in behavior both with and without CONFIG_IP_ROUTE_TOS set. > > Therefore, I think it behooves us just kill off this config > value. It saves a mere 6 or 7 lines of code and no data > space. Still need comment on this after killing TOS? cheers, jamal From davem@davemloft.net Tue Sep 21 20:32:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:32:09 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3W340016273 for ; Tue, 21 Sep 2004 20:32:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9xqg-0003Wu-00; Tue, 21 Sep 2004 20:31:18 -0700 Date: Tue, 21 Sep 2004 20:31:18 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-Id: <20040921203118.734a0a7e.davem@davemloft.net> In-Reply-To: <20040920225140.GH1307@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1429 Lines: 40 Ok Harald, I did some snooping around and here is what I've come up with. 1) We have 5 or 6 implementations of "walk neighbour hash table in sequence", that's rediculious and is the only reason that hashtable layout or number of entries is even known by code outside of net/core/neighbour.c In fact, many cases get it wrong :( For example, the ARP seq_file stuff locks the normal hash table correctly but does zero locking when traversing the pneigh hashes. Oops. Another reason to put this logic in a common spot. So I think the first thing to do is to write table walker functions generically inside of net/core/neighbour.c This is the first step. 1.5) tbl->ops->hash() should return the raw hash, the caller will do the necessary masking. At this point, there is no reason to declare {P,}NEIGH_HASHMASK in net/neighbour.h 2) We should size these hash table dynamically, growing them at neigh_create() time. This makes the most sense, and the scheme is similar to how net/ipv4/fib_hash.c works, for example. 3) If we have a sysctl for this stuff at all, it will be for the limit of the hash table growth, but I don't think that is necessary given #2 I like the jenkins hash change and yes I think it should be applied elsewhere too. I'll work on the set of patches implementing the above tomorrow and will send it to the list for review and commentary. From davem@davemloft.net Tue Sep 21 20:37:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:37:27 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3bMJf016710 for ; Tue, 21 Sep 2004 20:37:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1C9xvw-0003XX-00; Tue, 21 Sep 2004 20:36:44 -0700 Date: Tue, 21 Sep 2004 20:36:43 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Clean up fib_hash datastructures Message-Id: <20040921203643.3e15e877.davem@davemloft.net> In-Reply-To: <1095823808.1045.40.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <1095823808.1045.40.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 139 Lines: 6 On 21 Sep 2004 23:30:09 -0400 jamal wrote: > Still need comment on this after killing TOS? Nope, not at all, thanks :) From herbert@gondor.apana.org.au Tue Sep 21 20:40:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:40:14 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3e5Bs017102 for ; Tue, 21 Sep 2004 20:40:06 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9xyk-0004jy-00; Wed, 22 Sep 2004 13:39:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9xyd-0003qD-00; Wed, 22 Sep 2004 13:39:31 +1000 Date: Wed, 22 Sep 2004 13:39:31 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040922033931.GA14747@gondor.apana.org.au> References: <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <1095821845.1047.9.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095821845.1047.9.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1034 Lines: 24 On Tue, Sep 21, 2004 at 10:57:26PM -0400, jamal wrote: > > > Secondly each of your user-space messages is producing a number of > > replies. This should be done as a dump operation. If you do it as > > a dump operation, then you will never get overruns because the kernel > > never sends more than the user can handle. > > This is not accurate. You will get overruns. Try adding a few thousand > ipsec policies and then dumping them. Perhaps we can have the cb reset > in case of overrun detection. I just happen to have a few thousand ipsec policies :) I dump them all the time with the great new tool in iproute and I've never had any overruns. In contrast whenever I use setkey to dump them over PFKEY it dies very quickly indeed. I bet that there is a bug somewhere in the tc stuff. Let me have a look. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Sep 21 20:47:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:47:09 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3l0GM017494 for ; Tue, 21 Sep 2004 20:47:01 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9y5V-0004mO-00; Wed, 22 Sep 2004 13:46:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9y5T-0003t0-00; Wed, 22 Sep 2004 13:46:35 +1000 Date: Wed, 22 Sep 2004 13:46:35 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040922034634.GA14928@gondor.apana.org.au> References: <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <1095821624.1045.6.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095821624.1045.6.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 517 Lines: 14 On Tue, Sep 21, 2004 at 10:53:44PM -0400, jamal wrote: > > Its not ipsec policies, rather tc actions - but i expect the same to > happen to ipsec policies being dumped.. Well I haven't seen any with IPsec. Can you please provide a strace of a failed tc dump so that I know what I'm looking for? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue Sep 21 20:57:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 20:57:43 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M3vYuA018057 for ; Tue, 21 Sep 2004 20:57:35 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9yFp-0004ny-00; Wed, 22 Sep 2004 13:57:17 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9yFj-0004Ui-00; Wed, 22 Sep 2004 13:57:11 +1000 Date: Wed, 22 Sep 2004 13:57:10 +1000 To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: [IPv4] Check PAGE_SIZE in fz_hash_alloc Message-ID: <20040922035710.GA17249@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040922020729.GA14062@gondor.apana.org.au> <20040921193234.1c5b09a1.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20040921193234.1c5b09a1.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1543 Lines: 57 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 21, 2004 at 07:32:34PM -0700, David S. Miller wrote: > > I'll apply this, thanks Herbert. Thanks. Here is a minor optimisation to fz_hash_alloc. The break-even point should be based on PAGE_SIZE rather than the value of divisor. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/fib_hash.c 1.21 vs edited ===== --- 1.21/net/ipv4/fib_hash.c 2004-09-22 06:35:25 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-22 13:05:41 +10:00 @@ -109,7 +109,7 @@ { unsigned long size = divisor * sizeof(struct hlist_head); - if (divisor <= 1024) { + if (size <= PAGE_SIZE) { return kmalloc(size, GFP_KERNEL); } else { return (struct hlist_head *) @@ -141,11 +141,12 @@ static void fz_hash_free(struct hlist_head *hash, int divisor) { - if (divisor <= 1024) + unsigned long size = divisor * sizeof(struct hlist_head); + + if (size <= PAGE_SIZE) kfree(hash); else - free_pages((unsigned long) hash, - get_order(divisor * sizeof(struct hlist_head))); + free_pages((unsigned long)hash, get_order(size)); } static void fn_rehash_zone(struct fn_zone *fz) --DocE+STaALJfprDB-- From herbert@gondor.apana.org.au Tue Sep 21 21:02:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 21:02:17 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M42AGM018480 for ; Tue, 21 Sep 2004 21:02:11 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9yKK-0004pd-00; Wed, 22 Sep 2004 14:01:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9yKJ-00051b-00; Wed, 22 Sep 2004 14:01:55 +1000 Date: Wed, 22 Sep 2004 14:01:55 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPv4] Kill remnant of ip_nat_dumb Message-ID: <20040922040155.GA19302@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1016 Lines: 37 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This line in net/ipv4/Makefile was left behind when the rest of the dumb NAT option was taken out. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/Makefile 1.24 vs edited ===== --- 1.24/net/ipv4/Makefile 2004-08-20 00:13:10 +10:00 +++ edited/net/ipv4/Makefile 2004-09-22 13:53:54 +10:00 @@ -11,7 +11,6 @@ obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o -obj-$(CONFIG_IP_ROUTE_NAT) += ip_nat_dumb.o obj-$(CONFIG_IP_MROUTE) += ipmr.o obj-$(CONFIG_NET_IPIP) += ipip.o obj-$(CONFIG_NET_IPGRE) += ip_gre.o --u3/rZRmxL6MmkK24-- From herbert@gondor.apana.org.au Tue Sep 21 21:53:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 21:53:21 -0700 (PDT) Received: from arnor.apana.org.au (203-217-17-39.perm.iinet.net.au [203.217.17.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M4rB2q019759 for ; Tue, 21 Sep 2004 21:53:12 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C9z7X-0004xt-00; Wed, 22 Sep 2004 14:52:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C9z7P-00056P-00; Wed, 22 Sep 2004 14:52:39 +1000 Date: Wed, 22 Sep 2004 14:52:39 +1000 To: Pablo Neira Cc: hadi@cyberus.ca, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040922045239.GA19573@gondor.apana.org.au> References: <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4150E7E5.2000001@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1794 Lines: 41 On Wed, Sep 22, 2004 at 04:48:05AM +0200, Pablo Neira wrote: > > b) I'm thinking about netlink sockets as a method to generate event > notifications. My benchmark tool just want to emulate that N events > happen in a *very* short period of time (worst case), that implies > sending N messages. So, forget that my tool sends previously a message > to generate those N messages. That's what I thought you wanted too, something like ip_queue. You've got to remember that for ip_queue netlink is inherently *unreliable*. Your application must be able to cope with dropped packets and recover in a sane way. The kernel makes it slightly easier for you in that it'll tell you if messages have been dropped. But in the end it's up to the application to deal with it. The only knob that you can tweak is the receive queue length. You might think that making the kernel wait/back off is going solve the problem. But it's just another way of extending the receive queue length. > Jamal, you're getting an overrun dumping ipsec policies. If I'm not > wrong, that tool is doing that as dump operation, but that this > shouldn't happen by using dump. Am I missing something? I've never seen any overruns with IPsec. Perhaps there is a bug somewhere. > I would like to have a way to send notifications via netlink sockets > without losing congestion control ability, that is, without losing > messages because of an overrun. Congestion control similar to the way dumping works may work for you. But you need to tell us more about what you're actually using this for. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From dtor_core@ameritech.net Tue Sep 21 23:27:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 21 Sep 2004 23:27:38 -0700 (PDT) Received: from smtp812.mail.sc5.yahoo.com (smtp812.mail.sc5.yahoo.com [66.163.170.82]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8M6RV27028413 for ; Tue, 21 Sep 2004 23:27:31 -0700 Received: from unknown (HELO core-wl.prvt.inr.net) (dtor?core@ameritech.net@68.21.92.85 with plain) by smtp812.mail.sc5.yahoo.com with SMTP; 22 Sep 2004 06:27:20 -0000 From: Dmitry Torokhov To: netdev@oss.sgi.com Subject: OOPS when enslaving atmel card to bonded interface (2.6.9-rc2-bk-pull) Date: Wed, 22 Sep 2004 01:27:18 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200409220127.19174.dtor_core@ameritech.net> X-archive-position: 9281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dtor_core@ameritech.net Precedence: bulk X-list: netdev Content-Length: 2974 Lines: 47 Hi, Getting the following OOPs at startup when PCMCIA discovers an SMC wireless card (atmel_cs) and tries to enslave it to bond0. The kernel is last night pull form Linus. -- Dmitry ep 22 01:12:51 core kernel: eth1: SMC 2632W-V2 index 0x01: Vcc 3.3, irq 3, io 0x0100-0x011f Sep 22 01:12:51 core kernel: Unable to handle kernel paging request at virtual address 962da8e8 Sep 22 01:12:51 core kernel: printing eip: Sep 22 01:12:51 core kernel: c02c5c99 Sep 22 01:12:51 core kernel: *pde = 00000000 Sep 22 01:12:51 core kernel: Oops: 0000 [#1] Sep 22 01:12:51 core kernel: PREEMPT Sep 22 01:12:51 core kernel: Modules linked in: atmel_cs atmel firmware_class crc32 3c59x bonding iptable_filter snd_maestro3 sn d_ac97_codec snd_pcm snd_timer snd_page_alloc snd soundcore uhci_hcd usbcore mousedev psmouse Sep 22 01:12:51 core kernel: CPU: 0 Sep 22 01:12:51 core kernel: EIP: 0060:[] Not tainted VLI Sep 22 01:12:51 core kernel: EFLAGS: 00010287 (2.6.9-rc2) Sep 22 01:12:51 core kernel: EIP is at fn_hash_insert+0x3a9/0x420 Sep 22 01:12:51 core kernel: eax: 00000000 ebx: de985e68 ecx: 962da8c0 edx: 00000c01 Sep 22 01:12:51 core kernel: esi: deed7268 edi: dfbad2c0 ebp: de985e00 esp: de985d94 Sep 22 01:12:51 core kernel: ds: 007b es: 007b ss: 0068 Sep 22 01:12:51 core kernel: Process ifenslave (pid: 2388, threadinfo=de985000 task=df8c6aa0) Sep 22 01:12:51 core kernel: Stack: de985dec de9c3440 de985db4 c017eb96 def2b280 00000000 962da8c0 de9e731c Sep 22 01:12:51 core kernel: de980c01 c011e831 00004000 de9c3b60 def2b280 962da8c0 009c3b60 00000002 Sep 22 01:12:51 core kernel: 00000020 df1e3860 de985e04 deed7260 00000004 dfc9ade0 ffffffef 962da8c0 Sep 22 01:12:51 core kernel: Call Trace: Sep 22 01:12:51 core kernel: [] show_stack+0x7a/0x90 Sep 22 01:12:51 core kernel: [] show_registers+0x14a/0x1c0 Sep 22 01:12:51 core kernel: [] die+0xdb/0x170 Sep 22 01:12:51 core kernel: [] do_page_fault+0x23a/0x590 Sep 22 01:12:51 core kernel: [] error_code+0x2d/0x38 Sep 22 01:12:51 core kernel: [] fib_magic+0xd7/0xf0 Sep 22 01:12:51 core kernel: [] fib_add_ifaddr+0x64/0x160 Sep 22 01:12:51 core kernel: [] fib_inetaddr_event+0x4b/0x50 Sep 22 01:12:51 core kernel: [] notifier_call_chain+0x28/0x50 Sep 22 01:12:51 core kernel: [] inet_insert_ifa+0xa0/0x150 Sep 22 01:12:51 core kernel: [] devinet_ioctl+0x349/0x6f0 Sep 22 01:12:51 core kernel: [] inet_ioctl+0x63/0xa0 Sep 22 01:12:51 core kernel: [] sock_ioctl+0x102/0x2a0 Sep 22 01:12:51 core kernel: [] sys_ioctl+0xf6/0x240 Sep 22 01:12:51 core kernel: [] syscall_call+0x7/0xb Sep 22 01:12:51 core kernel: Code: 8b 46 04 8b 30 8b 0e 89 4d a4 0f 18 01 90 3b 76 04 74 37 8b 47 28 89 45 a8 89 f6 8d bc 27 00 00 00 00 8b 4e 08 8b 45 a8 89 4d ac <39> 41 28 75 1a 0f b6 46 0d 3b 45 d0 74 25 8b 75 a4 8b 06 89 45 From olh@suse.de Wed Sep 22 01:42:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 01:42:33 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M8gPqk007521 for ; Wed, 22 Sep 2004 01:42:26 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 054B4C48C5C; Wed, 22 Sep 2004 10:42:09 +0200 (CEST) Date: Wed, 22 Sep 2004 10:42:08 +0200 From: Olaf Hering To: "David S. Miller" Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] remove leading space in linux/skbuff.h Message-ID: <20040922084208.GB12717@suse.de> References: <20040918223832.GA28730@suse.de> <20040921195529.0f355491.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040921195529.0f355491.davem@davemloft.net> X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-archive-position: 9282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 3014 Lines: 65 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Sep 21, David S. Miller wrote: > > Olaf, please resend your patches as attachments or something > like that, there are "=20" all over your patch when I > save the email and try to use it as a patch. David, msgid 20040918224507.GA28794@suse.de and the reply doesnt contain such an encoding. Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit -- USB is for mice, FireWire is for men! sUse lINUX ag, nÃœRNBERG --J2SCkAp4GZ/dPZZf Content-Type: application/x-gunzip Content-Disposition: attachment; filename="1095547557.3917_1.wotan:2,S.gz" Content-Transfer-Encoding: base64 H4sICKW6TEECAzEwOTU1NDc1NTcuMzkxN18xLndvdGFuOjIsUwC9Vttyo0gSfXZ9RXbMi3wp BAgkwG2HdXNb0bbsEOqZ7uiYUCAopBojSksVsh0b8yfzN/tjmyVZbV3snu7djcXGGCrJOnky 85ADpsoip3eRmgbwPmcqYQs6FmUeswshpSEn3IjF7Jx8prcFn/A8yuhQBCCy6cWDUFFuyFIy I2FkwGLGFywJIC3EDKasmDG5XoXKzv1XyzT0j/X7ITkYP8GWL6jcCalS/ngID1xNoRveDO+A J2Bd2p263fJrbXKQigLe78E4P4WwzE/A8iFkc7BN0wHTDBw3cBtwbOI9VNrdcHi4gRe330W7 3p8c6F39VtftdJqty//A+ZIMGUf5FF2+bLD35Kvl+IbjGFbdNGr1Z1begrVLS81y/XqzWetu 0PJfEPJqAjcB6qxp2t6Oay8eqESzaMFlQnP2cAJzUSiwTNN20dNONI5p2dR0YT8U8mYs7ndj aUe5EsULynj7/qvlu4ZVcw3bNg1bc18pJc8nMLwOF9YKXsznyAh0O1d0EDZppxvSdqtdo+FV EypW3aviCWOu5KF+vS8gzjjLFcSsUDzlcaQYFOwfJZOKJT+V3bbtWs3OZbvh/lR2v8/IRm9D ZfMGubANxzOwogy78VyHu/y9gbTZdptm27Zcr/FTUJ0fh5qJOMqeC8xubEnIlh0GUDPM6uqy i5N7vZt783pqWqbtm6fkIIwUAvNegFlu4NQD0wJqNkxzA9HKUbs5GPZCqCwsjeAUMo6AVuJ5 iGG+5s0NbG/lDenr/A9K9Kcj/qPf62HEpuU/J2cFeEvm3wZf26PiOzJP2aN6DbpleP+37vrB mm3Xupata7bh60J4vULNHans4H4B/I0xuUSCArjNohSuWKEj3uoHor+jzTwp2APcoByKHN5H 9/MZJiTJDFFMzk9gP0UkLMd/sFgFMEAIX++aw/bV7xj7TCwYZCxK9D5yHsUMeI6FmZePVXk/ LtPUmJIbJmU0YbTXwY+9hmz6lmfbjms2jA9N22v4zgu8AUtZwXAQkFvGNa9mr4xr5ovxDZ8x +isrJBd5ANgWpC1yhSmiw6c5AlVYEdV5FvH8FOJpVEimzkqVUu+bXYfLuZBcLR3wHJGzFx9F lEtEQ7t5LHSEAXhYDaSX0wGbZ0/LkeRvMX6mndswgB5MhIInURZQd8yPyGOUYQKwRgZ8MlU6 VwxaZZI8vcNXrsSMZVGe0JDFZcHVUwBfRAkR2uToRpZzRM0SUAKTEOF1yqWmnb37Zhdh9EUh ChSJd+STxDCaE4wqgJtSKSjzBBYcsCMSSEQ8xY/qNGdZhu0QZRL6QjEJFW31oRDl/Dcu2SHi iop4in1IXzjzzbqDCyyOsCckXayT0V09gJVYkZDlCSsCeHPWI10NVi45fdvoMxXreVA+e9wo bnJXoE4kunpwviqze7TXIrn2iLe/8qKUNESdy5+HsI0BASK1N1zgO+E8mtFQRarEmuyLE5ii JJxRDAxUNJmwZBSNsQ/OKIqkuRQEXrDkzNXrKA3yrNX80g1HjnNC4ObL6LrX//R57faaLVgW ACFwm69aW/e15Z9sdfBDgfkICDkH/C1zniYsBeRjWdoScPtSYQ3stKJBgMyipzFbLj1MRcbw pWVtA0YJ42Wz/rLyNhp97A763evRiJCQT5AdKtKUjp++pyUk4WkKdF4W/VXTU9uoG16V53FW Jqy6LQSbJsbj4+MbZoRS+gPeDnTjUdOnqIUogZYV1HzD9B2r4XiO+SyGx8fHP7jrjjvHDvQ4 4jXcmlf319p6cQHUqp3U4Rj/NuDiAhnWBOZLBpeJHYUfW58uL0dXuIBPsSX3Fo73KV+6WeGC 9ytgmKmUT4zp+f7SPSuwV/WSBmQ3LMRybDfsJSSQqihjLOT7kY4M/knWKW7f9i97H0b97nDU vg5HzfaQwMFoVNZseDlUPMIeTk5h+6gegSqiFD96yxIqRAbajONGR9XX3cRZJCXf9vSKm2cz 7YbCL9jUPEWGVldNy/q/ZaieuwzVq2MOXg31AI8jfAWH9j/xJPQVrqtHBODo4Ar1NdM1jQKn ME9yKZsiz3DESbEzUD6xe7XE6vZZca5fRJwUyKewBShveqSZ8ZidwCU2/W94fnvK8neESFRe yHT+IZrgl/Vffw36re7gAyH/Bq9mYhoEDwAA --J2SCkAp4GZ/dPZZf-- From jchapman@katalix.com Wed Sep 22 02:59:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 02:59:50 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8M9xVV2014865 for ; Wed, 22 Sep 2004 02:59:31 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1CA3t6-0001Su-Ok; Wed, 22 Sep 2004 04:58:12 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Wed, 22 Sep 2004 10:58:12 +0100 Message-ID: <1095847092.41514cb435b7e@www.katalix.com> Date: Wed, 22 Sep 2004 10:58:12 +0100 From: James Chapman To: Benjamin LaHaise , "David S. Miller" Cc: netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review References: <1095714704.414f4790cd168@www.katalix.com> <20040920141704.16085067.davem@davemloft.net> <1095760525.414ffa8d111a1@www.katalix.com> <20040921210427.GB19575@kvack.org> In-Reply-To: <20040921210427.GB19575@kvack.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 3617 Lines: 87 Although Ben and I are both working on L2TP projects, I think we're targetting two totally different usage scenarios. Time for some ASCII art... 1. ISP scenario +----+ ---+ D | ---| S | +--------+ +-------+ ---| L |======| LAC |==============| LNS | ---| A | | | | | ---| M | +--------+ +-------+ ---| | ---| | ---| | +----+ thousands PPPoA each PPP session of PPP or tunneled thru clients PPPoE L2TP session to LNS 2. VPN scenario +---+ +------+ |LAC+----------------------------------| | +---+ | | +---+ | | |LAC+----------------------------------| LNS | +---+ | | +---+ | | |LAC+----------------------------------| | +---+ | | +------+ PPP client Terminates in each LAC. multiple tunnels Typically 1 session per tunnel Ben is addressing the ISP case, where client PPP sessions are terminated only temporarily at the LAC while it authenticates the PPP users to decide how to tunnel them. Each PPP session is then tunneled straight through the LAC via an L2TP session (inside an L2TP tunnel) to the LNS. Scalability is important here, which Ben has addressed. I'm addressing the VPN case, where multiple clients (M$ L2TP/IPSEC or rp-l2tp/openl2tp clients) connect to an enterprise VPN server. Current solutions involve userspace pty hacks in the datapath, shunting data in and out of pppd ttys. The proposed driver moves the datapath into the kernel where it should be. The driver integrates with existing PPP and IPSEC kernel subsystems and will handle hundreds of sessions today. The biggest difference in our approaches is that Martijn and I use a PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel socket while Ben uses a new AF_L2TP tunnel socket and no separate socket per session. Both have their merits. If I can put the case for our driver, Linux really needs a good VPN solution. I know of two companies that run their offices with Linux servers yet they both retain a Microsoft server _only_ to provide VPN access to off-site workers. Including this driver in the kernel will enable us to build binary packages for OpenL2TP and perhaps other L2TP solutions like rp-l2tp would be updated to use it too. Being able to handle hundreds (not thousands) of sessions is more than adequate in this case. Where do we go from here then? Perhaps both approaches are equally valid and could even co-exist in the Linux kernel distribution? /james Quoting Benjamin LaHaise : > > - Architecture seems to be using char devices for communication with > > the kernel and all the PPP datapath is handled by custom virtual > > net_devices; the generic PPP kernel code isn't used as far as I can > > tell. Unfortunately it is very old (linux-2.0 era I think) but Ben > > has probably updated it. > > I've updated it. The current build is at http://www.kvack.org/~bcrl/babylon/ > and is 1.6-pre3-bcrl8. [snip] From herbert@gondor.apana.org.au Wed Sep 22 03:55:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 03:55:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MAt17p016526 for ; Wed, 22 Sep 2004 03:55:04 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CA4lP-0007K2-00; Wed, 22 Sep 2004 20:54:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CA4kn-0005jn-00; Wed, 22 Sep 2004 20:53:41 +1000 From: Herbert Xu To: jchapman@katalix.com (James Chapman) Subject: Re: PPP-over-L2TP kernel support, new patch for review Cc: bcrl@kvack.org, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Organization: Core In-Reply-To: <1095847092.41514cb435b7e@www.katalix.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 22 Sep 2004 20:53:41 +1000 X-archive-position: 9284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 704 Lines: 17 James Chapman wrote: > > The biggest difference in our approaches is that Martijn and I use a > PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel > socket while Ben uses a new AF_L2TP tunnel socket and no separate > socket per session. Both have their merits. Can you elaborate on the merits of having a socket? It would seem to me that not having a socket is a lot more scalable. After all IPsec doesn't carry a socket around per session. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From laforge@gnumonks.org Wed Sep 22 04:15:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 04:15:20 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MBF00v017680 for ; Wed, 22 Sep 2004 04:15:01 -0700 Received: from dsl-082-082-103-103.arcor-ip.net ([82.82.103.103] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CA55E-0002av-9A; Wed, 22 Sep 2004 13:14:48 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CA55D-0001Wr-4T; Wed, 22 Sep 2004 13:14:47 +0200 Date: Wed, 22 Sep 2004 13:14:47 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-ID: <20040922111447.GP3236@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> <20040921203118.734a0a7e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nccO0ldXW0cuDU6a" Content-Disposition: inline In-Reply-To: <20040921203118.734a0a7e.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 2522 Lines: 72 --nccO0ldXW0cuDU6a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 08:31:18PM -0700, David S. Miller wrote: =20 > Ok Harald, I did some snooping around and here is what > I've come up with. Thanks for digging into this issue. > 1) We have 5 or 6 implementations of "walk neighbour hash > table in sequence", that's rediculious and is the only > reason that hashtable layout or number of entries is > even known by code outside of net/core/neighbour.c > [...] > 1.5) tbl->ops->hash() should return the raw hash, the caller > will do the necessary masking. > [...] >=20 > 2) We should size these hash table dynamically, growing them > at neigh_create() time. great, that sounds like a scalable approach. I'm looking forward to reading through the code :) > 3) If we have a sysctl for this stuff at all, it will be for > the limit of the hash table growth, but I don't think that > is necessary given #2 But we will still have the existing sysctls for the garbage collector, I guess (like gc_thresh*). =20 And I still want to address the "all complete entries flushed due to lots of bogus incomplete entires" issue somehow. As stated before, I have seen this on happen on live systems. =20 Do you agree that this is an existing problem? I think just having a certain 'reserve' for complete entries (or a let's say 80% limit for incomplete ones) should address this issue. btw: I guess you're implementing this as 2.6.x only patch. Once you're finished, I'll have to do a 2.4.x backport anyway [for business reasons *g*]. So don't bother doing that, I'll post the patch here (which doesn't imply that I want to have it merged mainline). --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --nccO0ldXW0cuDU6a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUV6nXaXGVTD0i/8RAj2vAKCSr1GNraXld1/8enzBtqwpqXz2PQCgoDjl Yc58z9aa9wUR9s7ELYJEKoc= =88zI -----END PGP SIGNATURE----- --nccO0ldXW0cuDU6a-- From hadi@cyberus.ca Wed Sep 22 04:36:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 04:36:30 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MBaGJu021564 for ; Wed, 22 Sep 2004 04:36:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CA5Pm-0002ZX-5U for netdev@oss.sgi.com; Wed, 22 Sep 2004 07:36:02 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CA5Pj-0002E1-CX; Wed, 22 Sep 2004 07:35:59 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040922034634.GA14928@gondor.apana.org.au> References: <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <1095821624.1045.6.camel@jzny.localdomain> <20040922034634.GA14928@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095852956.1048.47.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Sep 2004 07:35:57 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 594 Lines: 30 On Tue, 2004-09-21 at 23:46, Herbert Xu wrote: > > Well I haven't seen any with IPsec. Can you please provide a strace > of a failed tc dump so that I know what I'm looking for? Try explicitly reducing the socket buffer size and see what happens Heres a script i use (you would need to compile tc action gact and have the latest iproute2): --- #!/bin/sh tc qdisc del dev eth1 ingress tc qdisc add dev eth1 ingress for ((i = 1 ; i <= $1 ; i++)) do tc actions add action drop index $i done ---- set i to 10000 or a little more to dump: tc actions ls action drop cheers, jamal From slblake@petri-meat.com Wed Sep 22 04:56:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 04:56:53 -0700 (PDT) Received: from server26.totalchoicehosting.com (server26.totalchoicehosting.com [209.152.177.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MBuew9022383 for ; Wed, 22 Sep 2004 04:56:40 -0700 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1CA5jU-0001N0-Qt; Wed, 22 Sep 2004 07:56:24 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: Steven Blake To: hadi@cyberus.ca Cc: netdev@oss.sgi.com In-Reply-To: <1095822637.1048.23.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> <1095809938.2340.19.camel@localhost.localdomain> <1095822637.1048.23.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1095854181.2342.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 22 Sep 2004 07:56:21 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 9287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: slblake@petri-meat.com Precedence: bulk X-list: netdev Content-Length: 676 Lines: 23 On Tue, 2004-09-21 at 23:10, jamal wrote: > On Tue, 2004-09-21 at 19:38, Steven Blake wrote: > > > RFC 1812 was written before TOS routes were pulled out of OSPFv2 (due to > > too fee independent implementations). No one implements FIB lookup as > > described in RFC 1812 in the core. What people do implement is PBR, as > > well as DSCP-based nexthop selection for MPLS DIFF-TE (RFC 3564). > > What about edge? I've seen no evidence that any HW-based router is doing this. > The PBR nh selection is a post routing policy though. Do you see it > valuable to have DSCP replace TOS for lookup? No. No protocol is distributing DSCP-based routes. Regards, // Steve From SRS0+ba6e40e72d677e93dd28+395+infradead.org+dwmw2@pentafluge.srs.infradead.org Wed Sep 22 05:09:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 05:09:18 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MC99Tc022941 for ; Wed, 22 Sep 2004 05:09:10 -0700 Received: from [213.86.99.236] (helo=[172.16.18.64]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CA5vZ-0007eu-KC; Wed, 22 Sep 2004 13:08:54 +0100 Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. From: David Woodhouse To: Andre Tomt Cc: Jeff Garzik , Pekka Pietikainen , netdev@oss.sgi.com In-Reply-To: <414FC92F.6090009@tomt.net> References: <20040920212453.GA15392@ee.oulu.fi> <414F7CD9.3090008@pobox.com> <414FC92F.6090009@tomt.net> Content-Type: text/plain Message-Id: <1095854932.17821.1190.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Wed, 22 Sep 2004 13:08:52 +0100 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 9289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: netdev Content-Length: 753 Lines: 21 On Tue, 2004-09-21 at 08:24 +0200, Andre Tomt wrote: > Jeff Garzik wrote: > > I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6 > > router). > > > > No idea why it went away, I just assumed a more recent kernel fixed > > something. > > We've been seeing this all the time on 2.6.8.1 + "critical fixes". > Pretty much anytime a router with tunneling interfaces is taken down for > shutdown or reboot, it hangs spinning waiting for the tunnel devices to > get freed, as ifdown gets run. It's not just tunnel interfaces. It seems to be related to hot-unplug of interfaces with live IPv6 addresses. I've seen it on my prism54 card too on many recent kernels. All I have to do is insert it and remove it a few times. -- dwmw2 From hadi@cyberus.ca Wed Sep 22 05:08:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 05:09:10 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MC8wQQ022930 for ; Wed, 22 Sep 2004 05:08:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CA5vQ-0001pf-8z for netdev@oss.sgi.com; Wed, 22 Sep 2004 08:08:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CA5vP-0005vL-03; Wed, 22 Sep 2004 08:08:43 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040922045239.GA19573@gondor.apana.org.au> References: <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095854920.1047.64.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Sep 2004 08:08:40 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 509 Lines: 14 On Wed, 2004-09-22 at 00:52, Herbert Xu wrote: > Congestion control similar to the way dumping works may work for you. Note the initial goal was to have dump work for large tables and a simple get for a basic table row. Since netlink is being used for a lot of things now, it may be time to obsolete those assumptions. Note also, theres a lot of wastage of that scarce sock buffer via page sized skbs - its not as trivial to fix, but would go some way to improve overrunning of the socket. cheers, jamal From hadi@cyberus.ca Wed Sep 22 05:10:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 05:11:06 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MCAvk9023585 for ; Wed, 22 Sep 2004 05:10:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CA5xL-0002CQ-NY for netdev@oss.sgi.com; Wed, 22 Sep 2004 08:10:43 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CA5xJ-00067Q-SV; Wed, 22 Sep 2004 08:10:42 -0400 Subject: Re: [IPv4] Kill remnant of ip_nat_dumb From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040922040155.GA19302@gondor.apana.org.au> References: <20040922040155.GA19302@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095855039.1045.67.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Sep 2004 08:10:39 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 403 Lines: 18 Geez, I missed that we killed static NAT too. Whats wrong with it? I know at least two users of this - did we ask or is posting on netdev == ask? cheers, jamal On Wed, 2004-09-22 at 00:01, Herbert Xu wrote: > Hi Dave: > > This line in net/ipv4/Makefile was left behind when the rest of the > dumb NAT option was taken out. > > Signed-off-by: Herbert Xu > > Cheers, From hadi@cyberus.ca Wed Sep 22 05:12:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 05:13:00 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MCCp6h023941 for ; Wed, 22 Sep 2004 05:12:51 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CA5zB-0003N6-DC for netdev@oss.sgi.com; Wed, 22 Sep 2004 08:12:37 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CA5zA-0006Mh-9a; Wed, 22 Sep 2004 08:12:36 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: jamal Reply-To: hadi@cyberus.ca To: Steve Blake Cc: netdev@oss.sgi.com In-Reply-To: <1095854181.2342.2.camel@localhost.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> <1095809938.2340.19.camel@localhost.localdomain> <1095822637.1048.23.camel@jzny.localdomain> <1095854181.2342.2.camel@localhost.localdomain> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095855154.1047.70.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Sep 2004 08:12:34 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 925 Lines: 29 On Wed, 2004-09-22 at 07:56, Steven Blake wrote: > On Tue, 2004-09-21 at 23:10, jamal wrote: > > > On Tue, 2004-09-21 at 19:38, Steven Blake wrote: > > > > > RFC 1812 was written before TOS routes were pulled out of OSPFv2 (due to > > > too fee independent implementations). No one implements FIB lookup as > > > described in RFC 1812 in the core. What people do implement is PBR, as > > > well as DSCP-based nexthop selection for MPLS DIFF-TE (RFC 3564). > > > > What about edge? > > I've seen no evidence that any HW-based router is doing this. None of the chips i have come across had it - what about NPF, are they putting this in their specs? > > The PBR nh selection is a post routing policy though. Do you see it > > valuable to have DSCP replace TOS for lookup? > > No. No protocol is distributing DSCP-based routes. > Ok, sounds like we can write an obituary for TOS based routing. RIP. cheers, jamal From ak@suse.de Wed Sep 22 07:00:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 07:00:31 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ME0IH4026868 for ; Wed, 22 Sep 2004 07:00:19 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id AB632C4BE61; Wed, 22 Sep 2004 16:00:02 +0200 (CEST) Date: Wed, 22 Sep 2004 16:00:00 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040922140000.GD27432@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040921155835.18aee381.davem@davemloft.net> X-archive-position: 9292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1098 Lines: 29 On Tue, Sep 21, 2004 at 03:58:35PM -0700, David S. Miller wrote: > On Mon, 20 Sep 2004 22:30:21 +0200 > Andi Kleen wrote: > > > I see the same problem here, but it's even worse. I only get 150-200KB/s > > sending data with scp from a fast machine with e1000 with a gigabit link. > > netperf also gives only 250KB/s. > > So I re-enabled TSO support in the loopback driver to try and > reproduce this, but I can't. > > There has been a lot of churn in this area so please make sure you > are using the latest sources, all of my current TSO fixes are in > Linus's BK tree. I tried it with rc2bk8 again and the performance is much better (22MB/s) that what I got earlier with 2.6.8rc2, but still far below what 2.6.5 gets on the same hardware (68MB/s) Both tests with netperf over e1000. > And, take the patch below and do a loopback bandwidth test before > and after the patch is applied. Do things slow down when loopback > has TSO enabled just as it does for your gigabit interfaces? Without TSO ~755MB/s, with TSO ~600-620MB/s (results seem to be a bit variable). -Andi From shemminger@osdl.org Wed Sep 22 09:23:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 09:23:54 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MGNkQT008661 for ; Wed, 22 Sep 2004 09:23:47 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MGNJv31770; Wed, 22 Sep 2004 09:23:19 -0700 Date: Wed, 22 Sep 2004 09:23:19 -0700 From: Stephen Hemminger To: j@lumiere.net, "David S. Miller" Cc: netdev@oss.sgi.com Subject: Fw: [Bug 3419] New: kernel BUG at net/ipv4/fib_semantics.c:1039! Message-Id: <20040922092319.4ba5b8fb@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3592 Lines: 90 Is this fixed with the more recent version of 2.6.9? Dave Miller fixed up several initialization bugs from his earlier change. Begin forwarded message: Date: Sat, 18 Sep 2004 03:21:09 -0700 From: bugme-daemon@osdl.org To: shemminger@osdl.org Subject: [Bug 3419] New: kernel BUG at net/ipv4/fib_semantics.c:1039! http://bugme.osdl.org/show_bug.cgi?id=3419 Summary: kernel BUG at net/ipv4/fib_semantics.c:1039! Kernel Version: 2.6.9-rc2-bk3 Status: NEW Severity: normal Owner: shemminger@osdl.org Submitter: j@lumiere.net Distribution: Fedora Core 2 (i686) Hardware Environment: P4 3.2GHz 1MB cache, SuperMicro P4SCT+, 1 GB ECC RAM (2 x 512), 4 x SATA HD. Onboard components include two gigabit ethernet controllers, LAN1/eth0 in use (100Mbps, e1000). LAN1: Intel 82547GI (uses CSA), LAN2: (82541GI). Hance Rapids (6300ESB) ICH, Marvell 88SX5041 SATA controller. Software Environment: Fedora Core 2, updated to latest standard updates. Vanilla 2.6.9-rc2-bk3 kernel. Problem Description: During kudzu running on bootup, kernel BUG at net/ipv4/fib_semantics.c:1039! occurs. Boot continues until "Bringing up loopback interface:" at which point it gets stuck. Can still scroll up/down. Does NOT occur on 2.6.9-rc2. Steps to reproduce: Boot with 2.6.9-rc2-bk3 kernel and wait for 'Checking for new hardware'. Here's output... possibly with a few typos, as it's copied by hand. Checking for new hardware-------------[ cut here ]-------------- kernel BUG at net/ipv4/fib_semantics.c:1039! invalid operand: 0000 [#1] SMP Modules linked in: e1000 floppy sg microcode uhci_hcd ehci_hcd button battery asus_acpi ac ext3 jbd dm_mod ata_piix libata sd_mod linuxIAL scsi_mod raid5 xor raid1 CPU: 1 EIP: 0060:[] Tainted: P VLI EFLAGS: 00010246 (2.6.9-rc2-bk3-leaf) EIP is at fib_sync_down+0x197/0x1a4 eax: ffffffff ebx: 00000000 ecx: 00000002 edx: f7395000 esi: 00000000 edi: 00000006 ebp: f6395028 esp: f640dea8 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 924, threadinfo=f640d000 task=f7c38550) Stack: 00000282 c0104fd0 ffffffff 00000000 00000002 f6395000 f6395000 f6395000 00000006 f6395028 c02bcb35 c03455fc c02bcc14 c03455fc f6395000 c012ac76 f6395000 f6395000 c0339da8 c027bf23 00000000 c016c13a c014adda 00000292 Call Trace: []__down_trylock+0x3e/0x62 [] fib_disable_ip+0xe/0x28 [] fib_netdev_event+0x72/0x7e [] notifier_call_chain+0x17/0x2b [] unregister_netdevice+0x137/0x249 [] wake_up_inode+0xc/0x3b [] clear_inode+0x8/0xe2 [] unregister_netdev+0xf/0x15 [] e1000_remove+0x4c/0x7e [e1000] [] pci_device_remove+0x28/0x2a [] device_release_driver+0x56/0x58 [] driver_detach+0x16/0x21 [] bus_remove_driver+0x43/0x74 [] driver_unregister+0x8/0x19 [] pci_unregister_driver+0xb/0x13 [] sys_delete_module+0x121/0x150 [] unmap_vma_list+0xe/0x17 [] do_munmap+0x11c/0x15f [] do_page_fault+0x0/0x54b [] sysenter_past_esp+0x52/0x71 Code: e8 5b t1 01 00 83 04 24 01 8b 4f 5c eb 89 0f 0b 2a 04 1c b9 30 c0 e9 3a ff ff ff 83 48 1c 01 83 44 24 0c 01 8b 11 e9 dd fe ff ff <0f> 0b 0f 04 1c b9 30 c0 e9 9b fe ff ff 55 57 56 53 83 ec 10 89 [ OK ] Updating /etc/fstab [ OK ] Setting network parameters: [ OK ] Bringing up loopback interface: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From j@lumiere.net Wed Sep 22 09:26:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 09:27:02 -0700 (PDT) Received: from tetris.eyetide.com (209.133.65.209.above.net [209.133.65.209] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MGQm3a009847 for ; Wed, 22 Sep 2004 09:26:48 -0700 Received: from localhost (localhost [127.0.0.1]) by tetris.eyetide.com (Postfix) with ESMTP id 3408494A8F; Wed, 22 Sep 2004 09:26:32 -0700 (PDT) Received: from tetris.eyetide.com ([127.0.0.1]) by localhost (tetris.eyetide.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 59000-02; Wed, 22 Sep 2004 09:26:31 -0700 (PDT) Received: from leaf.lumiere.net (unknown [209.133.65.222]) by tetris.eyetide.com (Postfix) with ESMTP id D9E3993165; Wed, 22 Sep 2004 09:26:30 -0700 (PDT) Received: by leaf.lumiere.net (Postfix, from userid 1000) id 55FE8CE8A; Wed, 22 Sep 2004 09:26:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leaf.lumiere.net (Postfix) with ESMTP id 541E33ADA; Wed, 22 Sep 2004 09:26:30 -0700 (PDT) Date: Wed, 22 Sep 2004 09:26:30 -0700 (PDT) From: Jesse To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Fw: [Bug 3419] New: kernel BUG at net/ipv4/fib_semantics.c:1039! In-Reply-To: <20040922092319.4ba5b8fb@dell_ss3.pdx.osdl.net> Message-ID: <20040922092520.U41787@leaf.lumiere.net> References: <20040922092319.4ba5b8fb@dell_ss3.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at eyetide.com X-archive-position: 9294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: j@lumiere.net Precedence: bulk X-list: netdev Content-Length: 3952 Lines: 102 Hi Stephen, I haven't had a chance to try a new snapshot version yet. I will try one later today and report back. On Wed, 22 Sep 2004, Stephen Hemminger wrote: > Is this fixed with the more recent version of 2.6.9? > Dave Miller fixed up several initialization bugs from his earlier > change. > > Begin forwarded message: > > Date: Sat, 18 Sep 2004 03:21:09 -0700 > From: bugme-daemon@osdl.org > To: shemminger@osdl.org > Subject: [Bug 3419] New: kernel BUG at net/ipv4/fib_semantics.c:1039! > > > http://bugme.osdl.org/show_bug.cgi?id=3419 > > Summary: kernel BUG at net/ipv4/fib_semantics.c:1039! > Kernel Version: 2.6.9-rc2-bk3 > Status: NEW > Severity: normal > Owner: shemminger@osdl.org > Submitter: j@lumiere.net > > > Distribution: Fedora Core 2 (i686) > Hardware Environment: > P4 3.2GHz 1MB cache, SuperMicro P4SCT+, 1 GB ECC RAM (2 x 512), 4 x SATA HD. > Onboard components include two gigabit ethernet controllers, LAN1/eth0 in use > (100Mbps, e1000). LAN1: Intel 82547GI (uses CSA), LAN2: (82541GI). Hance Rapids > (6300ESB) ICH, Marvell 88SX5041 SATA controller. > > Software Environment: > Fedora Core 2, updated to latest standard updates. Vanilla 2.6.9-rc2-bk3 kernel. > > Problem Description: > During kudzu running on bootup, kernel BUG at net/ipv4/fib_semantics.c:1039! > occurs. Boot continues until "Bringing up loopback interface:" at which point it > gets stuck. Can still scroll up/down. Does NOT occur on 2.6.9-rc2. > > Steps to reproduce: > Boot with 2.6.9-rc2-bk3 kernel and wait for 'Checking for new hardware'. > > Here's output... possibly with a few typos, as it's copied by hand. > Checking for new hardware-------------[ cut here ]-------------- > kernel BUG at net/ipv4/fib_semantics.c:1039! > invalid operand: 0000 [#1] > SMP > Modules linked in: e1000 floppy sg microcode uhci_hcd ehci_hcd button battery > asus_acpi ac ext3 jbd dm_mod ata_piix libata sd_mod linuxIAL scsi_mod raid5 xor > raid1 > CPU: 1 > EIP: 0060:[] Tainted: P VLI > EFLAGS: 00010246 (2.6.9-rc2-bk3-leaf) > EIP is at fib_sync_down+0x197/0x1a4 > eax: ffffffff ebx: 00000000 ecx: 00000002 edx: f7395000 > esi: 00000000 edi: 00000006 ebp: f6395028 esp: f640dea8 > ds: 007b es: 007b ss: 0068 > Process modprobe (pid: 924, threadinfo=f640d000 task=f7c38550) > Stack: 00000282 c0104fd0 ffffffff 00000000 00000002 f6395000 f6395000 f6395000 > 00000006 f6395028 c02bcb35 c03455fc c02bcc14 c03455fc f6395000 c012ac76 > f6395000 f6395000 c0339da8 c027bf23 00000000 c016c13a c014adda 00000292 > Call Trace: > []__down_trylock+0x3e/0x62 > [] fib_disable_ip+0xe/0x28 > [] fib_netdev_event+0x72/0x7e > [] notifier_call_chain+0x17/0x2b > [] unregister_netdevice+0x137/0x249 > [] wake_up_inode+0xc/0x3b > [] clear_inode+0x8/0xe2 > [] unregister_netdev+0xf/0x15 > [] e1000_remove+0x4c/0x7e [e1000] > [] pci_device_remove+0x28/0x2a > [] device_release_driver+0x56/0x58 > [] driver_detach+0x16/0x21 > [] bus_remove_driver+0x43/0x74 > [] driver_unregister+0x8/0x19 > [] pci_unregister_driver+0xb/0x13 > [] sys_delete_module+0x121/0x150 > [] unmap_vma_list+0xe/0x17 > [] do_munmap+0x11c/0x15f > [] do_page_fault+0x0/0x54b > [] sysenter_past_esp+0x52/0x71 > Code: e8 5b t1 01 00 83 04 24 01 8b 4f 5c eb 89 0f 0b 2a 04 1c b9 30 c0 e9 3a ff > ff ff 83 48 1c 01 83 44 24 0c 01 8b 11 e9 dd fe ff ff <0f> 0b 0f 04 1c b9 30 c0 > e9 9b fe ff ff 55 57 56 53 83 ec 10 89 > [ OK ] > Updating /etc/fstab [ OK ] > Setting network parameters: [ OK ] > Bringing up loopback interface: > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > --- Jesse From shemminger@osdl.org Wed Sep 22 09:27:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 09:27:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MGRnWK010171 for ; Wed, 22 Sep 2004 09:27:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MGRDv32379; Wed, 22 Sep 2004 09:27:14 -0700 Date: Wed, 22 Sep 2004 09:27:13 -0700 From: Stephen Hemminger To: per.sil@gmx.it, john.ronciak@intel.com, ganesh.venkatesan@intel.com, scott.feldman@intel.com Cc: netdev@oss.sgi.com Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Message-Id: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net> In-Reply-To: <200409211642.i8LGg6Uq012224@fire-1.osdl.org> References: <200409211642.i8LGg6Uq012224@fire-1.osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4945 Lines: 131 This is an ethernet driver related problem. Which of the ethernet cars (PCNet32 or E100) is assigned to eth0? And which of the two e100 drivers (e100 or eepro100) are you using? On Tue, 21 Sep 2004 09:42:06 -0700 bugme-daemon@osdl.org wrote: > http://bugme.osdl.org/show_bug.cgi?id=3440 > > Summary: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out > " > Kernel Version: 2.6.8.1 > Status: NEW > Severity: high > Owner: shemminger@osdl.org > Submitter: per.sil@gmx.it > > > Hi kernel developers, > > There exists a severe problem with a linux box of my own. The problem does not > occur when using kernel 2.4.25 on the same machine. I need your help. > > Distribution: > ------------- > Gentoo Linux 1.4 (2004.2), recompiled whole system with kernel 2.6 and NPTL. > > Hardware Environment: > --------------------- > - IBM PC Server 325, Dual Pentium Pro 180MHz, 256MB RAM, > - 3ware Controller 6410 with RAID 1+0, > - PCNet32 10MBit on-board card > - Intel EtherExpress Pro 100 > - RTL 8139 Card. > - 2x AVM ISDN B1 active ISA cards (Rev. 2.0 and Rev. 3.0 cards) > > Tried with both cards, and tried both manually set to half-duplex or > full-duplex. tried same kernel with ISDN cards removed (but modules still > compiled in) > > I removed one processor using same SMP-enabled kernel on single processor system > - problem persists. > > The box is connected to a DLink DGS-1008D GigaBit switch and I tried with a > D-Link DES 1026G switch. > > > The source of the transfer is a HP Netserver Dual Pentium III 600MHz with kernel > 2.4.23_pre8 SMP and same openSSH version, connected to the same switch. > > > Software Environment: > --------------------- > "vanilla" kernel 2.6.8.1 on Gentoo Linux (see dmesg output and config file) > IPv6 compiled in but deactivated with > ifconfig eth1 inet6 del ... > > same problem with kernel 2.6.7 and 2.6.8 using same kernel configuration. > > gcc-3.3.4 > glibc-2.3.4.20040808 > OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 > > (for installed system utils, see attached file) > > Problem Description: > --------------------- > > When transfering some data (approx. 3 GB in size) from one amchine on the LAN to > this box the transmission hangs on the interface after some seconds (20MBs) and > a "time out" occures. Then the LAN connection freezes, is terminated and the > linux box is not reachable from the network anymore. After some minutes the > connection recoveres again. > > The network transmission times out and the ethernet driver is not responding to > any LAN traffic (not even to any ICMP echo request). kernel log message tells: > > NETDEV WATCHDOG: eth0: transmit timed out > eth0: Tx descriptor 0 is 0008a072. > > (off course: address of descriptor varies) > After approx. 4 minutes, the LAN connection of the box recovers and you can > connect to the box again. (until next transfer is started) > > transfer issued by another host: > ................................ > Usually a transfer host consumes all interface bandwidth available (100 MBit LAN > with full-duplex cards on both involved machines gives at least 1.6 MByte/s if > SCP overhead is taken into consideration). the connection stays alive if it > limited to smaller bandwith with fe. 100 Kbit (~ 12.5 KBytes) "scp -l 100 ...". > But using 1000 KBit (~125 KByte) "scp -l 1000 ..." the connection is freezing > although maximum bandwidth is not reached. > > transfer issued by host itself: > ................................ > If the box issues a transfer from the internet using 235 KBytes/s (~ 2MBits/s) > everything works out fine. If the box issues the transfer from the LAN with full > bandwith of 1.8 MBytes/s then the LAN connection is freezing too. > > > If I turn of window scaling with "echo 0 > > /proc/sys/net/ipv4/tcp_window_scaling" then the time needed to recover the > interface seems to decrease. The SCP transfer still freezes but LAN timeout of > the box is small enough to keep SSH connection alive. > > it did not help to set the following, as suggested by other web pages: > tcp_default_win_scale=0 > tcp_moderate_rcvbuf=0 > > > Steps to reproduce: > ------------------- > start any SCP/SFTP transfer to the linux box with kernel 2.6.8.1 - always > reproducable on my box. I do not know about others since this is my first box > with kernel 2.6.x > > > > If you need more information or testing, please let me know. I will not change > the configuration of the box for some time to be able to fullfill your requests, > hoping to help solving the problem. > > > Yours > Perolo > > PS: Dear maintainer, I am able to grant you access to the computer if this will > help you. please contact me if this is vital for solving the problem. > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. From elueck@de.ibm.com Wed Sep 22 09:32:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 09:32:42 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.29.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MGWYcd010598 for ; Wed, 22 Sep 2004 09:32:35 -0700 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8MGWHfQ151608; Wed, 22 Sep 2004 16:32:17 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MGWG3V210690; Wed, 22 Sep 2004 18:32:17 +0200 Message-ID: <4151A8E5.6060600@de.ibm.com> Date: Wed, 22 Sep 2004 18:31:33 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [RFC][PATCH 1/2] ipv4 multipath routing, bk head Content-Type: multipart/mixed; boundary="------------000606070709040205050506" X-archive-position: 9296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 19084 Lines: 697 This is a multi-part message in MIME format. --------------000606070709040205050506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We propose the attached and the subsequent patch for an extension of the existing multipath capabilities. These patches are partly extended versions of patches posted last week as RFC. (Please refer to the corresponding mails for details about their purpose). There are the following changes and additions for which we hope you have comments on: * a _weighted_ random routing policiy utilizing the weights configurable via "ip route" that allows to approximate many other policies (e.g. round robin) * a routing policy choosing routes with equal probability without any state maintenance overhead(=> low delay) * a simple round robin policy * the extended behaviour is only optionally compiled in to allow for the utilization of the old behaviour (as David Miller denoted: there are scenarios/setups in which the old behaviour is more desirable than the new behaviour) * the ip_route_input lookup function does not consider more than one alternative, only ip_route_output_key does (as Jamal denoted: our extension makes primarily sense if one routes on a per connection basis as we do in ip_route_output_key and not on a per "packet" basis as we do in the ip forwarding case) * an interface round robin policy that selects among relevant routes in a way that tries to ensure an overall round robin among the available _interfaces_ is achieved. In addition to any opinions about the above mentioned changes we would be very glad about any comments on the following issue: Is it desirable to introduce modules for the policy implementations? We think the weighted random policy is the most relevant one in this context as it allows for the rough emulation of all other policies and considers the weights configured via "ip route". Anyway, the other policies are more efficient than their emulated counterparts. Up to now, as we are not sure, wether more policies than weighted random are desired, one has to decide via kernel configuration, which implementation should be utilized. Further remarks on the organisation of the patch: * the patch attached to this mail splits up ip_route_(input|output)_slow (identical to the one posted last week as it still fits to bitkeeper head) * the patch following in the subsequent mail encompasses the changes mentioned above on the basis of the splitting patch Regards, Einar --------------000606070709040205050506 Content-Type: text/x-patch; name="routingsplit.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="routingsplit.diff" diff -ruN linux-2.6.8.1/net/ipv4/route.c linux-2.6.8.1.split/net/ipv4/route.c --- linux-2.6.8.1/net/ipv4/route.c 2004-09-10 10:24:12.000000000 +0200 +++ linux-2.6.8.1.split/net/ipv4/route.c 2004-09-14 09:38:49.000000000 +0200 @@ -104,6 +104,9 @@ #include #endif +#define RT_FL_TOS(oldflp) \ + ((u32)(oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK))) + #define IP_MAX_MTU 0xFFF0 #define RT_GC_TIMEOUT (300*HZ) @@ -143,6 +146,7 @@ static void ipv4_link_failure(struct sk_buff *skb); static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu); static int rt_garbage_collect(void); +static inline int compare_keys(struct flowi *fl1, struct flowi *fl2); static struct dst_ops ipv4_dst_ops = { @@ -1528,6 +1532,169 @@ return -EINVAL; } + +static void ip_handle_martian_source(struct net_device *dev, + struct in_device *in_dev, + struct sk_buff *skb, + u32 daddr, + u32 saddr) +{ + RT_CACHE_STAT_INC(in_martian_src); +#ifdef CONFIG_IP_ROUTE_VERBOSE + if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { + /* + * RFC1812 recommendation, if source is martian, + * the only hint is MAC header. + */ + printk(KERN_WARNING "martian source %u.%u.%u.%u from " + "%u.%u.%u.%u, on dev %s\n", + NIPQUAD(daddr), NIPQUAD(saddr), dev->name); + if (dev->hard_header_len) { + int i; + unsigned char *p = skb->mac.raw; + printk(KERN_WARNING "ll header: "); + for (i = 0; i < dev->hard_header_len; i++, p++) { + printk("%02x", *p); + if (i < (dev->hard_header_len - 1)) + printk(":"); + } + printk("\n"); + } + } +#endif +} + +static inline int __mkroute_input(struct sk_buff *skb, + struct fib_result* res, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos, + struct rtable **result) +{ + + struct rtable *rth; + int err; + struct in_device *out_dev; + unsigned flags = 0; + u32 spec_dst, itag; + + /* get a working reference to the output device */ + out_dev = in_dev_get(FIB_RES_DEV(*res)); + if (out_dev == NULL) { + if (net_ratelimit()) + printk(KERN_CRIT "Bug in ip_route_input" \ + "_slow(). Please, report\n"); + return -EINVAL; + } + + + err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(*res), + in_dev->dev, &spec_dst, &itag); + if (err < 0) { + ip_handle_martian_source(in_dev->dev, in_dev, skb, daddr, + saddr); + + err = -EINVAL; + goto cleanup; + } + + if (err) + flags |= RTCF_DIRECTSRC; + + if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && + (IN_DEV_SHARED_MEDIA(out_dev) || + inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) + flags |= RTCF_DOREDIRECT; + + if (skb->protocol != htons(ETH_P_IP)) { + /* Not IP (i.e. ARP). Do not create route, if it is + * invalid for proxy arp. DNAT routes are always valid. + */ + if (out_dev == in_dev && !(flags & RTCF_DNAT)) { + err = -EINVAL; + goto cleanup; + } + } + + + rth = dst_alloc(&ipv4_dst_ops); + if (!rth) { + err = -ENOBUFS; + goto cleanup; + } + + rth->u.dst.flags= DST_HOST; + if (in_dev->cnf.no_policy) + rth->u.dst.flags |= DST_NOPOLICY; + if (in_dev->cnf.no_xfrm) + rth->u.dst.flags |= DST_NOXFRM; + rth->fl.fl4_dst = daddr; + rth->rt_dst = daddr; + rth->fl.fl4_tos = tos; +#ifdef CONFIG_IP_ROUTE_FWMARK + rth->fl.fl4_fwmark= skb->nfmark; +#endif + rth->fl.fl4_src = saddr; + rth->rt_src = saddr; + rth->rt_gateway = daddr; + rth->rt_iif = + rth->fl.iif = in_dev->dev->ifindex; + rth->u.dst.dev = (out_dev)->dev; + dev_hold(rth->u.dst.dev); + rth->idev = in_dev_get(rth->u.dst.dev); + rth->fl.oif = 0; + rth->rt_spec_dst= spec_dst; + + rth->u.dst.input = ip_forward; + rth->u.dst.output = ip_output; + + rt_set_nexthop(rth, res, itag); + + rth->rt_flags = flags; + + *result = rth; + err = 0; + cleanup: + /* release the working reference to the output device */ + in_dev_put(out_dev); + return err; +} + +static inline int ip_mkroute_input_def(struct sk_buff *skb, + struct fib_result* res, + const struct flowi *fl, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos) +{ + struct rtable* rth; + int err; + unsigned hash; + +#ifdef CONFIG_IP_ROUTE_MULTIPATH + if (res->fi->fib_nhs > 1 && fl->oif == 0) + fib_select_multipath(fl, res); +#endif + + /* create a routing cache entry */ + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, &rth ); + if ( err ) + return err; + atomic_set(&rth->u.dst.__refcnt, 1); + + /* put it into the cache */ + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); + return rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); +} + +static inline int ip_mkroute_input(struct sk_buff *skb, + struct fib_result* res, + const struct flowi *fl, + struct in_device *in_dev, + u32 daddr, u32 saddr, u32 tos) +{ + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); +} + + /* * NOTE. We drop all the packets that has local source * addresses, because every properly looped back packet @@ -1539,11 +1706,10 @@ */ static int ip_route_input_slow(struct sk_buff *skb, u32 daddr, u32 saddr, - u8 tos, struct net_device *dev) + u8 tos, struct net_device *dev) { struct fib_result res; struct in_device *in_dev = in_dev_get(dev); - struct in_device *out_dev = NULL; struct flowi fl = { .nl_u = { .ip4_u = { .daddr = daddr, .saddr = saddr, @@ -1567,8 +1733,6 @@ if (!in_dev) goto out; - hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); - /* Check for the most weird martians, which can be not detected by fib_lookup. */ @@ -1621,79 +1785,14 @@ if (res.type != RTN_UNICAST) goto martian_destination; -#ifdef CONFIG_IP_ROUTE_MULTIPATH - if (res.fi->fib_nhs > 1 && fl.oif == 0) - fib_select_multipath(&fl, &res); -#endif - out_dev = in_dev_get(FIB_RES_DEV(res)); - if (out_dev == NULL) { - if (net_ratelimit()) - printk(KERN_CRIT "Bug in ip_route_input_slow(). " - "Please, report\n"); - goto e_inval; - } - - err = fib_validate_source(saddr, daddr, tos, FIB_RES_OIF(res), dev, - &spec_dst, &itag); - if (err < 0) - goto martian_source; - - if (err) - flags |= RTCF_DIRECTSRC; - - if (out_dev == in_dev && err && !(flags & (RTCF_NAT | RTCF_MASQ)) && - (IN_DEV_SHARED_MEDIA(out_dev) || - inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res)))) - flags |= RTCF_DOREDIRECT; - - if (skb->protocol != htons(ETH_P_IP)) { - /* Not IP (i.e. ARP). Do not create route, if it is - * invalid for proxy arp. DNAT routes are always valid. - */ - if (out_dev == in_dev && !(flags & RTCF_DNAT)) - goto e_inval; - } - - rth = dst_alloc(&ipv4_dst_ops); - if (!rth) + err = ip_mkroute_input(skb, &res, &fl, in_dev, daddr, saddr, tos); + if ( err == -ENOBUFS ) goto e_nobufs; - - atomic_set(&rth->u.dst.__refcnt, 1); - rth->u.dst.flags= DST_HOST; - if (in_dev->cnf.no_policy) - rth->u.dst.flags |= DST_NOPOLICY; - if (in_dev->cnf.no_xfrm) - rth->u.dst.flags |= DST_NOXFRM; - rth->fl.fl4_dst = daddr; - rth->rt_dst = daddr; - rth->fl.fl4_tos = tos; -#ifdef CONFIG_IP_ROUTE_FWMARK - rth->fl.fl4_fwmark= skb->nfmark; -#endif - rth->fl.fl4_src = saddr; - rth->rt_src = saddr; - rth->rt_gateway = daddr; - rth->rt_iif = - rth->fl.iif = dev->ifindex; - rth->u.dst.dev = out_dev->dev; - dev_hold(rth->u.dst.dev); - rth->idev = in_dev_get(rth->u.dst.dev); - rth->fl.oif = 0; - rth->rt_spec_dst= spec_dst; - - rth->u.dst.input = ip_forward; - rth->u.dst.output = ip_output; - - rt_set_nexthop(rth, &res, itag); - - rth->rt_flags = flags; - -intern: - err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + if ( err == -EINVAL ) + goto e_inval; + done: in_dev_put(in_dev); - if (out_dev) - in_dev_put(out_dev); if (free_res) fib_res_put(&res); out: return err; @@ -1753,7 +1852,9 @@ rth->rt_flags &= ~RTCF_LOCAL; } rth->rt_type = res.type; - goto intern; + hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + goto done; no_route: RT_CACHE_STAT_INC(in_no_route); @@ -1781,30 +1882,7 @@ goto done; martian_source: - - RT_CACHE_STAT_INC(in_martian_src); -#ifdef CONFIG_IP_ROUTE_VERBOSE - if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { - /* - * RFC1812 recommendation, if source is martian, - * the only hint is MAC header. - */ - printk(KERN_WARNING "martian source %u.%u.%u.%u from " - "%u.%u.%u.%u, on dev %s\n", - NIPQUAD(daddr), NIPQUAD(saddr), dev->name); - if (dev->hard_header_len) { - int i; - unsigned char *p = skb->mac.raw; - printk(KERN_WARNING "ll header: "); - for (i = 0; i < dev->hard_header_len; i++, p++) { - printk("%02x", *p); - if (i < (dev->hard_header_len - 1)) - printk(":"); - } - printk("\n"); - } - } -#endif + ip_handle_martian_source(dev, in_dev, skb, daddr, saddr); goto e_inval; } @@ -1875,13 +1953,166 @@ return ip_route_input_slow(skb, daddr, saddr, tos, dev); } +static inline int __mkroute_output(struct rtable **result, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + struct rtable *rth; + struct in_device *in_dev; + u32 tos = RT_FL_TOS(oldflp); + int err = 0; + + if (LOOPBACK(fl->fl4_src) && !(dev_out->flags&IFF_LOOPBACK)) + return -EINVAL; + + if (fl->fl4_dst == 0xFFFFFFFF) + res->type = RTN_BROADCAST; + else if (MULTICAST(fl->fl4_dst)) + res->type = RTN_MULTICAST; + else if (BADCLASS(fl->fl4_dst) || ZERONET(fl->fl4_dst)) + return -EINVAL; + + if (dev_out->flags & IFF_LOOPBACK) + flags |= RTCF_LOCAL; + + /* get work reference to inet device */ + in_dev = in_dev_get(dev_out); + if (!in_dev) + return -EINVAL; + + if (res->type == RTN_BROADCAST) { + flags |= RTCF_BROADCAST | RTCF_LOCAL; + if (res->fi) { + fib_info_put(res->fi); + res->fi = NULL; + } + } else if (res->type == RTN_MULTICAST) { + flags |= RTCF_MULTICAST|RTCF_LOCAL; + if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src, + oldflp->proto)) + flags &= ~RTCF_LOCAL; + /* If multicast route do not exist use + default one, but do not gateway in this case. + Yes, it is hack. + */ + if (res->fi && res->prefixlen < 4) { + fib_info_put(res->fi); + res->fi = NULL; + } + } + + + rth = dst_alloc(&ipv4_dst_ops); + if (!rth) { + err = -ENOBUFS; + goto cleanup; + } + + rth->u.dst.flags= DST_HOST; + if (in_dev->cnf.no_xfrm) + rth->u.dst.flags |= DST_NOXFRM; + if (in_dev->cnf.no_policy) + rth->u.dst.flags |= DST_NOPOLICY; + + rth->fl.fl4_dst = oldflp->fl4_dst; + rth->fl.fl4_tos = tos; + rth->fl.fl4_src = oldflp->fl4_src; + rth->fl.oif = oldflp->oif; +#ifdef CONFIG_IP_ROUTE_FWMARK + rth->fl.fl4_fwmark= oldflp->fl4_fwmark; +#endif + rth->rt_dst = fl->fl4_dst; + rth->rt_src = fl->fl4_src; + rth->rt_iif = oldflp->oif ? : dev_out->ifindex; + /* get references to the devices that are to be hold by the routing + cache entry */ + rth->u.dst.dev = dev_out; + dev_hold(dev_out); + rth->idev = in_dev_get(dev_out); + rth->rt_gateway = fl->fl4_dst; + rth->rt_spec_dst= fl->fl4_src; + + rth->u.dst.output=ip_output; + + RT_CACHE_STAT_INC(out_slow_tot); + + if (flags & RTCF_LOCAL) { + rth->u.dst.input = ip_local_deliver; + rth->rt_spec_dst = fl->fl4_dst; + } + if (flags & (RTCF_BROADCAST | RTCF_MULTICAST)) { + rth->rt_spec_dst = fl->fl4_src; + if (flags & RTCF_LOCAL && + !(dev_out->flags & IFF_LOOPBACK)) { + rth->u.dst.output = ip_mc_output; + RT_CACHE_STAT_INC(out_slow_mc); + } +#ifdef CONFIG_IP_MROUTE + if (res->type == RTN_MULTICAST) { + if (IN_DEV_MFORWARD(in_dev) && + !LOCAL_MCAST(oldflp->fl4_dst)) { + rth->u.dst.input = ip_mr_input; + rth->u.dst.output = ip_mc_output; + } + } +#endif + } + + rt_set_nexthop(rth, res, 0); + + rth->rt_flags = flags; + + *result = rth; + cleanup: + /* release work reference to inet device */ + in_dev_put(in_dev); + + return err; +} + +static inline int ip_mkroute_output_def(struct rtable **rp, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + struct rtable *rth; + int err = __mkroute_output(&rth, res, fl, oldflp, dev_out, flags); + unsigned hash; + if ( err == 0 ) { + u32 tos = RT_FL_TOS(oldflp); + + atomic_set(&rth->u.dst.__refcnt, 1); + + hash = rt_hash_code(oldflp->fl4_dst, + oldflp->fl4_src ^ (oldflp->oif << 5), tos); + err = rt_intern_hash(hash, rth, rp); + } + + return err; +} + +static inline int ip_mkroute_output(struct rtable** rp, + struct fib_result* res, + const struct flowi *fl, + const struct flowi *oldflp, + struct net_device *dev_out, + unsigned flags) +{ + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); +} + /* * Major route resolver routine. */ static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp) { - u32 tos = oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK); + u32 tos = RT_FL_TOS(oldflp); struct flowi fl = { .nl_u = { .ip4_u = { .daddr = oldflp->fl4_dst, .saddr = oldflp->fl4_src, @@ -1897,10 +2128,7 @@ .oif = oldflp->oif }; struct fib_result res; unsigned flags = 0; - struct rtable *rth; struct net_device *dev_out = NULL; - struct in_device *in_dev = NULL; - unsigned hash; int free_res = 0; int err; @@ -2060,116 +2288,13 @@ fl.oif = dev_out->ifindex; make_route: - if (LOOPBACK(fl.fl4_src) && !(dev_out->flags&IFF_LOOPBACK)) - goto e_inval; + err = ip_mkroute_output(rp, &res, &fl, oldflp, dev_out, flags); - if (fl.fl4_dst == 0xFFFFFFFF) - res.type = RTN_BROADCAST; - else if (MULTICAST(fl.fl4_dst)) - res.type = RTN_MULTICAST; - else if (BADCLASS(fl.fl4_dst) || ZERONET(fl.fl4_dst)) - goto e_inval; - - if (dev_out->flags & IFF_LOOPBACK) - flags |= RTCF_LOCAL; - - in_dev = in_dev_get(dev_out); - if (!in_dev) - goto e_inval; - - if (res.type == RTN_BROADCAST) { - flags |= RTCF_BROADCAST | RTCF_LOCAL; - if (res.fi) { - fib_info_put(res.fi); - res.fi = NULL; - } - } else if (res.type == RTN_MULTICAST) { - flags |= RTCF_MULTICAST|RTCF_LOCAL; - if (!ip_check_mc(in_dev, oldflp->fl4_dst, oldflp->fl4_src, oldflp->proto)) - flags &= ~RTCF_LOCAL; - /* If multicast route do not exist use - default one, but do not gateway in this case. - Yes, it is hack. - */ - if (res.fi && res.prefixlen < 4) { - fib_info_put(res.fi); - res.fi = NULL; - } - } - - rth = dst_alloc(&ipv4_dst_ops); - if (!rth) - goto e_nobufs; - - atomic_set(&rth->u.dst.__refcnt, 1); - rth->u.dst.flags= DST_HOST; - if (in_dev->cnf.no_xfrm) - rth->u.dst.flags |= DST_NOXFRM; - if (in_dev->cnf.no_policy) - rth->u.dst.flags |= DST_NOPOLICY; - rth->fl.fl4_dst = oldflp->fl4_dst; - rth->fl.fl4_tos = tos; - rth->fl.fl4_src = oldflp->fl4_src; - rth->fl.oif = oldflp->oif; -#ifdef CONFIG_IP_ROUTE_FWMARK - rth->fl.fl4_fwmark= oldflp->fl4_fwmark; -#endif - rth->rt_dst = fl.fl4_dst; - rth->rt_src = fl.fl4_src; - rth->rt_iif = oldflp->oif ? : dev_out->ifindex; - rth->u.dst.dev = dev_out; - dev_hold(dev_out); - rth->idev = in_dev_get(dev_out); - rth->rt_gateway = fl.fl4_dst; - rth->rt_spec_dst= fl.fl4_src; - - rth->u.dst.output=ip_output; - - RT_CACHE_STAT_INC(out_slow_tot); - - if (flags & RTCF_LOCAL) { - rth->u.dst.input = ip_local_deliver; - rth->rt_spec_dst = fl.fl4_dst; - } - if (flags & (RTCF_BROADCAST | RTCF_MULTICAST)) { - rth->rt_spec_dst = fl.fl4_src; - if (flags & RTCF_LOCAL && !(dev_out->flags & IFF_LOOPBACK)) { - rth->u.dst.output = ip_mc_output; - RT_CACHE_STAT_INC(out_slow_mc); - } -#ifdef CONFIG_IP_MROUTE - if (res.type == RTN_MULTICAST) { - if (IN_DEV_MFORWARD(in_dev) && - !LOCAL_MCAST(oldflp->fl4_dst)) { - rth->u.dst.input = ip_mr_input; - rth->u.dst.output = ip_mc_output; - } - } -#endif - } - - rt_set_nexthop(rth, &res, 0); - - - rth->rt_flags = flags; - - hash = rt_hash_code(oldflp->fl4_dst, oldflp->fl4_src ^ (oldflp->oif << 5), tos); - err = rt_intern_hash(hash, rth, rp); -done: if (free_res) fib_res_put(&res); if (dev_out) dev_put(dev_out); - if (in_dev) - in_dev_put(in_dev); out: return err; - -e_inval: - err = -EINVAL; - goto done; -e_nobufs: - err = -ENOBUFS; - goto done; } int __ip_route_output_key(struct rtable **rp, const struct flowi *flp) --------------000606070709040205050506-- From elueck@de.ibm.com Wed Sep 22 09:32:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 09:32:51 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MGWerV010603 for ; Wed, 22 Sep 2004 09:32:41 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8MGWMLi137008; Wed, 22 Sep 2004 16:32:22 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MGWMZg081518; Wed, 22 Sep 2004 18:32:22 +0200 Message-ID: <4151A8EB.80408@de.ibm.com> Date: Wed, 22 Sep 2004 18:31:39 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [RFC][PATCH 2/2] ipv4 multipath routing, bk head Content-Type: multipart/mixed; boundary="------------080000050907000406020006" X-archive-position: 9297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 42075 Lines: 1511 This is a multi-part message in MIME format. --------------080000050907000406020006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The intention of this patch is described in detail in the previous mail. Regards Einar. --------------080000050907000406020006 Content-Type: text/x-patch; name="multipath_cached.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="multipath_cached.diff" diff -ruN linux-2.6.8.1.split/include/net/dst.h linux-2.6.8.1.multipath/include/net/dst.h --- linux-2.6.8.1.split/include/net/dst.h 2004-09-22 10:01:01.000000000 +0200 +++ linux-2.6.8.1.multipath/include/net/dst.h 2004-09-22 14:18:40.000000000 +0200 @@ -48,6 +48,7 @@ #define DST_NOXFRM 2 #define DST_NOPOLICY 4 #define DST_NOHASH 8 +#define DST_BALANCED 0x10 unsigned long lastuse; unsigned long expires; diff -ruN linux-2.6.8.1.split/include/net/flow.h linux-2.6.8.1.multipath/include/net/flow.h --- linux-2.6.8.1.split/include/net/flow.h 2004-09-22 10:01:01.000000000 +0200 +++ linux-2.6.8.1.multipath/include/net/flow.h 2004-09-22 14:19:31.000000000 +0200 @@ -51,6 +51,7 @@ __u8 proto; __u8 flags; +#define FLOWI_FLAG_MULTIPATHOLDROUTE 0x01 union { struct { __u16 sport; diff -ruN linux-2.6.8.1.split/include/net/ip_fib.h linux-2.6.8.1.multipath/include/net/ip_fib.h --- linux-2.6.8.1.split/include/net/ip_fib.h 2004-09-22 10:01:01.000000000 +0200 +++ linux-2.6.8.1.multipath/include/net/ip_fib.h 2004-09-22 14:18:08.000000000 +0200 @@ -95,6 +95,10 @@ unsigned char nh_sel; unsigned char type; unsigned char scope; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM + __u32 network; + __u32 netmask; +#endif struct fib_info *fi; #ifdef CONFIG_IP_MULTIPLE_TABLES struct fib_rule *r; @@ -119,6 +123,14 @@ #define FIB_RES_DEV(res) (FIB_RES_NH(res).nh_dev) #define FIB_RES_OIF(res) (FIB_RES_NH(res).nh_oif) +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM +#define FIB_RES_NETWORK(res) ((res).network) +#define FIB_RES_NETMASK(res) ((res).netmask) +#else /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ +#define FIB_RES_NETWORK(res) (0) +#define FIB_RES_NETMASK(res) (0) +#endif /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ + struct fib_table { unsigned char tb_id; unsigned tb_stamp; diff -ruN linux-2.6.8.1.split/include/net/route.h linux-2.6.8.1.multipath/include/net/route.h --- linux-2.6.8.1.split/include/net/route.h 2004-09-22 10:01:01.000000000 +0200 +++ linux-2.6.8.1.multipath/include/net/route.h 2004-09-22 15:00:29.000000000 +0200 @@ -46,6 +46,7 @@ #define RT_CONN_FLAGS(sk) (RT_TOS(inet_sk(sk)->tos) | sk->sk_localroute) +struct fib_nh; struct inet_peer; struct rtable { @@ -179,6 +180,9 @@ memcpy(&fl, &(*rp)->fl, sizeof(fl)); fl.fl_ip_sport = sport; fl.fl_ip_dport = dport; +#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) + fl.flags |= FLOWI_FLAG_MULTIPATHOLDROUTE; +#endif ip_rt_put(*rp); *rp = NULL; return ip_route_output_flow(rp, &fl, sk, 0); @@ -197,4 +201,69 @@ return rt->peer; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM +extern void __multipath_flush(void); +static inline void multipath_flush(void) { + __multipath_flush(); +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ +static inline void multipath_flush(void){} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ + +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM +extern void __multipath_set_nhinfo(__u32 network, + __u32 netmask, + unsigned char prefixlen, + const struct fib_nh* nh); +static inline void multipath_set_nhinfo(__u32 network, + __u32 netmask, + unsigned char prefixlen, + const struct fib_nh* nh) { + __multipath_set_nhinfo(network, netmask, prefixlen, nh); +} +#else +static inline void multipath_set_nhinfo(__u32 network, + __u32 netmask, + unsigned char prefixlen, + const struct fib_nh* nh) { +} +#endif + + + +#if defined(CONFIG_IP_ROUTE_MULTIPATH_RR) || defined(CONFIG_IP_ROUTE_MULTIPATH_DRR) +extern void __multipath_remove(struct rtable *rt); +static inline void multipath_remove(struct rtable *rt) { + if ( rt->u.dst.flags & DST_BALANCED ) { + __multipath_remove( rt ); + } +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_RR || CONFIG_IP_ROUTE_MULTIPATH_DRR */ +static inline void multipath_remove(struct rtable *rt) {} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_RR || CONFIG_IP_ROUTE_MULTIPATH_DRR */ + + +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED +extern void __multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp); +static inline int multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp) { + if ( rth->u.dst.flags & DST_BALANCED ) { + __multipath_selectroute( flp, rth, rp ); + return 1; + } + else { + return 0; + } +} +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ +static inline int multipath_selectroute(const struct flowi *flp, + struct rtable *rth, + struct rtable **rp) { + return 0; +} +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ + #endif /* _ROUTE_H */ diff -ruN linux-2.6.8.1.split/net/ipv4/fib_hash.c linux-2.6.8.1.multipath/net/ipv4/fib_hash.c --- linux-2.6.8.1.split/net/ipv4/fib_hash.c 2004-09-22 10:01:21.000000000 +0200 +++ linux-2.6.8.1.multipath/net/ipv4/fib_hash.c 2004-09-22 15:01:49.000000000 +0200 @@ -292,6 +292,11 @@ res->type = f->fn_type; res->scope = f->fn_scope; res->prefixlen = fz->fz_order; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM + res->netmask = fz->fz_mask; + res->network = f->fn_key & + (0xFFFFFFFF >> (32 - fz->fz_order)); +#endif goto out; } if (err < 0) diff -ruN linux-2.6.8.1.split/net/ipv4/Kconfig linux-2.6.8.1.multipath/net/ipv4/Kconfig --- linux-2.6.8.1.split/net/ipv4/Kconfig 2004-09-22 10:01:21.000000000 +0200 +++ linux-2.6.8.1.multipath/net/ipv4/Kconfig 2004-09-22 13:39:14.000000000 +0200 @@ -94,6 +94,54 @@ equal "cost" and chooses one of them in a non-deterministic fashion if a matching packet arrives. +config IP_ROUTE_MULTIPATH_CACHED + bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" + depends on: IP_ROUTE_MULTIPATH + help + Normally, equal cost multipath routing is not supported by the + routing cache. If you say Y here, alternative routes are cached + and on cache lookup a route is chosen in a configurable fashion. + + If unsure, say N. + +# +# multipath policy configuration +# +choice + prompt "Multipath policy" + depends on IP_ROUTE_MULTIPATH_CACHED + default IP_ROUTE_MULTIPATH_RANDOM + +config IP_ROUTE_MULTIPATH_RR + bool "round robin (EXPERIMENTAL)" + help + Mulitpath routes are chosen according to Round Robin + +config IP_ROUTE_MULTIPATH_RANDOM + bool "random multipath (EXPERIMENTAL)" + help + Multipath routes are chosen in a random fashion. Actually, + there is no weight for a route. The advantage of this policy + is that it is implemented stateless and therefore introduces only + a very small delay. +config IP_ROUTE_MULTIPATH_WRANDOM + bool "weighted random multipath (EXPERIMENTAL)" + help + Multipath routes are chosen in a weighted random fashion. + The per route weights are the weights visible via ip route 2. As the + corresponding state management introduces some overhead routing delay + is increased. +config IP_ROUTE_MULTIPATH_DRR + bool "interface round robin (EXPERIMENTAL)" + help + Connections are distributed in a round robin fashion over the + available interfaces. This policy makes sense if the connections + should be primarily distributed on interfaces and not on routes. +endchoice +# +# END OF multipath policy configuration +# + config IP_ROUTE_TOS bool "IP: use TOS value as routing key" depends on IP_ADVANCED_ROUTER diff -ruN linux-2.6.8.1.split/net/ipv4/Makefile linux-2.6.8.1.multipath/net/ipv4/Makefile --- linux-2.6.8.1.split/net/ipv4/Makefile 2004-09-22 10:01:21.000000000 +0200 +++ linux-2.6.8.1.multipath/net/ipv4/Makefile 2004-09-22 13:40:36.000000000 +0200 @@ -21,6 +21,10 @@ obj-$(CONFIG_INET_IPCOMP) += ipcomp.o obj-$(CONFIG_INET_TUNNEL) += xfrm4_tunnel.o obj-$(CONFIG_IP_PNP) += ipconfig.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RR) += multipath_rr.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RANDOM) += multipath_random.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_WRANDOM) += multipath_wrandom.o +obj-$(CONFIG_IP_ROUTE_MULTIPATH_DRR) += multipath_drr.o obj-$(CONFIG_NETFILTER) += netfilter/ obj-$(CONFIG_IP_VS) += ipvs/ diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_drr.c linux-2.6.8.1.multipath/net/ipv4/multipath_drr.c --- linux-2.6.8.1.split/net/ipv4/multipath_drr.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath/net/ipv4/multipath_drr.c 2004-09-22 18:09:04.000000000 +0200 @@ -0,0 +1,292 @@ +/* + * Device round robin policy for multipath. + * + * + * Version: $Id: multipath_drr.c,v 1.1.2.1 2004/09/16 07:42:34 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +struct multipath_device +{ + int ifi; /* interface index of device */ + atomic_t usecount; + int allocated; +}; + +#define MULTIPATH_MAX_DEVICECANDIDATES 10 + +static struct multipath_device state[MULTIPATH_MAX_DEVICECANDIDATES]; +static spinlock_t state_lock = SPIN_LOCK_UNLOCKED; +static int registered_dev_notifier = 0; +static struct rtable *last_selection = NULL; + +#define RTprint(a...) // printk(KERN_DEBUG a) + + + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +static int __inline__ __multipath_findslot(void) { + int i; + for (i=0; iifindex); + if (devidx != -1) { + state[devidx].allocated = 0; + state[devidx].ifi = 0; + atomic_set(&state[devidx].usecount, 0); + RTprint(KERN_DEBUG"%s: successfully removed device " \ + "with index %d\n",__FUNCTION__, devidx); + } + else { + RTprint(KERN_DEBUG"%s: Device not relevant for " \ + " multipath: %d\n", + __FUNCTION__, devidx); + } + + spin_unlock_bh(&state_lock); + break; + } + return NOTIFY_DONE; +} + +struct notifier_block multipath_dev_notifier = { + .notifier_call = multipath_dev_event, +}; + +void __multipath_remove(struct rtable* rt) { + if (last_selection == rt) { + last_selection = NULL; + } +} + +void __multipath_safe_inc(atomic_t* usecount) +{ + int n; + atomic_inc(usecount); + n = atomic_read(usecount); + if (n<=0) { + int i; + RTprint("%s: detected overflow, now ill will reset all "\ + "usecounts\n", __FUNCTION__); + + spin_lock_bh(&state_lock); + for (i=0; iflags & FLOWI_FLAG_MULTIPATHOLDROUTE ) != 0 && + last_selection != NULL ) { + RTprint( KERN_CRIT"%s: holding route \n", __FUNCTION__ ); + result = last_selection; + *rp = result; + return; + } + + + /* 1. make sure all alt. nexthops have the same GC related data */ + /* 2. determine the new candidate to be returned */ + result = NULL; + cur_min = NULL; + for (nh = rcu_dereference(first); nh; + nh = rcu_dereference(nh->u.rt_next)) { + if ( ( nh->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&nh->fl, flp ) ) { + int nh_ifidx = nh->u.dst.dev->ifindex; + nh->u.dst.lastuse = jiffies; + nh->u.dst.__use++; + if (result != NULL) { + continue; + } + + /* search for the output interface */ + /* this is not SMP safe, only add/remove are + SMP safe as wrong usecount updates have no big + impact */ + devidx = __multipath_finddev(nh_ifidx); + if (devidx==-1) { + /* add the interface to the array + SMP safe */ + spin_lock_bh(&state_lock); + + /* due to SMP: search again */ + devidx = __multipath_finddev(nh_ifidx); + if (devidx==-1) { + /* add entry for device */ + devidx = __multipath_findslot(); + if (devidx==-1) { + /* unlikely but possible */ + RTprint(KERN_DEBUG"%s: " \ + "out of space\n", + __FUNCTION__); + continue; + } + + state[devidx].allocated = 1; + state[devidx].ifi = nh_ifidx; + atomic_set(&state[devidx].usecount, 0); + min_usecount = 0; + RTprint(KERN_DEBUG"%s: created " \ + " for " \ + "device %d and " \ + "min_usecount " \ + " == -1\n", + __FUNCTION__, + nh_ifidx ); + } + + spin_unlock_bh(&state_lock); + } + + if (min_usecount == 0) { + /* if the device has not been used it is + the primary target */ + RTprint(KERN_DEBUG"%s: now setting " \ + "result to device %d\n", + __FUNCTION__, nh_ifidx ); + + __multipath_safe_inc(&state[devidx].usecount); + result = nh; + } + else { + int count = + atomic_read(&state[devidx].usecount); + + if (min_usecount == -1 || + count < min_usecount) { + cur_min = nh; + cur_min_devidx = devidx; + min_usecount = count; + + RTprint(KERN_DEBUG"%s: found " \ + "device " \ + "%d with usecount == %d\n", + __FUNCTION__, + nh_ifidx, + min_usecount); + } + } + } + } + + if (!result) { + if (cur_min) { + RTprint( KERN_DEBUG"%s: index of device in state "\ + "array: %d\n", + __FUNCTION__, cur_min_devidx ); + __multipath_safe_inc(&state[cur_min_devidx].usecount); + result = cur_min; + } + else { + RTprint( KERN_DEBUG"%s: utilized first\n", + __FUNCTION__); + result = first; + } + } + else { + RTprint(KERN_DEBUG"%s: utilize result: found device " \ + "%d with usecount == %d\n", + __FUNCTION__, result->u.dst.dev->ifindex, + min_usecount); + + } + + *rp = result; + last_selection = result; +} diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_random.c linux-2.6.8.1.multipath/net/ipv4/multipath_random.c --- linux-2.6.8.1.split/net/ipv4/multipath_random.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath/net/ipv4/multipath_random.c 2004-09-22 17:59:24.000000000 +0200 @@ -0,0 +1,124 @@ +/* + * Random policy for multipath. + * + * + * Version: $Id: multipath_random.c,v 1.1.2.3 2004/09/21 08:42:11 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RTprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_MAX_CANDIDATES 40 + +/* interface to random number generation */ +static unsigned int RANDOM_SEED = 93186752; +static __inline__ unsigned int random(unsigned int ubound); + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, + struct rtable **rp) { + struct rtable *rt; + struct rtable *decision; + unsigned char candidate_count = 0; + + /* count all candidate */ + for (rt = rcu_dereference(first); rt; + rt = rcu_dereference(rt->u.rt_next)) { + if ( ( rt->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&rt->fl, flp) ) { + ++candidate_count; + } + } + + /* choose a random candidate */ + decision = first; + if ( candidate_count > 1 ) { + unsigned char i = 0; + unsigned char candidate_no = (unsigned char) + random(candidate_count); + RTprint( "%s: randomly chosen candidate: %d (count: %d)\n", + __FUNCTION__, candidate_no, candidate_count ); + + + /* find chosen candidate and adjust GC data for all candidates + to ensure they stay in cache */ + for (rt = first; rt; rt = rt->u.rt_next) { + if ( ( rt->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&rt->fl, flp) ) { + rt->u.dst.lastuse = jiffies; + if (i == candidate_no) { + decision = rt; + } + if (i >= candidate_count) { + break; + } + i++; + } + } + } + + decision->u.dst.__use++; + *rp = decision; +} + +static __inline__ unsigned int random(unsigned int ubound) +{ + static unsigned int a = 1588635695, + q = 2, + r = 1117695901; + RANDOM_SEED = a*(RANDOM_SEED % q) - r*(RANDOM_SEED / q); + return RANDOM_SEED % ubound; +} + diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_rr.c linux-2.6.8.1.multipath/net/ipv4/multipath_rr.c --- linux-2.6.8.1.split/net/ipv4/multipath_rr.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath/net/ipv4/multipath_rr.c 2004-09-22 17:03:07.000000000 +0200 @@ -0,0 +1,118 @@ +/* + * Round robin policy for multipath. + * + * + * Version: $Id: multipath_rr.c,v 1.1.2.2 2004/09/16 07:42:34 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RTprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_MAX_CANDIDATES 40 + +static struct rtable* last_used = NULL; + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + +void __multipath_remove(struct rtable *rt) +{ + if (last_used==rt) { + last_used = NULL; + } +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, struct rtable **rp) +{ + struct rtable *nh, *result, *min_use_cand = NULL; + int min_use = -1; + + /* if necessary and possible utilize the old alternative */ + if ( ( flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) != 0 && + last_used != NULL ) { + RTprint( KERN_CRIT"%s: holding route \n", + __FUNCTION__ ); + result = last_used; + goto out; + } + + + /* 1. make sure all alt. nexthops have the same GC related data */ + /* 2. determine the new candidate to be returned */ + result = NULL; + for (nh = rcu_dereference(first); nh; + nh = rcu_dereference(nh->u.rt_next)) { + if ( ( nh->u.dst.flags & DST_BALANCED ) != 0 && + multipath_comparekeys(&nh->fl, flp ) ) { + nh->u.dst.lastuse = jiffies; + + if (min_use == -1 || nh->u.dst.__use < min_use) { + min_use = nh->u.dst.__use; + min_use_cand = nh; + } + RTprint( KERN_CRIT"%s: found balanced entry\n", + __FUNCTION__ ); + } + } + result = min_use_cand; + if (!result) { + result = first; + } + + out: + last_used = result; + result->u.dst.__use++; + *rp = result; +} + + diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_wrandom.c linux-2.6.8.1.multipath/net/ipv4/multipath_wrandom.c --- linux-2.6.8.1.split/net/ipv4/multipath_wrandom.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8.1.multipath/net/ipv4/multipath_wrandom.c 2004-09-22 17:01:43.000000000 +0200 @@ -0,0 +1,374 @@ +/* + * Weighted random policy for multipath. + * + * + * Version: $Id: multipath_wrandom.c,v 1.1.2.3 2004/09/22 07:51:40 elueck Exp $ + * + * Authors: Einar Lueck + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define MPprint(a...) // printk(KERN_DEBUG a) + +#define MULTIPATH_STATE_SIZE 15 + +struct multipath_candidate { + struct multipath_candidate *next; + int power; + struct rtable *rt; +}; + +struct multipath_dest { + struct list_head list; + + const struct fib_nh *nh_info; + __u32 netmask; + __u32 network; + unsigned char prefixlen; + + struct rcu_head rcu; +}; + +struct multipath_bucket { + struct list_head head; + spinlock_t lock; +}; + +struct multipath_route { + struct list_head list; + + int oif; + __u32 gw; + struct list_head dests; + + struct rcu_head rcu; +}; + + +/* state: primarily weight per route information */ +static int multipath_state_initialized = 0; +static spinlock_t state_big_lock = SPIN_LOCK_UNLOCKED; +static struct multipath_bucket state[MULTIPATH_STATE_SIZE]; + + +/* interface to random number generation */ +static unsigned int RANDOM_SEED = 93186752; +static __inline__ unsigned int random(unsigned int ubound); + +static int __inline__ multipath_comparekeys(const struct flowi *flp1, + const struct flowi *flp2) { + return flp1->fl4_dst == flp2->fl4_dst && + flp1->fl4_src == flp2->fl4_src && + flp1->oif == flp2->oif && +#ifdef CONFIG_IP_ROUTE_FWMARK + flp1->fl4_fwmark == flp2->fl4_fwmark && +#endif + !((flp1->fl4_tos ^ flp2->fl4_tos) & + (IPTOS_RT_MASK | RTO_ONLINK)); +} + + +static unsigned char __multipath_lookup_weight(const struct flowi *fl, + const struct rtable *rt) { + const int state_idx = rt->idev->dev->ifindex % MULTIPATH_STATE_SIZE; + struct multipath_route *r; + struct multipath_route *target_route = NULL; + struct multipath_dest *d; + int weight = 1; + + /* lookup the weight information for a certain route */ + rcu_read_lock(); + + /* find state entry for gateway or add one if necessary */ + list_for_each_entry_rcu(r, &state[state_idx].head, list) { + if (r->gw == rt->rt_gateway && + r->oif == rt->idev->dev->ifindex) { + target_route = r; + break; + } + } + if (!target_route) { + /* this should not happen... but we are prepared */ + printk( KERN_CRIT"%s: missing state for gateway: %u and " \ + "device %d\n", __FUNCTION__, rt->rt_gateway, + rt->idev->dev->ifindex); + goto out; + } + + /* find state entry for destination */ + list_for_each_entry_rcu(d, &target_route->dests, list) { + __u32 targetnetwork = fl->fl4_dst & + (0xFFFFFFFF >> (32 - d->prefixlen)); + + if ((targetnetwork & d->netmask) == d->network) { + weight = d->nh_info->nh_weight; + MPprint("%s: found weight %d for gateway %u\n", + __FUNCTION__, weight, rt->rt_gateway); + goto out; + } + } + + out: + rcu_read_unlock(); + return weight; +} + +static void __multipath_init_state(void) +{ + spin_lock(&state_big_lock); + + /* check again due to SMP and to prevent contention */ + if (!multipath_state_initialized) { + int i; + for (i = 0; i < MULTIPATH_STATE_SIZE; ++i) { + INIT_LIST_HEAD(&state[i].head); + state[i].lock = SPIN_LOCK_UNLOCKED; + } + } + + /* now mark initialized */ + multipath_state_initialized = 1; + + spin_unlock(&state_big_lock); +} + +static void inline __multipath_init(void) +{ + /* do not spinlock to reduce unnecessary contention */ + if (!multipath_state_initialized) { + __multipath_init_state(); + } +} + +void __multipath_selectroute(const struct flowi *flp, + struct rtable *first, + struct rtable **rp) { + struct rtable *rt; + struct rtable *decision; + struct multipath_candidate *first_mpc = NULL; + struct multipath_candidate *mpc, *last_mpc = NULL; + int power = 0; + int last_power; + int selector; + const size_t size_mpc = sizeof(struct multipath_candidate); + + /* init state if necessary */ + __multipath_init(); + + + /* collect all candidates and identify their weights */ + for (rt = rcu_dereference(first); rt; + rt = rcu_dereference(rt->u.rt_next)) { + if ((rt->u.dst.flags & DST_BALANCED) != 0 && + multipath_comparekeys(&rt->fl, flp) ) { + struct multipath_candidate* mpc = + (struct multipath_candidate*) + kmalloc(size_mpc, GFP_KERNEL); + + power += __multipath_lookup_weight(flp, rt) * 10000; + + mpc->power = power; + mpc->rt = rt; + mpc->next = NULL; + + if (!first_mpc) + first_mpc = mpc; + else + last_mpc->next = mpc; + + last_mpc = mpc; + } + } + + /* choose a weighted random candidate */ + decision = first; + selector = random(power); + MPprint("%s: random number %d in range %d\n", __FUNCTION__, selector, + power); + last_power = 0; + + + /* select candidate, adjust GC data and cleanup local state */ + decision = first; + last_mpc = NULL; + for (mpc = first_mpc; mpc; mpc = mpc->next) { + mpc->rt->u.dst.lastuse = jiffies; + MPprint("%s: last_power = %d, selector: %d, mpc->power: %d\n", + __FUNCTION__, last_power, selector, mpc->power); + if (last_power <= selector && selector < mpc->power) { + decision = mpc->rt; + MPprint("%s: selected %u\n", __FUNCTION__, + decision->rt_gateway); + } + last_power = mpc->power; + if (last_mpc) { + kfree(last_mpc); + } + last_mpc = mpc; + } + if (last_mpc) { + /* concurrent __multipath_flush may lead to !last_mpc */ + kfree(last_mpc); + } + + decision->u.dst.__use++; + *rp = decision; +} + +void __multipath_set_nhinfo(__u32 network, + __u32 netmask, + unsigned char prefixlen, + const struct fib_nh* nh) +{ + const int state_idx = nh->nh_oif % MULTIPATH_STATE_SIZE; + struct multipath_route *r, *target_route = NULL; + struct multipath_dest *d, *target_dest = NULL; + + /* init state if necessary */ + __multipath_init(); + + /* store the weight information for a certain route */ + spin_lock(&state[state_idx].lock); + + /* find state entry for gateway or add one if necessary */ + list_for_each_entry_rcu(r, &state[state_idx].head, list) { + if (r->gw == nh->nh_gw && r->oif == nh->nh_oif) { + target_route = r; + break; + } + } + if (!target_route) { + const size_t size_rt = sizeof(struct multipath_route); + target_route = (struct multipath_route *) + kmalloc(size_rt, GFP_KERNEL); + + target_route->gw = nh->nh_gw; + target_route->oif = nh->nh_oif; + memset(&target_route->rcu, sizeof(struct rcu_head), 0); + INIT_LIST_HEAD(&target_route->dests); + + list_add_rcu(&target_route->list, &state[state_idx].head); + } + + /* find state entry for destination or add one if necessary */ + list_for_each_entry_rcu(d, &target_route->dests, list) { + if (d->nh_info == nh) { + target_dest = d; + break; + } + } + if (!target_dest) { + const size_t size_dst = sizeof(struct multipath_dest); + target_dest = (struct multipath_dest*) + kmalloc(size_dst, GFP_KERNEL); + + target_dest->nh_info = nh; + target_dest->network = network; + target_dest->netmask = netmask; + target_dest->prefixlen = prefixlen; + memset(&target_dest->rcu, sizeof(struct rcu_head), 0); + + list_add_rcu(&target_dest->list, &target_route->dests); + } + /* else: we already stored this info for another destination => + we are finished */ + + spin_unlock(&state[state_idx].lock); +} + + +static void __multipath_free(struct rcu_head *head) +{ + struct multipath_route *rt = container_of(head, struct multipath_route, + rcu); + kfree(rt); +} + +static void __multipath_free_dst(struct rcu_head *head) +{ + struct multipath_dest *dst = container_of(head, + struct multipath_dest, + rcu); + kfree(dst); +} + +void __multipath_flush() +{ + int i; + + MPprint("%s: called\n", __FUNCTION__); + + /* init state if necessary */ + __multipath_init(); + + /* defere delete to all entries */ + for (i = 0; i < MULTIPATH_STATE_SIZE; ++i) { + struct multipath_route *r; + spin_lock(&state[i].lock); + + list_for_each_entry_rcu(r, &state[i].head, list) { + struct multipath_dest *d; + list_for_each_entry_rcu(d, &r->dests, list) { + list_del_rcu(&d->list); + call_rcu(&d->rcu, + __multipath_free_dst); + + } + list_del_rcu(&r->list); + call_rcu(&r->rcu, + __multipath_free); + } + + spin_unlock(&state[i].lock); + } + + MPprint("%s: finished\n", __FUNCTION__); +} + +static __inline__ unsigned int random(unsigned int ubound) +{ + static unsigned int a = 1588635695, + q = 2, + r = 1117695901; + RANDOM_SEED = a*(RANDOM_SEED % q) - r*(RANDOM_SEED / q); + return RANDOM_SEED % ubound; +} diff -ruN linux-2.6.8.1.split/net/ipv4/route.c linux-2.6.8.1.multipath/net/ipv4/route.c --- linux-2.6.8.1.split/net/ipv4/route.c 2004-09-22 10:01:49.000000000 +0200 +++ linux-2.6.8.1.multipath/net/ipv4/route.c 2004-09-22 17:29:29.000000000 +0200 @@ -129,7 +129,7 @@ int ip_rt_secret_interval = 10 * 60 * HZ; static unsigned long rt_deadline; -#define RTprint(a...) printk(KERN_DEBUG a) +#define RTprint(a...) // printk(KERN_DEBUG a) static struct timer_list rt_flush_timer; static struct timer_list rt_periodic_timer; @@ -442,11 +442,13 @@ static __inline__ void rt_free(struct rtable *rt) { + multipath_remove( rt ); call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free); } static __inline__ void rt_drop(struct rtable *rt) { + multipath_remove( rt ); ip_rt_put(rt); call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free); } @@ -508,6 +510,54 @@ return score; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED +static struct rtable **rt_remove_balanced_route(struct rtable **chain_head, + struct rtable *expentry, + int* removed_count) +{ + int passedexpired = 0; + struct rtable **nextstep = NULL; + struct rtable **rthp = chain_head; + struct rtable *rth; + if (removed_count) + *removed_count = 0; + while ((rth = *rthp) != NULL) { + if ( rth == expentry ) { + passedexpired = 1; + } + + if (((*rthp)->u.dst.flags & DST_BALANCED) != 0 && + compare_keys(&(*rthp)->fl, &expentry->fl)) { + if (*rthp == expentry) { + *rthp = rth->u.rt_next; + continue; + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + if (removed_count) + ++(*removed_count); + } + } + else { + if ( !((*rthp)->u.dst.flags & DST_BALANCED) && + passedexpired && !nextstep ) { + nextstep = &rth->u.rt_next; + } + rthp = &rth->u.rt_next; + } + } + + rt_free(expentry); + if (removed_count) + ++(*removed_count); + + return nextstep; +} + +#endif + + /* This runs via a timer and thus is always in BH context. */ static void rt_check_expire(unsigned long dummy) { @@ -539,8 +589,24 @@ } /* Cleanup aged off entries. */ - *rthp = rth->u.rt_next; - rt_free(rth); +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + /* remove all related balanced entries if necessary */ + if ( rth->u.dst.flags & DST_BALANCED ) { + rthp = rt_remove_balanced_route( + &rt_hash_table[i].chain, + rth, NULL); + if (!rthp) { + break; + } + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ + *rthp = rth->u.rt_next; + rt_free(rth); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } spin_unlock(&rt_hash_table[i].lock); @@ -588,6 +654,9 @@ if (delay < 0) delay = ip_rt_min_delay; + /* flush existing multipath state*/ + multipath_flush(); + spin_lock_bh(&rt_flush_lock); if (del_timer(&rt_flush_timer) && delay > 0 && rt_deadline) { @@ -706,9 +775,29 @@ rthp = &rth->u.rt_next; continue; } +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + /* remove all related balanced entries if necessary */ + if ( rth->u.dst.flags & DST_BALANCED ) { + int r; + rthp = rt_remove_balanced_route( + &rt_hash_table[i].chain, + rth, + &r); + goal -= r; + if (!rthp) { + break; + } + } + else { + *rthp = rth->u.rt_next; + rt_free(rth); + goal--; + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ *rthp = rth->u.rt_next; rt_free(rth); goal--; +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } spin_unlock_bh(&rt_hash_table[k].lock); if (goal <= 0) @@ -789,7 +878,12 @@ spin_lock_bh(&rt_hash_table[hash].lock); while ((rth = *rthp) != NULL) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if (!(rth->u.dst.flags & DST_BALANCED) && + compare_keys(&rth->fl, &rt->fl)) { +#else if (compare_keys(&rth->fl, &rt->fl)) { +#endif /* Put it first */ *rthp = rth->u.rt_next; /* @@ -1623,6 +1717,10 @@ } rth->u.dst.flags= DST_HOST; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if ( res->fi->fib_nhs > 1 ) + rth->u.dst.flags |= DST_BALANCED; +#endif if (in_dev->cnf.no_policy) rth->u.dst.flags |= DST_NOPOLICY; if (in_dev->cnf.no_xfrm) @@ -1691,7 +1789,60 @@ struct in_device *in_dev, u32 daddr, u32 saddr, u32 tos) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + struct rtable* rth; + unsigned char hop, hopcount, lasthop; + int err = -EINVAL; + unsigned hash; + hopcount = res->fi->fib_nhs; + lasthop = hopcount - 1; + + /* distinguish between multipath and singlepath */ + if ( hopcount < 2 ) + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, + saddr, tos); + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", __FUNCTION__, + hopcount); + + /* add all alternatives to the routing cache */ + for ( hop = 0; hop < hopcount; ++hop ) { + res->nh_sel = hop; + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", + __FUNCTION__, hopcount); + + /* create a routing cache entry */ + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, + &rth ); + if ( err ) + return err; + + + /* put it into the cache */ + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); + if ( err ) + return err; + + /* forward hop information to multipath impl. */ + multipath_set_nhinfo(FIB_RES_NETWORK(*res), + FIB_RES_NETMASK(*res), + res->prefixlen, + &FIB_RES_NH(*res)); + + + /* only for the last hop the reference count is handled + outside */ + RTprint( KERN_DEBUG"%s: balanced entry created: %d\n", + __FUNCTION__, rth ); + if ( hop == lasthop ) + atomic_set(&(skb->dst->__refcnt), 1); + } + return err; +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ } @@ -2012,6 +2163,10 @@ } rth->u.dst.flags= DST_HOST; +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + if (res->fi->fib_nhs > 1) + rth->u.dst.flags |= DST_BALANCED; +#endif if (in_dev->cnf.no_xfrm) rth->u.dst.flags |= DST_NOXFRM; if (in_dev->cnf.no_policy) @@ -2103,7 +2258,77 @@ struct net_device *dev_out, unsigned flags) { +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED + u32 tos = RT_FL_TOS(oldflp); + unsigned char hop; + unsigned hash; + int err = -EINVAL; + unsigned char hopcount = res->fi->fib_nhs; + struct rtable* rth; + + RTprint( KERN_DEBUG"%s: entered (hopcount: %d, fl->oif: %d)\n", + __FUNCTION__, hopcount, fl->oif); + + if (res->fi->fib_nhs > 1) { + for ( hop = 0; hop < hopcount; ++hop ) { + struct net_device *dev2nexthop; + RTprint( KERN_DEBUG"%s: hop %d of %d\n", __FUNCTION__, + hop, hopcount ); + + res->nh_sel = hop; + + /* hold a work reference to the output device */ + dev2nexthop = FIB_RES_DEV(*res); + dev_hold(dev2nexthop); + + err = __mkroute_output(&rth, res, fl, oldflp, + dev2nexthop, flags); + + /** FIXME remove debug code */ + RTprint( KERN_DEBUG"%s: balanced entry created: %d " \ + " (GW: %u)\n", + __FUNCTION__, + &rth->u.dst, + FIB_RES_GW(*res) ); + + if ( err != 0 ) { + goto cleanup; + } + + RTprint( KERN_DEBUG"%s: created successfully %d\n", + __FUNCTION__, hop ); + + hash = rt_hash_code(oldflp->fl4_dst, + oldflp->fl4_src ^ + (oldflp->oif << 5), tos); + err = rt_intern_hash(hash, rth, rp); + RTprint( KERN_DEBUG"%s: hashed %d\n", + __FUNCTION__, hop ); + + /* forward hop information to multipath impl. */ + multipath_set_nhinfo(FIB_RES_NETWORK(*res), + FIB_RES_NETMASK(*res), + res->prefixlen, + &FIB_RES_NH(*res)); + cleanup: + /* release work reference to output device */ + dev_put(dev2nexthop); + + if ( err != 0 ) { + return err; + } + } + RTprint( KERN_DEBUG"%s: exited loop\n", __FUNCTION__ ); + atomic_set(&(*rp)->u.dst.__refcnt, 1); + return err; + } + else { + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, + flags); + } +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); +#endif } /* @@ -2316,6 +2541,15 @@ #endif !((rth->fl.fl4_tos ^ flp->fl4_tos) & (IPTOS_RT_MASK | RTO_ONLINK))) { + /* check for multipath routes and choose one if + necessary */ + if (multipath_selectroute(flp, rth, rp)) { + dst_hold(&(*rp)->u.dst); + RT_CACHE_STAT_INC(out_hit); + rcu_read_unlock_bh(); + return 0; + } + rth->u.dst.lastuse = jiffies; dst_hold(&rth->u.dst); rth->u.dst.__use++; --------------080000050907000406020006-- From per.sil@gmx.it Wed Sep 22 09:45:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 09:45:46 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8MGjYFA011469 for ; Wed, 22 Sep 2004 09:45:34 -0700 Received: (qmail 2107 invoked by uid 65534); 22 Sep 2004 16:45:17 -0000 Received: from 83-64-102-174.dreihufeisengasse.xdsl-line.inode.at (EHLO nikic) (83.64.102.174) by mail.gmx.net (mp017) with SMTP; 22 Sep 2004 18:45:17 +0200 X-Authenticated: #4053160 From: "Perolo Silantico" To: "Stephen Hemminger" , , , , Cc: Subject: AW: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Date: Wed, 22 Sep 2004 18:45:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8MGjYFA011469 X-archive-position: 9298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per.sil@gmx.it Precedence: bulk X-list: netdev Content-Length: 5986 Lines: 183 Same behaviour for drivers: - 8139too (kernel 2.6.8.1 and 2.6.8) - e100 (kernel 2.6.8) - eepro100 (kernel 2.6.8.1) I have tried with all these drivers. Therefore it seemed to me, that this is not related to any specific driver. But to be sure, I will grab a 3com 905C from another server and try with that one and will try with the PCNet32 too. > > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Sent: Mittwoch, 22. September 2004 18:27 > To: per.sil@gmx.it; john.ronciak@intel.com; ganesh.venkatesan@intel.com; > scott.feldman@intel.com > Cc: netdev@oss.sgi.com > Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: > transmit timed out " > > > This is an ethernet driver related problem. Which of the > ethernet cars (PCNet32 or E100) > is assigned to eth0? And which of the two e100 drivers (e100 or > eepro100) are you using? > > > On Tue, 21 Sep 2004 09:42:06 -0700 > bugme-daemon@osdl.org wrote: > > > http://bugme.osdl.org/show_bug.cgi?id=3440 > > > > Summary: eth0 freezes: "NETDEV WATCHDOG: eth0: > transmit timed out > > " > > Kernel Version: 2.6.8.1 > > Status: NEW > > Severity: high > > Owner: shemminger@osdl.org > > Submitter: per.sil@gmx.it > > > > > > Hi kernel developers, > > > > There exists a severe problem with a linux box of my own. The > problem does not > > occur when using kernel 2.4.25 on the same machine. I need your help. > > > > Distribution: > > ------------- > > Gentoo Linux 1.4 (2004.2), recompiled whole system with kernel > 2.6 and NPTL. > > > > Hardware Environment: > > --------------------- > > - IBM PC Server 325, Dual Pentium Pro 180MHz, 256MB RAM, > > - 3ware Controller 6410 with RAID 1+0, > > - PCNet32 10MBit on-board card > > - Intel EtherExpress Pro 100 > > - RTL 8139 Card. > > - 2x AVM ISDN B1 active ISA cards (Rev. 2.0 and Rev. 3.0 cards) > > > > Tried with both cards, and tried both manually set to half-duplex or > > full-duplex. tried same kernel with ISDN cards removed (but > modules still > > compiled in) > > > > I removed one processor using same SMP-enabled kernel on single > processor system > > - problem persists. > > > > The box is connected to a DLink DGS-1008D GigaBit switch and I > tried with a > > D-Link DES 1026G switch. > > > > > > The source of the transfer is a HP Netserver Dual Pentium III > 600MHz with kernel > > 2.4.23_pre8 SMP and same openSSH version, connected to the same switch. > > > > > > Software Environment: > > --------------------- > > "vanilla" kernel 2.6.8.1 on Gentoo Linux (see dmesg output and > config file) > > IPv6 compiled in but deactivated with > > ifconfig eth1 inet6 del ... > > > > same problem with kernel 2.6.7 and 2.6.8 using same kernel > configuration. > > > > gcc-3.3.4 > > glibc-2.3.4.20040808 > > OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 > > > > (for installed system utils, see attached file) > > > > Problem Description: > > --------------------- > > > > When transfering some data (approx. 3 GB in size) from one > amchine on the LAN to > > this box the transmission hangs on the interface after some > seconds (20MBs) and > > a "time out" occures. Then the LAN connection freezes, is > terminated and the > > linux box is not reachable from the network anymore. After some > minutes the > > connection recoveres again. > > > > The network transmission times out and the ethernet driver is > not responding to > > any LAN traffic (not even to any ICMP echo request). kernel log > message tells: > > > > NETDEV WATCHDOG: eth0: transmit timed out > > eth0: Tx descriptor 0 is 0008a072. > > > > (off course: address of descriptor varies) > > After approx. 4 minutes, the LAN connection of the box recovers > and you can > > connect to the box again. (until next transfer is started) > > > > transfer issued by another host: > > ................................ > > Usually a transfer host consumes all interface bandwidth > available (100 MBit LAN > > with full-duplex cards on both involved machines gives at least > 1.6 MByte/s if > > SCP overhead is taken into consideration). the connection stays > alive if it > > limited to smaller bandwith with fe. 100 Kbit (~ 12.5 KBytes) > "scp -l 100 ...". > > But using 1000 KBit (~125 KByte) "scp -l 1000 ..." the > connection is freezing > > although maximum bandwidth is not reached. > > > > transfer issued by host itself: > > ................................ > > If the box issues a transfer from the internet using 235 > KBytes/s (~ 2MBits/s) > > everything works out fine. If the box issues the transfer from > the LAN with full > > bandwith of 1.8 MBytes/s then the LAN connection is freezing too. > > > > > > If I turn of window scaling with "echo 0 > > > /proc/sys/net/ipv4/tcp_window_scaling" then the time needed to > recover the > > interface seems to decrease. The SCP transfer still freezes but > LAN timeout of > > the box is small enough to keep SSH connection alive. > > > > it did not help to set the following, as suggested by other web pages: > > tcp_default_win_scale=0 > > tcp_moderate_rcvbuf=0 > > > > > > Steps to reproduce: > > ------------------- > > start any SCP/SFTP transfer to the linux box with kernel > 2.6.8.1 - always > > reproducable on my box. I do not know about others since this > is my first box > > with kernel 2.6.x > > > > > > > > If you need more information or testing, please let me know. I > will not change > > the configuration of the box for some time to be able to > fullfill your requests, > > hoping to help solving the problem. > > > > > > Yours > > Perolo > > > > PS: Dear maintainer, I am able to grant you access to the > computer if this will > > help you. please contact me if this is vital for solving the problem. > > > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > From brazilnut@us.ibm.com Wed Sep 22 10:51:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 10:51:18 -0700 (PDT) Received: from beaverton.ibm.com (bi01p1.co.us.ibm.com [32.97.110.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MHp6tR013762 for ; Wed, 22 Sep 2004 10:51:13 -0700 Received: by beaverton.ibm.com (Postfix, from userid 1000) id 797491F88BF; Wed, 22 Sep 2004 10:50:39 -0700 (PDT) Date: Wed, 22 Sep 2004 10:50:39 -0700 From: Don Fry To: Perolo Silantico Cc: Stephen Hemminger , john.ronciak@intel.com, ganesh.venkatesan@intel.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Message-ID: <20040922175039.GA14542@us.ibm.com> References: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-archive-position: 9299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2223 Lines: 63 In looking at the dmesg log for bug 3440, it looks like eth0 is a RealTek adapter and eth1 is an eepro100. "8139too Fast Ethernet driver 0.9.27 eth0: RealTek RTL8139 at 0xd0842000, 00:50:fc:4c:d6:9b, IRQ 9 eth0: Identified 8139 chip type 'RTL-8139C'" "eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others eth1: 0000:00:0e.0, 00:A0:C9:43:8C:E4, IRQ 15." Another way to verify which driver is associated with a device name is to use 'ethtool -i eth0'. This will report the driver name and version of the driver. If the same problems happens with the pcnet32 driver, I can help you debug the problem with the pcnet32. On Wed, Sep 22, 2004 at 06:45:12PM +0200, Perolo Silantico wrote: > Same behaviour for drivers: > - 8139too (kernel 2.6.8.1 and 2.6.8) > - e100 (kernel 2.6.8) > - eepro100 (kernel 2.6.8.1) > > I have tried with all these drivers. Therefore it seemed to me, that this is not related to any specific driver. But to be sure, I will grab a 3com 905C from another server and try with that one and will try with the PCNet32 too. > > > > > From: Stephen Hemminger [mailto:shemminger@osdl.org] > > Sent: Mittwoch, 22. September 2004 18:27 > > To: per.sil@gmx.it; john.ronciak@intel.com; ganesh.venkatesan@intel.com; > > scott.feldman@intel.com > > Cc: netdev@oss.sgi.com > > Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: > > transmit timed out " > > > > > > This is an ethernet driver related problem. Which of the > > ethernet cars (PCNet32 or E100) > > is assigned to eth0? And which of the two e100 drivers (e100 or > > eepro100) are you using? > > > > > > On Tue, 21 Sep 2004 09:42:06 -0700 > > bugme-daemon@osdl.org wrote: > > > > > http://bugme.osdl.org/show_bug.cgi?id=3440 > > > > > > Summary: eth0 freezes: "NETDEV WATCHDOG: eth0: > > transmit timed out > > > " > > > Kernel Version: 2.6.8.1 > > > Status: NEW > > > Severity: high > > > Owner: shemminger@osdl.org > > > Submitter: per.sil@gmx.it > > > > > > -- Don Fry brazilnut@us.ibm.com From davem@davemloft.net Wed Sep 22 10:53:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 10:53:33 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MHrSoj014103 for ; Wed, 22 Sep 2004 10:53:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABHx-0004Tk-00; Wed, 22 Sep 2004 10:52:21 -0700 Date: Wed, 22 Sep 2004 10:52:21 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, pablo@eurodev.net, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040922105221.59a67d4b.davem@davemloft.net> In-Reply-To: <1095854920.1047.64.camel@jzny.localdomain> References: <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 277 Lines: 9 On 22 Sep 2004 08:08:40 -0400 jamal wrote: > Note also, theres a lot of wastage of that scarce sock buffer via page > sized skbs - its not as trivial to fix, but would go some way to improve > overrunning of the socket. Thanks for reminding me about this. From davem@davemloft.net Wed Sep 22 11:02:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:02:22 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MI2E05014641 for ; Wed, 22 Sep 2004 11:02:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABQf-0004V1-00; Wed, 22 Sep 2004 11:01:21 -0700 Date: Wed, 22 Sep 2004 11:01:20 -0700 From: "David S. Miller" To: Jesse Cc: shemminger@osdl.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: Fw: [Bug 3419] New: kernel BUG at net/ipv4/fib_semantics.c:1039! Message-Id: <20040922110120.022c170e.davem@davemloft.net> In-Reply-To: <20040922092520.U41787@leaf.lumiere.net> References: <20040922092319.4ba5b8fb@dell_ss3.pdx.osdl.net> <20040922092520.U41787@leaf.lumiere.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 280 Lines: 10 On Wed, 22 Sep 2004 09:26:30 -0700 (PDT) Jesse wrote: > I haven't had a chance to try a new snapshot version yet. I will try one > later today and report back. That crash should definitely be cured in the current code. Let us know if it is still there. Thanks. From davem@davemloft.net Wed Sep 22 11:05:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:05:08 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MI50Y4015019 for ; Wed, 22 Sep 2004 11:05:00 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABTL-0004VN-00; Wed, 22 Sep 2004 11:04:07 -0700 Date: Wed, 22 Sep 2004 11:04:07 -0700 From: "David S. Miller" To: Olaf Hering Cc: akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] remove leading space in linux/skbuff.h Message-Id: <20040922110407.401c90bc.davem@davemloft.net> In-Reply-To: <20040922084208.GB12717@suse.de> References: <20040918223832.GA28730@suse.de> <20040921195529.0f355491.davem@davemloft.net> <20040922084208.GB12717@suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 417 Lines: 15 On Wed, 22 Sep 2004 10:42:08 +0200 Olaf Hering wrote: > David, > msgid 20040918224507.GA28794@suse.de and the reply doesnt contain such > an encoding. > > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit Well, there they were when I saved the message text to a file using sylpheed. Thanks for the attachment, I'll integrate your patches. From davem@davemloft.net Wed Sep 22 11:10:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:10:44 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MIAcrW015462 for ; Wed, 22 Sep 2004 11:10:38 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABYZ-0004W8-00; Wed, 22 Sep 2004 11:09:31 -0700 Date: Wed, 22 Sep 2004 11:09:31 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [IPv4] Kill remnant of ip_nat_dumb Message-Id: <20040922110931.68b113a4.davem@davemloft.net> In-Reply-To: <1095855039.1045.67.camel@jzny.localdomain> References: <20040922040155.GA19302@gondor.apana.org.au> <1095855039.1045.67.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 789 Lines: 23 On 22 Sep 2004 08:10:39 -0400 jamal wrote: > Geez, I missed that we killed static NAT too. Whats wrong with it? > I know at least two users of this - did we ask or > is posting on netdev == ask? It's gone until someone fixes it up into working condition once more. It's been broken ever since the first bits of IPSEC dst cache infrastructure went in. The old code is in the source history if anyone wants to resurrect it and try to get it going again, but frankly my opinion is: 1) there are ways to do that with other technologies in the tree, hey even tc actions could do it (wink wink :-) 2) judging by the amount of complaints of it not working any- more (ie. nearly zero), I don't think it's worth spending time on it But have at it if you want :-) From davem@davemloft.net Wed Sep 22 11:13:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:13:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MID2di015835 for ; Wed, 22 Sep 2004 11:13:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABb7-0004WT-00; Wed, 22 Sep 2004 11:12:09 -0700 Date: Wed, 22 Sep 2004 11:12:09 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922111209.7887df53.davem@davemloft.net> In-Reply-To: <20040922140000.GD27432@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 490 Lines: 17 On Wed, 22 Sep 2004 16:00:00 +0200 Andi Kleen wrote: > I tried it with rc2bk8 again and the performance is much better (22MB/s) > that what I got earlier with 2.6.8rc2, but still far below what 2.6.5 gets > on the same hardware (68MB/s) > > Both tests with netperf over e1000. Great, please try one more thing to help me narrow this down. Rerun your e1000 tests after going: ethtool -K eth? tso off and see if that gets you back to 2.6.5 era performance. Thanks Andi. From davem@davemloft.net Wed Sep 22 11:15:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:15:15 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MIFAAx016207 for ; Wed, 22 Sep 2004 11:15:11 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABdB-0004Ws-00; Wed, 22 Sep 2004 11:14:17 -0700 Date: Wed, 22 Sep 2004 11:14:16 -0700 From: "David S. Miller" To: lkml@einar-lueck.de Cc: elueck@de.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 1/2] ipv4 multipath routing, bk head Message-Id: <20040922111416.66563786.davem@davemloft.net> In-Reply-To: <4151A8E5.6060600@de.ibm.com> References: <4151A8E5.6060600@de.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 82 Lines: 5 We've all seen your patches already, you don't need to send them again. Thanks. From davem@davemloft.net Wed Sep 22 11:16:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:17:04 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MIGxFY016558 for ; Wed, 22 Sep 2004 11:16:59 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CABea-0004XA-00; Wed, 22 Sep 2004 11:15:44 -0700 Date: Wed, 22 Sep 2004 11:15:44 -0700 From: "David S. Miller" To: David Woodhouse Cc: andre@tomt.net, jgarzik@pobox.com, pp@ee.oulu.fi, netdev@oss.sgi.com Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. Message-Id: <20040922111544.469dc4c2.davem@davemloft.net> In-Reply-To: <1095854932.17821.1190.camel@hades.cambridge.redhat.com> References: <20040920212453.GA15392@ee.oulu.fi> <414F7CD9.3090008@pobox.com> <414FC92F.6090009@tomt.net> <1095854932.17821.1190.camel@hades.cambridge.redhat.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 24 On Wed, 22 Sep 2004 13:08:52 +0100 David Woodhouse wrote: > On Tue, 2004-09-21 at 08:24 +0200, Andre Tomt wrote: > > Jeff Garzik wrote: > > > I hit this _once_ on my gateway (NAT'ing firewall IPv4, now also IPv6 > > > router). > > > > > > No idea why it went away, I just assumed a more recent kernel fixed > > > something. > > > > We've been seeing this all the time on 2.6.8.1 + "critical fixes". > > Pretty much anytime a router with tunneling interfaces is taken down for > > shutdown or reboot, it hangs spinning waiting for the tunnel devices to > > get freed, as ifdown gets run. > > It's not just tunnel interfaces. It seems to be related to hot-unplug of > interfaces with live IPv6 addresses. I've seen it on my prism54 card too > on many recent kernels. All I have to do is insert it and remove it a > few times. There is code in ipv6 which takes route references to devices and moves that reference over to loopback. There might be bugs in that area, and I would suggest debugging in that area. From ak@suse.de Wed Sep 22 11:19:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 11:19:15 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MIJ8Hm016906 for ; Wed, 22 Sep 2004 11:19:09 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 6C65CC4BDB2; Wed, 22 Sep 2004 20:14:36 +0200 (CEST) Date: Wed, 22 Sep 2004 20:14:33 +0200 From: Andi Kleen To: "David S. Miller" Cc: hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [IPv4] Kill remnant of ip_nat_dumb Message-ID: <20040922181433.GH27432@wotan.suse.de> References: <20040922040155.GA19302@gondor.apana.org.au> <1095855039.1045.67.camel@jzny.localdomain> <20040922110931.68b113a4.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922110931.68b113a4.davem@davemloft.net> X-archive-position: 9307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 573 Lines: 16 On Wed, Sep 22, 2004 at 11:09:31AM -0700, David S. Miller wrote: > On 22 Sep 2004 08:10:39 -0400 > jamal wrote: > > > Geez, I missed that we killed static NAT too. Whats wrong with it? > > I know at least two users of this - did we ask or > > is posting on netdev == ask? > > It's gone until someone fixes it up into working condition > once more. It's been broken ever since the first bits > of IPSEC dst cache infrastructure went in. Also netfilter has a static NAT too these days, so it doesn't seem to be very useful to have another one. -Andi From jesse.brandeburg@intel.com Wed Sep 22 12:26:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 12:26:07 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MJQ00N021745 for ; Wed, 22 Sep 2004 12:26:01 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8MJPXrr017636; Wed, 22 Sep 2004 19:25:33 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id i8MJSowM013396; Wed, 22 Sep 2004 19:28:50 GMT Received: from [10.23.51.23] ([10.23.51.23]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i8MJPiMs016024; Wed, 22 Sep 2004 12:25:44 -0700 Date: Wed, 22 Sep 2004 12:25:44 -0700 (PDT) From: Jesse Brandeburg X-X-Sender: jbrandeb@isotope.jf.intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [PATCH 1/2 2.6] e100: fix NAPI race with watchdog Message-ID: ReplyTo: "Jesse Brandeburg" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 2150 Lines: 59 While polling in NAPI mode, we were occassionally getting interrupts re-enabled by the watchdog trying to generate a software interrupt. Fix is to add a spinlock around that shared hardware register to allow a read-modify-write operation. This was nasty nasty. I don't like the spinlock in the hot path but i see no other way. Comments are welcome. Updates the driver version as well. Signed-off-by: Jesse Brandeburg --- netdev-2.6/drivers/net/e100.c 2004-09-21 13:54:33.000000000 -0700 +++ /home/jbrandeb/netdev-2.6/drivers/net/e100.c.watchdog.patch 2004-09-22 11:49:05.000000000 -0700 @@ -155,7 +155,7 @@ #define DRV_NAME "e100" #define DRV_EXT "-NAPI" -#define DRV_VERSION "3.1.4"DRV_EXT +#define DRV_VERSION "3.1.4-k2"DRV_EXT #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" #define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" #define PFX DRV_NAME ": " @@ -575,13 +575,21 @@ static inline void e100_write_flush(stru static inline void e100_enable_irq(struct nic *nic) { + unsigned long flags; + + spin_lock_irqsave(&nic->cmd_lock, flags); writeb(irq_mask_none, &nic->csr->scb.cmd_hi); + spin_unlock_irqrestore(&nic->cmd_lock, flags); e100_write_flush(nic); } static inline void e100_disable_irq(struct nic *nic) { + unsigned long flags; + + spin_lock_irqsave(&nic->cmd_lock, flags); writeb(irq_mask_all, &nic->csr->scb.cmd_hi); + spin_unlock_irqrestore(&nic->cmd_lock, flags); e100_write_flush(nic); } @@ -1254,8 +1262,13 @@ static void e100_watchdog(unsigned long mii_check_link(&nic->mii); /* Software generated interrupt to recover from (rare) Rx - * allocation failure */ - writeb(irq_sw_gen, &nic->csr->scb.cmd_hi); + * allocation failure. + * Unfortunately have to use a spinlock to not re-enable interrupts + * accidentally, due to hardware that shares a register between the + * interrupt mask bit and the SW Interrupt generation bit */ + spin_lock_irq(&nic->cmd_lock); + writeb(readb(&nic->csr->scb.cmd_hi) | irq_sw_gen,&nic->csr->scb.cmd_hi); + spin_unlock_irq(&nic->cmd_lock); e100_write_flush(nic); e100_update_stats(nic); From jesse.brandeburg@intel.com Wed Sep 22 12:28:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 12:28:14 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MJS9g2022080 for ; Wed, 22 Sep 2004 12:28:09 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8MJRdrr018838; Wed, 22 Sep 2004 19:27:40 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id i8MJJwkH027571; Wed, 22 Sep 2004 19:19:59 GMT Received: from [10.23.51.23] ([10.23.51.23]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i8MJRiMs016064; Wed, 22 Sep 2004 12:27:44 -0700 Date: Wed, 22 Sep 2004 12:27:44 -0700 (PDT) From: Jesse Brandeburg X-X-Sender: jbrandeb@isotope.jf.intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [PATCH 2/2 2.6] e100: whitespace and DPRINTKS Message-ID: ReplyTo: "Jesse Brandeburg" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 1802 Lines: 52 This is a short patch to add a couple of new DPRINTKS and fix some whitespace issues. Signed-off-by: Jesse Brandeburg --- netdev-2.6/drivers/net/e100.c 2004-09-21 13:54:33.000000000 -0700 +++ /home/jbrandeb/netdev-2.6/drivers/net/e100.c.msg.patch 2004-09-22 11:55:01.000000000 -0700 @@ -1305,6 +1305,7 @@ static int e100_xmit_frame(struct sk_buf switch(err) { case -ENOSPC: /* We queued the skb, but now we're out of space. */ + DPRINTK(TX_ERR, DEBUG, "No space for CB\n"); netif_stop_queue(netdev); break; case -ENOMEM: @@ -1469,7 +1470,7 @@ static inline int e100_rx_indicate(struc /* If data isn't ready, nothing to indicate */ if(unlikely(!(rfd_status & cb_complete))) - return -EAGAIN; + return -EAGAIN; /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; @@ -1761,7 +1762,7 @@ static int e100_loopback_test(struct nic if(memcmp(nic->rx_to_clean->skb->data + sizeof(struct rfd), skb->data, ETH_DATA_LEN)) - err = -EAGAIN; + err = -EAGAIN; err_loopback_none: mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, 0); @@ -1960,6 +1961,8 @@ static int e100_set_ringparam(struct net rfds->count = min(rfds->count, rfds->max); cbs->count = max(ring->tx_pending, cbs->min); cbs->count = min(cbs->count, cbs->max); + DPRINTK(DRV, INFO, "Ring Param settings: rx: %d, tx %d\n", + rfds->count, cbs->count); if(netif_running(netdev)) e100_up(nic); @@ -2352,7 +2355,7 @@ static int __init e100_init_module(void) printk(KERN_INFO PFX "%s, %s\n", DRV_DESCRIPTION, DRV_VERSION); printk(KERN_INFO PFX "%s\n", DRV_COPYRIGHT); } - return pci_module_init(&e100_driver); + return pci_module_init(&e100_driver); } static void __exit e100_cleanup_module(void) From jesse.brandeburg@intel.com Wed Sep 22 12:31:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 12:31:21 -0700 (PDT) Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MJVFgj022440 for ; Wed, 22 Sep 2004 12:31:15 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8MJV5JB031546; Wed, 22 Sep 2004 19:31:05 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id i8MJY4wM016983; Wed, 22 Sep 2004 19:34:04 GMT Received: from [10.23.51.23] ([10.23.51.23]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i8MJUwMs016187; Wed, 22 Sep 2004 12:30:58 -0700 Date: Wed, 22 Sep 2004 12:30:58 -0700 (PDT) From: Jesse Brandeburg X-X-Sender: jbrandeb@isotope.jf.intel.com To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [PATCH 1/1 2.6] RESEND ixgb: fix endianness issue for tx cleanup Message-ID: ReplyTo: "Jesse Brandeburg" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jesse.brandeburg@intel.com Precedence: bulk X-list: netdev Content-Length: 1044 Lines: 27 This patch fixes tx cleanup so that it works correctly on big endian machines. This time I remembered to update the version string. Signed-off-by: Jesse Brandeburg --- netdev-2.6/drivers/net/ixgb/ixgb_main.c 2004-09-21 13:54:34.000000000 -0700 +++ /home/jbrandeb/netdev-2.6/drivers/net/ixgb/ixgb_main.c 2004-09-22 12:01:42.000000000 -0700 @@ -30,7 +30,7 @@ char ixgb_driver_name[] = "ixgb"; char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver"; -char ixgb_driver_version[] = "1.0.66"; +char ixgb_driver_version[] = "1.0.66-k2"; char ixgb_copyright[] = "Copyright (c) 2001-2004 Intel Corporation."; /* ixgb_pci_tbl - PCI Device ID Table @@ -1676,7 +1676,7 @@ static boolean_t ixgb_clean_tx_irq(struc eop = tx_ring->buffer_info[i].next_to_watch; eop_desc = IXGB_TX_DESC(*tx_ring, eop); - while (eop_desc->status & cpu_to_le32(IXGB_TX_DESC_STATUS_DD)) { + while (eop_desc->status & IXGB_TX_DESC_STATUS_DD) { for (cleaned = FALSE; !cleaned;) { tx_desc = IXGB_TX_DESC(*tx_ring, i); From ak@suse.de Wed Sep 22 12:58:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 12:58:36 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MJwSrS023208 for ; Wed, 22 Sep 2004 12:58:29 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 77DE6C4E64A; Wed, 22 Sep 2004 21:55:16 +0200 (CEST) Date: Wed, 22 Sep 2004 21:55:15 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040922195515.GA2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922111209.7887df53.davem@davemloft.net> X-archive-position: 9311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 839 Lines: 25 On Wed, Sep 22, 2004 at 11:12:09AM -0700, David S. Miller wrote: > On Wed, 22 Sep 2004 16:00:00 +0200 > Andi Kleen wrote: > > > I tried it with rc2bk8 again and the performance is much better (22MB/s) > > that what I got earlier with 2.6.8rc2, but still far below what 2.6.5 gets > > on the same hardware (68MB/s) > > > > Both tests with netperf over e1000. > > Great, please try one more thing to help me narrow this down. > Rerun your e1000 tests after going: > > ethtool -K eth? tso off > > and see if that gets you back to 2.6.5 era performance. With tso off i get the same performance as on 2.6.5. I must add that this is a CSA e1000 (directly integrated into the chipset and doesn't use PCI) and TSO doesn't seem to be bring any advantage. On 2.6.5 the performance is the same with both TSO on or off. -Andi From slblake@petri-meat.com Wed Sep 22 13:05:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:05:09 -0700 (PDT) Received: from server26.totalchoicehosting.com (server26.totalchoicehosting.com [209.152.177.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MK52SV023630 for ; Wed, 22 Sep 2004 13:05:02 -0700 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1CADM8-0005Ex-E2; Wed, 22 Sep 2004 16:04:48 -0400 Subject: Re: [PATCH] Clean up fib_hash datastructures From: Steven Blake To: hadi@cyberus.ca Cc: netdev@oss.sgi.com In-Reply-To: <1095855154.1047.70.camel@jzny.localdomain> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040921090423.GE8058@wotan.suse.de> <20040921093252.GA32545@gondor.apana.org.au> <1095764621.1049.14.camel@jzny.localdomain> <1095809938.2340.19.camel@localhost.localdomain> <1095822637.1048.23.camel@jzny.localdomain> <1095854181.2342.2.camel@localhost.localdomain> <1095855154.1047.70.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1095883483.2342.472.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 22 Sep 2004 16:04:43 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 9312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: slblake@petri-meat.com Precedence: bulk X-list: netdev Content-Length: 376 Lines: 20 On Wed, 2004-09-22 at 08:12, jamal wrote: > > > What about edge? > > > > I've seen no evidence that any HW-based router is doing this. > > None of the chips i have come across had it - what about NPF, are they > putting this in their specs? No. See http://www.npforum.org/techinfo/IPv4-Rev2_IA.pdf http://www.npforum.org/techinfo/IPv6-Rev2_IA.pdf Regards, // Steve From j@lumiere.net Wed Sep 22 13:06:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:06:20 -0700 (PDT) Received: from tetris.eyetide.com (209.133.65.209.above.net [209.133.65.209] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MK6Dnq023940 for ; Wed, 22 Sep 2004 13:06:14 -0700 Received: from localhost (localhost [127.0.0.1]) by tetris.eyetide.com (Postfix) with ESMTP id 23A28947E3; Wed, 22 Sep 2004 13:05:58 -0700 (PDT) Received: from tetris.eyetide.com ([127.0.0.1]) by localhost (tetris.eyetide.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 65757-15; Wed, 22 Sep 2004 13:05:56 -0700 (PDT) Received: from leaf.lumiere.net (unknown [209.133.65.222]) by tetris.eyetide.com (Postfix) with ESMTP id C480E94677; Wed, 22 Sep 2004 13:05:52 -0700 (PDT) Received: by leaf.lumiere.net (Postfix, from userid 1000) id 16EB1CD13; Wed, 22 Sep 2004 13:05:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leaf.lumiere.net (Postfix) with ESMTP id 14D473ADA; Wed, 22 Sep 2004 13:05:52 -0700 (PDT) Date: Wed, 22 Sep 2004 13:05:52 -0700 (PDT) From: Jesse To: "David S. Miller" Cc: shemminger@osdl.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: Fw: [Bug 3419] New: kernel BUG at net/ipv4/fib_semantics.c:1039! In-Reply-To: <20040922110120.022c170e.davem@davemloft.net> Message-ID: <20040922130502.N41787@leaf.lumiere.net> References: <20040922092319.4ba5b8fb@dell_ss3.pdx.osdl.net> <20040922092520.U41787@leaf.lumiere.net> <20040922110120.022c170e.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at eyetide.com X-archive-position: 9313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: j@lumiere.net Precedence: bulk X-list: netdev Content-Length: 343 Lines: 14 > > I haven't had a chance to try a new snapshot version yet. I will try one > > later today and report back. > > That crash should definitely be cured in the current code. > Let us know if it is still there. I tested 2.6.9-rc2-bk8 and the system came up cleanly, including networking. Looks good so far. Thanks. --- Jesse From niv@us.ibm.com Wed Sep 22 13:07:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:07:39 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MK7Xpw024330 for ; Wed, 22 Sep 2004 13:07:34 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8MK7BRK518612; Wed, 22 Sep 2004 16:07:11 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MK8M6D078858; Wed, 22 Sep 2004 16:08:23 -0400 Message-ID: <4151DB6C.8050906@us.ibm.com> Date: Wed, 22 Sep 2004 13:07:08 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> In-Reply-To: <20040922195515.GA2619@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 574 Lines: 20 Andi Kleen wrote: > With tso off i get the same performance as on 2.6.5. > > I must add that this is a CSA e1000 (directly integrated into > the chipset and doesn't use PCI) and TSO doesn't seem to be > bring any advantage. On 2.6.5 the performance is the same > with both TSO on or off. Andi, was that with a netperf TCP stream test? I would not have thought there would be no difference prior to the changes DaveM made recently (now we obey congestion window). We certainly got quite a bit of a difference running SPECWeb etc, but that was on the e1000s. Nivedita From andy.grover@gmail.com Wed Sep 22 13:13:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:13:08 -0700 (PDT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.251]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKD3Yd024887 for ; Wed, 22 Sep 2004 13:13:03 -0700 Received: by mproxy.gmail.com with SMTP id w41so135526cwb for ; Wed, 22 Sep 2004 13:12:47 -0700 (PDT) Received: by 10.11.118.63 with SMTP id q63mr104651cwc; Wed, 22 Sep 2004 13:12:47 -0700 (PDT) Received: by 10.11.99.78 with HTTP; Wed, 22 Sep 2004 13:12:47 -0700 (PDT) Message-ID: Date: Wed, 22 Sep 2004 13:12:47 -0700 From: Andrew Grover Reply-To: Andrew Grover To: Andi Kleen Subject: Re: bad TSO performance in 2.6.9-rc2-BK Cc: "David S. Miller" , anton@samba.org, netdev@oss.sgi.com In-Reply-To: <20040922195515.GA2619@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> X-archive-position: 9315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.grover@gmail.com Precedence: bulk X-list: netdev Content-Length: 559 Lines: 14 On Wed, 22 Sep 2004 21:55:15 +0200, Andi Kleen wrote: > With tso off i get the same performance as on 2.6.5. > > I must add that this is a CSA e1000 (directly integrated into > the chipset and doesn't use PCI) and TSO doesn't seem to be > bring any advantage. On 2.6.5 the performance is the same > with both TSO on or off. I think this is caused by the congestion changes added between 2.6.9-rc1 and rc2. I am seeing good performance with rc1 and tso on (or off), but bad performance with rc2 and bk-latest only if tso is on. Regards -- Andy From niv@us.ibm.com Wed Sep 22 13:18:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:18:35 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKIUYi025281 for ; Wed, 22 Sep 2004 13:18:30 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8MKIDRS400210; Wed, 22 Sep 2004 16:18:13 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MKJM6D077558; Wed, 22 Sep 2004 16:19:26 -0400 Message-ID: <4151DDFF.6000902@us.ibm.com> Date: Wed, 22 Sep 2004 13:18:07 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leonid Grossman CC: "'Andi Kleen'" , "'David S. Miller'" , "'John Heffner'" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design References: <200409162034.i8GKYq39023185@guinness.s2io.com> In-Reply-To: <200409162034.i8GKYq39023185@guinness.s2io.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9316 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1704 Lines: 51 Leonid Grossman wrote: >>From: Nivedita Singhvi [mailto:niv@us.ibm.com] >>Sent: Thursday, September 16, 2004 9:19 AM >>To: Leonid Grossman >>Cc: 'Andi Kleen'; 'David S. Miller'; 'John Heffner'; >>netdev@oss.sgi.com >>Subject: Re: The ultimate TOE design >> >>Leonid Grossman wrote: >> >> >>>We can dream about benefits of huge MTUs, but the reality is that >>>moving beyond 9k MTU is years away. Reasons - mainly infrastructure, >>>plus MTU above ~10k may loose checksum protection (granted, this >>>depends whether the errors are simple or complex, and also this may >>>not be a showstopper for some people). >>>Even 9k MTU is very far from being universally accepted, >>>eight years after our Alteon spec went out :-). >> >>One other factor is TCP congestion control, and congestion >>windows we obey. Most of the time, you just can't send that much. > > > It's a bit painful to setup, but in general with 9k jumbos and TSO we were > able to get close to pci-x 133 limit - both in LAN and WAN tests. > Leonid Cool, but a very specific environment, no? ;) What concerns me about all this is that it seems so very host-centric design. Wouldn't it be nice if we had a little bit more network-centric worldview when designing network infrastructure? It isn't just a matter of how had we can push stuff out, it also matters how much the network can take. Blasting tens of gigs into the ether seems all very exciting sexy and cool, but suited for dedicated links or network attached storage channels, not general-purpose networking on the Internet or intra-nets. And if that is the case, we're talking about a much smaller market (but perhaps a more profitable one ;))... thanks, Nivedita From romieu@fr.zoreil.com Wed Sep 22 13:24:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:24:19 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKOCJW025751 for ; Wed, 22 Sep 2004 13:24:13 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8MKMSvr023602; Wed, 22 Sep 2004 22:22:28 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8MKMRpQ023601; Wed, 22 Sep 2004 22:22:27 +0200 Date: Wed, 22 Sep 2004 22:22:27 +0200 From: Francois Romieu To: Perolo Silantico Cc: Stephen Hemminger , john.ronciak@intel.com, ganesh.venkatesan@intel.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Message-ID: <20040922202227.GA23275@electric-eye.fr.zoreil.com> References: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 530 Lines: 17 Perolo Silantico : > Same behaviour for drivers: > - 8139too (kernel 2.6.8.1 and 2.6.8) > - e100 (kernel 2.6.8) > - eepro100 (kernel 2.6.8.1) > > I have tried with all these drivers. Therefore it seemed to me, that > this is not related to any specific driver. But to be sure, I will > grab a 3com 905C from another server and try with that one and will > try with the PCNet32 too. Can you give a try to 2.6.7 for the 8139 setup ? A dmesg from a working 2.4.x may help figure some difference. -- Ueimor From davem@davemloft.net Wed Sep 22 13:29:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:29:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKTFBi026159 for ; Wed, 22 Sep 2004 13:29:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CADiq-0004qm-00; Wed, 22 Sep 2004 13:28:16 -0700 Date: Wed, 22 Sep 2004 13:28:16 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922132816.1553292c.davem@davemloft.net> In-Reply-To: <20040922195515.GA2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 485 Lines: 12 On Wed, 22 Sep 2004 21:55:15 +0200 Andi Kleen wrote: > I must add that this is a CSA e1000 (directly integrated into > the chipset and doesn't use PCI) and TSO doesn't seem to be > bring any advantage. On 2.6.5 the performance is the same > with both TSO on or off. That's expected. It decreases the cpu and bus load, but if those are capable of running the card full tilt already TSO buys you nothing except spare cpu and memory cycles for other work on your system. From davem@davemloft.net Wed Sep 22 13:35:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:35:08 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKZ2ra026581 for ; Wed, 22 Sep 2004 13:35:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CADkh-0004r7-00; Wed, 22 Sep 2004 13:30:11 -0700 Date: Wed, 22 Sep 2004 13:30:11 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922133011.5885640b.davem@davemloft.net> In-Reply-To: <4151DB6C.8050906@us.ibm.com> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <4151DB6C.8050906@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 849 Lines: 24 On Wed, 22 Sep 2004 13:07:08 -0700 Nivedita Singhvi wrote: > Andi, was that with a netperf TCP stream test? I > would not have thought there would be no difference > prior to the changes DaveM made recently (now we > obey congestion window). We certainly got quite a bit > of a difference running SPECWeb etc, but that was on > the e1000s. A netperf single stream TCP test and something like SpecWEB are two different animals. The former rarely goes faster with TSO enabled simply because there is sufficient cpu and bus bandwidth to keep the card full. Whereas with something like SpecWEB the extra cpu and bus cycles are needed by other resources of the benchmark and thus performance goes up. I have no idea why people think TSO will make some single stream TCP test go faster, it doesn't buy you more bytes on the wire :-) From shemminger@osdl.org Wed Sep 22 13:38:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:38:45 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKcfRK026938 for ; Wed, 22 Sep 2004 13:38:41 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MKcNv13669; Wed, 22 Sep 2004 13:38:23 -0700 Date: Wed, 22 Sep 2004 13:38:23 -0700 From: Stephen Hemminger To: Jesse Brandeburg Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 1/2 2.6] e100: fix NAPI race with watchdog Message-Id: <20040922133823.50a66ef9@dell_ss3.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 577 Lines: 11 On Wed, 22 Sep 2004 12:25:44 -0700 (PDT) Jesse Brandeburg wrote: > While polling in NAPI mode, we were occassionally getting interrupts > re-enabled by the watchdog trying to generate a software interrupt. Fix > is to add a spinlock around that shared hardware register to allow a > read-modify-write operation. This was nasty nasty. I don't like the > spinlock in the hot path but i see no other way. Comments are welcome. > Updates the driver version as well. You could convert it to LLTX then at least there is only one lock roundtrip From davem@davemloft.net Wed Sep 22 13:40:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:40:26 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKeKDD027269 for ; Wed, 22 Sep 2004 13:40:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CADtK-0004se-00; Wed, 22 Sep 2004 13:39:06 -0700 Date: Wed, 22 Sep 2004 13:39:06 -0700 From: "David S. Miller" To: Andrew Grover Cc: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922133906.7d57ef49.davem@davemloft.net> In-Reply-To: References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1724 Lines: 46 On Wed, 22 Sep 2004 13:12:47 -0700 Andrew Grover wrote: > I think this is caused by the congestion changes added between > 2.6.9-rc1 and rc2. I am seeing good performance with rc1 and tso on > (or off), but bad performance with rc2 and bk-latest only if tso is > on. Yes, we know it is the packet counting change but those are pretty much necessary else TSO violates congestion window rules. There is a slight bug somewhere limiting performance, but we'll find it. The thing to watch if you're debugging this is what tp->packets_out is set to, and what happens in each tcp_snd_test() call. Also, watch tcp_cong_avoid() to make sure that tp->snd_cwnd is incrementing on every ACK and that tp->snd_cwnd_clamp is not some silly small value. Tracking tcp_snd_test() should tell you everything, watch what happens to the values of: tcp_packets_in_flight(tp); 'pkts' aka. TCP_SKB_CB(skb)->tso_factor after the possible tcp_set_skb_tso_factor() call tp->snd_cwnd One thing that could be biting us is the nagle check which probably needs to be adjusted to use the standard MSS not the TSO one... perhaps play with this patch: ===== include/net/tcp.h 1.88 vs edited ===== --- 1.88/include/net/tcp.h 2004-09-14 13:57:07 -07:00 +++ edited/include/net/tcp.h 2004-09-22 13:18:43 -07:00 @@ -1505,7 +1505,7 @@ * final FIN frame. -DaveM */ return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && + || !tcp_nagle_check(tp, skb, tp->mss_cache_std, nonagle)) && (((tcp_packets_in_flight(tp) + (pkts-1)) < tp->snd_cwnd) || (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); From niv@us.ibm.com Wed Sep 22 13:56:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 13:56:41 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MKuZ0P028051 for ; Wed, 22 Sep 2004 13:56:36 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i8MKuJWs193990; Wed, 22 Sep 2004 16:56:19 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8MKvV6D084566; Wed, 22 Sep 2004 16:57:32 -0400 Message-ID: <4151E6F1.7000405@us.ibm.com> Date: Wed, 22 Sep 2004 13:56:17 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <4151DB6C.8050906@us.ibm.com> <20040922133011.5885640b.davem@davemloft.net> In-Reply-To: <20040922133011.5885640b.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9322 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 849 Lines: 31 David S. Miller wrote: > The former rarely goes faster with TSO enabled simply > because there is sufficient cpu and bus bandwidth to > keep the card full. At about 700MHz (ok, old, I know) or thereabouts, it usually took > 1 CPU to drive a gigabit card, iirc, about 1.5 CPUs or so. > Whereas with something like SpecWEB the extra cpu and > bus cycles are needed by other resources of the benchmark > and thus performance goes up. Yep.. > I have no idea why people think TSO will make some single > stream TCP test go faster, it doesn't buy you more bytes > on the wire :-) True, if the card was already doing line speed, no, as you say, it won't help making the stack go faster :). If not, though, the gain in doing only one pass down the stack, one route look up, etc in place of multiple handoffs should help, correct? thanks, Nivedita From per.sil@gmx.it Wed Sep 22 14:03:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:03:58 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8ML3oPN028714 for ; Wed, 22 Sep 2004 14:03:51 -0700 Received: (qmail 28769 invoked by uid 65534); 22 Sep 2004 21:03:34 -0000 Received: from 83-64-102-174.dreihufeisengasse.xdsl-line.inode.at (EHLO nikic) (83.64.102.174) by mail.gmx.net (mp008) with SMTP; 22 Sep 2004 23:03:34 +0200 X-Authenticated: #4053160 From: "Perolo Silantico" To: "Stephen Hemminger" , , , , Cc: Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Date: Wed, 22 Sep 2004 23:03:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8ML3oPN028714 X-archive-position: 9323 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per.sil@gmx.it Precedence: bulk X-list: netdev Content-Length: 6762 Lines: 191 Dear Stephen Hemminger, OK, it seems you are right - it is a driver problem. I added the modules 3c59x and pcnet32 to the kernel (2.6.8.1) Transfer is fine with 3c59x (3Com 905B) and with pcnet32. The EtherExpress Pro 100 works perfectly on another server with kernel 2.4.23 (e100). Hence I retestet it on this machine. It works perfectly too, now. I rotated all the PCI cards between my testing machines to test various kernel/card combinations and connections. Noting wrong with eepro100 and 3c59x module on 2.6.8.1. During the hours of testing I must have overseen some mistake of mine with all these devices in the machine - I am very sorry :( Using the 8139too driver the interface freezes after some seconds of full bandwidth transfer. It seems to be a problem with this module. I'll try to close the bug - Now that the problem is pinned down to one device I need more testing to ensure this is not a hardware problem. This takes quite some time and I will file a new bug if the device is OK and the driver is the problem. I am very sorry that I have taken your time. Yours Perolo > -----Ursprungliche Nachricht----- > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Date: Mittwoch, 22. September 2004 18:27 > To: per.sil@gmx.it; john.ronciak@intel.com; ganesh.venkatesan@intel.com; > scott.feldman@intel.com > Cc: netdev@oss.sgi.com > Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: > transmit timed out " > > > This is an ethernet driver related problem. Which of the > ethernet cars (PCNet32 or E100) > is assigned to eth0? And which of the two e100 drivers (e100 or > eepro100) are you using? > > > On Tue, 21 Sep 2004 09:42:06 -0700 > bugme-daemon@osdl.org wrote: > > > http://bugme.osdl.org/show_bug.cgi?id=3440 > > > > Summary: eth0 freezes: "NETDEV WATCHDOG: eth0: > transmit timed out > > " > > Kernel Version: 2.6.8.1 > > Status: NEW > > Severity: high > > Owner: shemminger@osdl.org > > Submitter: per.sil@gmx.it > > > > > > Hi kernel developers, > > > > There exists a severe problem with a linux box of my own. The > problem does not > > occur when using kernel 2.4.25 on the same machine. I need your help. > > > > Distribution: > > ------------- > > Gentoo Linux 1.4 (2004.2), recompiled whole system with kernel > 2.6 and NPTL. > > > > Hardware Environment: > > --------------------- > > - IBM PC Server 325, Dual Pentium Pro 180MHz, 256MB RAM, > > - 3ware Controller 6410 with RAID 1+0, > > - PCNet32 10MBit on-board card > > - Intel EtherExpress Pro 100 > > - RTL 8139 Card. > > - 2x AVM ISDN B1 active ISA cards (Rev. 2.0 and Rev. 3.0 cards) > > > > Tried with both cards, and tried both manually set to half-duplex or > > full-duplex. tried same kernel with ISDN cards removed (but > modules still > > compiled in) > > > > I removed one processor using same SMP-enabled kernel on single > processor system > > - problem persists. > > > > The box is connected to a DLink DGS-1008D GigaBit switch and I > tried with a > > D-Link DES 1026G switch. > > > > > > The source of the transfer is a HP Netserver Dual Pentium III > 600MHz with kernel > > 2.4.23_pre8 SMP and same openSSH version, connected to the same switch. > > > > > > Software Environment: > > --------------------- > > "vanilla" kernel 2.6.8.1 on Gentoo Linux (see dmesg output and > config file) > > IPv6 compiled in but deactivated with > > ifconfig eth1 inet6 del ... > > > > same problem with kernel 2.6.7 and 2.6.8 using same kernel > configuration. > > > > gcc-3.3.4 > > glibc-2.3.4.20040808 > > OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 > > > > (for installed system utils, see attached file) > > > > Problem Description: > > --------------------- > > > > When transfering some data (approx. 3 GB in size) from one > amchine on the LAN to > > this box the transmission hangs on the interface after some > seconds (20MBs) and > > a "time out" occures. Then the LAN connection freezes, is > terminated and the > > linux box is not reachable from the network anymore. After some > minutes the > > connection recoveres again. > > > > The network transmission times out and the ethernet driver is > not responding to > > any LAN traffic (not even to any ICMP echo request). kernel log > message tells: > > > > NETDEV WATCHDOG: eth0: transmit timed out > > eth0: Tx descriptor 0 is 0008a072. > > > > (off course: address of descriptor varies) > > After approx. 4 minutes, the LAN connection of the box recovers > and you can > > connect to the box again. (until next transfer is started) > > > > transfer issued by another host: > > ................................ > > Usually a transfer host consumes all interface bandwidth > available (100 MBit LAN > > with full-duplex cards on both involved machines gives at least > 1.6 MByte/s if > > SCP overhead is taken into consideration). the connection stays > alive if it > > limited to smaller bandwith with fe. 100 Kbit (~ 12.5 KBytes) > "scp -l 100 ...". > > But using 1000 KBit (~125 KByte) "scp -l 1000 ..." the > connection is freezing > > although maximum bandwidth is not reached. > > > > transfer issued by host itself: > > ................................ > > If the box issues a transfer from the internet using 235 > KBytes/s (~ 2MBits/s) > > everything works out fine. If the box issues the transfer from > the LAN with full > > bandwith of 1.8 MBytes/s then the LAN connection is freezing too. > > > > > > If I turn of window scaling with "echo 0 > > > /proc/sys/net/ipv4/tcp_window_scaling" then the time needed to > recover the > > interface seems to decrease. The SCP transfer still freezes but > LAN timeout of > > the box is small enough to keep SSH connection alive. > > > > it did not help to set the following, as suggested by other web pages: > > tcp_default_win_scale=0 > > tcp_moderate_rcvbuf=0 > > > > > > Steps to reproduce: > > ------------------- > > start any SCP/SFTP transfer to the linux box with kernel > 2.6.8.1 - always > > reproducable on my box. I do not know about others since this > is my first box > > with kernel 2.6.x > > > > > > > > If you need more information or testing, please let me know. I > will not change > > the configuration of the box for some time to be able to > fullfill your requests, > > hoping to help solving the problem. > > > > > > Yours > > Perolo > > > > PS: Dear maintainer, I am able to grant you access to the > computer if this will > > help you. please contact me if this is vital for solving the problem. > > > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > From shemminger@osdl.org Wed Sep 22 14:12:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:12:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MLCMAc029289 for ; Wed, 22 Sep 2004 14:12:22 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MLBwv20454; Wed, 22 Sep 2004 14:11:58 -0700 Date: Wed, 22 Sep 2004 14:11:58 -0700 From: Stephen Hemminger To: Robert Olsson , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] pktgen - handle NETDEV_TX_LOCKED Message-Id: <20040922141158.3a16416c@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1318 Lines: 53 Change pktgen to handle drivers that return TX_LOCKED better. This isn't a real busy state so just spin. Signed-off-by: Stephen Hemminger diff -Nru a/net/core/pktgen.c b/net/core/pktgen.c --- a/net/core/pktgen.c 2004-09-22 14:13:45 -07:00 +++ b/net/core/pktgen.c 2004-09-22 14:13:45 -07:00 @@ -587,11 +587,12 @@ static void inject(struct pktgen_info* info) { - struct net_device *odev = NULL; + struct net_device *odev; struct sk_buff *skb = NULL; __u64 total = 0; __u64 idle = 0; __u64 lcount = 0; + int ret; int nr_frags = 0; int last_ok = 1; /* Was last skb sent? * Or a failed transmit of some sort? This will keep @@ -640,19 +641,23 @@ atomic_inc(&skb->users); - if (odev->hard_start_xmit(skb, odev)) { - + retry: + ret = odev->hard_start_xmit(skb, odev); + if (likely(ret == NETDEV_TX_OK)) { + last_ok = 1; + info->sofar++; + info->seq_num++; + } else if (ret == NETDEV_TX_LOCKED + && (odev->features & NETIF_F_LLTX)) { + cpu_relax(); + goto retry; + } else { atomic_dec(&skb->users); if (net_ratelimit()) { printk(KERN_INFO "Hard xmit error\n"); } info->errors++; last_ok = 0; - } - else { - last_ok = 1; - info->sofar++; - info->seq_num++; } } else { From shemminger@osdl.org Wed Sep 22 14:19:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:19:46 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MLJet8029758 for ; Wed, 22 Sep 2004 14:19:40 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MLJMv21956; Wed, 22 Sep 2004 14:19:22 -0700 Date: Wed, 22 Sep 2004 14:19:22 -0700 From: Stephen Hemminger To: "Perolo Silantico" Cc: netdev@oss.sgi.com Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Message-Id: <20040922141922.41bb9288@dell_ss3.pdx.osdl.net> In-Reply-To: References: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1522 Lines: 19 On Wed, 22 Sep 2004 23:03:32 +0200 "Perolo Silantico" wrote: > Dear Stephen Hemminger, > > OK, it seems you are right - it is a driver problem. > I added the modules 3c59x and pcnet32 to the kernel (2.6.8.1) > Transfer is fine with 3c59x (3Com 905B) and with pcnet32. > The EtherExpress Pro 100 works perfectly on another server with kernel 2.4.23 (e100). Hence I retestet it on this machine. It works perfectly too, now. I rotated all the PCI cards between my testing machines to test various kernel/card combinations and connections. Noting wrong with eepro100 and 3c59x module on 2.6.8.1. > > During the hours of testing I must have overseen some mistake of mine with all these devices in the machine - I am very sorry :( > > Using the 8139too driver the interface freezes after some seconds of full bandwidth transfer. It seems to be a problem with this module. I'll try to close the bug - Now that the problem is pinned down to one device I need more testing to ensure this is not a hardware problem. This takes quite some time and I will file a new bug if the device is OK and the driver is the problem. On some systems the 8139too card interrupt is configured as edge (not level triggered) and this can cause the problem because in 2.6 version of the driver it uses NAPI to avoid doing lots of work in interrupt context. For NAPI to work properly, the interrupt needs to be level triggered to avoid races. Check the BIOS settings, it may be possible to change the interrupt behaviour there. From shemminger@osdl.org Wed Sep 22 14:23:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:23:38 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MLNWWb030111 for ; Wed, 22 Sep 2004 14:23:32 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MLN1v22851; Wed, 22 Sep 2004 14:23:01 -0700 Date: Wed, 22 Sep 2004 14:23:01 -0700 From: Stephen Hemminger To: Robert Olsson , "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] pktgen - output formatting Message-Id: <20040922142301.6618c24d@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3301 Lines: 112 This changes how the results of pktgen are computed. * use do_div to get 64 by 32 divide, scale as needed to handle really long runs where total us > 2^32. * communication data rates are supposed to be reported as 1Meg = 1000000 * split long line. Signed-off-by: Stephen Hemminger diff -Nru a/net/core/pktgen.c b/net/core/pktgen.c --- a/net/core/pktgen.c 2004-09-22 14:24:02 -07:00 +++ b/net/core/pktgen.c 2004-09-22 14:24:02 -07:00 @@ -584,16 +584,48 @@ return skb; } +static void show_results(struct pktgen_info* info, int nr_frags) +{ + __u64 total, bps, mbps, pps; + unsigned long idle; + int size = info->pkt_size + 4; /* incl 32bit ethernet CRC */ + char *p = info->result; + + total = (info->stopped_at.tv_sec - info->started_at.tv_sec) * 1000000ull + + info->stopped_at.tv_usec - info->started_at.tv_usec; + + BUG_ON(cpu_speed == 0); + + idle = info->idle_acc; + do_div(idle, cpu_speed); + + p += sprintf(p, "OK: %llu(c%llu+d%lu) usec, %llu (%dbyte,%dfrags)\n", + total, total - idle, idle, + info->sofar, size, nr_frags); + + pps = info->sofar * USEC_PER_SEC; + + while ((total >> 32) != 0) { + pps >>= 1; + total >>= 1; + } + + do_div(pps, total); + + bps = pps * 8 * size; + + mbps = bps; + do_div(mbps, 1000000); + p += sprintf(p, " %llupps %lluMb/sec (%llubps) errors: %llu", + pps, mbps, bps, info->errors); +} static void inject(struct pktgen_info* info) { struct net_device *odev; struct sk_buff *skb = NULL; - __u64 total = 0; - __u64 idle = 0; __u64 lcount = 0; int ret; - int nr_frags = 0; int last_ok = 1; /* Was last skb sent? * Or a failed transmit of some sort? This will keep * sequence numbers in order, for example. @@ -633,8 +665,6 @@ } } - nr_frags = skb_shinfo(skb)->nr_frags; - if (!(odev->features & NETIF_F_LLTX)) spin_lock_bh(&odev->xmit_lock); if (!netif_queue_stopped(odev)) { @@ -730,38 +760,7 @@ do_gettimeofday(&(info->stopped_at)); - total = (info->stopped_at.tv_sec - info->started_at.tv_sec) * 1000000 + - info->stopped_at.tv_usec - info->started_at.tv_usec; - - idle = (__u32)(info->idle_acc)/(__u32)(cpu_speed); - - { - char *p = info->result; - __u64 bps, pps = 0; - - if (total > 1000) - pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); - else if(total > 100) - pps = (__u32)(info->sofar * 10000) / ((__u32)(total) / 100); - else if(total > 10) - pps = (__u32)(info->sofar * 100000) / ((__u32)(total) / 10); - else if(total > 1) - pps = (__u32)(info->sofar * 1000000) / (__u32)total; - - bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */ - p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps) errors: %llu", - (unsigned long long) total, - (unsigned long long) (total - idle), - (unsigned long long) idle, - (unsigned long long) info->sofar, - skb->len + 4, /* Add 4 to account for the ethernet checksum */ - nr_frags, - (unsigned long long) pps, - (unsigned long long) (bps / (u64) 1024 / (u64) 1024), - (unsigned long long) bps, - (unsigned long long) info->errors - ); - } + show_results(info, skb_shinfo(skb)->nr_frags); kfree_skb(skb); From jchapman@katalix.com Wed Sep 22 14:29:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:29:16 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MLTASb030633 for ; Wed, 22 Sep 2004 14:29:10 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1CAEfW-0001wt-3V; Wed, 22 Sep 2004 16:28:54 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Wed, 22 Sep 2004 22:28:53 +0100 Message-ID: <1095888533.4151ee95ed23c@www.katalix.com> Date: Wed, 22 Sep 2004 22:28:53 +0100 From: James Chapman To: Herbert Xu Cc: bcrl@kvack.org, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 4095 Lines: 91 Hi Herbert, Quoting Herbert Xu : > James Chapman wrote: > > > > The biggest difference in our approaches is that Martijn and I use a > > PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel > > socket while Ben uses a new AF_L2TP tunnel socket and no separate > > socket per session. Both have their merits. > > Can you elaborate on the merits of having a socket? It would seem to me > that not having a socket is a lot more scalable. After all IPsec doesn't > carry a socket around per session. What I meant by "both have their merits" is that both general approaches have their merits. It's a shame Martijn isn't available right now (he's moving home to a new country) as he came up with the initial kernel driver concept. Anyway, I'm sure he'll chime in later. We could have implemented this thing by hooking specific UDP ports out in udp.c or adding to the UDP encap framework that you use for IPsec. Neither seem ideal for this case -- modifying core code in udp.c to add support for a new UDP protocol just seemed wrong. IPsec is special -- it is a core technology that the IP stack should know about. L2TP isn't special at all. There are several reasons why I think the approach taken is a reasonable compromise:- - No changes to core kernel code needed. The new L2TP support can be loaded as a module into current 2.4 and 2.6 Linux distributions. - It fits well into the existing PPPoX framework. This is, after all, PPP over L2TP. - Implementing a new socket address family for the tunnel socket instead of using a plain UDP socket meant cloning a lot of UDP code. We thought it might break IPsec assumptions and having code that did almost the same thing as other components of the kernel was not ideal. It also seemed to set the wrong precedent for adding a new UDP protocol. - Having PPP create a socket and bind it to the L2TP tunnel UDP socket gave us all the packet hooks we needed to implement the L2TP datapath. And using a per-session socket made it trivial to add control and status APIs for userspace. Also, for handling L2TP (optional) data packet reordering, the socket buffer would help when holding packets for their predecessors, preventing one bad session from breaking others in the tunnel. - For VPN usage scenarios where 50 or so L2TP sessions would be unusually large, the extra socket overhead didn't seem to matter that much when weighed up against all its advantages. Since in the VPN case, PPP sessions are locally terminated, there's also a net_device per session. Are we going to get rid of that too? We keep coming back to the scalability issue. Sure this driver wouldn't work when handling thousands of sessions, but I just don't think it's an issue in the VPN case. People will be nailing up their VPNs directly with hardware-assisted IPsec or even MPLS well before we hear users complaining that they want Linux's L2TP to support thousands of sessions for VPN use. Please don't get me wrong, I'm not saying that scalability doesn't matter. But I do think we're getting hung up on the need to support thousands of L2TP sessions carrying non-terminated PPP sessions as a typical Linux use case. Linux systems, especially those built from the core kernel source distribution, are much more likely to be using L2TP for VPNs, terminating PPP locally. There are many problems to solve first in order to handle thousands of sessions before our proposed driver's limitations become an issue, i.e. single daemon pppd and how to handle each PPP interface without a net_device. Ben's Babylon-based solution does this but it won't solve the VPN problem. I really want to see an end to those userspace pty pppd hacks being used by current L2TP, PPTP and PPPoE solutions. I think the proposed driver solves that problem well for L2TP and because it can be installed in current Linux installations with little effort (as a module), it stands a reasonable chance. I'll shut up now, I've gone on long enough. Thanks for reading this far! :) /james From Robert.Olsson@data.slu.se Wed Sep 22 14:57:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:57:42 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MLvZvw031584 for ; Wed, 22 Sep 2004 14:57:36 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8MLvKY2024409; Wed, 22 Sep 2004 23:57:20 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 62CA190265; Wed, 22 Sep 2004 23:57:20 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16721.62784.358708.572905@robur.slu.se> Date: Wed, 22 Sep 2004 23:57:20 +0200 To: Stephen Hemminger Cc: Robert Olsson , "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] pktgen - output formatting In-Reply-To: <20040922142301.6618c24d@dell_ss3.pdx.osdl.net> References: <20040922142301.6618c24d@dell_ss3.pdx.osdl.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 3841 Lines: 121 Thanks Stephen! Seems sane but I've not tested. If do_div is now sane on all arch it should be used and 1024 vs 1000 is always "wrong" Time to give up hacking here. --ro Stephen Hemminger writes: > This changes how the results of pktgen are computed. > * use do_div to get 64 by 32 divide, scale as needed to handle really long > runs where total us > 2^32. > * communication data rates are supposed to be reported as 1Meg = 1000000 > * split long line. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/net/core/pktgen.c b/net/core/pktgen.c > --- a/net/core/pktgen.c 2004-09-22 14:24:02 -07:00 > +++ b/net/core/pktgen.c 2004-09-22 14:24:02 -07:00 > @@ -584,16 +584,48 @@ > return skb; > } > > +static void show_results(struct pktgen_info* info, int nr_frags) > +{ > + __u64 total, bps, mbps, pps; > + unsigned long idle; > + int size = info->pkt_size + 4; /* incl 32bit ethernet CRC */ > + char *p = info->result; > + > + total = (info->stopped_at.tv_sec - info->started_at.tv_sec) * 1000000ull > + + info->stopped_at.tv_usec - info->started_at.tv_usec; > + > + BUG_ON(cpu_speed == 0); > + > + idle = info->idle_acc; > + do_div(idle, cpu_speed); > + > + p += sprintf(p, "OK: %llu(c%llu+d%lu) usec, %llu (%dbyte,%dfrags)\n", > + total, total - idle, idle, > + info->sofar, size, nr_frags); > + > + pps = info->sofar * USEC_PER_SEC; > + > + while ((total >> 32) != 0) { > + pps >>= 1; > + total >>= 1; > + } > + > + do_div(pps, total); > + > + bps = pps * 8 * size; > + > + mbps = bps; > + do_div(mbps, 1000000); > + p += sprintf(p, " %llupps %lluMb/sec (%llubps) errors: %llu", > + pps, mbps, bps, info->errors); > +} > > static void inject(struct pktgen_info* info) > { > struct net_device *odev; > struct sk_buff *skb = NULL; > - __u64 total = 0; > - __u64 idle = 0; > __u64 lcount = 0; > int ret; > - int nr_frags = 0; > int last_ok = 1; /* Was last skb sent? > * Or a failed transmit of some sort? This will keep > * sequence numbers in order, for example. > @@ -633,8 +665,6 @@ > } > } > > - nr_frags = skb_shinfo(skb)->nr_frags; > - > if (!(odev->features & NETIF_F_LLTX)) > spin_lock_bh(&odev->xmit_lock); > if (!netif_queue_stopped(odev)) { > @@ -730,38 +760,7 @@ > > do_gettimeofday(&(info->stopped_at)); > > - total = (info->stopped_at.tv_sec - info->started_at.tv_sec) * 1000000 + > - info->stopped_at.tv_usec - info->started_at.tv_usec; > - > - idle = (__u32)(info->idle_acc)/(__u32)(cpu_speed); > - > - { > - char *p = info->result; > - __u64 bps, pps = 0; > - > - if (total > 1000) > - pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); > - else if(total > 100) > - pps = (__u32)(info->sofar * 10000) / ((__u32)(total) / 100); > - else if(total > 10) > - pps = (__u32)(info->sofar * 100000) / ((__u32)(total) / 10); > - else if(total > 1) > - pps = (__u32)(info->sofar * 1000000) / (__u32)total; > - > - bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */ > - p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps) errors: %llu", > - (unsigned long long) total, > - (unsigned long long) (total - idle), > - (unsigned long long) idle, > - (unsigned long long) info->sofar, > - skb->len + 4, /* Add 4 to account for the ethernet checksum */ > - nr_frags, > - (unsigned long long) pps, > - (unsigned long long) (bps / (u64) 1024 / (u64) 1024), > - (unsigned long long) bps, > - (unsigned long long) info->errors > - ); > - } > + show_results(info, skb_shinfo(skb)->nr_frags); > > kfree_skb(skb); > From ak@suse.de Wed Sep 22 14:57:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 14:57:27 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MLvFGA031546 for ; Wed, 22 Sep 2004 14:57:17 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 48784C50E82; Wed, 22 Sep 2004 23:56:59 +0200 (CEST) Date: Wed, 22 Sep 2004 23:56:57 +0200 From: Andi Kleen To: "David S. Miller" Cc: Nivedita Singhvi , ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040922215657.GB2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <4151DB6C.8050906@us.ibm.com> <20040922133011.5885640b.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922133011.5885640b.davem@davemloft.net> X-archive-position: 9328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 295 Lines: 11 > I have no idea why people think TSO will make some single > stream TCP test go faster, it doesn't buy you more bytes > on the wire :-) It definitely helps on 10GB/s - without it the maximum for single stream is slower. I suspect with a slow bus you can also see advantages on 1Gb/s. -Andi From davem@davemloft.net Wed Sep 22 15:05:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 15:05:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MM5P72032673 for ; Wed, 22 Sep 2004 15:05:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAFDt-0005Fv-00; Wed, 22 Sep 2004 15:04:25 -0700 Date: Wed, 22 Sep 2004 15:04:25 -0700 From: "David S. Miller" To: Andi Kleen Cc: niv@us.ibm.com, ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922150425.78839350.davem@davemloft.net> In-Reply-To: <20040922215657.GB2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <4151DB6C.8050906@us.ibm.com> <20040922133011.5885640b.davem@davemloft.net> <20040922215657.GB2619@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 271 Lines: 12 On Wed, 22 Sep 2004 23:56:57 +0200 Andi Kleen wrote: > I suspect with a slow bus you can also see advantages > on 1Gb/s. Yes, that's true. I can keep a gigabit line full on my slow 350MHZ sparc64 boxes except when the card is in a 33Mhz/32-bit PCI slot. From herbert@gondor.apana.org.au Wed Sep 22 15:06:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 15:06:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MM6Fq6000419 for ; Wed, 22 Sep 2004 15:06:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAFFA-0004f4-00; Thu, 23 Sep 2004 08:05:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAFF1-00076S-00; Thu, 23 Sep 2004 08:05:35 +1000 From: Herbert Xu To: jchapman@katalix.com (James Chapman) Subject: Re: PPP-over-L2TP kernel support, new patch for review Cc: herbert@gondor.apana.org.au, bcrl@kvack.org, davem@davemloft.net, netdev@oss.sgi.com, kleptog@svana.org, mostrows@styx.uwaterloo.ca Organization: Core In-Reply-To: <1095888533.4151ee95ed23c@www.katalix.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 23 Sep 2004 08:05:35 +1000 X-archive-position: 9331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 755 Lines: 19 James Chapman wrote: > > We keep coming back to the scalability issue. Sure this driver > wouldn't work when handling thousands of sessions, but I just don't > think it's an issue in the VPN case. People will be nailing up their That's where I disagree. We don't want to end up with two L2TP implementations in the kernel, one geared towards large installations and one geared towards IPsec setups. So I think both Ben and James need to work out how they can best absorb the advantages of each other's stack. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@suse.de Wed Sep 22 15:09:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 15:09:49 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MM9iW4001250 for ; Wed, 22 Sep 2004 15:09:44 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id E34CAC4DA87; Thu, 23 Sep 2004 00:06:28 +0200 (CEST) Date: Thu, 23 Sep 2004 00:06:28 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andrew Grover , ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040922220628.GC2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <20040922133906.7d57ef49.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922133906.7d57ef49.davem@davemloft.net> X-archive-position: 9332 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 835 Lines: 24 > One thing that could be biting us is the nagle check which > probably needs to be adjusted to use the standard MSS not > the TSO one... perhaps play with this patch: I tried it and it breaks the performance completely (21MB/s) -Andi > > ===== include/net/tcp.h 1.88 vs edited ===== > --- 1.88/include/net/tcp.h 2004-09-14 13:57:07 -07:00 > +++ edited/include/net/tcp.h 2004-09-22 13:18:43 -07:00 > @@ -1505,7 +1505,7 @@ > * final FIN frame. -DaveM > */ > return (((nonagle&TCP_NAGLE_PUSH) || tp->urg_mode > - || !tcp_nagle_check(tp, skb, cur_mss, nonagle)) && > + || !tcp_nagle_check(tp, skb, tp->mss_cache_std, nonagle)) && > (((tcp_packets_in_flight(tp) + (pkts-1)) < tp->snd_cwnd) || > (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) && > !after(TCP_SKB_CB(skb)->end_seq, tp->snd_una + tp->snd_wnd)); > > From davem@davemloft.net Wed Sep 22 15:27:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 15:27:06 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MMR1cn002443 for ; Wed, 22 Sep 2004 15:27:01 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAFYO-0005He-00; Wed, 22 Sep 2004 15:25:36 -0700 Date: Wed, 22 Sep 2004 15:25:35 -0700 From: "David S. Miller" To: Andi Kleen Cc: andy.grover@gmail.com, ak@suse.de, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922152535.7bc81c8a.davem@davemloft.net> In-Reply-To: <20040922220628.GC2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <20040922133906.7d57ef49.davem@davemloft.net> <20040922220628.GC2619@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 372 Lines: 11 On Thu, 23 Sep 2004 00:06:28 +0200 Andi Kleen wrote: > > One thing that could be biting us is the nagle check which > > probably needs to be adjusted to use the standard MSS not > > the TSO one... perhaps play with this patch: > > I tried it and it breaks the performance completely > (21MB/s) You said you were getting 22MB/sec before the change, right? From ak@suse.de Wed Sep 22 15:47:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 15:47:54 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MMlnWc003378 for ; Wed, 22 Sep 2004 15:47:49 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0ED27C4FF3F; Thu, 23 Sep 2004 00:47:33 +0200 (CEST) Date: Thu, 23 Sep 2004 00:47:32 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040922224732.GD2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <20040922133906.7d57ef49.davem@davemloft.net> <20040922220628.GC2619@wotan.suse.de> <20040922152535.7bc81c8a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040922152535.7bc81c8a.davem@davemloft.net> X-archive-position: 9334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 555 Lines: 17 On Wed, Sep 22, 2004 at 03:25:35PM -0700, David S. Miller wrote: > On Thu, 23 Sep 2004 00:06:28 +0200 > Andi Kleen wrote: > > > > One thing that could be biting us is the nagle check which > > > probably needs to be adjusted to use the standard MSS not > > > the TSO one... perhaps play with this patch: > > > > I tried it and it breaks the performance completely > > (21MB/s) > > You said you were getting 22MB/sec before the change, right? 22-23MB/s, but not 21MB/s. Ok "breaks completely" was a bit of overstatement, admitted. -Andi From davem@davemloft.net Wed Sep 22 15:51:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 15:51:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MMpUUe003712 for ; Wed, 22 Sep 2004 15:51:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAFwW-0005JW-00; Wed, 22 Sep 2004 15:50:32 -0700 Date: Wed, 22 Sep 2004 15:50:31 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040922155031.7068468d.davem@davemloft.net> In-Reply-To: <20040922224732.GD2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <20040922133906.7d57ef49.davem@davemloft.net> <20040922220628.GC2619@wotan.suse.de> <20040922152535.7bc81c8a.davem@davemloft.net> <20040922224732.GD2619@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 331 Lines: 12 On Thu, 23 Sep 2004 00:47:32 +0200 Andi Kleen wrote: > 22-23MB/s, but not 21MB/s. Ok "breaks completely" was a bit of overstatement, > admitted. Right. Can you do some of the tcp_snd_test() debugging I suggested above the patch you just tested? I really need help debugging this as I cannot reproduce it locally. From shemminger@osdl.org Wed Sep 22 16:05:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 16:05:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MN5pZm004328 for ; Wed, 22 Sep 2004 16:05:52 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8MN5Xv11088; Wed, 22 Sep 2004 16:05:33 -0700 Date: Wed, 22 Sep 2004 16:05:33 -0700 From: Stephen Hemminger To: Jeb Cramer , John Ronciak , Ganesh Venkatesan Cc: netdev@oss.sgi.com Subject: [PATCH] e1000 - avoid filling tx ring completely. Message-Id: <20040922160533.64f25d12@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1552 Lines: 35 With the current driver and the default transmit ring size, it is easy to get the ring to fill. When this happens the way the current e1000 driver responds is to return TX_BUSY. This works but is sub-optimal and requires the network scheduler to requeue the packet. The following patch adds a test to see if there is space left in the ring, and stops the network queue just before it fills. When the tx intr (or cleanup via NAPI) occurs, then the queue is re-enabled. There is a tradeoff here, the check causes the last 11 elements in the ring to not be used but avoids an unnecessary send/requeue. Signed-off-by: Stephen Hemminger --- netdev-2.6/drivers/net/e1000/e1000_main.c 2004-09-22 14:53:16.492728880 -0700 +++ test-2.6/drivers/net/e1000/e1000_main.c 2004-09-22 14:55:09.780506520 -0700 @@ -1811,7 +1811,7 @@ e1000_xmit_frame(struct sk_buff *skb, st /* need: count + 2 desc gap to keep tail from touching * head, otherwise try next time */ - if(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2) { + if(unlikely(E1000_DESC_UNUSED(&adapter->tx_ring) < count + 2)) { netif_stop_queue(netdev); spin_unlock_irqrestore(&adapter->tx_lock, flags); return NETDEV_TX_BUSY; @@ -1844,6 +1844,10 @@ e1000_xmit_frame(struct sk_buff *skb, st netdev->trans_start = jiffies; + /* Make sure there is space in the ring for the next send. */ + if (E1000_DESC_UNUSED(&adapter->tx_ring) < MAX_SKB_FRAGS + 2) + netif_stop_queue(netdev); + spin_unlock_irqrestore(&adapter->tx_lock, flags); return NETDEV_TX_OK; } From edmudama@gmail.com Wed Sep 22 16:25:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 16:26:02 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8MNPtgx008117 for ; Wed, 22 Sep 2004 16:25:56 -0700 Received: by mproxy.gmail.com with SMTP id 79so2135674rnk for ; Wed, 22 Sep 2004 16:25:39 -0700 (PDT) Received: by 10.38.82.75 with SMTP id f75mr4418573rnb; Wed, 22 Sep 2004 16:25:38 -0700 (PDT) Received: by 10.38.70.42 with HTTP; Wed, 22 Sep 2004 16:25:38 -0700 (PDT) Message-ID: <311601c904092216257bfd5752@mail.gmail.com> Date: Wed, 22 Sep 2004 17:25:38 -0600 From: Eric Mudama Reply-To: Eric Mudama To: "valdis.kletnieks@vt.edu" Subject: Re: The ultimate TOE design Cc: David Stevens , Netdev , leonid.grossman@s2io.com, Linux Kernel In-Reply-To: <200409172027.i8HKRVwY005444@turing-police.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4148991B.9050200@pobox.com> <311601c90409162346184649eb@mail.gmail.com> <200409172027.i8HKRVwY005444@turing-police.cc.vt.edu> X-archive-position: 9337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: edmudama@gmail.com Precedence: bulk X-list: netdev Content-Length: 439 Lines: 10 On Fri, 17 Sep 2004 16:27:31 -0400, valdis.kletnieks@vt.edu wrote: > No, he means "offload the processing of the filesystem to the disk itself". I know what was meant. I'm not saying the filesystem on the drive is very advanced, but it's still a filesystem. Our "Record ID" is the LBA identifier, and all records are 1 block in size. We can handle defects, reallocations, and other issues, with some success. From sriharivijayaraghavan@yahoo.com.au Wed Sep 22 16:55:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 16:55:57 -0700 (PDT) Received: from smtp202.mail.sc5.yahoo.com (smtp202.mail.sc5.yahoo.com [216.136.129.92]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8MNtrmT008890 for ; Wed, 22 Sep 2004 16:55:53 -0700 Received: from unknown (HELO ?192.168.0.2?) (sriharivijayaraghavan@150.101.154.2 with plain) by smtp202.mail.sc5.yahoo.com with SMTP; 22 Sep 2004 23:55:42 -0000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: r8169 - panic and a fix Date: Thu, 23 Sep 2004 10:03:17 +1000 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: <200409082224.23829.sriharivijayaraghavan@yahoo.com.au> <200409121832.57233.sriharivijayaraghavan@yahoo.com.au> <20040912231516.GA27299@electric-eye.fr.zoreil.com> In-Reply-To: <20040912231516.GA27299@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409231003.17255.sriharivijayaraghavan@yahoo.com.au> X-archive-position: 9338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sriharivijayaraghavan@yahoo.com.au Precedence: bulk X-list: netdev Content-Length: 116 Lines: 5 I see your patch for r8169 in Linus' bk tree. I have tried 2.6.9-rc2-bk8, and it works just fine. Thank you. Hari From wsonguci@yahoo.com Wed Sep 22 17:29:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 17:29:28 -0700 (PDT) Received: from web40007.mail.yahoo.com (web40007.mail.yahoo.com [66.218.78.25]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8N0TMxj009860 for ; Wed, 22 Sep 2004 17:29:22 -0700 Message-ID: <20040923002906.60244.qmail@web40007.mail.yahoo.com> Received: from [63.87.1.243] by web40007.mail.yahoo.com via HTTP; Wed, 22 Sep 2004 17:29:06 PDT Date: Wed, 22 Sep 2004 17:29:06 -0700 (PDT) From: Song Wang Subject: Re: [Routing] Performance Comparison between 2.6 and 2.4 kernel To: hadi@cyberus.ca, "David S. Miller" Cc: netdev@oss.sgi.com In-Reply-To: <1095334258.1065.158.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wsonguci@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1099 Lines: 47 > > > > Although I would very much anticipate this being > > a MIPS or network adapter specific problem since > > on x86 routing is pretty fast in 2.6.x > > Note, I could hit 4-500Kpps on a bcom sb1250 800Mhz; > trying to simulate > Andis gettimeofday changes (which are in 2.6 since i > havent seen a 2.6 > port for that board ) gives another 100Kpps. Theres > still room for > improvement just havent had time. > You are right though it could be a 2.6.x arch > specific issue. Bacchus? > > cheers, > jamal > > Hi Jamal and Dave, I continued to do some testing in a minimal environment, basically the routing between the two ethernet ports on the mips board. Only ethernet driver is loaded. The user-space only has busybox. The difference between 2.6.8.1 and 2.4.17 kernel is 3000pps less for routing. However, the bridging performance is the same between two kernels. Jamal, where is the Andis gettimeofday changes you mentioned? Thanks. -Song __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From margitsw@t-online.de Wed Sep 22 20:25:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 20:25:23 -0700 (PDT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N3P6Fh018088 for ; Wed, 22 Sep 2004 20:25:09 -0700 Received: from fwd01.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1CAKDf-0000Pr-00; Thu, 23 Sep 2004 05:24:31 +0200 Received: from margit.t-online.de (VrK9NaZLZewXRhTBs-eFjHh5JcrprQXaOA2BfG9wgxOX2YjzQl1a6D@[217.255.119.136]) by fwd01.sul.t-online.com with esmtp id 1CAKDb-1Xlh3Y0; Thu, 23 Sep 2004 05:24:27 +0200 Message-Id: <5.1.0.14.2.20040923050120.0257f490@pop.t-online.de> X-Sender: margitsw@pop.t-online.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 Sep 2004 05:24:33 +0200 To: Nishanth Aravamudan From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: msleep changes Cc: davem@davemloft.net, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ID: VrK9NaZLZewXRhTBs-eFjHh5JcrprQXaOA2BfG9wgxOX2YjzQl1a6D X-TOI-MSGID: 61580466-9266-448c-8df1-e8231b3c70fe X-archive-position: 9340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 682 Lines: 30 Hi Nish, In latest BK : # drivers/atm/lanai.c # 2004/09/21 14:58:17-07:00 chas@cmf.nrl.navy.mil +1 -1 # [ATM]: [drivers] Use msleep() instead of schedule_timeout() # From Nishanth Aravamudan diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2004-09-21 17:11:30 -07:00 +++ b/drivers/atm/lanai.c 2004-09-21 17:11:30 -07:00 @@ -813,7 +813,7 @@ DPRINTK("read, write = %d, %d\n", read, write); break; } - schedule_timeout(HZ / 25); + msleep(4); ?????? Just one that immediately lept to my eye. I am not going to check them all. That's your job :-) These msleep(_interruptible) changes have been tested or ? Margit From kaber@trash.net Wed Sep 22 21:11:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 21:11:23 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N4BCiH019478 for ; Wed, 22 Sep 2004 21:11:14 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1CAL2k-0002T6-00; Thu, 23 Sep 2004 06:17:18 +0200 Message-ID: <41524CC8.1070104@trash.net> Date: Thu, 23 Sep 2004 06:10:48 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: [PATCH 2.6]: fix unbalances spin_unlock_bh in __xfrm_find_acq_byseq Content-Type: multipart/mixed; boundary="------------020503090501010701010107" X-archive-position: 9341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1262 Lines: 46 This is a multi-part message in MIME format. --------------020503090501010701010107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch fixes an unbalanced spin_unlock_bh in __xfrm_find_acq_byseq left over from the larval state SA fix. Regards Patrick --------------020503090501010701010107 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 06:05:52+02:00 kaber@coreworks.de # [XFRM]: Fix unbalanced spin_unlock_bh # # Signed-off-by: Patrick McHardy # # net/xfrm/xfrm_state.c # 2004/09/23 06:05:25+02:00 kaber@coreworks.de +0 -1 # [XFRM]: Fix unbalanced spin_unlock_bh # # Signed-off-by: Patrick McHardy # diff -Nru a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c --- a/net/xfrm/xfrm_state.c 2004-09-23 06:07:23 +02:00 +++ b/net/xfrm/xfrm_state.c 2004-09-23 06:07:23 +02:00 @@ -592,7 +592,6 @@ list_for_each_entry(x, xfrm_state_bydst+i, bydst) { if (x->km.seq == seq) { xfrm_state_hold(x); - spin_unlock_bh(&xfrm_state_lock); return x; } } --------------020503090501010701010107-- From herbert@gondor.apana.org.au Wed Sep 22 21:15:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 21:15:46 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N4FYLn019879 for ; Wed, 22 Sep 2004 21:15:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAL0o-0006jT-00; Thu, 23 Sep 2004 14:15:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAL0m-00050v-00; Thu, 23 Sep 2004 14:15:16 +1000 Date: Thu, 23 Sep 2004 14:15:16 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPv4] Fix thinko in fib_find_alias Message-ID: <20040923041516.GA19252@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 973 Lines: 38 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: fib_find_alias is meant to return either an exact match or the entry just before where it should be. Currently it returns the entry after that. This patch fixes that. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/fib_hash.c 1.23 vs edited ===== --- 1.23/net/ipv4/fib_hash.c 2004-09-23 14:07:29 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-23 14:08:42 +10:00 @@ -448,7 +448,7 @@ if (prio <= fa->fa_info->fib_priority) break; } - return fa; + return prev_fa; } return NULL; } --k+w/mQv8wyuph6w0-- From leonid.grossman@s2io.com Wed Sep 22 21:47:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 21:48:03 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N4liFs021081 for ; Wed, 22 Sep 2004 21:47:44 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8N4ktje002865; Thu, 23 Sep 2004 00:46:55 -0400 (EDT) Received: from lgt40 ([192.168.0.7]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8N4kr39005611; Thu, 23 Sep 2004 00:46:53 -0400 (EDT) Message-Id: <200409230446.i8N4kr39005611@guinness.s2io.com> From: "Leonid Grossman" To: "'Nivedita Singhvi'" Cc: "'Andi Kleen'" , "'David S. Miller'" , "'John Heffner'" , , Subject: RE: The ultimate TOE design Date: Wed, 22 Sep 2004 21:46:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4151DDFF.6000902@us.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 thread-index: AcSg4Wls/1uX1Fa0Q4apuZMmesL9gQADYFIQ X-Scanned-By: MIMEDefang 2.34 X-archive-position: 9343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 1353 Lines: 44 > > > > It's a bit painful to setup, but in general with 9k jumbos > and TSO we > > were able to get close to pci-x 133 limit - both in LAN and > WAN tests. > > Leonid > > Cool, but a very specific environment, no? ;) Define specific environment :-). We are running common tcp benchmarks like nttcp or iperf or Chariot or filesystem applications on a very generic white boxes, with generic OS/settings. > > What concerns me about all this is that it seems so very > host-centric design. Wouldn't it be nice if we had a little > bit more network-centric worldview when designing network > infrastructure? > > It isn't just a matter of how had we can push stuff out, it > also matters how much the network can take. > Blasting tens of gigs into the ether seems all very exciting > sexy and cool, but suited for dedicated links or network > attached storage channels, not general-purpose networking on > the Internet or intra-nets. This is somewhat different from IB or FC "miniature networks", some/most of 10GbE testing runs in existing datacenters or over existing long-haul links - see for example http://sravot.home.cern.ch/sravot/Networking/10GbE/LSR_041504.htm Cheers, Leonid > > And if that is the case, we're talking about a much smaller > market (but perhaps a more profitable one ;))... > > thanks, > Nivedita > > > From laforge@gnumonks.org Wed Sep 22 23:19:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 23:19:55 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N6JnHs023735 for ; Wed, 22 Sep 2004 23:19:49 -0700 Received: from dsl-082-083-227-139.arcor-ip.net ([82.83.227.139] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CAMx6-0000vW-Vk; Thu, 23 Sep 2004 08:19:37 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CAMwt-0002ZJ-71; Thu, 23 Sep 2004 08:19:23 +0200 Date: Thu, 23 Sep 2004 08:19:23 +0200 From: Harald Welte To: Andi Kleen Cc: "David S. Miller" , hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [IPv4] Kill remnant of ip_nat_dumb Message-ID: <20040923061923.GL3236@sunbeam.de.gnumonks.org> References: <20040922040155.GA19302@gondor.apana.org.au> <1095855039.1045.67.camel@jzny.localdomain> <20040922110931.68b113a4.davem@davemloft.net> <20040922181433.GH27432@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="suYNV1AwziNMnBoj" Content-Disposition: inline In-Reply-To: <20040922181433.GH27432@wotan.suse.de> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1487 Lines: 47 --suYNV1AwziNMnBoj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2004 at 08:14:33PM +0200, Andi Kleen wrote: > > It's gone until someone fixes it up into working condition > > once more. It's been broken ever since the first bits > > of IPSEC dst cache infrastructure went in. >=20 > Also netfilter has a static NAT too these days, so it doesn't=20 > seem to be very useful to have another one. yes and no.=20 =46rom a functionality point of view: yes. =20 =46rom a performance point of view, there are applications for really dumb static NAT where you don't want to pull all the dependencies from ip_conntrack over ip_tables. > -Andi --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --suYNV1AwziNMnBoj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUmrrXaXGVTD0i/8RAsB3AJ4pbskrLDWWLXYGbVUOwcO21Vi/SQCgigyn eRZF/QFIUXBkd31eIDHaatU= =Q/LN -----END PGP SIGNATURE----- --suYNV1AwziNMnBoj-- From yoshfuji@linux-ipv6.org Wed Sep 22 23:18:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 23:18:54 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N6ImR5023535 for ; Wed, 22 Sep 2004 23:18:49 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 109A933CE7; Thu, 23 Sep 2004 15:18:50 +0900 (JST) Date: Thu, 23 Sep 2004 15:18:49 +0900 (JST) Message-Id: <20040923.151849.54646117.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: dwmw2@infradead.org, andre@tomt.net, jgarzik@pobox.com, pp@ee.oulu.fi, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040922111544.469dc4c2.davem@davemloft.net> References: <414FC92F.6090009@tomt.net> <1095854932.17821.1190.camel@hades.cambridge.redhat.com> <20040922111544.469dc4c2.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 625 Lines: 14 In article <20040922111544.469dc4c2.davem@davemloft.net> (at Wed, 22 Sep 2004 11:15:44 -0700), "David S. Miller" says: > > It's not just tunnel interfaces. It seems to be related to hot-unplug of > > interfaces with live IPv6 addresses. I've seen it on my prism54 card too > > on many recent kernels. All I have to do is insert it and remove it a > > few times. > > There is code in ipv6 which takes route references to devices and moves > that reference over to loopback. There might be bugs in that area, and > I would suggest debugging in that area. Okay, I'll look into it again... --yoshfuji From herbert@gondor.apana.org.au Wed Sep 22 23:28:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Sep 2004 23:29:04 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N6Sp1f024282 for ; Wed, 22 Sep 2004 23:28:54 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAN5n-0007LN-00; Thu, 23 Sep 2004 16:28:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAN5j-0005G6-00; Thu, 23 Sep 2004 16:28:31 +1000 Date: Thu, 23 Sep 2004 16:28:31 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPv4] Missing TOS checks after fib_find_alias Message-ID: <20040923062831.GA20202@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1273 Lines: 47 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: It looks like some of the places where FIB_SCAN_TOS macros were used have lost the tos check. This patch adds them back. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/fib_hash.c 1.24 vs edited ===== --- 1.24/net/ipv4/fib_hash.c 2004-09-23 16:10:05 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-23 16:16:48 +10:00 @@ -538,6 +538,8 @@ */ fa_orig = fa; list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { + if (fa->fa_tos != tos) + break; if (fa->fa_info->fib_priority != fi->fib_priority) break; if (fa->fa_type == type && @@ -636,6 +638,9 @@ fa_to_delete = NULL; list_for_each_entry(fa, fa->fa_list.prev, fa_list) { struct fib_info *fi = fa->fa_info; + + if (fa->fa_tos != tos) + break; if ((!r->rtm_type || fa->fa_type == r->rtm_type) && --VbJkn9YxBvnuCH5J-- From andre@tomt.net Thu Sep 23 00:11:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 00:11:32 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N7BQfO025525 for ; Thu, 23 Sep 2004 00:11:26 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id AF58E229A1; Thu, 23 Sep 2004 09:11:14 +0200 (CEST) Message-ID: <41527796.4010204@tomt.net> Date: Thu, 23 Sep 2004 09:13:26 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. References: <20040920212453.GA15392@ee.oulu.fi> <414F7CD9.3090008@pobox.com> <414FC92F.6090009@tomt.net> <20040921121332.GR31616@rei.reeler.org> <4151E680.80203@tomt.net> <20040922211942.GA1674@postel.suug.ch> <41523670.1090603@tomt.net> <41523EC5.20805@tomt.net> In-Reply-To: <41523EC5.20805@tomt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 953 Lines: 28 (CC'ed to netdev) I can taste the bug now :-) Me and Thomas Graf have been discussing this a bit off-list; so for those on netdev, this is my current setup: server A sets up a sit tunnel to server B. server B has a sit tunnel to Provider. All communication between A, B and Provider is going over ethernet on the physical layer. server B is the one getting stuck in "waiting for to become free.." when ifdown'ing (ip tunnel del) the interface to Provider. If I boot with net.ipv6.conf.default.forward = 1 in sysctl.conf - but then after the boot do echo 1 > /proc/sys/net/ipv6/conf/all/forward (to actually get it running) we'll crash and burn when taking down the interface. Only setting /proc/sys/net/ipv6/conf/all/forward = 1, but never touch default, it goes down cleanly. I have the ipv6/conf/default/forwarding set in sysctl.conf on all the routers, and it seems zebra sets the ipv6/conf/all/forwarding later on. From andre@tomt.net Thu Sep 23 01:05:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 01:05:32 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N85PWR030673 for ; Thu, 23 Sep 2004 01:05:26 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 10F2F229A1; Thu, 23 Sep 2004 10:05:14 +0200 (CEST) Message-ID: <4152843D.6010204@tomt.net> Date: Thu, 23 Sep 2004 10:07:25 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. References: <20040920212453.GA15392@ee.oulu.fi> <414F7CD9.3090008@pobox.com> <414FC92F.6090009@tomt.net> <20040921121332.GR31616@rei.reeler.org> <4151E680.80203@tomt.net> <20040922211942.GA1674@postel.suug.ch> <41523670.1090603@tomt.net> <41523EC5.20805@tomt.net> <41527796.4010204@tomt.net> In-Reply-To: <41527796.4010204@tomt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 1407 Lines: 44 Andre Tomt wrote: > (CC'ed to netdev) > > > > I can taste the bug now :-) > > Me and Thomas Graf have been discussing this a bit off-list; so for > those on netdev, this is my current setup: > > server A sets up a sit tunnel to server B. server B has a sit tunnel to > Provider. All communication between A, B and Provider is going over > ethernet on the physical layer. > > server B is the one getting stuck in "waiting for to become > free.." when ifdown'ing (ip tunnel del) the interface to Provider. > > > If I boot with net.ipv6.conf.default.forward = 1 in sysctl.conf - but > then after the boot do echo 1 > /proc/sys/net/ipv6/conf/all/forward (to > actually get it running) > > we'll crash and burn when taking down the interface. > > Only setting /proc/sys/net/ipv6/conf/all/forward = 1, but never touch > default, it goes down cleanly. > > I have the ipv6/conf/default/forwarding set in sysctl.conf on all the > routers, and it seems zebra sets the ipv6/conf/all/forwarding later on. > Possibly important note: if I set up both conf.all and conf.default (order does not matter) before the tunnel devices are created, everything works as expected. eg. in sysctl.conf: net.ipv6.conf.default.forwarding=1 net.ipv6.conf.all.forwarding=1 if default is set first, then tunnels created, followed by setting "all"; everything breaks down on ifdown. pretty neat :) From herbert@gondor.apana.org.au Thu Sep 23 01:13:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 01:13:47 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N8Dbsm031459 for ; Thu, 23 Sep 2004 01:13:38 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAOiz-00084l-00; Thu, 23 Sep 2004 18:13:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAOil-0005Ot-00; Thu, 23 Sep 2004 18:12:55 +1000 From: Herbert Xu To: laforge@gnumonks.org (Harald Welte) Subject: Re: [IPv4] Kill remnant of ip_nat_dumb Cc: ak@suse.de, davem@davemloft.net, hadi@cyberus.ca, herbert@gondor.apana.org.au, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040923061923.GL3236@sunbeam.de.gnumonks.org> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 23 Sep 2004 18:12:55 +1000 X-archive-position: 9349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 674 Lines: 19 Harald Welte wrote: > > From a functionality point of view: yes. > > From a performance point of view, there are applications for really dumb > static NAT where you don't want to pull all the dependencies from > ip_conntrack over ip_tables. Well the problem is nobody is stepping forward to fix it. It was removed not because it was redundant, but because it was broken. Until someone actually fixes it, it can't go back in. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From yoshfuji@linux-ipv6.org Thu Sep 23 01:22:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 01:22:58 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N8MqOn032006 for ; Thu, 23 Sep 2004 01:22:53 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E131E33CE7; Thu, 23 Sep 2004 17:22:53 +0900 (JST) Date: Thu, 23 Sep 2004 17:22:53 +0900 (JST) Message-Id: <20040923.172253.125681726.yoshfuji@linux-ipv6.org> To: andre@tomt.net, tgraf@suug.ch, pp@ee.oulu.fi, jgarzik@pobox.com, dwmw2@infradead.org Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, davem@davemloft.net Subject: Re: unregister_netdevice: waiting for tun6to4 to become free. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <4152843D.6010204@tomt.net> References: <41523EC5.20805@tomt.net> <41527796.4010204@tomt.net> <4152843D.6010204@tomt.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1283 Lines: 36 In article <4152843D.6010204@tomt.net> (at Thu, 23 Sep 2004 10:07:25 +0200), Andre Tomt says: > > If I boot with net.ipv6.conf.default.forward = 1 in sysctl.conf - but > > then after the boot do echo 1 > /proc/sys/net/ipv6/conf/all/forward (to > > actually get it running) > > > > we'll crash and burn when taking down the interface. > > > > Only setting /proc/sys/net/ipv6/conf/all/forward = 1, but never touch > > default, it goes down cleanly. > > > > I have the ipv6/conf/default/forwarding set in sysctl.conf on all the > > routers, and it seems zebra sets the ipv6/conf/all/forwarding later on. > > > > Possibly important note: > > if I set up both conf.all and conf.default (order does not matter) > before the tunnel devices are created, everything works as expected. > > eg. in sysctl.conf: > net.ipv6.conf.default.forwarding=1 > net.ipv6.conf.all.forwarding=1 > > if default is set first, then tunnels created, followed by setting > "all"; everything breaks down on ifdown. > > pretty neat :) Thank you everyone for tracking down this bug. I will fix this bug and come up with patch tomorrow (or so). Thanks again. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From laforge@gnumonks.org Thu Sep 23 01:30:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 01:30:18 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N8UCUV032472 for ; Thu, 23 Sep 2004 01:30:13 -0700 Received: from dsl-082-083-227-139.arcor-ip.net ([82.83.227.139] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CAOzJ-0003iY-1F; Thu, 23 Sep 2004 10:30:01 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CAOzD-0002j2-WB; Thu, 23 Sep 2004 10:29:56 +0200 Date: Thu, 23 Sep 2004 10:29:55 +0200 From: Harald Welte To: Herbert Xu Cc: ak@suse.de, davem@davemloft.net, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [IPv4] Kill remnant of ip_nat_dumb Message-ID: <20040923082955.GP3236@sunbeam.de.gnumonks.org> References: <20040923061923.GL3236@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2NSZC26AJDpFITwK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1668 Lines: 51 --2NSZC26AJDpFITwK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2004 at 06:12:55PM +1000, Herbert Xu wrote: > Harald Welte wrote: > >=20 > > From a functionality point of view: yes. =20 > >=20 > > From a performance point of view, there are applications for really dumb > > static NAT where you don't want to pull all the dependencies from > > ip_conntrack over ip_tables. >=20 > Well the problem is nobody is stepping forward to fix it. It was removed > not because it was redundant, but because it was broken. >=20 > Until someone actually fixes it, it can't go back in. I fully understand this, and I support that decision. =20 Independent of this, I just wanted to note that if there was working and compatible code, it had it's use for high performance static nat applications. > Cheers, --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --2NSZC26AJDpFITwK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBUomDXaXGVTD0i/8RAiYnAJ4tgZ8Ypj+OBa8QtuKWjp/rr0BTmACgpldR kGQTXrupEi1I6GBmkXE2sV4= =yzoq -----END PGP SIGNATURE----- --2NSZC26AJDpFITwK-- From jchapman@katalix.com Thu Sep 23 02:09:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 02:09:10 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8N9938G017008 for ; Thu, 23 Sep 2004 02:09:04 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1CAPar-0003Pc-F4; Thu, 23 Sep 2004 04:08:49 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Thu, 23 Sep 2004 10:08:48 +0100 Message-ID: <1095930528.415292a0cd16a@www.katalix.com> Date: Thu, 23 Sep 2004 10:08:48 +0100 From: James Chapman To: jesse.brandeburg@intel.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH 1/2 2.6] e100: fix NAPI race with watchdog MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 595 Lines: 19 > While polling in NAPI mode, we were occassionally getting interrupts > re-enabled by the watchdog trying to generate a software interrupt. > Fix is to add a spinlock around that shared hardware register to > allow a read-modify-write operation. This was nasty nasty. I don't > like the spinlock in the hot path but i see no other way. Comments > are welcome. While working with NAPI on the e100 a while ago, I seriously considered removing the generation of the sw interrupt altogether for the NAPI case. Does it serve any purpose? NAPI is polling the driver already anyway. /james From herbert@gondor.apana.org.au Thu Sep 23 04:17:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 04:17:22 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NBH8bs006507 for ; Thu, 23 Sep 2004 04:17:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CARaX-0000sG-00; Thu, 23 Sep 2004 21:16:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CARaS-00071j-00; Thu, 23 Sep 2004 21:16:32 +1000 From: Herbert Xu To: xhejtman@mail.muni.cz (Lukas Hejtmanek) Subject: Re: 2.6.9-rc2-mm2 fn_hash_insert oops Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040923103723.GA12145@mail.muni.cz> X-Newsgroups: apana.lists.os.linux.kernel User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Thu, 23 Sep 2004 21:16:32 +1000 X-archive-position: 9353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1128 Lines: 37 Lukas Hejtmanek wrote: > > However there is still the issue with endless loop in fn_hash_delete :( Same problem, same fix. Can someone think of a generic fix to list_for_each_*? Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/ipv4/fib_hash.c 1.22 vs edited ===== --- 1.22/net/ipv4/fib_hash.c 2004-09-22 09:31:48 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-23 21:16:04 +10:00 @@ -608,6 +608,7 @@ struct fn_hash *table = (struct fn_hash*)tb->tb_data; struct fib_node *f; struct fib_alias *fa, *fa_to_delete; + struct list_head *fa_head; int z = r->rtm_dst_len; struct fn_zone *fz; u32 key; @@ -633,7 +634,8 @@ return -ESRCH; fa_to_delete = NULL; - list_for_each_entry(fa, fa->fa_list.prev, fa_list) { + fa_head = fa->fa_list.prev; + list_for_each_entry(fa, fa_head, fa_list) { struct fib_info *fi = fa->fa_info; if ((!r->rtm_type || From herbert@gondor.apana.org.au Thu Sep 23 05:05:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 05:06:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NC5qYw010966 for ; Thu, 23 Sep 2004 05:05:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CASLo-0001Fw-00; Thu, 23 Sep 2004 22:05:28 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CASLg-0008Vw-00; Thu, 23 Sep 2004 22:05:20 +1000 Date: Thu, 23 Sep 2004 22:05:20 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040923120520.GA32624@gondor.apana.org.au> References: <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <1095821624.1045.6.camel@jzny.localdomain> <20040922034634.GA14928@gondor.apana.org.au> <1095852956.1048.47.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095852956.1048.47.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 970 Lines: 34 On Wed, Sep 22, 2004 at 07:35:57AM -0400, jamal wrote: > On Tue, 2004-09-21 at 23:46, Herbert Xu wrote: > > > > Well I haven't seen any with IPsec. Can you please provide a strace > > of a failed tc dump so that I know what I'm looking for? > > Try explicitly reducing the socket buffer size and see what happens What's wrong with the default sizes? If you decrease it far enough of course it's going to overflow. > set i to 10000 or a little more You might want to optimise your add path. It was painful with 20000 :) > to dump: tc actions ls action drop That was much faster, no overflows at all: angband:~# time tc action ls action gact > out real 0m0.943s user 0m0.075s sys 0m0.867s angband:~# wc -l out 80000 out angband:~# Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Sep 23 05:07:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 05:07:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NC7a0E011298 for ; Thu, 23 Sep 2004 05:07:37 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CASNQ-0001HL-00; Thu, 23 Sep 2004 22:07:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CASNP-0008WO-00; Thu, 23 Sep 2004 22:07:07 +1000 Date: Thu, 23 Sep 2004 22:07:07 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040923120707.GB32624@gondor.apana.org.au> References: <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095854920.1047.64.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 730 Lines: 20 On Wed, Sep 22, 2004 at 08:08:40AM -0400, jamal wrote: > > Since netlink is being used for a lot of things now, it may be time to > obsolete those assumptions. I'm not against changes. But so far I haven't seen anything concrete about what these new things are yet :) > Note also, theres a lot of wastage of that scarce sock buffer via page > sized skbs - its not as trivial to fix, but would go some way to improve > overrunning of the socket. I wasn't aware of this scarcity problem. Can you elaborate? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From elueck@de.ibm.com Thu Sep 23 06:08:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 06:08:48 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.29.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ND8gFc013075 for ; Thu, 23 Sep 2004 06:08:43 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8ND7sfQ138108; Thu, 23 Sep 2004 13:07:54 GMT Received: from de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ND7sRg090318; Thu, 23 Sep 2004 15:07:54 +0200 Message-ID: <4152CA7F.5070206@de.ibm.com> Date: Thu, 23 Sep 2004 15:07:11 +0200 From: Einar Lueck Reply-To: lkml@einar-lueck.de Organization: IBM Deutschland Entwicklung GmbH User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC][PATCH 1/2] ipv4 multipath routing, bk head References: <4151A8E5.6060600@de.ibm.com> <20040922111416.66563786.davem@davemloft.net> In-Reply-To: <20040922111416.66563786.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: elueck@de.ibm.com Precedence: bulk X-list: netdev Content-Length: 235 Lines: 13 David S. Miller wrote: >We've all seen your patches already, you don't need to send them >again. > >Thanks. > > Sorry, David. I did not post the same patches. I pointed out in the mail that there are major changes. Regards, Einar. From pablo@eurodev.net Thu Sep 23 06:39:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 06:39:53 -0700 (PDT) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NDdkxd014189 for ; Thu, 23 Sep 2004 06:39:47 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp07.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040923133928.GUHK9737.smtp07.retemail.es@eurodev.net>; Thu, 23 Sep 2004 15:39:28 +0200 Message-ID: <4152EE68.4030803@eurodev.net> Date: Thu, 23 Sep 2004 17:40:24 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: hadi@cyberus.ca, herbert@gondor.apana.org.au, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> In-Reply-To: <20040922105221.59a67d4b.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 878 Lines: 29 David S. Miller wrote: >On 22 Sep 2004 08:08:40 -0400 >jamal wrote: > > > >>Note also, theres a lot of wastage of that scarce sock buffer via page >>sized skbs - its not as trivial to fix, but would go some way to improve >>overrunning of the socket. >> >> > >Thanks for reminding me about this. > > Initially we could allocate a skb with size NLMSG_GOODSIZE, then after all the information has been added, we could use a function (skb_*) which allocates a new buffer headroom, memcpy the old skb headroom and release it, so we trim the useless part of the headroom. This make us waste some extra jiffies with memcpy's but we could save same space in the queue. Does such skb_* function exist? Another choice could be using a temporary buffer and them memcpy the buffer to a skb which has only allocated the buffer space used. regards, Pablo From xhejtman@pc2073.sks3.muni.cz Thu Sep 23 07:06:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 07:06:21 -0700 (PDT) Received: from hell.sks3.muni.cz (share.sks3.muni.cz [147.251.211.22]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NE6FF2015125 for ; Thu, 23 Sep 2004 07:06:15 -0700 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1CAUB2-0004Mg-00; Thu, 23 Sep 2004 16:02:28 +0200 Date: Thu, 23 Sep 2004 16:02:28 +0200 From: Lukas Hejtmanek To: Herbert Xu Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: 2.6.9-rc2-mm2 fn_hash_insert oops Message-ID: <20040923140228.GA16675@mail.muni.cz> References: <20040923103723.GA12145@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: netdev Content-Length: 318 Lines: 12 On Thu, Sep 23, 2004 at 09:16:32PM +1000, Herbert Xu wrote: > Lukas Hejtmanek wrote: > > > > However there is still the issue with endless loop in fn_hash_delete :( > > Same problem, same fix. Can someone think of a generic fix to > list_for_each_*? It helped. Thankx. -- Luká¹ Hejtmánek From nacc@us.ibm.com Thu Sep 23 09:07:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 09:07:20 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NG78Iw023703 for ; Thu, 23 Sep 2004 09:07:15 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8NG6fRK219294; Thu, 23 Sep 2004 12:06:41 -0400 Received: from localhost.localdomain (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8NG7s6G092448; Thu, 23 Sep 2004 12:07:55 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11/Debian-5) with ESMTP id i8NG7BGP001772; Thu, 23 Sep 2004 09:07:11 -0700 Received: (from nacc@localhost) by localhost.localdomain (8.12.11/8.12.11/Debian-5) id i8NG7ATE001769; Thu, 23 Sep 2004 09:07:10 -0700 X-Authentication-Warning: localhost.localdomain: nacc set sender to nacc@us.ibm.com using -f Date: Thu, 23 Sep 2004 09:07:10 -0700 From: Nishanth Aravamudan To: chas3@users.sourceforge.net Cc: netdev@oss.sgi.com, davem@redhat.com, kernel-janitors@lists.osdl.org Subject: Re: [PATCH][ATM]: [drivers] use msleep() instead of schedule_timeout() (from Nishanth Aravamudan ) Message-ID: <20040923160710.GB1699@us.ibm.com> References: <200409212029.i8LKTINv010576@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409212029.i8LKTINv010576@ginger.cmf.nrl.navy.mil> X-Operating-System: Linux 2.6.8.1 (i686) User-Agent: Mutt/1.5.6+20040722i X-archive-position: 9359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 591 Lines: 18 On Tue, Sep 21, 2004 at 04:29:19PM -0400, chas williams (contractor) wrote: > diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c > --- a/drivers/atm/lanai.c 2004-09-21 12:48:17 -04:00 > +++ b/drivers/atm/lanai.c 2004-09-21 12:48:17 -04:00 > @@ -813,7 +813,7 @@ > DPRINTK("read, write = %d, %d\n", read, write); > break; > } > - schedule_timeout(HZ / 25); > + msleep(4); Somehow this got changed for msleep(40); to msleep(4); !! :) The patch I sent on 15 September had msleep(40); in it, at least. If you could make the change in your bk, that would be great! -Nish From nacc@us.ibm.com Thu Sep 23 09:08:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 09:08:30 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NG8N9D023895 for ; Thu, 23 Sep 2004 09:08:23 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8NG7acs212920; Thu, 23 Sep 2004 12:07:36 -0400 Received: from localhost.localdomain (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8NG7Z9d106452; Thu, 23 Sep 2004 10:07:35 -0600 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11/Debian-5) with ESMTP id i8NG8B6A001792; Thu, 23 Sep 2004 09:08:11 -0700 Received: (from nacc@localhost) by localhost.localdomain (8.12.11/8.12.11/Debian-5) id i8NG8Ai8001789; Thu, 23 Sep 2004 09:08:10 -0700 X-Authentication-Warning: localhost.localdomain: nacc set sender to nacc@us.ibm.com using -f Date: Thu, 23 Sep 2004 09:08:10 -0700 From: Nishanth Aravamudan To: Margit Schubert-While Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: msleep changes Message-ID: <20040923160810.GC1699@us.ibm.com> References: <5.1.0.14.2.20040923050120.0257f490@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040923050120.0257f490@pop.t-online.de> X-Operating-System: Linux 2.6.8.1 (i686) User-Agent: Mutt/1.5.6+20040722i X-archive-position: 9360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1084 Lines: 33 On Thu, Sep 23, 2004 at 05:24:33AM +0200, Margit Schubert-While wrote: > Hi Nish, > In latest BK : > > # drivers/atm/lanai.c > # 2004/09/21 14:58:17-07:00 chas@cmf.nrl.navy.mil +1 -1 > # [ATM]: [drivers] Use msleep() instead of schedule_timeout() > # From Nishanth Aravamudan > > diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c > --- a/drivers/atm/lanai.c 2004-09-21 17:11:30 -07:00 > +++ b/drivers/atm/lanai.c 2004-09-21 17:11:30 -07:00 > @@ -813,7 +813,7 @@ > DPRINTK("read, write = %d, %d\n", read, write); > break; > } > - schedule_timeout(HZ / 25); > + msleep(4); > > > ?????? > > Just one that immediately lept to my eye. > I am not going to check them all. > That's your job :-) Thanks for catching this. I actually have re-pushed the patch already with the correct time, but it is only going to be in the latest kjt (which was sent yesterday, I think). Ahh, I see the problem; somehow the maintainer's patch had msleep(4) in it, even though my patch had msleep(40). It should be corrected soon. Thanks for seeing this, again. -Nish From chas@cmf.nrl.navy.mil Thu Sep 23 09:26:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 09:26:33 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NGQRrM024671 for ; Thu, 23 Sep 2004 09:26:27 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8NGQ44f014489; Thu, 23 Sep 2004 12:26:04 -0400 (EDT) Message-Id: <200409231626.i8NGQ44f014489@ginger.cmf.nrl.navy.mil> To: Nishanth Aravamudan cc: netdev@oss.sgi.com, davem@redhat.com, kernel-janitors@lists.osdl.org Subject: Re: [PATCH][ATM]: [drivers] use msleep() instead of schedule_timeout() (from Nishanth Aravamudan ) In-Reply-To: Message from Nishanth Aravamudan of "Thu, 23 Sep 2004 09:07:10 PDT." <20040923160710.GB1699@us.ibm.com> Date: Thu, 23 Sep 2004 12:26:05 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1435 Lines: 47 oops. sorry about that. dave, please apply the following patch. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 12:24:28-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [lanai] get sleep interval right # # drivers/atm/lanai.c # 2004/09/23 12:24:12-04:00 chas@relax.cmf.nrl.navy.mil +1 -1 # [ATM]: [lanai] get sleep interval right # diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c --- a/drivers/atm/lanai.c 2004-09-23 12:25:36 -04:00 +++ b/drivers/atm/lanai.c 2004-09-23 12:25:36 -04:00 @@ -813,7 +813,7 @@ DPRINTK("read, write = %d, %d\n", read, write); break; } - msleep(4); + msleep(40); } /* 15.2.2 - clear out all tx registers */ cardvcc_write(lvcc, 0, vcc_txreadptr); In message <20040923160710.GB1699@us.ibm.com>,Nishanth Aravamudan writes: >On Tue, Sep 21, 2004 at 04:29:19PM -0400, chas williams (contractor) wrote: > > >> diff -Nru a/drivers/atm/lanai.c b/drivers/atm/lanai.c >> --- a/drivers/atm/lanai.c 2004-09-21 12:48:17 -04:00 >> +++ b/drivers/atm/lanai.c 2004-09-21 12:48:17 -04:00 >> @@ -813,7 +813,7 @@ >> DPRINTK("read, write = %d, %d\n", read, write); >> break; >> } >> - schedule_timeout(HZ / 25); >> + msleep(4); > >Somehow this got changed for msleep(40); to msleep(4); !! :) The patch I >sent on 15 September had msleep(40); in it, at least. If you could make >the change in your bk, that would be great! > >-Nish > From andre@tomt.net Thu Sep 23 09:54:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 09:54:17 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NGs9Vx025411 for ; Thu, 23 Sep 2004 09:54:09 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 861DA229A7 for ; Thu, 23 Sep 2004 18:53:57 +0200 (CEST) Message-ID: <41530028.6040600@tomt.net> Date: Thu, 23 Sep 2004 18:56:08 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: sundance buckles under load Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 22458 Lines: 316 I have one of those cheap ass so far mostly unusable D-Link 4port sundance based NIC's laying around collecting dust. So far its been a troublesome card to use, it worked OK for a while in 2.4, but at least in recent 2.6 it's rather unstable. I know this is a piece of junk, but it would be cool to have it working anyway ;-) Even a simple iperf test tips it over into triggering the netdev watchdog, often within seconds, or if we're lucky - a few minutes. Usually the reset gets it back online again - for a short period of time, untill netdev watchdog trigger again. running iperf -s on the pc with sundance, and iperf -c -d (bi-directional test) on a client, triggers it reliably. The machine is running with ACPI disabled (automaticly at boot, as BIOS is from 2000 or earlier.) Other than that, the kernel has vectorized interrupts enabled, but it doesn't seem to be used in this case. kernel version is equalent of 2.6.8.1, CONFIG_SUNDANCE_MMIO is off. from the kernel log: > Sep 18 09:16:46 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out > Sep 18 09:16:46 localhost kernel: eth0: Transmit timed out, TxStatus 00 TxFrameId 17, resetting... > Sep 18 09:16:46 localhost kernel: 00 0f45e000 0f45e010 00008001(00) 0f2d308e 800005ea > Sep 18 09:16:46 localhost kernel: 01 0f45e010 0f45e020 00000005(01) 0474488e 800005ea > Sep 18 09:16:46 localhost kernel: 02 0f45e020 0f45e030 00000009(02) 0bffd88e 800005ea > Sep 18 09:16:46 localhost kernel: 03 0f45e030 0f45e040 0000000d(03) 041f108e 800005ea > Sep 18 09:16:46 localhost kernel: 04 0f45e040 0f45e050 00000011(04) 0efb008e 800005ea > Sep 18 09:16:46 localhost kernel: 05 0f45e050 0f45e060 00000015(05) 0d87708e 800005ea > Sep 18 09:16:46 localhost kernel: 06 0f45e060 0f45e070 00000019(06) 029e608e 800005ea > Sep 18 09:16:46 localhost kernel: 07 0f45e070 0f45e080 0000001d(07) 0dd3208e 800005ea > Sep 18 09:16:46 localhost kernel: 08 0f45e080 0f45e090 00000021(08) 0c07188e 800005ea > Sep 18 09:16:46 localhost kernel: 09 0f45e090 0f45e0a0 00000025(09) 0b91008e 800005ea > Sep 18 09:16:46 localhost kernel: 0a 0f45e0a0 0f45e0b0 00000029(0a) 0c77d88e 800005ea > Sep 18 09:16:46 localhost kernel: 0b 0f45e0b0 0f45e0c0 0000002d(0b) 0b99908e 800005ea > Sep 18 09:16:46 localhost kernel: 0c 0f45e0c0 0f45e0d0 00000031(0c) 0d85688e 800005ea > Sep 18 09:16:46 localhost kernel: 0d 0f45e0d0 0f45e0e0 00000035(0d) 0fb2708e 800005ea > Sep 18 09:16:46 localhost kernel: 0e 0f45e0e0 0f45e0f0 00000039(0e) 04b7e08e 800005ea > Sep 18 09:16:46 localhost kernel: 0f 0f45e0f0 0f45e100 0000003d(0f) 04b3908e 800005ea > Sep 18 09:16:46 localhost kernel: 10 0f45e100 0f45e110 00000041(10) 0b9ac08e 800005ea > Sep 18 09:16:46 localhost kernel: 11 0f45e110 0f45e120 00000045(11) 0b9ac88e 800005ea > Sep 18 09:16:46 localhost kernel: 12 0f45e120 0f45e130 00000049(12) 04ad808e 800005ea > Sep 18 09:16:46 localhost kernel: 13 0f45e130 00000000 0000804d(13) 04ad888e 800005ea > Sep 18 09:16:46 localhost kernel: 14 0f45e140 0f45e150 00018051(14) 00000000 00000000 > Sep 18 09:16:46 localhost kernel: 15 0f45e150 0f45e160 00010055(15) 00000000 00000000 > Sep 18 09:16:46 localhost kernel: 16 0f45e160 0f45e170 00010059(16) 00000000 00000000 > Sep 18 09:16:46 localhost kernel: 17 0f45e170 0f45e180 0001005d(17) 00000000 00000000 > Sep 18 09:16:46 localhost kernel: 18 0f45e180 0f45e190 00008061(18) 0dc2a88e 800005ea > Sep 18 09:16:46 localhost kernel: 19 0f45e190 0f45e1a0 00000065(19) 0d33488e 800005ea > Sep 18 09:16:46 localhost kernel: 1a 0f45e1a0 0f45e1b0 00000069(1a) 0f7d108e 800005ea > Sep 18 09:16:46 localhost kernel: 1b 0f45e1b0 0f45e1c0 0000006d(1b) 0415508e 800005ea > Sep 18 09:16:46 localhost kernel: 1c 0f45e1c0 0f45e1d0 00008071(1c) 0b9a188e 800005ea > Sep 18 09:16:46 localhost kernel: 1d 0f45e1d0 0f45e1e0 00000075(1d) 0f73588e 800005ea > Sep 18 09:16:46 localhost kernel: 1e 0f45e1e0 0f45e1f0 00000079(1e) 0e12b88e 800005ea > Sep 18 09:16:46 localhost kernel: 1f 0f45e1f0 0f45e000 0000007d(1f) 042c788e 800005ea > Sep 18 09:16:46 localhost kernel: TxListPtr=0f45e180 netif_queue_stopped=1 > Sep 18 09:16:46 localhost kernel: cur_tx=9449428(14) dirty_tx=9449400(18) > Sep 18 09:16:46 localhost kernel: cur_rx=33 dirty_rx=33 > Sep 18 09:16:46 localhost kernel: cur_task=9449428 > Sep 18 09:16:54 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out > Sep 18 09:16:54 localhost kernel: eth0: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... > Sep 18 09:16:54 localhost kernel: 00 0f45e000 0f45e010 00010001(00) 00000000 00000000 > Sep 18 09:16:54 localhost kernel: 01 0f45e010 0f45e020 00000005(01) 0d87308e 800005ea > Sep 18 09:16:54 localhost kernel: 02 0f45e020 0f45e030 00000009(02) 0c77b08e 800005ea > Sep 18 09:16:54 localhost kernel: 03 0f45e030 0f45e040 0000000d(03) 0f95808e 800005ea > Sep 18 09:16:54 localhost kernel: 04 0f45e040 0f45e050 00000011(04) 0f8e828e 80000042 > Sep 18 09:16:54 localhost kernel: 05 0f45e050 0f45e060 00000015(05) 0f8e848e 80000042 > Sep 18 09:16:54 localhost kernel: 06 0f45e060 0f45e070 00000019(06) 0d61188e 800005ea > Sep 18 09:16:54 localhost kernel: 07 0f45e070 0f45e080 0000001d(07) 0b99708e 800005ea > Sep 18 09:16:54 localhost kernel: 08 0f45e080 0f45e090 00000021(08) 04b3988e 800005ea > Sep 18 09:16:54 localhost kernel: 09 0f45e090 0f45e0a0 00000025(09) 0faad08e 800005ea > Sep 18 09:16:54 localhost kernel: 0a 0f45e0a0 0f45e0b0 00000029(0a) 0edb788e 800005ea > Sep 18 09:16:54 localhost kernel: 0b 0f45e0b0 0f45e0c0 0000002d(0b) 0d08b88e 800005ea > Sep 18 09:16:54 localhost kernel: 0c 0f45e0c0 0f45e0d0 00000031(0c) 0bffd08e 800005ea > Sep 18 09:16:54 localhost kernel: 0d 0f45e0d0 0f45e0e0 00000035(0d) 0b9a108e 800005ea > Sep 18 09:16:54 localhost kernel: 0e 0f45e0e0 0f45e0f0 00000039(0e) 0f62a88e 800005ea > Sep 18 09:16:54 localhost kernel: 0f 0f45e0f0 0f45e100 0000003d(0f) 0f7d188e 800005ea > Sep 18 09:16:54 localhost kernel: 10 0f45e100 0f45e110 00000041(10) 0d84288e 800005ea > Sep 18 09:16:54 localhost kernel: 11 0f45e110 0f45e120 00000045(11) 0dd3288e 800005ea > Sep 18 09:16:54 localhost kernel: 12 0f45e120 0f45e130 00000049(12) 0ed1808e 800005ea > Sep 18 09:16:54 localhost kernel: 13 0f45e130 0f45e140 0000004d(13) 0427188e 800005ea > Sep 18 09:16:54 localhost kernel: 14 0f45e140 0f45e150 00000051(14) 0c30808e 800005ea > Sep 18 09:16:54 localhost kernel: 15 0f45e150 0f45e160 00000055(15) 0427108e 800005ea > Sep 18 09:16:54 localhost kernel: 16 0f45e160 0f45e170 00000059(16) 0137208e 800005ea > Sep 18 09:16:54 localhost kernel: 17 0f45e170 0f45e180 0000005d(17) 0d5d608e 800005ea > Sep 18 09:16:54 localhost kernel: 18 0f45e180 0f45e190 00000061(18) 04b7e88e 800005ea > Sep 18 09:16:54 localhost kernel: 19 0f45e190 0f45e1a0 00000065(19) 0b9af88e 800005ea > Sep 18 09:16:54 localhost kernel: 1a 0f45e1a0 0f45e1b0 00000069(1a) 0ba9708e 800005ea > Sep 18 09:16:54 localhost kernel: 1b 0f45e1b0 0f45e1c0 0000006d(1b) 04adb88e 800005ea > Sep 18 09:16:54 localhost kernel: 1c 0f45e1c0 0f45e1d0 00000071(1c) 0474688e 800005ea > Sep 18 09:16:54 localhost kernel: 1d 0f45e1d0 00000000 00008075(1d) 0f73f08e 800005ea > Sep 18 09:16:54 localhost kernel: 1e 0f45e1e0 0f45e1f0 00000079(1e) 0e12b88e 800005ea > Sep 18 09:16:54 localhost kernel: 1f 0f45e1f0 0f45e000 0000007d(1f) 042c788e 800005ea > Sep 18 09:16:54 localhost kernel: TxListPtr=0f45e010 netif_queue_stopped=1 > Sep 18 09:16:54 localhost kernel: cur_tx=30(1e) dirty_tx=1(01) > Sep 18 09:16:54 localhost kernel: cur_rx=35 dirty_rx=35 > Sep 18 09:16:54 localhost kernel: cur_task=30 > Sep 18 09:17:46 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out > Sep 18 09:17:46 localhost kernel: eth0: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... > Sep 18 09:17:46 localhost kernel: 00 0f45e000 0f45e010 00008001(00) 0423388e 800005ea > Sep 18 09:17:46 localhost kernel: 01 0f45e010 0f45e020 00008005(01) 0f866c82 8000004e > Sep 18 09:17:46 localhost kernel: 02 0f45e020 0f45e030 00008009(02) 0a17a88e 800005ea > Sep 18 09:17:46 localhost kernel: 03 0f45e030 0f45e040 0000800d(03) 0f866402 8000002a > Sep 18 09:17:46 localhost kernel: 04 0f45e040 00000000 00008011(04) 0f866602 8000002a > Sep 18 09:17:46 localhost kernel: 05 0f45e050 0f45e060 00010015(05) 00000000 00000000 > Sep 18 09:17:46 localhost kernel: 06 0f45e060 0f45e070 00010019(06) 00000000 00000000 > Sep 18 09:17:46 localhost kernel: 07 0f45e070 0f45e080 0000001d(07) 0f8eb28e 80000042 > Sep 18 09:17:46 localhost kernel: 08 0f45e080 0f45e090 00000021(08) 0f8eba8e 80000042 > Sep 18 09:17:46 localhost kernel: 09 0f45e090 0f45e0a0 00000025(09) 0f8eb88e 80000042 > Sep 18 09:17:46 localhost kernel: 0a 0f45e0a0 0f45e0b0 00000029(0a) 0f8ebe8e 80000042 > Sep 18 09:17:46 localhost kernel: 0b 0f45e0b0 0f45e0c0 0000002d(0b) 0fc1968e 80000042 > Sep 18 09:17:46 localhost kernel: 0c 0f45e0c0 0f45e0d0 00000031(0c) 0f8e8e8e 80000042 > Sep 18 09:17:46 localhost kernel: 0d 0f45e0d0 0f45e0e0 00000035(0d) 0f8eb48e 80000042 > Sep 18 09:17:46 localhost kernel: 0e 0f45e0e0 0f45e0f0 00000039(0e) 0fc19e8e 80000042 > Sep 18 09:17:46 localhost kernel: 0f 0f45e0f0 0f45e100 0000003d(0f) 0fc19a8e 80000042 > Sep 18 09:17:46 localhost kernel: 10 0f45e100 0f45e110 00000041(10) 0f8e8a8e 80000042 > Sep 18 09:17:46 localhost kernel: 11 0f45e110 0f45e120 00000045(11) 0fc1988e 80000042 > Sep 18 09:17:46 localhost kernel: 12 0f45e120 0f45e130 00000049(12) 0f8e868e 80000042 > Sep 18 09:17:46 localhost kernel: 13 0f45e130 0f45e140 0000004d(13) 0fe04482 8000004e > Sep 18 09:17:46 localhost kernel: 14 0f45e140 0f45e150 00000051(14) 0c30888e 800005ea > Sep 18 09:17:46 localhost kernel: 15 0f45e150 0f45e160 00000055(15) 0fe04c82 8000004e > Sep 18 09:17:46 localhost kernel: 16 0f45e160 0f45e170 00000059(16) 0474608e 800005ea > Sep 18 09:17:46 localhost kernel: 17 0f45e170 0f45e180 0000005d(17) 0fe04a82 8000004e > Sep 18 09:17:46 localhost kernel: 18 0f45e180 0f45e190 00000061(18) 0edb708e 800005ea > Sep 18 09:17:46 localhost kernel: 19 0f45e190 0f45e1a0 00000065(19) 0fe04282 8000004e > Sep 18 09:17:46 localhost kernel: 1a 0f45e1a0 0f45e1b0 00000069(1a) 0497708e 800005ea > Sep 18 09:17:46 localhost kernel: 1b 0f45e1b0 0f45e1c0 0000006d(1b) 0fc0c682 8000004e > Sep 18 09:17:46 localhost kernel: 1c 0f45e1c0 0f45e1d0 00000071(1c) 042c708e 800005ea > Sep 18 09:17:46 localhost kernel: 1d 0f45e1d0 0f45e1e0 00008075(1d) 0f8eb682 8000004e > Sep 18 09:17:46 localhost kernel: 1e 0f45e1e0 0f45e1f0 00008079(1e) 0ba3508e 800005ea > Sep 18 09:17:46 localhost kernel: 1f 0f45e1f0 0f45e000 0000807d(1f) 0f8e4482 8000004e > Sep 18 09:17:46 localhost kernel: TxListPtr=0f45e070 netif_queue_stopped=1 > Sep 18 09:17:46 localhost kernel: cur_tx=37(05) dirty_tx=7(07) > Sep 18 09:17:46 localhost kernel: cur_rx=37 dirty_rx=37 > Sep 18 09:17:46 localhost kernel: cur_task=37 > Sep 18 09:21:42 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out > Sep 18 09:21:42 localhost kernel: eth0: Transmit timed out, TxStatus 00 TxFrameId 00, resetting... > Sep 18 09:21:42 localhost kernel: 00 0f45e000 0f45e010 00008001(00) 0fcfd202 8000002a > Sep 18 09:21:42 localhost kernel: 01 0f45e010 0f45e020 00008005(01) 0fcfda02 8000002a > Sep 18 09:21:42 localhost kernel: 02 0f45e020 0f45e030 00008009(02) 0fcfe202 8000002a > Sep 18 09:21:42 localhost kernel: 03 0f45e030 0f45e040 0000800d(03) 0fcfea02 8000002a > Sep 18 09:21:42 localhost kernel: 04 0f45e040 0f45e050 00008011(04) 0fcfe802 8000002a > Sep 18 09:21:42 localhost kernel: 05 0f45e050 0f45e060 00008015(05) 0fcfe402 8000002a > Sep 18 09:21:42 localhost kernel: 06 0f45e060 0f45e070 00008019(06) 0fcfec02 8000002a > Sep 18 09:21:42 localhost kernel: 07 0f45e070 00000000 0000801d(07) 0fcfe602 8000002a > Sep 18 09:21:42 localhost kernel: 08 0f45e080 0f45e090 00018021(08) 00000000 00000000 > Sep 18 09:21:42 localhost kernel: 09 0f45e090 0f45e0a0 00018025(09) 00000000 00000000 > Sep 18 09:21:42 localhost kernel: 0a 0f45e0a0 0f45e0b0 00008029(0a) 0f8ec802 8000002a > Sep 18 09:21:42 localhost kernel: 0b 0f45e0b0 0f45e0c0 0000802d(0b) 0f867802 8000002a > Sep 18 09:21:42 localhost kernel: 0c 0f45e0c0 0f45e0d0 00008031(0c) 0f867a02 8000002a > Sep 18 09:21:42 localhost kernel: 0d 0f45e0d0 0f45e0e0 00008035(0d) 0fcf5602 8000002a > Sep 18 09:21:42 localhost kernel: 0e 0f45e0e0 0f45e0f0 00008039(0e) 0fcf5c02 8000002a > Sep 18 09:21:42 localhost kernel: 0f 0f45e0f0 0f45e100 0000803d(0f) 0fcf5202 8000002a > Sep 18 09:21:42 localhost kernel: 10 0f45e100 0f45e110 00008041(10) 0fcf5e02 8000002a > Sep 18 09:21:42 localhost kernel: 11 0f45e110 0f45e120 00008045(11) 0fcf5802 8000002a > Sep 18 09:21:42 localhost kernel: 12 0f45e120 0f45e130 00008049(12) 0fcf5402 8000002a > Sep 18 09:21:42 localhost kernel: 13 0f45e130 0f45e140 0000804d(13) 0fcf5a02 8000002a > Sep 18 09:21:42 localhost kernel: 14 0f45e140 0f45e150 00008051(14) 0f885c02 8000002a > Sep 18 09:21:42 localhost kernel: 15 0f45e150 0f45e160 00008055(15) 0f885a02 8000002a > Sep 18 09:21:42 localhost kernel: 16 0f45e160 0f45e170 00008059(16) 0f885602 8000002a > Sep 18 09:21:42 localhost kernel: 17 0f45e170 0f45e180 0000805d(17) 0f881a02 8000002a > Sep 18 09:21:42 localhost kernel: 18 0f45e180 0f45e190 00008061(18) 0f881402 8000002a > Sep 18 09:21:42 localhost kernel: 19 0f45e190 0f45e1a0 00008065(19) 0f881e02 8000002a > Sep 18 09:21:42 localhost kernel: 1a 0f45e1a0 0f45e1b0 00008069(1a) 0f881602 8000002a > Sep 18 09:21:42 localhost kernel: 1b 0f45e1b0 0f45e1c0 0000806d(1b) 0fcfc202 8000002a > Sep 18 09:21:42 localhost kernel: 1c 0f45e1c0 0f45e1d0 00008071(1c) 0fcfd802 8000002a > Sep 18 09:21:42 localhost kernel: 1d 0f45e1d0 0f45e1e0 00008075(1d) 0fcfde02 8000002a > Sep 18 09:21:42 localhost kernel: 1e 0f45e1e0 0f45e1f0 00008079(1e) 0fcfdc02 8000002a > Sep 18 09:21:42 localhost kernel: 1f 0f45e1f0 0f45e000 0000807d(1f) 0fcfd402 8000002a > Sep 18 09:21:42 localhost kernel: TxListPtr=0f45e0a0 netif_queue_stopped=1 > Sep 18 09:21:42 localhost kernel: cur_tx=40(08) dirty_tx=10(0a) > Sep 18 09:21:42 localhost kernel: cur_rx=14 dirty_rx=14 > Sep 18 09:21:42 localhost kernel: cur_task=40 from lspci (note, the pci-bridge is on the card): > 0000:00:0f.0 PCI bridge: Intel Corp. 21152 PCI-to-PCI Bridge (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64, Cache Line Size: 0x08 (32 bytes) > Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 > I/O behind bridge: 00009000-0000bfff > Memory behind bridge: efe00000-efefffff > Prefetchable memory behind bridge: 00000000e9b00000-00000000e9b00000 > BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- > Capabilities: [dc] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Bridge: PM- B3+ > 00: 86 80 52 b1 07 00 90 02 00 00 04 06 08 40 01 00 > 10: 00 00 00 00 00 00 00 00 00 02 02 40 91 b1 80 22 > 20: e0 ef e0 ef b1 e9 b1 e9 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 00 03 00 > 40: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 3e 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 00 > e0: 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 0000:02:04.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 12) > Subsystem: D-Link System Inc DFE-580TX > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes) > Interrupt: pin A routed to IRQ 10 > Region 0: I/O ports at bc00 [size=128] > Expansion ROM at efef0000 [disabled] [size=64K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=2 PME- > 00: 86 11 02 10 17 00 10 02 12 00 00 02 08 40 00 00 > 10: 01 bc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 12 10 > 30: 00 00 ef ef 50 00 00 00 00 00 00 00 0a 01 0a 0a > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 01 00 02 f6 00 40 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 0000:02:05.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 12) > Subsystem: D-Link System Inc DFE-580TX > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes) > Interrupt: pin A routed to IRQ 12 > Region 0: I/O ports at b800 [size=128] > Expansion ROM at efee0000 [disabled] [size=64K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=2 PME- > 00: 86 11 02 10 17 00 10 02 12 00 00 02 08 40 00 00 > 10: 01 b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 12 10 > 30: 00 00 ee ef 50 00 00 00 00 00 00 00 0c 01 0a 0a > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 01 00 02 f6 00 40 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 0000:02:06.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 12) > Subsystem: D-Link System Inc DFE-580TX > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes) > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at b400 [size=128] > Expansion ROM at efed0000 [disabled] [size=64K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=2 PME- > 00: 86 11 02 10 17 00 10 02 12 00 00 02 08 40 00 00 > 10: 01 b4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 12 10 > 30: 00 00 ed ef 50 00 00 00 00 00 00 00 0b 01 0a 0a > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 01 00 02 f6 00 40 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 0000:02:07.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 12) > Subsystem: D-Link System Inc DFE-580TX > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes) > Interrupt: pin A routed to IRQ 9 > Region 0: I/O ports at b000 [size=128] > Expansion ROM at efec0000 [disabled] [size=64K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=2 PME- > 00: 86 11 02 10 17 00 10 02 12 00 00 02 08 40 00 00 > 10: 01 b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 12 10 > 30: 00 00 ec ef 50 00 00 00 00 00 00 00 09 01 0a 0a > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 01 00 02 f6 00 40 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 From kleptog@svana.org Thu Sep 23 11:34:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 11:34:51 -0700 (PDT) Received: from svana.org (mail@svana.org [203.20.62.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NIYgJo027696 for ; Thu, 23 Sep 2004 11:34:43 -0700 Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 1CAYPx-0005Cg-00; Fri, 24 Sep 2004 04:34:09 +1000 Date: Fri, 24 Sep 2004 04:34:09 +1000 From: Martijn van Oosterhout To: James Chapman Cc: Herbert Xu , bcrl@kvack.org, davem@davemloft.net, netdev@oss.sgi.com, mostrows@styx.uwaterloo.ca Subject: Re: PPP-over-L2TP kernel support, new patch for review Message-ID: <20040923183355.GB13753@svana.org> Reply-To: Martijn van Oosterhout References: <1095888533.4151ee95ed23c@www.katalix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <1095888533.4151ee95ed23c@www.katalix.com> User-Agent: Mutt/1.3.28i X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6 X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522 48A7 6394 F08A 0DC6 7BE6 X-PGP-Key-URL: X-archive-position: 9363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kleptog@svana.org Precedence: bulk X-list: netdev Content-Length: 3394 Lines: 81 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2004 at 10:28:53PM +0100, James Chapman wrote: > Hi Herbert, >=20 > Quoting Herbert Xu : >=20 > > James Chapman wrote: > > > > > > The biggest difference in our approaches is that Martijn and I use a > > > PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel > > > socket while Ben uses a new AF_L2TP tunnel socket and no separate > > > socket per session. Both have their merits. > > > > Can you elaborate on the merits of having a socket? It would seem to me > > that not having a socket is a lot more scalable. After all IPsec doesn= 't > > carry a socket around per session. >=20 > What I meant by "both have their merits" is that both general > approaches have their merits. It's a shame Martijn isn't available > right now (he's moving home to a new country) as he came up with the > initial kernel driver concept. Anyway, I'm sure he'll chime in later. Ok, I've just cut off the power connector of my laptop and whacked a new one on, so I'm just beginning ot catch up. I'd just like to comment that the socket-per-connection is part of the kernel generic-PPP support. The PPP packets not handled by the kernel need to be transported somewhere and I guess the decision was made to pass it though a PPPoX socket. If you want to get away from the one socket per session model, you can't use PPPoX sockets. You need something in the kernel to hold the ppp generic data structure. I imagine Ben's uses an array in the kernel and passes stuff to userspace in a way so the user-space daemon can identify the session it belongs to. I don't see why this PPPoX solution won't scale to thousands of sessions. Sure, you get one socket per session plus one socket per tunnel, but IRC servers run with thousands of sockets and the costs here aren't much more. Sure, someone needs to write a PPP daemon that can handle multiple simultaneous connections, but that's orthoginal to the issue at hand. If you want to remove the one socket per session requirement, someone needs to redo the PPPoX support. In fact, the whole PPPoX idea seems to have been a bit of a dud since even with it there it seems to be better to just invent your own character device/protocal family/etc than use it. When I started I just used the PPPoX stuff since I figured that was going to be the "supported" way to use the in-kernel PPP stuff. Also, if Ben's stuff is handling the case of taking seperate L2TP sessions and merging them through to another LNS server, then it is a completely orthoginal system, since that doesn't require full PPP support anyway... Have a nice day, --=20 Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFBUxcTY5Twig3Ge+YRApikAKDZMJAQ26cZmDmcGfIhXr/fZfaf3gCeItzA tbK+5tvpBzM7zlzy3nJjXI0= =MlDW -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From chas@cmf.nrl.navy.mil Thu Sep 23 11:41:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 11:42:03 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NIfvah028089 for ; Thu, 23 Sep 2004 11:41:57 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8NIfaoj018070; Thu, 23 Sep 2004 14:41:36 -0400 (EDT) Message-Id: <200409231841.i8NIfaoj018070@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH][ATM]: [eni] fix __iomem related warnings Reply-To: chas3@users.sourceforge.net Date: Thu, 23 Sep 2004 14:41:38 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 10388 Lines: 321 dave, this one was quite troublesome to fix. please apply to 2.x thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 10:29:01-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [eni] fix __iomem related warnings # diff -Nru a/drivers/atm/eni.c b/drivers/atm/eni.c --- a/drivers/atm/eni.c 2004-09-23 14:38:34 -04:00 +++ b/drivers/atm/eni.c 2004-09-23 14:38:34 -04:00 @@ -173,7 +173,7 @@ int i; for (i = 0; i < eni_dev->free_len; i++) - printk(KERN_DEBUG " %d: 0x%lx %d\n",i, + printk(KERN_DEBUG " %d: %p %d\n",i, eni_dev->free_list[i].start, 1 << eni_dev->free_list[i].order); } @@ -191,19 +191,19 @@ printk(KERN_NOTICE "TX buffers\n"); for (i = 0; i < NR_CHAN; i++) if (eni_dev->tx[i].send) - printk(KERN_NOTICE " TX %d @ 0x%lx: %ld\n",i, + printk(KERN_NOTICE " TX %d @ %p: %ld\n",i, eni_dev->tx[i].send,eni_dev->tx[i].words*4); printk(KERN_NOTICE "RX buffers\n"); for (i = 0; i < 1024; i++) if (eni_dev->rx_map[i] && ENI_VCC(eni_dev->rx_map[i])->rx) - printk(KERN_NOTICE " RX %d @ 0x%lx: %ld\n",i, + printk(KERN_NOTICE " RX %d @ %p: %ld\n",i, ENI_VCC(eni_dev->rx_map[i])->recv, ENI_VCC(eni_dev->rx_map[i])->words*4); printk(KERN_NOTICE "----\n"); } -static void eni_put_free(struct eni_dev *eni_dev,unsigned long start, +static void eni_put_free(struct eni_dev *eni_dev, void __iomem *start, unsigned long size) { struct eni_free *list; @@ -215,17 +215,17 @@ len = eni_dev->free_len; while (size) { if (len >= eni_dev->free_list_size) { - printk(KERN_CRIT "eni_put_free overflow (0x%lx,%ld)\n", + printk(KERN_CRIT "eni_put_free overflow (%p,%ld)\n", start,size); break; } - for (order = 0; !((start | size) & (1 << order)); order++); + for (order = 0; !(((unsigned long)start | size) & (1 << order)); order++); if (MID_MIN_BUF_SIZE > (1 << order)) { printk(KERN_CRIT "eni_put_free: order %d too small\n", order); break; } - list[len].start = start; + list[len].start = (void __iomem *) start; list[len].order = order; len++; start += 1 << order; @@ -236,10 +236,10 @@ } -static unsigned long eni_alloc_mem(struct eni_dev *eni_dev,unsigned long *size) +static void __iomem *eni_alloc_mem(struct eni_dev *eni_dev, unsigned long *size) { struct eni_free *list; - unsigned long start; + void __iomem *start; int len,i,order,best_order,index; list = eni_dev->free_list; @@ -273,7 +273,7 @@ } -static void eni_free_mem(struct eni_dev *eni_dev,unsigned long start, +static void eni_free_mem(struct eni_dev *eni_dev, void __iomem *start, unsigned long size) { struct eni_free *list; @@ -283,20 +283,20 @@ list = eni_dev->free_list; len = eni_dev->free_len; for (order = -1; size; order++) size >>= 1; - DPRINTK("eni_free_mem: 0x%lx+0x%lx (order %d)\n",start,size,order); + DPRINTK("eni_free_mem: %p+0x%lx (order %d)\n",start,size,order); for (i = 0; i < len; i++) - if (list[i].start == (start^(1 << order)) && + if (((unsigned long) list[i].start) == ((unsigned long)start^(1 << order)) && list[i].order == order) { DPRINTK("match[%d]: 0x%lx/0x%lx(0x%x), %d/%d\n",i, list[i].start,start,1 << order,list[i].order,order); list[i] = list[--len]; - start &= ~(unsigned long) (1 << order); + start = (void __iomem *) ((unsigned long) start & ~(unsigned long) (1 << order)); order++; i = -1; continue; } if (len >= eni_dev->free_list_size) { - printk(KERN_ALERT "eni_free_mem overflow (0x%lx,%d)\n",start, + printk(KERN_ALERT "eni_free_mem overflow (%p,%d)\n",start, order); return; } @@ -333,7 +333,7 @@ printk(KERN_ALERT " host descr 0x%lx, rx pos 0x%lx, descr value " "0x%x\n",eni_vcc->descr,eni_vcc->rx_pos, (unsigned) readl(eni_vcc->recv+eni_vcc->descr*4)); - printk(KERN_ALERT " last 0x%p, servicing %d\n",eni_vcc->last, + printk(KERN_ALERT " last %p, servicing %d\n",eni_vcc->last, eni_vcc->servicing); EVENT("---dump ends here---\n",0,0); printk(KERN_NOTICE "---recent events---\n"); @@ -617,7 +617,8 @@ static inline int rx_vcc(struct atm_vcc *vcc) { - unsigned long vci_dsc,tmp; + void __iomem *vci_dsc; + unsigned long tmp; struct eni_vcc *eni_vcc; eni_vcc = ENI_VCC(vcc); @@ -728,7 +729,7 @@ struct eni_vcc *eni_vcc; struct atm_vcc *vcc; struct sk_buff *skb; - unsigned long vci_dsc; + void __iomem *vci_dsc; int first; eni_dev = ENI_DEV(dev); @@ -808,7 +809,7 @@ static int open_rx_second(struct atm_vcc *vcc) { - unsigned long here; + void __iomem *here; struct eni_dev *eni_dev; struct eni_vcc *eni_vcc; unsigned long size; @@ -840,7 +841,7 @@ static void close_rx(struct atm_vcc *vcc) { DECLARE_WAITQUEUE(wait,current); - unsigned long here; + void __iomem *here; struct eni_dev *eni_dev; struct eni_vcc *eni_vcc; @@ -1289,7 +1290,8 @@ struct eni_dev *eni_dev = ENI_DEV(vcc->dev); struct eni_vcc *eni_vcc = ENI_VCC(vcc); struct eni_tx *tx; - unsigned long size,mem; + unsigned long size; + void __iomem *mem; int rate,ubr,unlimited,new_tx; int pre,res,order; int error; @@ -1687,9 +1689,9 @@ #undef GET_SEPROM -static int __devinit get_esi_fpga(struct atm_dev *dev,unsigned long base) +static int __devinit get_esi_fpga(struct atm_dev *dev, void __iomem *base) { - unsigned long mac_base; + void __iomem *mac_base; int i; mac_base = base+EPROM_SIZE-sizeof(struct midway_eprom); @@ -1703,7 +1705,8 @@ struct midway_eprom *eprom; struct eni_dev *eni_dev; struct pci_dev *pci_dev; - unsigned long real_base,base; + unsigned long real_base; + void __iomem *base; unsigned char revision; int error,i,last; @@ -1730,13 +1733,13 @@ } printk(KERN_NOTICE DEV_LABEL "(itf %d): rev.%d,base=0x%lx,irq=%d,", dev->number,revision,real_base,eni_dev->irq); - if (!(base = (unsigned long) ioremap_nocache(real_base,MAP_MAX_SIZE))) { + if (!(base = ioremap_nocache(real_base,MAP_MAX_SIZE))) { printk("\n"); printk(KERN_ERR DEV_LABEL "(itf %d): can't set up page " "mapping\n",dev->number); return error; } - eni_dev->base_diff = real_base-base; + eni_dev->base_diff = real_base - (unsigned long) base; /* id may not be present in ASIC Tonga boards - check this @@@ */ if (!eni_dev->asic) { eprom = (struct midway_eprom *) (base+EPROM_SIZE-sizeof(struct @@ -1790,7 +1793,9 @@ static int __devinit eni_start(struct atm_dev *dev) { struct eni_dev *eni_dev; - unsigned long buf,buffer_mem; + + void __iomem *buf; + unsigned long buffer_mem; int error; DPRINTK(">eni_start\n"); @@ -1828,7 +1833,7 @@ tasklet_init(&eni_dev->task,eni_tasklet,(unsigned long) dev); eni_dev->events = 0; /* initialize memory management */ - buffer_mem = eni_dev->mem-(buf-eni_dev->ram); + buffer_mem = eni_dev->mem - (buf - eni_dev->ram); eni_dev->free_list_size = buffer_mem/MID_MIN_BUF_SIZE/2; eni_dev->free_list = (struct eni_free *) kmalloc( sizeof(struct eni_free)*(eni_dev->free_list_size+1),GFP_KERNEL); @@ -1955,7 +1960,7 @@ */ tasklet_disable(&eni_dev->task); skb_queue_walk(&eni_dev->tx_queue, skb) { - unsigned long dsc; + void __iomem *dsc; if (ATM_SKB(skb)->vcc != vcc) continue; dsc = tx->send+ENI_PRV_POS(skb)*4; @@ -2136,9 +2141,9 @@ if (!tx->send) continue; if (!--left) { - return sprintf(page,"tx[%d]: 0x%06lx-0x%06lx " + return sprintf(page,"tx[%d]: 0x%ld-0x%ld " "(%6ld bytes), rsv %d cps, shp %d cps%s\n",i, - tx->send-eni_dev->ram, + (unsigned long) (tx->send - eni_dev->ram), tx->send-eni_dev->ram+tx->words*4-1,tx->words*4, tx->reserved,tx->shaping, tx == eni_dev->ubr ? " (UBR)" : ""); @@ -2162,9 +2167,9 @@ if (--left) continue; length = sprintf(page,"vcc %4d: ",vcc->vci); if (eni_vcc->rx) { - length += sprintf(page+length,"0x%06lx-0x%06lx " + length += sprintf(page+length,"0x%ld-0x%ld " "(%6ld bytes)", - eni_vcc->recv-eni_dev->ram, + (unsigned long) (eni_vcc->recv - eni_dev->ram), eni_vcc->recv-eni_dev->ram+eni_vcc->words*4-1, eni_vcc->words*4); if (eni_vcc->tx) length += sprintf(page+length,", "); @@ -2183,8 +2188,8 @@ unsigned long offset; if (--left) continue; - offset = eni_dev->ram+eni_dev->base_diff; - return sprintf(page,"free 0x%06lx-0x%06lx (%6d bytes)\n", + offset = (unsigned long) eni_dev->ram+eni_dev->base_diff; + return sprintf(page,"free %p-%p (%6d bytes)\n", fe->start-offset,fe->start-offset+(1 << fe->order)-1, 1 << fe->order); } diff -Nru a/drivers/atm/eni.h b/drivers/atm/eni.h --- a/drivers/atm/eni.h 2004-09-23 14:38:34 -04:00 +++ b/drivers/atm/eni.h 2004-09-23 14:38:34 -04:00 @@ -33,12 +33,12 @@ struct eni_free { - unsigned long start; /* counting in bytes */ + void __iomem *start; /* counting in bytes */ int order; }; struct eni_tx { - unsigned long send; /* base, 0 if unused */ + void __iomem *send; /* base, 0 if unused */ int prescaler; /* shaping prescaler */ int resolution; /* shaping divider */ unsigned long tx_pos; /* current TX write position */ @@ -51,7 +51,7 @@ struct eni_vcc { int (*rx)(struct atm_vcc *vcc); /* RX function, NULL if none */ - unsigned long recv; /* receive buffer */ + void __iomem *recv; /* receive buffer */ unsigned long words; /* its size in words */ unsigned long descr; /* next descriptor (RX) */ unsigned long rx_pos; /* current RX descriptor pos */ @@ -72,13 +72,13 @@ u32 events; /* pending events */ /*-------------------------------- base pointers into Midway address space */ - unsigned long phy; /* PHY interface chip registers */ - unsigned long reg; /* register base */ - unsigned long ram; /* RAM base */ - unsigned long vci; /* VCI table */ - unsigned long rx_dma; /* RX DMA queue */ - unsigned long tx_dma; /* TX DMA queue */ - unsigned long service; /* service list */ + void __iomem *phy; /* PHY interface chip registers */ + void __iomem *reg; /* register base */ + void __iomem *ram; /* RAM base */ + void __iomem *vci; /* VCI table */ + void __iomem *rx_dma; /* RX DMA queue */ + void __iomem *tx_dma; /* TX DMA queue */ + void __iomem *service; /* service list */ /*-------------------------------- TX part */ struct eni_tx tx[NR_CHAN]; /* TX channels */ struct eni_tx *ubr; /* UBR channel */ From chas@cmf.nrl.navy.mil Thu Sep 23 11:43:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 11:43:31 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NIhQ5Q028443 for ; Thu, 23 Sep 2004 11:43:26 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8NIh9sm018124; Thu, 23 Sep 2004 14:43:09 -0400 (EDT) Message-Id: <200409231843.i8NIh9sm018124@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH][ATM]: [ambassador] remove warnings related to unused variables Reply-To: chas3@users.sourceforge.net Date: Thu, 23 Sep 2004 14:43:11 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 928 Lines: 29 dave, please apply to 2.x. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 10:37:44-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [ambassador] remove warnings related to unused variables # diff -Nru a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c --- a/drivers/atm/ambassador.c 2004-09-23 14:38:52 -04:00 +++ b/drivers/atm/ambassador.c 2004-09-23 14:38:52 -04:00 @@ -2291,11 +2291,10 @@ // read resources from PCI configuration space u8 irq = pci_dev->irq; - u32 * membase = bus_to_virt (pci_resource_start (pci_dev, 0)); - u32 iobase = pci_resource_start (pci_dev, 1); PRINTD (DBG_INFO, "found Madge ATM adapter (amb) at" - " IO %x, IRQ %u, MEM %p", iobase, irq, membase); + " IO %x, IRQ %u, MEM %p", pci_resource_start(pci_dev, 1), + irq, bus_to_virt(pci_resource_start(pci_dev, 0))); // check IO region err = pci_request_region(pci_dev, 1, DEV_LABEL); From chas@cmf.nrl.navy.mil Thu Sep 23 11:44:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 11:44:23 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NIiIUG028784 for ; Thu, 23 Sep 2004 11:44:19 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i8NIi0gD018156; Thu, 23 Sep 2004 14:44:00 -0400 (EDT) Message-Id: <200409231844.i8NIi0gD018156@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH][ATM]: [fore200e] fix warnings related to dma_addr_t Reply-To: chas3@users.sourceforge.net Date: Thu, 23 Sep 2004 14:44:02 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 9366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 890 Lines: 24 dave, please apply to 2.6. thanks! # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 10:50:50-04:00 chas@relax.cmf.nrl.navy.mil # [ATM]: [fore200e] fix warnings related to dma_addr_t # diff -Nru a/drivers/atm/fore200e.h b/drivers/atm/fore200e.h --- a/drivers/atm/fore200e.h 2004-09-23 14:39:11 -04:00 +++ b/drivers/atm/fore200e.h 2004-09-23 14:39:11 -04:00 @@ -565,7 +565,7 @@ typedef struct chunk { void* alloc_addr; /* base address of allocated chunk */ void* align_addr; /* base address of aligned chunk */ - u32 dma_addr; /* DMA address of aligned chunk */ + dma_addr_t dma_addr; /* DMA address of aligned chunk */ int direction; /* direction of DMA mapping */ u32 alloc_size; /* length of allocated chunk */ u32 align_size; /* length of aligned chunk */ From mingo@elte.hu Thu Sep 23 12:16:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 12:16:58 -0700 (PDT) Received: from mx2.elte.hu (scanner2.mail.elte.hu [157.181.151.9]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NJGpZm029797 for ; Thu, 23 Sep 2004 12:16:52 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx2.elte.hu (Postfix) with ESMTP id B3E8C26FEE3; Thu, 23 Sep 2004 21:10:42 +0200 (CEST) Received: by chiara.elte.hu (Postfix, from userid 17806) id F2A0D1FC2; Thu, 23 Sep 2004 21:16:27 +0200 (CEST) Date: Thu, 23 Sep 2004 21:18:20 +0200 From: Ingo Molnar To: Herbert Xu Cc: Lukas Hejtmanek , akpm@osdl.org, linux-kernel@vger.kernel.org, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: 2.6.9-rc2-mm2 fn_hash_insert oops Message-ID: <20040923191819.GA30482@elte.hu> References: <20040923103723.GA12145@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 X-archive-position: 9367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mingo@elte.hu Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 36 * Herbert Xu wrote: > Lukas Hejtmanek wrote: > > > > However there is still the issue with endless loop in fn_hash_delete :( > > Same problem, same fix. Can someone think of a generic fix to > list_for_each_*? > > Signed-off-by: Herbert Xu did the trick here too. on a related note, e100 ifup still gives: enable_irq(16) unbalanced from c021afa5 [] enable_irq+0xd0/0xe0 [] e100_up+0xf5/0x1e0 [] e100_up+0xf5/0x1e0 [] e100_intr+0x0/0x130 [] e100_open+0x2d/0x80 [] handle_mm_fault+0x14a/0x1f0 [] dev_open+0x85/0xa0 [] dev_mc_upload+0x24/0x40 [] dev_change_flags+0x53/0x130 [] devinet_ioctl+0x26b/0x6c0 [] inet_ioctl+0x66/0xb0 [] sock_ioctl+0xc9/0x290 [] sys_ioctl+0xca/0x230 [] do_page_fault+0x0/0x6f0 [] sysenter_past_esp+0x52/0x71 this is with Andrew's current tree (x.bz2). Ingo From davem@davemloft.net Thu Sep 23 12:18:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 12:18:39 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NJIWf2030092 for ; Thu, 23 Sep 2004 12:18:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAZ5H-0006ii-00; Thu, 23 Sep 2004 12:16:51 -0700 Date: Thu, 23 Sep 2004 12:16:51 -0700 From: "David S. Miller" To: Pablo Neira Cc: hadi@cyberus.ca, herbert@gondor.apana.org.au, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040923121651.51a58cf2.davem@davemloft.net> In-Reply-To: <4152EE68.4030803@eurodev.net> References: <414DF11C.1080505@eurodev.net> <20040919215915.GB9573@gondor.apana.org.au> <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1350 Lines: 34 On Thu, 23 Sep 2004 17:40:24 +0200 Pablo Neira wrote: > Initially we could allocate a skb with size NLMSG_GOODSIZE, then after > all the information has been added, we could use a function (skb_*) > which allocates a new buffer headroom, memcpy the old skb headroom and > release it, so we trim the useless part of the headroom. This make us > waste some extra jiffies with memcpy's but we could save same space in > the queue. Does such skb_* function exist? No such function exists. Such a function would need to modify skb->truesize and that is very dangerous. People using such a routine would need to be _extremely_ careful since if the skb being worked on is on a socket queue, changing skb->truesize is going to mess up socket buffer accounting later when the skb gets freed and the socket buffer space liberated. That doesn't apply to what you're trying to do here, of course. Simpler would be: 1) For each netlink socket, allocate a page, much like TCP sockets do. 2) Construct the netlink response in this page sized buffer, keeping track of how much of the page is actually used. 3) At the end, allocate the skb with the necessary length, copy into the skb from the page buffer. 4) Since the RTNL semaphore is held during the length of these operations, the per-socket page needs no locking. From johnpol@2ka.mipt.ru Thu Sep 23 12:52:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 12:53:01 -0700 (PDT) Received: from mailer.campus.mipt.ru (mailer.campus.mipt.ru [194.85.82.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NJqnnQ001911 for ; Thu, 23 Sep 2004 12:52:52 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by mailer.campus.mipt.ru (8.13.1/8.13.1) with SMTP id i8NJquuk021888; Thu, 23 Sep 2004 23:52:56 +0400 Date: Fri, 24 Sep 2004 00:07:39 +0400 From: Evgeniy Polyakov To: Andrew Morton Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". Message-Id: <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> In-Reply-To: <20040921124623.GA6942@uganda.factory.vocord.ru> References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 30514 Lines: 1179 Connector driver adds possibility to connect various agents using netlink based network. One must register callback and identificator. When driver receives special netlink message with appropriate identificator, appropriate callback will be called. From the userspace point of view it's quite straightforward: socket(); bind(); send(); recv(); But if kernespace want to use full power of such connections, driver writer must create special sockets, must know about struct skbuff handling... Following driver allows any kernelspace agents to use netlink based networking for inter-process communication in a significantly easier way: register_callback(id, callback_function); cn_connector_send(); where id is currently two 32bit values which can be considered as name + id. Current driver offers just transport layer but with fixed header. Recommended protocol using such header is following: msg->seq and msg->ack are used to determine message genealogy. When someone sends message it puts there locally unique sequence and random acknowledge numbers. Sequence number may be copied into nlmsghdr->nlmsg_seq too. Sequence number is incremented with each message to be sent. If we expect reply to our message, then sequence number in received message MUST be the same as in original message, and acknowledge number MUST be the same + 1. If we receive message and it's sequence number is not equal to one we are expecting, then it is new message. If we receive message and it's sequence number is the same as one we are expecting, but it's acknowledge is not equal acknowledge number in original message + 1, then it is new message. Obviously, protocol header contains above id. As a bonus, suggested by Jamal Hadi Salim in netdev@ maillist, connector driver allows event notification in the following form: kernel driver or userspace process can ask connector to notify it when selected id's will be turned on or off(registered or unregistered it's callback). It is done by sending special command to connector driver(it also registers itself with id={-1, -1}). Created schema contains large reserve for different future extensions. All previous mentioned problems are successfully resolved. Signed-off-by: Evgeniy Polyakov --- linux-2.6/drivers/Makefile.orig 2004-09-12 01:14:07.000000000 +0400 +++ linux-2.6/drivers/Makefile 2004-09-11 22:49:32.000000000 +0400 @@ -43,6 +43,7 @@ obj-$(CONFIG_I2O) += message/ obj-$(CONFIG_I2C) += i2c/ obj-$(CONFIG_W1) += w1/ +obj-$(CONFIG_CONNECTOR) += connector/ obj-$(CONFIG_PHONE) += telephony/ obj-$(CONFIG_MD) += md/ obj-$(CONFIG_BT) += bluetooth/ --- linux-2.6/drivers/Kconfig 2004-09-21 13:56:46.000000000 +0400 +++ linux-2.6/drivers/Kconfig.orig 2004-09-21 13:55:18.000000000 +0400 @@ -44,6 +44,8 @@ source "drivers/w1/Kconfig" +source "drivers/connector/Kconfig" + source "drivers/misc/Kconfig" source "drivers/media/Kconfig" diff -Nru /tmp/empty/Kconfig linux-2.6/drivers/connector/Kconfig --- /tmp/empty/Kconfig 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/Kconfig 2004-09-09 08:43:37.000000000 +0400 @@ -0,0 +1,13 @@ +menu "Connector - unified userspace <-> kernelspace linker" + +config CONNECTOR + tristate "Connector - unified userspace <-> kernelspace linker" + depends on NET + ---help--- + This is unified userspace <-> kernelspace connector working on top + of the netlink socket protocol. + + Connector support can also be built as a module. If so, the module + will be called connector.ko. + +endmenu diff -Nru /tmp/empty/Makefile linux-2.6/drivers/connector/Makefile --- /tmp/empty/Makefile 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/Makefile 2004-09-10 08:59:26.000000000 +0400 @@ -0,0 +1,2 @@ +obj-$(CONFIG_CONNECTOR) += cn.o +cn-objs := cn_queue.o connector.o diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.000000000 +0400 @@ -0,0 +1,218 @@ +/* + * cn_queue.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "cn_queue.h" + +static void cn_queue_wrapper(void *data) +{ + struct cn_callback_entry *cbq = (struct cn_callback_entry *)data; + + atomic_inc(&cbq->cb->refcnt); + cbq->cb->callback(cbq->cb->priv); + atomic_dec(&cbq->cb->refcnt); + + cbq->destruct_data(cbq->ddata); +} + +static struct cn_callback_entry *cn_queue_alloc_callback_entry(struct + cn_callback *cb) +{ + struct cn_callback_entry *cbq; + + cbq = kmalloc(sizeof(*cbq), GFP_KERNEL); + if (!cbq) { + printk(KERN_ERR "Failed to create new callback queue.\n"); + return NULL; + } + + memset(cbq, 0, sizeof(*cbq)); + + cbq->cb = cb; + + INIT_WORK(&cbq->work, &cn_queue_wrapper, cbq); + + return cbq; +} + +static void cn_queue_free_callback(struct cn_callback_entry *cbq) +{ + cancel_delayed_work(&cbq->work); + + while (atomic_read(&cbq->cb->refcnt)) { + printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n", + cbq->pdev->name, atomic_read(&cbq->cb->refcnt)); + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } + + kfree(cbq); +} + +int cn_cb_equal(struct cb_id *i1, struct cb_id *i2) +{ + return ((i1->idx == i2->idx) && (i1->val == i2->val)); +} + +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb) +{ + struct cn_callback_entry *cbq, *n, *__cbq; + int found = 0; + + cbq = cn_queue_alloc_callback_entry(cb); + if (!cbq) + return -ENOMEM; + + atomic_inc(&dev->refcnt); + cbq->pdev = dev; + + spin_lock(&dev->queue_lock); + list_for_each_entry_safe(__cbq, n, &dev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &cb->id)) { + found = 1; + break; + } + } + if (!found) { + atomic_set(&cbq->cb->refcnt, 1); + list_add_tail(&cbq->callback_entry, &dev->queue_list); + } + spin_unlock(&dev->queue_lock); + + if (found) { + atomic_dec(&dev->refcnt); + atomic_set(&cbq->cb->refcnt, 0); + cn_queue_free_callback(cbq); + return -EINVAL; + } + + cbq->nls = dev->nls; + cbq->seq = 0; + cbq->group = ++dev->netlink_groups; + + return 0; +} + +void cn_queue_del_callback(struct cn_queue_dev *dev, struct cn_callback *cb) +{ + struct cn_callback_entry *cbq = NULL, *n; + int found = 0; + + spin_lock(&dev->queue_lock); + list_for_each_entry_safe(cbq, n, &dev->queue_list, callback_entry) { + if (cn_cb_equal(&cbq->cb->id, &cb->id)) { + list_del(&cbq->callback_entry); + found = 1; + break; + } + } + spin_unlock(&dev->queue_lock); + + if (found) { + atomic_dec(&cbq->cb->refcnt); + cn_queue_free_callback(cbq); + atomic_dec(&dev->refcnt); + } +} + +struct cn_queue_dev *cn_queue_alloc_dev(char *name, struct sock *nls) +{ + struct cn_queue_dev *dev; + + dev = kmalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) { + printk(KERN_ERR "%s: Failed to allocte new struct cn_queue_dev.\n", + name); + return NULL; + } + + memset(dev, 0, sizeof(*dev)); + + snprintf(dev->name, sizeof(dev->name), "%s", name); + + atomic_set(&dev->refcnt, 0); + INIT_LIST_HEAD(&dev->queue_list); + spin_lock_init(&dev->queue_lock); + + dev->nls = nls; + dev->netlink_groups = 0; + + dev->cn_queue = create_workqueue(dev->name); + if (!dev->cn_queue) { + printk(KERN_ERR "Failed to create %s queue.\n", dev->name); + kfree(dev); + return NULL; + } + + return dev; +} + +void cn_queue_free_dev(struct cn_queue_dev *dev) +{ + struct cn_callback_entry *cbq, *n; + + flush_workqueue(dev->cn_queue); + destroy_workqueue(dev->cn_queue); + + spin_lock(&dev->queue_lock); + list_for_each_entry_safe(cbq, n, &dev->queue_list, callback_entry) { + list_del(&cbq->callback_entry); + atomic_dec(&cbq->cb->refcnt); + } + spin_unlock(&dev->queue_lock); + + while (atomic_read(&dev->refcnt)) { + printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n", + dev->name, atomic_read(&dev->refcnt)); + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } + + memset(dev, 0, sizeof(*dev)); + kfree(dev); + dev = NULL; +} + +EXPORT_SYMBOL(cn_queue_add_callback); +EXPORT_SYMBOL(cn_queue_del_callback); +EXPORT_SYMBOL(cn_queue_alloc_dev); +EXPORT_SYMBOL(cn_queue_free_dev); diff -Nru /tmp/empty/cn_queue.h linux-2.6/drivers/connector/cn_queue.h --- /tmp/empty/cn_queue.h 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/cn_queue.h 2004-09-21 13:38:57.000000000 +0400 @@ -0,0 +1,90 @@ +/* + * cn_queue.h + * + * 2004 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __CN_QUEUE_H +#define __CN_QUEUE_H + +#include + +struct cb_id +{ + __u32 idx; + __u32 val; +}; + +#ifdef __KERNEL__ + +#include + +#include +#include + +#define CN_CBQ_NAMELEN 32 + +struct cn_queue_dev +{ + atomic_t refcnt; + unsigned char name[CN_CBQ_NAMELEN]; + + struct workqueue_struct *cn_queue; + + struct list_head queue_list; + spinlock_t queue_lock; + + int netlink_groups; + struct sock *nls; +}; + +struct cn_callback +{ + unsigned char name[CN_CBQ_NAMELEN]; + + struct cb_id id; + void (* callback)(void *); + void *priv; + + atomic_t refcnt; +}; + +struct cn_callback_entry +{ + struct list_head callback_entry; + struct cn_callback *cb; + struct work_struct work; + struct cn_queue_dev *pdev; + + void (* destruct_data)(void *); + void *ddata; + + int seq, group; + struct sock *nls; +}; + +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb); +void cn_queue_del_callback(struct cn_queue_dev *dev, struct cn_callback *cb); + +struct cn_queue_dev *cn_queue_alloc_dev(char *name, struct sock *); +void cn_queue_free_dev(struct cn_queue_dev *dev); + +int cn_cb_equal(struct cb_id *, struct cb_id *); + +#endif /* __KERNEL__ */ +#endif /* __CN_QUEUE_H */ diff -Nru /tmp/empty/cn_test.c linux-2.6/drivers/connector/cn_test.c --- /tmp/empty/cn_test.c 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/cn_test.c 2004-09-21 13:38:57.000000000 +0400 @@ -0,0 +1,160 @@ +/* + * cn_test.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include + +#include "connector.h" + +static struct cb_id cn_test_id = { 0x123, 0x456 }; +static char cn_test_name[] = "cn_test"; +static struct sock *nls; + +void cn_test_callback(void *data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + + printk("%s: idx=%x, val=%x, len=%d.\n", + __func__, msg->id.idx, msg->id.val, msg->len); +} + +static int cn_test_want_notify(void) +{ + struct cn_ctl_msg *ctl; + struct cn_notify_req *req; + struct cn_msg *msg = NULL; + int size, size0; + struct sk_buff *skb; + struct nlmsghdr *nlh; + u32 group = 1; + + size0 = sizeof(*msg) + sizeof(*ctl) + 3*sizeof(*req); + + size = NLMSG_SPACE(size0); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + + return -ENOMEM; + } + + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh)); + + msg = (struct cn_msg *)NLMSG_DATA(nlh); + + memset(msg, 0, size0); + + msg->id.idx = -1; + msg->id.val = -1; + msg->seq = 0x123; + msg->ack = 0x345; + msg->len = size0 - sizeof(*msg); + + ctl = (struct cn_ctl_msg *)(msg + 1); + + ctl->idx_notify_num = 1; + ctl->val_notify_num = 2; + ctl->group = group; + ctl->len = msg->len - sizeof(*ctl); + + req = (struct cn_notify_req *)(ctl + 1); + + /* + * Idx. + */ + req->first = cn_test_id.idx; + req->range = 10; + + /* + * Val 0. + */ + req++; + req->first = cn_test_id.val; + req->range = 10; + + /* + * Val 1. + */ + req++; + req->first = cn_test_id.val + 20; + req->range = 10; + + NETLINK_CB(skb).dst_groups = ctl->group; + //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); + netlink_unicast(nls, skb, 0, 0); + + printk(KERN_INFO "Request was sent. Group=0x%x.\n", group); + + return 0; + +nlmsg_failure: + printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); + kfree_skb(skb); + return -EINVAL; +} + +static int cn_test_init(void) +{ + int err; + + nls = netlink_kernel_create(NETLINK_NFLOG, NULL); + if (!nls) { + printk(KERN_ERR "Failed to create new netlink socket(%u).\n", NETLINK_NFLOG); + return -EIO; + } + + err = cn_test_want_notify(); + if (err) + goto err_out; + + err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); + if (err) + goto err_out; + cn_test_id.val++; + err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); + if (err) { + cn_del_callback(&cn_test_id); + goto err_out; + } + + return 0; + +err_out: + if (nls->sk_socket) + sock_release(nls->sk_socket); + + return err; +} + +static void cn_test_fini(void) +{ + cn_del_callback(&cn_test_id); + cn_test_id.val--; + cn_del_callback(&cn_test_id); + if (nls->sk_socket) + sock_release(nls->sk_socket); +} + +module_init(cn_test_init); +module_exit(cn_test_fini); diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c --- /tmp/empty/connector.c 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.000000000 +0400 @@ -0,0 +1,498 @@ +/* + * connector.c + * + * 2004 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include + +#include + +#include "../connector/connector.h" +#include "../connector/cn_queue.h" + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Evgeniy Polyakov "); +MODULE_DESCRIPTION("Generic userspace <-> kernelspace connector."); + +static int unit = NETLINK_NFLOG; +static u32 cn_idx = -1; +static u32 cn_val = -1; + +module_param(unit, int, 0); +module_param(cn_idx, uint, 0); +module_param(cn_val, uint, 0); + +spinlock_t notify_lock = SPIN_LOCK_UNLOCKED; +static LIST_HEAD(notify_list); + +static struct cn_dev cdev; + +/* + * msg->seq and msg->ack are used to determine message genealogy. + * When someone sends message it puts there locally unique sequence + * and random acknowledge numbers. + * Sequence number may be copied into nlmsghdr->nlmsg_seq too. + * + * Sequence number is incremented with each message to be sent. + * + * If we expect reply to our message, + * then sequence number in received message MUST be the same as in original message, + * and acknowledge number MUST be the same + 1. + * + * If we receive message and it's sequence number is not equal to one we are expecting, + * then it is new message. + * If we receive message and it's sequence number is the same as one we are expecting, + * but it's acknowledge is not equal acknowledge number in original message + 1, + * then it is new message. + * + */ +void cn_netlink_send(struct cn_msg *msg, u32 __groups) +{ + struct cn_callback_entry *n, *__cbq; + unsigned int size; + struct sk_buff *skb; + struct nlmsghdr *nlh; + struct cn_msg *data; + struct cn_dev *dev = &cdev; + u32 groups = 0; + int found = 0; + + if (!__groups) + { + spin_lock(&dev->cbdev->queue_lock); + list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { + found = 1; + groups = __cbq->group; + } + } + spin_unlock(&dev->cbdev->queue_lock); + + if (!found) { + printk(KERN_ERR "Failed to find multicast netlink group for callback[0x%x.0x%x]. seq=%u\n", + msg->id.idx, msg->id.val, msg->seq); + return; + } + } + else + groups = __groups; + + size = NLMSG_SPACE(sizeof(*msg) + msg->len); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size); + return; + } + + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh)); + + data = (struct cn_msg *)NLMSG_DATA(nlh); + + memcpy(data, msg, sizeof(*data) + msg->len); +#if 0 + printk("%s: len=%u, seq=%u, ack=%u, group=%u.\n", + __func__, msg->len, msg->seq, msg->ack, groups); +#endif + NETLINK_CB(skb).dst_groups = groups; + netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC); + + return; + + nlmsg_failure: + printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); + kfree_skb(skb); + return; +} + +static int cn_call_callback(struct cn_msg *msg, void (*destruct_data) (void *), void *data) +{ + struct cn_callback_entry *n, *__cbq; + struct cn_dev *dev = &cdev; + int found = 0; + + spin_lock(&dev->cbdev->queue_lock); + list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, &msg->id)) { + __cbq->cb->priv = msg; + + __cbq->ddata = data; + __cbq->destruct_data = destruct_data; + + queue_work(dev->cbdev->cn_queue, &__cbq->work); + found = 1; + break; + } + } + spin_unlock(&dev->cbdev->queue_lock); + + return found; +} + +static int __cn_rx_skb(struct sk_buff *skb, struct nlmsghdr *nlh) +{ + u32 pid, uid, seq, group; + struct cn_msg *msg; + + pid = NETLINK_CREDS(skb)->pid; + uid = NETLINK_CREDS(skb)->uid; + seq = nlh->nlmsg_seq; + group = NETLINK_CB((skb)).groups; + msg = (struct cn_msg *)NLMSG_DATA(nlh); + + if (msg->len != nlh->nlmsg_len - sizeof(*msg) - sizeof(*nlh)) { + printk(KERN_ERR "skb does not have enough length: " + "requested msg->len=%u[%u], nlh->nlmsg_len=%u[%u], skb->len=%u[must be %u].\n", + msg->len, NLMSG_SPACE(msg->len), + nlh->nlmsg_len, nlh->nlmsg_len - sizeof(*nlh), + skb->len, msg->len + sizeof(*msg)); + return -EINVAL; + } +#if 0 + printk(KERN_INFO "pid=%u, uid=%u, seq=%u, group=%u.\n", + pid, uid, seq, group); +#endif + return cn_call_callback(msg, (void (*)(void *))kfree_skb, skb); +} + +static void cn_rx_skb(struct sk_buff *__skb) +{ + struct nlmsghdr *nlh; + u32 len; + int err; + struct sk_buff *skb; + + skb = skb_get(__skb); + if (!skb) { + printk(KERN_ERR "Failed to reference an skb.\n"); + return; + } +#if 0 + printk(KERN_INFO + "skb: len=%u, data_len=%u, truesize=%u, proto=%u, cloned=%d, shared=%d.\n", + skb->len, skb->data_len, skb->truesize, skb->protocol, + skb_cloned(skb), skb_shared(skb)); +#endif + while (skb->len >= NLMSG_SPACE(0)) { + nlh = (struct nlmsghdr *)skb->data; + if (nlh->nlmsg_len < sizeof(struct cn_msg) || + skb->len < nlh->nlmsg_len || + nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) { + printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n", + nlh->nlmsg_len, sizeof(*nlh)); + break; + } + + len = NLMSG_ALIGN(nlh->nlmsg_len); + if (len > skb->len) + len = skb->len; + + err = __cn_rx_skb(skb, nlh); + if (err) { +#if 0 + if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK)) + netlink_ack(skb, nlh, -err); +#endif + kfree_skb(skb); + break; + } else { +#if 0 + if (nlh->nlmsg_flags & NLM_F_ACK) + netlink_ack(skb, nlh, 0); +#endif + kfree_skb(skb); + break; + } + skb_pull(skb, len); + } +} + +static void cn_input(struct sock *sk, int len) +{ + struct sk_buff *skb; + + while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) + cn_rx_skb(skb); +} + +static void cn_notify(struct cb_id *id, u32 notify_event) +{ + struct cn_ctl_entry *ent; + + spin_lock(¬ify_lock); + list_for_each_entry(ent, ¬ify_list, notify_entry) { + int i; + struct cn_notify_req *req; + struct cn_ctl_msg *ctl = ent->msg; + int a, b; + + a = b = 0; + + req = (struct cn_notify_req *)ctl->data; + for (i=0; iidx_notify_num; ++i, ++req) { + if (id->idx >= req->first && id->idx < req->first + req->range) { + a = 1; + break; + } + } + + for (i=0; ival_notify_num; ++i, ++req) { + if (id->val >= req->first && id->val < req->first + req->range) { + b = 1; + break; + } + } + + if (a && b) { + struct cn_msg m; + + printk(KERN_INFO "Notifying group %x with event %u about %x.%x.\n", + ctl->group, notify_event, + id->idx, id->val); + + memset(&m, 0, sizeof(m)); + m.ack = notify_event; + + memcpy(&m.id, id, sizeof(m.id)); + cn_netlink_send(&m, ctl->group); + } + } + spin_unlock(¬ify_lock); +} + +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)) +{ + int err; + struct cn_dev *dev = &cdev; + struct cn_callback *cb; + + cb = kmalloc(sizeof(*cb), GFP_KERNEL); + if (!cb) { + printk(KERN_INFO "%s: Failed to allocate new struct cn_callback.\n", + dev->cbdev->name); + return -ENOMEM; + } + + memset(cb, 0, sizeof(*cb)); + + snprintf(cb->name, sizeof(cb->name), "%s", name); + + memcpy(&cb->id, id, sizeof(cb->id)); + cb->callback = callback; + + atomic_set(&cb->refcnt, 0); + + err = cn_queue_add_callback(dev->cbdev, cb); + if (err) { + kfree(cb); + return err; + } + + cn_notify(id, 0); + + return 0; +} + +void cn_del_callback(struct cb_id *id) +{ + struct cn_dev *dev = &cdev; + struct cn_callback_entry *n, *__cbq; + + list_for_each_entry_safe(__cbq, n, &dev->cbdev->queue_list, callback_entry) { + if (cn_cb_equal(&__cbq->cb->id, id)) { + cn_queue_del_callback(dev->cbdev, __cbq->cb); + cn_notify(id, 1); + break; + } + } +} + +static int cn_ctl_msg_equals(struct cn_ctl_msg *m1, struct cn_ctl_msg *m2) +{ + int i; + struct cn_notify_req *req1, *req2; + + if (m1->idx_notify_num != m2->idx_notify_num) + return 0; + + if (m1->val_notify_num != m2->val_notify_num) + return 0; + + if (m1->len != m2->len) + return 0; + + if ((m1->idx_notify_num + m1->val_notify_num)*sizeof(*req1) != m1->len) { + printk(KERN_ERR "Notify entry[idx_num=%x, val_num=%x, len=%u] contains garbage. Removing.\n", + m1->idx_notify_num, m1->val_notify_num, m1->len); + return 1; + } + + req1 = (struct cn_notify_req *)m1->data; + req2 = (struct cn_notify_req *)m2->data; + + for (i=0; iidx_notify_num; ++i) { + if (memcmp(req1, req2, sizeof(*req1))) + return 0; + + req1++; + req2++; + } + + for (i=0; ival_notify_num; ++i) { + if (memcmp(req1, req2, sizeof(*req1))) + return 0; + + req1++; + req2++; + } + + return 1; +} + +static void cn_callback(void * data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + struct cn_ctl_msg *ctl; + struct cn_ctl_entry *ent; + u32 size; + + if (msg->len < sizeof(*ctl)) { + printk(KERN_ERR "Wrong connector request size %u, must be >= %u.\n", + msg->len, sizeof(*ctl)); + return; + } + + ctl = (struct cn_ctl_msg *)msg->data; + + size = sizeof(*ctl) + (ctl->idx_notify_num + ctl->val_notify_num)*sizeof(struct cn_notify_req); + + if (msg->len != size) { + printk(KERN_ERR "Wrong connector request size %u, must be == %u.\n", + msg->len, size); + return; + } + + if (ctl->len + sizeof(*ctl) != msg->len) { + printk(KERN_ERR "Wrong message: msg->len=%u must be equal to inner_len=%u [+%u].\n", + msg->len, ctl->len, sizeof(*ctl)); + return; + } + + /* + * Remove notification. + */ + if (ctl->group == 0) { + struct cn_ctl_entry *n; + + spin_lock(¬ify_lock); + list_for_each_entry_safe(ent, n, ¬ify_list, notify_entry) { + if (cn_ctl_msg_equals(ent->msg, ctl)) { + list_del(&ent->notify_entry); + kfree(ent); + } + } + spin_unlock(¬ify_lock); + + return; + } + + size += sizeof(*ent); + + ent = kmalloc(size, GFP_ATOMIC); + if (!ent) { + printk(KERN_ERR "Failed to allocate %d bytes for new notify entry.\n", size); + return; + } + + memset(ent, 0, size); + + ent->msg = (struct cn_ctl_msg *)(ent + 1); + + memcpy(ent->msg, ctl, size - sizeof(*ent)); + + spin_lock(¬ify_lock); + list_add(&ent->notify_entry, ¬ify_list); + spin_unlock(¬ify_lock); + + { + int i; + struct cn_notify_req *req; + + printk("Notify group %x for idx: ", ctl->group); + + req = (struct cn_notify_req *)ctl->data; + for (i=0; iidx_notify_num; ++i, ++req) { + printk("%u-%u ", req->first, req->first+req->range-1); + } + + printk("\nNotify group %x for val: ", ctl->group); + + for (i=0; ival_notify_num; ++i, ++req) { + printk("%u-%u ", req->first, req->first+req->range-1); + } + printk("\n"); + } +} + +static int cn_init(void) +{ + struct cn_dev *dev = &cdev; + + dev->input = cn_input; + dev->id.idx = cn_idx; + dev->id.val = cn_val; + + dev->nls = netlink_kernel_create(unit, dev->input); + if (!dev->nls) { + printk(KERN_ERR "Failed to create new netlink socket(%u).\n", + unit); + return -EIO; + } + + dev->cbdev = cn_queue_alloc_dev("cqueue", dev->nls); + if (!dev->cbdev) { + if (dev->nls->sk_socket) + sock_release(dev->nls->sk_socket); + return -EINVAL; + } + + return cn_add_callback(&dev->id, "connector", &cn_callback); +} + +static void cn_fini(void) +{ + struct cn_dev *dev = &cdev; + + cn_del_callback(&dev->id); + cn_queue_free_dev(dev->cbdev); + if (dev->nls->sk_socket) + sock_release(dev->nls->sk_socket); +} + +module_init(cn_init); +module_exit(cn_fini); + +EXPORT_SYMBOL(cn_add_callback); +EXPORT_SYMBOL(cn_del_callback); +EXPORT_SYMBOL(cn_netlink_send); diff -Nru /tmp/empty/connector.h linux-2.6/drivers/connector/connector.h --- /tmp/empty/connector.h 1970-01-01 03:00:00.000000000 +0300 +++ linux-2.6/drivers/connector/connector.h 2004-09-21 13:38:57.000000000 +0400 @@ -0,0 +1,81 @@ +/* + * connector.h + * + * 2004 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __CONNECTOR_H +#define __CONNECTOR_H + +#include "../connector/cn_queue.h" + +#define CONNECTOR_MAX_MSG_SIZE 1024 + +struct cn_msg +{ + struct cb_id id; + + __u32 seq; + __u32 ack; + + __u32 len; /* Length of the following data */ + __u8 data[0]; +}; + +struct cn_notify_req +{ + __u32 first; + __u32 range; +}; + +struct cn_ctl_msg +{ + __u32 idx_notify_num; + __u32 val_notify_num; + __u32 group; + __u32 len; + __u8 data[0]; +}; + +#ifdef __KERNEL__ + +#include + +struct cn_ctl_entry +{ + struct list_head notify_entry; + struct cn_ctl_msg *msg; +}; + +struct cn_dev +{ + struct cb_id id; + + u32 seq, groups; + struct sock *nls; + void (*input)(struct sock *sk, int len); + + struct cn_queue_dev *cbdev; +}; + +int cn_add_callback(struct cb_id *, char *, void (* callback)(void *)); +void cn_del_callback(struct cb_id *); +void cn_netlink_send(struct cn_msg *, u32); + +#endif /* __KERNEL__ */ +#endif /* __CONNECTOR_H */ Evgeniy Polyakov ( s0mbre ) Only failure makes us experts. -- Theo de Raadt From davem@davemloft.net Thu Sep 23 13:04:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:04:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NK4Zfx002459 for ; Thu, 23 Sep 2004 13:04:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAZo6-0006oT-00; Thu, 23 Sep 2004 13:03:10 -0700 Date: Thu, 23 Sep 2004 13:03:10 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com, coreteam@netfilter.org Subject: Re: [NETFILTER] Fix comment typo in ip_nat_helper Message-Id: <20040923130310.71bca65b.davem@davemloft.net> In-Reply-To: <20040921013548.GA27679@gondor.apana.org.au> References: <20040921013548.GA27679@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 180 Lines: 7 On Tue, 21 Sep 2004 11:35:48 +1000 Herbert Xu wrote: > Here's a trivial comment fix that I noticed while tracking down an FTP/NAT > issue. Applied. From davem@davemloft.net Thu Sep 23 13:06:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:06:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NK6jN2002833 for ; Thu, 23 Sep 2004 13:06:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAZqE-0006or-00; Thu, 23 Sep 2004 13:05:22 -0700 Date: Thu, 23 Sep 2004 13:05:21 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [IPv4] Check PAGE_SIZE in fz_hash_alloc Message-Id: <20040923130521.7029a724.davem@davemloft.net> In-Reply-To: <20040922035710.GA17249@gondor.apana.org.au> References: <20040918203319.24004d6e.davem@davemloft.net> <1095645106.1048.190.camel@jzny.localdomain> <20040919195351.0b3560e6.davem@davemloft.net> <1095686672.1049.301.camel@jzny.localdomain> <20040920121123.70baf895.davem@davemloft.net> <20040921034212.GA28462@gondor.apana.org.au> <20040920231805.3f18479c.davem@davemloft.net> <20040922020729.GA14062@gondor.apana.org.au> <20040921193234.1c5b09a1.davem@davemloft.net> <20040922035710.GA17249@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 355 Lines: 10 On Wed, 22 Sep 2004 13:57:10 +1000 Herbert Xu wrote: > Here is a minor optimisation to fz_hash_alloc. The break-even point > should be based on PAGE_SIZE rather than the value of divisor. > > Signed-off-by: Herbert Xu It happens to be equivalent on several platforms, but yes good fixup :-) From davem@redhat.com Thu Sep 23 13:10:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:10:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKAH0p003216 for ; Thu, 23 Sep 2004 13:10:18 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8NKA3co003086; Thu, 23 Sep 2004 16:10:03 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8NKA2r02155; Thu, 23 Sep 2004 16:10:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8NK9pEY023000; Thu, 23 Sep 2004 16:09:51 -0400 Date: Thu, 23 Sep 2004 13:08:59 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: [PATCH] pktgen - handle NETDEV_TX_LOCKED Message-Id: <20040923130859.4e6c0502.davem@redhat.com> In-Reply-To: <20040922141158.3a16416c@dell_ss3.pdx.osdl.net> References: <20040922141158.3a16416c@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 278 Lines: 9 On Wed, 22 Sep 2004 14:11:58 -0700 Stephen Hemminger wrote: > Change pktgen to handle drivers that return TX_LOCKED better. > This isn't a real busy state so just spin. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From davem@davemloft.net Thu Sep 23 13:24:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:24:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKOoAC003942 for ; Thu, 23 Sep 2004 13:24:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAa7m-0006qv-00; Thu, 23 Sep 2004 13:23:30 -0700 Date: Thu, 23 Sep 2004 13:23:30 -0700 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6]: fix unbalances spin_unlock_bh in __xfrm_find_acq_byseq Message-Id: <20040923132330.24f5a5f6.davem@davemloft.net> In-Reply-To: <41524CC8.1070104@trash.net> References: <41524CC8.1070104@trash.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 239 Lines: 10 On Thu, 23 Sep 2004 06:10:48 +0200 Patrick McHardy wrote: > This patch fixes an unbalanced spin_unlock_bh in > __xfrm_find_acq_byseq left over from the larval > state SA fix. Good catch, patch applied. Thanks Patrick. From davem@davemloft.net Thu Sep 23 13:32:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:32:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKWGCi004417 for ; Thu, 23 Sep 2004 13:32:16 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaEu-0006rT-00; Thu, 23 Sep 2004 13:30:52 -0700 Date: Thu, 23 Sep 2004 13:30:52 -0700 From: "David S. Miller" To: "chas williams (contractor)" Cc: nacc@us.ibm.com, netdev@oss.sgi.com, davem@redhat.com, kernel-janitors@lists.osdl.org Subject: Re: [PATCH][ATM]: [drivers] use msleep() instead of schedule_timeout() (from Nishanth Aravamudan ) Message-Id: <20040923133052.259d3e39.davem@davemloft.net> In-Reply-To: <200409231626.i8NGQ44f014489@ginger.cmf.nrl.navy.mil> References: <20040923160710.GB1699@us.ibm.com> <200409231626.i8NGQ44f014489@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 235 Lines: 8 On Thu, 23 Sep 2004 12:26:05 -0400 "chas williams (contractor)" wrote: > # ChangeSet > # 2004/09/23 12:24:28-04:00 chas@relax.cmf.nrl.navy.mil > # [ATM]: [lanai] get sleep interval right Applied, thanks. From davem@davemloft.net Thu Sep 23 13:33:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:33:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKXPZk004747 for ; Thu, 23 Sep 2004 13:33:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaFq-0006rw-00; Thu, 23 Sep 2004 13:31:50 -0700 Date: Thu, 23 Sep 2004 13:31:50 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH][ATM]: [eni] fix __iomem related warnings Message-Id: <20040923133150.318fb57a.davem@davemloft.net> In-Reply-To: <200409231841.i8NIfaoj018070@ginger.cmf.nrl.navy.mil> References: <200409231841.i8NIfaoj018070@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 242 Lines: 8 On Thu, 23 Sep 2004 14:41:38 -0400 "chas williams (contractor)" wrote: > # ChangeSet > # 2004/09/23 10:29:01-04:00 chas@relax.cmf.nrl.navy.mil > # [ATM]: [eni] fix __iomem related warnings Applied, thanks Chas. From davem@davemloft.net Thu Sep 23 13:34:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:34:14 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKY94j005073 for ; Thu, 23 Sep 2004 13:34:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaGo-0006sI-00; Thu, 23 Sep 2004 13:32:50 -0700 Date: Thu, 23 Sep 2004 13:32:49 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH][ATM]: [ambassador] remove warnings related to unused variables Message-Id: <20040923133249.7d9613eb.davem@davemloft.net> In-Reply-To: <200409231843.i8NIh9sm018124@ginger.cmf.nrl.navy.mil> References: <200409231843.i8NIh9sm018124@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 264 Lines: 8 On Thu, 23 Sep 2004 14:43:11 -0400 "chas williams (contractor)" wrote: > # ChangeSet > # 2004/09/23 10:37:44-04:00 chas@relax.cmf.nrl.navy.mil > # [ATM]: [ambassador] remove warnings related to unused variables Applied, thanks Chas. From davem@davemloft.net Thu Sep 23 13:34:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:34:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKYk2S005365 for ; Thu, 23 Sep 2004 13:34:46 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaHO-0006sb-00; Thu, 23 Sep 2004 13:33:26 -0700 Date: Thu, 23 Sep 2004 13:33:25 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH][ATM]: [fore200e] fix warnings related to dma_addr_t Message-Id: <20040923133325.03f4a6a9.davem@davemloft.net> In-Reply-To: <200409231844.i8NIi0gD018156@ginger.cmf.nrl.navy.mil> References: <200409231844.i8NIi0gD018156@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 240 Lines: 8 On Thu, 23 Sep 2004 14:44:02 -0400 "chas williams (contractor)" wrote: > # ChangeSet > # 2004/09/23 10:50:50-04:00 chas@relax.cmf.nrl.navy.mil > # [ATM]: [fore200e] fix warnings related to dma_addr_t Applied. From davem@davemloft.net Thu Sep 23 13:37:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:37:45 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKbd0q005764 for ; Thu, 23 Sep 2004 13:37:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaJx-0006sr-00; Thu, 23 Sep 2004 13:36:05 -0700 Date: Thu, 23 Sep 2004 13:36:04 -0700 From: "David S. Miller" To: Herbert Xu Cc: xhejtman@mail.muni.cz, akpm@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.9-rc2-mm2 fn_hash_insert oops Message-Id: <20040923133604.26a2ea2a.davem@davemloft.net> In-Reply-To: References: <20040923103723.GA12145@mail.muni.cz> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 269 Lines: 10 On Thu, 23 Sep 2004 21:16:32 +1000 Herbert Xu wrote: > Lukas Hejtmanek wrote: > > > > However there is still the issue with endless loop in fn_hash_delete :( > > Same problem, same fix. Applied, thanks Herbert. From davem@davemloft.net Thu Sep 23 13:38:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:38:41 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKcaTW005973 for ; Thu, 23 Sep 2004 13:38:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaL5-0006tK-00; Thu, 23 Sep 2004 13:37:15 -0700 Date: Thu, 23 Sep 2004 13:37:15 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPv4] Fix thinko in fib_find_alias Message-Id: <20040923133715.714e9c44.davem@davemloft.net> In-Reply-To: <20040923041516.GA19252@gondor.apana.org.au> References: <20040923041516.GA19252@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 279 Lines: 8 On Thu, 23 Sep 2004 14:15:16 +1000 Herbert Xu wrote: > fib_find_alias is meant to return either an exact match or the > entry just before where it should be. Currently it returns the > entry after that. This patch fixes that. Good fix, applied. From davem@davemloft.net Thu Sep 23 13:40:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 13:40:15 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NKeAi8006448 for ; Thu, 23 Sep 2004 13:40:10 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAaMc-0006tg-00; Thu, 23 Sep 2004 13:38:50 -0700 Date: Thu, 23 Sep 2004 13:38:50 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [IPv4] Missing TOS checks after fib_find_alias Message-Id: <20040923133850.2ed1b7ab.davem@davemloft.net> In-Reply-To: <20040923062831.GA20202@gondor.apana.org.au> References: <20040923062831.GA20202@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 258 Lines: 9 On Thu, 23 Sep 2004 16:28:31 +1000 Herbert Xu wrote: > It looks like some of the places where FIB_SCAN_TOS macros were used > have lost the tos check. This patch adds them back. Right you are, patch applied. Thanks Herbert. From nuno.ferreira@graycell.biz Thu Sep 23 14:38:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 14:38:29 -0700 (PDT) Received: from sapo.pt (relay2.ptmail.sapo.pt [212.55.154.22]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8NLcMfN008590 for ; Thu, 23 Sep 2004 14:38:22 -0700 Received: (qmail 15613 invoked from network); 23 Sep 2004 21:38:04 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.151) by relay2 with SMTP; 23 Sep 2004 21:38:04 -0000 Received: (qmail 24338 invoked from network); 23 Sep 2004 21:37:15 -0000 Received: from unknown (HELO [81.193.72.139]) ([81.193.72.139]) (envelope-sender ) by mta1 (qmail-ldap-1.03) with SMTP for ; 23 Sep 2004 21:37:15 -0000 Subject: Re: 2.6.9-rc2-mm2 fn_hash_insert oops From: Nuno Ferreira To: Herbert Xu Cc: akpm@osdl.org, Linux Kernel , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Graycell Date: Thu, 23 Sep 2004 22:38:04 +0100 Message-Id: <1095975485.4339.1.camel@taz.graycell.biz> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nuno.ferreira@graycell.biz Precedence: bulk X-list: netdev Content-Length: 401 Lines: 14 On Qui, 2004-09-23 at 21:16 +1000, Herbert Xu wrote: > Lukas Hejtmanek wrote: > > > > However there is still the issue with endless loop in fn_hash_delete :( > > Same problem, same fix. Can someone think of a generic fix to > list_for_each_*? > This also fixed the problem I reported earlier with the machine freezing when my Speedtouch USB ADSL modem connected. Thanks From marcel@holtmann.org Thu Sep 23 14:41:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 14:41:16 -0700 (PDT) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NLfA8U008961 for ; Thu, 23 Sep 2004 14:41:11 -0700 Received: from pegasus (p5082BAD1.dip.t-dialin.net [80.130.186.209]) by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8NLexXS014113 for ; Thu, 23 Sep 2004 23:41:00 +0200 Subject: Oops when stopping IPsec connection From: Marcel Holtmann To: Network Development Mailing List Content-Type: text/plain Message-Id: <1095975655.5976.13.camel@pegasus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 23:40:55 +0200 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on coyote X-Virus-Status: Clean X-archive-position: 9382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Content-Length: 2546 Lines: 60 Hi, when I stop my IPsec connection I see the following oops with the latest kernel from the BK tree. Has anyone an idea what is wrong? Unable to handle kernel paging request at virtual address 00a02d0d printing eip: c0266185 *pde = 00000000 Oops: 0000 [#1] Modules linked in: ide_cd cdrom rfcomm hidp l2cap ds irda crc_ccitt af_packet bi nfmt_misc deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish de s sha256 sha1 md5 crypto_null xfrm_user ipcomp esp4 ah4 af_key yenta_socket ehci _hcd h2usb hci_usb ohci_hcd 8250_pci 8250 serial_core snd_intel8x0 snd_ac97_code c snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd _rawmidi snd soundcore usbhid uhci_hcd intel_agp agpgart evdev nls_iso8859_1 nls _cp437 vfat fat nls_base eth1394 st bluetooth usbcore pcmcia_core w83781d i2c_se nsor i2c_i801 i2c_core ohci1394 ieee1394 sd_mod aic7xxx scsi_mod e100 mii unix CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010286 (2.6.9-rc2) EIP is at fib_nh_match+0x58/0x61 eax: dfff4ac0 ebx: de84b148 ecx: dfff4ac0 edx: df27e430 esi: 00a02c95 edi: df27e410 ebp: de84b140 esp: c0c93c34 ds: 007b es: 007b ss: 0068 Process ip (pid: 24496, threadinfo=c0c92000 task=d3054020) Stack: 00000000 df27e410 c02680dd df27e410 df27e400 dfff4ac0 00a02c95 0007801e 00000000 00000000 dd50b6c0 00000013 00a02c95 df27e410 df27e400 dfff4ac0 df27e400 c02657d1 dffcda80 df27e410 dfff4ac0 df27e400 ddf130b8 ddf13080 Call Trace: [] fn_hash_delete+0x231/0x243 [] inet_rtm_delroute+0x66/0x7a [] rtnetlink_rcv+0x2dc/0x394 [] netlink_data_ready+0x61/0x69 [] netlink_sendskb+0x32/0x54 [] netlink_sendmsg+0x1f9/0x2fc [] sock_sendmsg+0x11a/0x11c [] __mark_inode_dirty+0x19d/0x1a2 [] sock_sendmsg+0x11a/0x11c [] copy_from_user+0x42/0x6e [] autoremove_wake_function+0x0/0x57 [] sys_sendmsg+0x189/0x1e6 [] handle_mm_fault+0xd2/0x138 [] do_page_fault+0x192/0x590 [] do_brk+0x1f8/0x25c [] copy_from_user+0x42/0x6e [] sys_socketcall+0x236/0x254 [] sys_brk+0xd8/0xfd [] do_page_fault+0x0/0x590 [] error_code+0x2d/0x38 [] syscall_call+0x7/0xb Code: c4 08 c3 8b 51 0c 85 d2 75 21 8b 79 10 85 ff 74 16 8b 41 10 85 c0 74 0f 8d 7e 7c b9 04 00 00 00 fc 89 c6 f3 a6 75 cc 31 c0 eb cd <8b> 46 78 39 02 75 c1 eb dd 55 57 56 53 81 ec b4 00 00 00 8b b4 Regards Marcel From mcgrof@studorgs.rutgers.edu Thu Sep 23 14:54:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 14:55:03 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NLswPg009588 for ; Thu, 23 Sep 2004 14:54:59 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 5A123F99BD; Thu, 23 Sep 2004 17:54:47 -0400 (EDT) Date: Thu, 23 Sep 2004 17:54:47 -0400 To: Evgeniy Polyakov Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". Message-ID: <20040923215447.GD30131@ruslug.rutgers.edu> Mail-Followup-To: Evgeniy Polyakov , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 663 Lines: 28 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable RFC:=20 Can and should we work towards using this as interface for drivers that need callbacks from an external (closed source) library/HAL? --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBU0Ynat1JN+IKUl4RAv84AJ48EAwhP4PmmERogfg6cyipV2jYNgCfWMCF LCot3fpQXCwbd5Y/T+4cJPc= =4RAE -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From herbert@gondor.apana.org.au Thu Sep 23 15:06:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 15:06:26 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NM6FRI010357 for ; Thu, 23 Sep 2004 15:06:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAbif-0006Au-00; Fri, 24 Sep 2004 08:05:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAbiX-00016Q-00; Fri, 24 Sep 2004 08:05:33 +1000 From: Herbert Xu To: marcel@holtmann.org (Marcel Holtmann) Subject: Re: Oops when stopping IPsec connection Cc: netdev@oss.sgi.com Organization: Core In-Reply-To: <1095975655.5976.13.camel@pegasus> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 24 Sep 2004 08:05:33 +1000 X-archive-position: 9384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1061 Lines: 35 Marcel Holtmann wrote: > EIP is at fib_nh_match+0x58/0x61 > > Call Trace: > [] fn_hash_delete+0x231/0x243 > [] inet_rtm_delroute+0x66/0x7a Does this patch help? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/ipv4/fib_hash.c 1.22 vs edited ===== --- 1.22/net/ipv4/fib_hash.c 2004-09-22 09:31:48 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-23 21:16:04 +10:00 @@ -608,6 +608,7 @@ struct fn_hash *table = (struct fn_hash*)tb->tb_data; struct fib_node *f; struct fib_alias *fa, *fa_to_delete; + struct list_head *fa_head; int z = r->rtm_dst_len; struct fn_zone *fz; u32 key; @@ -633,7 +634,8 @@ return -ESRCH; fa_to_delete = NULL; - list_for_each_entry(fa, fa->fa_list.prev, fa_list) { + fa_head = fa->fa_list.prev; + list_for_each_entry(fa, fa_head, fa_list) { struct fib_info *fi = fa->fa_info; if ((!r->rtm_type || From mcgrof@studorgs.rutgers.edu Thu Sep 23 15:55:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 15:55:33 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NMtMsM011794 for ; Thu, 23 Sep 2004 15:55:22 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id F3F62F99BD; Thu, 23 Sep 2004 18:55:07 -0400 (EDT) Date: Thu, 23 Sep 2004 18:55:07 -0400 To: Nishanth Aravamudan Cc: hvr@gnu.org, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, margitsw@t-online.de, prism54-devel@prism54.org, Netdev Subject: Re: [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040923225507.GI30131@ruslug.rutgers.edu> Mail-Followup-To: Nishanth Aravamudan , hvr@gnu.org, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, margitsw@t-online.de, prism54-devel@prism54.org, Netdev References: <20040923221303.GB13244@us.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="df+09Je9rNq3P+GE" Content-Disposition: inline In-Reply-To: <20040923221303.GB13244@us.ibm.com> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 2035 Lines: 66 --df+09Je9rNq3P+GE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2004 at 03:13:03PM -0700, Nishanth Aravamudan wrote: > Any comments would be appreciated. >=20 > Description: Use msleep() instead of schedule_timeout() > to guarantee the task delays as expected. Also set_current_state() is > inserted before schedule_timeout(). If the for-loop were to execute > twice, the second time would not set the state before sleeping in the > current code; this causes schedule_timeout() to return immediately. >=20 > Signed-off-by: Nishanth Aravamudan >=20 > --- 2.6.9-rc2-vanilla/drivers/net/wireless/prism54/islpci_dev.c 2004-09-1= 3 17:15:41.000000000 -0700 > +++ 2.6.9-rc2/drivers/net/wireless/prism54/islpci_dev.c 2004-09-23 13:58:= 42.000000000 -0700 > @@ -436,8 +436,7 @@ prism54_bring_down(islpci_private *priv) > wmb(); > =20 > /* wait a while for the device to reset */ > - set_current_state(TASK_UNINTERRUPTIBLE); > - schedule_timeout(50*HZ/1000); > + msleep(50); > =20 > return 0; > } > @@ -489,6 +488,7 @@ islpci_reset_if(islpci_private *priv) > /* The software reset acknowledge needs about 220 msec here. > * Be conservative and wait for up to one second. */ > =09 > + set_current_state(TASK_UNINTERRUPTIBLE); > remaining =3D schedule_timeout(HZ); > =20 > if(remaining > 0) { Looks good to me. IIRC Margit had something to say about this last time this popped around -- CC'ing her to see if there are any outstanding comments. PS. For future prism54 patches please feel free to CC prism54-devel and netdev. Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --df+09Je9rNq3P+GE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBU1RLat1JN+IKUl4RAk9+AJ9KiSJszt4vr2I7L1igpeJB4SNe5QCgrIa8 SUQv0TM059cGvmMHKU73qhw= =JuFF -----END PGP SIGNATURE----- --df+09Je9rNq3P+GE-- From davem@davemloft.net Thu Sep 23 16:14:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 16:15:09 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NNEwI1012540 for ; Thu, 23 Sep 2004 16:14:59 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAckX-00077p-00; Thu, 23 Sep 2004 16:11:41 -0700 Date: Thu, 23 Sep 2004 16:11:41 -0700 From: "David S. Miller" To: Andi Kleen , niv@us.ibm.com Cc: ak@suse.de, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040923161141.4ea9be4c.davem@davemloft.net> In-Reply-To: <20040922224732.GD2619@wotan.suse.de> References: <20040920063012.GL2825@krispykreme> <20040920203021.GD4242@wotan.suse.de> <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <20040922133906.7d57ef49.davem@davemloft.net> <20040922220628.GC2619@wotan.suse.de> <20040922152535.7bc81c8a.davem@davemloft.net> <20040922224732.GD2619@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1217 Lines: 41 I think I know what may be going on here. Let's say that we even get the congestion window openned up so that we can build 64K TSO frames, that's around 43 or 44 1500 mtu frames. That means as the window fills up, we have to see 44 ACKs before we are able to send the next TSO frame. Needless to say that breaks ACK clocking completely. And given that, getting 22MB/sec with TSO enabled is actually an impressive feat. I can't think of a fix I'm completely happy with. We could limit TSO to something like 2 or 4 normal MSS frames, but that negates much of the gain from TSO. But something like this is necessary to keep the pipe full. Anyways, for testing, something like the patch below. If things still stink a bit, try using a limit of "2" in this patch instead of "4". ===== net/ipv4/tcp_output.c 1.58 vs edited ===== --- 1.58/net/ipv4/tcp_output.c 2004-09-13 21:39:17 -07:00 +++ edited/net/ipv4/tcp_output.c 2004-09-23 15:51:51 -07:00 @@ -645,6 +645,12 @@ if (factor > tp->snd_cwnd) factor = tp->snd_cwnd; + /* Also, do not let it grow more than 4 frames + * so that ACK clocking continues to work. + */ + if (factor > 4) + factor = 4; + tp->mss_cache = mss_now * factor; } From marcel@holtmann.org Thu Sep 23 16:15:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 16:15:48 -0700 (PDT) Received: from mail.holtmann.net (root@coyote.holtmann.net [217.160.111.169]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NNFftx012718 for ; Thu, 23 Sep 2004 16:15:42 -0700 Received: from pegasus (p5082BAD1.dip.t-dialin.net [80.130.186.209]) by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i8NNFMXS015223; Fri, 24 Sep 2004 01:15:24 +0200 Subject: Re: Oops when stopping IPsec connection From: Marcel Holtmann To: Herbert Xu Cc: Network Development Mailing List In-Reply-To: References: Content-Type: text/plain Message-Id: <1095981318.6198.0.camel@pegasus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 24 Sep 2004 01:15:18 +0200 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c on coyote X-Virus-Status: Clean X-archive-position: 9387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcel@holtmann.org Precedence: bulk X-list: netdev Content-Length: 238 Lines: 17 Hi Herbert, > > EIP is at fib_nh_match+0x58/0x61 > > > > Call Trace: > > [] fn_hash_delete+0x231/0x243 > > [] inet_rtm_delroute+0x66/0x7a > > Does this patch help? yes, this works for me. Thanks. Regards Marcel From lists@mdiehl.de Thu Sep 23 16:30:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 16:30:24 -0700 (PDT) Received: from bart.webpack.hosteurope.de (bart.webpack.hosteurope.de [217.115.142.76]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NNUElq016654 for ; Thu, 23 Sep 2004 16:30:15 -0700 Received: from pd9e9586c.dip0.t-ipconnect.de ([217.233.88.108] helo=notebook.home.mdiehl.de) by bart.webpack.hosteurope.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CAd22-0000LW-BB; Fri, 24 Sep 2004 01:29:46 +0200 Received: from notebook.home.mdiehl.de (localhost.localdomain [127.0.0.1]) by notebook.home.mdiehl.de (8.12.1/8.12.1) with ESMTP id i8NNTxji019731; Fri, 24 Sep 2004 01:30:01 +0200 Received: from localhost (martin@localhost) by notebook.home.mdiehl.de (8.12.1/8.12.1/Submit) with ESMTP id i8NNTvWj019728; Fri, 24 Sep 2004 01:29:58 +0200 X-Authentication-Warning: notebook.home.mdiehl.de: martin owned process doing -bs Date: Fri, 24 Sep 2004 01:29:57 +0200 (CEST) From: Martin Diehl X-X-Sender: martin@notebook.home.mdiehl.de To: "David S. Miller" cc: Herbert Xu , , , , Subject: Re: 2.6.9-rc2-mm2 fn_hash_insert oops In-Reply-To: <20040923133604.26a2ea2a.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HE-MXrcvd: no X-archive-position: 9388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lists@mdiehl.de Precedence: bulk X-list: netdev Content-Length: 1792 Lines: 47 On Thu, 23 Sep 2004, David S. Miller wrote: > On Thu, 23 Sep 2004 21:16:32 +1000 > Herbert Xu wrote: > > > Lukas Hejtmanek wrote: > > > > > > However there is still the issue with endless loop in fn_hash_delete :( > > > > Same problem, same fix. > > Applied, thanks Herbert. FYI: it seems applying these two list_for_each fixes did also solve a related issue with different symptoms, which I was just seeing: Unable to handle kernel NULL pointer dereference at virtual address 00000028 printing eip: c0267a35 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: tulip soundcore parport_pc lp parport usblp ohci_hcd usbcore ne2k_pci 8390 crc32 rtc CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010297 (2.6.9-rc2-mm2) EIP is at fn_hash_insert+0x225/0x3e0 eax: 00000000 ebx: c3580401 ecx: cadcc2ec edx: 00000000 esi: c358bea0 edi: cad03314 ebp: cbd335cc esp: c358be30 ds: 007b es: 007b ss: 0068 Process route (pid: 2667, threadinfo=c358a000 task=c333b850) Stack: 00000000 cadcc2ec 00000000 0002a8c0 00000001 00000000 cbd53ca8 cad0330c ffffffef 00000000 c0141a72 00000000 c01422e7 cbc3e600 ffffff97 0000890b 0000890b c358a000 c02654c7 c11ca9f4 c358bea0 c358bf10 c358be90 00000000 Call Trace: [] check_spinlock_acquired+0x12/0x20 [] check_slabp+0x17/0xe0 [] ip_rt_ioctl+0x137/0x170 [] inet_ioctl+0x40/0xa0 [] sock_ioctl+0x2c0/0x300 [] sys_ioctl+0x266/0x2b0 [] syscall_call+0x7/0xb Code: 75 14 8b 74 24 50 8a 46 06 38 47 0e 75 08 39 ea 0f 84 ae 01 00 00 89 cf 8b 07 89 c1 8d 74 26 00 3b 7f 04 74 0b 8b 57 08 8b 04 24 <39> 42 28 74 c8 81 e3 00 08 00 00 75 04 8b 7c 24 04 8b 54 24 58 Thanks, Martin From davem@davemloft.net Thu Sep 23 16:43:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 16:43:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NNhkb9017132 for ; Thu, 23 Sep 2004 16:43:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAdDi-0007BH-00; Thu, 23 Sep 2004 16:41:50 -0700 Date: Thu, 23 Sep 2004 16:41:49 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040923164149.5368d291.davem@davemloft.net> In-Reply-To: References: <20040923161141.4ea9be4c.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 593 Lines: 15 On Fri, 24 Sep 2004 09:41:04 +1000 Herbert Xu wrote: > David S. Miller wrote: > > > > That means as the window fills up, we have to see 44 ACKs > > before we are able to send the next TSO frame. Needless to > > say that breaks ACK clocking completely. > > Hang on a second, the same problem would occur before the congestion > changes were made, right? Previously we counted TSO frames as single "packets" as long as we could fit one more frame into the congestion window we'd spit out the whole TSO frame, and this kept the pipe full. From herbert@gondor.apana.org.au Thu Sep 23 16:45:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 16:45:43 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NNjYpn017505 for ; Thu, 23 Sep 2004 16:45:35 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAdD8-00073o-00; Fri, 24 Sep 2004 09:41:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAdCy-0001FM-00; Fri, 24 Sep 2004 09:41:04 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: bad TSO performance in 2.6.9-rc2-BK Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040923161141.4ea9be4c.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 24 Sep 2004 09:41:04 +1000 X-archive-position: 9390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 754 Lines: 19 David S. Miller wrote: > > That means as the window fills up, we have to see 44 ACKs > before we are able to send the next TSO frame. Needless to > say that breaks ACK clocking completely. Hang on a second, the same problem would occur before the congestion changes were made, right? I thought Anton was saying that with the old kernels he was getting 100MB/s with TSO enabled... Anton, can you please get tcpdump to somehow show the length of the TSO packets so that we know what the factor is being set to? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Sep 23 16:46:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 16:46:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8NNk9M7017723 for ; Thu, 23 Sep 2004 16:46:10 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAdHd-000770-00; Fri, 24 Sep 2004 09:45:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAdHc-0001GZ-00; Fri, 24 Sep 2004 09:45:52 +1000 Date: Fri, 24 Sep 2004 09:45:52 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [TCP] Fix tcp_current_mss when MTU changes Message-ID: <20040923234552.GA4846@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1506 Lines: 55 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: There is a small bug in tcp_current_mss where it can return the real MSS when MTU changes even if the TSO MSS is what is intended. This patch fixes it. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/net/tcp.h 1.88 vs edited ===== --- 1.88/include/net/tcp.h 2004-09-15 06:57:07 +10:00 +++ edited/include/net/tcp.h 2004-09-24 09:35:22 +10:00 @@ -1049,17 +1049,20 @@ struct dst_entry *dst = __sk_dst_get(sk); int do_large, mss_now; - do_large = (large && - (sk->sk_route_caps & NETIF_F_TSO) && - !tp->urg_mode); - mss_now = do_large ? tp->mss_cache : tp->mss_cache_std; - + mss_now = tp->mss_cache_std; if (dst) { u32 mtu = dst_pmtu(dst); if (mtu != tp->pmtu_cookie || tp->ext2_header_len != dst->header_len) mss_now = tcp_sync_mss(sk, mtu); } + + do_large = (large && + (sk->sk_route_caps & NETIF_F_TSO) && + !tp->urg_mode); + if (do_large) + mss_now = tp->mss_cache; + if (tp->eff_sacks) mss_now -= (TCPOLEN_SACK_BASE_ALIGNED + (tp->eff_sacks * TCPOLEN_SACK_PERBLOCK)); --C7zPtVaVf+AK4Oqc-- From herbert@gondor.apana.org.au Thu Sep 23 17:13:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 17:13:21 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O0D6BX018638 for ; Thu, 23 Sep 2004 17:13:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAdhQ-0007J8-00; Fri, 24 Sep 2004 10:12:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAdhJ-0001K2-00; Fri, 24 Sep 2004 10:12:25 +1000 Date: Fri, 24 Sep 2004 10:12:25 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040924001225.GA5051@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040923164149.5368d291.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040923164149.5368d291.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 774 Lines: 21 On Thu, Sep 23, 2004 at 04:41:49PM -0700, David S. Miller wrote: > > Previously we counted TSO frames as single "packets" as long as > we could fit one more frame into the congestion window we'd spit > out the whole TSO frame, and this kept the pipe full. I see. In that case what we've got now can't possibly work. How about this? We always to treat TSO frames as one packet. We continue to obey the congestion window by starting with a TSO MSS that is small enough. We increase the TSO MSS as the congestion window goes up. That should work, no? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From paulmck@us.ibm.com Thu Sep 23 17:36:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 17:36:34 -0700 (PDT) Received: from linux.local (bi01p1.co.us.ibm.com [32.97.110.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O0aIiM019356 for ; Thu, 23 Sep 2004 17:36:25 -0700 Received: by linux.local (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 52730148B98; Thu, 23 Sep 2004 17:31:36 -0700 (PDT) Date: Thu, 23 Sep 2004 17:31:36 -0700 From: "Paul E. McKenney" To: lkml@einar-lueck.de Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 2/2] ipv4 multipath routing, bk head Message-ID: <20040924003136.GA1500@us.ibm.com> Reply-To: paulmck@us.ibm.com References: <4151A8EB.80408@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4151A8EB.80408@de.ibm.com> User-Agent: Mutt/1.4.1i X-archive-position: 9393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulmck@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 46412 Lines: 1548 Hello, Einar, Looks pretty good from an RCU standpoint! A few comments interspersed, search for empty lines. Nothing fatal, but some readability problems, some memory wastage, and some minor performance issues. Thanx, Paul On Wed, Sep 22, 2004 at 06:31:39PM +0200, Einar Lueck wrote: > The intention of this patch is described in detail in the previous mail. > > Regards > Einar. > > diff -ruN linux-2.6.8.1.split/include/net/dst.h linux-2.6.8.1.multipath/include/net/dst.h > --- linux-2.6.8.1.split/include/net/dst.h 2004-09-22 10:01:01.000000000 +0200 > +++ linux-2.6.8.1.multipath/include/net/dst.h 2004-09-22 14:18:40.000000000 +0200 > @@ -48,6 +48,7 @@ > #define DST_NOXFRM 2 > #define DST_NOPOLICY 4 > #define DST_NOHASH 8 > +#define DST_BALANCED 0x10 > unsigned long lastuse; > unsigned long expires; > > diff -ruN linux-2.6.8.1.split/include/net/flow.h linux-2.6.8.1.multipath/include/net/flow.h > --- linux-2.6.8.1.split/include/net/flow.h 2004-09-22 10:01:01.000000000 +0200 > +++ linux-2.6.8.1.multipath/include/net/flow.h 2004-09-22 14:19:31.000000000 +0200 > @@ -51,6 +51,7 @@ > > __u8 proto; > __u8 flags; > +#define FLOWI_FLAG_MULTIPATHOLDROUTE 0x01 > union { > struct { > __u16 sport; > diff -ruN linux-2.6.8.1.split/include/net/ip_fib.h linux-2.6.8.1.multipath/include/net/ip_fib.h > --- linux-2.6.8.1.split/include/net/ip_fib.h 2004-09-22 10:01:01.000000000 +0200 > +++ linux-2.6.8.1.multipath/include/net/ip_fib.h 2004-09-22 14:18:08.000000000 +0200 > @@ -95,6 +95,10 @@ > unsigned char nh_sel; > unsigned char type; > unsigned char scope; > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM > + __u32 network; > + __u32 netmask; > +#endif > struct fib_info *fi; > #ifdef CONFIG_IP_MULTIPLE_TABLES > struct fib_rule *r; > @@ -119,6 +123,14 @@ > #define FIB_RES_DEV(res) (FIB_RES_NH(res).nh_dev) > #define FIB_RES_OIF(res) (FIB_RES_NH(res).nh_oif) > > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM > +#define FIB_RES_NETWORK(res) ((res).network) > +#define FIB_RES_NETMASK(res) ((res).netmask) > +#else /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ > +#define FIB_RES_NETWORK(res) (0) > +#define FIB_RES_NETMASK(res) (0) > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ > + > struct fib_table { > unsigned char tb_id; > unsigned tb_stamp; > diff -ruN linux-2.6.8.1.split/include/net/route.h linux-2.6.8.1.multipath/include/net/route.h > --- linux-2.6.8.1.split/include/net/route.h 2004-09-22 10:01:01.000000000 +0200 > +++ linux-2.6.8.1.multipath/include/net/route.h 2004-09-22 15:00:29.000000000 +0200 > @@ -46,6 +46,7 @@ > > #define RT_CONN_FLAGS(sk) (RT_TOS(inet_sk(sk)->tos) | sk->sk_localroute) > > +struct fib_nh; > struct inet_peer; > struct rtable > { > @@ -179,6 +180,9 @@ > memcpy(&fl, &(*rp)->fl, sizeof(fl)); > fl.fl_ip_sport = sport; > fl.fl_ip_dport = dport; > +#if defined(CONFIG_IP_ROUTE_MULTIPATH_CACHED) > + fl.flags |= FLOWI_FLAG_MULTIPATHOLDROUTE; > +#endif > ip_rt_put(*rp); > *rp = NULL; > return ip_route_output_flow(rp, &fl, sk, 0); > @@ -197,4 +201,69 @@ > return rt->peer; > } > > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM > +extern void __multipath_flush(void); > +static inline void multipath_flush(void) { > + __multipath_flush(); > +} > +#else /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ > +static inline void multipath_flush(void){} > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_WRANDOM */ > + > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM > +extern void __multipath_set_nhinfo(__u32 network, > + __u32 netmask, > + unsigned char prefixlen, > + const struct fib_nh* nh); > +static inline void multipath_set_nhinfo(__u32 network, > + __u32 netmask, > + unsigned char prefixlen, > + const struct fib_nh* nh) { > + __multipath_set_nhinfo(network, netmask, prefixlen, nh); > +} > +#else > +static inline void multipath_set_nhinfo(__u32 network, > + __u32 netmask, > + unsigned char prefixlen, > + const struct fib_nh* nh) { > +} > +#endif > + > + > + > +#if defined(CONFIG_IP_ROUTE_MULTIPATH_RR) || defined(CONFIG_IP_ROUTE_MULTIPATH_DRR) > +extern void __multipath_remove(struct rtable *rt); > +static inline void multipath_remove(struct rtable *rt) { > + if ( rt->u.dst.flags & DST_BALANCED ) { > + __multipath_remove( rt ); > + } > +} > +#else /* CONFIG_IP_ROUTE_MULTIPATH_RR || CONFIG_IP_ROUTE_MULTIPATH_DRR */ > +static inline void multipath_remove(struct rtable *rt) {} > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_RR || CONFIG_IP_ROUTE_MULTIPATH_DRR */ > + > + > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > +extern void __multipath_selectroute(const struct flowi *flp, > + struct rtable *rth, > + struct rtable **rp); > +static inline int multipath_selectroute(const struct flowi *flp, > + struct rtable *rth, > + struct rtable **rp) { > + if ( rth->u.dst.flags & DST_BALANCED ) { > + __multipath_selectroute( flp, rth, rp ); > + return 1; > + } > + else { > + return 0; > + } > +} > +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > +static inline int multipath_selectroute(const struct flowi *flp, > + struct rtable *rth, > + struct rtable **rp) { > + return 0; > +} > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > + > #endif /* _ROUTE_H */ > diff -ruN linux-2.6.8.1.split/net/ipv4/fib_hash.c linux-2.6.8.1.multipath/net/ipv4/fib_hash.c > --- linux-2.6.8.1.split/net/ipv4/fib_hash.c 2004-09-22 10:01:21.000000000 +0200 > +++ linux-2.6.8.1.multipath/net/ipv4/fib_hash.c 2004-09-22 15:01:49.000000000 +0200 > @@ -292,6 +292,11 @@ > res->type = f->fn_type; > res->scope = f->fn_scope; > res->prefixlen = fz->fz_order; > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_WRANDOM > + res->netmask = fz->fz_mask; > + res->network = f->fn_key & > + (0xFFFFFFFF >> (32 - fz->fz_order)); > +#endif > goto out; > } > if (err < 0) > diff -ruN linux-2.6.8.1.split/net/ipv4/Kconfig linux-2.6.8.1.multipath/net/ipv4/Kconfig > --- linux-2.6.8.1.split/net/ipv4/Kconfig 2004-09-22 10:01:21.000000000 +0200 > +++ linux-2.6.8.1.multipath/net/ipv4/Kconfig 2004-09-22 13:39:14.000000000 +0200 > @@ -94,6 +94,54 @@ > equal "cost" and chooses one of them in a non-deterministic fashion > if a matching packet arrives. > > +config IP_ROUTE_MULTIPATH_CACHED > + bool "IP: equal cost multipath with caching support (EXPERIMENTAL)" > + depends on: IP_ROUTE_MULTIPATH > + help > + Normally, equal cost multipath routing is not supported by the > + routing cache. If you say Y here, alternative routes are cached > + and on cache lookup a route is chosen in a configurable fashion. > + > + If unsure, say N. > + > +# > +# multipath policy configuration > +# > +choice > + prompt "Multipath policy" > + depends on IP_ROUTE_MULTIPATH_CACHED > + default IP_ROUTE_MULTIPATH_RANDOM > + > +config IP_ROUTE_MULTIPATH_RR > + bool "round robin (EXPERIMENTAL)" > + help > + Mulitpath routes are chosen according to Round Robin > + > +config IP_ROUTE_MULTIPATH_RANDOM > + bool "random multipath (EXPERIMENTAL)" > + help > + Multipath routes are chosen in a random fashion. Actually, > + there is no weight for a route. The advantage of this policy > + is that it is implemented stateless and therefore introduces only > + a very small delay. > +config IP_ROUTE_MULTIPATH_WRANDOM > + bool "weighted random multipath (EXPERIMENTAL)" > + help > + Multipath routes are chosen in a weighted random fashion. > + The per route weights are the weights visible via ip route 2. As the > + corresponding state management introduces some overhead routing delay > + is increased. > +config IP_ROUTE_MULTIPATH_DRR > + bool "interface round robin (EXPERIMENTAL)" > + help > + Connections are distributed in a round robin fashion over the > + available interfaces. This policy makes sense if the connections > + should be primarily distributed on interfaces and not on routes. > +endchoice > +# > +# END OF multipath policy configuration > +# > + > config IP_ROUTE_TOS > bool "IP: use TOS value as routing key" > depends on IP_ADVANCED_ROUTER > diff -ruN linux-2.6.8.1.split/net/ipv4/Makefile linux-2.6.8.1.multipath/net/ipv4/Makefile > --- linux-2.6.8.1.split/net/ipv4/Makefile 2004-09-22 10:01:21.000000000 +0200 > +++ linux-2.6.8.1.multipath/net/ipv4/Makefile 2004-09-22 13:40:36.000000000 +0200 > @@ -21,6 +21,10 @@ > obj-$(CONFIG_INET_IPCOMP) += ipcomp.o > obj-$(CONFIG_INET_TUNNEL) += xfrm4_tunnel.o > obj-$(CONFIG_IP_PNP) += ipconfig.o > +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RR) += multipath_rr.o > +obj-$(CONFIG_IP_ROUTE_MULTIPATH_RANDOM) += multipath_random.o > +obj-$(CONFIG_IP_ROUTE_MULTIPATH_WRANDOM) += multipath_wrandom.o > +obj-$(CONFIG_IP_ROUTE_MULTIPATH_DRR) += multipath_drr.o > obj-$(CONFIG_NETFILTER) += netfilter/ > obj-$(CONFIG_IP_VS) += ipvs/ > > diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_drr.c linux-2.6.8.1.multipath/net/ipv4/multipath_drr.c > --- linux-2.6.8.1.split/net/ipv4/multipath_drr.c 1970-01-01 01:00:00.000000000 +0100 > +++ linux-2.6.8.1.multipath/net/ipv4/multipath_drr.c 2004-09-22 18:09:04.000000000 +0200 > @@ -0,0 +1,292 @@ > +/* > + * Device round robin policy for multipath. > + * > + * > + * Version: $Id: multipath_drr.c,v 1.1.2.1 2004/09/16 07:42:34 elueck Exp $ > + * > + * Authors: Einar Lueck > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct multipath_device > +{ > + int ifi; /* interface index of device */ > + atomic_t usecount; > + int allocated; > +}; > + > +#define MULTIPATH_MAX_DEVICECANDIDATES 10 > + > +static struct multipath_device state[MULTIPATH_MAX_DEVICECANDIDATES]; > +static spinlock_t state_lock = SPIN_LOCK_UNLOCKED; > +static int registered_dev_notifier = 0; > +static struct rtable *last_selection = NULL; > + > +#define RTprint(a...) // printk(KERN_DEBUG a) > + > + > + > +static int __inline__ multipath_comparekeys(const struct flowi *flp1, > + const struct flowi *flp2) { > + return flp1->fl4_dst == flp2->fl4_dst && > + flp1->fl4_src == flp2->fl4_src && > + flp1->oif == flp2->oif && > +#ifdef CONFIG_IP_ROUTE_FWMARK > + flp1->fl4_fwmark == flp2->fl4_fwmark && > +#endif > + !((flp1->fl4_tos ^ flp2->fl4_tos) & > + (IPTOS_RT_MASK | RTO_ONLINK)); > +} > + > +static int __inline__ __multipath_findslot(void) { > + int i; > + for (i=0; i + if (state[i].allocated == 0) { > + return i; > + } > + } > + return -1; > +} > + > +static int __inline__ __multipath_finddev(int ifindex) > +{ > + int i; > + for (i=0; i + if (state[i].allocated != 0 && state[i].ifi == ifindex) { > + return i; > + } > + } > + return -1; > +} > + > +static int multipath_dev_event(struct notifier_block *this, > + unsigned long event, void *ptr) > +{ > + struct net_device *dev = ptr; > + int devidx; > + > + switch (event) { > + case NETDEV_UNREGISTER: > + case NETDEV_DOWN: > + spin_lock_bh(&state_lock); > + > + devidx = __multipath_finddev(dev->ifindex); > + if (devidx != -1) { > + state[devidx].allocated = 0; > + state[devidx].ifi = 0; > + atomic_set(&state[devidx].usecount, 0); > + RTprint(KERN_DEBUG"%s: successfully removed device " \ > + "with index %d\n",__FUNCTION__, devidx); > + } > + else { > + RTprint(KERN_DEBUG"%s: Device not relevant for " \ > + " multipath: %d\n", > + __FUNCTION__, devidx); > + } > + > + spin_unlock_bh(&state_lock); > + break; > + } > + return NOTIFY_DONE; > +} > + > +struct notifier_block multipath_dev_notifier = { > + .notifier_call = multipath_dev_event, > +}; > + > +void __multipath_remove(struct rtable* rt) { > + if (last_selection == rt) { > + last_selection = NULL; > + } > +} > + > +void __multipath_safe_inc(atomic_t* usecount) > +{ > + int n; > + atomic_inc(usecount); > + n = atomic_read(usecount); > + if (n<=0) { > + int i; > + RTprint("%s: detected overflow, now ill will reset all "\ > + "usecounts\n", __FUNCTION__); > + > + spin_lock_bh(&state_lock); > + for (i=0; i + atomic_set(&state[i].usecount, 0); > + } > + spin_unlock_bh(&state_lock); > + } > +} > + > +void __multipath_selectroute(const struct flowi *flp, > + struct rtable *first, struct rtable **rp) > +{ > + struct rtable *nh, *result, *cur_min; > + int min_usecount = -1; > + int devidx = -1; > + int cur_min_devidx = -1; > + > + /* register a notifier to stay informed about dying devices */ > + if (!registered_dev_notifier) { > + registered_dev_notifier = 1; > + register_netdevice_notifier(&multipath_dev_notifier); > + } > + > + /* if necessary and possible utilize the old alternative */ > + if ( ( flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) != 0 && > + last_selection != NULL ) { > + RTprint( KERN_CRIT"%s: holding route \n", __FUNCTION__ ); > + result = last_selection; > + *rp = result; > + return; > + } > + > + > + /* 1. make sure all alt. nexthops have the same GC related data */ > + /* 2. determine the new candidate to be returned */ > + result = NULL; > + cur_min = NULL; > + for (nh = rcu_dereference(first); nh; > + nh = rcu_dereference(nh->u.rt_next)) { > + if ( ( nh->u.dst.flags & DST_BALANCED ) != 0 && > + multipath_comparekeys(&nh->fl, flp ) ) { > + int nh_ifidx = nh->u.dst.dev->ifindex; > + nh->u.dst.lastuse = jiffies; > + nh->u.dst.__use++; > + if (result != NULL) { > + continue; > + } > + > + /* search for the output interface */ > + /* this is not SMP safe, only add/remove are > + SMP safe as wrong usecount updates have no big > + impact */ > + devidx = __multipath_finddev(nh_ifidx); > + if (devidx==-1) { > + /* add the interface to the array > + SMP safe */ > + spin_lock_bh(&state_lock); > + > + /* due to SMP: search again */ > + devidx = __multipath_finddev(nh_ifidx); > + if (devidx==-1) { > + /* add entry for device */ > + devidx = __multipath_findslot(); > + if (devidx==-1) { > + /* unlikely but possible */ > + RTprint(KERN_DEBUG"%s: " \ > + "out of space\n", > + __FUNCTION__); > + continue; > + } > + > + state[devidx].allocated = 1; > + state[devidx].ifi = nh_ifidx; > + atomic_set(&state[devidx].usecount, 0); > + min_usecount = 0; > + RTprint(KERN_DEBUG"%s: created " \ > + " for " \ > + "device %d and " \ > + "min_usecount " \ > + " == -1\n", > + __FUNCTION__, > + nh_ifidx ); > + } > + > + spin_unlock_bh(&state_lock); > + } > + > + if (min_usecount == 0) { > + /* if the device has not been used it is > + the primary target */ > + RTprint(KERN_DEBUG"%s: now setting " \ > + "result to device %d\n", > + __FUNCTION__, nh_ifidx ); > + > + __multipath_safe_inc(&state[devidx].usecount); > + result = nh; > + } > + else { > + int count = > + atomic_read(&state[devidx].usecount); > + > + if (min_usecount == -1 || > + count < min_usecount) { > + cur_min = nh; > + cur_min_devidx = devidx; > + min_usecount = count; > + > + RTprint(KERN_DEBUG"%s: found " \ > + "device " \ > + "%d with usecount == %d\n", > + __FUNCTION__, > + nh_ifidx, > + min_usecount); > + } > + } > + } > + } > + > + if (!result) { > + if (cur_min) { > + RTprint( KERN_DEBUG"%s: index of device in state "\ > + "array: %d\n", > + __FUNCTION__, cur_min_devidx ); > + __multipath_safe_inc(&state[cur_min_devidx].usecount); > + result = cur_min; > + } > + else { > + RTprint( KERN_DEBUG"%s: utilized first\n", > + __FUNCTION__); > + result = first; > + } > + } > + else { > + RTprint(KERN_DEBUG"%s: utilize result: found device " \ > + "%d with usecount == %d\n", > + __FUNCTION__, result->u.dst.dev->ifindex, > + min_usecount); > + > + } > + > + *rp = result; > + last_selection = result; > +} > diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_random.c linux-2.6.8.1.multipath/net/ipv4/multipath_random.c > --- linux-2.6.8.1.split/net/ipv4/multipath_random.c 1970-01-01 01:00:00.000000000 +0100 > +++ linux-2.6.8.1.multipath/net/ipv4/multipath_random.c 2004-09-22 17:59:24.000000000 +0200 > @@ -0,0 +1,124 @@ > +/* > + * Random policy for multipath. > + * > + * > + * Version: $Id: multipath_random.c,v 1.1.2.3 2004/09/21 08:42:11 elueck Exp $ > + * > + * Authors: Einar Lueck > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define RTprint(a...) // printk(KERN_DEBUG a) > + > +#define MULTIPATH_MAX_CANDIDATES 40 > + > +/* interface to random number generation */ > +static unsigned int RANDOM_SEED = 93186752; > +static __inline__ unsigned int random(unsigned int ubound); > + > +static int __inline__ multipath_comparekeys(const struct flowi *flp1, > + const struct flowi *flp2) { > + return flp1->fl4_dst == flp2->fl4_dst && > + flp1->fl4_src == flp2->fl4_src && > + flp1->oif == flp2->oif && > +#ifdef CONFIG_IP_ROUTE_FWMARK > + flp1->fl4_fwmark == flp2->fl4_fwmark && > +#endif > + !((flp1->fl4_tos ^ flp2->fl4_tos) & > + (IPTOS_RT_MASK | RTO_ONLINK)); > +} > + > +void __multipath_selectroute(const struct flowi *flp, > + struct rtable *first, > + struct rtable **rp) { > + struct rtable *rt; > + struct rtable *decision; > + unsigned char candidate_count = 0; > + > + /* count all candidate */ > + for (rt = rcu_dereference(first); rt; > + rt = rcu_dereference(rt->u.rt_next)) { > + if ( ( rt->u.dst.flags & DST_BALANCED ) != 0 && > + multipath_comparekeys(&rt->fl, flp) ) { > + ++candidate_count; > + } > + } > + > + /* choose a random candidate */ > + decision = first; > + if ( candidate_count > 1 ) { > + unsigned char i = 0; > + unsigned char candidate_no = (unsigned char) > + random(candidate_count); > + RTprint( "%s: randomly chosen candidate: %d (count: %d)\n", > + __FUNCTION__, candidate_no, candidate_count ); > + > + > + /* find chosen candidate and adjust GC data for all candidates > + to ensure they stay in cache */ > + for (rt = first; rt; rt = rt->u.rt_next) { > + if ( ( rt->u.dst.flags & DST_BALANCED ) != 0 && > + multipath_comparekeys(&rt->fl, flp) ) { > + rt->u.dst.lastuse = jiffies; > + if (i == candidate_no) { > + decision = rt; > + } > + if (i >= candidate_count) { > + break; > + } > + i++; > + } > + } > + } > + > + decision->u.dst.__use++; > + *rp = decision; > +} > + > +static __inline__ unsigned int random(unsigned int ubound) > +{ > + static unsigned int a = 1588635695, > + q = 2, > + r = 1117695901; > + RANDOM_SEED = a*(RANDOM_SEED % q) - r*(RANDOM_SEED / q); > + return RANDOM_SEED % ubound; > +} > + > diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_rr.c linux-2.6.8.1.multipath/net/ipv4/multipath_rr.c > --- linux-2.6.8.1.split/net/ipv4/multipath_rr.c 1970-01-01 01:00:00.000000000 +0100 > +++ linux-2.6.8.1.multipath/net/ipv4/multipath_rr.c 2004-09-22 17:03:07.000000000 +0200 > @@ -0,0 +1,118 @@ > +/* > + * Round robin policy for multipath. > + * > + * > + * Version: $Id: multipath_rr.c,v 1.1.2.2 2004/09/16 07:42:34 elueck Exp $ > + * > + * Authors: Einar Lueck > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define RTprint(a...) // printk(KERN_DEBUG a) > + > +#define MULTIPATH_MAX_CANDIDATES 40 > + > +static struct rtable* last_used = NULL; > + > +static int __inline__ multipath_comparekeys(const struct flowi *flp1, > + const struct flowi *flp2) { > + return flp1->fl4_dst == flp2->fl4_dst && > + flp1->fl4_src == flp2->fl4_src && > + flp1->oif == flp2->oif && > +#ifdef CONFIG_IP_ROUTE_FWMARK > + flp1->fl4_fwmark == flp2->fl4_fwmark && > +#endif > + !((flp1->fl4_tos ^ flp2->fl4_tos) & > + (IPTOS_RT_MASK | RTO_ONLINK)); > +} > + > +void __multipath_remove(struct rtable *rt) > +{ > + if (last_used==rt) { > + last_used = NULL; > + } > +} > + > +void __multipath_selectroute(const struct flowi *flp, > + struct rtable *first, struct rtable **rp) > +{ > + struct rtable *nh, *result, *min_use_cand = NULL; > + int min_use = -1; > + > + /* if necessary and possible utilize the old alternative */ > + if ( ( flp->flags & FLOWI_FLAG_MULTIPATHOLDROUTE ) != 0 && > + last_used != NULL ) { > + RTprint( KERN_CRIT"%s: holding route \n", > + __FUNCTION__ ); > + result = last_used; > + goto out; > + } > + > + > + /* 1. make sure all alt. nexthops have the same GC related data */ > + /* 2. determine the new candidate to be returned */ > + result = NULL; > + for (nh = rcu_dereference(first); nh; > + nh = rcu_dereference(nh->u.rt_next)) { > + if ( ( nh->u.dst.flags & DST_BALANCED ) != 0 && > + multipath_comparekeys(&nh->fl, flp ) ) { > + nh->u.dst.lastuse = jiffies; > + > + if (min_use == -1 || nh->u.dst.__use < min_use) { > + min_use = nh->u.dst.__use; > + min_use_cand = nh; > + } > + RTprint( KERN_CRIT"%s: found balanced entry\n", > + __FUNCTION__ ); > + } > + } > + result = min_use_cand; > + if (!result) { > + result = first; > + } > + > + out: > + last_used = result; > + result->u.dst.__use++; > + *rp = result; > +} > + > + > diff -ruN linux-2.6.8.1.split/net/ipv4/multipath_wrandom.c linux-2.6.8.1.multipath/net/ipv4/multipath_wrandom.c > --- linux-2.6.8.1.split/net/ipv4/multipath_wrandom.c 1970-01-01 01:00:00.000000000 +0100 > +++ linux-2.6.8.1.multipath/net/ipv4/multipath_wrandom.c 2004-09-22 17:01:43.000000000 +0200 > @@ -0,0 +1,374 @@ > +/* > + * Weighted random policy for multipath. > + * > + * > + * Version: $Id: multipath_wrandom.c,v 1.1.2.3 2004/09/22 07:51:40 elueck Exp $ > + * > + * Authors: Einar Lueck > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version > + * 2 of the License, or (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define MPprint(a...) // printk(KERN_DEBUG a) > + > +#define MULTIPATH_STATE_SIZE 15 > + > +struct multipath_candidate { > + struct multipath_candidate *next; > + int power; > + struct rtable *rt; > +}; > + > +struct multipath_dest { > + struct list_head list; > + > + const struct fib_nh *nh_info; > + __u32 netmask; > + __u32 network; > + unsigned char prefixlen; > + > + struct rcu_head rcu; > +}; > + > +struct multipath_bucket { > + struct list_head head; > + spinlock_t lock; > +}; > + > +struct multipath_route { > + struct list_head list; > + > + int oif; > + __u32 gw; > + struct list_head dests; > + > + struct rcu_head rcu; > +}; > + > + > +/* state: primarily weight per route information */ > +static int multipath_state_initialized = 0; > +static spinlock_t state_big_lock = SPIN_LOCK_UNLOCKED; > +static struct multipath_bucket state[MULTIPATH_STATE_SIZE]; > + > + > +/* interface to random number generation */ > +static unsigned int RANDOM_SEED = 93186752; > +static __inline__ unsigned int random(unsigned int ubound); > + > +static int __inline__ multipath_comparekeys(const struct flowi *flp1, > + const struct flowi *flp2) { > + return flp1->fl4_dst == flp2->fl4_dst && > + flp1->fl4_src == flp2->fl4_src && > + flp1->oif == flp2->oif && > +#ifdef CONFIG_IP_ROUTE_FWMARK > + flp1->fl4_fwmark == flp2->fl4_fwmark && > +#endif > + !((flp1->fl4_tos ^ flp2->fl4_tos) & > + (IPTOS_RT_MASK | RTO_ONLINK)); > +} > + > + > +static unsigned char __multipath_lookup_weight(const struct flowi *fl, > + const struct rtable *rt) { > + const int state_idx = rt->idev->dev->ifindex % MULTIPATH_STATE_SIZE; > + struct multipath_route *r; > + struct multipath_route *target_route = NULL; > + struct multipath_dest *d; > + int weight = 1; > + > + /* lookup the weight information for a certain route */ > + rcu_read_lock(); > + > + /* find state entry for gateway or add one if necessary */ > + list_for_each_entry_rcu(r, &state[state_idx].head, list) { > + if (r->gw == rt->rt_gateway && > + r->oif == rt->idev->dev->ifindex) { > + target_route = r; > + break; > + } > + } > + if (!target_route) { > + /* this should not happen... but we are prepared */ > + printk( KERN_CRIT"%s: missing state for gateway: %u and " \ > + "device %d\n", __FUNCTION__, rt->rt_gateway, > + rt->idev->dev->ifindex); > + goto out; > + } > + > + /* find state entry for destination */ > + list_for_each_entry_rcu(d, &target_route->dests, list) { > + __u32 targetnetwork = fl->fl4_dst & > + (0xFFFFFFFF >> (32 - d->prefixlen)); > + > + if ((targetnetwork & d->netmask) == d->network) { > + weight = d->nh_info->nh_weight; > + MPprint("%s: found weight %d for gateway %u\n", > + __FUNCTION__, weight, rt->rt_gateway); > + goto out; > + } > + } > + > + out: > + rcu_read_unlock(); > + return weight; > +} > + > +static void __multipath_init_state(void) > +{ > + spin_lock(&state_big_lock); > + > + /* check again due to SMP and to prevent contention */ > + if (!multipath_state_initialized) { > + int i; > + for (i = 0; i < MULTIPATH_STATE_SIZE; ++i) { > + INIT_LIST_HEAD(&state[i].head); > + state[i].lock = SPIN_LOCK_UNLOCKED; > + } > + } > + > + /* now mark initialized */ > + multipath_state_initialized = 1; > + > + spin_unlock(&state_big_lock); > +} > + > +static void inline __multipath_init(void) > +{ > + /* do not spinlock to reduce unnecessary contention */ > + if (!multipath_state_initialized) { > + __multipath_init_state(); > + } > +} > + > +void __multipath_selectroute(const struct flowi *flp, > + struct rtable *first, > + struct rtable **rp) { > + struct rtable *rt; > + struct rtable *decision; > + struct multipath_candidate *first_mpc = NULL; > + struct multipath_candidate *mpc, *last_mpc = NULL; > + int power = 0; > + int last_power; > + int selector; > + const size_t size_mpc = sizeof(struct multipath_candidate); > + > + /* init state if necessary */ > + __multipath_init(); > + > + > + /* collect all candidates and identify their weights */ > + for (rt = rcu_dereference(first); rt; > + rt = rcu_dereference(rt->u.rt_next)) { > + if ((rt->u.dst.flags & DST_BALANCED) != 0 && > + multipath_comparekeys(&rt->fl, flp) ) { > + struct multipath_candidate* mpc = > + (struct multipath_candidate*) > + kmalloc(size_mpc, GFP_KERNEL); > + > + power += __multipath_lookup_weight(flp, rt) * 10000; > + > + mpc->power = power; > + mpc->rt = rt; > + mpc->next = NULL; > + > + if (!first_mpc) > + first_mpc = mpc; > + else > + last_mpc->next = mpc; > + > + last_mpc = mpc; > + } > + } > + > + /* choose a weighted random candidate */ > + decision = first; > + selector = random(power); > + MPprint("%s: random number %d in range %d\n", __FUNCTION__, selector, > + power); > + last_power = 0; > + > + > + /* select candidate, adjust GC data and cleanup local state */ > + decision = first; > + last_mpc = NULL; > + for (mpc = first_mpc; mpc; mpc = mpc->next) { > + mpc->rt->u.dst.lastuse = jiffies; > + MPprint("%s: last_power = %d, selector: %d, mpc->power: %d\n", > + __FUNCTION__, last_power, selector, mpc->power); > + if (last_power <= selector && selector < mpc->power) { > + decision = mpc->rt; > + MPprint("%s: selected %u\n", __FUNCTION__, > + decision->rt_gateway); > + } > + last_power = mpc->power; > + if (last_mpc) { > + kfree(last_mpc); > + } > + last_mpc = mpc; > + } > + if (last_mpc) { > + /* concurrent __multipath_flush may lead to !last_mpc */ > + kfree(last_mpc); > + } > + > + decision->u.dst.__use++; > + *rp = decision; > +} > + > +void __multipath_set_nhinfo(__u32 network, > + __u32 netmask, > + unsigned char prefixlen, > + const struct fib_nh* nh) > +{ > + const int state_idx = nh->nh_oif % MULTIPATH_STATE_SIZE; > + struct multipath_route *r, *target_route = NULL; > + struct multipath_dest *d, *target_dest = NULL; > + > + /* init state if necessary */ > + __multipath_init(); > + > + /* store the weight information for a certain route */ > + spin_lock(&state[state_idx].lock); > + > + /* find state entry for gateway or add one if necessary */ > + list_for_each_entry_rcu(r, &state[state_idx].head, list) { Since you hold the lock here, list_for_each_entry() should suffice, right? > + if (r->gw == nh->nh_gw && r->oif == nh->nh_oif) { > + target_route = r; > + break; > + } > + } > + if (!target_route) { > + const size_t size_rt = sizeof(struct multipath_route); > + target_route = (struct multipath_route *) > + kmalloc(size_rt, GFP_KERNEL); > + > + target_route->gw = nh->nh_gw; > + target_route->oif = nh->nh_oif; > + memset(&target_route->rcu, sizeof(struct rcu_head), 0); The memset() is not needed, since call_rcu() fully initializes the structure. OK if needed for debug purposes, I guess. > + INIT_LIST_HEAD(&target_route->dests); > + > + list_add_rcu(&target_route->list, &state[state_idx].head); > + } > + > + /* find state entry for destination or add one if necessary */ > + list_for_each_entry_rcu(d, &target_route->dests, list) { Since you hold the lock here, list_for_each_entry() should suffice, right? > + if (d->nh_info == nh) { > + target_dest = d; > + break; > + } > + } > + if (!target_dest) { > + const size_t size_dst = sizeof(struct multipath_dest); > + target_dest = (struct multipath_dest*) > + kmalloc(size_dst, GFP_KERNEL); > + > + target_dest->nh_info = nh; > + target_dest->network = network; > + target_dest->netmask = netmask; > + target_dest->prefixlen = prefixlen; > + memset(&target_dest->rcu, sizeof(struct rcu_head), 0); The memset() is not needed, since call_rcu() fully initializes the structure. OK if needed for debug purposes, I guess. > + > + list_add_rcu(&target_dest->list, &target_route->dests); > + } > + /* else: we already stored this info for another destination => > + we are finished */ > + > + spin_unlock(&state[state_idx].lock); > +} > + > + > +static void __multipath_free(struct rcu_head *head) > +{ > + struct multipath_route *rt = container_of(head, struct multipath_route, > + rcu); > + kfree(rt); > +} > + > +static void __multipath_free_dst(struct rcu_head *head) > +{ > + struct multipath_dest *dst = container_of(head, > + struct multipath_dest, > + rcu); > + kfree(dst); > +} > + > +void __multipath_flush() > +{ > + int i; > + > + MPprint("%s: called\n", __FUNCTION__); > + > + /* init state if necessary */ > + __multipath_init(); > + > + /* defere delete to all entries */ > + for (i = 0; i < MULTIPATH_STATE_SIZE; ++i) { > + struct multipath_route *r; > + spin_lock(&state[i].lock); > + > + list_for_each_entry_rcu(r, &state[i].head, list) { Since you hold the spinlock here, list_for_each_entry() suffices. > + struct multipath_dest *d; > + list_for_each_entry_rcu(d, &r->dests, list) { Since you hold the spinlock here, list_for_each_entry() suffices. Or am I misunderstanding the locking design? > + list_del_rcu(&d->list); > + call_rcu(&d->rcu, > + __multipath_free_dst); Another approach to consider is to just do the upper-level list_del_rcu(), and have have the RCU callback (__multipath_free()) remove the "dests" from the structure after a single grace period. This would have the advantage of shrinking the multipath_dest structure, since only the multipath_bucket structure would need an rcu_head in that case. It would also reduce the number of callbacks registered and invoked. > + > + } > + list_del_rcu(&r->list); > + call_rcu(&r->rcu, > + __multipath_free); > + } > + > + spin_unlock(&state[i].lock); > + } > + > + MPprint("%s: finished\n", __FUNCTION__); > +} > + > +static __inline__ unsigned int random(unsigned int ubound) > +{ > + static unsigned int a = 1588635695, > + q = 2, > + r = 1117695901; > + RANDOM_SEED = a*(RANDOM_SEED % q) - r*(RANDOM_SEED / q); > + return RANDOM_SEED % ubound; > +} > diff -ruN linux-2.6.8.1.split/net/ipv4/route.c linux-2.6.8.1.multipath/net/ipv4/route.c > --- linux-2.6.8.1.split/net/ipv4/route.c 2004-09-22 10:01:49.000000000 +0200 > +++ linux-2.6.8.1.multipath/net/ipv4/route.c 2004-09-22 17:29:29.000000000 +0200 > @@ -129,7 +129,7 @@ > int ip_rt_secret_interval = 10 * 60 * HZ; > static unsigned long rt_deadline; > > -#define RTprint(a...) printk(KERN_DEBUG a) > +#define RTprint(a...) // printk(KERN_DEBUG a) > > static struct timer_list rt_flush_timer; > static struct timer_list rt_periodic_timer; > @@ -442,11 +442,13 @@ > > static __inline__ void rt_free(struct rtable *rt) > { > + multipath_remove( rt ); Good catch... Interestingly enough, I left out the equivalent to this call to multipath_remove() in my very first use of RCU, longer ago than I care to admit. A very bright fellow named Jan-Simon Pendry ran into the corresponding panic. Despite never having heard of RCU, and having no clue how it worked, he managed to generate the correct patch! Needless to say, he had some -very- pointed questions for me on his next visit to Beaverton... ;-) > call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free); > } > > static __inline__ void rt_drop(struct rtable *rt) > { > + multipath_remove( rt ); > ip_rt_put(rt); > call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free); > } > @@ -508,6 +510,54 @@ > return score; > } > > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > +static struct rtable **rt_remove_balanced_route(struct rtable **chain_head, > + struct rtable *expentry, > + int* removed_count) > +{ > + int passedexpired = 0; > + struct rtable **nextstep = NULL; > + struct rtable **rthp = chain_head; > + struct rtable *rth; > + if (removed_count) > + *removed_count = 0; > + while ((rth = *rthp) != NULL) { > + if ( rth == expentry ) { > + passedexpired = 1; > + } > + > + if (((*rthp)->u.dst.flags & DST_BALANCED) != 0 && > + compare_keys(&(*rthp)->fl, &expentry->fl)) { > + if (*rthp == expentry) { > + *rthp = rth->u.rt_next; > + continue; > + } > + else { > + *rthp = rth->u.rt_next; > + rt_free(rth); > + if (removed_count) > + ++(*removed_count); > + } > + } > + else { > + if ( !((*rthp)->u.dst.flags & DST_BALANCED) && > + passedexpired && !nextstep ) { > + nextstep = &rth->u.rt_next; > + } > + rthp = &rth->u.rt_next; > + } > + } > + > + rt_free(expentry); > + if (removed_count) > + ++(*removed_count); > + > + return nextstep; > +} > + > +#endif > + > + > /* This runs via a timer and thus is always in BH context. */ > static void rt_check_expire(unsigned long dummy) > { > @@ -539,8 +589,24 @@ > } > > /* Cleanup aged off entries. */ > - *rthp = rth->u.rt_next; > - rt_free(rth); > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + /* remove all related balanced entries if necessary */ > + if ( rth->u.dst.flags & DST_BALANCED ) { > + rthp = rt_remove_balanced_route( > + &rt_hash_table[i].chain, > + rth, NULL); > + if (!rthp) { > + break; > + } > + } > + else { > + *rthp = rth->u.rt_next; > + rt_free(rth); > + } > +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > + *rthp = rth->u.rt_next; > + rt_free(rth); > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > } > spin_unlock(&rt_hash_table[i].lock); > > @@ -588,6 +654,9 @@ > if (delay < 0) > delay = ip_rt_min_delay; > > + /* flush existing multipath state*/ > + multipath_flush(); > + > spin_lock_bh(&rt_flush_lock); > > if (del_timer(&rt_flush_timer) && delay > 0 && rt_deadline) { > @@ -706,9 +775,29 @@ > rthp = &rth->u.rt_next; > continue; > } > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + /* remove all related balanced entries if necessary */ > + if ( rth->u.dst.flags & DST_BALANCED ) { > + int r; > + rthp = rt_remove_balanced_route( > + &rt_hash_table[i].chain, > + rth, > + &r); > + goal -= r; > + if (!rthp) { > + break; > + } > + } > + else { > + *rthp = rth->u.rt_next; > + rt_free(rth); > + goal--; > + } > +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > *rthp = rth->u.rt_next; > rt_free(rth); > goal--; > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > } > spin_unlock_bh(&rt_hash_table[k].lock); > if (goal <= 0) > @@ -789,7 +878,12 @@ > > spin_lock_bh(&rt_hash_table[hash].lock); > while ((rth = *rthp) != NULL) { > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + if (!(rth->u.dst.flags & DST_BALANCED) && > + compare_keys(&rth->fl, &rt->fl)) { > +#else > if (compare_keys(&rth->fl, &rt->fl)) { > +#endif > /* Put it first */ > *rthp = rth->u.rt_next; > /* > @@ -1623,6 +1717,10 @@ > } > > rth->u.dst.flags= DST_HOST; > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + if ( res->fi->fib_nhs > 1 ) > + rth->u.dst.flags |= DST_BALANCED; > +#endif > if (in_dev->cnf.no_policy) > rth->u.dst.flags |= DST_NOPOLICY; > if (in_dev->cnf.no_xfrm) > @@ -1691,7 +1789,60 @@ > struct in_device *in_dev, > u32 daddr, u32 saddr, u32 tos) > { > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + struct rtable* rth; > + unsigned char hop, hopcount, lasthop; > + int err = -EINVAL; > + unsigned hash; > + hopcount = res->fi->fib_nhs; > + lasthop = hopcount - 1; > + > + /* distinguish between multipath and singlepath */ > + if ( hopcount < 2 ) > + return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, > + saddr, tos); > + > + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", __FUNCTION__, > + hopcount); > + > + /* add all alternatives to the routing cache */ > + for ( hop = 0; hop < hopcount; ++hop ) { > + res->nh_sel = hop; > + > + RTprint( KERN_DEBUG"%s: entered (hopcount: %d)\n", > + __FUNCTION__, hopcount); > + > + /* create a routing cache entry */ > + err = __mkroute_input( skb, res, in_dev, daddr, saddr, tos, > + &rth ); > + if ( err ) > + return err; > + > + > + /* put it into the cache */ > + hash = rt_hash_code(daddr, saddr ^ (fl->iif << 5), tos); > + err = rt_intern_hash(hash, rth, (struct rtable**)&skb->dst); > + if ( err ) > + return err; > + > + /* forward hop information to multipath impl. */ > + multipath_set_nhinfo(FIB_RES_NETWORK(*res), > + FIB_RES_NETMASK(*res), > + res->prefixlen, > + &FIB_RES_NH(*res)); > + > + > + /* only for the last hop the reference count is handled > + outside */ > + RTprint( KERN_DEBUG"%s: balanced entry created: %d\n", > + __FUNCTION__, rth ); > + if ( hop == lasthop ) > + atomic_set(&(skb->dst->__refcnt), 1); > + } > + return err; > +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > return ip_mkroute_input_def(skb, res, fl, in_dev, daddr, saddr, tos); > +#endif /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > } > > > @@ -2012,6 +2163,10 @@ > } > > rth->u.dst.flags= DST_HOST; > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + if (res->fi->fib_nhs > 1) > + rth->u.dst.flags |= DST_BALANCED; > +#endif > if (in_dev->cnf.no_xfrm) > rth->u.dst.flags |= DST_NOXFRM; > if (in_dev->cnf.no_policy) > @@ -2103,7 +2258,77 @@ > struct net_device *dev_out, > unsigned flags) > { > +#ifdef CONFIG_IP_ROUTE_MULTIPATH_CACHED > + u32 tos = RT_FL_TOS(oldflp); > + unsigned char hop; > + unsigned hash; > + int err = -EINVAL; > + unsigned char hopcount = res->fi->fib_nhs; > + struct rtable* rth; > + > + RTprint( KERN_DEBUG"%s: entered (hopcount: %d, fl->oif: %d)\n", > + __FUNCTION__, hopcount, fl->oif); > + > + if (res->fi->fib_nhs > 1) { > + for ( hop = 0; hop < hopcount; ++hop ) { > + struct net_device *dev2nexthop; > + RTprint( KERN_DEBUG"%s: hop %d of %d\n", __FUNCTION__, > + hop, hopcount ); > + > + res->nh_sel = hop; > + > + /* hold a work reference to the output device */ > + dev2nexthop = FIB_RES_DEV(*res); > + dev_hold(dev2nexthop); > + > + err = __mkroute_output(&rth, res, fl, oldflp, > + dev2nexthop, flags); > + > + /** FIXME remove debug code */ > + RTprint( KERN_DEBUG"%s: balanced entry created: %d " \ > + " (GW: %u)\n", > + __FUNCTION__, > + &rth->u.dst, > + FIB_RES_GW(*res) ); > + > + if ( err != 0 ) { > + goto cleanup; > + } > + > + RTprint( KERN_DEBUG"%s: created successfully %d\n", > + __FUNCTION__, hop ); > + > + hash = rt_hash_code(oldflp->fl4_dst, > + oldflp->fl4_src ^ > + (oldflp->oif << 5), tos); > + err = rt_intern_hash(hash, rth, rp); > + RTprint( KERN_DEBUG"%s: hashed %d\n", > + __FUNCTION__, hop ); > + > + /* forward hop information to multipath impl. */ > + multipath_set_nhinfo(FIB_RES_NETWORK(*res), > + FIB_RES_NETMASK(*res), > + res->prefixlen, > + &FIB_RES_NH(*res)); > + cleanup: > + /* release work reference to output device */ > + dev_put(dev2nexthop); > + > + if ( err != 0 ) { > + return err; > + } > + } > + RTprint( KERN_DEBUG"%s: exited loop\n", __FUNCTION__ ); > + atomic_set(&(*rp)->u.dst.__refcnt, 1); > + return err; > + } > + else { > + return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, > + flags); > + } > +#else /* CONFIG_IP_ROUTE_MULTIPATH_CACHED */ > return ip_mkroute_output_def(rp, res, fl, oldflp, dev_out, flags); > +#endif > } > > /* > @@ -2316,6 +2541,15 @@ > #endif > !((rth->fl.fl4_tos ^ flp->fl4_tos) & > (IPTOS_RT_MASK | RTO_ONLINK))) { > + /* check for multipath routes and choose one if > + necessary */ > + if (multipath_selectroute(flp, rth, rp)) { > + dst_hold(&(*rp)->u.dst); > + RT_CACHE_STAT_INC(out_hit); > + rcu_read_unlock_bh(); > + return 0; > + } > + > rth->u.dst.lastuse = jiffies; > dst_hold(&rth->u.dst); > rth->u.dst.__use++; > > From herbert@gondor.apana.org.au Thu Sep 23 17:41:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 17:41:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O0fGxS019787 for ; Thu, 23 Sep 2004 17:41:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAe8h-0007Xs-00; Fri, 24 Sep 2004 10:40:43 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAe8c-0001N3-00; Fri, 24 Sep 2004 10:40:38 +1000 Date: Fri, 24 Sep 2004 10:40:38 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040924004038.GA5252@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040923164149.5368d291.davem@davemloft.net> <20040924001225.GA5051@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924001225.GA5051@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 654 Lines: 16 On Fri, Sep 24, 2004 at 10:12:25AM +1000, herbert wrote: > > How about this? We always to treat TSO frames as one packet. We > continue to obey the congestion window by starting with a TSO MSS > that is small enough. We increase the TSO MSS as the congestion > window goes up. > > That should work, no? Probably not. There many things (such as snd_cwnd) in the stack that doesn't work properly when the mss changes drastically like this. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Sep 23 18:08:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 18:08:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O18NM6020661 for ; Thu, 23 Sep 2004 18:08:24 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAeYw-0007ga-00; Fri, 24 Sep 2004 11:07:50 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAeYn-0001QC-00; Fri, 24 Sep 2004 11:07:41 +1000 Date: Fri, 24 Sep 2004 11:07:41 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040924010741.GA5452@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040923164149.5368d291.davem@davemloft.net> <20040924001225.GA5051@gondor.apana.org.au> <20040924004038.GA5252@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924004038.GA5252@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 473 Lines: 11 On Fri, Sep 24, 2004 at 10:40:38AM +1000, herbert wrote: > > Probably not. There many things (such as snd_cwnd) in the stack > that doesn't work properly when the mss changes drastically like this. Perhaps we should start counting in bytes instead of packets? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From pablo@eurodev.net Thu Sep 23 18:08:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 18:08:32 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O18P1B020659 for ; Thu, 23 Sep 2004 18:08:26 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp06.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040924010808.BIKZ11445.smtp06.retemail.es@eurodev.net>; Fri, 24 Sep 2004 03:08:08 +0200 Message-ID: <415372F4.1010400@eurodev.net> Date: Fri, 24 Sep 2004 03:05:56 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, "David S. Miller" Subject: [NETLINK] hlist initilization Content-Type: multipart/mixed; boundary="------------060603070007000300000509" X-archive-position: 9395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1065 Lines: 38 This is a multi-part message in MIME format. --------------060603070007000300000509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Davem, This patch adds proper initialization for hlist. It applies to af_netlink.c with the workqueue patch reverted. Signed-off-by: Pablo Neira Ayuso regards, Pablo --------------060603070007000300000509 Content-Type: text/x-patch; name="hlist-initialize.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hlist-initialize.patch" ===== net/netlink/af_netlink.c 1.55 vs edited ===== --- 1.55/net/netlink/af_netlink.c Thu Sep 23 20:27:46 2004 +++ edited/net/netlink/af_netlink.c Sat Oct 23 19:09:17 2004 @@ -1191,6 +1191,10 @@ static int __init netlink_proto_init(void) { struct sk_buff *dummy_skb; + int i; + + for(i=0; i sizeof(dummy_skb->cb)) { printk(KERN_CRIT "netlink_init: panic\n"); --------------060603070007000300000509-- From pablo@eurodev.net Thu Sep 23 18:14:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 18:15:02 -0700 (PDT) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O1Em2D021405 for ; Thu, 23 Sep 2004 18:14:49 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp06.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040924011432.BKXA11445.smtp06.retemail.es@eurodev.net>; Fri, 24 Sep 2004 03:14:32 +0200 Message-ID: <41537473.1090306@eurodev.net> Date: Fri, 24 Sep 2004 03:12:19 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com, "David S. Miller" Subject: [NETLINK] netlink_ack takes gfp flag as parameter Content-Type: multipart/mixed; boundary="------------000902000507060900080103" X-archive-position: 9397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 6856 Lines: 220 This is a multi-part message in MIME format. --------------000902000507060900080103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Davem, AFAIK ip_queue, ip6_queue and dn_rtmsg use netlink_ack in interrupt context which calls alloc_skb with the GFP_KERNEL flag. This patch adds a new parameter to netlink_ack to set the gfp flag. Signed-off-by: Pablo Neira Ayuso regards, Pablo --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack.patch" ===== include/linux/netlink.h 1.19 vs edited ===== --- 1.19/include/linux/netlink.h Sat Aug 28 02:13:43 2004 +++ edited/include/linux/netlink.h Fri Sep 24 02:02:05 2004 @@ -119,7 +119,7 @@ extern void netlink_detach(int unit); extern int netlink_post(int unit, struct sk_buff *skb); extern struct sock *netlink_kernel_create(int unit, void (*input)(struct sock *sk, int len)); -extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err); +extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err, int gfp_mask); extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid, int nonblock); extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32 pid, __u32 group, int allocation); ===== net/netlink/af_netlink.c 1.56 vs edited ===== --- 1.56/net/netlink/af_netlink.c Fri Sep 24 02:01:00 2004 +++ edited/net/netlink/af_netlink.c Fri Sep 24 02:02:06 2004 @@ -957,7 +957,8 @@ return 0; } -void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err) +void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err, + int gfp_mask) { struct sk_buff *skb; struct nlmsghdr *rep; @@ -969,7 +970,7 @@ else size = NLMSG_SPACE(4 + NLMSG_ALIGN(nlh->nlmsg_len)); - skb = alloc_skb(size, GFP_KERNEL); + skb = alloc_skb(size, gfp_mask); if (!skb) { struct sock *sk; --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack-audit.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-audit.patch" ===== kernel/audit.c 1.3 vs edited ===== --- 1.3/kernel/audit.c Tue Sep 14 02:23:21 2004 +++ edited/kernel/audit.c Fri Sep 24 02:02:06 2004 @@ -419,9 +419,9 @@ if (rlen > skb->len) rlen = skb->len; if ((err = audit_receive_msg(skb, nlh))) { - netlink_ack(skb, nlh, -err); + netlink_ack(skb, nlh, -err, GFP_KERNEL); } else if (nlh->nlmsg_flags & NLM_F_ACK) - netlink_ack(skb, nlh, 0); + netlink_ack(skb, nlh, 0, GFP_KERNEL); skb_pull(skb, rlen); } return 0; --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack-dn_rtmsg.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-dn_rtmsg.patch" ===== net/decnet/netfilter/dn_rtmsg.c 1.3 vs edited ===== --- 1.3/net/decnet/netfilter/dn_rtmsg.c Thu Jun 5 02:57:08 2003 +++ edited/net/decnet/netfilter/dn_rtmsg.c Fri Sep 24 02:14:31 2004 @@ -99,7 +99,9 @@ } -#define RCV_SKB_FAIL(err) do { netlink_ack(skb, nlh, (err)); return; } while (0) +#define RCV_SKB_FAIL(err) do { \ + netlink_ack(skb, nlh, (err), GFP_ATOMIC); return; \ + } while (0) \ static inline void dnrmg_receive_user_skb(struct sk_buff *skb) { --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack-ip6_queue.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-ip6_queue.patch" ===== net/ipv6/netfilter/ip6_queue.c 1.14 vs edited ===== --- 1.14/net/ipv6/netfilter/ip6_queue.c Thu Jan 29 00:59:34 2004 +++ edited/net/ipv6/netfilter/ip6_queue.c Fri Sep 24 02:19:58 2004 @@ -474,7 +474,9 @@ ipq_issue_verdict(entry, NF_DROP); } -#define RCV_SKB_FAIL(err) do { netlink_ack(skb, nlh, (err)); return; } while (0) +#define RCV_SKB_FAIL(err) do { \ + netlink_ack(skb, nlh, (err), GFP_ATOMIC); return; \ + } while (0) \ static inline void ipq_rcv_skb(struct sk_buff *skb) --------------000902000507060900080103 Content-Type: text/x-csrc; name="netlink_ack-ip_queue.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-ip_queue.c" ===== net/ipv4/netfilter/ip_queue.c 1.17 vs edited ===== --- 1.17/net/ipv4/netfilter/ip_queue.c Tue Sep 7 23:18:28 2004 +++ edited/net/ipv4/netfilter/ip_queue.c Fri Sep 24 02:15:45 2004 @@ -471,7 +471,9 @@ ipq_issue_verdict(entry, NF_DROP); } -#define RCV_SKB_FAIL(err) do { netlink_ack(skb, nlh, (err)); return; } while (0) +#define RCV_SKB_FAIL(err) do { \ + netlink_ack(skb, nlh, (err), GFP_ATOMIC); return; \ + } while (0) \ static inline void ipq_rcv_skb(struct sk_buff *skb) @@ -526,7 +528,7 @@ RCV_SKB_FAIL(status); if (flags & NLM_F_ACK) - netlink_ack(skb, nlh, 0); + netlink_ack(skb, nlh, 0, GFP_ATOMIC); return; } --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack-rtnetlink.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-rtnetlink.patch" ===== net/core/rtnetlink.c 1.27 vs edited ===== --- 1.27/net/core/rtnetlink.c Mon Sep 13 02:03:08 2004 +++ edited/net/core/rtnetlink.c Fri Sep 24 02:02:05 2004 @@ -558,9 +558,9 @@ */ if (err == 0) return -1; - netlink_ack(skb, nlh, err); + netlink_ack(skb, nlh, err, GFP_KERNEL); } else if (nlh->nlmsg_flags&NLM_F_ACK) - netlink_ack(skb, nlh, 0); + netlink_ack(skb, nlh, 0, GFP_KERNEL); skb_pull(skb, rlen); } --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack-tcp_diag.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-tcp_diag.patch" ===== net/ipv4/tcp_diag.c 1.16 vs edited ===== --- 1.16/net/ipv4/tcp_diag.c Tue Sep 7 18:18:04 2004 +++ edited/net/ipv4/tcp_diag.c Fri Sep 24 02:02:05 2004 @@ -634,7 +634,7 @@ return; err = tcpdiag_rcv_msg(skb, nlh); if (err || nlh->nlmsg_flags & NLM_F_ACK) - netlink_ack(skb, nlh, err); + netlink_ack(skb, nlh, err, GFP_KERNEL); } } --------------000902000507060900080103 Content-Type: text/x-patch; name="netlink_ack-xfrm_user.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netlink_ack-xfrm_user.patch" ===== net/xfrm/xfrm_user.c 1.48 vs edited ===== --- 1.48/net/xfrm/xfrm_user.c Fri Sep 10 23:35:53 2004 +++ edited/net/xfrm/xfrm_user.c Fri Sep 24 02:02:06 2004 @@ -995,7 +995,7 @@ if (xfrm_user_rcv_msg(skb, nlh, &err) < 0) { if (err == 0) return -1; - netlink_ack(skb, nlh, err); + netlink_ack(skb, nlh, err, GFP_KERNEL); } else if (nlh->nlmsg_flags & NLM_F_ACK) netlink_ack(skb, nlh, 0); skb_pull(skb, rlen); --------------000902000507060900080103-- From davem@redhat.com Thu Sep 23 18:18:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 18:18:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O1Hxx8021792 for ; Thu, 23 Sep 2004 18:18:00 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8O1Hkbt017425; Thu, 23 Sep 2004 21:17:46 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8O1Hkr24269; Thu, 23 Sep 2004 21:17:46 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8O1HZQ7025220; Thu, 23 Sep 2004 21:17:35 -0400 Date: Thu, 23 Sep 2004 18:16:39 -0700 From: "David S. Miller" To: Pablo Neira Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] hlist initilization Message-Id: <20040923181639.754ca876.davem@redhat.com> In-Reply-To: <415372F4.1010400@eurodev.net> References: <415372F4.1010400@eurodev.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 350 Lines: 11 On Fri, 24 Sep 2004 03:05:56 +0200 Pablo Neira wrote: > This patch adds proper initialization for hlist. It applies to > af_netlink.c with the workqueue patch reverted. nl_table[] is in the BSS and therefore will be properly zero initialized already. I took advantage of this same property in the net/ipv4/fib_hash.c changes. From davem@davemloft.net Thu Sep 23 18:19:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 18:19:12 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O1J7mr022133 for ; Thu, 23 Sep 2004 18:19:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAeiD-0007JW-00; Thu, 23 Sep 2004 18:17:25 -0700 Date: Thu, 23 Sep 2004 18:17:25 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040923181725.3e19cee8.davem@davemloft.net> In-Reply-To: <20040924010741.GA5452@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040923164149.5368d291.davem@davemloft.net> <20040924001225.GA5051@gondor.apana.org.au> <20040924004038.GA5252@gondor.apana.org.au> <20040924010741.GA5452@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 407 Lines: 11 On Fri, 24 Sep 2004 11:07:41 +1000 Herbert Xu wrote: > On Fri, Sep 24, 2004 at 10:40:38AM +1000, herbert wrote: > > > > Probably not. There many things (such as snd_cwnd) in the stack > > that doesn't work properly when the mss changes drastically like this. > > Perhaps we should start counting in bytes instead of packets? No, because routers drop packets not bytes :-) From pablo@eurodev.net Thu Sep 23 18:21:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 18:21:47 -0700 (PDT) Received: from smtp07.retemail.es (smtp07.auna.com [62.81.186.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O1Lfis022604 for ; Thu, 23 Sep 2004 18:21:42 -0700 Received: from eurodev.net ([217.217.182.158]) by smtp07.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040924012125.RELV9737.smtp07.retemail.es@eurodev.net>; Fri, 24 Sep 2004 03:21:25 +0200 Message-ID: <41537610.1040403@eurodev.net> Date: Fri, 24 Sep 2004 03:19:12 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: jamal , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> In-Reply-To: <20040923120707.GB32624@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 852 Lines: 29 Hi Herbert, Herbert Xu wrote: >On Wed, Sep 22, 2004 at 08:08:40AM -0400, jamal wrote: > > >>Since netlink is being used for a lot of things now, it may be time to >>obsolete those assumptions. >> >> > >I'm not against changes. But so far I haven't seen anything concrete >about what these new things are yet :) > > Nothing mysterious :), people are willing to put more and more things in kernel space, so I wanted to evaluate netlink sockets as a method to pass information from kernel to user space and vice-versa. I think that, instead of putting all the things in kernel space, a kernel component can provide an API to user space programs to interact with them, so I wanted to evaluate them to figure out what they could do and what they could't do at this moment. I can also focus this to component replication. regards, Pablo From herbert@gondor.apana.org.au Thu Sep 23 19:13:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 19:13:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O2DGSr024474 for ; Thu, 23 Sep 2004 19:13:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAfZy-00086o-00; Fri, 24 Sep 2004 12:13:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAfZv-0001XB-00; Fri, 24 Sep 2004 12:12:55 +1000 From: Herbert Xu To: pablo@eurodev.net (Pablo Neira) Subject: Re: [NETLINK] netlink_ack takes gfp flag as parameter Cc: netdev@oss.sgi.com, davem@redhat.com Organization: Core In-Reply-To: <41537473.1090306@eurodev.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Fri, 24 Sep 2004 12:12:55 +1000 X-archive-position: 9401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 540 Lines: 13 Pablo Neira wrote: > > AFAIK ip_queue, ip6_queue and dn_rtmsg use netlink_ack in interrupt > context which calls alloc_skb with the GFP_KERNEL flag. This patch adds > a new parameter to netlink_ack to set the gfp flag. Bogus. All of those functions call netlink_ack in the context of the sending process. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Thu Sep 23 19:56:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 19:57:01 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O2uuCH025705 for ; Thu, 23 Sep 2004 19:56:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CAgGN-0003cO-Dd for netdev@oss.sgi.com; Thu, 23 Sep 2004 22:56:47 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CAgGH-0000uZ-PO; Thu, 23 Sep 2004 22:56:42 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040923120520.GA32624@gondor.apana.org.au> References: <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <1095821624.1045.6.camel@jzny.localdomain> <20040922034634.GA14928@gondor.apana.org.au> <1095852956.1048.47.camel@jzny.localdomain> <20040923120520.GA32624@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095994597.1045.26.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Sep 2004 22:56:37 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 861 Lines: 34 On Thu, 2004-09-23 at 08:05, Herbert Xu wrote: > > Try explicitly reducing the socket buffer size and see what happens > > What's wrong with the default sizes? If you decrease it far enough > of course it's going to overflow. The idea is to reproduce the overun ;-> > > set i to 10000 or a little more > > You might want to optimise your add path. It was painful with 20000 :) Probably debug prints slowing things; you could of course do some batching like so: $TC actions add \ action drop index 1 action drop index 2 action drop index 3 ... Do 10 a time in the for loop and should be roughly 10 times as fast > > to dump: tc actions ls action drop > > That was much faster, no overflows at all: I apologize i dont have time right now to chase it and experiment; my test machine can be made to reproduce it. Maybe this weekend cheers, jamal From hadi@cyberus.ca Thu Sep 23 20:04:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 20:04:24 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O34Kdg026239 for ; Thu, 23 Sep 2004 20:04:20 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CAgNW-0006BD-Vt for netdev@oss.sgi.com; Thu, 23 Sep 2004 23:04:10 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CAgNS-0001UM-Me; Thu, 23 Sep 2004 23:04:06 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040923120707.GB32624@gondor.apana.org.au> References: <1095633569.1047.107.camel@jzny.localdomain> <20040919231734.GA10124@gondor.apana.org.au> <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095995042.1044.34.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Sep 2004 23:04:02 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1103 Lines: 32 On Thu, 2004-09-23 at 08:07, Herbert Xu wrote: > On Wed, Sep 22, 2004 at 08:08:40AM -0400, jamal wrote: > > > > Since netlink is being used for a lot of things now, it may be time to > > obsolete those assumptions. > > I'm not against changes. But so far I haven't seen anything concrete > about what these new things are yet :) So lets start by using the following logic: 1) If you made the socket buffers small enough compared to message size/arrival rate, then an overrun will happen corrollary: 2) If you made the message size/arrival fast enough relative to socket size, an overrun will happen If you agree that #1 is equivalent to #2, then you can experiment by #1 to see the issue. > > Note also, theres a lot of wastage of that scarce sock buffer via page > > sized skbs - its not as trivial to fix, but would go some way to improve > > overrunning of the socket. > > I wasn't aware of this scarcity problem. Can you elaborate? The NLM_GOODSIZE allocation done for each netlink skb, In the case of the dump you dont apriori know how much space you need, so it is fair. cheers, jamal From hadi@cyberus.ca Thu Sep 23 20:10:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 20:10:10 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O3A4Zi026769 for ; Thu, 23 Sep 2004 20:10:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CAgT3-0002ut-3v for netdev@oss.sgi.com; Thu, 23 Sep 2004 23:09:53 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CAgSz-0001vk-IZ; Thu, 23 Sep 2004 23:09:49 -0400 Subject: Re: [IPv4] Kill remnant of ip_nat_dumb From: jamal Reply-To: hadi@cyberus.ca To: Harald Welte Cc: Herbert Xu , ak@suse.de, davem@davemloft.net, netdev@oss.sgi.com In-Reply-To: <20040923082955.GP3236@sunbeam.de.gnumonks.org> References: <20040923061923.GL3236@sunbeam.de.gnumonks.org> <20040923082955.GP3236@sunbeam.de.gnumonks.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1095995385.1045.41.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Sep 2004 23:09:45 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 389 Lines: 14 On Thu, 2004-09-23 at 04:29, Harald Welte wrote: > On Thu, Sep 23, 2004 at 06:12:55PM +1000, Herbert Xu wrote: [..] > Independent of this, I just wanted to note that if there was working > and compatible code, it had it's use for high performance static nat > applications. indeed. What happened to he who breaketh fixeth? I may take a crack at it when i get the cycles. cheers, jamal From herbert@gondor.apana.org.au Thu Sep 23 20:20:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 20:20:48 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O3KckZ030561 for ; Thu, 23 Sep 2004 20:20:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAgcx-0008Td-00; Fri, 24 Sep 2004 13:20:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAgcs-0001fp-00; Fri, 24 Sep 2004 13:20:02 +1000 Date: Fri, 24 Sep 2004 13:20:02 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040924032002.GA6384@gondor.apana.org.au> References: <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <1095821624.1045.6.camel@jzny.localdomain> <20040922034634.GA14928@gondor.apana.org.au> <1095852956.1048.47.camel@jzny.localdomain> <20040923120520.GA32624@gondor.apana.org.au> <1095994597.1045.26.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095994597.1045.26.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1934 Lines: 44 On Thu, Sep 23, 2004 at 10:56:37PM -0400, jamal wrote: > > > What's wrong with the default sizes? If you decrease it far enough > > of course it's going to overflow. > > The idea is to reproduce the overun ;-> OK, I've just tried 4096 and nothing: 21619 socket(PF_NETLINK, SOCK_RAW, 0) = 3 21619 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 21619 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [4096], 4) = 0 ... 21619 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, sa_data="\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0"}, msg_iov(1)=[{"\30\16\0\0002\0\2\0\366@SAsT\0\0\0 00\4\16\1\0p\0\0 \0\24"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3608 21619 write(1, "\n\taction order 0: gact action dr"..., 4096) = 4096 21619 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, sa_data="\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0"}, msg_iov(1)=[{"\30\16\0\0002\0\2\0\366@SAsT\0\0\0 00\4\16\1\0p\0\0 \0\24"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3608 21619 write(1, "0\n\t index 19312 ref 1 bind 0\n \n\t"..., 4096) = 4096 21619 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, sa_data="\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0"}, msg_iov(1)=[{"\30\16\0\0002\0\2\0\366@SAsT\0\0\0 00\4\16\1\0p\0\0 \0\24"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3608 21619 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, sa_data="\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0"}, msg_iov(1)=[{"\30\16\0\0002\0\2\0\366@SAsT\0\0\0 00\4\16\1\0p\0\0 \0\24"..., 16384}], msg_controllen=0, msg_flags=0}, 0) = 3608 21619 write(1, "action drop\n\t random type none p"..., 4096) = 4096 > $TC actions add \ > action drop index 1 > action drop index 2 > action drop index 3 ... > > Do 10 a time in the for loop and should be roughly 10 times as fast Cool, didn't know that. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Sep 23 20:25:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 20:25:23 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O3PEm9031003 for ; Thu, 23 Sep 2004 20:25:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAghS-00006b-00; Fri, 24 Sep 2004 13:24:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAghM-0001gV-00; Fri, 24 Sep 2004 13:24:40 +1000 Date: Fri, 24 Sep 2004 13:24:40 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040924032440.GB6384@gondor.apana.org.au> References: <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095995042.1044.34.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1427 Lines: 42 On Thu, Sep 23, 2004 at 11:04:02PM -0400, jamal wrote: > > So lets start by using the following logic: > 1) If you made the socket buffers small enough compared to message > size/arrival rate, then an overrun will happen > corrollary: > 2) If you made the message size/arrival fast enough relative to socket > size, an overrun will happen > > If you agree that #1 is equivalent to #2, then you can experiment by #1 > to see the issue. There are three possible netlink usages: 1) Request/response: No overruns should occur. 2) Dump: No overruns should occur because of dump only fills in the next one when the previous one is taken off the queue by the user. 3) Async messages: Overruns may occur if the arrival rate exceeds the application's processing capacity or if the queue is too small for a burst. Now we were discussing about how we can do congestion control for 3). But to do that we need to know exactly what these messages are. For example if they're coming from an external source as is the case in ip_queue then you can't congestion control it at all. Oh and never use the same socket for 1+2) and 3) together. You can use the socket for 1) and 2), but 3) must be in its own socket. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Thu Sep 23 20:29:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 20:29:14 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O3T8Ja031417 for ; Thu, 23 Sep 2004 20:29:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAgl6-000091-00; Fri, 24 Sep 2004 13:28:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAgl4-0001hA-00; Fri, 24 Sep 2004 13:28:30 +1000 Date: Fri, 24 Sep 2004 13:28:30 +1000 To: "David S. Miller" Cc: Pablo Neira , hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040924032830.GC6384@gondor.apana.org.au> References: <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040923121651.51a58cf2.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 865 Lines: 24 On Thu, Sep 23, 2004 at 12:16:51PM -0700, David S. Miller wrote: > > Simpler would be: > > 1) For each netlink socket, allocate a page, much like TCP sockets > do. > > 2) Construct the netlink response in this page sized buffer, > keeping track of how much of the page is actually used. > > 3) At the end, allocate the skb with the necessary length, > copy into the skb from the page buffer. > > 4) Since the RTNL semaphore is held during the length of these > operations, the per-socket page needs no locking. Can someone please tell me why we need to do this at all? Most of the dump messages should be close to PAGE_SIZE anyway, no? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Thu Sep 23 20:35:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 20:35:51 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O3Zk5c031903 for ; Thu, 23 Sep 2004 20:35:47 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i8O3ZGTi011282; Fri, 24 Sep 2004 07:35:18 +0400 Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "Luis R. Rodriguez" Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040923215447.GD30131@ruslug.rutgers.edu> References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> <20040923215447.GD30131@ruslug.rutgers.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8fpkCBNjFfMFdPaA8Oer" Organization: MIPT Message-Id: <1095997232.17587.8.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 24 Sep 2004 07:40:32 +0400 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on dea.vocord.com X-Virus-Status: Clean X-archive-position: 9408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1600 Lines: 51 --=-8fpkCBNjFfMFdPaA8Oer Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote: > RFC:=20 >=20 > Can and should we work towards using this as interface for drivers that > need callbacks from an external (closed source) library/HAL? As I mentioned to Richard Jonson, it can be considered as ioctl. ioctl-ng! Unified interface (as ioctl) can be used for any type of modules. It is just a bit extended ioctl :) And _yes_, it can be used to turn on/off binary-only callbacks. Remember pwc - closed part can register callback and open part can send message, or even closed part can register notification when open part registers itself and begin to "trash the kernel". I understand that it is not right way to include it is into the kernel, but I personally do not understand how it is different=20 from just extended ioctl. It was designed to be usefull and convenient, and it is. BTW, any binary-only module can _itself_ create netlink socket with input callback. And that is all - it will be absolutely the same as above. One may consider connector as yet-another-netlink-helper. --=20 Evgeniy Polyakov Crash is better than data corruption. -- Art Grabowski --=-8fpkCBNjFfMFdPaA8Oer Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBU5cwIKTPhE+8wY0RArB9AJ9BVtouc/+Y4NtRR36frbG5W/k/gACeKd9o Va1gj+T3Fd5AXJOAOMWsLpU= =mKmD -----END PGP SIGNATURE----- --=-8fpkCBNjFfMFdPaA8Oer-- From davem@davemloft.net Thu Sep 23 22:40:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:40:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5ekYX002762 for ; Thu, 23 Sep 2004 22:40:46 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAinV-0007gz-00; Thu, 23 Sep 2004 22:39:09 -0700 Date: Thu, 23 Sep 2004 22:39:09 -0700 From: "David S. Miller" To: Herbert Xu Cc: pablo@eurodev.net, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040923223909.6f4da27f.davem@davemloft.net> In-Reply-To: <20040924032830.GC6384@gondor.apana.org.au> References: <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 326 Lines: 9 On Fri, 24 Sep 2004 13:28:30 +1000 Herbert Xu wrote: > Can someone please tell me why we need to do this at all? > > Most of the dump messages should be close to PAGE_SIZE anyway, no? It's moreso for the "give me a single entry" requests than for dumps. NLMSG_GOODSIZE is used for all cases. From davem@davemloft.net Thu Sep 23 22:48:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:49:00 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5mswY003349 for ; Thu, 23 Sep 2004 22:48:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAivT-0007hj-00; Thu, 23 Sep 2004 22:47:23 -0700 Date: Thu, 23 Sep 2004 22:47:23 -0700 From: "David S. Miller" To: "David S. Miller" Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-Id: <20040923224723.743da8c8.davem@davemloft.net> In-Reply-To: <20040921203118.734a0a7e.davem@davemloft.net> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> <20040921203118.734a0a7e.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 346 Lines: 10 On Tue, 21 Sep 2004 20:31:18 -0700 "David S. Miller" wrote: > I'll work on the set of patches implementing the above tomorrow > and will send it to the list for review and commentary. Ok, coming in followup emails. The hardest was abstracting the generic neigh seq_file stuff such that net/atm/clip.c could still fit in. From mcgrof@studorgs.rutgers.edu Thu Sep 23 22:48:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:49:02 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5mtda003355 for ; Thu, 23 Sep 2004 22:48:55 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 13778F99BD; Fri, 24 Sep 2004 01:48:44 -0400 (EDT) Date: Fri, 24 Sep 2004 01:48:44 -0400 To: Evgeniy Polyakov Cc: "Luis R. Rodriguez" , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". Message-ID: <20040924054844.GO30131@ruslug.rutgers.edu> Mail-Followup-To: Evgeniy Polyakov , "Luis R. Rodriguez" , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> <20040923215447.GD30131@ruslug.rutgers.edu> <1095997232.17587.8.camel@uganda> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kr14OxHsRwZHHqxS" Content-Disposition: inline In-Reply-To: <1095997232.17587.8.camel@uganda> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 2010 Lines: 61 --kr14OxHsRwZHHqxS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 24, 2004 at 07:40:32AM +0400, Evgeniy Polyakov wrote: > On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote: > > RFC:=20 > >=20 > > Can and should we work towards using this as interface for drivers that > > need callbacks from an external (closed source) library/HAL? >=20 > As I mentioned to Richard Jonson, it can be considered as > ioctl. ioctl-ng! > Unified interface (as ioctl) can be used for any type of modules. > It is just a bit extended ioctl :) >=20 > And _yes_, it can be used to turn on/off binary-only callbacks. > Remember pwc - closed part can register callback and open part can > send message, or even closed part can register notification when > open part registers itself and begin to "trash the kernel". >=20 > I understand that it is not right way to include it is into the kernel, > but I personally do not understand how it is different=20 > from just extended ioctl. It was designed to be usefull and convenient, > and it is. >=20 > BTW, any binary-only module can _itself_ create netlink socket > with input callback. And that is all - it will be absolutely > the same as above. >=20 > One may consider connector as yet-another-netlink-helper. >=20 Eh. I'm just wondering if there's any *right* way of using binary callbacks on a linux driver so that it doesn't *taint* and possibly *trash it*, as you said. I was wondering if perhaps through the connector we could somehow protect the kernel of possibly ill-behaved callb= acks. Comments? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --kr14OxHsRwZHHqxS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBU7U7at1JN+IKUl4RAmPrAJ9wEi5xKV+97H/viSOrxyda89l6yACgmRZr 3ilj8b4TnhHMG0xOeASvblk= =YK7d -----END PGP SIGNATURE----- --kr14OxHsRwZHHqxS-- From davem@davemloft.net Thu Sep 23 22:50:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:50:17 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5o8CX004019 for ; Thu, 23 Sep 2004 22:50:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAiwj-0007i2-00; Thu, 23 Sep 2004 22:48:41 -0700 Date: Thu, 23 Sep 2004 22:48:41 -0700 From: "David S. Miller" To: laforge@gnumonks.org Cc: netdev@oss.sgi.com Subject: [1/6]: Abstract neigh table walking Message-Id: <20040923224841.16ac32fa.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 28429 Lines: 1166 This way we can hide hash table accesses inside of net/core/neigh.c # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 15:15:26-07:00 davem@nuts.davemloft.net # [NET]: Abstract neigh table walking. # # This way no code actually needs to traverse the # neigh hash tables outside of net/core/neighbour.c # # Signed-off-by: David S. Miller # # net/ipv4/arp.c # 2004/09/23 15:14:50-07:00 davem@nuts.davemloft.net +20 -163 # [NET]: Abstract neigh table walking. # # This way no code actually needs to traverse the # neigh hash tables outside of net/core/neighbour.c # # Signed-off-by: David S. Miller # # net/decnet/dn_neigh.c # 2004/09/23 15:14:50-07:00 davem@nuts.davemloft.net +52 -120 # [NET]: Abstract neigh table walking. # # This way no code actually needs to traverse the # neigh hash tables outside of net/core/neighbour.c # # Signed-off-by: David S. Miller # # net/core/neighbour.c # 2004/09/23 15:14:50-07:00 davem@nuts.davemloft.net +260 -0 # [NET]: Abstract neigh table walking. # # This way no code actually needs to traverse the # neigh hash tables outside of net/core/neighbour.c # # Signed-off-by: David S. Miller # # net/atm/clip.c # 2004/09/23 15:14:50-07:00 davem@nuts.davemloft.net +117 -129 # [NET]: Abstract neigh table walking. # # This way no code actually needs to traverse the # neigh hash tables outside of net/core/neighbour.c # # Signed-off-by: David S. Miller # # include/net/neighbour.h # 2004/09/23 15:14:49-07:00 davem@nuts.davemloft.net +19 -0 # [NET]: Abstract neigh table walking. # # This way no code actually needs to traverse the # neigh hash tables outside of net/core/neighbour.c # # Signed-off-by: David S. Miller # diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-23 22:25:53 -07:00 +++ b/include/net/neighbour.h 2004-09-23 22:25:53 -07:00 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -223,6 +224,24 @@ extern int neigh_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern void neigh_app_ns(struct neighbour *n); + +extern void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neighbour *, void *), void *cookie); +extern void __neigh_for_each_release(struct neigh_table *tbl, int (*cb)(struct neighbour *)); +extern void pneigh_for_each(struct neigh_table *tbl, void (*cb)(struct pneigh_entry *)); + +struct neigh_seq_state { + struct neigh_table *tbl; + void *(*neigh_sub_iter)(struct neigh_seq_state *state, + struct neighbour *n, loff_t *pos); + unsigned int bucket; + unsigned int flags; +#define NEIGH_SEQ_NEIGH_ONLY 0x00000001 +#define NEIGH_SEQ_IS_PNEIGH 0x00000002 +#define NEIGH_SEQ_SKIP_NOARP 0x00000004 +}; +extern void *neigh_seq_start(struct seq_file *, loff_t *, struct neigh_table *, unsigned int); +extern void *neigh_seq_next(struct seq_file *, void *, loff_t *); +extern void neigh_seq_stop(struct seq_file *, void *); extern int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p, diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c 2004-09-23 22:25:53 -07:00 +++ b/net/atm/clip.c 2004-09-23 22:25:53 -07:00 @@ -123,64 +123,49 @@ spin_unlock_bh(&entry->neigh->dev->xmit_lock); } - -static void idle_timer_check(unsigned long dummy) +/* The neighbour entry n->lock is held. */ +static int neigh_check_cb(struct neighbour *n) { - int i; + struct atmarp_entry *entry = NEIGH2ENTRY(n); + struct clip_vcc *cv; - /*DPRINTK("idle_timer_check\n");*/ - write_lock(&clip_tbl.lock); - for (i = 0; i <= NEIGH_HASHMASK; i++) { - struct neighbour **np; + for (cv = entry->vccs; cv; cv = cv->next) { + unsigned long exp = cv->last_use + cv->idle_timeout; - for (np = &clip_tbl.hash_buckets[i]; *np;) { - struct neighbour *n = *np; - struct atmarp_entry *entry = NEIGH2ENTRY(n); - struct clip_vcc *clip_vcc; - - write_lock(&n->lock); - - for (clip_vcc = entry->vccs; clip_vcc; - clip_vcc = clip_vcc->next) - if (clip_vcc->idle_timeout && - time_after(jiffies, clip_vcc->last_use+ - clip_vcc->idle_timeout)) { - DPRINTK("releasing vcc %p->%p of " - "entry %p\n",clip_vcc,clip_vcc->vcc, - entry); - vcc_release_async(clip_vcc->vcc, - -ETIMEDOUT); - } - if (entry->vccs || - time_before(jiffies, entry->expires)) { - np = &n->next; - write_unlock(&n->lock); - continue; - } - if (atomic_read(&n->refcnt) > 1) { - struct sk_buff *skb; - - DPRINTK("destruction postponed with ref %d\n", - atomic_read(&n->refcnt)); - while ((skb = skb_dequeue(&n->arp_queue)) != - NULL) - dev_kfree_skb(skb); - np = &n->next; - write_unlock(&n->lock); - continue; - } - *np = n->next; - DPRINTK("expired neigh %p\n",n); - n->dead = 1; - write_unlock(&n->lock); - neigh_release(n); + if (cv->idle_timeout && time_after(jiffies, exp)) { + DPRINTK("releasing vcc %p->%p of entry %p\n", + cv, cv->vcc, entry); + vcc_release_async(cv->vcc, -ETIMEDOUT); } } + + if (entry->vccs || time_before(jiffies, entry->expires)) + return 0; + + if (atomic_read(&n->refcnt) > 1) { + struct sk_buff *skb; + + DPRINTK("destruction postponed with ref %d\n", + atomic_read(&n->refcnt)); + + while ((skb = skb_dequeue(&n->arp_queue)) != NULL) + dev_kfree_skb(skb); + + return 0; + } + + DPRINTK("expired neigh %p\n",n); + return 1; +} + +static void idle_timer_check(unsigned long dummy) +{ + write_lock(&clip_tbl.lock); + __neigh_for_each_release(&clip_tbl, neigh_check_cb); mod_timer(&idle_timer, jiffies+CLIP_CHECK_INTERVAL*HZ); write_unlock(&clip_tbl.lock); } - static int clip_arp_rcv(struct sk_buff *skb) { struct atm_vcc *vcc; @@ -833,120 +818,126 @@ } } +/* This means the neighbour entry has no attached VCC objects. */ +#define SEQ_NO_VCC_TOKEN ((void *) 2) + static void atmarp_info(struct seq_file *seq, struct net_device *dev, struct atmarp_entry *entry, struct clip_vcc *clip_vcc) { + unsigned long exp; char buf[17]; - int svc, off; + int svc, llc, off; + + svc = ((clip_vcc == SEQ_NO_VCC_TOKEN) || + (clip_vcc->vcc->sk->sk_family == AF_ATMSVC)); + + llc = ((clip_vcc == SEQ_NO_VCC_TOKEN) || + clip_vcc->encap); + + if (clip_vcc == SEQ_NO_VCC_TOKEN) + exp = entry->neigh->used; + else + exp = clip_vcc->last_use; - svc = !clip_vcc || clip_vcc->vcc->sk->sk_family == AF_ATMSVC; - seq_printf(seq, "%-6s%-4s%-4s%5ld ", dev->name, svc ? "SVC" : "PVC", - !clip_vcc || clip_vcc->encap ? "LLC" : "NULL", - (jiffies-(clip_vcc ? clip_vcc->last_use : entry->neigh->used))/HZ); + exp = (jiffies - exp) / HZ; - off = scnprintf(buf, sizeof(buf) - 1, "%d.%d.%d.%d", NIPQUAD(entry->ip)); + seq_printf(seq, "%-6s%-4s%-4s%5ld ", + dev->name, + svc ? "SVC" : "PVC", + llc ? "LLC" : "NULL", + exp); + + off = scnprintf(buf, sizeof(buf) - 1, "%d.%d.%d.%d", + NIPQUAD(entry->ip)); while (off < 16) buf[off++] = ' '; buf[off] = '\0'; seq_printf(seq, "%s", buf); - if (!clip_vcc) { + if (clip_vcc == SEQ_NO_VCC_TOKEN) { if (time_before(jiffies, entry->expires)) seq_printf(seq, "(resolving)\n"); else seq_printf(seq, "(expired, ref %d)\n", atomic_read(&entry->neigh->refcnt)); } else if (!svc) { - seq_printf(seq, "%d.%d.%d\n", clip_vcc->vcc->dev->number, - clip_vcc->vcc->vpi, clip_vcc->vcc->vci); + seq_printf(seq, "%d.%d.%d\n", + clip_vcc->vcc->dev->number, + clip_vcc->vcc->vpi, + clip_vcc->vcc->vci); } else { svc_addr(seq, &clip_vcc->vcc->remote); seq_putc(seq, '\n'); } } -struct arp_state { - int bucket; - struct neighbour *n; +struct clip_seq_state { + /* This member must be first. */ + struct neigh_seq_state ns; + + /* Local to clip specific iteration. */ struct clip_vcc *vcc; }; - -static void *arp_vcc_walk(struct arp_state *state, - struct atmarp_entry *e, loff_t *l) -{ - struct clip_vcc *vcc = state->vcc; - if (!vcc) - vcc = e->vccs; - if (vcc == (void *)1) { - vcc = e->vccs; - --*l; - } - for (; vcc; vcc = vcc->next) { - if (--*l < 0) - break; - } - state->vcc = vcc; - return (*l < 0) ? state : NULL; -} - -static void *arp_get_idx(struct arp_state *state, loff_t l) +static struct clip_vcc *clip_seq_next_vcc(struct atmarp_entry *e, + struct clip_vcc *curr) { - void *v = NULL; - - for (; state->bucket <= NEIGH_HASHMASK; state->bucket++) { - for (; state->n; state->n = state->n->next) { - v = arp_vcc_walk(state, NEIGH2ENTRY(state->n), &l); - if (v) - goto done; - } - state->n = clip_tbl.hash_buckets[state->bucket + 1]; + if (!curr) { + curr = e->vccs; + if (!curr) + return SEQ_NO_VCC_TOKEN; + return curr; } -done: - return v; + if (curr == SEQ_NO_VCC_TOKEN) + return NULL; + + curr = curr->next; + + return curr; } -static void *arp_seq_start(struct seq_file *seq, loff_t *pos) +static void *clip_seq_vcc_walk(struct clip_seq_state *state, + struct atmarp_entry *e, loff_t *pos) { - struct arp_state *state = seq->private; - void *ret = (void *)1; + struct clip_vcc *vcc = state->vcc; - read_lock_bh(&clip_tbl.lock); - state->bucket = 0; - state->n = clip_tbl.hash_buckets[0]; - state->vcc = (void *)1; - if (*pos) - ret = arp_get_idx(state, *pos); - return ret; -} + vcc = clip_seq_next_vcc(e, vcc); + if (vcc && pos != NULL) { + while (*pos) { + vcc = clip_seq_next_vcc(e, vcc); + if (!vcc) + break; + --(*pos); + } + } + state->vcc = vcc; -static void arp_seq_stop(struct seq_file *seq, void *v) + return vcc; +} + +static void *clip_seq_sub_iter(struct neigh_seq_state *_state, + struct neighbour *n, loff_t *pos) { - struct arp_state *state = seq->private; + struct clip_seq_state *state = (struct clip_seq_state *) _state; - if (state->bucket != -1) - read_unlock_bh(&clip_tbl.lock); + return clip_seq_vcc_walk(state, NEIGH2ENTRY(n), pos); } -static void *arp_seq_next(struct seq_file *seq, void *v, loff_t *pos) +static void *clip_seq_start(struct seq_file *seq, loff_t *pos) { - struct arp_state *state = seq->private; - - v = arp_get_idx(state, 1); - *pos += !!PTR_ERR(v); - return v; + return neigh_seq_start(seq, pos, &clip_tbl, NEIGH_SEQ_NEIGH_ONLY); } -static int arp_seq_show(struct seq_file *seq, void *v) +static int clip_seq_show(struct seq_file *seq, void *v) { static char atm_arp_banner[] = "IPitf TypeEncp Idle IP address ATM address\n"; - if (v == (void *)1) + if (v == SEQ_START_TOKEN) { seq_puts(seq, atm_arp_banner); - else { - struct arp_state *state = seq->private; - struct neighbour *n = state->n; + } else { + struct clip_seq_state *state = seq->private; + struct neighbour *n = v; struct clip_vcc *vcc = state->vcc; atmarp_info(seq, n->dev, NEIGH2ENTRY(n), vcc); @@ -955,15 +946,15 @@ } static struct seq_operations arp_seq_ops = { - .start = arp_seq_start, - .next = arp_seq_next, - .stop = arp_seq_stop, - .show = arp_seq_show, + .start = clip_seq_start, + .next = neigh_seq_next, + .stop = neigh_seq_stop, + .show = clip_seq_show, }; static int arp_seq_open(struct inode *inode, struct file *file) { - struct arp_state *state; + struct clip_seq_state *state; struct seq_file *seq; int rc = -EAGAIN; @@ -972,6 +963,8 @@ rc = -ENOMEM; goto out_kfree; } + memset(state, 0, sizeof(*state)); + state->ns.neigh_sub_iter = clip_seq_sub_iter; rc = seq_open(file, &arp_seq_ops); if (rc) @@ -987,16 +980,11 @@ goto out; } -static int arp_seq_release(struct inode *inode, struct file *file) -{ - return seq_release_private(inode, file); -} - static struct file_operations arp_seq_fops = { .open = arp_seq_open, .read = seq_read, .llseek = seq_lseek, - .release = arp_seq_release, + .release = seq_release_private, .owner = THIS_MODULE }; #endif diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-23 22:25:53 -07:00 +++ b/net/core/neighbour.c 2004-09-23 22:25:53 -07:00 @@ -1489,6 +1489,266 @@ return skb->len; } +void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neighbour *, void *), void *cookie) +{ + int chain; + + read_lock_bh(&tbl->lock); + for (chain = 0; chain <= NEIGH_HASHMASK; chain++) { + struct neighbour *n; + + for (n = tbl->hash_buckets[chain]; n; n = n->next) + cb(n, cookie); + } + read_unlock_bh(&tbl->lock); +} +EXPORT_SYMBOL(neigh_for_each); + +/* The tbl->lock must be held as a writer and BH disabled. */ +void __neigh_for_each_release(struct neigh_table *tbl, + int (*cb)(struct neighbour *)) +{ + int chain; + + for (chain = 0; chain <= NEIGH_HASHMASK; chain++) { + struct neighbour *n, **np; + + np = &tbl->hash_buckets[chain]; + while ((n = *np) != NULL) { + int release; + + write_lock(&n->lock); + release = cb(n); + if (release) { + *np = n->next; + n->dead = 1; + } else + np = &n->next; + write_unlock(&n->lock); + if (release) + neigh_release(n); + } + } +} +EXPORT_SYMBOL(__neigh_for_each_release); + +#ifdef CONFIG_PROC_FS + +static struct neighbour *neigh_get_first(struct seq_file *seq) +{ + struct neigh_seq_state *state = seq->private; + struct neigh_table *tbl = state->tbl; + struct neighbour *n = NULL; + int bucket = state->bucket; + + state->flags &= ~NEIGH_SEQ_IS_PNEIGH; + for (bucket = 0; bucket <= NEIGH_HASHMASK; bucket++) { + n = tbl->hash_buckets[bucket]; + + while (n) { + if (state->neigh_sub_iter) { + loff_t fakep = 0; + void *v; + + v = state->neigh_sub_iter(state, n, &fakep); + if (!v) + goto next; + } + if (!(state->flags & NEIGH_SEQ_SKIP_NOARP)) + break; + if (n->nud_state & ~NUD_NOARP) + break; + next: + n = n->next; + } + + if (n) + break; + } + state->bucket = bucket; + + return n; +} + +static struct neighbour *neigh_get_next(struct seq_file *seq, + struct neighbour *n, + loff_t *pos) +{ + struct neigh_seq_state *state = seq->private; + struct neigh_table *tbl = state->tbl; + + if (state->neigh_sub_iter) { + void *v = state->neigh_sub_iter(state, n, pos); + if (v) + return n; + } + n = n->next; + + while (1) { + while (n) { + if (state->neigh_sub_iter) { + void *v = state->neigh_sub_iter(state, n, pos); + if (v) + return n; + goto next; + } + if (!(state->flags & NEIGH_SEQ_SKIP_NOARP)) + break; + + if (n->nud_state & ~NUD_NOARP) + break; + next: + n = n->next; + } + + if (n) + break; + + if (++state->bucket > NEIGH_HASHMASK) + break; + + n = tbl->hash_buckets[state->bucket]; + } + + if (n && pos) + --(*pos); + return n; +} + +static struct neighbour *neigh_get_idx(struct seq_file *seq, loff_t *pos) +{ + struct neighbour *n = neigh_get_first(seq); + + if (n) { + while (*pos) { + n = neigh_get_next(seq, n, pos); + if (!n) + break; + } + } + return *pos ? NULL : n; +} + +static struct pneigh_entry *pneigh_get_first(struct seq_file *seq) +{ + struct neigh_seq_state *state = seq->private; + struct neigh_table *tbl = state->tbl; + struct pneigh_entry *pn = NULL; + int bucket = state->bucket; + + state->flags |= NEIGH_SEQ_IS_PNEIGH; + for (bucket = 0; bucket <= PNEIGH_HASHMASK; bucket++) { + pn = tbl->phash_buckets[bucket]; + if (pn) + break; + } + state->bucket = bucket; + + return pn; +} + +static struct pneigh_entry *pneigh_get_next(struct seq_file *seq, + struct pneigh_entry *pn, + loff_t *pos) +{ + struct neigh_seq_state *state = seq->private; + struct neigh_table *tbl = state->tbl; + + pn = pn->next; + while (!pn) { + if (++state->bucket > PNEIGH_HASHMASK) + break; + pn = tbl->phash_buckets[state->bucket]; + if (pn) + break; + } + + if (pn && pos) + --(*pos); + + return pn; +} + +static struct pneigh_entry *pneigh_get_idx(struct seq_file *seq, loff_t *pos) +{ + struct pneigh_entry *pn = pneigh_get_first(seq); + + if (pn) { + while (*pos) { + pn = pneigh_get_next(seq, pn, pos); + if (!pn) + break; + } + } + return *pos ? NULL : pn; +} + +static void *neigh_get_idx_any(struct seq_file *seq, loff_t *pos) +{ + struct neigh_seq_state *state = seq->private; + void *rc; + + rc = neigh_get_idx(seq, pos); + if (!rc && !(state->flags & NEIGH_SEQ_NEIGH_ONLY)) + rc = pneigh_get_idx(seq, pos); + + return rc; +} + +void *neigh_seq_start(struct seq_file *seq, loff_t *pos, struct neigh_table *tbl, unsigned int neigh_seq_flags) +{ + struct neigh_seq_state *state = seq->private; + loff_t pos_minus_one; + + state->tbl = tbl; + state->bucket = 0; + state->flags = (neigh_seq_flags & ~NEIGH_SEQ_IS_PNEIGH); + + read_lock_bh(&tbl->lock); + + pos_minus_one = *pos - 1; + return *pos ? neigh_get_idx_any(seq, &pos_minus_one) : SEQ_START_TOKEN; +} +EXPORT_SYMBOL(neigh_seq_start); + +void *neigh_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct neigh_seq_state *state; + void *rc; + + if (v == SEQ_START_TOKEN) { + rc = neigh_get_idx(seq, pos); + goto out; + } + + state = seq->private; + if (!(state->flags & NEIGH_SEQ_IS_PNEIGH)) { + rc = neigh_get_next(seq, v, NULL); + if (rc) + goto out; + if (!(state->flags & NEIGH_SEQ_NEIGH_ONLY)) + rc = pneigh_get_first(seq); + } else { + BUG_ON(state->flags & NEIGH_SEQ_NEIGH_ONLY); + rc = pneigh_get_next(seq, v, NULL); + } +out: + ++(*pos); + return rc; +} +EXPORT_SYMBOL(neigh_seq_next); + +void neigh_seq_stop(struct seq_file *seq, void *v) +{ + struct neigh_seq_state *state = seq->private; + struct neigh_table *tbl = state->tbl; + + read_unlock_bh(&tbl->lock); +} +EXPORT_SYMBOL(neigh_seq_stop); + +#endif /* CONFIG_PROC_FS */ + #ifdef CONFIG_ARPD void neigh_app_ns(struct neighbour *n) { diff -Nru a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c --- a/net/decnet/dn_neigh.c 2004-09-23 22:25:53 -07:00 +++ b/net/decnet/dn_neigh.c 2004-09-23 22:25:53 -07:00 @@ -514,141 +514,66 @@ return (*min < priority) ? (min - 6) : NULL; } -int dn_neigh_elist(struct net_device *dev, unsigned char *ptr, int n) -{ - int t = 0; - int i; - struct neighbour *neigh; - struct dn_neigh *dn; - struct neigh_table *tbl = &dn_neigh_table; - unsigned char *rs = ptr; - struct dn_dev *dn_db = (struct dn_dev *)dev->dn_ptr; - - read_lock_bh(&tbl->lock); - - for(i = 0; i < NEIGH_HASHMASK; i++) { - for(neigh = tbl->hash_buckets[i]; neigh != NULL; neigh = neigh->next) { - if (neigh->dev != dev) - continue; - dn = (struct dn_neigh *)neigh; - if (!(dn->flags & (DN_NDFLAG_R1|DN_NDFLAG_R2))) - continue; - if (dn_db->parms.forwarding == 1 && (dn->flags & DN_NDFLAG_R2)) - continue; - if (t == n) - rs = dn_find_slot(ptr, n, dn->priority); - else - t++; - if (rs == NULL) - continue; - dn_dn2eth(rs, dn->addr); - rs += 6; - *rs = neigh->nud_state & NUD_CONNECTED ? 0x80 : 0x0; - *rs |= dn->priority; - rs++; - } - } - - read_unlock_bh(&tbl->lock); - - return t; -} - - -#ifdef CONFIG_PROC_FS - -struct dn_neigh_iter_state { - int bucket; +struct elist_cb_state { + struct net_device *dev; + unsigned char *ptr; + unsigned char *rs; + int t, n; }; -static struct neighbour *neigh_get_first(struct seq_file *seq) +static void neigh_elist_cb(struct neighbour *neigh, void *_info) { - struct dn_neigh_iter_state *state = seq->private; - struct neighbour *n = NULL; - - for(state->bucket = 0; - state->bucket <= NEIGH_HASHMASK; - ++state->bucket) { - n = dn_neigh_table.hash_buckets[state->bucket]; - if (n) - break; - } - - return n; -} + struct elist_cb_state *s = _info; + struct dn_dev *dn_db; + struct dn_neigh *dn; -static struct neighbour *neigh_get_next(struct seq_file *seq, - struct neighbour *n) -{ - struct dn_neigh_iter_state *state = seq->private; + if (neigh->dev != s->dev) + return; - n = n->next; -try_again: - if (n) - goto out; - if (++state->bucket > NEIGH_HASHMASK) - goto out; - n = dn_neigh_table.hash_buckets[state->bucket]; - goto try_again; -out: - return n; + dn = (struct dn_neigh *) neigh; + if (!(dn->flags & (DN_NDFLAG_R1|DN_NDFLAG_R2))) + return; + + dn_db = (struct dn_dev *) s->dev->dn_ptr; + if (dn_db->parms.forwarding == 1 && (dn->flags & DN_NDFLAG_R2)) + return; + + if (s->t == s->n) + s->rs = dn_find_slot(s->ptr, s->n, dn->priority); + else + s->t++; + if (s->rs == NULL) + return; + + dn_dn2eth(s->rs, dn->addr); + s->rs += 6; + *(s->rs) = neigh->nud_state & NUD_CONNECTED ? 0x80 : 0x0; + *(s->rs) |= dn->priority; + s->rs++; } -static struct neighbour *neigh_get_idx(struct seq_file *seq, loff_t *pos) +int dn_neigh_elist(struct net_device *dev, unsigned char *ptr, int n) { - struct neighbour *n = neigh_get_first(seq); + struct elist_cb_state state; - if (n) - while(*pos && (n = neigh_get_next(seq, n))) - --*pos; - return *pos ? NULL : n; -} + state.dev = dev; + state.t = 0; + state.n = n; + state.ptr = ptr; + state.rs = ptr; -static void *dn_neigh_get_idx(struct seq_file *seq, loff_t pos) -{ - void *rc; - read_lock_bh(&dn_neigh_table.lock); - rc = neigh_get_idx(seq, &pos); - if (!rc) { - read_unlock_bh(&dn_neigh_table.lock); - } - return rc; -} + neigh_for_each(&dn_neigh_table, neigh_elist_cb, &state); -static void *dn_neigh_seq_start(struct seq_file *seq, loff_t *pos) -{ - return *pos ? dn_neigh_get_idx(seq, *pos - 1) : SEQ_START_TOKEN; + return state.t; } -static void *dn_neigh_seq_next(struct seq_file *seq, void *v, loff_t *pos) -{ - void *rc; - - - if (v == SEQ_START_TOKEN) { - rc = dn_neigh_get_idx(seq, 0); - goto out; - } - rc = neigh_get_next(seq, v); - if (rc) - goto out; - read_unlock_bh(&dn_neigh_table.lock); -out: - ++*pos; - return rc; -} - -static void dn_neigh_seq_stop(struct seq_file *seq, void *v) -{ - if (v && v != SEQ_START_TOKEN) - read_unlock_bh(&dn_neigh_table.lock); -} +#ifdef CONFIG_PROC_FS static inline void dn_neigh_format_entry(struct seq_file *seq, struct neighbour *n) { - struct dn_neigh *dn = (struct dn_neigh *)n; + struct dn_neigh *dn = (struct dn_neigh *) n; char buf[DN_ASCBUF_LEN]; read_lock(&n->lock); @@ -675,10 +600,16 @@ return 0; } +static void *dn_neigh_seq_start(struct seq_file *seq, loff_t *pos) +{ + return neigh_seq_start(seq, pos, &dn_neigh_table, + NEIGH_SEQ_NEIGH_ONLY); +} + static struct seq_operations dn_neigh_seq_ops = { .start = dn_neigh_seq_start, - .next = dn_neigh_seq_next, - .stop = dn_neigh_seq_stop, + .next = neigh_seq_next, + .stop = neigh_seq_stop, .show = dn_neigh_seq_show, }; @@ -686,11 +617,12 @@ { struct seq_file *seq; int rc = -ENOMEM; - struct dn_neigh_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL); + struct neigh_seq_state *s = kmalloc(sizeof(*s), GFP_KERNEL); if (!s) goto out; + memset(s, 0, sizeof(*s)); rc = seq_open(file, &dn_neigh_seq_ops); if (rc) goto out_kfree; diff -Nru a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c 2004-09-23 22:25:53 -07:00 +++ b/net/ipv4/arp.c 2004-09-23 22:25:53 -07:00 @@ -1269,162 +1269,10 @@ } #endif /* CONFIG_AX25 */ -struct arp_iter_state { - int is_pneigh, bucket; -}; - -static struct neighbour *neigh_get_first(struct seq_file *seq) -{ - struct arp_iter_state* state = seq->private; - struct neighbour *n = NULL; - - state->is_pneigh = 0; - - for (state->bucket = 0; - state->bucket <= NEIGH_HASHMASK; - ++state->bucket) { - n = arp_tbl.hash_buckets[state->bucket]; - while (n && !(n->nud_state & ~NUD_NOARP)) - n = n->next; - if (n) - break; - } - - return n; -} - -static struct neighbour *neigh_get_next(struct seq_file *seq, - struct neighbour *n) -{ - struct arp_iter_state* state = seq->private; - - do { - n = n->next; - /* Don't confuse "arp -a" w/ magic entries */ -try_again: - ; - } while (n && !(n->nud_state & ~NUD_NOARP)); - - if (n) - goto out; - if (++state->bucket > NEIGH_HASHMASK) - goto out; - n = arp_tbl.hash_buckets[state->bucket]; - goto try_again; -out: - return n; -} - -static struct neighbour *neigh_get_idx(struct seq_file *seq, loff_t *pos) -{ - struct neighbour *n = neigh_get_first(seq); - - if (n) - while (*pos && (n = neigh_get_next(seq, n))) - --*pos; - return *pos ? NULL : n; -} - -static struct pneigh_entry *pneigh_get_first(struct seq_file *seq) -{ - struct arp_iter_state* state = seq->private; - struct pneigh_entry *pn; - - state->is_pneigh = 1; - - for (state->bucket = 0; - state->bucket <= PNEIGH_HASHMASK; - ++state->bucket) { - pn = arp_tbl.phash_buckets[state->bucket]; - if (pn) - break; - } - return pn; -} - -static struct pneigh_entry *pneigh_get_next(struct seq_file *seq, - struct pneigh_entry *pn) -{ - struct arp_iter_state* state = seq->private; - - pn = pn->next; - while (!pn) { - if (++state->bucket > PNEIGH_HASHMASK) - break; - pn = arp_tbl.phash_buckets[state->bucket]; - } - return pn; -} - -static struct pneigh_entry *pneigh_get_idx(struct seq_file *seq, loff_t pos) -{ - struct pneigh_entry *pn = pneigh_get_first(seq); - - if (pn) - while (pos && (pn = pneigh_get_next(seq, pn))) - --pos; - return pos ? NULL : pn; -} - -static void *arp_get_idx(struct seq_file *seq, loff_t pos) -{ - void *rc; - - read_lock_bh(&arp_tbl.lock); - rc = neigh_get_idx(seq, &pos); - - if (!rc) { - read_unlock_bh(&arp_tbl.lock); - rc = pneigh_get_idx(seq, pos); - } - return rc; -} - -static void *arp_seq_start(struct seq_file *seq, loff_t *pos) -{ - struct arp_iter_state* state = seq->private; - - state->is_pneigh = 0; - state->bucket = 0; - return *pos ? arp_get_idx(seq, *pos - 1) : SEQ_START_TOKEN; -} - -static void *arp_seq_next(struct seq_file *seq, void *v, loff_t *pos) -{ - void *rc; - struct arp_iter_state* state; - - if (v == SEQ_START_TOKEN) { - rc = arp_get_idx(seq, 0); - goto out; - } - - state = seq->private; - if (!state->is_pneigh) { - rc = neigh_get_next(seq, v); - if (rc) - goto out; - read_unlock_bh(&arp_tbl.lock); - rc = pneigh_get_first(seq); - } else - rc = pneigh_get_next(seq, v); -out: - ++*pos; - return rc; -} - -static void arp_seq_stop(struct seq_file *seq, void *v) -{ - struct arp_iter_state* state = seq->private; - - if (!state->is_pneigh && v != SEQ_START_TOKEN) - read_unlock_bh(&arp_tbl.lock); -} - #define HBUFFERLEN 30 -static __inline__ void arp_format_neigh_entry(struct seq_file *seq, - struct neighbour *n) +static void arp_format_neigh_entry(struct seq_file *seq, + struct neighbour *n) { char hbuffer[HBUFFERLEN]; const char hexbuf[] = "0123456789ABCDEF"; @@ -1455,8 +1303,8 @@ read_unlock(&n->lock); } -static __inline__ void arp_format_pneigh_entry(struct seq_file *seq, - struct pneigh_entry *n) +static void arp_format_pneigh_entry(struct seq_file *seq, + struct pneigh_entry *n) { struct net_device *dev = n->dev; int hatype = dev ? dev->type : 0; @@ -1470,13 +1318,13 @@ static int arp_seq_show(struct seq_file *seq, void *v) { - if (v == SEQ_START_TOKEN) + if (v == SEQ_START_TOKEN) { seq_puts(seq, "IP address HW type Flags " "HW address Mask Device\n"); - else { - struct arp_iter_state* state = seq->private; + } else { + struct neigh_seq_state *state = seq->private; - if (state->is_pneigh) + if (state->flags & NEIGH_SEQ_IS_PNEIGH) arp_format_pneigh_entry(seq, v); else arp_format_neigh_entry(seq, v); @@ -1485,12 +1333,20 @@ return 0; } +static void *arp_seq_start(struct seq_file *seq, loff_t *pos) +{ + /* Don't want to confuse "arp -a" w/ magic entries, + * so we tell the generic iterator to skip NUD_NOARP. + */ + return neigh_seq_start(seq, pos, &arp_tbl, NEIGH_SEQ_SKIP_NOARP); +} + /* ------------------------------------------------------------------------ */ static struct seq_operations arp_seq_ops = { .start = arp_seq_start, - .next = arp_seq_next, - .stop = arp_seq_stop, + .next = neigh_seq_next, + .stop = neigh_seq_stop, .show = arp_seq_show, }; @@ -1498,11 +1354,12 @@ { struct seq_file *seq; int rc = -ENOMEM; - struct arp_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL); + struct neigh_seq_state *s = kmalloc(sizeof(*s), GFP_KERNEL); if (!s) goto out; + memset(s, 0, sizeof(*s)); rc = seq_open(file, &arp_seq_ops); if (rc) goto out_kfree; From davem@davemloft.net Thu Sep 23 22:50:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:50:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5ojhB004287 for ; Thu, 23 Sep 2004 22:50:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAixN-0007iA-00; Thu, 23 Sep 2004 22:49:21 -0700 Date: Thu, 23 Sep 2004 22:49:21 -0700 From: "David S. Miller" To: laforge@gnumonks.org Cc: netdev@oss.sgi.com Subject: [2/6]: Move hash masking to call sites Message-Id: <20040923224921.3461f7a8.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4064 Lines: 129 Another step towards moving all hashing details into net/core/neighbour.c # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 15:20:38-07:00 davem@nuts.davemloft.net # [NET]: Apply NEIGH_HASHMASK at tbl->hash() caller. # # Now there is no reason for any neigh implementation # to know the value of {P,}NEIGH_HASHMASK # # Signed-off-by: David S. Miller # # net/ipv6/ndisc.c # 2004/09/23 15:20:09-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Apply NEIGH_HASHMASK at tbl->hash() caller. # # Now there is no reason for any neigh implementation # to know the value of {P,}NEIGH_HASHMASK # # Signed-off-by: David S. Miller # # net/ipv4/arp.c # 2004/09/23 15:20:09-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Apply NEIGH_HASHMASK at tbl->hash() caller. # # Now there is no reason for any neigh implementation # to know the value of {P,}NEIGH_HASHMASK # # Signed-off-by: David S. Miller # # net/decnet/dn_neigh.c # 2004/09/23 15:20:09-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Apply NEIGH_HASHMASK at tbl->hash() caller. # # Now there is no reason for any neigh implementation # to know the value of {P,}NEIGH_HASHMASK # # Signed-off-by: David S. Miller # # net/core/neighbour.c # 2004/09/23 15:20:09-07:00 davem@nuts.davemloft.net +2 -2 # [NET]: Apply NEIGH_HASHMASK at tbl->hash() caller. # # Now there is no reason for any neigh implementation # to know the value of {P,}NEIGH_HASHMASK # # Signed-off-by: David S. Miller # # net/atm/clip.c # 2004/09/23 15:20:09-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Apply NEIGH_HASHMASK at tbl->hash() caller. # # Now there is no reason for any neigh implementation # to know the value of {P,}NEIGH_HASHMASK # # Signed-off-by: David S. Miller # diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c 2004-09-23 22:26:08 -07:00 +++ b/net/atm/clip.c 2004-09-23 22:26:08 -07:00 @@ -334,7 +334,7 @@ hash_val ^= (hash_val>>16); hash_val ^= hash_val>>8; hash_val ^= hash_val>>3; - hash_val = (hash_val^dev->ifindex)&NEIGH_HASHMASK; + hash_val = (hash_val^dev->ifindex); return hash_val; } diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-23 22:26:08 -07:00 +++ b/net/core/neighbour.c 2004-09-23 22:26:08 -07:00 @@ -291,7 +291,7 @@ { struct neighbour *n; int key_len = tbl->key_len; - u32 hash_val = tbl->hash(pkey, dev); + u32 hash_val = tbl->hash(pkey, dev) & NEIGH_HASHMASK; read_lock_bh(&tbl->lock); for (n = tbl->hash_buckets[hash_val]; n; n = n->next) { @@ -336,7 +336,7 @@ n->confirmed = jiffies - (n->parms->base_reachable_time << 1); - hash_val = tbl->hash(pkey, dev); + hash_val = tbl->hash(pkey, dev) & NEIGH_HASHMASK; write_lock_bh(&tbl->lock); if (n->parms->dead) { diff -Nru a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c --- a/net/decnet/dn_neigh.c 2004-09-23 22:26:08 -07:00 +++ b/net/decnet/dn_neigh.c 2004-09-23 22:26:08 -07:00 @@ -128,7 +128,7 @@ hash_val ^= (hash_val >> 10); hash_val ^= (hash_val >> 3); - return hash_val & NEIGH_HASHMASK; + return hash_val; } static int dn_neigh_construct(struct neighbour *neigh) diff -Nru a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c 2004-09-23 22:26:08 -07:00 +++ b/net/ipv4/arp.c 2004-09-23 22:26:08 -07:00 @@ -229,7 +229,7 @@ hash_val ^= (hash_val>>16); hash_val ^= hash_val>>8; hash_val ^= hash_val>>3; - hash_val = (hash_val^dev->ifindex)&NEIGH_HASHMASK; + hash_val = (hash_val^dev->ifindex); return hash_val; } diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-23 22:26:08 -07:00 +++ b/net/ipv6/ndisc.c 2004-09-23 22:26:08 -07:00 @@ -276,7 +276,7 @@ hash_val ^= (hash_val>>16); hash_val ^= hash_val>>8; hash_val ^= hash_val>>3; - hash_val = (hash_val^dev->ifindex)&NEIGH_HASHMASK; + hash_val = (hash_val^dev->ifindex); return hash_val; } From davem@davemloft.net Thu Sep 23 22:51:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:51:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5pP1T004646 for ; Thu, 23 Sep 2004 22:51:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAixx-0007iI-00; Thu, 23 Sep 2004 22:49:57 -0700 Date: Thu, 23 Sep 2004 22:49:57 -0700 From: "David S. Miller" To: laforge@gnumonks.org Cc: netdev@oss.sgi.com Subject: [3/6]: Move neigh hash masks Message-Id: <20040923224957.624361a6.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2671 Lines: 98 This actually moves the mask macros into net/core/neighbour.c # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 16:47:26-07:00 davem@nuts.davemloft.net # [NET]: Privatize {P,}NEIGH_HASHMASK. # # Signed-off-by: David S. Miller # # net/core/neighbour.c # 2004/09/23 16:46:50-07:00 davem@nuts.davemloft.net +23 -0 # [NET]: Privatize {P,}NEIGH_HASHMASK. # # include/net/neighbour.h # 2004/09/23 16:46:50-07:00 davem@nuts.davemloft.net +2 -5 # [NET]: Privatize {P,}NEIGH_HASHMASK. # diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-23 22:26:24 -07:00 +++ b/include/net/neighbour.h 2004-09-23 22:26:24 -07:00 @@ -140,9 +140,6 @@ u8 key[0]; }; -#define NEIGH_HASHMASK 0x1F -#define PNEIGH_HASHMASK 0xF - /* * neighbour table manipulation */ @@ -176,8 +173,8 @@ struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; struct neigh_statistics stats; - struct neighbour *hash_buckets[NEIGH_HASHMASK+1]; - struct pneigh_entry *phash_buckets[PNEIGH_HASHMASK+1]; + struct neighbour **hash_buckets; + struct pneigh_entry **phash_buckets; }; /* flags for neigh_update() */ diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-23 22:26:24 -07:00 +++ b/net/core/neighbour.c 2004-09-23 22:26:24 -07:00 @@ -47,6 +47,9 @@ #define NEIGH_PRINTK2 NEIGH_PRINTK #endif +#define NEIGH_HASHMASK 0x1F +#define PNEIGH_HASHMASK 0xF + static void neigh_timer_handler(unsigned long arg); #ifdef CONFIG_ARPD static void neigh_app_notify(struct neighbour *n); @@ -1205,6 +1208,7 @@ void neigh_table_init(struct neigh_table *tbl) { unsigned long now = jiffies; + unsigned long hsize, phsize; atomic_set(&tbl->parms.refcnt, 1); INIT_RCU_HEAD(&tbl->parms.rcu_head); @@ -1220,6 +1224,18 @@ if (!tbl->kmem_cachep) panic("cannot create neighbour cache"); + hsize = (NEIGH_HASHMASK + 1) * sizeof(struct neighbour *); + tbl->hash_buckets = kmalloc(hsize, GFP_KERNEL); + + phsize = (PNEIGH_HASHMASK + 1) * sizeof(struct pneigh_entry *); + tbl->phash_buckets = kmalloc(phsize, GFP_KERNEL); + + if (!tbl->hash_buckets || !tbl->phash_buckets) + panic("cannot allocate neighbour cache hashes"); + + memset(tbl->hash_buckets, 0, hsize); + memset(tbl->phash_buckets, 0, phsize); + tbl->lock = RW_LOCK_UNLOCKED; init_timer(&tbl->gc_timer); tbl->gc_timer.data = (unsigned long)tbl; @@ -1260,6 +1276,13 @@ } } write_unlock(&neigh_tbl_lock); + + kfree(tbl->hash_buckets); + tbl->hash_buckets = NULL; + + kfree(tbl->phash_buckets); + tbl->phash_buckets = NULL; + return 0; } From davem@davemloft.net Thu Sep 23 22:52:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:52:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5q5Hh004944 for ; Thu, 23 Sep 2004 22:52:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAiyg-0007iQ-00; Thu, 23 Sep 2004 22:50:42 -0700 Date: Thu, 23 Sep 2004 22:50:41 -0700 From: "David S. Miller" To: laforge@gnumonks.org Cc: netdev@oss.sgi.com Subject: [4/6]: Add nodev neigh lookup for decnet Message-Id: <20040923225041.4a388eb0.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4428 Lines: 133 It was the one and only tbl->hash() call site outside of net/core/neighbour.c # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 16:52:29-07:00 davem@nuts.davemloft.net # [NET]: Create neigh_lookup_nodev for decnet. # # Signed-off-by: David S. Miller # # net/decnet/dn_route.c # 2004/09/23 16:51:55-07:00 davem@nuts.davemloft.net +1 -1 # [NET]: Create neigh_lookup_nodev for decnet. # # net/decnet/dn_neigh.c # 2004/09/23 16:51:55-07:00 davem@nuts.davemloft.net +0 -21 # [NET]: Create neigh_lookup_nodev for decnet. # # net/core/neighbour.c # 2004/09/23 16:51:55-07:00 davem@nuts.davemloft.net +18 -0 # [NET]: Create neigh_lookup_nodev for decnet. # # include/net/neighbour.h # 2004/09/23 16:51:55-07:00 davem@nuts.davemloft.net +2 -0 # [NET]: Create neigh_lookup_nodev for decnet. # # include/net/dn_neigh.h # 2004/09/23 16:51:55-07:00 davem@nuts.davemloft.net +0 -1 # [NET]: Create neigh_lookup_nodev for decnet. # diff -Nru a/include/net/dn_neigh.h b/include/net/dn_neigh.h --- a/include/net/dn_neigh.h 2004-09-23 22:26:40 -07:00 +++ b/include/net/dn_neigh.h 2004-09-23 22:26:40 -07:00 @@ -18,7 +18,6 @@ extern void dn_neigh_init(void); extern void dn_neigh_cleanup(void); -extern struct neighbour *dn_neigh_lookup(struct neigh_table *tbl, const void *ptr); extern int dn_neigh_router_hello(struct sk_buff *skb); extern int dn_neigh_endnode_hello(struct sk_buff *skb); extern void dn_neigh_pointopoint_hello(struct sk_buff *skb); diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-23 22:26:40 -07:00 +++ b/include/net/neighbour.h 2004-09-23 22:26:40 -07:00 @@ -189,6 +189,8 @@ extern struct neighbour * neigh_lookup(struct neigh_table *tbl, const void *pkey, struct net_device *dev); +extern struct neighbour * neigh_lookup_nodev(struct neigh_table *tbl, + const void *pkey); extern struct neighbour * neigh_create(struct neigh_table *tbl, const void *pkey, struct net_device *dev); diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-23 22:26:40 -07:00 +++ b/net/core/neighbour.c 2004-09-23 22:26:40 -07:00 @@ -307,6 +307,23 @@ return n; } +struct neighbour *neigh_lookup_nodev(struct neigh_table *tbl, const void *pkey) +{ + struct neighbour *n; + int key_len = tbl->key_len; + u32 hash_val = tbl->hash(pkey, NULL) & NEIGH_HASHMASK; + + read_lock_bh(&tbl->lock); + for (n = tbl->hash_buckets[hash_val]; n; n = n->next) { + if (!memcmp(n->primary_key, pkey, key_len)) { + neigh_hold(n); + break; + } + } + read_unlock_bh(&tbl->lock); + return n; +} + struct neighbour *neigh_create(struct neigh_table *tbl, const void *pkey, struct net_device *dev) { @@ -2068,6 +2085,7 @@ EXPORT_SYMBOL(neigh_event_ns); EXPORT_SYMBOL(neigh_ifdown); EXPORT_SYMBOL(neigh_lookup); +EXPORT_SYMBOL(neigh_lookup_nodev); EXPORT_SYMBOL(neigh_parms_alloc); EXPORT_SYMBOL(neigh_parms_release); EXPORT_SYMBOL(neigh_rand_reach_time); diff -Nru a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c --- a/net/decnet/dn_neigh.c 2004-09-23 22:26:40 -07:00 +++ b/net/decnet/dn_neigh.c 2004-09-23 22:26:40 -07:00 @@ -359,27 +359,6 @@ * basically does a neigh_lookup(), but without comparing the device * field. This is required for the On-Ethernet cache */ -struct neighbour *dn_neigh_lookup(struct neigh_table *tbl, const void *ptr) -{ - struct neighbour *neigh; - u32 hash_val; - - hash_val = tbl->hash(ptr, NULL); - - read_lock_bh(&tbl->lock); - for(neigh = tbl->hash_buckets[hash_val]; neigh != NULL; neigh = neigh->next) { - if (memcmp(neigh->primary_key, ptr, tbl->key_len) == 0) { - atomic_inc(&neigh->refcnt); - read_unlock_bh(&tbl->lock); - return neigh; - } - } - read_unlock_bh(&tbl->lock); - - return NULL; -} - - /* * Any traffic on a pointopoint link causes the timer to be reset * for the entry in the neighbour table. diff -Nru a/net/decnet/dn_route.c b/net/decnet/dn_route.c --- a/net/decnet/dn_route.c 2004-09-23 22:26:40 -07:00 +++ b/net/decnet/dn_route.c 2004-09-23 22:26:40 -07:00 @@ -996,7 +996,7 @@ * here */ if (!try_hard) { - neigh = dn_neigh_lookup(&dn_neigh_table, &fl.fld_dst); + neigh = neigh_lookup_nodev(&dn_neigh_table, &fl.fld_dst); if (neigh) { if ((oldflp->oif && (neigh->dev->ifindex != oldflp->oif)) || From davem@davemloft.net Thu Sep 23 22:52:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:52:59 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5qsHD005356 for ; Thu, 23 Sep 2004 22:52:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAizP-0007ib-00; Thu, 23 Sep 2004 22:51:27 -0700 Date: Thu, 23 Sep 2004 22:51:27 -0700 From: "David S. Miller" To: laforge@gnumonks.org Cc: netdev@oss.sgi.com Subject: [5/6]: Dynamic neigh hash table growth Message-Id: <20040923225127.10b0ef68.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 7069 Lines: 266 This implements dynamic growth of neigh tbl->hash_buckets[] which is extremely simple now that all the accesses sit in one file. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 17:31:14-07:00 davem@nuts.davemloft.net # [NET]: Grow neigh hash table dynamically. # # Signed-off-by: David S. Miller # # net/core/neighbour.c # 2004/09/23 17:30:42-07:00 davem@nuts.davemloft.net +82 -18 # [NET]: Grow neigh hash table dynamically. # # include/net/neighbour.h # 2004/09/23 17:30:42-07:00 davem@nuts.davemloft.net +1 -0 # [NET]: Grow neigh hash table dynamically. # diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-23 22:26:58 -07:00 +++ b/include/net/neighbour.h 2004-09-23 22:26:58 -07:00 @@ -174,6 +174,7 @@ kmem_cache_t *kmem_cachep; struct neigh_statistics stats; struct neighbour **hash_buckets; + unsigned int hash_mask; struct pneigh_entry **phash_buckets; }; diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-23 22:26:58 -07:00 +++ b/net/core/neighbour.c 2004-09-23 22:26:58 -07:00 @@ -47,7 +47,6 @@ #define NEIGH_PRINTK2 NEIGH_PRINTK #endif -#define NEIGH_HASHMASK 0x1F #define PNEIGH_HASHMASK 0xF static void neigh_timer_handler(unsigned long arg); @@ -116,7 +115,7 @@ int shrunk = 0; int i; - for (i = 0; i <= NEIGH_HASHMASK; i++) { + for (i = 0; i <= tbl->hash_mask; i++) { struct neighbour *n, **np; np = &tbl->hash_buckets[i]; @@ -180,7 +179,7 @@ write_lock_bh(&tbl->lock); - for (i=0; i <= NEIGH_HASHMASK; i++) { + for (i=0; i <= tbl->hash_mask; i++) { struct neighbour *n, **np; np = &tbl->hash_buckets[i]; @@ -207,7 +206,7 @@ write_lock_bh(&tbl->lock); - for (i = 0; i <= NEIGH_HASHMASK; i++) { + for (i = 0; i <= tbl->hash_mask; i++) { struct neighbour *n, **np = &tbl->hash_buckets[i]; while ((n = *np) != NULL) { @@ -289,12 +288,75 @@ return n; } +static struct neighbour **neigh_hash_alloc(unsigned int entries) +{ + unsigned long size = entries * sizeof(struct neighbour *); + struct neighbour **ret; + + if (size <= PAGE_SIZE) { + ret = kmalloc(size, GFP_KERNEL); + } else { + ret = (struct neighbour **) + __get_free_pages(GFP_KERNEL, get_order(size)); + } + if (ret) + memset(ret, 0, size); + + return ret; +} + +static void neigh_hash_free(struct neighbour **hash, unsigned int entries) +{ + unsigned long size = entries * sizeof(struct neighbour *); + + if (size <= PAGE_SIZE) + kfree(hash); + else + free_pages((unsigned long)hash, get_order(size)); +} + +static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_entries) +{ + struct neighbour **new_hash, **old_hash; + unsigned int i, new_hash_mask, old_entries; + + BUG_ON(new_entries & (new_entries - 1)); + new_hash = neigh_hash_alloc(new_entries); + if (!new_hash) + return; + + old_entries = tbl->hash_mask + 1; + new_hash_mask = new_entries - 1; + old_hash = tbl->hash_buckets; + + write_lock_bh(&tbl->lock); + for (i = 0; i < old_entries; i++) { + struct neighbour *n, *next; + + next = NULL; + for (n = old_hash[i]; n; n = next) { + unsigned int hash_val = tbl->hash(n->primary_key, n->dev); + + hash_val &= new_hash_mask; + next = n->next; + + n->next = new_hash[hash_val]; + new_hash[hash_val] = n; + } + } + tbl->hash_buckets = new_hash; + tbl->hash_mask = new_hash_mask; + write_unlock_bh(&tbl->lock); + + neigh_hash_free(old_hash, old_entries); +} + struct neighbour *neigh_lookup(struct neigh_table *tbl, const void *pkey, struct net_device *dev) { struct neighbour *n; int key_len = tbl->key_len; - u32 hash_val = tbl->hash(pkey, dev) & NEIGH_HASHMASK; + u32 hash_val = tbl->hash(pkey, dev) & tbl->hash_mask; read_lock_bh(&tbl->lock); for (n = tbl->hash_buckets[hash_val]; n; n = n->next) { @@ -311,7 +373,7 @@ { struct neighbour *n; int key_len = tbl->key_len; - u32 hash_val = tbl->hash(pkey, NULL) & NEIGH_HASHMASK; + u32 hash_val = tbl->hash(pkey, NULL) & tbl->hash_mask; read_lock_bh(&tbl->lock); for (n = tbl->hash_buckets[hash_val]; n; n = n->next) { @@ -337,6 +399,9 @@ goto out; } + if (tbl->entries > (tbl->hash_mask + 1)) + neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); + memcpy(n->primary_key, pkey, key_len); n->dev = dev; dev_hold(dev); @@ -356,7 +421,7 @@ n->confirmed = jiffies - (n->parms->base_reachable_time << 1); - hash_val = tbl->hash(pkey, dev) & NEIGH_HASHMASK; + hash_val = tbl->hash(pkey, dev) & tbl->hash_mask; write_lock_bh(&tbl->lock); if (n->parms->dead) { @@ -583,7 +648,7 @@ neigh_rand_reach_time(p->base_reachable_time); } - for (i = 0; i <= NEIGH_HASHMASK; i++) { + for (i = 0; i <= tbl->hash_mask; i++) { struct neighbour *n, **np; np = &tbl->hash_buckets[i]; @@ -1225,7 +1290,7 @@ void neigh_table_init(struct neigh_table *tbl) { unsigned long now = jiffies; - unsigned long hsize, phsize; + unsigned long phsize; atomic_set(&tbl->parms.refcnt, 1); INIT_RCU_HEAD(&tbl->parms.rcu_head); @@ -1241,8 +1306,8 @@ if (!tbl->kmem_cachep) panic("cannot create neighbour cache"); - hsize = (NEIGH_HASHMASK + 1) * sizeof(struct neighbour *); - tbl->hash_buckets = kmalloc(hsize, GFP_KERNEL); + tbl->hash_mask = 0x1f; + tbl->hash_buckets = neigh_hash_alloc(tbl->hash_mask + 1); phsize = (PNEIGH_HASHMASK + 1) * sizeof(struct pneigh_entry *); tbl->phash_buckets = kmalloc(phsize, GFP_KERNEL); @@ -1250,7 +1315,6 @@ if (!tbl->hash_buckets || !tbl->phash_buckets) panic("cannot allocate neighbour cache hashes"); - memset(tbl->hash_buckets, 0, hsize); memset(tbl->phash_buckets, 0, phsize); tbl->lock = RW_LOCK_UNLOCKED; @@ -1294,7 +1358,7 @@ } write_unlock(&neigh_tbl_lock); - kfree(tbl->hash_buckets); + neigh_hash_free(tbl->hash_buckets, tbl->hash_mask + 1); tbl->hash_buckets = NULL; kfree(tbl->phash_buckets); @@ -1479,7 +1543,7 @@ int rc, h, s_h = cb->args[1]; int idx, s_idx = idx = cb->args[2]; - for (h = 0; h <= NEIGH_HASHMASK; h++) { + for (h = 0; h <= tbl->hash_mask; h++) { if (h < s_h) continue; if (h > s_h) @@ -1534,7 +1598,7 @@ int chain; read_lock_bh(&tbl->lock); - for (chain = 0; chain <= NEIGH_HASHMASK; chain++) { + for (chain = 0; chain <= tbl->hash_mask; chain++) { struct neighbour *n; for (n = tbl->hash_buckets[chain]; n; n = n->next) @@ -1550,7 +1614,7 @@ { int chain; - for (chain = 0; chain <= NEIGH_HASHMASK; chain++) { + for (chain = 0; chain <= tbl->hash_mask; chain++) { struct neighbour *n, **np; np = &tbl->hash_buckets[chain]; @@ -1582,7 +1646,7 @@ int bucket = state->bucket; state->flags &= ~NEIGH_SEQ_IS_PNEIGH; - for (bucket = 0; bucket <= NEIGH_HASHMASK; bucket++) { + for (bucket = 0; bucket <= tbl->hash_mask; bucket++) { n = tbl->hash_buckets[bucket]; while (n) { @@ -1644,7 +1708,7 @@ if (n) break; - if (++state->bucket > NEIGH_HASHMASK) + if (++state->bucket > tbl->hash_mask) break; n = tbl->hash_buckets[state->bucket]; From davem@davemloft.net Thu Sep 23 22:53:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:53:30 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5rO1c005582 for ; Thu, 23 Sep 2004 22:53:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAizu-0007ij-00; Thu, 23 Sep 2004 22:51:58 -0700 Date: Thu, 23 Sep 2004 22:51:58 -0700 From: "David S. Miller" To: laforge@gnumonks.org Cc: netdev@oss.sgi.com Subject: [6/6]: jenkins hash for neigh Message-Id: <20040923225158.23c2d502.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 5510 Lines: 191 This makes all the neigh implementations use jenkins. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/23 18:03:13-07:00 davem@nuts.davemloft.net # [NET]: Convert neigh hashing over to jenkins. # # Based upon work by Harald Welte # # Signed-off-by: David S. Miller # # net/ipv6/ndisc.c # 2004/09/23 18:02:32-07:00 davem@nuts.davemloft.net +7 -7 # [NET]: Convert neigh hashing over to jenkins. # # net/ipv4/arp.c # 2004/09/23 18:02:32-07:00 davem@nuts.davemloft.net +3 -9 # [NET]: Convert neigh hashing over to jenkins. # # net/decnet/dn_neigh.c # 2004/09/23 18:02:32-07:00 davem@nuts.davemloft.net +2 -7 # [NET]: Convert neigh hashing over to jenkins. # # net/core/neighbour.c # 2004/09/23 18:02:32-07:00 davem@nuts.davemloft.net +3 -0 # [NET]: Convert neigh hashing over to jenkins. # # net/atm/clip.c # 2004/09/23 18:02:32-07:00 davem@nuts.davemloft.net +2 -9 # [NET]: Convert neigh hashing over to jenkins. # # include/net/neighbour.h # 2004/09/23 18:02:32-07:00 davem@nuts.davemloft.net +1 -0 # [NET]: Convert neigh hashing over to jenkins. # diff -Nru a/include/net/neighbour.h b/include/net/neighbour.h --- a/include/net/neighbour.h 2004-09-23 22:27:14 -07:00 +++ b/include/net/neighbour.h 2004-09-23 22:27:14 -07:00 @@ -175,6 +175,7 @@ struct neigh_statistics stats; struct neighbour **hash_buckets; unsigned int hash_mask; + __u32 hash_rnd; struct pneigh_entry **phash_buckets; }; diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c 2004-09-23 22:27:14 -07:00 +++ b/net/atm/clip.c 2004-09-23 22:27:14 -07:00 @@ -27,6 +27,7 @@ #include #include #include +#include #include /* for struct rtable and routing */ #include /* icmp_send */ #include /* for HZ */ @@ -328,15 +329,7 @@ static u32 clip_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val = *(u32*)pkey; - hash_val ^= (hash_val>>16); - hash_val ^= hash_val>>8; - hash_val ^= hash_val>>3; - hash_val = (hash_val^dev->ifindex); - - return hash_val; + return jhash_2words(*(u32 *)pkey, dev->ifindex, clip_tbl.hash_rnd); } static struct neigh_table clip_tbl = { diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-23 22:27:14 -07:00 +++ b/net/core/neighbour.c 2004-09-23 22:27:14 -07:00 @@ -29,6 +29,7 @@ #include #include #include +#include #define NEIGH_DEBUG 1 @@ -1316,6 +1317,8 @@ panic("cannot allocate neighbour cache hashes"); memset(tbl->phash_buckets, 0, phsize); + + get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd)); tbl->lock = RW_LOCK_UNLOCKED; init_timer(&tbl->gc_timer); diff -Nru a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c --- a/net/decnet/dn_neigh.c 2004-09-23 22:27:14 -07:00 +++ b/net/decnet/dn_neigh.c 2004-09-23 22:27:14 -07:00 @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include @@ -122,13 +123,7 @@ static u32 dn_neigh_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val = *(dn_address *)pkey; - hash_val ^= (hash_val >> 10); - hash_val ^= (hash_val >> 3); - - return hash_val; + return jhash_2words(*(dn_address *)pkey, 0, dn_neigh_table.hash_rnd); } static int dn_neigh_construct(struct neighbour *neigh) diff -Nru a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c 2004-09-23 22:27:14 -07:00 +++ b/net/ipv4/arp.c 2004-09-23 22:27:14 -07:00 @@ -71,6 +71,7 @@ * arp_xmit so intermediate drivers like * bonding can change the skb before * sending (e.g. insert 8021q tag). + * Harald Welte : convert to make use of jenkins hash */ #include @@ -97,6 +98,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -223,15 +225,7 @@ static u32 arp_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val = *(u32*)pkey; - hash_val ^= (hash_val>>16); - hash_val ^= hash_val>>8; - hash_val ^= hash_val>>3; - hash_val = (hash_val^dev->ifindex); - - return hash_val; + return jhash_2words(*(u32 *)pkey, dev->ifindex, arp_tbl.hash_rnd); } static int arp_constructor(struct neighbour *neigh) diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c 2004-09-23 22:27:14 -07:00 +++ b/net/ipv6/ndisc.c 2004-09-23 22:27:14 -07:00 @@ -66,6 +66,7 @@ #include #include #include +#include #include #include @@ -270,15 +271,14 @@ static u32 ndisc_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; + const u32 *p32 = pkey; + u32 addr_hash, i; - hash_val = *(u32*)(pkey + sizeof(struct in6_addr) - 4); - hash_val ^= (hash_val>>16); - hash_val ^= hash_val>>8; - hash_val ^= hash_val>>3; - hash_val = (hash_val^dev->ifindex); + addr_hash = 0; + for (i = 0; i < (sizeof(struct in6_addr) / sizeof(u32)); i++) + addr_hash ^= *p32++; - return hash_val; + return jhash_2words(addr_hash, dev->ifindex, nd_tbl.hash_rnd); } static int ndisc_constructor(struct neighbour *neigh) From davem@davemloft.net Thu Sep 23 22:54:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 22:54:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O5sjKL006043 for ; Thu, 23 Sep 2004 22:54:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAj1F-0007j6-00; Thu, 23 Sep 2004 22:53:21 -0700 Date: Thu, 23 Sep 2004 22:53:21 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability Message-Id: <20040923225321.7a19117d.davem@davemloft.net> In-Reply-To: <20040922111447.GP3236@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> <20040921203118.734a0a7e.davem@davemloft.net> <20040922111447.GP3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 563 Lines: 15 On Wed, 22 Sep 2004 13:14:47 +0200 Harald Welte wrote: > And I still want to address the "all complete entries flushed due to > lots of bogus incomplete entires" issue somehow. As stated before, I > have seen this on happen on live systems. > > Do you agree that this is an existing problem? I totally agree. Please scan my 6 patches, let's get that all fleshed out, then we can move on to this issue. Feel free to backport my 2.6.x neigh patches so far and send that work to me, I'll happily integrate them into my 2.4.x net tree. From johnpol@2ka.mipt.ru Thu Sep 23 23:09:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 23:09:36 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O69UvT006795 for ; Thu, 23 Sep 2004 23:09:31 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i8O69Eg9016114; Fri, 24 Sep 2004 10:09:14 +0400 Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "Luis R. Rodriguez" Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040924054844.GO30131@ruslug.rutgers.edu> References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> <20040923215447.GD30131@ruslug.rutgers.edu> <1095997232.17587.8.camel@uganda> <20040924054844.GO30131@ruslug.rutgers.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OUKycYtgexc6m67+nI/q" Organization: MIPT Message-Id: <1096006470.17587.37.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 24 Sep 2004 10:14:30 +0400 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on dea.vocord.com X-Virus-Status: Clean X-archive-position: 9419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2852 Lines: 79 --=-OUKycYtgexc6m67+nI/q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-09-24 at 09:48, Luis R. Rodriguez wrote: > On Fri, Sep 24, 2004 at 07:40:32AM +0400, Evgeniy Polyakov wrote: > > On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote: > > > RFC:=20 > > >=20 > > > Can and should we work towards using this as interface for drivers th= at > > > need callbacks from an external (closed source) library/HAL? > >=20 > > As I mentioned to Richard Jonson, it can be considered as > > ioctl. ioctl-ng! > > Unified interface (as ioctl) can be used for any type of modules. > > It is just a bit extended ioctl :) > >=20 > > And _yes_, it can be used to turn on/off binary-only callbacks. > > Remember pwc - closed part can register callback and open part can > > send message, or even closed part can register notification when > > open part registers itself and begin to "trash the kernel". > >=20 > > I understand that it is not right way to include it is into the kernel, > > but I personally do not understand how it is different=20 > > from just extended ioctl. It was designed to be usefull and convenient, > > and it is. > >=20 > > BTW, any binary-only module can _itself_ create netlink socket > > with input callback. And that is all - it will be absolutely > > the same as above. > >=20 > > One may consider connector as yet-another-netlink-helper. > >=20 >=20 > Eh. I'm just wondering if there's any *right* way of using binary > callbacks on a linux driver so that it doesn't *taint* and possibly > *trash it*, as you said. I was wondering if perhaps through the > connector we could somehow protect the kernel of possibly ill-behaved cal= lbacks. >=20 > Comments? Yes, we can. Connector itself has quite enough information about it's registrants. For example if it is somehow not good module( for example without GPL in it's license string) then connector can be extended to call it's callback from thread or in jail. If it is of interest I will think of some plugable mechanism for callback environment( probably provide ->before_callback() and ->after_callback() methods from external policy provider which may check callback data and/or confine callback execution ? ). We also may confine closed modules from being able to use event notification. In this scenario with worned out pwc-closed/open, situation will not differ from what we have now. > Luis --=20 Evgeniy Polyakov Crash is better than data corruption. -- Art Grabowski --=-OUKycYtgexc6m67+nI/q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBU7tGIKTPhE+8wY0RAhTqAJ0bDobit+gdUDKlL7W8zi900INwJACdGfC6 wgjevYUKMLT3Rv2gYXkw7r4= =5XJj -----END PGP SIGNATURE----- --=-OUKycYtgexc6m67+nI/q-- From johnpol@2ka.mipt.ru Thu Sep 23 23:25:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 23:25:09 -0700 (PDT) Received: from vocord.com (dea.vocord.ru [217.67.177.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O6P2Y1007561 for ; Thu, 23 Sep 2004 23:25:03 -0700 Received: from [192.168.0.48] (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.12.11/8.12.11) with ESMTP id i8O6Ole9016880; Fri, 24 Sep 2004 10:24:47 +0400 Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: "Luis R. Rodriguez" Cc: Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <1096006470.17587.37.camel@uganda> References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> <20040923215447.GD30131@ruslug.rutgers.edu> <1095997232.17587.8.camel@uganda> <20040924054844.GO30131@ruslug.rutgers.edu> <1096006470.17587.37.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hD0Sf8hCQxFHO3pSu8w1" Organization: MIPT Message-Id: <1096007404.17587.49.camel@uganda> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 24 Sep 2004 10:30:04 +0400 X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on dea.vocord.com X-Virus-Status: Clean X-archive-position: 9420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 3846 Lines: 99 --=-hD0Sf8hCQxFHO3pSu8w1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-09-24 at 10:14, Evgeniy Polyakov wrote: > On Fri, 2004-09-24 at 09:48, Luis R. Rodriguez wrote: > > On Fri, Sep 24, 2004 at 07:40:32AM +0400, Evgeniy Polyakov wrote: > > > On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote: > > > > RFC:=20 > > > >=20 > > > > Can and should we work towards using this as interface for drivers = that > > > > need callbacks from an external (closed source) library/HAL? > > >=20 > > > As I mentioned to Richard Jonson, it can be considered as > > > ioctl. ioctl-ng! > > > Unified interface (as ioctl) can be used for any type of modules. > > > It is just a bit extended ioctl :) > > >=20 > > > And _yes_, it can be used to turn on/off binary-only callbacks. > > > Remember pwc - closed part can register callback and open part can > > > send message, or even closed part can register notification when > > > open part registers itself and begin to "trash the kernel". > > >=20 > > > I understand that it is not right way to include it is into the kerne= l, > > > but I personally do not understand how it is different=20 > > > from just extended ioctl. It was designed to be usefull and convenien= t, > > > and it is. > > >=20 > > > BTW, any binary-only module can _itself_ create netlink socket > > > with input callback. And that is all - it will be absolutely > > > the same as above. > > >=20 > > > One may consider connector as yet-another-netlink-helper. > > >=20 > >=20 > > Eh. I'm just wondering if there's any *right* way of using binary > > callbacks on a linux driver so that it doesn't *taint* and possibly > > *trash it*, as you said. I was wondering if perhaps through the > > connector we could somehow protect the kernel of possibly ill-behaved c= allbacks. > >=20 > > Comments? >=20 > Yes, we can. > Connector itself has quite enough information about it's registrants. >=20 > For example if it is somehow not good module( for example without GPL in > it's license string) then connector can be extended to call it's > callback from thread or in jail. If it is of interest I will think of > some plugable mechanism for callback environment( probably provide > ->before_callback() and ->after_callback() methods from external policy > provider which may check callback data and/or confine callback execution > ? ). >=20 > We also may confine closed modules from being able to use event > notification. In this scenario with worned out pwc-closed/open, > situation will not differ from what we have now. BTW, it can also restrict userspace event notification in following way: when someone sends a message to notify group A of registering/unregistering of device with id {x,y} then connector can check if this group A is registered through callback_register_gpl(it is not exist for now, but can be created as a copy of callback_register() ) or not. If it is GPL - send notify, else - execute=20 "mail -s "shit happens" linux-kernel@vger.kernel.org"=20 in the way /sbin/hotplug is called. BTW, this decision also can be obtained from external policy module. As you may think connector in current implementation is quite powerful interface( if I will not praise it, who will? :) ), and somebody can make bad things a bit easier with it, but it is also very flexible and can be tuned to suit your needs. I'm open for discussion :) > > Luis --=20 Evgeniy Polyakov Crash is better than data corruption. -- Art Grabowski --=-hD0Sf8hCQxFHO3pSu8w1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBU77rIKTPhE+8wY0RAvVHAJ9xnAMas4iGun5iJVMD0nQbChzA3ACdHeJ2 bFvxAxfjVOSaBO6zO4gy30A= =v0ZB -----END PGP SIGNATURE----- --=-hD0Sf8hCQxFHO3pSu8w1-- From herbert@gondor.apana.org.au Thu Sep 23 23:26:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 23:26:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O6Qe7u007942 for ; Thu, 23 Sep 2004 23:26:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAjX3-00011x-00; Fri, 24 Sep 2004 16:26:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAjWu-0001y3-00; Fri, 24 Sep 2004 16:26:04 +1000 Date: Fri, 24 Sep 2004 16:26:04 +1000 To: "David S. Miller" Cc: pablo@eurodev.net, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040924062604.GA7393@gondor.apana.org.au> References: <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> <20040923223909.6f4da27f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040923223909.6f4da27f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1402 Lines: 41 On Thu, Sep 23, 2004 at 10:39:09PM -0700, David S. Miller wrote: > > It's moreso for the "give me a single entry" requests > than for dumps. NLMSG_GOODSIZE is used for all cases. I see. NLMSG_GOODSIZE is definitely a waste in that case. > Simpler would be: > > 1) For each netlink socket, allocate a page, much like TCP sockets > do. I'd let the responder allocate that page skb as they do now. After all what we lack is space on the receive queue, not kernel memory. So long as that page doesn't end up on the queue, it should be fine. It also means those responders that can calculate the correct size of the reply doesn't need to go through this copy process. > 2) Construct the netlink response in this page sized buffer, > keeping track of how much of the page is actually used. The size is in the NL header so that's easy. > 3) At the end, allocate the skb with the necessary length, > copy into the skb from the page buffer. We can put that into a helper function and then those netlink responders which use GOODSIZE (most of them for now) can call it. Putting it in a helper means that we can have implementations in future that don't need to do this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mcgrof@studorgs.rutgers.edu Thu Sep 23 23:32:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 23:32:49 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O6Wg41008414 for ; Thu, 23 Sep 2004 23:32:42 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 30137F99BD; Fri, 24 Sep 2004 02:32:31 -0400 (EDT) Date: Fri, 24 Sep 2004 02:32:31 -0400 To: Evgeniy Polyakov Cc: "Luis R. Rodriguez" , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". Message-ID: <20040924063231.GP30131@ruslug.rutgers.edu> Mail-Followup-To: Evgeniy Polyakov , "Luis R. Rodriguez" , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> <20040923215447.GD30131@ruslug.rutgers.edu> <1095997232.17587.8.camel@uganda> <20040924054844.GO30131@ruslug.rutgers.edu> <1096006470.17587.37.camel@uganda> <1096007404.17587.49.camel@uganda> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlsYxwg8UDQn+EKZ" Content-Disposition: inline In-Reply-To: <1096007404.17587.49.camel@uganda> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 4270 Lines: 106 --UlsYxwg8UDQn+EKZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 24, 2004 at 10:30:04AM +0400, Evgeniy Polyakov wrote: > On Fri, 2004-09-24 at 10:14, Evgeniy Polyakov wrote: > > On Fri, 2004-09-24 at 09:48, Luis R. Rodriguez wrote: > > > On Fri, Sep 24, 2004 at 07:40:32AM +0400, Evgeniy Polyakov wrote: > > > > On Fri, 2004-09-24 at 01:54, Luis R. Rodriguez wrote: > > > > > RFC:=20 > > > > >=20 > > > > > Can and should we work towards using this as interface for driver= s that > > > > > need callbacks from an external (closed source) library/HAL? > > > >=20 > > > > As I mentioned to Richard Jonson, it can be considered as > > > > ioctl. ioctl-ng! > > > > Unified interface (as ioctl) can be used for any type of modules. > > > > It is just a bit extended ioctl :) > > > >=20 > > > > And _yes_, it can be used to turn on/off binary-only callbacks. > > > > Remember pwc - closed part can register callback and open part can > > > > send message, or even closed part can register notification when > > > > open part registers itself and begin to "trash the kernel". > > > >=20 > > > > I understand that it is not right way to include it is into the ker= nel, > > > > but I personally do not understand how it is different=20 > > > > from just extended ioctl. It was designed to be usefull and conveni= ent, > > > > and it is. > > > >=20 > > > > BTW, any binary-only module can _itself_ create netlink socket > > > > with input callback. And that is all - it will be absolutely > > > > the same as above. > > > >=20 > > > > One may consider connector as yet-another-netlink-helper. > > > >=20 > > >=20 > > > Eh. I'm just wondering if there's any *right* way of using binary > > > callbacks on a linux driver so that it doesn't *taint* and possibly > > > *trash it*, as you said. I was wondering if perhaps through the > > > connector we could somehow protect the kernel of possibly ill-behaved= callbacks. > > >=20 > > > Comments? > >=20 > > Yes, we can. > > Connector itself has quite enough information about it's registrants. > >=20 > > For example if it is somehow not good module( for example without GPL in > > it's license string) then connector can be extended to call it's > > callback from thread or in jail. If it is of interest I will think of > > some plugable mechanism for callback environment( probably provide > > ->before_callback() and ->after_callback() methods from external policy > > provider which may check callback data and/or confine callback execution > > ? ). > >=20 > > We also may confine closed modules from being able to use event > > notification. In this scenario with worned out pwc-closed/open, > > situation will not differ from what we have now. >=20 > BTW, it can also restrict userspace event notification in following way: > when someone sends a message to notify group A of > registering/unregistering of device with id {x,y} then connector can > check if this group A is registered through callback_register_gpl(it is > not exist for now, but can be created as a copy of callback_register() ) > or not. If it is GPL - send notify, else - execute=20 > "mail -s "shit happens" linux-kernel@vger.kernel.org"=20 > in the way /sbin/hotplug is called. > BTW, this decision also can be obtained from external policy module. >=20 > As you may think connector in current implementation is quite powerful > interface( if I will not praise it, who will? :) ), and somebody can > make bad things a bit easier with it, but it is also very flexible and > can be tuned to suit your needs. >=20 > I'm open for discussion :) Kernel maintainers:=20 What do you think? Can a driver which requires access to binary callbacks be included as part of the stock kernel as GPL if Evgeniy's Connector provides some sort of kernel "jail" for the callback functionality?=20 Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --UlsYxwg8UDQn+EKZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBU79/at1JN+IKUl4RAu3VAKCh2zLdHZbNgo5hh+YBcbX6rFWszwCgjbCY dMrIA4Oi87HWkzgA3qGDpXY= =aBD6 -----END PGP SIGNATURE----- --UlsYxwg8UDQn+EKZ-- From mcgrof@studorgs.rutgers.edu Thu Sep 23 23:52:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 23 Sep 2004 23:52:24 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O6qI81009340 for ; Thu, 23 Sep 2004 23:52:19 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 6FC4BF99BD; Fri, 24 Sep 2004 02:52:07 -0400 (EDT) Date: Fri, 24 Sep 2004 02:52:07 -0400 To: Evgeniy Polyakov , "Luis R. Rodriguez" , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [1/1] connector: Kernel connector - userspace <-> kernelspace "linker". Message-ID: <20040924065207.GR30131@ruslug.rutgers.edu> Mail-Followup-To: Evgeniy Polyakov , "Luis R. Rodriguez" , Andrew Morton , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <1095331899.18219.58.camel@uganda> <20040921124623.GA6942@uganda.factory.vocord.ru> <20040924000739.112f07dd@zanzibar.2ka.mipt.ru> <20040923215447.GD30131@ruslug.rutgers.edu> <1095997232.17587.8.camel@uganda> <20040924054844.GO30131@ruslug.rutgers.edu> <1096006470.17587.37.camel@uganda> <1096007404.17587.49.camel@uganda> <20040924063231.GP30131@ruslug.rutgers.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vTfKKTivj/mQoluA" Content-Disposition: inline In-Reply-To: <20040924063231.GP30131@ruslug.rutgers.edu> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1924 Lines: 57 --vTfKKTivj/mQoluA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 24, 2004 at 02:32:31AM -0400, Luis R. Rodriguez wrote: > On Fri, Sep 24, 2004 at 10:30:04AM +0400, Evgeniy Polyakov wrote: > >=20 > > BTW, it can also restrict userspace event notification in following way: > > when someone sends a message to notify group A of > > registering/unregistering of device with id {x,y} then connector can > > check if this group A is registered through callback_register_gpl(it is > > not exist for now, but can be created as a copy of callback_register() ) > > or not. If it is GPL - send notify, else - execute=20 > > "mail -s "shit happens" linux-kernel@vger.kernel.org"=20 > > in the way /sbin/hotplug is called. > > BTW, this decision also can be obtained from external policy module. > >=20 > > As you may think connector in current implementation is quite powerful > > interface( if I will not praise it, who will? :) ), and somebody can > > make bad things a bit easier with it, but it is also very flexible and > > can be tuned to suit your needs. > >=20 > > I'm open for discussion :) >=20 > Kernel maintainers:=20 >=20 > What do you think? Can a driver which requires access to binary > callbacks be included as part of the stock kernel as GPL if Evgeniy's > Connector provides some sort of kernel "jail" for the callback > functionality?=20 >=20 > Luis >=20 BTW just wanted to say I realize all this is rediculous, I'm just testing waters ;) Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --vTfKKTivj/mQoluA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBU8QXat1JN+IKUl4RAiDnAJwPFH9r2jWf+Tf2E4DUVa4cA8EqIwCeOR1Q 79499n7yUrERNbzNeVnKScI= =oqnr -----END PGP SIGNATURE----- --vTfKKTivj/mQoluA-- From glen.turner@aarnet.edu.au Fri Sep 24 00:18:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 00:18:33 -0700 (PDT) Received: from clix.aarnet.edu.au (clix.aarnet.edu.au [192.94.63.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O7IBTN010356 for ; Fri, 24 Sep 2004 00:18:11 -0700 Received: from [202.158.193.5] (andromache.adelaide.aarnet.edu.au [202.158.193.5]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id i8O7HlCS022721 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 24 Sep 2004 17:17:50 +1000 Subject: Re: [PATCH + RFC] neighbour/ARP cache scalability From: Glen Turner To: Harald Welte Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040922111447.GP3236@sunbeam.de.gnumonks.org> References: <20040920225140.GH1307@sunbeam.de.gnumonks.org> <20040921203118.734a0a7e.davem@davemloft.net> <20040922111447.GP3236@sunbeam.de.gnumonks.org> Content-Type: text/plain Organization: Australian Academic and Research Network Message-Id: <1096010078.4414.91.camel@andromache> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 24 Sep 2004 16:44:38 +0930 Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 9424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glen.turner@aarnet.edu.au Precedence: bulk X-list: netdev Content-Length: 1987 Lines: 51 On Wed, 2004-09-22 at 20:44, Harald Welte wrote: > And I still want to address the "all complete entries flushed due to > lots of bogus incomplete entires" issue somehow. As stated before, I > have seen this on happen on live systems. > > Do you agree that this is an existing problem? > > I think just having a certain 'reserve' for complete entries (or a let's > say 80% limit for incomplete ones) should address this issue. Or two other ideas: 1) Recognising that there are two classes of incomplete entries, those that are recently-issued and those that are very unlikely to complete (as you've allowed enough time for a handful of serialisation delays, latencies and answering host turn-around (say 0.7s). You can pretty safely aggressively flush the "unlikely to complete" class of incomplete entries. The older the more aggressively. Completed entries should be flushed before the first of the "recently issued" incomplete entries, to stop repeated ARPing. This gets less useful as your address allocation grows and scanning rates rise, but is much better than the current algorithm or a straight-forward least-recently-used algorithm. 2) Record the source interface of the traffic which is causing this ARP. When flushing the cache, apply a penalty to entries where that entry's source interfaces has a large numbers of incomplete ARPs. The effect of this is that scanning from an Internet-facing interface won't succeed in pushing large numbers of entries generated from local-to-local (eg, local file, print, intranet) traffic out of the table. A combination of (1) and (2) should be pretty solid. If it falls apart under extreme scanning then hard-coding the ARP info for externally-facing servers (such as web servers) is needed. Currently hard-coding all machines would be needed in the extreme scanning case. Hope this helps, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From margitsw@t-online.de Fri Sep 24 00:44:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 00:44:44 -0700 (PDT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O7iWHm023346 for ; Fri, 24 Sep 2004 00:44:32 -0700 Received: from fwd08.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1CAkkM-00055t-07; Fri, 24 Sep 2004 09:44:02 +0200 Received: from margit.t-online.de (ESOtfmZLZen+I4VQydR5Xo1z8aOuB6GwvqGLR9Tf4NRCd0ciizANgl@[217.224.25.10]) by fwd08.sul.t-online.com with esmtp id 1CAkkI-29dlg00; Fri, 24 Sep 2004 09:43:58 +0200 Message-Id: <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> X-Sender: margitsw@pop.t-online.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Sep 2004 09:43:10 +0200 To: Nishanth Aravamudan From: margitsw@t-online.de (Margit Schubert-While) Subject: Re: [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() Cc: hvr@gnu.org, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, prism54-devel@prism54.org, netdev@oss.sgi.com, jgarzik@pobox.com In-Reply-To: <20040923225507.GI30131@ruslug.rutgers.edu> References: <20040923221303.GB13244@us.ibm.com> <20040923221303.GB13244@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ID: ESOtfmZLZen+I4VQydR5Xo1z8aOuB6GwvqGLR9Tf4NRCd0ciizANgl X-TOI-MSGID: 7c0a0212-9bc0-4e52-92c4-9675599140f4 X-archive-position: 9425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: margitsw@t-online.de Precedence: bulk X-list: netdev Content-Length: 2588 Lines: 72 Hi Nish, At 18:55 23.09.2004 -0400, Luis scribeth: >On Thu, Sep 23, 2004 at 03:13:03PM -0700, Nishanth Aravamudan wrote: > > Any comments would be appreciated. > > > > Description: Use msleep() instead of schedule_timeout() > > to guarantee the task delays as expected. Also set_current_state() is > > inserted before schedule_timeout(). If the for-loop were to execute > > twice, the second time would not set the state before sleeping in the > > current code; this causes schedule_timeout() to return immediately. > > > > Signed-off-by: Nishanth Aravamudan > > > > --- > 2.6.9-rc2-vanilla/drivers/net/wireless/prism54/islpci_dev.c > 2004-09-13 17:15:41.000000000 -0700 > > +++ > 2.6.9-rc2/drivers/net/wireless/prism54/islpci_dev.c 2004-09-23 > 13:58:42.000000000 -0700 > > @@ -436,8 +436,7 @@ prism54_bring_down(islpci_private *priv) > > wmb(); > > > > /* wait a while for the device to reset */ > > - set_current_state(TASK_UNINTERRUPTIBLE); > > - schedule_timeout(50*HZ/1000); > > + msleep(50); > > > > return 0; > > } > > @@ -489,6 +488,7 @@ islpci_reset_if(islpci_private *priv) > > /* The software reset acknowledge needs about 220 msec here. > > * Be conservative and wait for up to one second. */ > > > > + set_current_state(TASK_UNINTERRUPTIBLE); > > remaining = schedule_timeout(HZ); > > > > if(remaining > 0) { > > >Looks good to me. IIRC Margit had something to say about this last time >this popped around -- CC'ing her to see if there are any outstanding >comments. You bet she has. The patch has wrong line numbers. Doesn't take into account the stacked up netdev changes. (Therefore CC'ing Jeff Garzik) This breaks 2.4 compatibility. So either backport to 2.4 or Nish can take over prism54 2.4 maintenance ;-) Don't say a backport is not possible/reasonable, it happened with netdev_priv(). (In 2.4.27; At least there, we have HAVE_NETDEV_PRIV). If this is going to be forced, can we at least have a define HAVE_MSLEEP in delay.h ? I am somewhat confused by the second part of the patch. What has that got to do with msleep ? Actually, the fix would appear to be correct, but that is a seperate issue and nothing to do with msleep. (Prims54 developers -> I'll take a look over the weekend) I am sceptical about the whole msleep patchset as, by their own admission, the janitors have/can not (no hardware) test the majority of the changes. Even more worrying is that incorrect code has directly appeared in mainline kernel BK. Margit From ak@suse.de Fri Sep 24 01:30:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 01:30:38 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O8URFF027508 for ; Fri, 24 Sep 2004 01:30:28 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id A15D5C61DA9; Fri, 24 Sep 2004 10:30:10 +0200 (CEST) Date: Fri, 24 Sep 2004 10:30:07 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040924083007.GB25363@wotan.suse.de> References: <20040921155835.18aee381.davem@davemloft.net> <20040922140000.GD27432@wotan.suse.de> <20040922111209.7887df53.davem@davemloft.net> <20040922195515.GA2619@wotan.suse.de> <20040922133906.7d57ef49.davem@davemloft.net> <20040922220628.GC2619@wotan.suse.de> <20040922152535.7bc81c8a.davem@davemloft.net> <20040922224732.GD2619@wotan.suse.de> <20040923161141.4ea9be4c.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040923161141.4ea9be4c.davem@davemloft.net> X-archive-position: 9426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 328 Lines: 9 > Anyways, for testing, something like the patch below. If things > still stink a bit, try using a limit of "2" in this patch instead > of "4". Doesn't help unfortunately. Anything >= 2 gives 22MB/s or even below (e.g. 3 gives 16MB/s). The only factor that works is 1, but that turns TSO effectively off, doesn't it? -Andi From laforge@gnumonks.org Fri Sep 24 01:52:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 01:52:55 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8O8qmj5028339 for ; Fri, 24 Sep 2004 01:52:49 -0700 Received: from dsl-213-023-154-085.arcor-ip.net ([213.23.154.85] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CAloi-0001X5-5y; Fri, 24 Sep 2004 10:52:36 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CAlog-0003b4-74; Fri, 24 Sep 2004 10:52:34 +0200 Date: Fri, 24 Sep 2004 10:52:34 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20040924085234.GE3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DYCP9ZX4RRtQiwKl" Content-Disposition: inline In-Reply-To: <20040923225158.23c2d502.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 2356 Lines: 67 --DYCP9ZX4RRtQiwKl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave, I'm just reviewing your patches right now... On Thu, Sep 23, 2004 at 10:51:58PM -0700, David S. Miller wrote: >=20 > This makes all the neigh implementations use jenkins. > --- a/net/core/neighbour.c 2004-09-23 22:27:14 -07:00 > +++ b/net/core/neighbour.c 2004-09-23 22:27:14 -07:00 > @@ -1316,6 +1317,8 @@ > panic("cannot allocate neighbour cache hashes"); > =20 > memset(tbl->phash_buckets, 0, phsize); > + > + get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd)); > =20 > tbl->lock =3D RW_LOCK_UNLOCKED; > init_timer(&tbl->gc_timer); So this means you put get_random_bytes into the __init function. I explicitly didn't want to do that (and added that _initted variable), since at bootup time we might not have sufficient entropy yet. This is before userspace has had time to reload the random seed saved before shutdown, so especially on automatic-booting embedded devices without any user interaction and never-changing flash layout (and thus similar interrupt patterns) I think this is quite weak. If we defer get_random_bytes() until the first neighbour is created, this gives the system some more time to gather entropy... =20 That's the same reasoning we have for making the conntrack hash work this way. Also, wouldn't it make sense to use a new random value if we grow the hash table? I mean it's cheap, and we make it harder for someone trying a hash-based attack. =20 Anyway, maybe I'm just being too paranoid. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --DYCP9ZX4RRtQiwKl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBU+BSXaXGVTD0i/8RAmdIAJ9zzU148nbYf84n/zIRMqcVa75VmwCgm/Dq 372FoysSSofPdz2TXOHH/co= =vVbN -----END PGP SIGNATURE----- --DYCP9ZX4RRtQiwKl-- From tgraf@suug.ch Fri Sep 24 05:37:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 05:37:11 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OCb2CM008676 for ; Fri, 24 Sep 2004 05:37:03 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 868F081; Fri, 24 Sep 2004 14:36:27 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 414171C0E8; Fri, 24 Sep 2004 14:37:10 +0200 (CEST) Date: Fri, 24 Sep 2004 14:37:10 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6 PKT_SCHED] Report qdisc parent to userspace Message-ID: <20040924123710.GB3944@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 9428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1394 Lines: 43 Report parent classid of a qdisc back to userspace. Without this there is no way for userspace to see if the qdisc is attached to a class other than parsing all class trees of the link and check all tcm_info fields in the leaf classes. Note: This has nothing to do with __parent. Signed-off-by: Thomas Graf --- linux-2.6.9-rc2-bk7.orig/include/net/pkt_sched.h 2004-09-21 23:26:54.000000000 +0200 +++ linux-2.6.9-rc2-bk7/include/net/pkt_sched.h 2004-09-24 14:15:36.000000000 +0200 @@ -80,6 +80,7 @@ int padded; struct Qdisc_ops *ops; u32 handle; + u32 parent; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; --- linux-2.6.9-rc2-bk7.orig/net/sched/sch_api.c 2004-09-21 23:27:31.000000000 +0200 +++ linux-2.6.9-rc2-bk7/net/sched/sch_api.c 2004-09-24 13:56:03.000000000 +0200 @@ -702,10 +702,11 @@ return -ENOENT; if (clid == TC_H_INGRESS) q = qdisc_create(dev, tcm->tcm_parent, tca, &err); - else + else q = qdisc_create(dev, tcm->tcm_handle, tca, &err); if (q == NULL) return err; + q->parent = clid; graft: if (1) { @@ -821,7 +822,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, 0, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock_bh(&qdisc_tree_lock); goto done; From tgr@reeler.org Fri Sep 24 05:52:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 05:53:02 -0700 (PDT) Received: from rei.rakuen (217-162-107-144.dclient.hispeed.ch [217.162.107.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OCqvhr009397 for ; Fri, 24 Sep 2004 05:52:58 -0700 Received: from tgr by rei.rakuen with local (Exim 4.34) id 1CApZ2-0005Zs-HN; Fri, 24 Sep 2004 14:52:40 +0200 Date: Fri, 24 Sep 2004 14:52:40 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 PKT_SCHED] Report qdisc parent to userspace Message-ID: <20040924125240.GT31616@rei.reeler.org> References: <20040924123710.GB3944@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924123710.GB3944@postel.suug.ch> X-archive-position: 9429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 455 Lines: 9 * Thomas Graf <20040924123710.GB3944@postel.suug.ch> 2004-09-24 14:37 > Report parent classid of a qdisc back to userspace. Without this there > is no way for userspace to see if the qdisc is attached to a class > other than parsing all class trees of the link and check all tcm_info > fields in the leaf classes. Don't include this patch yet. I think i missed a case when tcm_parent is set to a non-existant classid but gets attached to the root class. From buytenh@wantstofly.org Fri Sep 24 06:07:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 06:07:57 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OD7of4010084 for ; Fri, 24 Sep 2004 06:07:51 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 39BB52B0EC; Fri, 24 Sep 2004 15:07:38 +0200 (MEST) Date: Fri, 24 Sep 2004 15:07:38 +0200 From: Lennert Buytenhek To: Leonid Grossman Cc: "'David S. Miller'" , "'Jeff Garzik'" , alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-ID: <20040924130738.GB24093@xi.wantstofly.org> References: <20040915142926.7bc456a4.davem@davemloft.net> <200409152329.i8FNTsqG025184@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409152329.i8FNTsqG025184@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-archive-position: 9430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 346 Lines: 12 On Wed, Sep 15, 2004 at 04:29:45PM -0700, Leonid Grossman wrote: > And at 10GbE, embedded CPUs just don't cut it - it has to be custom ASIC > (granted, with some means to simplify debugging and reduce the risk of hw > bugs and TCP changes). Intel's IXP2800 can do 10GbE. http://www.intel.com/design/network/products/npfamily/ixp2800.htm --L From buytenh@wantstofly.org Fri Sep 24 06:12:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 06:12:14 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ODC9hX010499 for ; Fri, 24 Sep 2004 06:12:10 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 5E79C2B0EC; Fri, 24 Sep 2004 15:11:58 +0200 (MEST) Date: Fri, 24 Sep 2004 15:11:58 +0200 From: Lennert Buytenhek To: Deepak Saxena Cc: Paul Jakma , Netdev , leonid.grossman@s2io.com, Linux Kernel Subject: Re: The ultimate TOE design Message-ID: <20040924131158.GC24093@xi.wantstofly.org> References: <4148991B.9050200@pobox.com> <20040915213600.GA12153@plexity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915213600.GA12153@plexity.net> User-Agent: Mutt/1.4.1i X-archive-position: 9431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 530 Lines: 15 On Wed, Sep 15, 2004 at 02:36:00PM -0700, Deepak Saxena wrote: > > The intel IXP's are like the above, XScale+extra-bits host-on-a-PCI > > card running Linux. Or is that what you were referring to with > > " but they are all fairly expensive."? > > Unfortunately all the SW that lets one make use of the interesting > features of the IXPs (microEngines, crypto, etc) is a pile of > propietary code. I'm working on open source microengine code for the IXP line, which should be available Real Soon Now(TM). --L From leonid.grossman@s2io.com Fri Sep 24 06:23:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 06:23:15 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ODN5kV011047 for ; Fri, 24 Sep 2004 06:23:06 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8ODM0je005800; Fri, 24 Sep 2004 09:22:00 -0400 (EDT) Received: from lgt40 ([192.168.0.7]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i8ODLf39012346; Fri, 24 Sep 2004 09:21:41 -0400 (EDT) Message-Id: <200409241321.i8ODLf39012346@guinness.s2io.com> From: "Leonid Grossman" To: "'Lennert Buytenhek'" Cc: "'David S. Miller'" , "'Jeff Garzik'" , , , , Subject: RE: The ultimate TOE design Date: Fri, 24 Sep 2004 06:21:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcSiN3ouJCXNcKFtTaC0s3q11RKVmAAATZSA In-Reply-To: <20040924130738.GB24093@xi.wantstofly.org> X-Scanned-By: MIMEDefang 2.34 X-archive-position: 9432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 976 Lines: 33 > -----Original Message----- > From: Lennert Buytenhek [mailto:buytenh@wantstofly.org] > Sent: Friday, September 24, 2004 6:08 AM > To: Leonid Grossman > Cc: 'David S. Miller'; 'Jeff Garzik'; > alan@lxorguk.ukuu.org.uk; paul@clubi.ie; netdev@oss.sgi.com; > linux-kernel@vger.kernel.org > Subject: Re: The ultimate TOE design > > On Wed, Sep 15, 2004 at 04:29:45PM -0700, Leonid Grossman wrote: > > > And at 10GbE, embedded CPUs just don't cut it - it has to be custom > > ASIC (granted, with some means to simplify debugging and reduce the > > risk of hw bugs and TCP changes). > > Intel's IXP2800 can do 10GbE. Hi Lennert, I was referring to the server side. One can certanly build a 10GbE box based on IPX2800 (or some other parts), but at 17-25W it is not usable in NICs since the entire PCI card budget is less than that - nothing left for 10GbE PHY, memory, etc. Leonid > > http://www.intel.com/design/network/products/npfamily/ixp2800.htm > > > --L > From tgraf@suug.ch Fri Sep 24 07:00:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 07:00:36 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OE0Usf012524 for ; Fri, 24 Sep 2004 07:00:31 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 18AA981; Fri, 24 Sep 2004 15:59:57 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 82D2F1C0E8; Fri, 24 Sep 2004 16:00:39 +0200 (CEST) Date: Fri, 24 Sep 2004 16:00:39 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [RESEND PATCH 2.6 PKT_SCHED] Report qdisc parent to userspace Message-ID: <20040924140039.GA4079@postel.suug.ch> References: <20040924123710.GB3944@postel.suug.ch> <20040924125240.GT31616@rei.reeler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924125240.GT31616@rei.reeler.org> X-archive-position: 9433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1361 Lines: 40 This patch should be better, sorry for the brain dead patch before. Report parent classid of a qdisc back to userspace. Without this there is no way for userspace to see if the qdisc is attached to a class other than parsing all class trees of the link and check all tcm_info fields in the leaf classes. Signed-off-by: Thomas Graf --- linux-2.6.9-rc2-bk7.orig/include/net/pkt_sched.h 2004-09-21 23:26:54.000000000 +0200 +++ linux-2.6.9-rc2-bk7/include/net/pkt_sched.h 2004-09-24 14:15:36.000000000 +0200 @@ -80,6 +80,7 @@ int padded; struct Qdisc_ops *ops; u32 handle; + u32 parent; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; --- linux-2.6.9-rc2-bk7.orig/net/sched/sch_api.c 2004-09-21 23:27:31.000000000 +0200 +++ linux-2.6.9-rc2-bk7/net/sched/sch_api.c 2004-09-24 15:34:43.000000000 +0200 @@ -371,6 +371,8 @@ unsigned long cl = cops->get(parent, classid); if (cl) { err = cops->graft(parent, cl, new, old); + if (new) + new->parent = classid; cops->put(parent, cl); } } @@ -821,7 +823,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, 0, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock_bh(&qdisc_tree_lock); goto done; From ak@muc.de Fri Sep 24 07:45:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 07:45:13 -0700 (PDT) Received: from zero.aec.at (Quincy_Giles@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OEj6rY014429 for ; Fri, 24 Sep 2004 07:45:07 -0700 Received: from averell.firstfloor.org.muc.de (Averil_Joop@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i8OEijg10374; Fri, 24 Sep 2004 16:44:46 +0200 To: netdev@oss.sgi.com, coreteam@netfilter.org Subject: [PATCH] Fix ipchains/ipfw modules From: Andi Kleen Date: Fri, 24 Sep 2004 16:44:45 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 767 Lines: 28 ipchains didn't load anymore because it had a undefined symbol, which was satisfied by ipconntrack. This caused ipconntrack to be loaded first by modprobe, but the second ipconntrack init in ipchains would fail, causing the ipchains load to fail. ipfw had the same problem. Declare the missing variable. Signed-off-by: Andi Kleen diff -u linux/net/ipv4/netfilter/ip_fw_compat.c-IPC linux/net/ipv4/netfilter/ip_fw_compat.c --- linux/net/ipv4/netfilter/ip_fw_compat.c-IPC 2004-06-16 14:07:34.000000000 +0200 +++ linux/net/ipv4/netfilter/ip_fw_compat.c 2004-09-24 15:56:55.000000000 +0200 @@ -28,6 +28,8 @@ static struct firewall_ops *fwops; +unsigned int ip_ct_log_invalid; + #ifdef CONFIG_IP_VS /* From ip_vs_core.c */ extern unsigned int From acme@conectiva.com.br Fri Sep 24 08:15:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 08:15:31 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OFFFoV015510 for ; Fri, 24 Sep 2004 08:15:21 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id 2255A47359; Fri, 24 Sep 2004 12:14:56 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id DFCFB4748E for ; Fri, 24 Sep 2004 12:14:55 -0300 (BRT) Received: (qmail 29877 invoked by uid 0); 24 Sep 2004 16:11:43 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 24 Sep 2004 16:11:43 -0000 Received: from [192.168.1.6] (amd64.kerneljanitors.org [192.168.1.6]) by oops.ghostprotocols.net (Postfix) with ESMTP id 78ECC76858; Fri, 24 Sep 2004 12:17:37 -0300 (BRT) Message-ID: <415439FC.10401@conectiva.com.br> Date: Fri, 24 Sep 2004 12:15:08 -0300 From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen Cc: netdev@oss.sgi.com, coreteam@netfilter.org Subject: Re: [PATCH] Fix ipchains/ipfw modules References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bogosity: No, tests=bogofilter, spamicity=0.117391, version=0.16.3 X-archive-position: 9435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 1232 Lines: 42 Patrick McHardy fixed this in a different way in the "Re: [PATCH] Warn people that ipchains and ipfwadm are going away." lkml thread :-) His explanation: "Fixed by this patch. The conntrack protocols need ip_ct_log_invalid which is defined in ip_conntrack_standalone, so ip_conntrack is loaded automatically before ipchains. This patch moves it over to ip_conntrack_core." - Arnaldo Andi Kleen wrote: > ipchains didn't load anymore because it had a undefined symbol, > which was satisfied by ipconntrack. This caused ipconntrack to be > loaded first by modprobe, but the second ipconntrack init in ipchains > would fail, causing the ipchains load to fail. > > ipfw had the same problem. > > Declare the missing variable. > > Signed-off-by: Andi Kleen > > diff -u linux/net/ipv4/netfilter/ip_fw_compat.c-IPC linux/net/ipv4/netfilter/ip_fw_compat.c > --- linux/net/ipv4/netfilter/ip_fw_compat.c-IPC 2004-06-16 14:07:34.000000000 +0200 > +++ linux/net/ipv4/netfilter/ip_fw_compat.c 2004-09-24 15:56:55.000000000 +0200 > @@ -28,6 +28,8 @@ > > static struct firewall_ops *fwops; > > +unsigned int ip_ct_log_invalid; > + > #ifdef CONFIG_IP_VS > /* From ip_vs_core.c */ > extern unsigned int > > > > > > From tgraf@suug.ch Fri Sep 24 09:28:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 09:28:24 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OGSHUr020896 for ; Fri, 24 Sep 2004 09:28:18 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id DD26B81; Fri, 24 Sep 2004 18:27:43 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 70FA01C0E8; Fri, 24 Sep 2004 18:28:26 +0200 (CEST) Date: Fri, 24 Sep 2004 18:28:26 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.6 PKT_SCHED] Remove unneeded line Message-ID: <20040924162826.GB4079@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 9436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 485 Lines: 14 Remove unneeded line. Signed-off-by: Thomas Graf --- linux-2.6.9-rc2-bk7.orig/net/sched/sch_sfq.c 2004-09-21 23:27:31.000000000 +0200 +++ linux-2.6.9-rc2-bk7/net/sched/sch_sfq.c 2004-09-24 18:20:54.000000000 +0200 @@ -372,7 +372,6 @@ struct sfq_sched_data *q = qdisc_priv(sch); q->perturbation = net_random()&0x1F; - q->perturb_timer.expires = jiffies + q->perturb_period; if (q->perturb_period) { q->perturb_timer.expires = jiffies + q->perturb_period; From max@stro.at Fri Sep 24 09:34:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 09:34:16 -0700 (PDT) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OGYAvn021374 for ; Fri, 24 Sep 2004 09:34:10 -0700 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 26CDC5C07B; Fri, 24 Sep 2004 18:33:56 +0200 (CEST) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17517-03; Fri, 24 Sep 2004 18:33:55 +0200 (CEST) Received: from sputnik (v216-190.vps.tuwien.ac.at [128.131.216.190]) by baikonur.stro.at (Postfix) with ESMTP id 53E495C034; Fri, 24 Sep 2004 18:33:55 +0200 (CEST) Received: from max by sputnik with local (Exim 4.34) id 1CAt1E-0001Dh-HM; Fri, 24 Sep 2004 18:34:00 +0200 Date: Fri, 24 Sep 2004 18:34:00 +0200 From: maximilian attems To: Margit Schubert-While Cc: Nishanth Aravamudan , netdev@oss.sgi.com, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, jgarzik@pobox.com, prism54-devel@prism54.org, hvr@gnu.org Subject: Re: [Kernel-janitors] [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() Message-ID: <20040924163400.GA3118@stro.at> Mail-Followup-To: Margit Schubert-While , Nishanth Aravamudan , netdev@oss.sgi.com, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, jgarzik@pobox.com, prism54-devel@prism54.org, hvr@gnu.org References: <20040923221303.GB13244@us.ibm.com> <20040923221303.GB13244@us.ibm.com> <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-archive-position: 9437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: janitor@sternwelten.at Precedence: bulk X-list: netdev Content-Length: 1748 Lines: 50 On Fri, 24 Sep 2004, Margit Schubert-While wrote: .. > The patch has wrong line numbers. Doesn't take into account the stacked up > netdev changes. (Therefore CC'ing Jeff Garzik) sure the kj patches are against mainline. > This breaks 2.4 compatibility. > So either backport to 2.4 or Nish can take over prism54 2.4 maintenance ;-) can't remember the last time when Randy submitted janitorial patches to 2.4.x, but it's long ago. 2.4 is in maintenance mode. > Don't say a backport is not possible/reasonable, it happened with > netdev_priv(). > (In 2.4.27; At least there, we have HAVE_NETDEV_PRIV). there must have been serious reasons for that. > If this is going to be forced, can we at least have a > define HAVE_MSLEEP in delay.h ? > > I am somewhat confused by the second part of the patch. > What has that got to do with msleep ? basically a lot, because as prism54 lots of drivers forgo/et to set there state when calling schedule_timeout(). > Actually, the fix would appear to be correct, but that is a seperate issue > and nothing to do with msleep. > (Prims54 developers -> I'll take a look over the weekend) great, please also remove the unused TRACE macro. (patch was sent to netdev on 3. Sept). the kj mailing list got another submission to correct the __FUNCTION__ use their. :) > I am sceptical about the whole msleep patchset as, by their own admission, > the janitors have/can not (no hardware) test the majority of the changes. > Even more worrying is that incorrect code has directly appeared in > mainline kernel BK. the named small errors were quickly corrected. it's up to the driver MAINTAINER to prove us wrong. we got lots of ack in between. -- maks kernel janitor http://janitor.kernelnewbies.org/ From davem@davemloft.net Fri Sep 24 11:00:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 11:00:52 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OI0k83023937 for ; Fri, 24 Sep 2004 11:00:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAuLP-0000Lw-00; Fri, 24 Sep 2004 10:58:55 -0700 Date: Fri, 24 Sep 2004 10:58:55 -0700 From: "David S. Miller" To: Herbert Xu Cc: pablo@eurodev.net, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040924105855.0e1aecd0.davem@davemloft.net> In-Reply-To: <20040924062604.GA7393@gondor.apana.org.au> References: <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> <20040923223909.6f4da27f.davem@davemloft.net> <20040924062604.GA7393@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 748 Lines: 20 On Fri, 24 Sep 2004 16:26:04 +1000 Herbert Xu wrote: > It also means those responders that can calculate the correct size > of the reply doesn't need to go through this copy process. This is the crux of the problem, you don't know how big the response will be until you look at the whole object you are returning. This is because there are usually an unknown number of attributes that will be returned. This is why I suggested the PAGE_SIZE scratchpad, you build the response fully into there, then you know the exact size SKB you need so you allocate it and copy into it from the scratch pad. It's just a response build up area, and the goal is to have the minimum sized SKB necessary to represent the response. From buytenh@wantstofly.org Fri Sep 24 11:09:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 11:09:33 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OI9Rc7024453 for ; Fri, 24 Sep 2004 11:09:28 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id CB8662B0EC; Fri, 24 Sep 2004 20:09:15 +0200 (MEST) Date: Fri, 24 Sep 2004 20:09:15 +0200 From: Lennert Buytenhek To: Leonid Grossman Cc: "'David S. Miller'" , "'Jeff Garzik'" , alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design Message-ID: <20040924180915.GB26922@xi.wantstofly.org> References: <20040924130738.GB24093@xi.wantstofly.org> <200409241321.i8ODLf39012346@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409241321.i8ODLf39012346@guinness.s2io.com> User-Agent: Mutt/1.4.1i X-archive-position: 9439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 770 Lines: 25 On Fri, Sep 24, 2004 at 06:21:35AM -0700, Leonid Grossman wrote: > > > And at 10GbE, embedded CPUs just don't cut it - it has to be custom > > > ASIC (granted, with some means to simplify debugging and reduce the > > > risk of hw bugs and TCP changes). > > > > Intel's IXP2800 can do 10GbE. > > Hi Lennert, Hello, > I was referring to the server side. > One can certanly build a 10GbE box based on IPX2800 (or some other parts), > but at 17-25W it is not usable in NICs since the entire PCI card budget is > less than that - nothing left for 10GbE PHY, memory, etc. Ah, ok, that makes sense. As someone else also noted, the IXP2800 only has a 64/66 PCI interface anyway, so it wouldn't really be suitable for the task you were referring to. cheers, Lennert From davem@davemloft.net Fri Sep 24 11:10:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 11:10:22 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OIAI0K024651 for ; Fri, 24 Sep 2004 11:10:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAuU2-0000NG-00; Fri, 24 Sep 2004 11:07:50 -0700 Date: Fri, 24 Sep 2004 11:07:50 -0700 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: ak@muc.de, netdev@oss.sgi.com, coreteam@netfilter.org Subject: Re: [PATCH] Fix ipchains/ipfw modules Message-Id: <20040924110750.40c5f187.davem@davemloft.net> In-Reply-To: <415439FC.10401@conectiva.com.br> References: <415439FC.10401@conectiva.com.br> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 546 Lines: 14 On Fri, 24 Sep 2004 12:15:08 -0300 Arnaldo Carvalho de Melo wrote: > Patrick McHardy fixed this in a different way in the "Re: [PATCH] Warn > people that ipchains and ipfwadm are going away." lkml thread :-) > > His explanation: > > "Fixed by this patch. The conntrack protocols need ip_ct_log_invalid > which is defined in ip_conntrack_standalone, so ip_conntrack is > loaded automatically before ipchains. This patch moves it over to > ip_conntrack_core." Yes, and that fix is on it's way to Linus today some time. From yoshfuji@linux-ipv6.org Fri Sep 24 12:05:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 12:05:11 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OJ548L026241 for ; Fri, 24 Sep 2004 12:05:04 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 9F09033CE7; Sat, 25 Sep 2004 04:05:06 +0900 (JST) Date: Sat, 25 Sep 2004 04:05:06 +0900 (JST) Message-Id: <20040925.040506.106641510.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: andre@tomt.net, tgraf@suug.ch, pp@ee.oulu.fi, jgarzik@pobox.com, dwmw2@infradead.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH/RFC] PATCH: IPV6: Fix multiple leakages (is Re: unregister_netdevice: waiting for tun6to4 to become free.) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040923.172253.125681726.yoshfuji@linux-ipv6.org> References: <41527796.4010204@tomt.net> <4152843D.6010204@tomt.net> <20040923.172253.125681726.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 9441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 15676 Lines: 520 Hello. In article <20040923.172253.125681726.yoshfuji@linux-ipv6.org> (at Thu, 23 Sep 2004 17:22:53 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > Thank you everyone for tracking down this bug. > I will fix this bug and come up with patch tomorrow (or so). Well, I've created changesets which should fix multiple leakages. Here's the snapshot. Please review. Also available at: . Thanks. HEADLINES --------- ChangeSet@1.2005, 2004-09-24 15:54:32+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix device multicast list leakage when forwarding is on. ChangeSet@1.2006, 2004-09-24 16:29:02+09:00, yoshfuji@linux-ipv6.org [IPV6] Don't multiply join multicast/anycast addresses. ChangeSet@1.2007, 2004-09-24 17:19:13+09:00, yoshfuji@linux-ipv6.org [IPV6] Save number of arguments for __ipv6_dev_mc_dev(). ChangeSet@1.2008, 2004-09-24 17:30:22+09:00, yoshfuji@linux-ipv6.org [IPV6] use __ipv6_dev_mc_dec() where appropriate. ChangeSet@1.2009, 2004-09-24 20:39:28+09:00, yoshfuji@linux-ipv6.org [IPV6] leave solicited-node multicast address during device deletion. ChangeSet@1.2010, 2004-09-24 20:49:10+09:00, yoshfuji@linux-ipv6.org [IPV6] leave subnet-routers anycast address during device deletion. ChangeSet@1.2011, 2004-09-24 20:56:13+09:00, yoshfuji@linux-ipv6.org [IPV6] Clean up anycast membership management. CHANGESETS ---------- ChangeSet@1.2005, 2004-09-24 15:54:32+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix device multicast list leakage when forwarding is on. We failed to leave all-routers multicast address. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/mcast.c b/net/ipv6/mcast.c --- a/net/ipv6/mcast.c 2004-09-24 20:57:13 +09:00 +++ b/net/ipv6/mcast.c 2004-09-24 20:57:13 +09:00 @@ -2110,6 +2110,11 @@ */ __ipv6_dev_mc_dec(idev->dev, idev, &maddr); + if (idev->cnf.forwarding) { + ipv6_addr_all_routers(&maddr); + __ipv6_dev_mc_dec(idev->dev, idev, &maddr); + } + write_lock_bh(&idev->lock); while ((i = idev->mc_list) != NULL) { idev->mc_list = i->next; ChangeSet@1.2006, 2004-09-24 16:29:02+09:00, yoshfuji@linux-ipv6.org [IPV6] Don't multiply join multicast/anycast addresses. Case 1: if net.ipv6.conf.IFACE.forwarding has been set to 1, we multiply join routers' multicast/anycast addresses by setting net.ipv6.conf.all.forwarding to 1. Noticed by Andre Tomt . Case 2: if we change net.ipv6.conf.FOO.forwarding from 1 to 2, we multiply join routers' multicast/anycast addresses. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2004-09-24 20:57:16 +09:00 +++ b/net/ipv6/addrconf.c 2004-09-24 20:57:16 +09:00 @@ -430,22 +430,20 @@ } -static void addrconf_forward_change(struct inet6_dev *idev) +static void addrconf_forward_change(void) { struct net_device *dev; - - if (idev) { - dev_forward_change(idev); - return; - } + struct inet6_dev *idev; read_lock(&dev_base_lock); for (dev=dev_base; dev; dev=dev->next) { read_lock(&addrconf_lock); idev = __in6_dev_get(dev); if (idev) { + int changed = (!idev->cnf.forwarding) ^ (!ipv6_devconf.forwarding); idev->cnf.forwarding = ipv6_devconf.forwarding; - dev_forward_change(idev); + if (changed) + dev_forward_change(idev); } read_unlock(&addrconf_lock); } @@ -3025,18 +3023,18 @@ ret = proc_dointvec(ctl, write, filp, buffer, lenp, ppos); - if (write && *valp != val && valp != &ipv6_devconf_dflt.forwarding) { - struct inet6_dev *idev = NULL; - + if (write && valp != &ipv6_devconf_dflt.forwarding) { if (valp != &ipv6_devconf.forwarding) { - idev = (struct inet6_dev *)ctl->extra1; - if (idev == NULL) - return ret; - } else + if ((!*valp) ^ (!val)) { + struct inet6_dev *idev = (struct inet6_dev *)ctl->extra1; + if (idev == NULL) + return ret; + dev_forward_change(idev); + } + } else { ipv6_devconf_dflt.forwarding = ipv6_devconf.forwarding; - - addrconf_forward_change(idev); - + addrconf_forward_change(); + } if (*valp) rt6_purge_dflt_routers(0); } @@ -3077,15 +3075,19 @@ } if (valp != &ipv6_devconf_dflt.forwarding) { - struct inet6_dev *idev; if (valp != &ipv6_devconf.forwarding) { - idev = (struct inet6_dev *)table->extra1; + struct inet6_dev *idev = (struct inet6_dev *)table->extra1; + int changed; if (unlikely(idev == NULL)) return -ENODEV; - } else - idev = NULL; - *valp = new; - addrconf_forward_change(idev); + changed = (!*valp) ^ (!new); + *valp = new; + if (changed) + dev_forward_change(idev); + } else { + *valp = new; + addrconf_forward_change(); + } if (*valp) rt6_purge_dflt_routers(0); ChangeSet@1.2007, 2004-09-24 17:19:13+09:00, yoshfuji@linux-ipv6.org [IPV6] Save number of arguments for __ipv6_dev_mc_dev(). dev is unused in the function. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/mcast.c b/net/ipv6/mcast.c --- a/net/ipv6/mcast.c 2004-09-24 20:57:19 +09:00 +++ b/net/ipv6/mcast.c 2004-09-24 20:57:19 +09:00 @@ -870,7 +870,7 @@ /* * device multicast group del */ -static int __ipv6_dev_mc_dec(struct net_device *dev, struct inet6_dev *idev, struct in6_addr *addr) +static int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr) { struct ifmcaddr6 *ma, **map; @@ -903,7 +903,7 @@ if (!idev) return -ENODEV; - err = __ipv6_dev_mc_dec(dev, idev, addr); + err = __ipv6_dev_mc_dec(idev, addr); in6_dev_put(idev); @@ -2108,11 +2108,11 @@ * addrconf.c has NULL'd out dev->ip6_ptr so in6_dev_get() will * fail. */ - __ipv6_dev_mc_dec(idev->dev, idev, &maddr); + __ipv6_dev_mc_dec(idev, &maddr); if (idev->cnf.forwarding) { ipv6_addr_all_routers(&maddr); - __ipv6_dev_mc_dec(idev->dev, idev, &maddr); + __ipv6_dev_mc_dec(idev, &maddr); } write_lock_bh(&idev->lock); ChangeSet@1.2008, 2004-09-24 17:30:22+09:00, yoshfuji@linux-ipv6.org [IPV6] use __ipv6_dev_mc_dec() where appropriate. Use __ipv6_dev_mc_dec() instead where the caller knows idev. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/mcast.c b/net/ipv6/mcast.c --- a/net/ipv6/mcast.c 2004-09-24 20:57:22 +09:00 +++ b/net/ipv6/mcast.c 2004-09-24 20:57:22 +09:00 @@ -128,6 +128,8 @@ static struct socket *igmp6_socket; +static int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr); + static void igmp6_join_group(struct ifmcaddr6 *ma); static void igmp6_leave_group(struct ifmcaddr6 *ma); static void igmp6_timer_handler(unsigned long data); @@ -256,9 +258,9 @@ if (idev) { (void) ip6_mc_leave_src(sk,mc_lst,idev); + __ipv6_dev_mc_dec(idev, &mc_lst->addr); in6_dev_put(idev); } - ipv6_dev_mc_dec(dev, &mc_lst->addr); dev_put(dev); } sock_kfree_s(sk, mc_lst, sizeof(*mc_lst)); @@ -322,9 +324,9 @@ if (idev) { (void) ip6_mc_leave_src(sk, mc_lst, idev); + __ipv6_dev_mc_dec(idev, &mc_lst->addr); in6_dev_put(idev); } - ipv6_dev_mc_dec(dev, &mc_lst->addr); dev_put(dev); } ChangeSet@1.2009, 2004-09-24 20:39:28+09:00, yoshfuji@linux-ipv6.org [IPV6] leave solicited-node multicast address during device deletion. Because in6_dev_get() fails during device deletion, we failed to leave solicited-node multicast address. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/addrconf.h b/include/net/addrconf.h --- a/include/net/addrconf.h 2004-09-24 20:57:26 +09:00 +++ b/include/net/addrconf.h 2004-09-24 20:57:26 +09:00 @@ -74,7 +74,7 @@ const struct sock *sk2); extern void addrconf_join_solict(struct net_device *dev, struct in6_addr *addr); -extern void addrconf_leave_solict(struct net_device *dev, +extern void addrconf_leave_solict(struct inet6_dev *idev, struct in6_addr *addr); /* @@ -89,6 +89,7 @@ struct in6_addr *src_addr); extern int ipv6_dev_mc_inc(struct net_device *dev, struct in6_addr *addr); +extern int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr); extern int ipv6_dev_mc_dec(struct net_device *dev, struct in6_addr *addr); extern void ipv6_mc_up(struct inet6_dev *idev); extern void ipv6_mc_down(struct inet6_dev *idev); diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2004-09-24 20:57:26 +09:00 +++ b/net/ipv6/addrconf.c 2004-09-24 20:57:26 +09:00 @@ -1060,15 +1060,15 @@ ipv6_dev_mc_inc(dev, &maddr); } -void addrconf_leave_solict(struct net_device *dev, struct in6_addr *addr) +void addrconf_leave_solict(struct inet6_dev *idev, struct in6_addr *addr) { struct in6_addr maddr; - if (dev->flags&(IFF_LOOPBACK|IFF_NOARP)) + if (idev->dev->flags&(IFF_LOOPBACK|IFF_NOARP)) return; addrconf_addr_solict_mult(addr, &maddr); - ipv6_dev_mc_dec(dev, &maddr); + __ipv6_dev_mc_dec(idev, &maddr); } @@ -2994,7 +2994,7 @@ dst_release(&ifp->rt->u.dst); break; case RTM_DELADDR: - addrconf_leave_solict(ifp->idev->dev, &ifp->addr); + addrconf_leave_solict(ifp->idev, &ifp->addr); if (ifp->idev->cnf.forwarding) { struct in6_addr addr; diff -Nru a/net/ipv6/anycast.c b/net/ipv6/anycast.c --- a/net/ipv6/anycast.c 2004-09-24 20:57:26 +09:00 +++ b/net/ipv6/anycast.c 2004-09-24 20:57:26 +09:00 @@ -408,7 +408,7 @@ else idev->ac_list = aca->aca_next; write_unlock_bh(&idev->lock); - addrconf_leave_solict(dev, &aca->aca_addr); + addrconf_leave_solict(idev, &aca->aca_addr); dst_hold(&aca->aca_rt->u.dst); if (ip6_del_rt(aca->aca_rt, NULL, NULL)) diff -Nru a/net/ipv6/mcast.c b/net/ipv6/mcast.c --- a/net/ipv6/mcast.c 2004-09-24 20:57:26 +09:00 +++ b/net/ipv6/mcast.c 2004-09-24 20:57:26 +09:00 @@ -128,7 +128,7 @@ static struct socket *igmp6_socket; -static int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr); +int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr); static void igmp6_join_group(struct ifmcaddr6 *ma); static void igmp6_leave_group(struct ifmcaddr6 *ma); @@ -872,7 +872,7 @@ /* * device multicast group del */ -static int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr) +int __ipv6_dev_mc_dec(struct inet6_dev *idev, struct in6_addr *addr) { struct ifmcaddr6 *ma, **map; ChangeSet@1.2010, 2004-09-24 20:49:10+09:00, yoshfuji@linux-ipv6.org [IPV6] leave subnet-routers anycast address during device deletion. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/include/net/addrconf.h b/include/net/addrconf.h --- a/include/net/addrconf.h 2004-09-24 20:57:29 +09:00 +++ b/include/net/addrconf.h 2004-09-24 20:57:29 +09:00 @@ -112,6 +112,7 @@ extern int inet6_ac_check(struct sock *sk, struct in6_addr *addr, int ifindex); extern int ipv6_dev_ac_inc(struct net_device *dev, struct in6_addr *addr); +extern int __ipv6_dev_ac_dec(struct inet6_dev *idev, struct in6_addr *addr); extern int ipv6_dev_ac_dec(struct net_device *dev, struct in6_addr *addr); extern int ipv6_chk_acast_addr(struct net_device *dev, struct in6_addr *addr); diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2004-09-24 20:57:29 +09:00 +++ b/net/ipv6/addrconf.c 2004-09-24 20:57:29 +09:00 @@ -3000,7 +3000,7 @@ ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); if (!ipv6_addr_any(&addr)) - ipv6_dev_ac_dec(ifp->idev->dev, &addr); + __ipv6_dev_ac_dec(ifp->idev, &addr); } dst_hold(&ifp->rt->u.dst); if (ip6_del_rt(ifp->rt, NULL, NULL)) diff -Nru a/net/ipv6/anycast.c b/net/ipv6/anycast.c --- a/net/ipv6/anycast.c 2004-09-24 20:57:29 +09:00 +++ b/net/ipv6/anycast.c 2004-09-24 20:57:29 +09:00 @@ -377,15 +377,10 @@ /* * device anycast group decrement */ -int ipv6_dev_ac_dec(struct net_device *dev, struct in6_addr *addr) +int __ipv6_dev_ac_dec(struct inet6_dev *idev, struct in6_addr *addr) { - struct inet6_dev *idev; struct ifacaddr6 *aca, *prev_aca; - idev = in6_dev_get(dev); - if (idev == NULL) - return -ENODEV; - write_lock_bh(&idev->lock); prev_aca = NULL; for (aca = idev->ac_list; aca; aca = aca->aca_next) { @@ -395,12 +390,10 @@ } if (!aca) { write_unlock_bh(&idev->lock); - in6_dev_put(idev); return -ENOENT; } if (--aca->aca_users > 0) { write_unlock_bh(&idev->lock); - in6_dev_put(idev); return 0; } if (prev_aca) @@ -417,10 +410,20 @@ dst_release(&aca->aca_rt->u.dst); aca_put(aca); - in6_dev_put(idev); return 0; } +int ipv6_dev_ac_dec(struct net_device *dev, struct in6_addr *addr) +{ + int ret; + struct inet6_dev *idev = in6_dev_get(dev); + if (idev == NULL) + return -ENODEV; + ret = __ipv6_dev_ac_dec(idev, addr); + in6_dev_put(idev); + return ret; +} + /* * check if the interface has this anycast address */ ChangeSet@1.2011, 2004-09-24 20:56:13+09:00, yoshfuji@linux-ipv6.org [IPV6] Clean up anycast membership management. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c 2004-09-24 20:57:32 +09:00 +++ b/net/ipv6/addrconf.c 2004-09-24 20:57:32 +09:00 @@ -128,6 +128,9 @@ TIMER_INITIALIZER(addrconf_verify, 0, 0); static spinlock_t addrconf_verify_lock = SPIN_LOCK_UNLOCKED; +static void addrconf_join_anycast(struct inet6_ifaddr *ifp); +static void addrconf_leave_anycast(struct inet6_ifaddr *ifp); + static int addrconf_ifdown(struct net_device *dev, int how); static void addrconf_dad_start(struct inet6_ifaddr *ifp, int flags); @@ -419,13 +422,10 @@ ipv6_dev_mc_dec(dev, &addr); } for (ifa=idev->addr_list; ifa; ifa=ifa->if_next) { - ipv6_addr_prefix(&addr, &ifa->addr, ifa->prefix_len); - if (ipv6_addr_any(&addr)) - continue; if (idev->cnf.forwarding) - ipv6_dev_ac_inc(idev->dev, &addr); + addrconf_join_anycast(ifa); else - ipv6_dev_ac_dec(idev->dev, &addr); + addrconf_leave_anycast(ifa); } } @@ -1071,6 +1071,23 @@ __ipv6_dev_mc_dec(idev, &maddr); } +void addrconf_join_anycast(struct inet6_ifaddr *ifp) +{ + struct in6_addr addr; + ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); + if (ipv6_addr_any(&addr)) + return; + ipv6_dev_ac_inc(ifp->idev->dev, &addr); +} + +void addrconf_leave_anycast(struct inet6_ifaddr *ifp) +{ + struct in6_addr addr; + ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); + if (ipv6_addr_any(&addr)) + return; + __ipv6_dev_ac_dec(ifp->idev, &addr); +} static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) { @@ -2223,14 +2240,6 @@ addrconf_mod_timer(ifp, AC_RS, ifp->idev->cnf.rtr_solicit_interval); spin_unlock_bh(&ifp->lock); } - - if (ifp->idev->cnf.forwarding) { - struct in6_addr addr; - - ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); - if (!ipv6_addr_any(&addr)) - ipv6_dev_ac_inc(ifp->idev->dev, &addr); - } } #ifdef CONFIG_PROC_FS @@ -2992,16 +3001,13 @@ dst_hold(&ifp->rt->u.dst); if (ip6_ins_rt(ifp->rt, NULL, NULL)) dst_release(&ifp->rt->u.dst); + if (ifp->idev->cnf.forwarding) + addrconf_join_anycast(ifp); break; case RTM_DELADDR: + if (ifp->idev->cnf.forwarding) + addrconf_leave_anycast(ifp); addrconf_leave_solict(ifp->idev, &ifp->addr); - if (ifp->idev->cnf.forwarding) { - struct in6_addr addr; - - ipv6_addr_prefix(&addr, &ifp->addr, ifp->prefix_len); - if (!ipv6_addr_any(&addr)) - __ipv6_dev_ac_dec(ifp->idev, &addr); - } dst_hold(&ifp->rt->u.dst); if (ip6_del_rt(ifp->rt, NULL, NULL)) dst_free(&ifp->rt->u.dst); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From joelja@darkwing.uoregon.edu Fri Sep 24 12:39:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 12:39:30 -0700 (PDT) Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OJdO56030497 for ; Fri, 24 Sep 2004 12:39:24 -0700 Received: from twin.uoregon.edu (IDENT:cixgWCFPldcTx0DmcUWlIN2oecVdLbn8@twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i8OJd1UD024018 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 24 Sep 2004 12:39:02 -0700 (PDT) Date: Fri, 24 Sep 2004 12:39:01 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Lennert Buytenhek cc: Leonid Grossman , "'David S. Miller'" , "'Jeff Garzik'" , alan@lxorguk.ukuu.org.uk, paul@clubi.ie, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: The ultimate TOE design In-Reply-To: <20040924180915.GB26922@xi.wantstofly.org> Message-ID: References: <20040924130738.GB24093@xi.wantstofly.org> <200409241321.i8ODLf39012346@guinness.s2io.com> <20040924180915.GB26922@xi.wantstofly.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joelja@darkwing.uoregon.edu Precedence: bulk X-list: netdev Content-Length: 1519 Lines: 35 On Fri, 24 Sep 2004, Lennert Buytenhek wrote: > >> I was referring to the server side. >> One can certanly build a 10GbE box based on IPX2800 (or some other parts), >> but at 17-25W it is not usable in NICs since the entire PCI card budget is >> less than that - nothing left for 10GbE PHY, memory, etc. I have a graphics card which requires two four pin molex power connectors, going back in time there have allway been certain perphiral cards which required external (non-bus supplied power sources for whatever reason) (hard-drive on a card, sparc on a card, pc on a card, early 90's hardware mpeg encoder, data collection device, remote mangement card, graphics card in modern mac etc), it's obviously not a general solution, but it's been done frequently enough that it shouldn't just be discarded out of hand. > Ah, ok, that makes sense. As someone else also noted, the IXP2800 > only has a 64/66 PCI interface anyway, so it wouldn't really be > suitable for the task you were referring to. > > > cheers, > Lennert > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 From kumarkr@us.ibm.com Fri Sep 24 13:15:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 13:15:25 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OKFEGN031561 for ; Fri, 24 Sep 2004 13:15:20 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8OKELnJ543174; Fri, 24 Sep 2004 16:14:21 -0400 Received: from d03nm132.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8OKEKWl278504; Fri, 24 Sep 2004 14:14:21 -0600 In-Reply-To: <20040923225127.10b0ef68.davem@davemloft.net> Subject: Re: [5/6]: Dynamic neigh hash table growth To: "David S. Miller" Cc: laforge@gnumonks.org, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Krishna Kumar Date: Fri, 24 Sep 2004 13:11:58 -0700 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/24/2004 14:14:20 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE58ADFFF826D8f9e8a93df938690918c07BBE58ADFFF826D" Content-Disposition: inline X-archive-position: 9443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1593 Lines: 54 --0__=07BBE58ADFFF826D8f9e8a93df938690918c07BBE58ADFFF826D Content-type: text/plain; charset=US-ASCII In neigh_hash_grow(), next need not be set to NULL. thx, - KK > + for (i = 0; i < old_entries; i++) { > + struct neighbour *n, *next; > + > + next = NULL; > + for (n = old_hash[i]; n; n = next) { > + unsigned int hash_val = tbl->hash(n->primary_key, n->dev); > + > + hash_val &= new_hash_mask; > + next = n->next; > + > + n->next = new_hash[hash_val]; > + new_hash[hash_val] = n; > + } > + } --0__=07BBE58ADFFF826D8f9e8a93df938690918c07BBE58ADFFF826D Content-type: text/html; charset=US-ASCII Content-Disposition: inline

In neigh_hash_grow(), next need not be set to NULL.

thx,

- KK

> +   for (i = 0; i < old_entries; i++) {
> +      struct neighbour *n, *next;
> +
> +      next = NULL;
> +      for (n = old_hash[i]; n; n = next) {
> +         unsigned int hash_val = tbl->hash(n->primary_key, n->dev);
> +
> +         hash_val &= new_hash_mask;
> +         next = n->next;
> +
> +         n->next = new_hash[hash_val];
> +         new_hash[hash_val] = n;
> +      }
> +   } --0__=07BBE58ADFFF826D8f9e8a93df938690918c07BBE58ADFFF826D-- From davem@davemloft.net Fri Sep 24 13:31:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 13:31:39 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OKVSge032210 for ; Fri, 24 Sep 2004 13:31:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAweK-0000Ye-00; Fri, 24 Sep 2004 13:26:36 -0700 Date: Fri, 24 Sep 2004 13:26:36 -0700 From: "David S. Miller" To: Krishna Kumar Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [5/6]: Dynamic neigh hash table growth Message-Id: <20040924132636.195d4035.davem@davemloft.net> In-Reply-To: References: <20040923225127.10b0ef68.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 330 Lines: 10 On Fri, 24 Sep 2004 13:11:58 -0700 Krishna Kumar wrote: > In neigh_hash_grow(), next need not be set to NULL. I thought the compiler would warn, but aparently it doesn't, so I'll remove the assignment, thanks. Perhaps an older version of gcc, which has poorer flow analysis, will warn though... we'll see. From andre@tomt.net Fri Sep 24 13:49:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 13:49:13 -0700 (PDT) Received: from puppen.tomt.net (gw.pasop.tomt.net [80.239.42.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OKn77n000512 for ; Fri, 24 Sep 2004 13:49:08 -0700 Received: from [10.255.1.10] (slurv.pasop.tomt.net [10.255.1.10]) by puppen.tomt.net (Postfix) with ESMTP id 73B27229A5; Fri, 24 Sep 2004 22:48:55 +0200 (CEST) Message-ID: <415488BA.7020609@tomt.net> Date: Fri, 24 Sep 2004 22:51:06 +0200 From: Andre Tomt User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?WU9TSElGVUpJIEhpZGVha2kgLyDlkInol6Toi7HmmI4=?= Cc: davem@davemloft.net, tgraf@suug.ch, pp@ee.oulu.fi, jgarzik@pobox.com, dwmw2@infradead.org, netdev@oss.sgi.com Subject: Re: [PATCH/RFC] PATCH: IPV6: Fix multiple leakages (is Re: unregister_netdevice: waiting for tun6to4 to become free.) References: <41527796.4010204@tomt.net> <4152843D.6010204@tomt.net> <20040923.172253.125681726.yoshfuji@linux-ipv6.org> <20040925.040506.106641510.yoshfuji@linux-ipv6.org> In-Reply-To: <20040925.040506.106641510.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 9445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre@tomt.net Precedence: bulk X-list: netdev Content-Length: 665 Lines: 19 YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: >>Thank you everyone for tracking down this bug. >>I will fix this bug and come up with patch tomorrow (or so). > > Well, I've created changesets which should fix multiple leakages. > Here's the snapshot. Please review. I applied the following set to my internal 2.6.8.1 tree; > ChangeSet@1.2006, 2004-09-24 16:29:02+09:00, yoshfuji@linux-ipv6.org > [IPV6] Don't multiply join multicast/anycast addresses. It fixed my problem, thanks :-) Unless someone convinces me it has ill-effects with whats in the 2.6.8.1 ipv6 stack, it will probably go out in a router upgrade push some late night this weekend. -- André Tomt From davem@davemloft.net Fri Sep 24 14:28:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 14:28:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OLSi1V001800 for ; Fri, 24 Sep 2004 14:28:44 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAxao-0000el-00; Fri, 24 Sep 2004 14:27:02 -0700 Date: Fri, 24 Sep 2004 14:27:02 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040924142702.62a2b23d.davem@davemloft.net> In-Reply-To: <20040924085234.GE3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2328 Lines: 70 On Fri, 24 Sep 2004 10:52:34 +0200 Harald Welte wrote: > So this means you put get_random_bytes into the __init function. I > explicitly didn't want to do that (and added that _initted variable), > since at bootup time we might not have sufficient entropy yet. Good point. > If we defer get_random_bytes() until the first neighbour is created, > this gives the system some more time to gather entropy... ... > Also, wouldn't it make sense to use a new random value if we grow the > hash table? I mean it's cheap, and we make it harder for someone trying > a hash-based attack. I've combined all of your thoughts into the patch below. We set the initial ARP table very small (2 chains), and we regenerate the random seed every time we grow the hash table. This should address all of your concerns. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/24 14:06:45-07:00 davem@nuts.davemloft.net # [NET]: Neighbour hashing tweaks. # # 1) Start with a smaller initial hash table size. # This stresses the new code better. # 2) Generate a new hash_rnd every time we grow # the hashes. # # Based upon commentary from Harald Welte. # # Signed-off-by: David S. Miller # # net/core/neighbour.c # 2004/09/24 14:06:02-07:00 davem@nuts.davemloft.net +2 -1 # [NET]: Neighbour hashing tweaks. # # 1) Start with a smaller initial hash table size. # This stresses the new code better. # 2) Generate a new hash_rnd every time we grow # the hashes. # # Based upon commentary from Harald Welte. # # Signed-off-by: David S. Miller # diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-24 14:07:07 -07:00 +++ b/net/core/neighbour.c 2004-09-24 14:07:07 -07:00 @@ -331,6 +331,7 @@ old_hash = tbl->hash_buckets; write_lock_bh(&tbl->lock); + get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd)); for (i = 0; i < old_entries; i++) { struct neighbour *n, *next; @@ -1306,7 +1307,7 @@ if (!tbl->kmem_cachep) panic("cannot create neighbour cache"); - tbl->hash_mask = 0x1f; + tbl->hash_mask = 1; tbl->hash_buckets = neigh_hash_alloc(tbl->hash_mask + 1); phsize = (PNEIGH_HASHMASK + 1) * sizeof(struct pneigh_entry *); From herbert@gondor.apana.org.au Fri Sep 24 15:07:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 15:07:51 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OM7gL8003050 for ; Fri, 24 Sep 2004 15:07:43 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAyDW-0000es-00; Sat, 25 Sep 2004 08:07:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAyDL-0002N5-00; Sat, 25 Sep 2004 08:06:51 +1000 Date: Sat, 25 Sep 2004 08:06:51 +1000 To: "David S. Miller" Cc: pablo@eurodev.net, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040924220651.GA6096@gondor.apana.org.au> References: <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> <20040923223909.6f4da27f.davem@davemloft.net> <20040924062604.GA7393@gondor.apana.org.au> <20040924105855.0e1aecd0.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924105855.0e1aecd0.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1294 Lines: 31 On Fri, Sep 24, 2004 at 10:58:55AM -0700, David S. Miller wrote: > On Fri, 24 Sep 2004 16:26:04 +1000 > Herbert Xu wrote: > > > It also means those responders that can calculate the correct size > > of the reply doesn't need to go through this copy process. > > This is the crux of the problem, you don't know how big > the response will be until you look at the whole object > you are returning. I understand. What I'm saying is that some of these places already know how big it is going to be. See tcp_diag.c for an example. So we shouldn't impose the copy over head on everyone. > This is why I suggested the PAGE_SIZE scratchpad, you build > the response fully into there, then you know the exact size > SKB you need so you allocate it and copy into it from the > scratch pad. I agree completely. I'm just saying that the current NLM_GOODSIZE skb is the perfect scratch-pad so we don't need a new one. All we need to do is to insert a helper call just before netlink_unicast to copy and trim the packet in the places that need it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Fri Sep 24 15:29:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 15:29:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8OMTL8s003792 for ; Fri, 24 Sep 2004 15:29:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAyY1-0000sf-00; Sat, 25 Sep 2004 08:28:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAyXr-00050e-00; Sat, 25 Sep 2004 08:28:03 +1000 Date: Sat, 25 Sep 2004 08:28:03 +1000 To: "David S. Miller" Cc: pablo@eurodev.net, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040924222803.GA17594@gondor.apana.org.au> References: <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> <20040923223909.6f4da27f.davem@davemloft.net> <20040924062604.GA7393@gondor.apana.org.au> <20040924105855.0e1aecd0.davem@davemloft.net> <20040924220651.GA6096@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <20040924220651.GA6096@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1626 Lines: 55 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Sep 25, 2004 at 08:06:51AM +1000, herbert wrote: > > I agree completely. I'm just saying that the current NLM_GOODSIZE > skb is the perfect scratch-pad so we don't need a new one. All we > need to do is to insert a helper call just before netlink_unicast > to copy and trim the packet in the places that need it. Here is a demonstration of what I meant. Please note that this is totally untested. We could just make the last argument of netlink_unicast into a flag so that it can do this directly. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/xfrm/xfrm_user.c 1.51 vs edited ===== --- 1.51/net/xfrm/xfrm_user.c 2004-09-12 21:51:43 +10:00 +++ edited/net/xfrm/xfrm_user.c 2004-09-25 08:22:05 +10:00 @@ -433,10 +433,17 @@ resp_skb = xfrm_state_netlink(skb, x, nlh->nlmsg_seq); if (IS_ERR(resp_skb)) { err = PTR_ERR(resp_skb); - } else { - err = netlink_unicast(xfrm_nl, resp_skb, - NETLINK_CB(skb).pid, MSG_DONTWAIT); + goto out_put; } + + err = pskb_expand_head(resp_skb, 0, skb->tail - skb->end, GFP_KERNEL); + if (err) + goto out_put; + + err = netlink_unicast(xfrm_nl, resp_skb, + NETLINK_CB(skb).pid, MSG_DONTWAIT); + +out_put: xfrm_state_put(x); out_noput: return err; --AhhlLboLdkugWU4S-- From herbert@gondor.apana.org.au Fri Sep 24 16:21:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 16:21:33 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ONLMaT008512 for ; Fri, 24 Sep 2004 16:21:25 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAzN4-0001Hj-00; Sat, 25 Sep 2004 09:20:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAzMz-00022c-00; Sat, 25 Sep 2004 09:20:53 +1000 Date: Sat, 25 Sep 2004 09:20:53 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: Set truesize in pskb_expand_head Message-ID: <20040924232053.GA7807@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 960 Lines: 36 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: In order for the skb trimming to work, we need to set truesize in pskb_expand_head. This patch does exactly that. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/core/skbuff.c 1.37 vs edited ===== --- 1.37/net/core/skbuff.c 2004-08-03 12:20:05 +10:00 +++ edited/net/core/skbuff.c 2004-09-25 09:15:23 +10:00 @@ -541,6 +541,7 @@ off = (data + nhead) - skb->head; + skb->truesize = size + sizeof(struct sk_buff); skb->head = data; skb->end = data + size; skb->data += off; --+HP7ph2BbKc20aGI-- From herbert@gondor.apana.org.au Fri Sep 24 16:36:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 16:36:29 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ONaFak009244 for ; Fri, 24 Sep 2004 16:36:16 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAzba-0001OV-00; Sat, 25 Sep 2004 09:35:58 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAzbY-00024g-00; Sat, 25 Sep 2004 09:35:56 +1000 Date: Sat, 25 Sep 2004 09:35:55 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-ID: <20040924233555.GA7962@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924163328.7597352c.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 896 Lines: 23 On Fri, Sep 24, 2004 at 04:33:28PM -0700, David S. Miller wrote: > On Sat, 25 Sep 2004 09:20:53 +1000 > Herbert Xu wrote: > > > In order for the skb trimming to work, we need to set truesize in > > pskb_expand_head. This patch does exactly that. > > I tried to warn people about this earlier in the netlink > NLMSG_GOODSIZE thread.... ho hum. > > This change mucks up socket buffer accounting. > > If you change skb->truesize, then when the kfree_skb(skb) > happens a different skb->truesize will be subtracted from > the socket buffer allocation than what was used when the > skb was first charged to the socket. Dave, it hasn't been charged yet... -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Fri Sep 24 16:35:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 16:35:20 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ONZGFT009133 for ; Fri, 24 Sep 2004 16:35:16 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAzZA-0000pL-00; Fri, 24 Sep 2004 16:33:28 -0700 Date: Fri, 24 Sep 2004 16:33:28 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-Id: <20040924163328.7597352c.davem@davemloft.net> In-Reply-To: <20040924232053.GA7807@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 755 Lines: 22 On Sat, 25 Sep 2004 09:20:53 +1000 Herbert Xu wrote: > In order for the skb trimming to work, we need to set truesize in > pskb_expand_head. This patch does exactly that. I tried to warn people about this earlier in the netlink NLMSG_GOODSIZE thread.... ho hum. This change mucks up socket buffer accounting. If you change skb->truesize, then when the kfree_skb(skb) happens a different skb->truesize will be subtracted from the socket buffer allocation than what was used when the skb was first charged to the socket. Basically, once a skb might potentially be charged to a socket, you cannot change truesize unless you are extremely careful. This is another reason why I recommended to use a scratch buffer, btw :-) From herbert@gondor.apana.org.au Fri Sep 24 16:37:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 16:37:38 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ONbVaa009730 for ; Fri, 24 Sep 2004 16:37:32 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CAzco-0001PQ-00; Sat, 25 Sep 2004 09:37:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CAzcn-00025H-00; Sat, 25 Sep 2004 09:37:13 +1000 Date: Sat, 25 Sep 2004 09:37:13 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-ID: <20040924233713.GA8001@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> <20040924233555.GA7962@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040924233555.GA7962@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 463 Lines: 13 On Sat, Sep 25, 2004 at 09:35:55AM +1000, herbert wrote: > > Dave, it hasn't been charged yet... Well at least not in the netlink case. But you're that we can't do this in general. I'll adjust it right after the pskb_expand_head call then. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Fri Sep 24 16:48:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 16:48:09 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ONm37Y011259 for ; Fri, 24 Sep 2004 16:48:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CAzkz-0000qS-00; Fri, 24 Sep 2004 16:45:41 -0700 Date: Fri, 24 Sep 2004 16:45:40 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-Id: <20040924164540.2d750572.davem@davemloft.net> In-Reply-To: <20040924233713.GA8001@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> <20040924233555.GA7962@gondor.apana.org.au> <20040924233713.GA8001@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1211 Lines: 37 On Sat, 25 Sep 2004 09:37:13 +1000 Herbert Xu wrote: > On Sat, Sep 25, 2004 at 09:35:55AM +1000, herbert wrote: > > > > Dave, it hasn't been charged yet... > > Well at least not in the netlink case. But you're that we can't do this > in general. I'll adjust it right after the pskb_expand_head call then. I still am hesitant about your idea. You're willing to do a very likely re-alloc every transaction where as I'm suggesting a single allocation for the socket at creation time which is used for every transaction on that socket. Let's talk more precisely, perhaps I'm missing something, my scheme: Single PAGE_SIZE scratch buffer per socket, results in one allocation at socket creation time, and one SKB allocation while building a response. your scheme: Allocate full PAGE_SIZE SKB for each netlink transaction, reallocate data area at end of building each transaction. So, two data area kmalloc()'s per netlink response compared to one for mine. Your scheme doesn't even avoid the copy. What's the advantage? Furthermore my per-socket PAGE_SIZE scratch area is likely to get very good cache hit rates making the copy very inexpensive. Comments? From herbert@gondor.apana.org.au Fri Sep 24 17:05:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 17:05:34 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P05Owb011972 for ; Fri, 24 Sep 2004 17:05:25 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CB03n-0001ew-00; Sat, 25 Sep 2004 10:05:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CB03j-0003Vp-00; Sat, 25 Sep 2004 10:05:03 +1000 Date: Sat, 25 Sep 2004 10:05:03 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-ID: <20040925000503.GA10873@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> <20040924233555.GA7962@gondor.apana.org.au> <20040924233713.GA8001@gondor.apana.org.au> <20040924164540.2d750572.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20040924164540.2d750572.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3421 Lines: 112 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 24, 2004 at 04:45:40PM -0700, David S. Miller wrote: > > I still am hesitant about your idea. Alright let's talk more about it :) > You're willing to do a very likely re-alloc every transaction > where as I'm suggesting a single allocation for the socket at > creation time which is used for every transaction on that > socket. Yes. However, what we really care about is not how many reallocations there are, but how likely are they going to fail. In your scheme, every netlink socket gets a page regardless of whether it's going to be used (think of a socket for multicast reception only). That means at the point just before the realloc, your scheme would have allocated at least as much memory as my method, if not more. Therefore I'd argue that the realloc is more likely to fail for you. Let's also consider what happens when it does fail. In your scheme you've got to drop the packet. In mine, you just continue as we do now. > your scheme: > > Allocate full PAGE_SIZE SKB for each netlink transaction, > reallocate data area at end of building each transaction. That's not quite true. Some users (e.g., tcp_diag) can and do accurately estimate the final message size. They do not require a realloc/copy at all. > So, two data area kmalloc()'s per netlink response compared > to one for mine. Now I admit that is one weakness in my scheme. However, I'd argue that the performance cost of doing one extra kmalloc is lost when compared to the rest of the work in filling up the skb and copying it, no? > Your scheme doesn't even avoid the copy. What's the advantage? Actually, it does avoid the copy for all dumped packets except the final one as well as those packets that are near the right size already. > Furthermore my per-socket PAGE_SIZE scratch area is likely to > get very good cache hit rates making the copy very inexpensive. True. But surely it is better to not copy at all where possible? Here is the real patch. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/netlink/af_netlink.c 1.53 vs edited ===== --- 1.53/net/netlink/af_netlink.c 2004-09-22 12:32:44 +10:00 +++ edited/net/netlink/af_netlink.c 2004-09-25 09:53:19 +10:00 @@ -536,12 +536,25 @@ sock_put(sk); } +static inline void netlink_trim(struct sk_buff *skb, int allocation) +{ + int delta = skb->end - skb->tail; + + if (delta * 2 < skb->truesize) + return; + if (pskb_expand_head(skb, 0, -delta, allocation)) + return; + skb->truesize -= delta; +} + int netlink_unicast(struct sock *ssk, struct sk_buff *skb, u32 pid, int nonblock) { struct sock *sk; int err; long timeo; + netlink_trim(skb, gfp_any()); + timeo = sock_sndtimeo(ssk, nonblock); retry: sk = netlink_getsockbypid(ssk, pid); @@ -587,6 +600,8 @@ struct sk_buff *skb2 = NULL; int protocol = ssk->sk_protocol; int failure = 0, delivered = 0; + + netlink_trim(skb, allocation); /* While we sleep in clone, do not allow to change socket list */ --6TrnltStXW4iwmi0-- From laforge@gnumonks.org Fri Sep 24 23:44:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 24 Sep 2004 23:44:28 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P6iMGj025536 for ; Fri, 24 Sep 2004 23:44:23 -0700 Received: from dsl-082-082-101-005.arcor-ip.net ([82.82.101.5] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CB6Hw-0004d1-Im; Sat, 25 Sep 2004 08:44:08 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CB6Hu-0004O9-6s; Sat, 25 Sep 2004 08:44:06 +0200 Date: Sat, 25 Sep 2004 08:44:06 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20040925064406.GL3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cjNfFEtZoUGcCUIb" Content-Disposition: inline In-Reply-To: <20040924142702.62a2b23d.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1525 Lines: 45 --cjNfFEtZoUGcCUIb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 24, 2004 at 02:27:02PM -0700, David S. Miller wrote: > I've combined all of your thoughts into the patch below. > We set the initial ARP table very small (2 chains), and we > regenerate the random seed every time we grow the hash table. Thanks, Dave. > This should address all of your concerns. Indeed, it does. This basically means I am very happy with your overall patchset. I'll inclue it in my next round of kernel builds and give it some testing. Do you still want to push this for 2.6.9? I think I'll defer the 2.4.x backport until we've sorted out the one remaining 'starvation due to incomplete' issue. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --cjNfFEtZoUGcCUIb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBVRO2XaXGVTD0i/8RAt/IAJ9Zn2qj0FVYffFVXyoBwLZYU2r4+ACfT6HB DVrGCbT3SIzFyPHPWlbBrXA= =F9JE -----END PGP SIGNATURE----- --cjNfFEtZoUGcCUIb-- From davem@davemloft.net Sat Sep 25 00:58:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 00:58:28 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P7wKFM030769 for ; Sat, 25 Sep 2004 00:58:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CB7Pr-0001GC-00; Sat, 25 Sep 2004 00:56:23 -0700 Date: Sat, 25 Sep 2004 00:56:23 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040925005623.2faf8faf.davem@davemloft.net> In-Reply-To: <20040925064406.GL3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU" X-archive-position: 9456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 16295 Lines: 270 This is a multi-part message in MIME format. --Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 25 Sep 2004 08:44:06 +0200 Harald Welte wrote: > I'll inclue it in my next round of kernel builds and give it > some testing. Thanks. > Do you still want to push this for 2.6.9? > > I think I'll defer the 2.4.x backport until we've sorted out the one > remaining 'starvation due to incomplete' issue. Yes, and I'll defer the push to 2.6.9 until we conquer that too. So let's start! :-) Attached are 4 patches, the first 3 I'm happy with the last is a major RFC. Here's the breakdown: 1) Remove unnecessary next = NULL assignment noticed earlier today. 2) Tim Gardner's change to smooth out periodic neighbour GC. 3) Fix locking and GFP_* bugs. 4) The controversial/RFC patch, dorking with neigh_forced_gc() So let's discuss #4. It is the first idea I had to combat the "problem", but honestly right now I am beginning to think that the real solution is to simply remove the INCOMPLETE checks altogether. Neighbours are a sub-cache of the routing cache. Therefore when a neigh entry has a singular refcount, no routing cache entry points to it. No routing cache entry, we're not sending packets to that neighbour any time soon, so there is no reason (especially during strong pressure) to hold onto such entries. Agree or disagree? Regardless, I'd be interested how effective your stress case is with patch #4 and my new suggestion which is just to remove the: (n->nud_state != NUD_INCOMPLETE || time_after(jiffies, n->used + n->parms->retrans_time) from the neigh_forced_gc() code. Have at it :-) --Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU Content-Type: application/octet-stream; name="diff1" Content-Disposition: attachment; filename="diff1" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjQgMTM6MDk6NTAtMDc6MDAga3VtYXJrckB1cy5pYm0u Y29tIAojICAgW05FVF06IFJlbW92ZSB1bm5lY2Vzc2FyeSBsb2NhbCB2YXIgaW5pdGlhbGl6YXRp b24uCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1s b2Z0Lm5ldD4KIyAKIyBuZXQvY29yZS9uZWlnaGJvdXIuYwojICAgMjAwNC8wOS8yNCAxMzowOTow MC0wNzowMCBrdW1hcmtyQHVzLmlibS5jb20gKzAgLTEKIyAgIFtORVRdOiBSZW1vdmUgdW5uZWNl c3NhcnkgbG9jYWwgdmFyIGluaXRpYWxpemF0aW9uLgojIApkaWZmIC1OcnUgYS9uZXQvY29yZS9u ZWlnaGJvdXIuYyBiL25ldC9jb3JlL25laWdoYm91ci5jCi0tLSBhL25ldC9jb3JlL25laWdoYm91 ci5jCTIwMDQtMDktMjUgMDA6MzA6MTMgLTA3OjAwCisrKyBiL25ldC9jb3JlL25laWdoYm91ci5j CTIwMDQtMDktMjUgMDA6MzA6MTMgLTA3OjAwCkBAIC0zMzQsNyArMzM0LDYgQEAKIAlmb3IgKGkg PSAwOyBpIDwgb2xkX2VudHJpZXM7IGkrKykgewogCQlzdHJ1Y3QgbmVpZ2hib3VyICpuLCAqbmV4 dDsKIAotCQluZXh0ID0gTlVMTDsKIAkJZm9yIChuID0gb2xkX2hhc2hbaV07IG47IG4gPSBuZXh0 KSB7CiAJCQl1bnNpZ25lZCBpbnQgaGFzaF92YWwgPSB0YmwtPmhhc2gobi0+cHJpbWFyeV9rZXks IG4tPmRldik7CiAK --Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU Content-Type: application/octet-stream; name="diff2" Content-Disposition: attachment; filename="diff2" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjQgMTY6MDU6MTQtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW05FVF06IFNtb290aCBvdXQgcGVyaW9kaWMgbmVpZ2hib3VyIEdDLgoj ICAgCiMgICBCYXNlZCBhbG1vc3QgZW50aXJlbHkgdXBvbiB3b3JrIGJ5IFRpbSBHYXJkbmVyCiMg ICAodGltZ0B0cGkuY29tKSBhbmQgSGFyYWxkIFdlbHRlIChsYWZvcmdlQGdudW1vbmtzLm9yZykK IyAgIAojICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBkYXZlbWxvZnQu bmV0PgojIAojIG5ldC9jb3JlL25laWdoYm91ci5jCiMgICAyMDA0LzA5LzI0IDE2OjA0OjQ0LTA3 OjAwIGRhdmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArMzggLTMyCiMgICBbTkVUXTogU21vb3RoIG91 dCBwZXJpb2RpYyBuZWlnaGJvdXIgR0MuCiMgICAKIyAgIEJhc2VkIGFsbW9zdCBlbnRpcmVseSB1 cG9uIHdvcmsgYnkgVGltIEdhcmRuZXIKIyAgICh0aW1nQHRwaS5jb20pIGFuZCBIYXJhbGQgV2Vs dGUgKGxhZm9yZ2VAZ251bW9ua3Mub3JnKQojICAgCiMgICBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBT LiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+CiMgCiMgaW5jbHVkZS9uZXQvbmVpZ2hib3Vy LmgKIyAgIDIwMDQvMDkvMjQgMTY6MDQ6NDQtMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0 ICsxIC0wCiMgICBbTkVUXTogU21vb3RoIG91dCBwZXJpb2RpYyBuZWlnaGJvdXIgR0MuCiMgICAK IyAgIEJhc2VkIGFsbW9zdCBlbnRpcmVseSB1cG9uIHdvcmsgYnkgVGltIEdhcmRuZXIKIyAgICh0 aW1nQHRwaS5jb20pIGFuZCBIYXJhbGQgV2VsdGUgKGxhZm9yZ2VAZ251bW9ua3Mub3JnKQojICAg CiMgICBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+ CiMgCmRpZmYgLU5ydSBhL2luY2x1ZGUvbmV0L25laWdoYm91ci5oIGIvaW5jbHVkZS9uZXQvbmVp Z2hib3VyLmgKLS0tIGEvaW5jbHVkZS9uZXQvbmVpZ2hib3VyLmgJMjAwNC0wOS0yNSAwMDozMDoy NyAtMDc6MDAKKysrIGIvaW5jbHVkZS9uZXQvbmVpZ2hib3VyLmgJMjAwNC0wOS0yNSAwMDozMDoy NyAtMDc6MDAKQEAgLTE3Niw2ICsxNzYsNyBAQAogCXN0cnVjdCBuZWlnaGJvdXIJKipoYXNoX2J1 Y2tldHM7CiAJdW5zaWduZWQgaW50CQloYXNoX21hc2s7CiAJX191MzIJCQloYXNoX3JuZDsKKwl1 bnNpZ25lZCBpbnQJCWhhc2hfY2hhaW5fZ2M7CiAJc3RydWN0IHBuZWlnaF9lbnRyeQkqKnBoYXNo X2J1Y2tldHM7CiB9OwogCmRpZmYgLU5ydSBhL25ldC9jb3JlL25laWdoYm91ci5jIGIvbmV0L2Nv cmUvbmVpZ2hib3VyLmMKLS0tIGEvbmV0L2NvcmUvbmVpZ2hib3VyLmMJMjAwNC0wOS0yNSAwMDoz MDoyNyAtMDc6MDAKKysrIGIvbmV0L2NvcmUvbmVpZ2hib3VyLmMJMjAwNC0wOS0yNSAwMDozMDoy NyAtMDc6MDAKQEAgLTYzMSw5ICs2MzEsOCBAQAogc3RhdGljIHZvaWQgbmVpZ2hfcGVyaW9kaWNf dGltZXIodW5zaWduZWQgbG9uZyBhcmcpCiB7CiAJc3RydWN0IG5laWdoX3RhYmxlICp0YmwgPSAo c3RydWN0IG5laWdoX3RhYmxlICopYXJnOwotCXVuc2lnbmVkIGxvbmcgbm93ID0gamlmZmllczsK LQlpbnQgaTsKLQorCXN0cnVjdCBuZWlnaGJvdXIgKm4sICoqbnA7CisJdW5zaWduZWQgbG9uZyBl eHBpcmUsIG5vdyA9IGppZmZpZXM7CiAKIAl3cml0ZV9sb2NrKCZ0YmwtPmxvY2spOwogCkBAIC02 NDksNDEgKzY0OCw0OSBAQAogCQkJCW5laWdoX3JhbmRfcmVhY2hfdGltZShwLT5iYXNlX3JlYWNo YWJsZV90aW1lKTsKIAl9CiAKLQlmb3IgKGkgPSAwOyBpIDw9IHRibC0+aGFzaF9tYXNrOyBpKysp IHsKLQkJc3RydWN0IG5laWdoYm91ciAqbiwgKipucDsKKwlucCA9ICZ0YmwtPmhhc2hfYnVja2V0 c1t0YmwtPmhhc2hfY2hhaW5fZ2NdOworCXRibC0+aGFzaF9jaGFpbl9nYyA9ICgodGJsLT5oYXNo X2NoYWluX2djICsgMSkgJiB0YmwtPmhhc2hfbWFzayk7CiAKLQkJbnAgPSAmdGJsLT5oYXNoX2J1 Y2tldHNbaV07Ci0JCXdoaWxlICgobiA9ICpucCkgIT0gTlVMTCkgewotCQkJdW5zaWduZWQgc3Rh dGU7Ci0KLQkJCXdyaXRlX2xvY2soJm4tPmxvY2spOwotCi0JCQlzdGF0ZSA9IG4tPm51ZF9zdGF0 ZTsKLQkJCWlmIChzdGF0ZSAmIChOVURfUEVSTUFORU5UIHwgTlVEX0lOX1RJTUVSKSkgewotCQkJ CXdyaXRlX3VubG9jaygmbi0+bG9jayk7Ci0JCQkJZ290byBuZXh0X2VsdDsKLQkJCX0KKwl3aGls ZSAoKG4gPSAqbnApICE9IE5VTEwpIHsKKwkJdW5zaWduZWQgaW50IHN0YXRlOwogCi0JCQlpZiAo dGltZV9iZWZvcmUobi0+dXNlZCwgbi0+Y29uZmlybWVkKSkKLQkJCQluLT51c2VkID0gbi0+Y29u ZmlybWVkOworCQl3cml0ZV9sb2NrKCZuLT5sb2NrKTsKIAotCQkJaWYgKGF0b21pY19yZWFkKCZu LT5yZWZjbnQpID09IDEgJiYKLQkJCSAgICAoc3RhdGUgPT0gTlVEX0ZBSUxFRCB8fAotCQkJICAg ICB0aW1lX2FmdGVyKG5vdywgbi0+dXNlZCArIG4tPnBhcm1zLT5nY19zdGFsZXRpbWUpKSkgewot CQkJCSpucCA9IG4tPm5leHQ7Ci0JCQkJbi0+ZGVhZCA9IDE7Ci0JCQkJd3JpdGVfdW5sb2NrKCZu LT5sb2NrKTsKLQkJCQluZWlnaF9yZWxlYXNlKG4pOwotCQkJCWNvbnRpbnVlOwotCQkJfQorCQlz dGF0ZSA9IG4tPm51ZF9zdGF0ZTsKKwkJaWYgKHN0YXRlICYgKE5VRF9QRVJNQU5FTlQgfCBOVURf SU5fVElNRVIpKSB7CiAJCQl3cml0ZV91bmxvY2soJm4tPmxvY2spOworCQkJZ290byBuZXh0X2Vs dDsKKwkJfQogCi1uZXh0X2VsdDoKLQkJCW5wID0gJm4tPm5leHQ7CisJCWlmICh0aW1lX2JlZm9y ZShuLT51c2VkLCBuLT5jb25maXJtZWQpKQorCQkJbi0+dXNlZCA9IG4tPmNvbmZpcm1lZDsKKwor CQlpZiAoYXRvbWljX3JlYWQoJm4tPnJlZmNudCkgPT0gMSAmJgorCQkgICAgKHN0YXRlID09IE5V RF9GQUlMRUQgfHwKKwkJICAgICB0aW1lX2FmdGVyKG5vdywgbi0+dXNlZCArIG4tPnBhcm1zLT5n Y19zdGFsZXRpbWUpKSkgeworCQkJKm5wID0gbi0+bmV4dDsKKwkJCW4tPmRlYWQgPSAxOworCQkJ d3JpdGVfdW5sb2NrKCZuLT5sb2NrKTsKKwkJCW5laWdoX3JlbGVhc2Uobik7CisJCQljb250aW51 ZTsKIAkJfQorCQl3cml0ZV91bmxvY2soJm4tPmxvY2spOworCituZXh0X2VsdDoKKwkJbnAgPSAm bi0+bmV4dDsKIAl9CiAKLQltb2RfdGltZXIoJnRibC0+Z2NfdGltZXIsIG5vdyArIHRibC0+Z2Nf aW50ZXJ2YWwpOworIAkvKiBDeWNsZSB0aHJvdWdoIGFsbCBoYXNoIGJ1Y2tldHMgZXZlcnkgYmFz ZV9yZWFjaGFibGVfdGltZS8yIHRpY2tzLgorIAkgKiBBUlAgZW50cnkgdGltZW91dHMgcmFuZ2Ug ZnJvbSAxLzIgYmFzZV9yZWFjaGFibGVfdGltZSB0byAzLzIKKyAJICogYmFzZV9yZWFjaGFibGVf dGltZS4KKwkgKi8KKwlleHBpcmUgPSB0YmwtPnBhcm1zLmJhc2VfcmVhY2hhYmxlX3RpbWUgPj4g MTsKKwlleHBpcmUgLz0gKHRibC0+aGFzaF9tYXNrICsgMSk7CisJaWYgKCFleHBpcmUpCisJCWV4 cGlyZSA9IDE7CisKKyAJbW9kX3RpbWVyKCZ0YmwtPmdjX3RpbWVyLCBub3cgKyBleHBpcmUpOwor CiAJd3JpdGVfdW5sb2NrKCZ0YmwtPmxvY2spOwogfQogCkBAIC0xMzI0LDggKzEzMzEsNyBAQAog CWluaXRfdGltZXIoJnRibC0+Z2NfdGltZXIpOwogCXRibC0+Z2NfdGltZXIuZGF0YSAgICAgPSAo dW5zaWduZWQgbG9uZyl0Ymw7CiAJdGJsLT5nY190aW1lci5mdW5jdGlvbiA9IG5laWdoX3Blcmlv ZGljX3RpbWVyOwotCXRibC0+Z2NfdGltZXIuZXhwaXJlcyAgPSBub3cgKyB0YmwtPmdjX2ludGVy dmFsICsKLQkJCQkgdGJsLT5wYXJtcy5yZWFjaGFibGVfdGltZTsKKwl0YmwtPmdjX3RpbWVyLmV4 cGlyZXMgID0gbm93ICsgMTsKIAlhZGRfdGltZXIoJnRibC0+Z2NfdGltZXIpOwogCiAJaW5pdF90 aW1lcigmdGJsLT5wcm94eV90aW1lcik7Cg== --Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU Content-Type: application/octet-stream; name="diff3" Content-Disposition: attachment; filename="diff3" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjQgMTY6MjI6MTQtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW05FVF06IEZpeCBzb21lIG5laWdoIHRhYmxlIGxvY2tpbmcgZXJyb3Jz LgojICAgCiMgICBBbHNvLCBtYWtlIG5laWdoX2hhc2hfYWxsb2MoKSB1c2UgR0ZQX0FUT01JQy4K IyAgIAojICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBkYXZlbWxvZnQu bmV0PgojIAojIG5ldC9jb3JlL25laWdoYm91ci5jCiMgICAyMDA0LzA5LzI0IDE2OjIxOjQ5LTA3 OjAwIGRhdmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArMTQgLTkKIyAgIFtORVRdOiBGaXggc29tZSBu ZWlnaCB0YWJsZSBsb2NraW5nIGVycm9ycy4KIyAgIAojICAgQWxzbywgbWFrZSBuZWlnaF9oYXNo X2FsbG9jKCkgdXNlIEdGUF9BVE9NSUMuCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMu IE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4KIyAKZGlmZiAtTnJ1IGEvbmV0L2NvcmUvbmVp Z2hib3VyLmMgYi9uZXQvY29yZS9uZWlnaGJvdXIuYwotLS0gYS9uZXQvY29yZS9uZWlnaGJvdXIu YwkyMDA0LTA5LTI1IDAwOjMwOjQwIC0wNzowMAorKysgYi9uZXQvY29yZS9uZWlnaGJvdXIuYwky MDA0LTA5LTI1IDAwOjMwOjQwIC0wNzowMApAQCAtMTE2LDExICsxMTYsMTEgQEAKIAlpbnQgc2hy dW5rID0gMDsKIAlpbnQgaTsKIAorCXdyaXRlX2xvY2tfYmgoJnRibC0+bG9jayk7CiAJZm9yIChp ID0gMDsgaSA8PSB0YmwtPmhhc2hfbWFzazsgaSsrKSB7CiAJCXN0cnVjdCBuZWlnaGJvdXIgKm4s ICoqbnA7CiAKIAkJbnAgPSAmdGJsLT5oYXNoX2J1Y2tldHNbaV07Ci0JCXdyaXRlX2xvY2tfYmgo JnRibC0+bG9jayk7CiAJCXdoaWxlICgobiA9ICpucCkgIT0gTlVMTCkgewogCQkJLyogTmVpZ2hi b3VyIHJlY29yZCBtYXkgYmUgZGlzY2FyZGVkIGlmOgogCQkJICAgLSBub2JvZHkgcmVmZXJzIHRv IGl0LgpAQCAtMTQ3LDEwICsxNDcsMTIgQEAKIAkJCXdyaXRlX3VubG9jaygmbi0+bG9jayk7CiAJ CQlucCA9ICZuLT5uZXh0OwogCQl9Ci0JCXdyaXRlX3VubG9ja19iaCgmdGJsLT5sb2NrKTsKIAl9 CiAKIAl0YmwtPmxhc3RfZmx1c2ggPSBqaWZmaWVzOworCisJd3JpdGVfdW5sb2NrX2JoKCZ0Ymwt PmxvY2spOworCiAJcmV0dXJuIHNocnVuazsKIH0KIApAQCAtMjk1LDEwICsyOTcsMTAgQEAKIAlz dHJ1Y3QgbmVpZ2hib3VyICoqcmV0OwogCiAJaWYgKHNpemUgPD0gUEFHRV9TSVpFKSB7Ci0JCXJl dCA9IGttYWxsb2Moc2l6ZSwgR0ZQX0tFUk5FTCk7CisJCXJldCA9IGttYWxsb2Moc2l6ZSwgR0ZQ X0FUT01JQyk7CiAJfSBlbHNlIHsKIAkJcmV0ID0gKHN0cnVjdCBuZWlnaGJvdXIgKiopCi0JCQlf X2dldF9mcmVlX3BhZ2VzKEdGUF9LRVJORUwsIGdldF9vcmRlcihzaXplKSk7CisJCQlfX2dldF9m cmVlX3BhZ2VzKEdGUF9BVE9NSUMsIGdldF9vcmRlcihzaXplKSk7CiAJfQogCWlmIChyZXQpCiAJ CW1lbXNldChyZXQsIDAsIHNpemUpOwpAQCAtMzMwLDcgKzMzMiw2IEBACiAJbmV3X2hhc2hfbWFz ayA9IG5ld19lbnRyaWVzIC0gMTsKIAlvbGRfaGFzaCA9IHRibC0+aGFzaF9idWNrZXRzOwogCi0J d3JpdGVfbG9ja19iaCgmdGJsLT5sb2NrKTsKIAlnZXRfcmFuZG9tX2J5dGVzKCZ0YmwtPmhhc2hf cm5kLCBzaXplb2YodGJsLT5oYXNoX3JuZCkpOwogCWZvciAoaSA9IDA7IGkgPCBvbGRfZW50cmll czsgaSsrKSB7CiAJCXN0cnVjdCBuZWlnaGJvdXIgKm4sICpuZXh0OwpAQCAtMzQ3LDcgKzM0OCw2 IEBACiAJfQogCXRibC0+aGFzaF9idWNrZXRzID0gbmV3X2hhc2g7CiAJdGJsLT5oYXNoX21hc2sg PSBuZXdfaGFzaF9tYXNrOwotCXdyaXRlX3VubG9ja19iaCgmdGJsLT5sb2NrKTsKIAogCW5laWdo X2hhc2hfZnJlZShvbGRfaGFzaCwgb2xkX2VudHJpZXMpOwogfQpAQCAtNDAwLDggKzQwMCwxMSBA QAogCQlnb3RvIG91dDsKIAl9CiAKLQlpZiAodGJsLT5lbnRyaWVzID4gKHRibC0+aGFzaF9tYXNr ICsgMSkpCisJaWYgKHRibC0+ZW50cmllcyA+ICh0YmwtPmhhc2hfbWFzayArIDEpKSB7CisJCXdy aXRlX2xvY2tfYmgoJnRibC0+bG9jayk7CiAJCW5laWdoX2hhc2hfZ3Jvdyh0YmwsICh0YmwtPmhh c2hfbWFzayArIDEpIDw8IDEpOworCQl3cml0ZV91bmxvY2tfYmgoJnRibC0+bG9jayk7CisJfQog CiAJbWVtY3B5KG4tPnByaW1hcnlfa2V5LCBwa2V5LCBrZXlfbGVuKTsKIAluLT5kZXYgPSBkZXY7 CkBAIC00MjIsOSArNDI1LDEwIEBACiAKIAluLT5jb25maXJtZWQgPSBqaWZmaWVzIC0gKG4tPnBh cm1zLT5iYXNlX3JlYWNoYWJsZV90aW1lIDw8IDEpOwogCisJd3JpdGVfbG9ja19iaCgmdGJsLT5s b2NrKTsKKwogCWhhc2hfdmFsID0gdGJsLT5oYXNoKHBrZXksIGRldikgJiB0YmwtPmhhc2hfbWFz azsKIAotCXdyaXRlX2xvY2tfYmgoJnRibC0+bG9jayk7CiAJaWYgKG4tPnBhcm1zLT5kZWFkKSB7 CiAJCXJjID0gRVJSX1BUUigtRUlOVkFMKTsKIAkJZ290byBvdXRfdGJsX3VubG9jazsKQEAgLTUx NCwxMCArNTE4LDEwIEBACiAJaGFzaF92YWwgXj0gaGFzaF92YWwgPj4gNDsKIAloYXNoX3ZhbCAm PSBQTkVJR0hfSEFTSE1BU0s7CiAKKwl3cml0ZV9sb2NrX2JoKCZ0YmwtPmxvY2spOwogCWZvciAo bnAgPSAmdGJsLT5waGFzaF9idWNrZXRzW2hhc2hfdmFsXTsgKG4gPSAqbnApICE9IE5VTEw7CiAJ ICAgICBucCA9ICZuLT5uZXh0KSB7CiAJCWlmICghbWVtY21wKG4tPmtleSwgcGtleSwga2V5X2xl bikgJiYgbi0+ZGV2ID09IGRldikgewotCQkJd3JpdGVfbG9ja19iaCgmdGJsLT5sb2NrKTsKIAkJ CSpucCA9IG4tPm5leHQ7CiAJCQl3cml0ZV91bmxvY2tfYmgoJnRibC0+bG9jayk7CiAJCQlpZiAo dGJsLT5wZGVzdHJ1Y3RvcikKQEAgLTUyNiw2ICs1MzAsNyBAQAogCQkJcmV0dXJuIDA7CiAJCX0K IAl9CisJd3JpdGVfdW5sb2NrX2JoKCZ0YmwtPmxvY2spOwogCXJldHVybiAtRU5PRU5UOwogfQog Cg== --Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU Content-Type: application/octet-stream; name="diff4" Content-Disposition: attachment; filename="diff4" Content-Transfer-Encoding: base64 PT09PT0gbmV0L2NvcmUvbmVpZ2hib3VyLmMgMS40NyB2cyBlZGl0ZWQgPT09PT0KLS0tIDEuNDcv bmV0L2NvcmUvbmVpZ2hib3VyLmMJMjAwNC0wOS0yNCAxNjoyMTo0OSAtMDc6MDAKKysrIGVkaXRl ZC9uZXQvY29yZS9uZWlnaGJvdXIuYwkyMDA0LTA5LTI0IDE2OjM4OjU4IC0wNzowMApAQCAtMTEw LDEzICsxMTAsMTMgQEAKIAlyZXR1cm4gKG5ldF9yYW5kb20oKSAlIGJhc2UpICsgKGJhc2UgPj4g MSk7CiB9CiAKLQotc3RhdGljIGludCBuZWlnaF9mb3JjZWRfZ2Moc3RydWN0IG5laWdoX3RhYmxl ICp0YmwpCitzdGF0aWMgaW50IG5laWdoX2ZvcmNlZF9nYyhzdHJ1Y3QgbmVpZ2hfdGFibGUgKnRi bCwgaW50IGdvYWwpCiB7Ci0JaW50IHNocnVuayA9IDA7CisJaW50IHNocnVuayA9IDAsIG51bV9p bmNvbXBsZXRlID0gMCwgcmVhcF9pbmNvbXBsZXRlID0gMDsKIAlpbnQgaTsKIAogCXdyaXRlX2xv Y2tfYmgoJnRibC0+bG9jayk7CityZXNjYW46CiAJZm9yIChpID0gMDsgaSA8PSB0YmwtPmhhc2hf bWFzazsgaSsrKSB7CiAJCXN0cnVjdCBuZWlnaGJvdXIgKm4sICoqbnA7CiAKQEAgLTEyNSwzMCAr MTI1LDQ2IEBACiAJCQkvKiBOZWlnaGJvdXIgcmVjb3JkIG1heSBiZSBkaXNjYXJkZWQgaWY6CiAJ CQkgICAtIG5vYm9keSByZWZlcnMgdG8gaXQuCiAJCQkgICAtIGl0IGlzIG5vdCBwZXJtYW5lbnQK LQkJCSAgIC0gKE5FVyBhbmQgcHJvYmFibHkgd3JvbmcpCisJCQkgICAtIE9uIHRoZSBmaXJzdCBw YXNzIG9mIHRoaXMgc2NhbiwKIAkJCSAgICAgSU5DT01QTEVURSBlbnRyaWVzIGFyZSBrZXB0IGF0 IGxlYXN0IGZvcgogCQkJICAgICBuLT5wYXJtcy0+cmV0cmFuc190aW1lLCBvdGhlcndpc2Ugd2Ug Y291bGQKIAkJCSAgICAgZmxvb2QgbmV0d29yayB3aXRoIHJlc29sdXRpb24gcmVxdWVzdHMuCi0J CQkgICAgIEl0IGlzIG5vdCBjbGVhciwgd2hhdCBpcyBiZXR0ZXIgdGFibGUgb3ZlcmZsb3cKLQkJ CSAgICAgb3IgZmxvb2RpbmcuCiAJCQkgKi8KIAkJCXdyaXRlX2xvY2soJm4tPmxvY2spOwotCQkJ aWYgKGF0b21pY19yZWFkKCZuLT5yZWZjbnQpID09IDEgJiYKLQkJCSAgICAhKG4tPm51ZF9zdGF0 ZSAmIE5VRF9QRVJNQU5FTlQpICYmCi0JCQkgICAgKG4tPm51ZF9zdGF0ZSAhPSBOVURfSU5DT01Q TEVURSB8fAotCQkJICAgICB0aW1lX2FmdGVyKGppZmZpZXMsIG4tPnVzZWQgKyBuLT5wYXJtcy0+ cmV0cmFuc190aW1lKSkpIHsKLQkJCQkqbnAJPSBuLT5uZXh0OwotCQkJCW4tPmRlYWQgPSAxOwot CQkJCXNocnVuawk9IDE7Ci0JCQkJd3JpdGVfdW5sb2NrKCZuLT5sb2NrKTsKLQkJCQluZWlnaF9y ZWxlYXNlKG4pOwotCQkJCWNvbnRpbnVlOworCQkJaWYgKGF0b21pY19yZWFkKCZuLT5yZWZjbnQp ICE9IDEpCisJCQkJZ290byBuZXh0X2VudDsKKworCQkJaWYgKG4tPm51ZF9zdGF0ZSAmIE5VRF9Q RVJNQU5FTlQpCisJCQkJZ290byBuZXh0X2VudDsKKworCQkJaWYgKG4tPm51ZF9zdGF0ZSAtPSBO VURfSU5DT01QTEVURSAmJgorCQkJICAgIHJlYXBfaW5jb21wbGV0ZSA9PSAwICYmCisJCQkgICAg dGltZV9hZnRlcihqaWZmaWVzLAorCQkJCSAgICAgICBuLT51c2VkICsgbi0+cGFybXMtPnJldHJh bnNfdGltZSkpIHsKKwkJCQludW1faW5jb21wbGV0ZSsrOworCQkJCWdvdG8gbmV4dF9lbnQ7CiAJ CQl9CisKKwkJCSpucAk9IG4tPm5leHQ7CisJCQluLT5kZWFkID0gMTsKKwkJCXNocnVuaysrOwor CQkJd3JpdGVfdW5sb2NrKCZuLT5sb2NrKTsKKwkJCW5laWdoX3JlbGVhc2Uobik7CisJCQljb250 aW51ZTsKKworCQluZXh0X2VudDoKIAkJCXdyaXRlX3VubG9jaygmbi0+bG9jayk7CiAJCQlucCA9 ICZuLT5uZXh0OwogCQl9CiAJfQogCisJaWYgKHJlYXBfaW5jb21wbGV0ZSA9PSAwICYmCisJICAg IHNocnVuayA8IGdvYWwgJiYKKwkgICAgKHNocnVuayArIG51bV9pbmNvbXBsZXRlKSA+PSBnb2Fs KSB7CisJCXJlYXBfaW5jb21wbGV0ZSA9IDE7CisJCWdvdG8gcmVzY2FuOworCX0KKwogCXRibC0+ bGFzdF9mbHVzaCA9IGppZmZpZXM7CiAKIAl3cml0ZV91bmxvY2tfYmgoJnRibC0+bG9jayk7CkBA IC0yNjEsNyArMjc3LDkgQEAKIAlpZiAodGJsLT5lbnRyaWVzID4gdGJsLT5nY190aHJlc2gzIHx8 CiAJICAgICh0YmwtPmVudHJpZXMgPiB0YmwtPmdjX3RocmVzaDIgJiYKIAkgICAgIHRpbWVfYWZ0 ZXIobm93LCB0YmwtPmxhc3RfZmx1c2ggKyA1ICogSFopKSkgewotCQlpZiAoIW5laWdoX2ZvcmNl ZF9nYyh0YmwpICYmCisJCWludCBnb2FsID0gdGJsLT5lbnRyaWVzIC0gdGJsLT5nY190aHJlc2gz OworCisJCWlmICghbmVpZ2hfZm9yY2VkX2djKHRibCwgZ29hbCkgJiYKIAkJICAgIHRibC0+ZW50 cmllcyA+IHRibC0+Z2NfdGhyZXNoMykKIAkJCWdvdG8gb3V0OwogCX0K --Multipart=_Sat__25_Sep_2004_00_56_23_-0700_uLfCl5pSLzMLSXzU-- From yoshfuji@linux-ipv6.org Sat Sep 25 01:14:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 01:14:14 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P8E9jB031496 for ; Sat, 25 Sep 2004 01:14:10 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id ECDDA33CE7; Sat, 25 Sep 2004 17:14:12 +0900 (JST) Date: Sat, 25 Sep 2004 17:14:12 +0900 (JST) Message-Id: <20040925.171412.75484376.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: laforge@gnumonks.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [6/6]: jenkins hash for neigh From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040925005623.2faf8faf.davem@davemloft.net> References: <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 391 Lines: 13 In article <20040925005623.2faf8faf.davem@davemloft.net> (at Sat, 25 Sep 2004 00:56:23 -0700), "David S. Miller" says: > + if (n->nud_state -= NUD_INCOMPLETE && I guess this is typo of: if (n->nud_state == NUD_INCOMPLETE && Am I wrong? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Sat Sep 25 01:27:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 01:27:15 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P8R9BW032125 for ; Sat, 25 Sep 2004 01:27:10 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id E0C5E33CE7; Sat, 25 Sep 2004 17:27:12 +0900 (JST) Date: Sat, 25 Sep 2004 17:27:12 +0900 (JST) Message-Id: <20040925.172712.30172597.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: laforge@gnumonks.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [6/6]: jenkins hash for neigh From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040925.171412.75484376.yoshfuji@linux-ipv6.org> References: <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925.171412.75484376.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 9458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 530 Lines: 15 In article <20040925.171412.75484376.yoshfuji@linux-ipv6.org> (at Sat, 25 Sep 2004 17:14:12 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > In article <20040925005623.2faf8faf.davem@davemloft.net> (at Sat, 25 Sep 2004 00:56:23 -0700), "David S. Miller" says: > > > > + if (n->nud_state -= NUD_INCOMPLETE && > > I guess this is typo of: > if (n->nud_state == NUD_INCOMPLETE && > > Am I wrong? Sorry, I forgot to state the source; this lives in diff4. --yoshfuji From davem@davemloft.net Sat Sep 25 01:32:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 01:32:43 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P8WS4x032545 for ; Sat, 25 Sep 2004 01:32:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CB7wy-0001Jl-00; Sat, 25 Sep 2004 01:30:36 -0700 Date: Sat, 25 Sep 2004 01:30:36 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040925013036.76586445.davem@davemloft.net> In-Reply-To: <20040925.172712.30172597.yoshfuji@linux-ipv6.org> References: <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925.171412.75484376.yoshfuji@linux-ipv6.org> <20040925.172712.30172597.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__25_Sep_2004_01_30_36_-0700_fNjW+ilCHUf_yLSs" X-archive-position: 9459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4421 Lines: 81 This is a multi-part message in MIME format. --Multipart=_Sat__25_Sep_2004_01_30_36_-0700_fNjW+ilCHUf_yLSs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, 25 Sep 2004 17:27:12 +0900 (JST) YOSHIFUJI Hideaki / =1B$B5HF#1QL@=1B(B wrote: > In article <20040925.171412.75484376.yoshfuji@linux-ipv6.org> (at Sat, 25= Sep 2004 17:14:12 +0900 (JST)), YOSHIFUJI Hideaki / =1B$B5HF#1QL@=1B(B says: >=20 > > In article <20040925005623.2faf8faf.davem@davemloft.net> (at Sat, 25 Se= p 2004 00:56:23 -0700), "David S. Miller" says: > >=20 > >=20 > > > + if (n->nud_state -=3D NUD_INCOMPLETE && > >=20 > > I guess this is typo of: > > if (n->nud_state =3D=3D NUD_INCOMPLETE && > >=20 > > Am I wrong? >=20 > Sorry, I forgot to state the source; this lives in diff4. Good catch, you are correct. Fixed version attached. --Multipart=_Sat__25_Sep_2004_01_30_36_-0700_fNjW+ilCHUf_yLSs Content-Type: application/octet-stream; name="diff4" Content-Disposition: attachment; filename="diff4" Content-Transfer-Encoding: base64 PT09PT0gbmV0L2NvcmUvbmVpZ2hib3VyLmMgMS40NyB2cyBlZGl0ZWQgPT09PT0KLS0tIDEuNDcv bmV0L2NvcmUvbmVpZ2hib3VyLmMJMjAwNC0wOS0yNCAxNjoyMTo0OSAtMDc6MDAKKysrIGVkaXRl ZC9uZXQvY29yZS9uZWlnaGJvdXIuYwkyMDA0LTA5LTI1IDAxOjExOjQ3IC0wNzowMApAQCAtMTEw LDEzICsxMTAsMTMgQEAKIAlyZXR1cm4gKG5ldF9yYW5kb20oKSAlIGJhc2UpICsgKGJhc2UgPj4g MSk7CiB9CiAKLQotc3RhdGljIGludCBuZWlnaF9mb3JjZWRfZ2Moc3RydWN0IG5laWdoX3RhYmxl ICp0YmwpCitzdGF0aWMgaW50IG5laWdoX2ZvcmNlZF9nYyhzdHJ1Y3QgbmVpZ2hfdGFibGUgKnRi bCwgaW50IGdvYWwpCiB7Ci0JaW50IHNocnVuayA9IDA7CisJaW50IHNocnVuayA9IDAsIG51bV9p bmNvbXBsZXRlID0gMCwgcmVhcF9pbmNvbXBsZXRlID0gMDsKIAlpbnQgaTsKIAogCXdyaXRlX2xv Y2tfYmgoJnRibC0+bG9jayk7CityZXNjYW46CiAJZm9yIChpID0gMDsgaSA8PSB0YmwtPmhhc2hf bWFzazsgaSsrKSB7CiAJCXN0cnVjdCBuZWlnaGJvdXIgKm4sICoqbnA7CiAKQEAgLTEyNSwzMCAr MTI1LDQ2IEBACiAJCQkvKiBOZWlnaGJvdXIgcmVjb3JkIG1heSBiZSBkaXNjYXJkZWQgaWY6CiAJ CQkgICAtIG5vYm9keSByZWZlcnMgdG8gaXQuCiAJCQkgICAtIGl0IGlzIG5vdCBwZXJtYW5lbnQK LQkJCSAgIC0gKE5FVyBhbmQgcHJvYmFibHkgd3JvbmcpCisJCQkgICAtIE9uIHRoZSBmaXJzdCBw YXNzIG9mIHRoaXMgc2NhbiwKIAkJCSAgICAgSU5DT01QTEVURSBlbnRyaWVzIGFyZSBrZXB0IGF0 IGxlYXN0IGZvcgogCQkJICAgICBuLT5wYXJtcy0+cmV0cmFuc190aW1lLCBvdGhlcndpc2Ugd2Ug Y291bGQKIAkJCSAgICAgZmxvb2QgbmV0d29yayB3aXRoIHJlc29sdXRpb24gcmVxdWVzdHMuCi0J CQkgICAgIEl0IGlzIG5vdCBjbGVhciwgd2hhdCBpcyBiZXR0ZXIgdGFibGUgb3ZlcmZsb3cKLQkJ CSAgICAgb3IgZmxvb2RpbmcuCiAJCQkgKi8KIAkJCXdyaXRlX2xvY2soJm4tPmxvY2spOwotCQkJ aWYgKGF0b21pY19yZWFkKCZuLT5yZWZjbnQpID09IDEgJiYKLQkJCSAgICAhKG4tPm51ZF9zdGF0 ZSAmIE5VRF9QRVJNQU5FTlQpICYmCi0JCQkgICAgKG4tPm51ZF9zdGF0ZSAhPSBOVURfSU5DT01Q TEVURSB8fAotCQkJICAgICB0aW1lX2FmdGVyKGppZmZpZXMsIG4tPnVzZWQgKyBuLT5wYXJtcy0+ cmV0cmFuc190aW1lKSkpIHsKLQkJCQkqbnAJPSBuLT5uZXh0OwotCQkJCW4tPmRlYWQgPSAxOwot CQkJCXNocnVuawk9IDE7Ci0JCQkJd3JpdGVfdW5sb2NrKCZuLT5sb2NrKTsKLQkJCQluZWlnaF9y ZWxlYXNlKG4pOwotCQkJCWNvbnRpbnVlOworCQkJaWYgKGF0b21pY19yZWFkKCZuLT5yZWZjbnQp ICE9IDEpCisJCQkJZ290byBuZXh0X2VudDsKKworCQkJaWYgKG4tPm51ZF9zdGF0ZSAmIE5VRF9Q RVJNQU5FTlQpCisJCQkJZ290byBuZXh0X2VudDsKKworCQkJaWYgKG4tPm51ZF9zdGF0ZSA9PSBO VURfSU5DT01QTEVURSAmJgorCQkJICAgIHJlYXBfaW5jb21wbGV0ZSA9PSAwICYmCisJCQkgICAg dGltZV9hZnRlcihqaWZmaWVzLAorCQkJCSAgICAgICBuLT51c2VkICsgbi0+cGFybXMtPnJldHJh bnNfdGltZSkpIHsKKwkJCQludW1faW5jb21wbGV0ZSsrOworCQkJCWdvdG8gbmV4dF9lbnQ7CiAJ CQl9CisKKwkJCSpucAk9IG4tPm5leHQ7CisJCQluLT5kZWFkID0gMTsKKwkJCXNocnVuaysrOwor CQkJd3JpdGVfdW5sb2NrKCZuLT5sb2NrKTsKKwkJCW5laWdoX3JlbGVhc2Uobik7CisJCQljb250 aW51ZTsKKworCQluZXh0X2VudDoKIAkJCXdyaXRlX3VubG9jaygmbi0+bG9jayk7CiAJCQlucCA9 ICZuLT5uZXh0OwogCQl9CiAJfQogCisJaWYgKHJlYXBfaW5jb21wbGV0ZSA9PSAwICYmCisJICAg IHNocnVuayA8IGdvYWwgJiYKKwkgICAgKHNocnVuayArIG51bV9pbmNvbXBsZXRlKSA+PSBnb2Fs KSB7CisJCXJlYXBfaW5jb21wbGV0ZSA9IDE7CisJCWdvdG8gcmVzY2FuOworCX0KKwogCXRibC0+ bGFzdF9mbHVzaCA9IGppZmZpZXM7CiAKIAl3cml0ZV91bmxvY2tfYmgoJnRibC0+bG9jayk7CkBA IC0yNjEsNyArMjc3LDkgQEAKIAlpZiAodGJsLT5lbnRyaWVzID4gdGJsLT5nY190aHJlc2gzIHx8 CiAJICAgICh0YmwtPmVudHJpZXMgPiB0YmwtPmdjX3RocmVzaDIgJiYKIAkgICAgIHRpbWVfYWZ0 ZXIobm93LCB0YmwtPmxhc3RfZmx1c2ggKyA1ICogSFopKSkgewotCQlpZiAoIW5laWdoX2ZvcmNl ZF9nYyh0YmwpICYmCisJCWludCBnb2FsID0gdGJsLT5lbnRyaWVzIC0gdGJsLT5nY190aHJlc2gz OworCisJCWlmICghbmVpZ2hfZm9yY2VkX2djKHRibCwgZ29hbCkgJiYKIAkJICAgIHRibC0+ZW50 cmllcyA+IHRibC0+Z2NfdGhyZXNoMykKIAkJCWdvdG8gb3V0OwogCX0K --Multipart=_Sat__25_Sep_2004_01_30_36_-0700_fNjW+ilCHUf_yLSs-- From herbert@gondor.apana.org.au Sat Sep 25 01:32:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 01:32:54 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P8Wekk032553 for ; Sat, 25 Sep 2004 01:32:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CB7yc-0003xo-00; Sat, 25 Sep 2004 18:32:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CB7yS-0007Mb-00; Sat, 25 Sep 2004 18:32:08 +1000 Date: Sat, 25 Sep 2004 18:32:08 +1000 To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: Resend: [NETDRV] Merge register_netdev calls Message-ID: <20040925083208.GA27592@gondor.apana.org.au> References: <20040701111914.GA11120@gondor.apana.org.au> <414F2997.9030901@pobox.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <414F2997.9030901@pobox.com> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 24346 Lines: 1013 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 20, 2004 at 03:03:51PM -0400, Jeff Garzik wrote: > Herbert Xu wrote: > >On Fri, Jun 11, 2004 at 12:08:55PM +1000, herbert wrote: > > > >>In fact it's really making these ISA/MCA probe() functions more > >>like the ones we have for PCI. > > there was a lot of churn and I held off on this patch. > > could you be convinced to rediff and resend (again)? Thanks for reminding me. Here it is diffed against net-drivers-2.6. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=netq ===== drivers/net/3c503.c 1.20 vs edited ===== --- 1.20/drivers/net/3c503.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/3c503.c 2004-09-25 18:29:01 +10:00 @@ -162,12 +162,7 @@ err = do_el2_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -343,6 +338,10 @@ dev->poll_controller = ei_poll; #endif + retval = register_netdev(dev); + if (retval) + goto out1; + if (dev->mem_start) printk("%s: %s - %dkB RAM, 8kB shared mem window at %#6lx-%#6lx.\n", dev->name, ei_status.name, (wordlength+1)<<3, @@ -702,11 +701,8 @@ dev->base_addr = io[this_dev]; dev->mem_end = xcvr[this_dev]; /* low 4bits = xcvr sel. */ if (do_el2_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_el2[found++] = dev; - continue; - } - cleanup_card(dev); + dev_el2[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "3c503.c: No 3c503 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/3c515.c 1.30 vs edited ===== --- 1.30/drivers/net/3c515.c 2004-07-27 04:25:51 +10:00 +++ edited/drivers/net/3c515.c 2004-09-25 18:29:01 +10:00 @@ -373,7 +373,7 @@ #endif /* __ISAPNP__ */ static struct net_device *corkscrew_scan(int unit); -static void corkscrew_setup(struct net_device *dev, int ioaddr, +static int corkscrew_setup(struct net_device *dev, int ioaddr, struct pnp_dev *idev, int card_number); static int corkscrew_open(struct net_device *dev); static void corkscrew_timer(unsigned long arg); @@ -537,10 +537,9 @@ printk(KERN_INFO "3c515 Resource configuration register %#4.4x, DCR %4.4x.\n", inl(ioaddr + 0x2002), inw(ioaddr + 0x2000)); /* irq = inw(ioaddr + 0x2002) & 15; */ /* Use the irq from isapnp */ - corkscrew_setup(dev, ioaddr, idev, cards_found++); SET_NETDEV_DEV(dev, &idev->dev); pnp_cards++; - err = register_netdev(dev); + err = corkscrew_setup(dev, ioaddr, idev, cards_found++); if (!err) return dev; cleanup_card(dev); @@ -556,8 +555,7 @@ printk(KERN_INFO "3c515 Resource configuration register %#4.4x, DCR %4.4x.\n", inl(ioaddr + 0x2002), inw(ioaddr + 0x2000)); - corkscrew_setup(dev, ioaddr, NULL, cards_found++); - err = register_netdev(dev); + err = corkscrew_setup(dev, ioaddr, NULL, cards_found++); if (!err) return dev; cleanup_card(dev); @@ -566,7 +564,7 @@ return NULL; } -static void corkscrew_setup(struct net_device *dev, int ioaddr, +static int corkscrew_setup(struct net_device *dev, int ioaddr, struct pnp_dev *idev, int card_number) { struct corkscrew_private *vp = (struct corkscrew_private *) dev->priv; @@ -689,6 +687,8 @@ dev->get_stats = &corkscrew_get_stats; dev->set_multicast_list = &set_rx_mode; dev->ethtool_ops = &netdev_ethtool_ops; + + return register_netdev(dev); } ===== drivers/net/3c523.c 1.16 vs edited ===== --- 1.16/drivers/net/3c523.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/3c523.c 2004-09-25 18:29:02 +10:00 @@ -572,6 +572,10 @@ dev->flags&=~IFF_MULTICAST; /* Multicast doesn't work */ #endif + retval = register_netdev(dev); + if (retval) + goto err_out; + return 0; err_out: mca_set_adapter_procfn(slot, NULL, NULL); @@ -600,12 +604,7 @@ err = do_elmc_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -1288,12 +1287,9 @@ dev->irq=irq[this_dev]; dev->base_addr=io[this_dev]; if (do_elmc_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_elmc[this_dev] = dev; - found++; - continue; - } - cleanup_card(dev); + dev_elmc[this_dev] = dev; + found++; + continue; } free_netdev(dev); if (io[this_dev]==0) ===== drivers/net/ac3200.c 1.19 vs edited ===== --- 1.19/drivers/net/ac3200.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ac3200.c 2004-09-25 18:29:02 +10:00 @@ -147,12 +147,7 @@ err = do_ac3200_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -284,7 +279,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + retval = register_netdev(dev); + if (retval) + goto out2; return 0; +out2: + if (ei_status.reg0) + iounmap((void *)dev->mem_start); out1: free_irq(dev->irq, dev); out: @@ -402,11 +404,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = mem[this_dev]; /* Currently ignored by driver */ if (do_ac3200_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ac32[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ac32[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "ac3200.c: No ac3200 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/cs89x0.c 1.27 vs edited ===== --- 1.27/drivers/net/cs89x0.c 2004-09-03 19:08:26 +10:00 +++ edited/drivers/net/cs89x0.c 2004-09-25 18:29:02 +10:00 @@ -318,13 +318,7 @@ } if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - outw(PP_ChipID, dev->base_addr + ADD_PORT); - release_region(dev->base_addr, NETCARD_IO_EXTENT); out: free_netdev(dev); printk(KERN_WARNING "cs89x0: no cs8900 or cs8920 detected. Be sure to disable PnP with SETUP\n"); @@ -734,7 +728,13 @@ printk("\n"); if (net_debug) printk("cs89x0_probe1() successful\n"); + + retval = register_netdev(dev); + if (retval) + goto out3; return 0; +out3: + outw(PP_ChipID, dev->base_addr + ADD_PORT); out2: release_region(ioaddr & ~3, NETCARD_IO_EXTENT); out1: @@ -1831,13 +1831,6 @@ if (ret) goto out; - if (register_netdev(dev) != 0) { - printk(KERN_ERR "cs89x0.c: No card found at 0x%x\n", io); - ret = -ENXIO; - outw(PP_ChipID, dev->base_addr + ADD_PORT); - release_region(dev->base_addr, NETCARD_IO_EXTENT); - goto out; - } dev_cs89x0 = dev; return 0; out: ===== drivers/net/e2100.c 1.18 vs edited ===== --- 1.18/drivers/net/e2100.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/e2100.c 2004-09-25 18:29:02 +10:00 @@ -161,12 +161,7 @@ err = do_e2100_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -278,6 +273,9 @@ #endif NS8390_init(dev, 0); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, E21_IO_EXTENT); @@ -445,11 +443,8 @@ dev->mem_start = mem[this_dev]; dev->mem_end = xcvr[this_dev]; /* low 4bits = xcvr sel. */ if (do_e2100_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_e21[found++] = dev; - continue; - } - cleanup_card(dev); + dev_e21[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "e2100.c: No E2100 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/eepro.c 1.25 vs edited ===== --- 1.25/drivers/net/eepro.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/eepro.c 2004-09-25 18:29:03 +10:00 @@ -596,12 +596,7 @@ err = do_eepro_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - release_region(dev->base_addr, EEPRO_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -747,6 +742,7 @@ struct eepro_local *lp; enum iftype { AUI=0, BNC=1, TPE=2 }; int ioaddr = dev->base_addr; + int err; /* Grab the region so we can find another board if autoIRQ fails. */ if (!request_region(ioaddr, EEPRO_IO_EXTENT, DRV_NAME)) { @@ -856,10 +852,16 @@ /* reset 82595 */ eepro_reset(ioaddr); + + err = register_netdev(dev); + if (err) + goto err; return 0; exit: + err = -ENODEV; +err: release_region(dev->base_addr, EEPRO_IO_EXTENT); - return -ENODEV; + return err; } /* Open/initialize the board. This is called (in the current kernel) @@ -1756,11 +1758,8 @@ dev->irq = irq[i]; if (do_eepro_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_eepro[n_eepro++] = dev; - continue; - } - release_region(dev->base_addr, EEPRO_IO_EXTENT); + dev_eepro[n_eepro++] = dev; + continue; } free_netdev(dev); break; ===== drivers/net/eexpress.c 1.19 vs edited ===== --- 1.19/drivers/net/eexpress.c 2004-07-11 19:23:27 +10:00 +++ edited/drivers/net/eexpress.c 2004-09-25 18:29:03 +10:00 @@ -436,11 +436,8 @@ netdev_boot_setup_check(dev); err = do_express_probe(dev); - if (!err) { - err = register_netdev(dev); - if (!err) - return dev; - } + if (!err) + return dev; free_netdev(dev); return ERR_PTR(err); } @@ -1205,7 +1202,8 @@ dev->set_multicast_list = &eexp_set_multicast; dev->tx_timeout = eexp_timeout; dev->watchdog_timeo = 2*HZ; - return 0; + + return register_netdev(dev); } /* @@ -1716,7 +1714,7 @@ break; printk(KERN_NOTICE "eexpress.c: Module autoprobe not recommended, give io=xx.\n"); } - if (do_express_probe(dev) == 0 && register_netdev(dev) == 0) { + if (do_express_probe(dev) == 0) { dev_eexp[this_dev] = dev; found++; continue; ===== drivers/net/es3210.c 1.13 vs edited ===== --- 1.13/drivers/net/es3210.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/es3210.c 2004-09-25 18:29:04 +10:00 @@ -176,12 +176,7 @@ err = do_es_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -304,6 +299,10 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; out1: free_irq(dev->irq, dev); @@ -439,11 +438,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = mem[this_dev]; if (do_es_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_es3210[found++] = dev; - continue; - } - cleanup_card(dev); + dev_es3210[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "es3210.c: No es3210 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/hp.c 1.14 vs edited ===== --- 1.14/drivers/net/hp.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/hp.c 2004-09-25 18:29:05 +10:00 @@ -123,12 +123,7 @@ err = do_hp_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -227,7 +222,12 @@ ei_status.block_output = &hp_block_output; hp_init_card(dev); + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + free_irq(dev->irq, dev); out: release_region(ioaddr, HP_IO_EXTENT); return retval; @@ -432,11 +432,8 @@ dev->irq = irq[this_dev]; dev->base_addr = io[this_dev]; if (do_hp_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_hp[found++] = dev; - continue; - } - cleanup_card(dev); + dev_hp[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "hp.c: No HP card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/eth16i.c 1.19 vs edited ===== --- 1.19/drivers/net/eth16i.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/eth16i.c 2004-09-25 18:29:04 +10:00 @@ -473,13 +473,7 @@ err = do_eth16i_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - free_irq(dev->irq, dev); - release_region(dev->base_addr, ETH16I_IO_EXTENT); out: free_netdev(dev); return ERR_PTR(err); @@ -569,7 +563,13 @@ dev->tx_timeout = eth16i_timeout; dev->watchdog_timeo = TX_TIMEOUT; spin_lock_init(&lp->lock); + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + free_irq(dev->irq, dev); out: release_region(ioaddr, ETH16I_IO_EXTENT); return retval; @@ -1462,12 +1462,8 @@ } if (do_eth16i_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_eth16i[found++] = dev; - continue; - } - free_irq(dev->irq, dev); - release_region(dev->base_addr, ETH16I_IO_EXTENT); + dev_eth16i[found++] = dev; + continue; } printk(KERN_WARNING "eth16i.c No Eth16i card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/hp-plus.c 1.17 vs edited ===== --- 1.17/drivers/net/hp-plus.c 2004-07-28 15:34:08 +10:00 +++ edited/drivers/net/hp-plus.c 2004-09-25 18:29:05 +10:00 @@ -159,12 +159,7 @@ err = do_hpp_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -271,6 +266,9 @@ /* Leave the 8390 and HP chip reset. */ outw(inw(ioaddr + HPP_OPTION) & ~EnableIRQ, ioaddr + HPP_OPTION); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, HP_IO_EXTENT); @@ -463,11 +461,8 @@ dev->irq = irq[this_dev]; dev->base_addr = io[this_dev]; if (do_hpp_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_hpp[found++] = dev; - continue; - } - cleanup_card(dev); + dev_hpp[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "hp-plus.c: No HP-Plus card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/isa-skeleton.c 1.13 vs edited ===== --- 1.13/drivers/net/isa-skeleton.c 2004-05-21 07:16:23 +10:00 +++ edited/drivers/net/isa-skeleton.c 2004-09-25 18:29:06 +10:00 @@ -176,12 +176,7 @@ err = do_netcard_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -316,7 +311,15 @@ dev->tx_timeout = &net_tx_timeout; dev->watchdog_timeo = MY_TX_TIMEOUT; + + err = register_netdev(dev); + if (err) + goto out2; return 0; +out2: +#ifdef jumpered_dma + free_dma(dev->dma); +#endif out1: #ifdef jumpered_interrupts free_irq(dev->irq, dev); @@ -691,11 +694,8 @@ dev->dma = dma; dev->mem_start = mem; if (do_netcard_probe(dev) == 0) { - if (register_netdev(dev) == 0) - this_device = dev; - return 0; - } - cleanup_card(dev); + this_device = dev; + return 0; } free_netdev(dev); return -ENXIO; ===== drivers/net/ne.c 1.24 vs edited ===== --- 1.24/drivers/net/ne.c 2004-09-17 17:07:01 +10:00 +++ edited/drivers/net/ne.c 2004-09-25 18:29:08 +10:00 @@ -229,12 +229,7 @@ err = do_ne_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -534,8 +529,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + ret = register_netdev(dev); + if (ret) + goto out_irq; return 0; +out_irq: + free_irq(dev->irq, dev); err_out: release_region(ioaddr, NE_IO_EXTENT); return ret; @@ -826,11 +827,8 @@ dev->mem_end = bad[this_dev]; dev->base_addr = io[this_dev]; if (do_ne_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ne[found++] = dev; + continue; } free_netdev(dev); if (found) ===== drivers/net/lne390.c 1.14 vs edited ===== --- 1.14/drivers/net/lne390.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/lne390.c 2004-09-25 18:29:07 +10:00 @@ -168,12 +168,7 @@ err = do_lne390_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -307,7 +302,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + ret = register_netdev(dev); + if (ret) + goto unmap; return 0; +unmap: + if (ei_status.reg0) + iounmap((void *)dev->mem_start); cleanup: free_irq(dev->irq, dev); return ret; @@ -436,11 +438,8 @@ dev->base_addr = io[this_dev]; dev->mem_start = mem[this_dev]; if (do_lne390_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_lne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_lne[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "lne390.c: No LNE390 card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/ne2.c 1.17 vs edited ===== --- 1.17/drivers/net/ne2.c 2004-07-17 03:32:45 +10:00 +++ edited/drivers/net/ne2.c 2004-09-25 18:29:09 +10:00 @@ -301,12 +301,7 @@ err = do_ne2_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -517,7 +512,14 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); + + retval = register_netdev(dev); + if (retval) + goto out1; return 0; +out1: + mca_set_adapter_procfn( ei_status.priv, NULL, NULL); + free_irq(dev->irq, dev); out: release_region(base_addr, NE_IO_EXTENT); return retval; @@ -798,11 +800,8 @@ dev->mem_end = bad[this_dev]; dev->base_addr = io[this_dev]; if (do_ne2_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ne[found++] = dev; + continue; } free_netdev(dev); break; ===== drivers/net/lance.c 1.23 vs edited ===== --- 1.23/drivers/net/lance.c 2004-07-27 04:28:14 +10:00 +++ edited/drivers/net/lance.c 2004-09-25 18:29:07 +10:00 @@ -355,11 +355,8 @@ dev->base_addr = io[this_dev]; dev->dma = dma[this_dev]; if (do_lance_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_lance[found++] = dev; - continue; - } - cleanup_card(dev); + dev_lance[found++] = dev; + continue; } free_netdev(dev); break; @@ -447,12 +444,7 @@ err = do_lance_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -723,6 +715,9 @@ dev->tx_timeout = lance_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; + err = register_netdev(dev); + if (err) + goto out_dma; return 0; out_dma: if (dev->dma != 4) ===== drivers/net/ne-h8300.c 1.4 vs edited ===== --- 1.4/drivers/net/ne-h8300.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/ne-h8300.c 2004-09-25 18:29:08 +10:00 @@ -180,12 +180,7 @@ err = do_ne_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -325,8 +320,13 @@ dev->poll_controller = ei_poll; #endif NS8390_init(dev, 0); - return 0; + ret = register_netdev(dev); + if (ret) + goto out_irq; + return 0; +out_irq: + free_irq(dev->irq, dev); err_out: release_region(ioaddr, NE_IO_EXTENT); return ret; @@ -633,11 +633,8 @@ err = init_reg_offset(dev, dev->base_addr); if (!err) { if (do_ne_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ne[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ne[found++] = dev; + continue; } } free_netdev(dev); ===== drivers/net/hp100.c 1.30 vs edited ===== --- 1.30/drivers/net/hp100.c 2004-08-27 17:02:39 +10:00 +++ edited/drivers/net/hp100.c 2004-09-25 18:29:06 +10:00 @@ -411,12 +411,7 @@ if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; - out1: - release_region(dev->base_addr, HP100_REGION_SIZE); out: free_netdev(dev); return ERR_PTR(err); @@ -770,11 +765,22 @@ printk("Warning! Link down.\n"); } + err = register_netdev(dev); + if (err) + goto out3; + return 0; +out3: + if (local_mode == 1) + pci_free_consistent(lp->pci_dev, MAX_RINGSIZE + 0x0f, + lp->page_vaddr_algn, + virt_to_whatever(dev, lp->page_vaddr_algn)); + if (mem_ptr_virt) + iounmap(mem_ptr_virt); out2: release_region(ioaddr, HP100_REGION_SIZE); out1: - return -ENODEV; + return err; } /* This procedure puts the card into a stable init state */ @@ -2868,18 +2874,12 @@ if (err) goto out1; - err = register_netdev(dev); - if (err) - goto out2; - #ifdef HP100_DEBUG printk("hp100: %s: EISA adapter found at 0x%x\n", dev->name, dev->base_addr); #endif gendev->driver_data = dev; return 0; - out2: - release_region(dev->base_addr, HP100_REGION_SIZE); out1: free_netdev(dev); return err; @@ -2944,17 +2944,12 @@ err = hp100_probe1(dev, ioaddr, HP100_BUS_PCI, pdev); if (err) goto out1; - err = register_netdev(dev); - if (err) - goto out2; #ifdef HP100_DEBUG printk("hp100: %s: PCI adapter found at 0x%x\n", dev->name, ioaddr); #endif pci_set_drvdata(pdev, dev); return 0; - out2: - release_region(dev->base_addr, HP100_REGION_SIZE); out1: free_netdev(dev); out0: @@ -3025,15 +3020,9 @@ SET_MODULE_OWNER(dev); err = hp100_isa_probe(dev, hp100_port[i]); - if (!err) { - err = register_netdev(dev); - if (!err) - hp100_devlist[cards++] = dev; - else - release_region(dev->base_addr, HP100_REGION_SIZE); - } - - if (err) + if (!err) + hp100_devlist[cards++] = dev; + else free_netdev(dev); } ===== drivers/net/smc-ultra.c 1.22 vs edited ===== --- 1.22/drivers/net/smc-ultra.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/smc-ultra.c 2004-09-25 18:29:09 +10:00 @@ -195,12 +195,7 @@ err = do_ultra_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -321,6 +316,9 @@ #endif NS8390_init(dev, 0); + retval = register_netdev(dev); + if (retval) + goto out; return 0; out: release_region(ioaddr, ULTRA_IO_EXTENT); @@ -579,11 +577,8 @@ dev->irq = irq[this_dev]; dev->base_addr = io[this_dev]; if (do_ultra_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_ultra[found++] = dev; - continue; - } - cleanup_card(dev); + dev_ultra[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "smc-ultra.c: No SMC Ultra card found (i/o = 0x%x).\n", io[this_dev]); ===== drivers/net/wd.c 1.19 vs edited ===== --- 1.19/drivers/net/wd.c 2004-05-23 03:40:55 +10:00 +++ edited/drivers/net/wd.c 2004-09-25 18:29:09 +10:00 @@ -148,12 +148,7 @@ err = do_wd_probe(dev); if (err) goto out; - err = register_netdev(dev); - if (err) - goto out1; return dev; -out1: - cleanup_card(dev); out: free_netdev(dev); return ERR_PTR(err); @@ -163,6 +158,7 @@ static int __init wd_probe1(struct net_device *dev, int ioaddr) { int i; + int err; int checksum = 0; int ancient = 0; /* An old card without config registers. */ int word16 = 0; /* 0 = 8 bit, 1 = 16 bit */ @@ -349,7 +345,10 @@ outb(inb(ioaddr+4)|0x80, ioaddr+4); #endif - return 0; + err = register_netdev(dev); + if (err) + free_irq(dev->irq, dev); + return err; } static int @@ -519,11 +518,8 @@ dev->mem_start = mem[this_dev]; dev->mem_end = mem_end[this_dev]; if (do_wd_probe(dev) == 0) { - if (register_netdev(dev) == 0) { - dev_wd[found++] = dev; - continue; - } - cleanup_card(dev); + dev_wd[found++] = dev; + continue; } free_netdev(dev); printk(KERN_WARNING "wd.c: No wd80x3 card found (i/o = 0x%x).\n", io[this_dev]); --7AUc2qLy4jB3hD7Z-- From laforge@gnumonks.org Sat Sep 25 02:09:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 02:09:54 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8P99le3001776 for ; Sat, 25 Sep 2004 02:09:48 -0700 Received: from dsl-082-082-101-005.arcor-ip.net ([82.82.101.5] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CB8Yh-0007fL-C5; Sat, 25 Sep 2004 11:09:35 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CB8Yf-0004XP-Ln; Sat, 25 Sep 2004 11:09:33 +0200 Date: Sat, 25 Sep 2004 11:09:33 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20040925090933.GU3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVx8OOgYiG4KXJJB" Content-Disposition: inline In-Reply-To: <20040925005623.2faf8faf.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 2231 Lines: 63 --EVx8OOgYiG4KXJJB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 25, 2004 at 12:56:23AM -0700, David S. Miller wrote: > > I'll inclue it in my next round of kernel builds and give it > > some testing. >=20 > Thanks. Please note that I guess I won't have any results until late Sunday/Monday. > 4) The controversial/RFC patch, dorking with neigh_forced_gc() >=20 > So let's discuss #4. It is the first idea I had to combat the > "problem", but honestly right now I am beginning to think that > the real solution is to simply remove the INCOMPLETE checks > altogether. >=20 > Neighbours are a sub-cache of the routing cache. Therefore when > a neigh entry has a singular refcount, no routing cache entry > points to it. No routing cache entry, we're not sending packets > to that neighbour any time soon, so there is no reason (especially > during strong pressure) to hold onto such entries. I am sure this is valid for IPv4 and IPv6. How about other users of the neighbour cache, do they share this assumption? I have to admit that I never looked throgh the ATM or=20 > Agree or disagree? Regardless, I'd be interested how effective > your stress case is with patch #4 and my new suggestion which > is just to remove the: I'll do tests with and without INCOMPLETE check. No results until late Sunday/Monday, as indicated above. [yes, I noticed your corrected version of diff4] --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --EVx8OOgYiG4KXJJB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBVTXNXaXGVTD0i/8RAksRAJoCT+544hPST+3j1NZaU9tq8D+DyACgsIx7 cdoBmQZWQoLgWSF8pVT8Z04= =3kz5 -----END PGP SIGNATURE----- --EVx8OOgYiG4KXJJB-- From steve@souterrain.chygwyn.com Sat Sep 25 06:33:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 06:33:36 -0700 (PDT) Received: from souterrain.chygwyn.com (souterrain.chygwyn.com [194.39.143.233]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8PDXUTP016044 for ; Sat, 25 Sep 2004 06:33:31 -0700 Received: from souterrain.chygwyn.com ([127.0.0.1]) by souterrain.chygwyn.com with esmtp (Exim 4.41) id 1CBCgO-0002wV-4O; Sat, 25 Sep 2004 14:33:48 +0100 Received: (from steve@localhost) by souterrain.chygwyn.com (8.13.0/8.13.0/Submit) id i8PDXgmN011314; Sat, 25 Sep 2004 14:33:42 +0100 Date: Sat, 25 Sep 2004 14:33:42 +0100 From: Steven Whitehouse To: Harald Welte Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20040925133342.GA11292@souterrain.chygwyn.com> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040925090933.GU3236@sunbeam.de.gnumonks.org> User-Agent: Mutt/1.4.1i Organization: ChyGwyn Limited X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: netdev@oss.sgi.com, davem@davemloft.net, laforge@gnumonks.org X-SA-Exim-Mail-From: steve@souterrain.chygwyn.com X-SA-Exim-Scanned: No (on souterrain.chygwyn.com); SAEximRunCond expanded to false X-archive-position: 9462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: steve@chygwyn.com Precedence: bulk X-list: netdev Content-Length: 1217 Lines: 27 Hi, On Sat, Sep 25, 2004 at 11:09:33AM +0200, Harald Welte wrote: > On Sat, Sep 25, 2004 at 12:56:23AM -0700, David S. Miller wrote: > > So let's discuss #4. It is the first idea I had to combat the > > "problem", but honestly right now I am beginning to think that > > the real solution is to simply remove the INCOMPLETE checks > > altogether. > > > > Neighbours are a sub-cache of the routing cache. Therefore when > > a neigh entry has a singular refcount, no routing cache entry > > points to it. No routing cache entry, we're not sending packets > > to that neighbour any time soon, so there is no reason (especially > > during strong pressure) to hold onto such entries. > > I am sure this is valid for IPv4 and IPv6. How about other users of the > neighbour cache, do they share this assumption? I have to admit that I > never looked throgh the ATM or > I cannot see this being any problem for DECnet at all.... the entry you most want to hold on to is the entry for the default router of which there will be a max of one per interface. This applies only in end node mode and we hold a ref count to it anyway, so that it should have the same effect as the routing cache entry holding a ref, Steve. From romieu@fr.zoreil.com Sat Sep 25 12:44:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 12:44:27 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8PJiFU4032238 for ; Sat, 25 Sep 2004 12:44:16 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8PJe5vr013084; Sat, 25 Sep 2004 21:40:05 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8PJe1sb013073; Sat, 25 Sep 2004 21:40:01 +0200 Date: Sat, 25 Sep 2004 21:40:01 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, Jon Mason , linux-kernel@vger.kernel.org Subject: 8139C+/8169 and suspend mode Message-ID: <20040925194000.GA11363@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 641 Lines: 16 Does anyone have positive experience with suspend mode on the aforementionned chipset ? Rationale: Jon noticed that the r8169 driver did not correctly set the dirty Rx ring index when the driver tries to reset the chipset (rtl8169_hw_start) after a Tx timeout recovery. The chipset is told where the Tx/Rx rings start but the software driver works with a badly inaccurate (rx_cur, rx_dirty) pair. If I am not mistaken, the same pattern applies to the resume function in the r8169 driver and in the 8139cp driver. So, despite me thinking that the poor thing is in a bad state, is there anybody who actually succeeds using it ? -- Ueimor From ja@ssi.bg Sat Sep 25 13:07:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 13:07:38 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8PK7SWa001171 for ; Sat, 25 Sep 2004 13:07:30 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8PK9BR5031641; Sat, 25 Sep 2004 23:09:12 +0300 Date: Sat, 25 Sep 2004 23:09:11 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [IPv4]: More fib_alias insertion fixes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 3165 Lines: 118 Hello, some fib alias fixes: - modify fib_find_alias to stop before the desired alias, even if reaching different TOS. If no alias is found we have to append at end of fn_alias. - properly prepend/append new alias with same prefix/tos/prio - use list_for_each_entry_continue Signed-off-by: Julian Anastasov diff -ur v2.6.9-rc2-bk10/linux/net/ipv4/fib_hash.c linux/net/ipv4/fib_hash.c --- v2.6.9-rc2-bk10/linux/net/ipv4/fib_hash.c 2004-09-25 22:44:31.000000000 +0300 +++ linux/net/ipv4/fib_hash.c 2004-09-25 22:45:06.580902744 +0300 @@ -431,24 +431,20 @@ return NULL; } -/* Return the first fib alias matching TOS with - * priority less than or equal to PRIO. - */ +/* Return the first fib alias below TOS and after PRIO thresholds */ static struct fib_alias *fib_find_alias(struct fib_node *fn, u8 tos, u32 prio) { if (fn) { struct list_head *head = &fn->fn_alias; - struct fib_alias *fa, *prev_fa; + struct fib_alias *fa; - prev_fa = NULL; list_for_each_entry(fa, head, fa_list) { - if (fa->fa_tos != tos) + if (fa->fa_tos > tos) continue; - prev_fa = fa; - if (prio <= fa->fa_info->fib_priority) - break; + if (fa->fa_info->fib_priority >= prio || + fa->fa_tos < tos) + return fa; } - return prev_fa; } return NULL; } @@ -461,6 +457,7 @@ struct fib_node *new_f, *f; struct fib_alias *fa, *new_fa; struct fn_zone *fz; + struct list_head *ins_before = NULL; struct fib_info *fi; int z = r->rtm_dst_len; int type = r->rtm_type; @@ -505,9 +502,12 @@ * and we need to allocate a new one of those as well. */ - if (fa && + if (fa) + ins_before = &fa->fa_list; + + if (fa && fa->fa_tos == tos && fa->fa_info->fib_priority == fi->fib_priority) { - struct fib_alias *fa_orig; + struct list_head *fa_head; err = -EEXIST; if (n->nlmsg_flags & NLM_F_EXCL) @@ -536,8 +536,9 @@ * uses the same scope, type, and nexthop * information. */ - fa_orig = fa; - list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { + fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list); + fa_head = &f->fn_alias; + list_for_each_entry_continue(fa, fa_head, fa_list) { if (fa->fa_tos != tos) break; if (fa->fa_info->fib_priority != fi->fib_priority) @@ -546,9 +547,9 @@ fa->fa_scope == r->rtm_scope && fa->fa_info == fi) goto out; + if (n->nlmsg_flags & NLM_F_APPEND) + ins_before = fa->fa_list.next; } - if (!(n->nlmsg_flags & NLM_F_APPEND)) - fa = fa_orig; } err = -ENOENT; @@ -585,8 +586,7 @@ write_lock_bh(&fib_hash_lock); if (new_f) fib_insert_node(fz, new_f); - list_add(&new_fa->fa_list, - (fa ? &fa->fa_list : &f->fn_alias)); + list_add_tail(&new_fa->fa_list, ins_before? : &f->fn_alias); write_unlock_bh(&fib_hash_lock); if (new_f) @@ -637,8 +637,9 @@ return -ESRCH; fa_to_delete = NULL; - fa_head = fa->fa_list.prev; - list_for_each_entry(fa, fa_head, fa_list) { + fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list); + fa_head = &f->fn_alias; + list_for_each_entry_continue(fa, fa_head, fa_list) { struct fib_info *fi = fa->fa_info; if (fa->fa_tos != tos) From davem@davemloft.net Sat Sep 25 17:50:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 17:50:26 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8Q0oHJr011365 for ; Sat, 25 Sep 2004 17:50:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CBNCs-0002l4-00; Sat, 25 Sep 2004 17:48:02 -0700 Date: Sat, 25 Sep 2004 17:48:02 -0700 From: "David S. Miller" To: Steven Whitehouse Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040925174802.43c86665.davem@davemloft.net> In-Reply-To: <20040925133342.GA11292@souterrain.chygwyn.com> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> <20040925133342.GA11292@souterrain.chygwyn.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1380 Lines: 27 On Sat, 25 Sep 2004 14:33:42 +0100 Steven Whitehouse wrote: > On Sat, Sep 25, 2004 at 11:09:33AM +0200, Harald Welte wrote: > > On Sat, Sep 25, 2004 at 12:56:23AM -0700, David S. Miller wrote: > > > So let's discuss #4. It is the first idea I had to combat the > > > "problem", but honestly right now I am beginning to think that > > > the real solution is to simply remove the INCOMPLETE checks > > > altogether. > > > > > > Neighbours are a sub-cache of the routing cache. Therefore when > > > a neigh entry has a singular refcount, no routing cache entry > > > points to it. No routing cache entry, we're not sending packets > > > to that neighbour any time soon, so there is no reason (especially > > > during strong pressure) to hold onto such entries. > > > > I am sure this is valid for IPv4 and IPv6. How about other users of the > > neighbour cache, do they share this assumption? I have to admit that I > > never looked throgh the ATM or > > > I cannot see this being any problem for DECnet at all.... the entry you > most want to hold on to is the entry for the default router of which > there will be a max of one per interface. This applies only in end node > mode and we hold a ref count to it anyway, so that it should have the > same effect as the routing cache entry holding a ref, And ATM clip is for ipv4's routing layer too so... From davem@davemloft.net Sat Sep 25 20:16:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 20:16:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8Q3GiJd015226 for ; Sat, 25 Sep 2004 20:16:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CBPUX-0004Dh-00; Sat, 25 Sep 2004 20:14:25 -0700 Date: Sat, 25 Sep 2004 20:14:25 -0700 From: "David S. Miller" To: Julian Anastasov Cc: netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes Message-Id: <20040925201425.16fbcb6c.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2664 Lines: 83 On Sat, 25 Sep 2004 23:09:11 +0300 (EEST) Julian Anastasov wrote: > - modify fib_find_alias to stop before the desired alias, even > if reaching different TOS. If no alias is found we have to append > at end of fn_alias. > > - properly prepend/append new alias with same prefix/tos/prio > > - use list_for_each_entry_continue > > Signed-off-by: Julian Anastasov Two things: 1) I applied a version of the list_for_each_entry_continue fix I got privately from Alexey, can you repatch relative to that? It is included below. 2) The fib_alias list is not meant at all to be sorted by TOS value. Within a TOS it _is_ sorted by priority. This was intentional, and I believe your changes assume I meant to keep the "aliases ordered by TOS" property. I did not. Please give test cases when posting fixes of this nature. I wouldn't have to guess about #2 if you gave a bunch of "ip route foo" commands that gave behavior you think is incorrect. Thanks. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/25 19:47:58-07:00 kuznet@ms2.inr.ac.ru # [IPV4]: Fix fa_list walking in fib_hash.c # # Prevent accidently referencing f->fn_alias list # head as a real fib_alias object. # # Signed-off-by: David S. Miller # # net/ipv4/fib_hash.c # 2004/09/25 19:47:27-07:00 kuznet@ms2.inr.ac.ru +4 -4 # [IPV4]: Fix fa_list walking in fib_hash.c # # Prevent accidently referencing f->fn_alias list # head as a real fib_alias object. # # Signed-off-by: David S. Miller # diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c --- a/net/ipv4/fib_hash.c 2004-09-25 19:54:08 -07:00 +++ b/net/ipv4/fib_hash.c 2004-09-25 19:54:08 -07:00 @@ -537,7 +537,8 @@ * information. */ fa_orig = fa; - list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { + fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list); + list_for_each_entry_continue(fa, &f->fn_alias, fa_list) { if (fa->fa_tos != tos) break; if (fa->fa_info->fib_priority != fi->fib_priority) @@ -611,7 +612,6 @@ struct fn_hash *table = (struct fn_hash*)tb->tb_data; struct fib_node *f; struct fib_alias *fa, *fa_to_delete; - struct list_head *fa_head; int z = r->rtm_dst_len; struct fn_zone *fz; u32 key; @@ -637,8 +637,8 @@ return -ESRCH; fa_to_delete = NULL; - fa_head = fa->fa_list.prev; - list_for_each_entry(fa, fa_head, fa_list) { + fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list); + list_for_each_entry_continue(fa, &f->fn_alias, fa_list) { struct fib_info *fi = fa->fa_info; if (fa->fa_tos != tos) From davem@davemloft.net Sat Sep 25 20:33:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 20:33:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8Q3XSro019122 for ; Sat, 25 Sep 2004 20:33:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CBPkr-0004Eu-00; Sat, 25 Sep 2004 20:31:17 -0700 Date: Sat, 25 Sep 2004 20:31:16 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040925203116.4e6f9b06.davem@davemloft.net> In-Reply-To: <20040925090933.GU3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2205 Lines: 52 On Sat, 25 Sep 2004 11:09:33 +0200 Harald Welte wrote: > I am sure this is valid for IPv4 and IPv6. How about other users of the > neighbour cache, do they share this assumption? I have to admit that I > never looked throgh the ATM or As Steven Whitehouse mentioned for DecNET and I mentioned for ATM clip, this is valid. So consider the following as well. Any time we send to a neighbour we will generate a routing cache entry, 'dst', and we will stick it to skb->dst. This dst will have neighbour, and the SKB will sit in the neighbour SKB queue until the neighbour entry is resolved or it times out. Therefore I think that test for INCOMPLETE in neigh_force_gc() is even more rediculious. Assuming that your test case runs fine with it, what I think we should do is just forget about my 'diff4' changes to neigh_forced_gc(), and instead remove that INCOMPLETE test entirely. Then, neigh_forced_gc() will simply remove all non-permanent entries with refcount of 1. Finally, we could think about possibly doing the following: 1) Parameterizing neigh_forced_gc() so that it purges say "N" entries each run instead of scanning the entire hash table. Perhaps some fraction of tbl->entries 2) Look seriously into making more formal the relationship between the routing caches and neighbour cache. What I mean by #2 is the following. We know that the worst case neighbour cache usage for a table is the size of the routing cache. No routing cache entry, no reference to a corresponding neighbour entry. In this sense, all of these gc_thresh* values are superfluous. What do people think about this? As a side note, I checked BSD just for the usual shits and grins, and they make no limits on ARP table growth. Each routing table entry may allocate a ARP resolution structure. It is not exactly stupid, frankly. Really, if we got rid of all of this garbage collection crap we could delete even that annoying message spit out by net/ipv4/route.c when we run into the problems that made us work on these changes to begin with. At the very least, we should have a threshold to run forced GC but failures to GC purge should not cause neigh_create() failures. From ja@ssi.bg Sat Sep 25 23:14:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 25 Sep 2004 23:14:25 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8Q6EELD022539 for ; Sat, 25 Sep 2004 23:14:16 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8Q6FwKj008379; Sun, 26 Sep 2004 09:15:59 +0300 Date: Sun, 26 Sep 2004 09:15:58 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes In-Reply-To: <20040925201425.16fbcb6c.davem@davemloft.net> Message-ID: References: <20040925201425.16fbcb6c.davem@davemloft.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-509301932-1096179358=:1151" X-archive-position: 9468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 6011 Lines: 129 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. --1607745702-509301932-1096179358=:1151 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, On Sat, 25 Sep 2004, David S. Miller wrote: > 2) The fib_alias list is not meant at all to be sorted by TOS > value. Within a TOS it _is_ sorted by priority. This was > intentional, and I believe your changes assume I meant to > keep the "aliases ordered by TOS" property. I did not. But it still needs one exception: the entries with TOS 0 must be at tail to allow fn_hash_lookup to match by TOS. With random TOS insertion this is not guaranteed, the entries with TOS=0 (wildcard) will match before the others. So, I fixed it to allow the TOS subchains to be in any order but always before the subchain with TOS 0. > Please give test cases when posting fixes of this nature. > I wouldn't have to guess about #2 if you gave a bunch of > "ip route foo" commands that gave behavior you think is > incorrect. ok, I'm attaching 3 files: new diff, test script to add/del entries in custom table and its output in another file (after applying the patch). I'm using: ./rt.sh start ./rt.sh stop Regards -- Julian Anastasov --1607745702-509301932-1096179358=:1151 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fib_ins2.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: fib_alias insertion fixes Content-Disposition: attachment; filename="fib_ins2.diff" ZGlmZiAtdXIgdjIuNi45LXJjMi1iazEwL2xpbnV4L25ldC9pcHY0L2ZpYl9o YXNoLmMgbGludXgvbmV0L2lwdjQvZmliX2hhc2guYw0KLS0tIHYyLjYuOS1y YzItYmsxMC9saW51eC9uZXQvaXB2NC9maWJfaGFzaC5jCTIwMDQtMDktMjYg MDg6NTY6MTkuMDAwMDAwMDAwICswMzAwDQorKysgbGludXgvbmV0L2lwdjQv ZmliX2hhc2guYwkyMDA0LTA5LTI2IDA4OjU2OjMzLjMxMzc3MDM0NCArMDMw MA0KQEAgLTQzMyw2ICs0MzMsNyBAQA0KIA0KIC8qIFJldHVybiB0aGUgZmly c3QgZmliIGFsaWFzIG1hdGNoaW5nIFRPUyB3aXRoDQogICogcHJpb3JpdHkg bGVzcyB0aGFuIG9yIGVxdWFsIHRvIFBSSU8uDQorICogQWxzbywgY29udHJv bCB0aGUgb3JkZXJpbmcgYnkgVE9TOiBrZWVwIHRoZSBlbnRyaWVzIHdpdGgg VE9TPTAgYXQgdGFpbC4NCiAgKi8NCiBzdGF0aWMgc3RydWN0IGZpYl9hbGlh cyAqZmliX2ZpbmRfYWxpYXMoc3RydWN0IGZpYl9ub2RlICpmbiwgdTggdG9z LCB1MzIgcHJpbykNCiB7DQpAQCAtNDQzLDEyICs0NDQsMTYgQEANCiAJCXBy ZXZfZmEgPSBOVUxMOw0KIAkJbGlzdF9mb3JfZWFjaF9lbnRyeShmYSwgaGVh ZCwgZmFfbGlzdCkgew0KIAkJCWlmIChmYS0+ZmFfdG9zICE9IHRvcykNCi0J CQkJY29udGludWU7DQorCQkJew0KKwkJCQlpZiAoIXByZXZfZmEgJiYgZmEt PmZhX3RvcykNCisJCQkJCWNvbnRpbnVlOw0KKwkJCQkvKiBTdG9wIGF0IFRP UyAwIG9yIGFmdGVyIGVudHJpZXMgZnJvbSBvdXIgVE9TICovDQorCQkJCXJl dHVybiBmYTsNCisJCQl9DQogCQkJcHJldl9mYSA9IGZhOw0KIAkJCWlmIChw cmlvIDw9IGZhLT5mYV9pbmZvLT5maWJfcHJpb3JpdHkpDQotCQkJCWJyZWFr Ow0KKwkJCQlyZXR1cm4gZmE7DQogCQl9DQotCQlyZXR1cm4gcHJldl9mYTsN CiAJfQ0KIAlyZXR1cm4gTlVMTDsNCiB9DQpAQCAtNTA1LDcgKzUxMCw3IEBA DQogCSAqIGFuZCB3ZSBuZWVkIHRvIGFsbG9jYXRlIGEgbmV3IG9uZSBvZiB0 aG9zZSBhcyB3ZWxsLg0KIAkgKi8NCiANCi0JaWYgKGZhICYmDQorCWlmIChm YSAmJiBmYS0+ZmFfdG9zID09IHRvcyAmJg0KIAkgICAgZmEtPmZhX2luZm8t PmZpYl9wcmlvcml0eSA9PSBmaS0+ZmliX3ByaW9yaXR5KSB7DQogCQlzdHJ1 Y3QgZmliX2FsaWFzICpmYV9vcmlnOw0KIA0KQEAgLTU4Niw3ICs1OTEsNyBA QA0KIAl3cml0ZV9sb2NrX2JoKCZmaWJfaGFzaF9sb2NrKTsNCiAJaWYgKG5l d19mKQ0KIAkJZmliX2luc2VydF9ub2RlKGZ6LCBuZXdfZik7DQotCWxpc3Rf YWRkKCZuZXdfZmEtPmZhX2xpc3QsDQorCWxpc3RfYWRkX3RhaWwoJm5ld19m YS0+ZmFfbGlzdCwNCiAJCSAoZmEgPyAmZmEtPmZhX2xpc3QgOiAmZi0+Zm5f YWxpYXMpKTsNCiAJd3JpdGVfdW5sb2NrX2JoKCZmaWJfaGFzaF9sb2NrKTsN CiANCg== --1607745702-509301932-1096179358=:1151 Content-Type: APPLICATION/x-sh; name="rt.sh" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: test script Content-Disposition: attachment; filename="rt.sh" IyEgL2Jpbi9zaAoKdGFibGU9MTAwCmRldj1ldGgwCmtleT0xLjEuMS4xCm5o MT0idmlhIDE5Mi4xNjguMTU5LjIgZGV2ICRkZXYgdGFibGUgJHRhYmxlIgpu aDI9InZpYSAxOTIuMTY4LjE1OS4zIGRldiAkZGV2IHRhYmxlICR0YWJsZSIK aXBhPSJpcCByb3V0ZSBhcHBlbmQgJGtleSIKaXBwPSJpcCByb3V0ZSBwcmVw ZW5kICRrZXkiCmlwZD0iaXAgcm91dGUgZGVsZXRlICRrZXkgdGFibGUgJHRh YmxlIgoKaWYgWyAiJDEiID0gInN0YXJ0IiBdCnRoZW4KCSMgYXBwZW5kCgkk aXBhICRuaDEgbWV0cmljIDEKCSRpcGEgJG5oMiBtZXRyaWMgMQoJJGlwYSAk bmgxCgkkaXBhICRuaDIKCSRpcGEgJG5oMSBtZXRyaWMgMwoJJGlwYSAkbmgx IG1ldHJpYyA0CgkkaXBhICRuaDIgbWV0cmljIDIKCSRpcGEgJG5oMiBtZXRy aWMgMwoJJGlwYSAkbmgyIG1ldHJpYyA0CgoJIyBhcHBlbmQgJiB0b3MKCSRp cGEgJG5oMSBtZXRyaWMgMSB0b3MgMHgxMAoJJGlwYSAkbmgyIG1ldHJpYyAx IHRvcyAweDIwCgkkaXBhICRuaDIgbWV0cmljIDEgdG9zIDB4MTAKCgkjIHBy ZXBlbmQKCSRpcHAgJG5oMSBtZXRyaWMgMgoJJGlwcCAkbmgxIG1ldHJpYyAx IHRvcyAweDIwCmVsc2UKCXdoaWxlICRpcGQ7IGRvIDo7ZG9uZQoJd2hpbGUg JGlwZCB0b3MgMHgyMDsgZG8gOjtkb25lCgl3aGlsZSAkaXBkIHRvcyAweDEw OyBkbyA6O2RvbmUKZmkKCg== --1607745702-509301932-1096179358=:1151 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rt.out" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: the desired output Content-Disposition: attachment; filename="rt.out" MS4xLjEuMSB0b3MgMHgxMCB2aWEgMTkyLjE2OC4xNTkuMiBkZXYgZXRoMCAg bWV0cmljIDEgDQoxLjEuMS4xIHRvcyAweDEwIHZpYSAxOTIuMTY4LjE1OS4z IGRldiBldGgwICBtZXRyaWMgMSANCjEuMS4xLjEgdG9zIDB4MjAgdmlhIDE5 Mi4xNjguMTU5LjIgZGV2IGV0aDAgIG1ldHJpYyAxIA0KMS4xLjEuMSB0b3Mg MHgyMCB2aWEgMTkyLjE2OC4xNTkuMyBkZXYgZXRoMCAgbWV0cmljIDEgDQox LjEuMS4xIHZpYSAxOTIuMTY4LjE1OS4yIGRldiBldGgwIA0KMS4xLjEuMSB2 aWEgMTkyLjE2OC4xNTkuMyBkZXYgZXRoMCANCjEuMS4xLjEgdmlhIDE5Mi4x NjguMTU5LjIgZGV2IGV0aDAgIG1ldHJpYyAxIA0KMS4xLjEuMSB2aWEgMTky LjE2OC4xNTkuMyBkZXYgZXRoMCAgbWV0cmljIDEgDQoxLjEuMS4xIHZpYSAx OTIuMTY4LjE1OS4yIGRldiBldGgwICBtZXRyaWMgMiANCjEuMS4xLjEgdmlh IDE5Mi4xNjguMTU5LjMgZGV2IGV0aDAgIG1ldHJpYyAyIA0KMS4xLjEuMSB2 aWEgMTkyLjE2OC4xNTkuMiBkZXYgZXRoMCAgbWV0cmljIDMgDQoxLjEuMS4x IHZpYSAxOTIuMTY4LjE1OS4zIGRldiBldGgwICBtZXRyaWMgMyANCjEuMS4x LjEgdmlhIDE5Mi4xNjguMTU5LjIgZGV2IGV0aDAgIG1ldHJpYyA0IA0KMS4x LjEuMSB2aWEgMTkyLjE2OC4xNTkuMyBkZXYgZXRoMCAgbWV0cmljIDQgDQo= --1607745702-509301932-1096179358=:1151-- From herbert@gondor.apana.org.au Sun Sep 26 01:15:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 01:15:44 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8Q8FXPE028413 for ; Sun, 26 Sep 2004 01:15:34 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBUBK-0003kP-00; Sun, 26 Sep 2004 18:14:54 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBUBF-00034F-00; Sun, 26 Sep 2004 18:14:49 +1000 From: Herbert Xu To: ja@ssi.bg (Julian Anastasov) Subject: Re: [IPv4]: More fib_alias insertion fixes Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 26 Sep 2004 18:14:49 +1000 X-archive-position: 9469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1705 Lines: 55 Julian Anastasov wrote: > > But it still needs one exception: the entries with TOS 0 > must be at tail to allow fn_hash_lookup to match by TOS. With > random TOS insertion this is not guaranteed, the entries with > TOS=0 (wildcard) will match before the others. Good point. > prev_fa = NULL; > list_for_each_entry(fa, head, fa_list) { > if (fa->fa_tos != tos) > - continue; > + { > + if (!prev_fa && fa->fa_tos) > + continue; > + /* Stop at TOS 0 or after entries from our TOS */ > + return fa; > + } Well if we're doing this then we might as well keep it sorted by TOS. It makes the code simpler, right? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== net/ipv4/fib_hash.c 1.26 vs edited ===== --- 1.26/net/ipv4/fib_hash.c 2004-09-24 06:19:43 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-26 18:12:57 +10:00 @@ -442,9 +442,11 @@ prev_fa = NULL; list_for_each_entry(fa, head, fa_list) { - if (fa->fa_tos != tos) - continue; + if (fa->fa_tos < tos) + break; prev_fa = fa; + if (fa->fa_tos > tos) + continue; if (prio <= fa->fa_info->fib_priority) break; } @@ -506,6 +508,7 @@ */ if (fa && + fa->fa_tos == tos && fa->fa_info->fib_priority == fi->fib_priority) { struct fib_alias *fa_orig; From yoshfuji@linux-ipv6.org Sun Sep 26 03:11:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 03:11:32 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QABQP0000309 for ; Sun, 26 Sep 2004 03:11:26 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 1D83433CE5; Sun, 26 Sep 2004 19:11:30 +0900 (JST) Date: Sun, 26 Sep 2004 19:11:27 +0900 (JST) Message-Id: <20040926.191127.96477984.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: laforge@gnumonks.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [6/6]: jenkins hash for neigh From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040925005623.2faf8faf.davem@davemloft.net> References: <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1844 Lines: 44 In article <20040925005623.2faf8faf.davem@davemloft.net> (at Sat, 25 Sep 2004 00:56:23 -0700), "David S. Miller" says: > So let's discuss #4. It is the first idea I had to combat the > "problem", but honestly right now I am beginning to think that > the real solution is to simply remove the INCOMPLETE checks > altogether. > > Neighbours are a sub-cache of the routing cache. Therefore when > a neigh entry has a singular refcount, no routing cache entry > points to it. No routing cache entry, we're not sending packets > to that neighbour any time soon, so there is no reason (especially > during strong pressure) to hold onto such entries. First, in IPv6, we usually do not create cache entries for now. (I assume it is rt6_info with RTF_CACHE flag set.) We create one if we receives - redirect or - too big (for pmtu). Personally, I agree to change this; always to create routing cache. Second, we should free only STALE entries first for specification conformity; lifetime of stale entries is not standardized, but ones of others are. We will be broken especially for neighbour-cache reachable-time is longer than routing-cache lifetime) case. So, I would say - stage 1: if num_entries > low_thresh, try purge STALE entries (with refcnt == 1). if not enough, schedule flushing routing cache. - stage 2: if num_entries > high_thresh, try to purge all states (except for permanent entries, but including 1 second-old INCOMPLETE entries.) if not enough, schedule flushing routing cache. - stage 3: if num_entries > ultimate_thresh, we fail. or something. So, I cannot agree simiply removing the "INCOMPLETE" test. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ja@ssi.bg Sun Sep 26 03:27:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 03:27:18 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QAR81Z000882 for ; Sun, 26 Sep 2004 03:27:10 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8QASiKj009490; Sun, 26 Sep 2004 13:28:44 +0300 Date: Sun, 26 Sep 2004 13:28:44 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Herbert Xu cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 9471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 2431 Lines: 67 Hello, On Sun, 26 Sep 2004, Herbert Xu wrote: > Well if we're doing this then we might as well keep it sorted by TOS. > It makes the code simpler, right? I do not know for good reason to avoid order by TOS, may be Dave can explain. As for your last change, it is wrong: > prev_fa = NULL; > list_for_each_entry(fa, head, fa_list) { > - if (fa->fa_tos != tos) > - continue; > + if (fa->fa_tos < tos) here prev_fa can be NULL but we require to stop at fa. It happens when we are creating first entry in our subchain. > + break; > prev_fa = fa; > + if (fa->fa_tos > tos) > + continue; > if (prio <= fa->fa_info->fib_priority) > break; here if fa is the last one it is wrong to return prev_fa!=NULL, we need to return NULL (append) because we have to append new entry in our subchain (which is last in this case). > } Here is my understanding how should work fib_find_alias (already implemented, refer to my first posting, the case where we sort by TOS). Note that the logic is same as before fib_alias appeared: - fib_find_alias can return exact match: the desired TOS & PRIO. This is the first entry in a subchain where append and prepend matter (NLM_F_APPEND). - the return value should be used in this way: if NULL then we have to append the new entry at end of list. Else, it is a fa with fa_tos= desired PRIO) We are going to insert the new entry before this fa (even if it is not exact match, even if it is from next subchain). Saying it in another way: use append only if there is no place to insert. Sometimes we can add entry with metric less than existing one but sometimes we have to insert new entry between two subchains (fa points to first entry in next subchain). The result: fa points to next subchain or somehere in our subchain - the place to insert. - list_add serves the purpose to insert between head and first (fa and next fa/fn_alias), we need list_add_tail (insert before fa or fn_alias, i.e. append at tail). So, may be we need my 1st version of fib_find_alias plus 'fa->fa_tos == tos' plus list_add_tail? Regards -- Julian Anastasov From tgr@reeler.org Sun Sep 26 04:21:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 04:21:51 -0700 (PDT) Received: from rei.rakuen (217-162-107-144.dclient.hispeed.ch [217.162.107.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QBLgEG005786 for ; Sun, 26 Sep 2004 04:21:43 -0700 Received: from tgr by rei.rakuen with local (Exim 4.34) id 1CBX5k-0006Di-Ub; Sun, 26 Sep 2004 13:21:20 +0200 Date: Sun, 26 Sep 2004 13:21:20 +0200 From: Thomas Graf To: "David S. Miller" Cc: Harald Welte , netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20040926112120.GV31616@rei.reeler.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> <20040925203116.4e6f9b06.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040925203116.4e6f9b06.davem@davemloft.net> X-archive-position: 9472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 951 Lines: 19 * David S. Miller <20040925203116.4e6f9b06.davem@davemloft.net> 2004-09-25 20:31 > 1) Parameterizing neigh_forced_gc() so that it purges say "N" > entries each run instead of scanning the entire hash table. > Perhaps some fraction of tbl->entries I'm not familiar with the neighbour code but here's a wild thought: Calculate the average number of neigh additions (A) over the last few minutes. Count the number of additions since the last call to neigh_forced_gc() (L). Make N depdendant on L, the faster the list grows the more entries we should check by each run to avoid the list growing too fast. Calculate a aggresivity factor out of A and L and remove stale and incomplete entries depending on this factor. Maybe L needs to be calculate from the last few gc runs. I don't know if any of this is implemented already or whether it's possible or not. The basic idea is to figure out unnatural situations and handle them more aggressively. From herbert@gondor.apana.org.au Sun Sep 26 05:33:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 05:33:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QCXEa7012509 for ; Sun, 26 Sep 2004 05:33:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBYCm-00054Z-00; Sun, 26 Sep 2004 22:32:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBYCg-0000RG-00; Sun, 26 Sep 2004 22:32:34 +1000 From: Herbert Xu To: ja@ssi.bg (Julian Anastasov) Subject: Re: [IPv4]: More fib_alias insertion fixes Cc: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Sun, 26 Sep 2004 22:32:34 +1000 X-archive-position: 9473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 5278 Lines: 163 Julian Anastasov wrote: > > As for your last change, it is wrong: > >> prev_fa = NULL; >> list_for_each_entry(fa, head, fa_list) { >> - if (fa->fa_tos != tos) >> - continue; >> + if (fa->fa_tos < tos) > > here prev_fa can be NULL but we require to stop at fa. > It happens when we are creating first entry in our subchain. If fa->fa_tos < tos, then we should add the new entry before fa. If prev_fa is not NULL, then adding after prev_fa is obviously correct. If prev_fa is NULL, the caller will add it after the head of the list which is also correct since fa must've been the first element in the list. >> + break; >> prev_fa = fa; >> + if (fa->fa_tos > tos) >> + continue; >> if (prio <= fa->fa_info->fib_priority) >> break; > > here if fa is the last one it is wrong to return prev_fa!=NULL, > we need to return NULL (append) because we have to append > new entry in our subchain (which is last in this case). I still haven't figured out what you mean here, but I've found a bug :) When prio < fa->fa_info->fib_priority, this returns the wrong entry. > - fib_find_alias can return exact match: the desired TOS & PRIO. > This is the first entry in a subchain where append and prepend > matter (NLM_F_APPEND). Ack. > - the return value should be used in this way: if NULL then we have > to append the new entry at end of list. Else, it is a fa with Not quite. If it's NULL we add it at the *head* of the list. We call list_add and not list_add_tail. Actually your patch changes the list_add call to list_add_tail so your comment would be correct if your patch had been applied :) > fa_tos= desired PRIO) > We are going to insert the new entry before this fa (even if it is > not exact match, even if it is from next subchain). Saying it in > another way: use append only if there is no place to insert. Again this is only true if we apply your patch. As it is find_alias returns (and is expected to return) the entry *before* where the new entry should be added. Whether it *should* be before or after is obviously a deep philosophical question :) So here are two patches to fix the fib_priority problem. The first one returns the entry before as we do now while the second one returns the entry afterwards. Actually, I just noticed that this philosophical question does have practical implications :) The list_for_each_entry_continue() loop in fn_hash_delete will fail if fa is the entry before the correct position. Therefore I withdraw my endorsement for the "entry before" interpretation :) So patch 1 is only present for review purposes, please don't apply it. Patch 2 is good as far as I can see. So, Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- patch 1 ===== net/ipv4/fib_hash.c 1.26 vs edited ===== --- 1.26/net/ipv4/fib_hash.c 2004-09-24 06:19:43 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-26 22:02:51 +10:00 @@ -442,11 +442,15 @@ prev_fa = NULL; list_for_each_entry(fa, head, fa_list) { - if (fa->fa_tos != tos) - continue; - prev_fa = fa; - if (prio <= fa->fa_info->fib_priority) + if (fa->fa_tos < tos) break; + if (fa->fa_tos == tos) { + if (prio == fa->fa_info->fib_priority) + prev_fa = fa; + if (prio <= fa->fa_info->fib_priority) + break; + } + prev_fa = fa; } return prev_fa; } @@ -506,6 +510,7 @@ */ if (fa && + fa->fa_tos == tos && fa->fa_info->fib_priority == fi->fib_priority) { struct fib_alias *fa_orig; -- patch 2 ===== net/ipv4/fib_hash.c 1.27 vs edited ===== --- 1.27/net/ipv4/fib_hash.c 2004-09-26 22:11:38 +10:00 +++ edited/net/ipv4/fib_hash.c 2004-09-26 22:25:10 +10:00 @@ -432,23 +432,23 @@ } /* Return the first fib alias matching TOS with - * priority less than or equal to PRIO. + * the same priority or the point where the node should be inserted. */ static struct fib_alias *fib_find_alias(struct fib_node *fn, u8 tos, u32 prio) { if (fn) { struct list_head *head = &fn->fn_alias; - struct fib_alias *fa, *prev_fa; + struct fib_alias *fa; - prev_fa = NULL; list_for_each_entry(fa, head, fa_list) { - if (fa->fa_tos != tos) + if (fa->fa_tos < tos) + break; + if (fa->fa_tos > tos) continue; - prev_fa = fa; if (prio <= fa->fa_info->fib_priority) break; } - return prev_fa; + return fa; } return NULL; } @@ -506,6 +506,7 @@ */ if (fa && + fa->fa_tos == tos && fa->fa_info->fib_priority == fi->fib_priority) { struct fib_alias *fa_orig; @@ -586,7 +587,7 @@ write_lock_bh(&fib_hash_lock); if (new_f) fib_insert_node(fz, new_f); - list_add(&new_fa->fa_list, + list_add_tail(&new_fa->fa_list, (fa ? &fa->fa_list : &f->fn_alias)); write_unlock_bh(&fib_hash_lock); From herbert@gondor.apana.org.au Sun Sep 26 05:36:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 05:36:36 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QCaUs0012904 for ; Sun, 26 Sep 2004 05:36:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBYFx-00055I-00; Sun, 26 Sep 2004 22:35:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBYFx-0000SD-00; Sun, 26 Sep 2004 22:35:57 +1000 Date: Sun, 26 Sep 2004 22:35:57 +1000 To: Julian Anastasov Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes Message-ID: <20040926123557.GA1708@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 624 Lines: 17 On Sun, Sep 26, 2004 at 10:32:34PM +1000, Herbert Xu wrote: > > Therefore I withdraw my endorsement for the "entry before" interpretation :) > So patch 1 is only present for review purposes, please don't apply it. > > Patch 2 is good as far as I can see. So, And now that I look at your patch again, it is pretty much the same as patch 2. So please accept my apologies for going on this goose-chase. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ja@ssi.bg Sun Sep 26 07:07:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 07:07:17 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QE6xUX015352 for ; Sun, 26 Sep 2004 07:07:03 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i8QE7xKj010585; Sun, 26 Sep 2004 17:07:59 +0300 Date: Sun, 26 Sep 2004 17:07:59 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Herbert Xu cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-1969527934-1096207679=:8973" X-archive-position: 9475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 6119 Lines: 146 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. --1607745702-1969527934-1096207679=:8973 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, attaching version with fib_alias ordered by TOS ... On Sun, 26 Sep 2004, Herbert Xu wrote: > > here prev_fa can be NULL but we require to stop at fa. > > It happens when we are creating first entry in our subchain. > > If fa->fa_tos < tos, then we should add the new entry before fa. True, but in your patch2 you return fa after list_for_each_entry which is not valid when the loop terminates. Just change it to return the fa into the loop. > If prev_fa is not NULL, then adding after prev_fa is obviously > correct. If prev_fa is NULL, the caller will add it after the May be there are two varaints when we do not return list_head but fa: - "insert before": find a place to "insert before" else add in tail - "insert after": find a place to "insert after" else add in top but as fib_find_alias is used also for deletion I do not think we have many choices, we return the node to insert before, as in the comment. > head of the list which is also correct since fa must've been the > first element in the list. > > >> + break; > >> prev_fa = fa; > >> + if (fa->fa_tos > tos) > >> + continue; > >> if (prio <= fa->fa_info->fib_priority) > >> break; > > > > here if fa is the last one it is wrong to return prev_fa!=NULL, > > we need to return NULL (append) because we have to append > > new entry in our subchain (which is last in this case). > > I still haven't figured out what you mean here, but I've found a bug :) > When prio < fa->fa_info->fib_priority, this returns the wrong entry. Yes, this is one of the original problems :) If you have the kernel running you can try the posted test script. > > - the return value should be used in this way: if NULL then we have > > to append the new entry at end of list. Else, it is a fa with > > Not quite. If it's NULL we add it at the *head* of the list. We > call list_add and not list_add_tail. Actually your patch changes the > list_add call to list_add_tail so your comment would be correct if your > patch had been applied :) It seems there are too many wishes currently in fib_find_alias. list_add can be used for "insert after" but fa is declared to be for "insert before fa". I think, fib_find_alias was originally designed to be used for "insert before fa". > > fa_tos= desired PRIO) > > We are going to insert the new entry before this fa (even if it is > > not exact match, even if it is from next subchain). Saying it in > > another way: use append only if there is no place to insert. > > Again this is only true if we apply your patch. As it is find_alias > returns (and is expected to return) the entry *before* where the new > entry should be added. Yes, "insert before fa", then why list_add is used? > Whether it *should* be before or after is obviously a deep philosophical > question :) > > So here are two patches to fix the fib_priority problem. The first one > returns the entry before as we do now while the second one returns the > entry afterwards. > > Actually, I just noticed that this philosophical question does have > practical implications :) The list_for_each_entry_continue() loop in > fn_hash_delete will fail if fa is the entry before the correct position. There are simply no alternatives :) I'm attaching version with TOS ordering for review. > Therefore I withdraw my endorsement for the "entry before" interpretation :) > So patch 1 is only present for review purposes, please don't apply it. > > Patch 2 is good as far as I can see. So, return fa in loop > Signed-off-by: Herbert Xu > > Cheers, Regards -- Julian Anastasov --1607745702-1969527934-1096207679=:8973 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fib_ins3.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: fib_alias ordered by TOS Content-Disposition: attachment; filename="fib_ins3.diff" ZGlmZiAtdXIgdjIuNi45LXJjMi1iazEwL2xpbnV4L25ldC9pcHY0L2ZpYl9o YXNoLmMgbGludXgvbmV0L2lwdjQvZmliX2hhc2guYw0KLS0tIHYyLjYuOS1y YzItYmsxMC9saW51eC9uZXQvaXB2NC9maWJfaGFzaC5jCTIwMDQtMDktMjYg MTY6NTI6MTEuMDAwMDAwMDAwICswMzAwDQorKysgbGludXgvbmV0L2lwdjQv ZmliX2hhc2guYwkyMDA0LTA5LTI2IDE2OjUyOjMyLjc5MDA3MDAwOCArMDMw MA0KQEAgLTQzOCwxNyArNDM4LDE1IEBADQogew0KIAlpZiAoZm4pIHsNCiAJ CXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmZm4tPmZuX2FsaWFzOw0KLQkJ c3RydWN0IGZpYl9hbGlhcyAqZmEsICpwcmV2X2ZhOw0KKwkJc3RydWN0IGZp Yl9hbGlhcyAqZmE7DQogDQotCQlwcmV2X2ZhID0gTlVMTDsNCiAJCWxpc3Rf Zm9yX2VhY2hfZW50cnkoZmEsIGhlYWQsIGZhX2xpc3QpIHsNCi0JCQlpZiAo ZmEtPmZhX3RvcyAhPSB0b3MpDQorCQkJaWYgKGZhLT5mYV90b3MgPiB0b3Mp DQogCQkJCWNvbnRpbnVlOw0KLQkJCXByZXZfZmEgPSBmYTsNCi0JCQlpZiAo cHJpbyA8PSBmYS0+ZmFfaW5mby0+ZmliX3ByaW9yaXR5KQ0KLQkJCQlicmVh azsNCisJCQlpZiAoZmEtPmZhX2luZm8tPmZpYl9wcmlvcml0eSA+PSBwcmlv IHx8DQorCQkJICAgIGZhLT5mYV90b3MgPCB0b3MpDQorCQkJCXJldHVybiBm YTsNCiAJCX0NCi0JCXJldHVybiBwcmV2X2ZhOw0KIAl9DQogCXJldHVybiBO VUxMOw0KIH0NCkBAIC01MDUsNyArNTAzLDcgQEANCiAJICogYW5kIHdlIG5l ZWQgdG8gYWxsb2NhdGUgYSBuZXcgb25lIG9mIHRob3NlIGFzIHdlbGwuDQog CSAqLw0KIA0KLQlpZiAoZmEgJiYNCisJaWYgKGZhICYmIGZhLT5mYV90b3Mg PT0gdG9zICYmDQogCSAgICBmYS0+ZmFfaW5mby0+ZmliX3ByaW9yaXR5ID09 IGZpLT5maWJfcHJpb3JpdHkpIHsNCiAJCXN0cnVjdCBmaWJfYWxpYXMgKmZh X29yaWc7DQogDQpAQCAtNTg2LDcgKzU4NCw3IEBADQogCXdyaXRlX2xvY2tf YmgoJmZpYl9oYXNoX2xvY2spOw0KIAlpZiAobmV3X2YpDQogCQlmaWJfaW5z ZXJ0X25vZGUoZnosIG5ld19mKTsNCi0JbGlzdF9hZGQoJm5ld19mYS0+ZmFf bGlzdCwNCisJbGlzdF9hZGRfdGFpbCgmbmV3X2ZhLT5mYV9saXN0LA0KIAkJ IChmYSA/ICZmYS0+ZmFfbGlzdCA6ICZmLT5mbl9hbGlhcykpOw0KIAl3cml0 ZV91bmxvY2tfYmgoJmZpYl9oYXNoX2xvY2spOw0KIA0K --1607745702-1969527934-1096207679=:8973-- From buytenh@wantstofly.org Sun Sep 26 08:30:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 08:30:13 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QFU86s020405 for ; Sun, 26 Sep 2004 08:30:08 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id EC2962B0EE; Sun, 26 Sep 2004 17:29:55 +0200 (MEST) Date: Sun, 26 Sep 2004 17:29:55 +0200 From: Lennert Buytenhek To: netdev@oss.sgi.com Subject: recommendations for NIC HW(/SW) design? Message-ID: <20040926152955.GD17043@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 9476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 739 Lines: 20 Hi, I'm working on a NIC driver for the Intel IXP network processor (I've got an almost releasable version at this point), but now I'm wondering about the following. Because the chip is programmable and I'm writing the firmware myself, I am more-or-less free to determine which features the hardware will implement, and more-or-less free to define the hardware-software interface. Does any of you have any general recommendations for this? Is there anything I should certainly implement, or any design mistakes that I should certainly avoid? (Since the Intel IXP processor is just an ARM processor with a network interface grafted onto the chip, a bunch of things that apply to PCI NIC design might not apply here.) thanks, Lennert From herbert@gondor.apana.org.au Sun Sep 26 14:24:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 14:24:37 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QLOUrK030562 for ; Sun, 26 Sep 2004 14:24:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBgUe-0006uo-00; Mon, 27 Sep 2004 07:23:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBgUG-0001GH-00; Mon, 27 Sep 2004 07:23:16 +1000 From: Herbert Xu To: ja@ssi.bg (Julian Anastasov) Subject: Re: [IPv4]: More fib_alias insertion fixes Cc: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 07:23:16 +1000 X-archive-position: 9477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 798 Lines: 22 Julian Anastasov wrote: > > True, but in your patch2 you return fa after > list_for_each_entry which is not valid when the loop terminates. > Just change it to return the fa into the loop. You're right, we dereference it in fn_hash_insert. > [-- text/plain, encoding base64, charset: US-ASCII, 28 lines, name: fib_ins3.diff --] > [-- Description: fib_alias ordered by TOS --] > > diff -ur v2.6.9-rc2-bk10/linux/net/ipv4/fib_hash.c linux/net/ipv4/fib_hash.c > --- v2.6.9-rc2-bk10/linux/net/ipv4/fib_hash.c 2004-09-26 16:52:11.000000000 +0300 Looks good. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From romieu@fr.zoreil.com Sun Sep 26 16:12:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 16:12:29 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8QNCHpG000538 for ; Sun, 26 Sep 2004 16:12:18 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8QN9Tvr031046; Mon, 27 Sep 2004 01:09:29 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8QN9SGv031045; Mon, 27 Sep 2004 01:09:28 +0200 Date: Mon, 27 Sep 2004 01:09:28 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: Jon Mason Subject: [PATCH] r8169 tx_timeout recovery and automatic DAC step-down Message-ID: <20040926230928.GA28817@electric-eye.fr.zoreil.com> References: <20040919224102.GA32577@electric-eye.fr.zoreil.com> <200409231558.29821.jdmason@us.ltcfwd.linux.ibm.com> <20040923220519.GD8018@electric-eye.fr.zoreil.com> <200409231840.12539.jdmason@us.ltcfwd.linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409231840.12539.jdmason@us.ltcfwd.linux.ibm.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 507 Lines: 13 Untested patches of the day (it's late and I need to sleep): http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc2-mm2/r8169-200.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc2-mm2/r8169-210.patch The first one should perform a clean reset of the device under TX_TIMEOUT. The second one should be able to detect a broken setup wrt pci dac transaction and downgrade the advertised features of the driver accordingly. The quality of my untested patches past 00 AM is not guaranteed. -- Ueimor From herbert@gondor.apana.org.au Sun Sep 26 18:29:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 18:30:08 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R1Tsd6007517 for ; Sun, 26 Sep 2004 18:29:55 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBkKC-0000uD-00; Mon, 27 Sep 2004 11:29:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBkIW-0001dF-00; Mon, 27 Sep 2004 11:27:24 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: bad TSO performance in 2.6.9-rc2-BK Cc: herbert@gondor.apana.org.au, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040923164149.5368d291.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 11:27:24 +1000 X-archive-position: 9479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1142 Lines: 32 David S. Miller wrote: > > Previously we counted TSO frames as single "packets" as long as > we could fit one more frame into the congestion window we'd spit > out the whole TSO frame, and this kept the pipe full. Indeed, I think the new code means that Minshall's check will disable Nagle which is what was keeping TSO working properly. Anton, could you please try this patch which disables Minshall's check and see what it does? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- ===== include/net/tcp.h 1.88 vs edited ===== --- 1.88/include/net/tcp.h 2004-09-15 06:57:07 +10:00 +++ edited/include/net/tcp.h 2004-09-27 11:25:56 +10:00 @@ -1461,8 +1461,7 @@ !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && ((nonagle&TCP_NAGLE_CORK) || (!nonagle && - tcp_get_pcount(&tp->packets_out) && - tcp_minshall_check(tp)))); + tcp_get_pcount(&tp->packets_out)))); } extern void tcp_set_skb_tso_factor(struct sk_buff *, unsigned int); From herbert@gondor.apana.org.au Sun Sep 26 19:52:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 19:52:56 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R2qgHH009498 for ; Sun, 26 Sep 2004 19:52:43 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBlcL-00013d-00; Mon, 27 Sep 2004 12:51:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBlbE-0001kq-00; Mon, 27 Sep 2004 12:50:48 +1000 Date: Mon, 27 Sep 2004 12:50:48 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040927025048.GA6723@gondor.apana.org.au> References: <20040923164149.5368d291.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 795 Lines: 22 On Mon, Sep 27, 2004 at 11:27:24AM +1000, Herbert Xu wrote: > > Indeed, I think the new code means that Minshall's check will disable > Nagle which is what was keeping TSO working properly. > > Anton, could you please try this patch which disables Minshall's check > and see what it does? Never mind. Minshall is innocent :) We set the maximum TSO factor bounded by the congestion window. But when the congestion window is raised, we don't call tcp_sync_mss which is the only place that can raise the TSO factor. So the TSO factor never grows above what we start with. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Sun Sep 26 20:55:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 20:55:37 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R3tU8I014490 for ; Sun, 26 Sep 2004 20:55:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CBmZU-0005bR-00; Sun, 26 Sep 2004 20:53:04 -0700 Date: Sun, 26 Sep 2004 20:53:04 -0700 From: "David S. Miller" To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: recommendations for NIC HW(/SW) design? Message-Id: <20040926205304.06cf1de6.davem@davemloft.net> In-Reply-To: <20040926152955.GD17043@xi.wantstofly.org> References: <20040926152955.GD17043@xi.wantstofly.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 545 Lines: 16 On Sun, 26 Sep 2004 17:29:55 +0200 Lennert Buytenhek wrote: > Does any of you have any general recommendations for this? Is there > anything I should certainly implement, or any design mistakes that I > should certainly avoid? The best thing I think the tg3 does is that it uses 3 rings for packet management. There is one transmit ring, one receive ring, and "response" ring. The cpu only writes to the first two rings, and the chip only writes to the third ring. And this is great for cache behavior on the bus. From davem@davemloft.net Sun Sep 26 21:12:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 21:12:46 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R4CZT9015184 for ; Sun, 26 Sep 2004 21:12:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CBmgf-0005c9-00; Sun, 26 Sep 2004 21:00:29 -0700 Date: Sun, 26 Sep 2004 21:00:29 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040926210029.22750d47.davem@davemloft.net> In-Reply-To: <20040927025048.GA6723@gondor.apana.org.au> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1193 Lines: 29 On Mon, 27 Sep 2004 12:50:48 +1000 Herbert Xu wrote: > On Mon, Sep 27, 2004 at 11:27:24AM +1000, Herbert Xu wrote: > > > > Indeed, I think the new code means that Minshall's check will disable > > Nagle which is what was keeping TSO working properly. > > > > Anton, could you please try this patch which disables Minshall's check > > and see what it does? > > Never mind. Minshall is innocent :) > > We set the maximum TSO factor bounded by the congestion window. But > when the congestion window is raised, we don't call tcp_sync_mss > which is the only place that can raise the TSO factor. > > So the TSO factor never grows above what we start with. The very next time we check to see if we can make forward progress on the send queue we'll call tcp_current_mss() which causes the right things to happen. Something else is wrong. I think part of it is that we need to make tcp_clean_rtx_queue() return FLAG_DATA_ACKED even when a partial TSO packet is ACK'd by the other end. This will make RTO etc. calculations actually occur, among other things. But I have no idea if that will clear up the performance problems TSO is having with the new code. From herbert@gondor.apana.org.au Sun Sep 26 22:48:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 26 Sep 2004 22:48:15 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R5m1Rx017997 for ; Sun, 26 Sep 2004 22:48:01 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBoM7-0001Yt-00; Mon, 27 Sep 2004 15:47:23 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBoKT-0002JE-00; Mon, 27 Sep 2004 15:45:41 +1000 Date: Mon, 27 Sep 2004 15:45:41 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040927054541.GA8858@gondor.apana.org.au> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040926210029.22750d47.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 954 Lines: 22 On Sun, Sep 26, 2004 at 09:00:29PM -0700, David S. Miller wrote: > > The very next time we check to see if we can > make forward progress on the send queue we'll call tcp_current_mss() > which causes the right things to happen. tcp_current_mss() doesn't call tcp_sync_mss() unless the PMTU changes. > Something else is wrong. I think part of it is that we need to > make tcp_clean_rtx_queue() return FLAG_DATA_ACKED even when a > partial TSO packet is ACK'd by the other end. This will make > RTO etc. calculations actually occur, among other things. But > I have no idea if that will clear up the performance problems > TSO is having with the new code. There probably is something else wrong, since this should only limit the TSO size. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 01:08:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 01:08:58 -0700 (PDT) Received: from arnor.apana.org.au (c211-30-229-77.rivrw4.nsw.optusnet.com.au [211.30.229.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R88oF1018464 for ; Mon, 27 Sep 2004 01:08:51 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBqYi-00023K-00; Mon, 27 Sep 2004 18:08:32 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBqYe-00038q-00; Mon, 27 Sep 2004 18:08:28 +1000 Date: Mon, 27 Sep 2004 18:08:28 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [TCP] Fixed mss in tcp_init_cwnd Message-ID: <20040927080828.GA12056@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1074 Lines: 40 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: The MSS in tcp_init_cwnd should be the real one instead of the TSO value. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/ipv4/tcp_input.c 1.73 vs edited ===== --- 1.73/net/ipv4/tcp_input.c 2004-09-13 10:30:58 +10:00 +++ edited/net/ipv4/tcp_input.c 2004-09-27 17:00:32 +10:00 @@ -799,10 +799,10 @@ __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); if (!cwnd) { - if (tp->mss_cache > 1460) + if (tp->mss_cache_std > 1460) cwnd = 2; else - cwnd = (tp->mss_cache > 1095) ? 3 : 4; + cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; } return min_t(__u32, cwnd, tp->snd_cwnd_clamp); } --0F1p//8PRICkK4MW-- From cat@zip.com.au Mon Sep 27 02:03:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 02:03:47 -0700 (PDT) Received: from theirongiant.lochness.weebeastie.net (nessie.weebeastie.net [220.233.7.36]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R93dZC020050 for ; Mon, 27 Sep 2004 02:03:40 -0700 Received: from theirongiant.lochness.weebeastie.net (localhost.localdomain [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.13.1/8.13.1/Debian-13) with ESMTP id i8R93kHv001904; Mon, 27 Sep 2004 19:03:47 +1000 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.13.1/8.13.1/Debian-13) id i8R93heG001903; Mon, 27 Sep 2004 19:03:43 +1000 X-Authentication-Warning: theirongiant.lochness.weebeastie.net: hogarth set sender to cat@zip.com.au using -f Date: Mon, 27 Sep 2004 19:03:43 +1000 From: CaT To: linux-kernel@vger.kernel.org Cc: davem@davemloft.net, jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: strange network slowness in 2.6 unless pingflooding Message-ID: <20040927090342.GA1794@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organisation: Furball Inc. User-Agent: Mutt/1.5.6+20040722i X-archive-position: 9485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev Content-Length: 2712 Lines: 69 Hi, This is still happening. I ran the same set of tests on a totally different network, with my xircom realport ethernet card (tulip driver - 16bit) and from linux to linux and windows to linux. Scrolling through a message in mutt eventually slows down and if I lift my finger off the enter key whilst it's slow the scrolling keeps going, as if it was all bufferd. If I do a pingflood (ping -f) from a machine to my laptop it's all fine. I am also now running 2.6.9-rc1-mm4. Help? :/ ----- Forwarded message from CaT ----- Date: Thu, 19 Aug 2004 12:03:40 +1000 From: CaT To: linux-kernel@vger.kernel.org Subject: Whacky 2.6 network behaviour Organisation: Furball Inc. X-Mailing-List: linux-kernel@vger.kernel.org I have an SSH session across a 100mb network from my desktop to my laptop. It's mostly ok but when I scroll line-by-line on a message with mutt it can fo really fast for a bit and then slows down to almost a line per second and keeps going after I take my finger off the enter key. If I pingflood the laptop from the desktop things improve drastically and I only get a few freezes here and there. If I pingflood with 60000 byte packets things get a little better but then a severe loss of pings occurs. Each time the pings are lost my SSH connection also freezes. If I ping a different host from my desktop (like my gateway) I get no pingloss with 60000 byte packets (though this doesn't help with the scrolling issues. :) If I ping my desktop from my laptop with 60000 byte packets, the freezes are totally gone and I get no pingloss. If I ping my gateway from my laptop with 60000 byte packets I also get no pingloss and the freezes are also gone. My desktop is using kernel 2.6.7, my laptop 2.6.8.1 and the gw 2.4.27. Cards in use are: desktop: 3com 3c59x; laptop: e100 (intels); gw: e100 (intels). CPUs are: desktop: P3 600; laptop: P3 700; gw: p3 500. (Hmm. Spoke too soon. There is still SOME packet loss but it's more a freak thing rather then a repeated occurance - I've only seen it once for the last two cases and I've been flood pinging for the laptop for the majority of this message). I'll be more then happy to do any debugging/diag but I need to know what is needed and, if need be, how to get it so if any help is requried please shout and I'll get on it ASAP. -- Red herrings strewn hither and yon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ----- End forwarded message ----- -- Red herrings strewn hither and yon. From laforge@gnumonks.org Mon Sep 27 02:12:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 02:12:10 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R9C46L020578 for ; Mon, 27 Sep 2004 02:12:04 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CBrXy-0001c0-4V for netdev@oss.sgi.com; Mon, 27 Sep 2004 11:11:50 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CBrXw-0006gi-Bk for netdev@oss.sgi.com; Mon, 27 Sep 2004 11:11:48 +0200 Date: Mon, 27 Sep 2004 11:11:48 +0200 From: Harald Welte To: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] natsemi.c NAPI Message-ID: <20040927091148.GF3236@sunbeam.de.gnumonks.org> References: <20040919163642.GC1307@sunbeam.de.gnumonks.org> <4155D781.8050700@colorfullife.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QMcAIMJS2LNMCtSQ" Content-Disposition: inline In-Reply-To: <4155D781.8050700@colorfullife.com> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 3389 Lines: 106 --QMcAIMJS2LNMCtSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [resend, went to wrong list address] Manfred, thanks for your comments. [explicit Cc to jamal becuase of NAPI-related stuff below] On Sat, Sep 25, 2004 at 10:39:29PM +0200, Manfred Spraul wrote: > >+config NATSEMI_NAPI > >+ bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" > >=20 > I'm not a big fan on config options for drivers. I'd prefer a runtime=20 > option. I see. > > TODO: > > * big endian support with CFG:BEM instead of cpu_to_le32 > > * support for an external PHY > >- * NAPI > >=20 > > > Hmm. Actually all TODO points are done: CFG:BEM is unusable because it=20 > swaps data words. > External PHYs are supported. You are closing the last point. Ok, I'll remove all three with my next patch > Additional registers. You didn't mention that in the changelog.=20 > Changelogs should mention every change, please do not piggypack=20 > unrelated changes. ack. > >+ long ioaddr =3D dev->base_addr; > >+ int boguscnt =3D max_interrupt_work; > >+ > This doesn't compile: you've removed max_interrupt_work. mh, apparently I've sent an outdated patch then. I'll repost an updated version once I know what the solution for IntrStatus is > >+ /* We cannot read IntrStatus since this would acknowledge > >+ * all interrupt sources. Thus we just blindly assume that > >+ * the interrupt really was for us -HW! */ > Huge problem - this is not acceptable. It means the driver is unusable=20 > for shared interrupts. We must find a solution. yes, I know :( Luckily on my embedded boards, there are no shared interrupts - but this is obviously a special case. I think this overall problem can be solved if there was some per-device variable that saves the IntrStatus until the NAPI callback gets scheduled. What do you think? This wouldn't even need some locking, since interrupts would be disabled before the field is updated, and not re-enabled before the field is read by the NAPI callback? I was surprised that this solution is not suggested in the NAPI-HOWTO.txt, = so I though there must be an error in my proposal... By using such a scheme, isn't it also possible to only offload RX into the NAPI callback with clear-on-read devices? > IRQ_NONE would be definitively wrong: The kernel disables interrupt=20 > sources if it can't find a handler. If our handler returns IRQ_NONE and= =20 > the irq is not shared, then the kernel will disable the irq after a=20 > short while. ok. > Also missing in the changelog. is related to the register definitions above. > Manfred --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --QMcAIMJS2LNMCtSQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBV9lUXaXGVTD0i/8RAt9CAJsHefOfhWgj96DYYeX5A1kbjR5Y0QCeP/eT /I4V9bIhKQ+k5bZ3yuMo7/U= =jA+9 -----END PGP SIGNATURE----- --QMcAIMJS2LNMCtSQ-- From laforge@gnumonks.org Mon Sep 27 02:29:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 02:29:53 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R9TlZd021383 for ; Mon, 27 Sep 2004 02:29:48 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CBrp8-0001xu-UE; Mon, 27 Sep 2004 11:29:35 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CBrp7-0006hI-OW; Mon, 27 Sep 2004 11:29:33 +0200 Date: Mon, 27 Sep 2004 11:29:33 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-ID: <20040927092933.GG3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OKO3D2de3c6Y4EaB" Content-Disposition: inline In-Reply-To: <20040925090933.GU3236@sunbeam.de.gnumonks.org> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1874 Lines: 54 --OKO3D2de3c6Y4EaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 25, 2004 at 11:09:33AM +0200, Harald Welte wrote: > Please note that I guess I won't have any results until late Sunday/Monda= y. Ok, there you go. I've tested a kernel with your 6-patch-set for cleanup/jenkins/..., and the four patch set, including > > 4) The controversial/RFC patch, dorking with neigh_forced_gc() It performed perfectly, I wasn't able to reproduce those overflows anymore (testing with two /16 networks and about 200kpps incoming packets to unresolved and non-existant neighbours) > I'll do tests with and without INCOMPLETE check. No results until late > Sunday/Monday, as indicated above. I didn't even bother doing the INCOMPLETE check since Yoshifuji indicated that this caused problems with IPv6.... and it already works for me while the INCOMPLETE check is still in place. If you still want me to run it, I'll give it a go. Please also note my next mail, where I'll publish some neighbour cache statistics similar to rt_cache_stat --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --OKO3D2de3c6Y4EaB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBV919XaXGVTD0i/8RAjUaAJ902dTXDxsoJETdqJF43z45IYinZACfczio flsJxYBHx9TXL696lCZf4zc= =f7ND -----END PGP SIGNATURE----- --OKO3D2de3c6Y4EaB-- From laforge@gnumonks.org Mon Sep 27 02:36:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 02:36:36 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8R9aRei021843 for ; Mon, 27 Sep 2004 02:36:27 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CBrva-00027z-H6 for netdev@oss.sgi.com; Mon, 27 Sep 2004 11:36:14 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CBrvZ-0006ha-Gc for netdev@oss.sgi.com; Mon, 27 Sep 2004 11:36:13 +0200 Date: Mon, 27 Sep 2004 11:36:13 +0200 From: Harald Welte To: netdev@oss.sgi.com Subject: [PATCH 2.6] neighbour cache statistics like rt_stat Message-ID: <20040927093613.GH3236@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H4P0SsLKzXVjsuEG" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 11175 Lines: 381 --H4P0SsLKzXVjsuEG Content-Type: multipart/mixed; boundary="zstpKqcpPeUL/4B7" Content-Disposition: inline --zstpKqcpPeUL/4B7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The patch below (on top of davem's recent 6-patch set and 4-patch-set up to diff4) adds rt_stat like statistics to the neighbour cache core. It helped a lot during debugging/testing, and I think it is generally useful for the mainline kernel if you want to do runtime analysis of neighbour cahce performance / problems. Some comments/questions/ideas 1) old statistics used to be unsigned long, new ones are int. I propose to convert all of them to int. 2) I'd also like to add gc statistics on non-forced-gc but normal garbage collection. 3) Do we need a seperate 'miss' counter, or is the 'allocs' counter sufficient? 4) Don't we want to put them in a /proc/net/neigh directory ? 5) Since there's now rt_stat, ct_stat, neighbour statistics, and they all use the same clumsy format that is difficult to expand, and all use copy+paste userspace tools: Would you accept a patch that changes the format once again to display a template as first line, giving the names of the individual fields? I would then work on a generic userspace tool (too bad that the name netstat is already used) that would work with all of those _stat files, including upcoming new ones. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --zstpKqcpPeUL/4B7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="laforge-neigh_statistics.patch" Content-Transfer-Encoding: quoted-printable Add rtstat-like per-cpu statistics to the neighbour cache core. This will add=20 /proc/net/arp_cache_stat for ipv4 /proc/net/ndisc_cache_stat for ipv6 /proc/net/clip_arp_cache_stat for atm/clip=20 /proc/net/decnet_neigh_stat for decnet The format is similar to rt_stat, one line per cpu where each line is: Field 1: Total number of entries in table Field 2: Total number of hash bucket grows Field 3: Total number of cache hits Field 4: Total number of neigh_allocs (should equal misses) Field 5: Total number of failed neighbour resolves Field 6: ? Field 7: ? Field 8: Total number of forced garbage collector runs Field 9: Total number of forced GC runs that missed their goal Signed-off-by: Harald Welte Index: linux-2.6.9-rc2-bk9-neigh1/include/net/neighbour.h =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/include/net/neighbour.h 2004-09-26 12:4= 5:38.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/include/net/neighbour.h 2004-09-26 23:31:13.= 000000000 +0200 @@ -7,6 +7,11 @@ * Authors: * Pedro Roque * Alexey Kuznetsov + * + * Changes: + * + * Harald Welte: + * - Add neighbour cache statistics like rtstat */ =20 /* The following flags & states are exported to user space, @@ -92,10 +97,21 @@ { unsigned long allocs; unsigned long res_failed; + + unsigned int hits; /* number of cache hits */ + unsigned long rcv_probes_mcast; unsigned long rcv_probes_ucast; + + unsigned int hash_grows; /* total number of hash resizes */ + + unsigned int forced_gc_runs; /* total number of GC runs */ + unsigned int forced_gc_goal_miss;/* total number of gc goal misses */ }; =20 +#define NEIGH_CACHE_STAT_INC(tbl, field) \ + (per_cpu_ptr((tbl)->stats, smp_processor_id())->field++) + struct neighbour { struct neighbour *next; @@ -172,12 +188,15 @@ unsigned long last_rand; struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; - struct neigh_statistics stats; + struct neigh_statistics *stats; struct neighbour **hash_buckets; unsigned int hash_mask; __u32 hash_rnd; unsigned int hash_chain_gc; struct pneigh_entry **phash_buckets; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *pde; +#endif }; =20 /* flags for neigh_update() */ Index: linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/core/neighbour.c 2004-09-26 12:37:1= 8.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c 2004-09-27 10:54:35.934= 120048 +0200 @@ -21,6 +21,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -59,6 +60,7 @@ =20 static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; +static struct file_operations neigh_stat_seq_fops; =20 /* Neighbour hash table buckets are protected with rwlock tbl->lock. @@ -115,6 +117,8 @@ int shrunk =3D 0, num_incomplete =3D 0, reap_incomplete =3D 0; int i; =20 + NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs); + write_lock_bh(&tbl->lock); rescan: for (i =3D 0; i <=3D tbl->hash_mask; i++) { @@ -161,6 +165,7 @@ if (reap_incomplete =3D=3D 0 && shrunk < goal && (shrunk + num_incomplete) >=3D goal) { + NEIGH_CACHE_STAT_INC(tbl, forced_gc_goal_miss); reap_incomplete =3D 1; goto rescan; } @@ -299,7 +304,8 @@ init_timer(&n->timer); n->timer.function =3D neigh_timer_handler; n->timer.data =3D (unsigned long)n; - tbl->stats.allocs++; + + NEIGH_CACHE_STAT_INC(tbl, allocs); neigh_glbl_allocs++; tbl->entries++; n->tbl =3D tbl; @@ -341,6 +347,8 @@ struct neighbour **new_hash, **old_hash; unsigned int i, new_hash_mask, old_entries; =20 + NEIGH_CACHE_STAT_INC(tbl, hash_grows); + BUG_ON(new_entries & (new_entries - 1)); new_hash =3D neigh_hash_alloc(new_entries); if (!new_hash) @@ -380,6 +388,7 @@ for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (dev =3D=3D n->dev && !memcmp(n->primary_key, pkey, key_len)) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -397,6 +406,7 @@ for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (!memcmp(n->primary_key, pkey, key_len)) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -787,7 +797,7 @@ =20 neigh->nud_state =3D NUD_FAILED; notify =3D 1; - neigh->tbl->stats.res_failed++; + NEIGH_CACHE_STAT_INC(neigh->tbl, res_failed); NEIGH_PRINTK2("neigh %p is failed.\n", neigh); =20 /* It is very thin place. report_unreachable is very complicated @@ -1336,6 +1346,30 @@ if (!tbl->kmem_cachep) panic("cannot create neighbour cache"); =20 + tbl->stats =3D alloc_percpu(struct neigh_statistics); + if (!tbl->stats) + panic("cannot create neighbour cache statistics"); +=09 +#ifdef CONFIG_PROC_FS +#define NC_STAT_SUFFIX "_stat" + { + char *proc_stat_name; + proc_stat_name =3D kmalloc(strlen(tbl->id) +=20 + strlen(NC_STAT_SUFFIX) + 1, GFP_KERNEL); + if (!proc_stat_name) + panic("cannot allocate neighbour cache proc name buffer"); + strcpy(proc_stat_name, tbl->id); + strcat(proc_stat_name, NC_STAT_SUFFIX); + + /* FIXME: move this to seperate directory and add _stat postfix */ + tbl->pde =3D create_proc_entry(proc_stat_name, 0, proc_net); + if (!tbl->pde)=20 + panic("cannot create neighbour proc dir entry"); + tbl->pde->proc_fops =3D &neigh_stat_seq_fops; + tbl->pde->data =3D tbl; + } +#endif + tbl->hash_mask =3D 0x1f; tbl->hash_buckets =3D neigh_hash_alloc(tbl->hash_mask + 1); =20 @@ -1882,6 +1916,94 @@ } EXPORT_SYMBOL(neigh_seq_stop); =20 +/* statistics via seq_file */ + +static void *neigh_stat_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int cpu; +=09 + for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos =3D cpu; + return per_cpu_ptr(tbl->stats, cpu); + } + return NULL; +} + +static void *neigh_stat_seq_next(struct seq_file *seq, void *v, loff_t *po= s) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int cpu; + + for (cpu =3D *pos + 1; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos =3D cpu; + return per_cpu_ptr(tbl->stats, cpu); + } + return NULL; +} + +static void neigh_stat_seq_stop(struct seq_file *seq, void *v) +{ + +} + +static int neigh_stat_seq_show(struct seq_file *seq, void *v) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + struct neigh_statistics *st =3D v; + + seq_printf(seq, "%08x %08x %08x %08lx %08lx %08lx %08lx " + "%08x %08x\n", + tbl->entries, + + st->hash_grows, + st->hits, + st->allocs, + st->res_failed, + + st->rcv_probes_mcast, + st->rcv_probes_ucast, + + st->forced_gc_runs, + st->forced_gc_goal_miss + ); + + return 0; +} + +static struct seq_operations neigh_stat_seq_ops =3D { + .start =3D neigh_stat_seq_start, + .next =3D neigh_stat_seq_next, + .stop =3D neigh_stat_seq_stop, + .show =3D neigh_stat_seq_show, +}; + +static int neigh_stat_seq_open(struct inode *inode, struct file *file) +{ + int ret =3D seq_open(file, &neigh_stat_seq_ops); + + if (!ret) { + struct seq_file *sf =3D file->private_data; + sf->private =3D PDE(inode); + } + return ret; +}; + +static struct file_operations neigh_stat_seq_fops =3D { + .owner =3D THIS_MODULE, + .open =3D neigh_stat_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release, +}; + #endif /* CONFIG_PROC_FS */ =20 #ifdef CONFIG_ARPD Index: linux-2.6.9-rc2-bk9-neigh1/net/ipv6/ndisc.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/ipv6/ndisc.c 2004-09-26 12:29:03.00= 0000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/ipv6/ndisc.c 2004-09-26 23:30:56.0000000= 00 +0200 @@ -802,9 +802,9 @@ } =20 if (inc) - nd_tbl.stats.rcv_probes_mcast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_mcast); else - nd_tbl.stats.rcv_probes_ucast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_ucast); =20 /*=20 * update / create cache entry --zstpKqcpPeUL/4B7-- --H4P0SsLKzXVjsuEG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBV98NXaXGVTD0i/8RAkVpAJ9H4sqIcdvJL8VEztEixrpYrOOJjgCgrlud scCrJZPXtc6X3WfsK7q3nRE= =9IxE -----END PGP SIGNATURE----- --H4P0SsLKzXVjsuEG-- From Robert.Olsson@data.slu.se Mon Sep 27 03:30:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 03:30:40 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RAUXsW025322 for ; Mon, 27 Sep 2004 03:30:34 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8RAUHY2019963; Mon, 27 Sep 2004 12:30:17 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id E340090265; Mon, 27 Sep 2004 12:30:17 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16727.60345.857450.162620@robur.slu.se> Date: Mon, 27 Sep 2004 12:30:17 +0200 To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] natsemi.c NAPI In-Reply-To: <20040927091148.GF3236@sunbeam.de.gnumonks.org> References: <20040919163642.GC1307@sunbeam.de.gnumonks.org> <4155D781.8050700@colorfullife.com> <20040927091148.GF3236@sunbeam.de.gnumonks.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 742 Lines: 18 > I think this overall problem can be solved if there was some per-device > variable that saves the IntrStatus until the NAPI callback gets > scheduled. What do you think? This wouldn't even need some locking, > since interrupts would be disabled before the field is updated, and not > re-enabled before the field is read by the NAPI callback? > > I was surprised that this solution is not suggested in the NAPI-HOWTO.txt, so I though there must be an error in my proposal... > > By using such a scheme, isn't it also possible to only offload RX into > the NAPI callback with clear-on-read devices? > e1000 used such technique before.If a remember correctly IntrStatus was saved in device priv struct. Cheers. --ro From herbert@gondor.apana.org.au Mon Sep 27 04:34:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 04:34:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RBY7B1032132 for ; Mon, 27 Sep 2004 04:34:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBtlG-0003G6-00; Mon, 27 Sep 2004 21:33:42 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBtl8-0000w8-00; Mon, 27 Sep 2004 21:33:34 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [5/6]: Dynamic neigh hash table growth Cc: laforge@gnumonks.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040923225127.10b0ef68.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 21:33:34 +1000 X-archive-position: 9490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 673 Lines: 19 David S. Miller wrote: > > +static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_entries) > +{ > + struct neighbour **new_hash, **old_hash; > + unsigned int i, new_hash_mask, old_entries; > + > + BUG_ON(new_entries & (new_entries - 1)); > + new_hash = neigh_hash_alloc(new_entries); Perhaps it'd be better to bound it based on MAX_ORDER rather than waiting for neigh_hash_alloc() to fail? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 04:44:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 04:44:32 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RBiM55032677 for ; Mon, 27 Sep 2004 04:44:23 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBtvG-0003LC-00; Mon, 27 Sep 2004 21:44:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBtvC-0000yM-00; Mon, 27 Sep 2004 21:43:58 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [6/6]: jenkins hash for neigh Cc: laforge@gnumonks.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040925005623.2faf8faf.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 21:43:58 +1000 X-archive-position: 9491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 386 Lines: 12 David S. Miller wrote: > > 2) Tim Gardner's change to smooth out periodic neighbour GC. I think tbl->gc_interval can be killed altogether now. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 04:48:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 04:49:03 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RBmvNs000642 for ; Mon, 27 Sep 2004 04:48:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBtzh-0003MM-00; Mon, 27 Sep 2004 21:48:37 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBtzd-0000zI-00; Mon, 27 Sep 2004 21:48:33 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [6/6]: jenkins hash for neigh Cc: laforge@gnumonks.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040925005623.2faf8faf.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 21:48:33 +1000 X-archive-position: 9492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 673 Lines: 22 David S. Miller wrote: > > 3) Fix locking and GFP_* bugs. > > @@ -400,8 +400,11 @@ > goto out; > } > > - if (tbl->entries > (tbl->hash_mask + 1)) > + if (tbl->entries > (tbl->hash_mask + 1)) { > + write_lock_bh(&tbl->lock); > neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); > + write_unlock_bh(&tbl->lock); > + } The locking should be outside the if block as otherwise you may grow unnecessarily or grow into the same size :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Robert.Olsson@data.slu.se Mon Sep 27 04:53:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 04:53:54 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RBrmEJ001097 for ; Mon, 27 Sep 2004 04:53:49 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8RBrXY2027290; Mon, 27 Sep 2004 13:53:33 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id C062590265; Mon, 27 Sep 2004 13:53:33 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16727.65341.747293.986870@robur.slu.se> Date: Mon, 27 Sep 2004 13:53:33 +0200 To: "David S. Miller" Cc: Julian Anastasov , netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes In-Reply-To: <20040925201425.16fbcb6c.davem@davemloft.net> References: <20040925201425.16fbcb6c.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 127 Lines: 7 I'll guess struct fib_alias should not be defined in fib_hash.c to support pluggable lookup algorithms. Cheers. --ro From herbert@gondor.apana.org.au Mon Sep 27 04:56:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 04:56:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RBudmu001497 for ; Mon, 27 Sep 2004 04:56:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBu79-0003Qn-00; Mon, 27 Sep 2004 21:56:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBu70-00010X-00; Mon, 27 Sep 2004 21:56:10 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [6/6]: jenkins hash for neigh Cc: laforge@gnumonks.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040925005623.2faf8faf.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 21:56:10 +1000 X-archive-position: 9494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 899 Lines: 28 David S. Miller wrote: > > 4) The controversial/RFC patch, dorking with neigh_forced_gc() > > + if (n->nud_state -= NUD_INCOMPLETE && > + reap_incomplete == 0 && > + time_after(jiffies, > + n->used + n->parms->retrans_time)) { > + num_incomplete++; > + goto next_ent; That should either be time_before, or you need to swap the arguments. @@ -261,7 +277,9 @@ if (tbl->entries > tbl->gc_thresh3 || (tbl->entries > tbl->gc_thresh2 && time_after(now, tbl->last_flush + 5 * HZ))) { - if (!neigh_forced_gc(tbl) && + int goal = tbl->entries - tbl->gc_thresh3; This could be negative but I suppose it's harmless... Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 05:00:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 05:00:50 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RC0gmn001913 for ; Mon, 27 Sep 2004 05:00:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CBuAi-0003Rw-00; Mon, 27 Sep 2004 22:00:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CBuAe-00011H-00; Mon, 27 Sep 2004 21:59:56 +1000 From: Herbert Xu To: Robert.Olsson@data.slu.se (Robert Olsson) Subject: Re: [IPv4]: More fib_alias insertion fixes Cc: davem@davemloft.net, ja@ssi.bg, netdev@oss.sgi.com Organization: Core In-Reply-To: <16727.65341.747293.986870@robur.slu.se> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Mon, 27 Sep 2004 21:59:56 +1000 X-archive-position: 9495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 418 Lines: 11 Robert Olsson wrote: > > I'll guess struct fib_alias should not be defined in fib_hash.c to > support pluggable lookup algorithms. Should one turn up then we can move it out :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Robert.Olsson@data.slu.se Mon Sep 27 05:09:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 05:09:54 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RC9nio002413 for ; Mon, 27 Sep 2004 05:09:49 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8RC9MY2010388; Mon, 27 Sep 2004 14:09:23 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id EA8C390265; Mon, 27 Sep 2004 14:09:22 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16728.754.931720.194249@robur.slu.se> Date: Mon, 27 Sep 2004 14:09:22 +0200 To: Herbert Xu Cc: Robert.Olsson@data.slu.se (Robert Olsson), davem@davemloft.net, ja@ssi.bg, netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes In-Reply-To: References: <16727.65341.747293.986870@robur.slu.se> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 328 Lines: 14 Herbert Xu writes: > Robert Olsson wrote: > > > > I'll guess struct fib_alias should not be defined in fib_hash.c to > > support pluggable lookup algorithms. > > Should one turn up then we can move it out :) Do. :-) Seems fib_find_alias should be moved out as well. Cheers. --ro From hadi@cyberus.ca Mon Sep 27 05:41:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 05:41:34 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RCfTm6004790 for ; Mon, 27 Sep 2004 05:41:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CBuod-00032F-6w for netdev@oss.sgi.com; Mon, 27 Sep 2004 08:41:15 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CBuoa-00041P-DI; Mon, 27 Sep 2004 08:41:12 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040924032002.GA6384@gondor.apana.org.au> References: <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <1095821624.1045.6.camel@jzny.localdomain> <20040922034634.GA14928@gondor.apana.org.au> <1095852956.1048.47.camel@jzny.localdomain> <20040923120520.GA32624@gondor.apana.org.au> <1095994597.1045.26.camel@jzny.localdomain> <20040924032002.GA6384@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096288869.1073.31.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 08:41:09 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 522 Lines: 18 On Thu, 2004-09-23 at 23:20, Herbert Xu wrote: > On Thu, Sep 23, 2004 at 10:56:37PM -0400, jamal wrote: > > > > > What's wrong with the default sizes? If you decrease it far enough > > > of course it's going to overflow. > > > > The idea is to reproduce the overun ;-> > > OK, I've just tried 4096 and nothing: Try harder! ;-> Ok, I will go and lookup my test machine and get back with an exact test case (problem is whenever i have time to scan my emails i am at least 30 minutes away from that box). cheers, jamal From hadi@cyberus.ca Mon Sep 27 05:46:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 05:46:53 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RCkmDo005290 for ; Mon, 27 Sep 2004 05:46:48 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CButl-0007f7-Gy for netdev@oss.sgi.com; Mon, 27 Sep 2004 08:46:33 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CButk-0004mi-O6; Mon, 27 Sep 2004 08:46:33 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040924032440.GB6384@gondor.apana.org.au> References: <1095647944.1046.206.camel@jzny.localdomain> <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096289189.1075.37.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 08:46:30 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1136 Lines: 36 On Thu, 2004-09-23 at 23:24, Herbert Xu wrote: > There are three possible netlink usages: > > 1) Request/response: > > No overruns should occur. Cant assume this. A request for an ACK is fine. A get is a different ball game. > 2) Dump: > > No overruns should occur because of dump only fills in the next one when > the previous one is taken off the queue by the user. > > 3) Async messages: > > Overruns may occur if the arrival rate exceeds the application's > processing capacity or if the queue is too small for a burst. > > Now we were discussing about how we can do congestion control for 3). > But to do that we need to know exactly what these messages are. For > example if they're coming from an external source as is the case in > ip_queue then you can't congestion control it at all. > > Oh and never use the same socket for 1+2) and 3) together. You can > use the socket for 1) and 2), but 3) must be in its own socket. I think the discussion to have a mini-slab-like allocator for netlink that i see going on in other thread is what we need. However, so far that seems to be only useful for 2). cheers, jamal From hadi@cyberus.ca Mon Sep 27 05:53:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 05:53:35 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RCrUcA006554 for ; Mon, 27 Sep 2004 05:53:30 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CBv0F-00028o-QA for netdev@oss.sgi.com; Mon, 27 Sep 2004 08:53:15 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CBv0E-0005oO-F5; Mon, 27 Sep 2004 08:53:14 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040924032830.GC6384@gondor.apana.org.au> References: <20040920025802.GA11567@gondor.apana.org.au> <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096289591.1075.45.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 08:53:11 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 453 Lines: 13 On Thu, 2004-09-23 at 23:28, Herbert Xu wrote: > Most of the dump messages should be close to PAGE_SIZE anyway, no? 20 bytes for the header; typical messages and attributes are in the range of 20 bytes. In the problematic case #2 or #3 (from what i have seen) in your previous email, you get events being broadcast to multiple users occupying say 400 bytes or about 10 messages (~10%) when 4096 is charged to the socket receive queue. cheers, jamal From hadi@cyberus.ca Mon Sep 27 05:59:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 05:59:29 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RCxOSK007032 for ; Mon, 27 Sep 2004 05:59:24 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CBv5y-0003zU-33 for netdev@oss.sgi.com; Mon, 27 Sep 2004 08:59:10 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CBv5w-0006Yc-UO; Mon, 27 Sep 2004 08:59:09 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: "David S. Miller" , pablo@eurodev.net, "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040924220651.GA6096@gondor.apana.org.au> References: <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040922105221.59a67d4b.davem@davemloft.net> <4152EE68.4030803@eurodev.net> <20040923121651.51a58cf2.davem@davemloft.net> <20040924032830.GC6384@gondor.apana.org.au> <20040923223909.6f4da27f.davem@davemloft.net> <20040924062604.GA7393@gondor.apana.org.au> <20040924105855.0e1aecd0.davem@davemloft.net> <20040924220651.GA6096@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096289945.1074.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 08:59:05 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 455 Lines: 14 On Fri, 2004-09-24 at 18:06, Herbert Xu wrote: > I agree completely. I'm just saying that the current NLM_GOODSIZE > skb is the perfect scratch-pad so we don't need a new one. All we > need to do is to insert a helper call just before netlink_unicast > to copy and trim the packet in the places that need it. You are probably talking past each other - to me you seem to be saying the same thing. A "manager" of some form is required. cheers, jamal From klassert@mathematik.tu-chemnitz.de Mon Sep 27 06:51:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 06:51:05 -0700 (PDT) Received: from john.hrz.tu-chemnitz.de (john.hrz.tu-chemnitz.de [134.109.132.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RDoxhC015416 for ; Mon, 27 Sep 2004 06:51:00 -0700 Received: from gareth.mathematik.tu-chemnitz.de ([134.109.40.156]) by john.hrz.tu-chemnitz.de with esmtp (Exim 4.41) id 1CBvtt-00068C-Ro; Mon, 27 Sep 2004 15:50:45 +0200 Received: by gareth.mathematik.tu-chemnitz.de (Postfix, from userid 274) id A85E28317; Mon, 27 Sep 2004 15:50:45 +0200 (CEST) Date: Mon, 27 Sep 2004 15:50:45 +0200 From: Steffen Klassert To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [PATCH] 3c59x - use netdev_priv Message-ID: <20040927135045.GC18851@gareth.mathematik.tu-chemnitz.de> Mail-Followup-To: jgarzik@pobox.com, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Scan-Signature: c4e529ea06550f8ae756d457c1b9e21b X-archive-position: 9501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klassert@mathematik.tu-chemnitz.de Precedence: bulk X-list: netdev Content-Length: 1085 Lines: 29 Patch changes the two remaining direct accessing of dev->priv to netdev_priv. Applies against linux-2.6.9-rc2-mm3 Signed-off-by: Steffen Klassert -- diff -urN vanilla-2.6.9-rc2-mm3/drivers/net/3c59x.c linux-2.6.9-rc2-mm3/drivers/net/3c59x.c --- vanilla-2.6.9-rc2-mm3/drivers/net/3c59x.c Sat Sep 25 12:00:58 2004 +++ linux-2.6.9-rc2-mm3/drivers/net/3c59x.c Mon Sep 27 10:27:07 2004 @@ -934,7 +934,7 @@ static int vortex_cards_found; #ifdef CONFIG_NET_POLL_CONTROLLER static void poll_vortex(struct net_device *dev) { - struct vortex_private *vp = (struct vortex_private *)dev->priv; + struct vortex_private *vp = netdev_priv(dev); unsigned long flags; local_save_flags(flags); local_irq_disable(); @@ -2982,7 +2982,7 @@ static void set_rx_mode(struct net_devic static void set_8021q_mode(struct net_device *dev, int enable) { - struct vortex_private *vp = (struct vortex_private *)dev->priv; + struct vortex_private *vp = netdev_priv(dev); long ioaddr = dev->base_addr; int old_window = inw(ioaddr + EL3_CMD); int mac_ctrl; From klassert@mathematik.tu-chemnitz.de Mon Sep 27 06:54:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 06:54:17 -0700 (PDT) Received: from john.hrz.tu-chemnitz.de (john.hrz.tu-chemnitz.de [134.109.132.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RDsBTZ015847 for ; Mon, 27 Sep 2004 06:54:12 -0700 Received: from gareth.mathematik.tu-chemnitz.de ([134.109.40.156]) by john.hrz.tu-chemnitz.de with esmtp (Exim 4.41) id 1CBvx1-0006QO-Jk; Mon, 27 Sep 2004 15:53:59 +0200 Received: by gareth.mathematik.tu-chemnitz.de (Postfix, from userid 274) id 77B20831C; Mon, 27 Sep 2004 15:53:59 +0200 (CEST) Date: Mon, 27 Sep 2004 15:53:59 +0200 From: Steffen Klassert To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [PATCH] 8139cp - add netpoll support Message-ID: <20040927135359.GD18851@gareth.mathematik.tu-chemnitz.de> Mail-Followup-To: jgarzik@pobox.com, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Scan-Signature: 88cb67b9b57d7b5bb9cb912476686b1b X-archive-position: 9502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klassert@mathematik.tu-chemnitz.de Precedence: bulk X-list: netdev Content-Length: 1706 Lines: 52 Patch adds netpoll support to the 8139cp driver. The patch needs some tests because I have no NIC of this type for testing. Applies against linux-2.6.9-rc2-mm3 Signed-off-by: Steffen Klassert -- diff -urN vanilla-2.6.9-rc2-mm3/drivers/net/8139cp.c linux-2.6.9-rc2-mm3/drivers/net/8139cp.c --- vanilla-2.6.9-rc2-mm3/drivers/net/8139cp.c Sat Sep 25 12:00:58 2004 +++ linux-2.6.9-rc2-mm3/drivers/net/8139cp.c Mon Sep 27 11:55:04 2004 @@ -398,6 +398,9 @@ struct cp_private { static void __cp_set_rx_mode (struct net_device *dev); static void cp_tx (struct cp_private *cp); static void cp_clean_rings (struct cp_private *cp); +#ifdef CONFIG_NET_POLL_CONTROLLER +static void cp_poll_controller(struct net_device *dev); +#endif static struct pci_device_id cp_pci_tbl[] = { { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139, @@ -690,6 +693,19 @@ cp_interrupt (int irq, void *dev_instanc return IRQ_HANDLED; } +#ifdef CONFIG_NET_POLL_CONTROLLER +/* + * Polling receive - used by netconsole and other diagnostic tools + * to allow network i/o with interrupts disabled. + */ +static void cp_poll_controller(struct net_device *dev) +{ + disable_irq(dev->irq); + cp_interrupt(dev->irq, dev, NULL); + enable_irq(dev->irq); +} +#endif + static void cp_tx (struct cp_private *cp) { unsigned tx_head = cp->tx_head; @@ -1761,6 +1777,9 @@ static int cp_init_one (struct pci_dev * dev->get_stats = cp_get_stats; dev->do_ioctl = cp_ioctl; dev->poll = cp_rx_poll; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = cp_poll_controller; +#endif dev->weight = 16; /* arbitrary? from NAPI_HOWTO.txt. */ #ifdef BROKEN dev->change_mtu = cp_change_mtu; From niv@us.ibm.com Mon Sep 27 08:37:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 08:37:15 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RFb0ls021785 for ; Mon, 27 Sep 2004 08:37:07 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (rwcrmhc13) with ESMTP id <20040927153642015009667he>; Mon, 27 Sep 2004 15:36:43 +0000 Message-ID: <41583381.9090003@us.ibm.com> Date: Mon, 27 Sep 2004 08:36:33 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [TCP] Fixed mss in tcp_init_cwnd References: <20040927080828.GA12056@gondor.apana.org.au> In-Reply-To: <20040927080828.GA12056@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 791 Lines: 29 Herbert Xu wrote: > Hi Dave: > > The MSS in tcp_init_cwnd should be the real one instead of the TSO value. > > Signed-off-by: Herbert Xu > > Cheers, > > > ------------------------------------------------------------------------ > > ===== net/ipv4/tcp_input.c 1.73 vs edited ===== > --- 1.73/net/ipv4/tcp_input.c 2004-09-13 10:30:58 +10:00 > +++ edited/net/ipv4/tcp_input.c 2004-09-27 17:00:32 +10:00 > @@ -799,10 +799,10 @@ > __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); > > if (!cwnd) { > - if (tp->mss_cache > 1460) > + if (tp->mss_cache_std > 1460) > cwnd = 2; > else > - cwnd = (tp->mss_cache > 1095) ? 3 : 4; > + cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; > } > return min_t(__u32, cwnd, tp->snd_cwnd_clamp); > } From niv@us.ibm.com Mon Sep 27 08:44:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 08:44:22 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RFiHlA022245 for ; Mon, 27 Sep 2004 08:44:17 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (rwcrmhc11) with ESMTP id <2004092715435901300ls0lie>; Mon, 27 Sep 2004 15:44:00 +0000 Message-ID: <41583537.2090906@us.ibm.com> Date: Mon, 27 Sep 2004 08:43:51 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [TCP] Fixed mss in tcp_init_cwnd References: <20040927080828.GA12056@gondor.apana.org.au> In-Reply-To: <20040927080828.GA12056@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 771 Lines: 28 Herbert Xu wrote: > ===== net/ipv4/tcp_input.c 1.73 vs edited ===== > --- 1.73/net/ipv4/tcp_input.c 2004-09-13 10:30:58 +10:00 > +++ edited/net/ipv4/tcp_input.c 2004-09-27 17:00:32 +10:00 > @@ -799,10 +799,10 @@ > __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0); > > if (!cwnd) { > - if (tp->mss_cache > 1460) > + if (tp->mss_cache_std > 1460) > cwnd = 2; > else > - cwnd = (tp->mss_cache > 1095) ? 3 : 4; > + cwnd = (tp->mss_cache_std > 1095) ? 3 : 4; > } > return min_t(__u32, cwnd, tp->snd_cwnd_clamp); > } Helps to send after finishing commenting.. I fixed this locally but was still seeing poor throughput, though it does correct how many we initially/on restart send out. Thought this was fixed in the bk tree? thanks, Nivedita From laforge@gnumonks.org Mon Sep 27 08:52:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 08:52:07 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RFq0b1022756 for ; Mon, 27 Sep 2004 08:52:01 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CBxn2-00021A-JY; Mon, 27 Sep 2004 17:51:48 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CBxmy-00071E-BQ; Mon, 27 Sep 2004 17:51:44 +0200 Date: Mon, 27 Sep 2004 17:51:44 +0200 From: Harald Welte To: Lennert Buytenhek Cc: netdev@oss.sgi.com Subject: Re: recommendations for NIC HW(/SW) design? Message-ID: <20040927155144.GU3236@sunbeam.de.gnumonks.org> References: <20040926152955.GD17043@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="399d5c/rwW6QrXB5" Content-Disposition: inline In-Reply-To: <20040926152955.GD17043@xi.wantstofly.org> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1397 Lines: 43 --399d5c/rwW6QrXB5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 26, 2004 at 05:29:55PM +0200, Lennert Buytenhek wrote: > (Since the Intel IXP processor is just an ARM processor with a network > interface grafted onto the chip, a bunch of things that apply to PCI > NIC design might not apply here.) I think this IXP is only a UP architecture, is it? For SMP scalability it would be nice to specify the Tx Interrupt in every descriptor, so you can cause Tx interrupts go to the cpu that actually sent the packet (cache locality). > thanks, > Lennert --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --399d5c/rwW6QrXB5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWDcQXaXGVTD0i/8RAkPwAJ40onleObLszderlWAjhfgfIa8axACgrMe3 deBeIUaHHFpUtQrRMxLdEYo= =hAgD -----END PGP SIGNATURE----- --399d5c/rwW6QrXB5-- From laforge@gnumonks.org Mon Sep 27 09:23:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 09:23:59 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RGNmtI023786 for ; Mon, 27 Sep 2004 09:23:49 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CByHn-0002i6-Im for netdev@oss.sgi.com; Mon, 27 Sep 2004 18:23:35 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CByHm-00072f-Hz for netdev@oss.sgi.com; Mon, 27 Sep 2004 18:23:34 +0200 Date: Mon, 27 Sep 2004 18:23:34 +0200 From: Harald Welte To: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] neighbour cache statistics like rt_stat Message-ID: <20040927162334.GV3236@sunbeam.de.gnumonks.org> References: <20040927093613.GH3236@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I2z5DWo3OKf2mlg0" Content-Disposition: inline In-Reply-To: <20040927093613.GH3236@sunbeam.de.gnumonks.org> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 12243 Lines: 431 --I2z5DWo3OKf2mlg0 Content-Type: multipart/mixed; boundary="1AxFftPZlP9RA4ZR" Content-Disposition: inline --1AxFftPZlP9RA4ZR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 27, 2004 at 11:36:13AM +0200, Harald Welte wrote: > The patch below (on top of davem's recent 6-patch set and 4-patch-set up > to diff4) adds rt_stat like statistics to the neighbour cache core. I've now updated the patch. Changes: - more statistics (lookups, destroy, periodic_gc_runs) - add template line to top of file --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --1AxFftPZlP9RA4ZR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="laforge-neigh_statistics.patch" Content-Transfer-Encoding: quoted-printable Add rtstat-like per-cpu statistics to the neighbour cache core. This will add=20 /proc/net/arp_cache_stat for ipv4 /proc/net/ndisc_cache_stat for ipv6 /proc/net/clip_arp_cache_stat for atm/clip=20 /proc/net/decnet_neigh_stat for decnet The format is similar to rt_stat, one line per cpu where each line is: Field 0: Total number of entries in table Field 1: Total number of neighbour allocations in this tbl Field 2: Total number of neighbour destroys in this tbl Field 3: Total number of hash bucket grows Field 4: Total number of failed neighbour resolves Field 5: Total number of cache lookups Field 6: Total number of cache hits Field 7: Total number of received multicast solicitations Field 8: Total number of received unicast solicitations Field 9: Total number of periodic garbage collector runs Field 10: Total number of forced garbage collector runs Field 11: Total number of forced GC runs that missed their goal Signed-off-by: Harald Welte Index: linux-2.6.9-rc2-bk9-neigh1/include/net/neighbour.h =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/include/net/neighbour.h 2004-09-26 12:4= 5:38.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/include/net/neighbour.h 2004-09-27 13:44:49.= 000000000 +0200 @@ -7,6 +7,11 @@ * Authors: * Pedro Roque * Alexey Kuznetsov + * + * Changes: + * + * Harald Welte: + * - Add neighbour cache statistics like rtstat */ =20 /* The following flags & states are exported to user space, @@ -90,12 +95,26 @@ =20 struct neigh_statistics { - unsigned long allocs; - unsigned long res_failed; - unsigned long rcv_probes_mcast; - unsigned long rcv_probes_ucast; + unsigned int allocs; /* number of allocated neighs */ + unsigned int destroys; /* number of destroyed neighs */ + unsigned int hash_grows; /* number of hash resizes */ + + unsigned int res_failed; /* nomber of failed resolutions */ + + unsigned int lookups; /* number of lookups */ + unsigned int hits; /* number of hits (among lookups) */ + + unsigned int rcv_probes_mcast; /* number of received mcast ipv6 */ + unsigned int rcv_probes_ucast; /* number of received ucast ipv6 */ + + unsigned int periodic_gc_runs; /* number of periodic GC runs */ + unsigned int forced_gc_runs; /* number of forced GC runs */ + unsigned int forced_gc_goal_miss;/* number of gc goal misses */ }; =20 +#define NEIGH_CACHE_STAT_INC(tbl, field) \ + (per_cpu_ptr((tbl)->stats, smp_processor_id())->field++) + struct neighbour { struct neighbour *next; @@ -172,12 +191,15 @@ unsigned long last_rand; struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; - struct neigh_statistics stats; + struct neigh_statistics *stats; struct neighbour **hash_buckets; unsigned int hash_mask; __u32 hash_rnd; unsigned int hash_chain_gc; struct pneigh_entry **phash_buckets; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *pde; +#endif }; =20 /* flags for neigh_update() */ Index: linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/core/neighbour.c 2004-09-26 12:37:1= 8.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c 2004-09-27 17:24:41.990= 753504 +0200 @@ -12,6 +12,7 @@ * * Fixes: * Vitaly E. Lavrov releasing NULL neighbor in neigh_add. + * Harald Welte Add neighbour cache statistics like rtstat */ =20 #include @@ -21,6 +22,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -59,6 +61,7 @@ =20 static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; +static struct file_operations neigh_stat_seq_fops; =20 /* Neighbour hash table buckets are protected with rwlock tbl->lock. @@ -115,6 +118,8 @@ int shrunk =3D 0, num_incomplete =3D 0, reap_incomplete =3D 0; int i; =20 + NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs); + write_lock_bh(&tbl->lock); rescan: for (i =3D 0; i <=3D tbl->hash_mask; i++) { @@ -161,6 +166,7 @@ if (reap_incomplete =3D=3D 0 && shrunk < goal && (shrunk + num_incomplete) >=3D goal) { + NEIGH_CACHE_STAT_INC(tbl, forced_gc_goal_miss); reap_incomplete =3D 1; goto rescan; } @@ -299,7 +305,8 @@ init_timer(&n->timer); n->timer.function =3D neigh_timer_handler; n->timer.data =3D (unsigned long)n; - tbl->stats.allocs++; + + NEIGH_CACHE_STAT_INC(tbl, allocs); neigh_glbl_allocs++; tbl->entries++; n->tbl =3D tbl; @@ -341,6 +348,8 @@ struct neighbour **new_hash, **old_hash; unsigned int i, new_hash_mask, old_entries; =20 + NEIGH_CACHE_STAT_INC(tbl, hash_grows); + BUG_ON(new_entries & (new_entries - 1)); new_hash =3D neigh_hash_alloc(new_entries); if (!new_hash) @@ -375,11 +384,14 @@ struct neighbour *n; int key_len =3D tbl->key_len; u32 hash_val =3D tbl->hash(pkey, dev) & tbl->hash_mask; +=09 + NEIGH_CACHE_STAT_INC(tbl, lookups); =20 read_lock_bh(&tbl->lock); for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (dev =3D=3D n->dev && !memcmp(n->primary_key, pkey, key_len)) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -393,10 +405,13 @@ int key_len =3D tbl->key_len; u32 hash_val =3D tbl->hash(pkey, NULL) & tbl->hash_mask; =20 + NEIGH_CACHE_STAT_INC(tbl, lookups); + read_lock_bh(&tbl->lock); for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (!memcmp(n->primary_key, pkey, key_len)) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -581,6 +596,8 @@ { struct hh_cache *hh; =20 + NEIGH_CACHE_STAT_INC(neigh->tbl, destroys); + if (!neigh->dead) { printk(KERN_WARNING "Destroying alive neighbour %p\n", neigh); @@ -656,6 +673,8 @@ struct neighbour *n, **np; unsigned long expire, now =3D jiffies; =20 + NEIGH_CACHE_STAT_INC(tbl, periodic_gc_runs); + write_lock(&tbl->lock); =20 /* @@ -787,7 +806,7 @@ =20 neigh->nud_state =3D NUD_FAILED; notify =3D 1; - neigh->tbl->stats.res_failed++; + NEIGH_CACHE_STAT_INC(neigh->tbl, res_failed); NEIGH_PRINTK2("neigh %p is failed.\n", neigh); =20 /* It is very thin place. report_unreachable is very complicated @@ -1336,6 +1355,29 @@ if (!tbl->kmem_cachep) panic("cannot create neighbour cache"); =20 + tbl->stats =3D alloc_percpu(struct neigh_statistics); + if (!tbl->stats) + panic("cannot create neighbour cache statistics"); +=09 +#ifdef CONFIG_PROC_FS +#define NC_STAT_SUFFIX "_stat" + { + char *proc_stat_name; + proc_stat_name =3D kmalloc(strlen(tbl->id) +=20 + strlen(NC_STAT_SUFFIX) + 1, GFP_KERNEL); + if (!proc_stat_name) + panic("cannot allocate neighbour cache proc name buffer"); + strcpy(proc_stat_name, tbl->id); + strcat(proc_stat_name, NC_STAT_SUFFIX); + + tbl->pde =3D create_proc_entry(proc_stat_name, 0, proc_net); + if (!tbl->pde)=20 + panic("cannot create neighbour proc dir entry"); + tbl->pde->proc_fops =3D &neigh_stat_seq_fops; + tbl->pde->data =3D tbl; + } +#endif + tbl->hash_mask =3D 0x1f; tbl->hash_buckets =3D neigh_hash_alloc(tbl->hash_mask + 1); =20 @@ -1882,6 +1924,107 @@ } EXPORT_SYMBOL(neigh_seq_stop); =20 +/* statistics via seq_file */ + +static void *neigh_stat_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int cpu; + + if (*pos =3D=3D 0) + return SEQ_START_TOKEN; +=09 + for (cpu =3D *pos-1; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos =3D cpu+1; + return per_cpu_ptr(tbl->stats, cpu); + } + return NULL; +} + +static void *neigh_stat_seq_next(struct seq_file *seq, void *v, loff_t *po= s) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int cpu; + + for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos =3D cpu+1; + return per_cpu_ptr(tbl->stats, cpu); + } + return NULL; +} + +static void neigh_stat_seq_stop(struct seq_file *seq, void *v) +{ + +} + +static int neigh_stat_seq_show(struct seq_file *seq, void *v) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + struct neigh_statistics *st =3D v; + + if (v =3D=3D SEQ_START_TOKEN) { + seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_= failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs = forced_gc_goal_miss\n"); + return 0; + } + + seq_printf(seq, "%08x %08x %08x %08x %08x %08x %08x %08x %08x " + "%08x %08x %08x\n", + tbl->entries, + + st->allocs, + st->destroys, + st->hash_grows, + + st->lookups, + st->hits, + + st->res_failed, + + st->rcv_probes_mcast, + st->rcv_probes_ucast, + + st->periodic_gc_runs, + st->forced_gc_runs, + st->forced_gc_goal_miss + ); + + return 0; +} + +static struct seq_operations neigh_stat_seq_ops =3D { + .start =3D neigh_stat_seq_start, + .next =3D neigh_stat_seq_next, + .stop =3D neigh_stat_seq_stop, + .show =3D neigh_stat_seq_show, +}; + +static int neigh_stat_seq_open(struct inode *inode, struct file *file) +{ + int ret =3D seq_open(file, &neigh_stat_seq_ops); + + if (!ret) { + struct seq_file *sf =3D file->private_data; + sf->private =3D PDE(inode); + } + return ret; +}; + +static struct file_operations neigh_stat_seq_fops =3D { + .owner =3D THIS_MODULE, + .open =3D neigh_stat_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release, +}; + #endif /* CONFIG_PROC_FS */ =20 #ifdef CONFIG_ARPD Index: linux-2.6.9-rc2-bk9-neigh1/net/ipv6/ndisc.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/ipv6/ndisc.c 2004-09-26 12:29:03.00= 0000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/ipv6/ndisc.c 2004-09-26 23:30:56.0000000= 00 +0200 @@ -802,9 +802,9 @@ } =20 if (inc) - nd_tbl.stats.rcv_probes_mcast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_mcast); else - nd_tbl.stats.rcv_probes_ucast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_ucast); =20 /*=20 * update / create cache entry --1AxFftPZlP9RA4ZR-- --I2z5DWo3OKf2mlg0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWD6GXaXGVTD0i/8RAn0TAKCBonyyrybY1T1RgxJ1wnbNjaRCUwCgnFlG uzPyv10PJtowIPdhs0nUEfY= =w/UB -----END PGP SIGNATURE----- --I2z5DWo3OKf2mlg0-- From ganesh.venkatesan@intel.com Mon Sep 27 09:34:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 09:34:31 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RGYPED024380 for ; Mon, 27 Sep 2004 09:34:25 -0700 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8RGaGTH002476; Mon, 27 Sep 2004 16:36:16 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8RGb3rb015021; Mon, 27 Sep 2004 16:37:22 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004092709341031892 ; Mon, 27 Sep 2004 09:34:10 -0700 Date: Mon, 27 Sep 2004 09:34:10 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [patch 1/1 2.4] e1000 update - reset default ITR value to 8000 Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 588 Lines: 17 diff -up linux-2.4/drivers/net/e1000/e1000_param.c linux-2.4/drivers/net/e1000.new/e1000_param.c --- linux-2.4/drivers/net/e1000/e1000_param.c 2004-09-20 21:21:20.000000000 -0700 +++ linux-2.4/drivers/net/e1000.new/e1000_param.c 2004-09-20 21:32:07.000000000 -0700 @@ -211,7 +211,7 @@ E1000_PARAM(InterruptThrottleRate, "Inte #define MAX_TXABSDELAY 0xFFFF #define MIN_TXABSDELAY 0 -#define DEFAULT_ITR 1 +#define DEFAULT_ITR 8000 #define MAX_ITR 100000 #define MIN_ITR 100 From ganesh.venkatesan@intel.com Mon Sep 27 09:38:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 09:38:11 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RGc4fK024811 for ; Mon, 27 Sep 2004 09:38:05 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8RGbeJa013460; Mon, 27 Sep 2004 16:37:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8RGeuNW017035; Mon, 27 Sep 2004 16:40:57 GMT Received: from [10.23.51.23] ([10.23.51.23]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004092709374406059 ; Mon, 27 Sep 2004 09:37:44 -0700 Date: Mon, 27 Sep 2004 09:37:45 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [patch 1/2 2.5] e1000 update -- fix MODULE_PARM, module_param, module_param_array usage Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 9774 Lines: 317 diff -up linux-2.5/drivers/net/e1000/e1000.h linux-2.5/drivers/net/e1000.new/e1000.h --- linux-2.5/drivers/net/e1000/e1000.h 2004-09-20 21:54:32.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000.h 2004-09-20 21:54:33.000000000 -0700 @@ -72,7 +72,6 @@ #include #include #include -#include #define BAR_0 0 #define BAR_1 1 diff -up linux-2.5/drivers/net/e1000/e1000_param.c linux-2.5/drivers/net/e1000.new/e1000_param.c --- linux-2.5/drivers/net/e1000/e1000_param.c 2004-09-20 21:54:32.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_param.c 2004-09-20 21:54:34.000000000 -0700 @@ -34,31 +34,21 @@ #define E1000_MAX_NIC 32 -#define OPTION_UNSET -1 +#define OPTION_UNSET -1 #define OPTION_DISABLED 0 #define OPTION_ENABLED 1 -/* Module Parameters are always initialized to -1, so that the driver - * can tell the difference between no user specified value or the - * user asking for the default value. - * The true default values are loaded in when e1000_check_options is called. - * - * This is a GCC extension to ANSI C. - * See the item "Labeled Elements in Initializers" in the section - * "Extensions to the C Language Family" of the GCC documentation. - */ - -#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET } - /* All parameters are treated the same, as an integer array of values. * This macro just reduces the need to repeat the same declaration code * over and over (plus this helps to avoid typo bugs). */ -#define E1000_PARAM(X, S) \ -static const int __devinitdata X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \ -MODULE_PARM(X, "1-" __MODULE_STRING(E1000_MAX_NIC) "i"); \ -MODULE_PARM_DESC(X, S); +#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET } +#define E1000_PARAM(X, desc) \ + static int __devinitdata X[E1000_MAX_NIC+1] = E1000_PARAM_INIT; \ + static int num_##X = 0; \ + module_param_array(X, int, num_##X, 0); \ + MODULE_PARM_DESC(X, desc); /* Transmit Descriptor Count * @@ -305,7 +295,6 @@ e1000_check_options(struct e1000_adapter DPRINTK(PROBE, NOTICE, "Warning: no configuration for board #%i\n", bd); DPRINTK(PROBE, NOTICE, "Using defaults for all values\n"); - bd = E1000_MAX_NIC; } { /* Transmit Descriptor Count */ @@ -322,9 +311,14 @@ e1000_check_options(struct e1000_adapter opt.arg.r.max = mac_type < e1000_82544 ? E1000_MAX_TXD : E1000_MAX_82544_TXD; - tx_ring->count = TxDescriptors[bd]; - e1000_validate_option(&tx_ring->count, &opt, adapter); - E1000_ROUNDUP(tx_ring->count, REQ_TX_DESCRIPTOR_MULTIPLE); + if (num_TxDescriptors > bd) { + tx_ring->count = TxDescriptors[bd]; + e1000_validate_option(&tx_ring->count, &opt, adapter); + E1000_ROUNDUP(tx_ring->count, + REQ_TX_DESCRIPTOR_MULTIPLE); + } else { + tx_ring->count = opt.def; + } } { /* Receive Descriptor Count */ struct e1000_option opt = { @@ -340,9 +334,14 @@ e1000_check_options(struct e1000_adapter opt.arg.r.max = mac_type < e1000_82544 ? E1000_MAX_RXD : E1000_MAX_82544_RXD; - rx_ring->count = RxDescriptors[bd]; - e1000_validate_option(&rx_ring->count, &opt, adapter); - E1000_ROUNDUP(rx_ring->count, REQ_RX_DESCRIPTOR_MULTIPLE); + if (num_RxDescriptors > bd) { + rx_ring->count = RxDescriptors[bd]; + e1000_validate_option(&rx_ring->count, &opt, adapter); + E1000_ROUNDUP(rx_ring->count, + REQ_RX_DESCRIPTOR_MULTIPLE); + } else { + rx_ring->count = opt.def; + } } { /* Checksum Offload Enable/Disable */ struct e1000_option opt = { @@ -352,9 +351,13 @@ e1000_check_options(struct e1000_adapter .def = OPTION_ENABLED }; - int rx_csum = XsumRX[bd]; - e1000_validate_option(&rx_csum, &opt, adapter); - adapter->rx_csum = rx_csum; + if (num_XsumRX > bd) { + int rx_csum = XsumRX[bd]; + e1000_validate_option(&rx_csum, &opt, adapter); + adapter->rx_csum = rx_csum; + } else { + adapter->rx_csum = opt.def; + } } { /* Flow Control */ @@ -374,9 +377,13 @@ e1000_check_options(struct e1000_adapter .p = fc_list }} }; - int fc = FlowControl[bd]; - e1000_validate_option(&fc, &opt, adapter); - adapter->hw.fc = adapter->hw.original_fc = fc; + if (num_FlowControl > bd) { + int fc = FlowControl[bd]; + e1000_validate_option(&fc, &opt, adapter); + adapter->hw.fc = adapter->hw.original_fc = fc; + } else { + adapter->hw.fc = opt.def; + } } { /* Transmit Interrupt Delay */ struct e1000_option opt = { @@ -388,8 +395,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_TXDELAY }} }; - adapter->tx_int_delay = TxIntDelay[bd]; - e1000_validate_option(&adapter->tx_int_delay, &opt, adapter); + if (num_TxIntDelay > bd) { + adapter->tx_int_delay = TxIntDelay[bd]; + e1000_validate_option(&adapter->tx_int_delay, &opt, + adapter); + } else { + adapter->tx_int_delay = opt.def; + } } { /* Transmit Absolute Interrupt Delay */ struct e1000_option opt = { @@ -401,8 +413,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_TXABSDELAY }} }; - adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; - e1000_validate_option(&adapter->tx_abs_int_delay, &opt, adapter); + if (num_TxAbsIntDelay > bd) { + adapter->tx_abs_int_delay = TxAbsIntDelay[bd]; + e1000_validate_option(&adapter->tx_abs_int_delay, &opt, + adapter); + } else { + adapter->tx_abs_int_delay = opt.def; + } } { /* Receive Interrupt Delay */ struct e1000_option opt = { @@ -414,8 +431,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_RXDELAY }} }; - adapter->rx_int_delay = RxIntDelay[bd]; - e1000_validate_option(&adapter->rx_int_delay, &opt, adapter); + if (num_RxIntDelay > bd) { + adapter->rx_int_delay = RxIntDelay[bd]; + e1000_validate_option(&adapter->rx_int_delay, &opt, + adapter); + } else { + adapter->rx_int_delay = opt.def; + } } { /* Receive Absolute Interrupt Delay */ struct e1000_option opt = { @@ -427,8 +449,13 @@ e1000_check_options(struct e1000_adapter .max = MAX_RXABSDELAY }} }; - adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; - e1000_validate_option(&adapter->rx_abs_int_delay, &opt, adapter); + if (num_RxAbsIntDelay > bd) { + adapter->rx_abs_int_delay = RxAbsIntDelay[bd]; + e1000_validate_option(&adapter->rx_abs_int_delay, &opt, + adapter); + } else { + adapter->rx_abs_int_delay = opt.def; + } } { /* Interrupt Throttling Rate */ struct e1000_option opt = { @@ -440,20 +467,27 @@ e1000_check_options(struct e1000_adapter .max = MAX_ITR }} }; - adapter->itr = InterruptThrottleRate[bd]; - switch(adapter->itr) { - case -1: + if (num_InterruptThrottleRate > bd) { + adapter->itr = InterruptThrottleRate[bd]; + switch(adapter->itr) { + case -1: + adapter->itr = 1; + break; + case 0: + DPRINTK(PROBE, INFO, "%s turned off\n", + opt.name); + break; + case 1: + DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", + opt.name); + break; + default: + e1000_validate_option(&adapter->itr, &opt, + adapter); + break; + } + } else { adapter->itr = 1; - break; - case 0: - DPRINTK(PROBE, INFO, "%s turned off\n", opt.name); - break; - case 1: - DPRINTK(PROBE, INFO, "%s set to dynamic mode\n", opt.name); - break; - default: - e1000_validate_option(&adapter->itr, &opt, adapter); - break; } } @@ -481,17 +515,17 @@ static void __devinit e1000_check_fiber_options(struct e1000_adapter *adapter) { int bd = adapter->bd_number; - bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; - - if((Speed[bd] != OPTION_UNSET)) { + if(num_Speed > bd) { DPRINTK(PROBE, INFO, "Speed not valid for fiber adapters, " "parameter ignored\n"); } - if((Duplex[bd] != OPTION_UNSET)) { + + if(num_Duplex > bd) { DPRINTK(PROBE, INFO, "Duplex not valid for fiber adapters, " "parameter ignored\n"); } - if((AutoNeg[bd] != OPTION_UNSET) && (AutoNeg[bd] != 0x20)) { + + if((num_AutoNeg > bd) && (AutoNeg[bd] != 0x20)) { DPRINTK(PROBE, INFO, "AutoNeg other than 1000/Full is " "not valid for fiber adapters, " "parameter ignored\n"); @@ -510,7 +544,6 @@ e1000_check_copper_options(struct e1000_ { int speed, dplx; int bd = adapter->bd_number; - bd = bd > E1000_MAX_NIC ? E1000_MAX_NIC : bd; { /* Speed */ struct e1000_opt_list speed_list[] = {{ 0, "" }, @@ -527,8 +560,12 @@ e1000_check_copper_options(struct e1000_ .p = speed_list }} }; - speed = Speed[bd]; - e1000_validate_option(&speed, &opt, adapter); + if (num_Speed > bd) { + speed = Speed[bd]; + e1000_validate_option(&speed, &opt, adapter); + } else { + speed = opt.def; + } } { /* Duplex */ struct e1000_opt_list dplx_list[] = {{ 0, "" }, @@ -544,11 +581,15 @@ e1000_check_copper_options(struct e1000_ .p = dplx_list }} }; - dplx = Duplex[bd]; - e1000_validate_option(&dplx, &opt, adapter); + if (num_Duplex > bd) { + dplx = Duplex[bd]; + e1000_validate_option(&dplx, &opt, adapter); + } else { + dplx = opt.def; + } } - if(AutoNeg[bd] != OPTION_UNSET && (speed != 0 || dplx != 0)) { + if((num_AutoNeg > bd) && (speed != 0 || dplx != 0)) { DPRINTK(PROBE, INFO, "AutoNeg specified along with Speed or Duplex, " "parameter ignored\n"); @@ -605,7 +646,7 @@ e1000_check_copper_options(struct e1000_ switch (speed + dplx) { case 0: adapter->hw.autoneg = adapter->fc_autoneg = 1; - if(Speed[bd] != OPTION_UNSET || Duplex[bd] != OPTION_UNSET) + if((num_Speed > bd) && (speed != 0 || dplx != 0)) DPRINTK(PROBE, INFO, "Speed and duplex autonegotiation enabled\n"); break; Only in linux-2.5/drivers/net/e1000.new: kcompat_ethtool.c From ganesh.venkatesan@intel.com Mon Sep 27 09:38:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 09:38:49 -0700 (PDT) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RGciAa024983 for ; Mon, 27 Sep 2004 09:38:44 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8RGgb7G020771; Mon, 27 Sep 2004 16:42:37 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8RGgTJd027449; Mon, 27 Sep 2004 16:42:41 GMT Received: from [10.23.51.23] ([10.23.51.23]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004092709382724182 ; Mon, 27 Sep 2004 09:38:27 -0700 Date: Mon, 27 Sep 2004 09:38:27 -0700 (PDT) From: Ganesh Venkatesan To: jgarzik@pobox.com cc: netdev@oss.sgi.com Subject: [patch 2/2 2.5] e1000 update - white space/driver version update Message-ID: ReplyTo: "Ganesh Venkatesan" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 9509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganesh.venkatesan@intel.com Precedence: bulk X-list: netdev Content-Length: 1224 Lines: 33 diff -up linux-2.5/drivers/net/e1000/e1000_ethtool.c linux-2.5/drivers/net/e1000.new/e1000_ethtool.c --- linux-2.5/drivers/net/e1000/e1000_ethtool.c 2004-09-20 21:54:32.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_ethtool.c 2004-09-20 21:54:33.000000000 -0700 @@ -1017,8 +1017,8 @@ e1000_setup_desc_rings(struct e1000_adap struct e1000_rx_desc *rx_desc = E1000_RX_DESC(*rxdr, i); struct sk_buff *skb; - if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, - GFP_KERNEL))) { + if(!(skb = alloc_skb(E1000_RXBUFFER_2048 + NET_IP_ALIGN, + GFP_KERNEL))) { ret_val = 6; goto err_nomem; } diff -up linux-2.5/drivers/net/e1000/e1000_main.c linux-2.5/drivers/net/e1000.new/e1000_main.c --- linux-2.5/drivers/net/e1000/e1000_main.c 2004-09-20 21:54:32.000000000 -0700 +++ linux-2.5/drivers/net/e1000.new/e1000_main.c 2004-09-20 21:54:34.000000000 -0700 @@ -48,7 +48,7 @@ char e1000_driver_string[] = "Intel(R) P #else #define DRIVERNAPI "-NAPI" #endif -char e1000_driver_version[] = "5.3.19-k2"DRIVERNAPI; +char e1000_driver_version[] = "5.4.11-k2"DRIVERNAPI; char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation."; /* e1000_pci_tbl - PCI Device ID Table From bob@kunk.qbjnet.com Mon Sep 27 10:10:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 10:10:29 -0700 (PDT) Received: from kunk.qbjnet.com (ddsl1-28.ddsl.mr.net [137.192.135.28]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8RHANFi026203 for ; Mon, 27 Sep 2004 10:10:24 -0700 Received: (qmail 20026 invoked by uid 1000); 27 Sep 2004 17:10:11 -0000 Message-ID: <20040927171011.20025.qmail@kunk.qbjnet.com> From: bob@kunk.qbjnet.com Subject: AX25 driver appears broken in PPC 2.6.x To: netdev@oss.sgi.com Date: Mon, 27 Sep 2004 12:10:11 -0500 (CDT) CC: acme@conectiva.com.br X-Mailer: ELM [version 2.4ME+ PL118 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-archive-position: 9510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bob@kunk.qbjnet.com Precedence: bulk X-list: netdev Content-Length: 1239 Lines: 29 It looks to me like there is a problem with the AX25 code in 2.6 PPC machines. I tested both a YAM modem and a KISS serial TNC with an x86 box running 2.6.7 and a couple of different PPC boxes also running 2.6.7 as well as trying 2.4.27 on the PPC boxes too. These boxes are running the same version of debian linux (sarge) and have as close as possible equivalent kernels. Using the ax25 call command (i.e. call N0TL-3) I can get connections with both the PPC and x86 2.6.7 systems. HOWEVER the TCP/IP stack only seems to work with ax25 on the x86 box. Same hardware, same software, same configuration. If I drop the PPC kernel back to 2.4.27, it works perfect. With 2.6.7 on the PPC box, it appears that received packets are being ignored or routed incorrectly somehow (the routing tables are the same though). Doing a simple test using ping, I can see the incoming echo reply packets using listen on the appropriate ax25 port however they seem to be going into the bitbucket as fas as TCP/IP is concerned. Regards, Bob -- /~\ The ASCII | Robert E. Brose II N0QBJ \ / Ribbon Campaign | http://www.qbjnet.com/ X Help cure | bob (at) qbjnet.com / \ HTML Email | public key at http://www.qbjnet.com/key.html From eric.lemoine@gmail.com Mon Sep 27 10:30:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 10:30:44 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RHUckJ027172 for ; Mon, 27 Sep 2004 10:30:39 -0700 Received: by mproxy.gmail.com with SMTP id 77so3664539rnk for ; Mon, 27 Sep 2004 10:30:23 -0700 (PDT) Received: by 10.38.171.50 with SMTP id t50mr205387rne; Mon, 27 Sep 2004 10:30:22 -0700 (PDT) Received: by 10.38.99.58 with HTTP; Mon, 27 Sep 2004 10:30:21 -0700 (PDT) Message-ID: <5cac192f04092710304a3d28b2@mail.gmail.com> Date: Mon, 27 Sep 2004 19:30:21 +0200 From: Eric Lemoine Reply-To: Eric Lemoine To: Robert Olsson Subject: Re: [PATCH 2.6] natsemi.c NAPI Cc: Harald Welte , netdev@oss.sgi.com In-Reply-To: <16727.60345.857450.162620@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040919163642.GC1307@sunbeam.de.gnumonks.org> <4155D781.8050700@colorfullife.com> <20040927091148.GF3236@sunbeam.de.gnumonks.org> <16727.60345.857450.162620@robur.slu.se> X-archive-position: 9511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: eric.lemoine@gmail.com Precedence: bulk X-list: netdev Content-Length: 802 Lines: 19 > > I think this overall problem can be solved if there was some per-device > > variable that saves the IntrStatus until the NAPI callback gets > > scheduled. What do you think? This wouldn't even need some locking, > > since interrupts would be disabled before the field is updated, and not > > re-enabled before the field is read by the NAPI callback? > > > > I was surprised that this solution is not suggested in the NAPI-HOWTO.txt, so I though there must be an error in my proposal... > > > > By using such a scheme, isn't it also possible to only offload RX into > > the NAPI callback with clear-on-read devices? > > > > e1000 used such technique before.If a remember correctly IntrStatus was > saved in device priv struct. That's also how it is done in current sungem. -- Eric From shemminger@osdl.org Mon Sep 27 11:14:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 11:14:42 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RIEaeo028589 for ; Mon, 27 Sep 2004 11:14:37 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i8RIEJWL020181 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 27 Sep 2004 11:14:19 -0700 Date: Mon, 27 Sep 2004 11:18:34 -0700 From: Stephen Hemminger To: David Miller Cc: netdev@oss.sgi.com Subject: [PATCH] (1/3) tcp - choose congestion algorithm at initialization Message-Id: <20040927111834.48c7baab@zqx3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.85 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6421 Lines: 213 The choice of congestion algorithm needs to be made when connection is setup to avoid problems when the sysctl values change later and the necessary data hasn't been collected. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h 2004-09-27 10:56:46 -07:00 +++ b/include/linux/tcp.h 2004-09-27 10:56:46 -07:00 @@ -205,6 +205,13 @@ __u32 val; } tcp_pcount_t; +enum tcp_congestion_algo { + TCP_RENO=0, + TCP_VEGAS, + TCP_WESTWOOD, + TCP_BIC, +}; + struct tcp_opt { int tcp_header_len; /* Bytes of tcp header to send */ @@ -265,7 +272,7 @@ __u8 frto_counter; /* Number of new acks after RTO */ __u32 frto_highmark; /* snd_nxt when RTO occurred */ - __u8 unused_pad; + __u8 adv_cong; /* Using Vegas, Westwood, or BIC */ __u8 defer_accept; /* User waits for some data after accept() */ /* one byte hole, try to pack */ @@ -412,7 +419,6 @@ __u32 beg_snd_nxt; /* right edge during last RTT */ __u32 beg_snd_una; /* left edge during last RTT */ __u32 beg_snd_cwnd; /* saves the size of the cwnd */ - __u8 do_vegas; /* do vegas for this connection */ __u8 doing_vegas_now;/* if true, do vegas for this RTT */ __u16 cntRTT; /* # of RTTs measured within last RTT */ __u32 minRTT; /* min of RTTs measured within last RTT (in usec) */ diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-09-27 10:56:46 -07:00 +++ b/include/net/tcp.h 2004-09-27 10:56:46 -07:00 @@ -1271,6 +1271,13 @@ tcp_get_pcount(&tp->retrans_out)); } +/* + * Which congestion algorithim is in use on the connection. + */ +#define tcp_is_vegas(__tp) ((__tp)->adv_cong == TCP_VEGAS) +#define tcp_is_westwood(__tp) ((__tp)->adv_cong == TCP_WESTWOOD) +#define tcp_is_bic(__tp) ((__tp)->adv_cong == TCP_BIC) + /* Recalculate snd_ssthresh, we want to set it to: * * Reno: @@ -1283,7 +1290,7 @@ */ static inline __u32 tcp_recalc_ssthresh(struct tcp_opt *tp) { - if (sysctl_tcp_bic) { + if (tcp_is_bic(tp)) { if (sysctl_tcp_bic_fast_convergence && tp->snd_cwnd < tp->bictcp.last_max_cwnd) tp->bictcp.last_max_cwnd @@ -1302,11 +1309,6 @@ /* Stop taking Vegas samples for now. */ #define tcp_vegas_disable(__tp) ((__tp)->vegas.doing_vegas_now = 0) - -/* Is this TCP connection using Vegas (regardless of whether it is taking - * Vegas measurements at the current time)? - */ -#define tcp_is_vegas(__tp) ((__tp)->vegas.do_vegas) static inline void tcp_vegas_enable(struct tcp_opt *tp) { @@ -1340,7 +1342,7 @@ /* Should we be taking Vegas samples right now? */ #define tcp_vegas_enabled(__tp) ((__tp)->vegas.doing_vegas_now) -extern void tcp_vegas_init(struct tcp_opt *tp); +extern void tcp_ca_init(struct tcp_opt *tp); static inline void tcp_set_ca_state(struct tcp_opt *tp, u8 ca_state) { @@ -2024,7 +2026,7 @@ static inline void tcp_westwood_update_rtt(struct tcp_opt *tp, __u32 rtt_seq) { - if (sysctl_tcp_westwood) + if (tcp_is_westwood(tp)) tp->westwood.rtt = rtt_seq; } @@ -2033,13 +2035,13 @@ static inline void tcp_westwood_fast_bw(struct sock *sk, struct sk_buff *skb) { - if (sysctl_tcp_westwood) + if (tcp_is_westwood(tcp_sk(sk))) __tcp_westwood_fast_bw(sk, skb); } static inline void tcp_westwood_slow_bw(struct sock *sk, struct sk_buff *skb) { - if (sysctl_tcp_westwood) + if (tcp_is_westwood(tcp_sk(sk))) __tcp_westwood_slow_bw(sk, skb); } @@ -2052,14 +2054,14 @@ static inline __u32 tcp_westwood_bw_rttmin(const struct tcp_opt *tp) { - return sysctl_tcp_westwood ? __tcp_westwood_bw_rttmin(tp) : 0; + return tcp_is_westwood(tp) ? __tcp_westwood_bw_rttmin(tp) : 0; } static inline int tcp_westwood_ssthresh(struct tcp_opt *tp) { __u32 ssthresh = 0; - if (sysctl_tcp_westwood) { + if (tcp_is_westwood(tp)) { ssthresh = __tcp_westwood_bw_rttmin(tp); if (ssthresh) tp->snd_ssthresh = ssthresh; @@ -2072,7 +2074,7 @@ { __u32 cwnd = 0; - if (sysctl_tcp_westwood) { + if (tcp_is_westwood(tp)) { cwnd = __tcp_westwood_bw_rttmin(tp); if (cwnd) tp->snd_cwnd = cwnd; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-09-27 10:56:46 -07:00 +++ b/net/ipv4/tcp_input.c 2004-09-27 10:56:46 -07:00 @@ -555,17 +555,20 @@ tcp_grow_window(sk, tp, skb); } -/* Set up a new TCP connection, depending on whether it should be - * using Vegas or not. - */ -void tcp_vegas_init(struct tcp_opt *tp) +/* When starting a new connection, pin down the current choice of + * congestion algorithm. + */ +void tcp_ca_init(struct tcp_opt *tp) { - if (sysctl_tcp_vegas_cong_avoid) { - tp->vegas.do_vegas = 1; + if (sysctl_tcp_westwood) + tp->adv_cong = TCP_WESTWOOD; + else if (sysctl_tcp_bic) + tp->adv_cong = TCP_BIC; + else if (sysctl_tcp_vegas_cong_avoid) { + tp->adv_cong = TCP_VEGAS; tp->vegas.baseRTT = 0x7fffffff; tcp_vegas_enable(tp); - } else - tcp_vegas_disable(tp); + } } /* Do RTT sampling needed for Vegas. @@ -2039,7 +2042,7 @@ static inline __u32 bictcp_cwnd(struct tcp_opt *tp) { /* orignal Reno behaviour */ - if (!sysctl_tcp_bic) + if (!tcp_is_bic(tp)) return tp->snd_cwnd; if (tp->bictcp.last_cwnd == tp->snd_cwnd && diff -Nru a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c --- a/net/ipv4/tcp_minisocks.c 2004-09-27 10:56:46 -07:00 +++ b/net/ipv4/tcp_minisocks.c 2004-09-27 10:56:46 -07:00 @@ -841,7 +841,8 @@ if (newtp->ecn_flags&TCP_ECN_OK) newsk->sk_no_largesend = 1; - tcp_vegas_init(newtp); + tcp_ca_init(newtp); + TCP_INC_STATS_BH(TCP_MIB_PASSIVEOPENS); } return newsk; diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-27 10:56:46 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-27 10:56:46 -07:00 @@ -1359,7 +1359,7 @@ tp->window_clamp = dst_metric(dst, RTAX_WINDOW); tp->advmss = dst_metric(dst, RTAX_ADVMSS); tcp_initialize_rcv_mss(sk); - tcp_vegas_init(tp); + tcp_ca_init(tp); tcp_select_initial_window(tcp_full_space(sk), tp->advmss - (tp->ts_recent_stamp ? tp->tcp_header_len - sizeof(struct tcphdr) : 0), @@ -1411,7 +1411,7 @@ TCP_SKB_CB(buff)->end_seq = tp->write_seq; tp->snd_nxt = tp->write_seq; tp->pushed_seq = tp->write_seq; - tcp_vegas_init(tp); + tcp_ca_init(tp); /* Send it off. */ TCP_SKB_CB(buff)->when = tcp_time_stamp; From shemminger@osdl.org Mon Sep 27 11:17:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 11:17:26 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RIHKqS028968 for ; Mon, 27 Sep 2004 11:17:20 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i8RIH3WL020376 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 27 Sep 2004 11:17:04 -0700 Date: Mon, 27 Sep 2004 11:21:18 -0700 From: Stephen Hemminger To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] (2/3) tcp - diagnostics enhancement for westwood Message-Id: <20040927112118.4c376303@zqx3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.85 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3310 Lines: 92 Enhancement to tcp diagnostics used by ss command. * use jiffies_to_usecs/msec instead of hardcode math * report bandwidth for Westwood Signed-off-by: Stephen Hemminger diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c 2004-09-27 10:27:00 -07:00 +++ b/net/ipv4/tcp_diag.c 2004-09-27 10:27:00 -07:00 @@ -41,6 +41,12 @@ rta->rta_len = rtalen; \ RTA_DATA(rta); }) +static inline unsigned int jiffies_to_usecs(const unsigned long j) +{ + return 1000*jiffies_to_msecs(j); +} + + /* Return information about state of tcp endpoint in API format. */ void tcp_get_info(struct sock *sk, struct tcp_info *info) { @@ -68,8 +74,8 @@ if (tp->ecn_flags&TCP_ECN_OK) info->tcpi_options |= TCPI_OPT_ECN; - info->tcpi_rto = (1000000*tp->rto)/HZ; - info->tcpi_ato = (1000000*tp->ack.ato)/HZ; + info->tcpi_rto = jiffies_to_usecs(tp->rto); + info->tcpi_ato = jiffies_to_usecs(tp->ack.ato); info->tcpi_snd_mss = tp->mss_cache_std; info->tcpi_rcv_mss = tp->ack.rcv_mss; @@ -79,20 +85,20 @@ info->tcpi_retrans = tcp_get_pcount(&tp->retrans_out); info->tcpi_fackets = tcp_get_pcount(&tp->fackets_out); - info->tcpi_last_data_sent = ((now - tp->lsndtime)*1000)/HZ; - info->tcpi_last_data_recv = ((now - tp->ack.lrcvtime)*1000)/HZ; - info->tcpi_last_ack_recv = ((now - tp->rcv_tstamp)*1000)/HZ; + info->tcpi_last_data_sent = jiffies_to_msecs(now - tp->lsndtime); + info->tcpi_last_data_recv = jiffies_to_msecs(now - tp->ack.lrcvtime); + info->tcpi_last_ack_recv = jiffies_to_msecs(now - tp->rcv_tstamp); info->tcpi_pmtu = tp->pmtu_cookie; info->tcpi_rcv_ssthresh = tp->rcv_ssthresh; - info->tcpi_rtt = ((1000000*tp->srtt)/HZ)>>3; - info->tcpi_rttvar = ((1000000*tp->mdev)/HZ)>>2; + info->tcpi_rtt = jiffies_to_usecs(tp->srtt)>>3; + info->tcpi_rttvar = jiffies_to_usecs(tp->mdev)>>2; info->tcpi_snd_ssthresh = tp->snd_ssthresh; info->tcpi_snd_cwnd = tp->snd_cwnd; info->tcpi_advmss = tp->advmss; info->tcpi_reordering = tp->reordering; - info->tcpi_rcv_rtt = ((1000000*tp->rcv_rtt_est.rtt)/HZ)>>3; + info->tcpi_rcv_rtt = jiffies_to_usecs(tp->rcv_rtt_est.rtt)>>3; info->tcpi_rcv_space = tp->rcvq_space.space; } @@ -116,7 +122,8 @@ if (ext & (1<<(TCPDIAG_INFO-1))) info = TCPDIAG_PUT(skb, TCPDIAG_INFO, sizeof(*info)); - if (tcp_is_vegas(tp) && (ext & (1<<(TCPDIAG_VEGASINFO-1)))) + if ((tcp_is_westwood(tp) || tcp_is_vegas(tp)) + && (ext & (1<<(TCPDIAG_VEGASINFO-1)))) vinfo = TCPDIAG_PUT(skb, TCPDIAG_VEGASINFO, sizeof(*vinfo)); } r->tcpdiag_family = sk->sk_family; @@ -209,10 +216,17 @@ tcp_get_info(sk, info); if (vinfo) { - vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; - vinfo->tcpv_rttcnt = tp->vegas.cntRTT; - vinfo->tcpv_rtt = tp->vegas.baseRTT; - vinfo->tcpv_minrtt = tp->vegas.minRTT; + if (tcp_is_vegas(tp)) { + vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; + vinfo->tcpv_rttcnt = tp->vegas.cntRTT; + vinfo->tcpv_rtt = jiffies_to_usecs(tp->vegas.baseRTT); + vinfo->tcpv_minrtt = jiffies_to_usecs(tp->vegas.minRTT); + } else { + vinfo->tcpv_enabled = 0; + vinfo->tcpv_rttcnt = 0; + vinfo->tcpv_rtt = jiffies_to_usecs(tp->westwood.rtt); + vinfo->tcpv_minrtt = jiffies_to_usecs(tp->westwood.rtt_min); + } } nlh->nlmsg_len = skb->tail - b; From davem@davemloft.net Mon Sep 27 11:18:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 11:18:23 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RIIHLk029324 for ; Mon, 27 Sep 2004 11:18:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC01w-0006bT-00; Mon, 27 Sep 2004 11:15:20 -0700 Date: Mon, 27 Sep 2004 11:15:20 -0700 From: "David S. Miller" To: Herbert Xu Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040927111520.4f495b17.davem@davemloft.net> In-Reply-To: References: <20040925005623.2faf8faf.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 583 Lines: 16 On Mon, 27 Sep 2004 21:48:33 +1000 Herbert Xu wrote: > > - if (tbl->entries > (tbl->hash_mask + 1)) > > + if (tbl->entries > (tbl->hash_mask + 1)) { > > + write_lock_bh(&tbl->lock); > > neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); > > + write_unlock_bh(&tbl->lock); > > + } > > The locking should be outside the if block as otherwise you may grow > unnecessarily or grow into the same size :) I'm not going to do that, because then we're grabbing that lock twice on every neigh create operation and I was trying hard to avoid that overhead. From shemminger@osdl.org Mon Sep 27 11:18:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 11:18:58 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RIIp5h029522 for ; Mon, 27 Sep 2004 11:18:52 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i8RIIYWL020517 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 27 Sep 2004 11:18:34 -0700 Date: Mon, 27 Sep 2004 11:22:49 -0700 From: Stephen Hemminger To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] (3/3) tcp westwood cleanup Message-Id: <20040927112249.38bea6ff@zqx3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.85 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2829 Lines: 108 Westwood code cleanup; * use const. * avoid needless paren's and returns * inline acked_count (called once) diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-09-27 10:26:03 -07:00 +++ b/net/ipv4/tcp_input.c 2004-09-27 10:26:03 -07:00 @@ -2620,18 +2620,16 @@ * WESTWOOD_RTT_MIN minimum bound since we could be on a LAN! */ -static inline __u32 westwood_update_rttmin(struct sock *sk) +static inline __u32 westwood_update_rttmin(const struct sock *sk) { - struct tcp_opt *tp = tcp_sk(sk); + const struct tcp_opt *tp = tcp_sk(sk); __u32 rttmin = tp->westwood.rtt_min; - if (tp->westwood.rtt == 0) - return(rttmin); - - if (tp->westwood.rtt < tp->westwood.rtt_min || !rttmin) + if (tp->westwood.rtt != 0 && + (tp->westwood.rtt < tp->westwood.rtt_min || !rttmin)) rttmin = tp->westwood.rtt; - return(rttmin); + return rttmin; } /* @@ -2639,11 +2637,11 @@ * Evaluate increases for dk. */ -static inline __u32 westwood_acked(struct sock *sk) +static inline __u32 westwood_acked(const struct sock *sk) { - struct tcp_opt *tp = tcp_sk(sk); + const struct tcp_opt *tp = tcp_sk(sk); - return ((tp->snd_una) - (tp->westwood.snd_una)); + return tp->snd_una - tp->westwood.snd_una; } /* @@ -2655,9 +2653,9 @@ * window, 1 if the sample has to be considered in the next window. */ -static int westwood_new_window(struct sock *sk) +static int westwood_new_window(const struct sock *sk) { - struct tcp_opt *tp = tcp_sk(sk); + const struct tcp_opt *tp = tcp_sk(sk); __u32 left_bound; __u32 rtt; int ret = 0; @@ -2691,14 +2689,13 @@ struct tcp_opt *tp = tcp_sk(sk); __u32 delta = now - tp->westwood.rtt_win_sx; - if (!delta) - return; - - if (tp->westwood.rtt) - westwood_filter(sk, delta); - - tp->westwood.bk = 0; - tp->westwood.rtt_win_sx = tcp_time_stamp; + if (delta) { + if (tp->westwood.rtt) + westwood_filter(sk, delta); + + tp->westwood.bk = 0; + tp->westwood.rtt_win_sx = tcp_time_stamp; + } } @@ -2742,7 +2739,7 @@ static inline int westwood_may_change_cumul(struct tcp_opt *tp) { - return ((tp->westwood.cumul_ack) > tp->mss_cache_std); + return (tp->westwood.cumul_ack > tp->mss_cache_std); } static inline void westwood_partial_update(struct tcp_opt *tp) @@ -2763,7 +2760,7 @@ * delayed or partial acks. */ -static __u32 westwood_acked_count(struct sock *sk) +static inline __u32 westwood_acked_count(struct sock *sk) { struct tcp_opt *tp = tcp_sk(sk); @@ -2777,7 +2774,7 @@ if (westwood_may_change_cumul(tp)) { /* Partial or delayed ack */ - if ((tp->westwood.accounted) >= (tp->westwood.cumul_ack)) + if (tp->westwood.accounted >= tp->westwood.cumul_ack) westwood_partial_update(tp); else westwood_complete_update(tp); From davem@davemloft.net Mon Sep 27 12:00:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:00:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJ0Og8030917 for ; Mon, 27 Sep 2004 12:00:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0gu-0006gP-00; Mon, 27 Sep 2004 11:57:40 -0700 Date: Mon, 27 Sep 2004 11:57:40 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040927115740.4d4b4c2a.davem@davemloft.net> In-Reply-To: <20040927092933.GG3236@sunbeam.de.gnumonks.org> References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> <20040927092933.GG3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1767 Lines: 43 On Mon, 27 Sep 2004 11:29:33 +0200 Harald Welte wrote: > > > 4) The controversial/RFC patch, dorking with neigh_forced_gc() > > It performed perfectly, I wasn't able to reproduce those overflows > anymore (testing with two /16 networks and about 200kpps incoming > packets to unresolved and non-existant neighbours) > > > I'll do tests with and without INCOMPLETE check. No results until late > > Sunday/Monday, as indicated above. > > I didn't even bother doing the INCOMPLETE check since Yoshifuji > indicated that this caused problems with IPv6.... You might as well have. Effectively, due to a bug that Herbert Xu spotted, diff4 acts the same as if the INCOMPLETE checks were removed. The time_after() check for INCOMPLETE entries in the diff4 changes ended up being opposite of what it should be. Yoshifuji said: > So, I cannot agree simiply removing the "INCOMPLETE" test. What some standard says is meaningless in these sorts of situations. It lacks any sense. If we are reaching limits of caches and we need to create a new neighbour entry in order to communicate with another hosts we must purge anything we can. I challenge something like TAHI to even be able to check out a case like this and for the results to be meaningful in some way. They certainly won't be. So I'm going to remove the INCOMPLETE tests instead of my original diff4 since: 1) That is effectively what my buggy diff4 was doing anyways. 2) It is the simplest change and keeps us from having to scan the hash table twice under high load situations when we need the cycles very badly. Yoshifuji, if we drop neighbour entry, we will just reprobe for this neighbour if we should try to communicate with it again. It is not the end of the world. From davem@davemloft.net Mon Sep 27 12:03:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:03:33 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJ3So2031295 for ; Mon, 27 Sep 2004 12:03:28 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0jf-0006gg-00; Mon, 27 Sep 2004 12:00:31 -0700 Date: Mon, 27 Sep 2004 12:00:31 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [TCP] Fixed mss in tcp_init_cwnd Message-Id: <20040927120031.55fb4a49.davem@davemloft.net> In-Reply-To: <20040927080828.GA12056@gondor.apana.org.au> References: <20040927080828.GA12056@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 567 Lines: 16 On Mon, 27 Sep 2004 18:08:28 +1000 Herbert Xu wrote: > The MSS in tcp_init_cwnd should be the real one instead of the TSO value. This happens too early in the connections lifetime to make a difference for anything. It happens on the first move to ESTABLISHED state, and therefore by definition before we try to send any data on the connection. You're barking up the wrong tree in the search for these TSO problems. Instead, I'd recommend looking seriously at the tcp_clean_rtx_queue() partial ack'ing stuff I spoke about yesterday. From davem@davemloft.net Mon Sep 27 12:05:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:05:17 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJ5DTp031688 for ; Mon, 27 Sep 2004 12:05:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0l0-0006h5-00; Mon, 27 Sep 2004 12:01:54 -0700 Date: Mon, 27 Sep 2004 12:01:54 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927120154.09fdcadf.davem@davemloft.net> In-Reply-To: <20040927054541.GA8858@gondor.apana.org.au> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 492 Lines: 13 On Mon, 27 Sep 2004 15:45:41 +1000 Herbert Xu wrote: > On Sun, Sep 26, 2004 at 09:00:29PM -0700, David S. Miller wrote: > > > > The very next time we check to see if we can > > make forward progress on the send queue we'll call tcp_current_mss() > > which causes the right things to happen. > > tcp_current_mss() doesn't call tcp_sync_mss() unless the PMTU changes. Good catch, probably we should make it do so when sk_route_caps indicates we are doing TSO. From davem@davemloft.net Mon Sep 27 12:09:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:09:27 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJ9LBO032101 for ; Mon, 27 Sep 2004 12:09:21 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0pR-0006hT-00; Mon, 27 Sep 2004 12:06:29 -0700 Date: Mon, 27 Sep 2004 12:06:29 -0700 From: "David S. Miller" To: Herbert Xu Cc: ja@ssi.bg, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes Message-Id: <20040927120629.25646b4b.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 518 Lines: 15 On Mon, 27 Sep 2004 07:23:16 +1000 Herbert Xu wrote: > > [-- text/plain, encoding base64, charset: US-ASCII, 28 lines, name: fib_ins3.diff --] > > [-- Description: fib_alias ordered by TOS --] > > > > diff -ur v2.6.9-rc2-bk10/linux/net/ipv4/fib_hash.c linux/net/ipv4/fib_hash.c > > --- v2.6.9-rc2-bk10/linux/net/ipv4/fib_hash.c 2004-09-26 16:52:11.000000000 +0300 > > Looks good. To me too, thanks for describing all of this and for the test scripts Julian. Patch applied, thanks. From davem@davemloft.net Mon Sep 27 12:14:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:14:13 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJE7Vo032523 for ; Mon, 27 Sep 2004 12:14:07 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0u8-0006iC-00; Mon, 27 Sep 2004 12:11:20 -0700 Date: Mon, 27 Sep 2004 12:11:20 -0700 From: "David S. Miller" To: Herbert Xu Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [5/6]: Dynamic neigh hash table growth Message-Id: <20040927121120.56511b32.davem@davemloft.net> In-Reply-To: References: <20040923225127.10b0ef68.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 745 Lines: 21 On Mon, 27 Sep 2004 21:33:34 +1000 Herbert Xu wrote: > David S. Miller wrote: > > > > +static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_entries) > > +{ > > + struct neighbour **new_hash, **old_hash; > > + unsigned int i, new_hash_mask, old_entries; > > + > > + BUG_ON(new_entries & (new_entries - 1)); > > + new_hash = neigh_hash_alloc(new_entries); > > Perhaps it'd be better to bound it based on MAX_ORDER rather than waiting > for neigh_hash_alloc() to fail? After reading this email I was about to add the check, but then again, __get_free_pages() handles this case not all that suboptimally. I don't think it'll be a problem in practice. From davem@davemloft.net Mon Sep 27 12:14:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:15:03 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJEwrQ000368 for ; Mon, 27 Sep 2004 12:14:58 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0uw-0006iT-00; Mon, 27 Sep 2004 12:12:10 -0700 Date: Mon, 27 Sep 2004 12:12:09 -0700 From: "David S. Miller" To: Herbert Xu Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040927121209.4d3d7e28.davem@davemloft.net> In-Reply-To: References: <20040925005623.2faf8faf.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 365 Lines: 11 On Mon, 27 Sep 2004 21:43:58 +1000 Herbert Xu wrote: > David S. Miller wrote: > > > > 2) Tim Gardner's change to smooth out periodic neighbour GC. > > I think tbl->gc_interval can be killed altogether now. Let's keep it around so we don't break scripts people have writing sysctl/procfs values to that thing. From davem@davemloft.net Mon Sep 27 12:15:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:15:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJFPXp000535 for ; Mon, 27 Sep 2004 12:15:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0vQ-0006id-00; Mon, 27 Sep 2004 12:12:40 -0700 Date: Mon, 27 Sep 2004 12:12:40 -0700 From: "David S. Miller" To: Robert Olsson Cc: ja@ssi.bg, netdev@oss.sgi.com Subject: Re: [IPv4]: More fib_alias insertion fixes Message-Id: <20040927121240.2aea6f1d.davem@davemloft.net> In-Reply-To: <16727.65341.747293.986870@robur.slu.se> References: <20040925201425.16fbcb6c.davem@davemloft.net> <16727.65341.747293.986870@robur.slu.se> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 286 Lines: 8 On Mon, 27 Sep 2004 13:53:33 +0200 Robert Olsson wrote: > I'll guess struct fib_alias should not be defined in fib_hash.c to > support pluggable lookup algorithms. Yes, all the fib_alias handling can move into fib_semantics() in fact. I'll work on that. From davem@davemloft.net Mon Sep 27 12:16:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:16:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJGprF001093 for ; Mon, 27 Sep 2004 12:16:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC0wl-0006j3-00; Mon, 27 Sep 2004 12:14:03 -0700 Date: Mon, 27 Sep 2004 12:14:03 -0700 From: "David S. Miller" To: Herbert Xu Cc: laforge@gnumonks.org, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh Message-Id: <20040927121403.767e2308.davem@davemloft.net> In-Reply-To: References: <20040925005623.2faf8faf.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2078 Lines: 61 On Mon, 27 Sep 2004 21:56:10 +1000 Herbert Xu wrote: > David S. Miller wrote: > > > > 4) The controversial/RFC patch, dorking with neigh_forced_gc() > > > > + if (n->nud_state -= NUD_INCOMPLETE && > > + reap_incomplete == 0 && > > + time_after(jiffies, > > + n->used + n->parms->retrans_time)) { > > + num_incomplete++; > > + goto next_ent; > > That should either be time_before, or you need to swap the arguments. Good catch, and it means that the code basically behaved as if the NUD_INCOMPLETE tests weren't even there. So, as mentioned in another email, this is what I'm using in the end: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/27 11:46:12-07:00 davem@nuts.davemloft.net # [NET]: Remove INCOMPLETE checks from neigh_forced_gc(). # # Signed-off-by: David S. Miller # # net/core/neighbour.c # 2004/09/27 11:45:40-07:00 davem@nuts.davemloft.net +3 -11 # [NET]: Remove INCOMPLETE checks from neigh_forced_gc(). # diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-27 11:55:57 -07:00 +++ b/net/core/neighbour.c 2004-09-27 11:55:57 -07:00 @@ -123,20 +123,12 @@ np = &tbl->hash_buckets[i]; while ((n = *np) != NULL) { /* Neighbour record may be discarded if: - - nobody refers to it. - - it is not permanent - - (NEW and probably wrong) - INCOMPLETE entries are kept at least for - n->parms->retrans_time, otherwise we could - flood network with resolution requests. - It is not clear, what is better table overflow - or flooding. + * - nobody refers to it. + * - it is not permanent */ write_lock(&n->lock); if (atomic_read(&n->refcnt) == 1 && - !(n->nud_state & NUD_PERMANENT) && - (n->nud_state != NUD_INCOMPLETE || - time_after(jiffies, n->used + n->parms->retrans_time))) { + !(n->nud_state & NUD_PERMANENT)) { *np = n->next; n->dead = 1; shrunk = 1; From davem@redhat.com Mon Sep 27 12:18:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:19:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJIwqG001466 for ; Mon, 27 Sep 2004 12:18:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8RJIfQZ027187; Mon, 27 Sep 2004 15:18:41 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8RJIar02977; Mon, 27 Sep 2004 15:18:36 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8RJIM9A016305; Mon, 27 Sep 2004 15:18:22 -0400 Date: Mon, 27 Sep 2004 12:16:10 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/3) tcp - choose congestion algorithm at initialization Message-Id: <20040927121610.68f942a4.davem@redhat.com> In-Reply-To: <20040927111834.48c7baab@zqx3.pdx.osdl.net> References: <20040927111834.48c7baab@zqx3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 432 Lines: 15 On Mon, 27 Sep 2004 11:18:34 -0700 Stephen Hemminger wrote: > The choice of congestion algorithm needs to be made when connection > is setup to avoid problems when the sysctl values change later and the > necessary data hasn't been collected. > > Signed-off-by: Stephen Hemminger Looks great, applied. We'll need 2.4.x versions of this stuff, could you cook those up for me? Thanks. From davem@redhat.com Mon Sep 27 12:20:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:20:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJKPqZ005033 for ; Mon, 27 Sep 2004 12:20:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8RJKCpP027713; Mon, 27 Sep 2004 15:20:12 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8RJKCr03537; Mon, 27 Sep 2004 15:20:12 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8RJJwEe017524; Mon, 27 Sep 2004 15:19:59 -0400 Date: Mon, 27 Sep 2004 12:17:46 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (2/3) tcp - diagnostics enhancement for westwood Message-Id: <20040927121746.7ab592d5.davem@redhat.com> In-Reply-To: <20040927112118.4c376303@zqx3.pdx.osdl.net> References: <20040927112118.4c376303@zqx3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 361 Lines: 14 On Mon, 27 Sep 2004 11:21:18 -0700 Stephen Hemminger wrote: > Enhancement to tcp diagnostics used by ss command. > * use jiffies_to_usecs/msec instead of hardcode math > * report bandwidth for Westwood > > Signed-off-by: Stephen Hemminger Looks great, applied. Again, 2.4.x variant would be appreciated. Thanks. From davem@redhat.com Mon Sep 27 12:21:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:21:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJLN7V005363 for ; Mon, 27 Sep 2004 12:21:23 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8RJLAaT027944; Mon, 27 Sep 2004 15:21:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8RJL4r03737; Mon, 27 Sep 2004 15:21:04 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8RJKo0r017936; Mon, 27 Sep 2004 15:20:51 -0400 Date: Mon, 27 Sep 2004 12:18:38 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (3/3) tcp westwood cleanup Message-Id: <20040927121838.21f260ef.davem@redhat.com> In-Reply-To: <20040927112249.38bea6ff@zqx3.pdx.osdl.net> References: <20040927112249.38bea6ff@zqx3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 224 Lines: 9 On Mon, 27 Sep 2004 11:22:49 -0700 Stephen Hemminger wrote: > Westwood code cleanup; > * use const. > * avoid needless paren's and returns > * inline acked_count (called once) Looks good, applied. From davem@davemloft.net Mon Sep 27 12:24:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:24:24 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJOIMf005743 for ; Mon, 27 Sep 2004 12:24:18 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC144-0006kL-00; Mon, 27 Sep 2004 12:21:36 -0700 Date: Mon, 27 Sep 2004 12:21:36 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] neighbour cache statistics like rt_stat Message-Id: <20040927122136.7016b2c1.davem@davemloft.net> In-Reply-To: <20040927162334.GV3236@sunbeam.de.gnumonks.org> References: <20040927093613.GH3236@sunbeam.de.gnumonks.org> <20040927162334.GV3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 698 Lines: 21 On Mon, 27 Sep 2004 18:23:34 +0200 Harald Welte wrote: > On Mon, Sep 27, 2004 at 11:36:13AM +0200, Harald Welte wrote: > > The patch below (on top of davem's recent 6-patch set and 4-patch-set up > > to diff4) adds rt_stat like statistics to the neighbour cache core. > > I've now updated the patch. > > Changes: > - more statistics (lookups, destroy, periodic_gc_runs) > - add template line to top of file I'm generally very happy with these changes, but two things: 1) Please update the patch since I replaced "diff4" with a patch simply removing the INCOMPLETE checks from neigh_forced_gc() 2) I'd recommend using unsigned long for all the statistics. Thanks. From davem@davemloft.net Mon Sep 27 12:26:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:26:47 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJQfi7006116 for ; Mon, 27 Sep 2004 12:26:41 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC16B-0006l8-00; Mon, 27 Sep 2004 12:23:47 -0700 Date: Mon, 27 Sep 2004 12:23:47 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: andre@tomt.net, tgraf@suug.ch, pp@ee.oulu.fi, jgarzik@pobox.com, dwmw2@infradead.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH/RFC] PATCH: IPV6: Fix multiple leakages (is Re: unregister_netdevice: waiting for tun6to4 to become free.) Message-Id: <20040927122347.045d04db.davem@davemloft.net> In-Reply-To: <20040925.040506.106641510.yoshfuji@linux-ipv6.org> References: <41527796.4010204@tomt.net> <4152843D.6010204@tomt.net> <20040923.172253.125681726.yoshfuji@linux-ipv6.org> <20040925.040506.106641510.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8RJQfi7006116 X-archive-position: 9528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 212 Lines: 7 On Sat, 25 Sep 2004 04:05:06 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > bk://bk.skbuff.net:20609/linux-2.6-refcnt/ These changes look fine. Pulled, thank you Yoshifuji. From davem@davemloft.net Mon Sep 27 12:30:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 12:30:49 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RJUiSS006497 for ; Mon, 27 Sep 2004 12:30:44 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC19I-0006m1-00; Mon, 27 Sep 2004 12:27:01 -0700 Date: Mon, 27 Sep 2004 12:27:00 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-Id: <20040927122700.4696e416.davem@davemloft.net> In-Reply-To: <20040925000503.GA10873@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> <20040924233555.GA7962@gondor.apana.org.au> <20040924233713.GA8001@gondor.apana.org.au> <20040924164540.2d750572.davem@davemloft.net> <20040925000503.GA10873@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 264 Lines: 8 On Sat, 25 Sep 2004 10:05:03 +1000 Herbert Xu wrote: > Here is the real patch. Ok.. idea wise. But, why are you subtracting 'delta' from skb->truesize? That's the amount actually used not the amount trimmed by pskb_expand_head(). From shemminger@osdl.org Mon Sep 27 13:20:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 13:20:27 -0700 (PDT) Received: from fire-1.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RKKLW1008036 for ; Mon, 27 Sep 2004 13:20:21 -0700 Received: from zqx3.pdx.osdl.net (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by fire-1.osdl.org (8.12.8/8.12.8) with ESMTP id i8RKK3WL031765 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 27 Sep 2004 13:20:04 -0700 Date: Mon, 27 Sep 2004 13:24:18 -0700 From: Stephen Hemminger To: "David S. Miller" , Joe Perches Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (2/3) tcp - diagnostics enhancement for westwood Message-Id: <20040927132418.509c689b@zqx3.pdx.osdl.net> In-Reply-To: <20040927121746.7ab592d5.davem@redhat.com> References: <20040927112118.4c376303@zqx3.pdx.osdl.net> <20040927121746.7ab592d5.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-suse-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.85 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1228 Lines: 43 Joe's suggestion, put jiffies_to_usecs in time.h and make it smarter about HZ values math. Signed-off-by: Stephen Hemminger diff -Nru a/include/linux/time.h b/include/linux/time.h --- a/include/linux/time.h 2004-09-27 13:22:41 -07:00 +++ b/include/linux/time.h 2004-09-27 13:22:41 -07:00 @@ -194,6 +194,18 @@ return (j * 1000) / HZ; #endif } + +static inline unsigned int jiffies_to_usecs(const unsigned long j) +{ +#if HZ <= 1000 && !(1000 % HZ) + return (1000000 / HZ) * j; +#elif HZ > 1000 && !(HZ % 1000) + return (j*1000 + (HZ - 1000))/(HZ / 1000); +#else + return (j * 1000000) / HZ; +#endif +} + static inline unsigned long msecs_to_jiffies(const unsigned int m) { #if HZ <= 1000 && !(1000 % HZ) diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c 2004-09-27 13:22:41 -07:00 +++ b/net/ipv4/tcp_diag.c 2004-09-27 13:22:41 -07:00 @@ -41,12 +41,6 @@ rta->rta_len = rtalen; \ RTA_DATA(rta); }) -static inline unsigned int jiffies_to_usecs(const unsigned long j) -{ - return 1000*jiffies_to_msecs(j); -} - - /* Return information about state of tcp endpoint in API format. */ void tcp_get_info(struct sock *sk, struct tcp_info *info) { From acme@conectiva.com.br Mon Sep 27 13:37:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 13:37:52 -0700 (PDT) Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RKbhGJ008675 for ; Mon, 27 Sep 2004 13:37:45 -0700 Received: by perninha.conectiva.com.br (Postfix, from userid 568) id 1220C473DC; Mon, 27 Sep 2004 17:37:15 -0300 (BRT) Received: from burns.conectiva (burns.conectiva [10.0.0.4]) by perninha.conectiva.com.br (Postfix) with SMTP id 9F63D473DC for ; Mon, 27 Sep 2004 17:37:14 -0300 (BRT) Received: (qmail 4485 invoked by uid 0); 27 Sep 2004 21:34:06 -0000 Received: from mapi8.distro.conectiva (HELO oops.ghostprotocols.net) (10.0.16.10) by burns.conectiva with SMTP; 27 Sep 2004 21:34:06 -0000 Received: from [192.168.1.6] (amd64.kerneljanitors.org [192.168.1.6]) by oops.ghostprotocols.net (Postfix) with ESMTP id 1AA5914639; Mon, 27 Sep 2004 17:40:05 -0300 (BRT) Message-ID: <41587A26.6020606@conectiva.com.br> Date: Mon, 27 Sep 2004 17:37:58 -0300 From: Arnaldo Carvalho de Melo Organization: Conectiva S.A. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CaT Cc: linux-kernel@vger.kernel.org, davem@davemloft.net, jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: strange network slowness in 2.6 unless pingflooding References: <20040927090342.GA1794@zip.com.au> In-Reply-To: <20040927090342.GA1794@zip.com.au> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bogosity: No, tests=bogofilter, spamicity=0.005206, version=0.16.3 X-archive-position: 9531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 597 Lines: 21 CaT wrote: > Hi, > > This is still happening. I ran the same set of tests on a totally > different network, with my xircom realport ethernet card (tulip > driver - 16bit) and from linux to linux and windows to linux. Scrolling > through a message in mutt eventually slows down and if I lift my finger > off the enter key whilst it's slow the scrolling keeps going, as if it > was all bufferd. If I do a pingflood (ping -f) from a machine to my > laptop it's all fine. > > I am also now running 2.6.9-rc1-mm4. > Have you tried FAQ: echo 0 > /proc/sys/net/ipv4/tcp_window_scaling - Arnaldo From dax@gurulabs.com Mon Sep 27 13:40:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 13:40:42 -0700 (PDT) Received: from mail.gurulabs.com (mail.gurulabs.com [67.137.148.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RKeaP6009051 for ; Mon, 27 Sep 2004 13:40:36 -0700 Received: from [10.2.3.10] (dhcp10.glwlan.gurulabs.com [10.2.3.10]) by mail.gurulabs.com (Postfix) with ESMTP id E6F3118D3E; Mon, 27 Sep 2004 14:40:21 -0600 (MDT) Subject: thinkpad issue --No PCMCIA hotplug activity when onboard nic (e1000) down From: Dax Kelson To: Linux Kernel Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, dahinds@users.sourceforge.net Content-Type: text/plain Message-Id: <1096317629.4075.65.camel@mentorng.gurulabs.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 27 Sep 2004 14:40:29 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 9532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dax@gurulabs.com Precedence: bulk X-list: netdev Content-Length: 2097 Lines: 63 Myself and a co-worker have two ThinkPads bought a few months apart. The two model numbers are: 2373-KUU -- T42p 14" LCD 2373-CXU -- T42 15" LCD Both have the following onboard NIC and cardbus controller 02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) 02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) The issue: Observed on both Laptops, under multiple distributions (Fedora 1/2/rawhide, SUSE 9.1, Debian Sarge) including 2.6.9-rc2. Inserting a PCMCIA/Cardbus device (tried a few different cards) results in no activity, dmesg output, or hotplug event. In order to recognize the card, a manual invocation of "cardctl insert" must occur. First (really strange) datapoint: If the onboard nic has an IP address and is UP, then PCMCIA hotplug works great! I can unplug and plug cards in, the drivers load, hotplug runs and everything works as expected. If I turn down the onboard NIC, "ifconfig eth0 down", then PCMCIA hotplug stops working, bring the onboard NIC back up "ifconfig eth0 up", then PCMCIA hotplug starts working again. The IP address may be irrelevant, it may just need to be "up", but I haven't tested that. It took a long time to stumble on to this correlation. Second datapoint: If the card is inserted before powering on the laptop, the card will be detected and drivers loaded during boot as expected independent of the status of the onboard NIC. Third datapoint: Out of the box, nearly everything is using IRQ 11. I've spread things around, but no change in behavior. Fourth datapoint: Running "cardctl insert" doesn't always work. The driver for the PCMCIA/Cardbus devices seems to load partway (not all of the normal printk's are seen), and any attempt to access the device (with ifconfig, iwconfig, etc) results in a hang of that command. A reboot is required to clear things up. Fifth datpoint: Windows XP has no troubles with PCMCIA. Any and all help greatly appreciated, Dax Kelson From rmk+netdev=oss.sgi.com@arm.linux.org.uk Mon Sep 27 13:53:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 13:53:33 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RKrPhN009679 for ; Mon, 27 Sep 2004 13:53:27 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41) id 1CC2Uc-0007Br-7h; Mon, 27 Sep 2004 21:53:06 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.41) id 1CC2Ua-0007qT-Tm; Mon, 27 Sep 2004 21:53:04 +0100 Date: Mon, 27 Sep 2004 21:53:04 +0100 From: Russell King To: Dax Kelson Cc: Linux Kernel , linux-net@vger.kernel.org, netdev@oss.sgi.com, dahinds@users.sourceforge.net Subject: Re: thinkpad issue --No PCMCIA hotplug activity when onboard nic (e1000) down Message-ID: <20040927215304.E26680@flint.arm.linux.org.uk> Mail-Followup-To: Dax Kelson , Linux Kernel , linux-net@vger.kernel.org, netdev@oss.sgi.com, dahinds@users.sourceforge.net References: <1096317629.4075.65.camel@mentorng.gurulabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1096317629.4075.65.camel@mentorng.gurulabs.com>; from dax@gurulabs.com on Mon, Sep 27, 2004 at 02:40:29PM -0600 X-archive-position: 9533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk+lkml@arm.linux.org.uk Precedence: bulk X-list: netdev Content-Length: 822 Lines: 20 On Mon, Sep 27, 2004 at 02:40:29PM -0600, Dax Kelson wrote: > Myself and a co-worker have two ThinkPads bought a few months apart. The > two model numbers are: > > 2373-KUU -- T42p 14" LCD > 2373-CXU -- T42 15" LCD > > Both have the following onboard NIC and cardbus controller > 02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) > 02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) > 02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) Can you also provide the output of lspci -n for the above two cardbus bridges please? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From dax@gurulabs.com Mon Sep 27 14:06:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 14:06:15 -0700 (PDT) Received: from mail.gurulabs.com (mail.gurulabs.com [67.137.148.7]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RL69CK010288 for ; Mon, 27 Sep 2004 14:06:10 -0700 Received: from [10.2.3.10] (dhcp10.glwlan.gurulabs.com [10.2.3.10]) by mail.gurulabs.com (Postfix) with ESMTP id 60EF84253B; Mon, 27 Sep 2004 15:05:58 -0600 (MDT) Subject: Re: thinkpad issue --No PCMCIA hotplug activity when onboard nic (e1000) down From: Dax Kelson To: Russell King Cc: Linux Kernel , linux-net@vger.kernel.org, netdev@oss.sgi.com, dahinds@users.sourceforge.net In-Reply-To: <20040927215304.E26680@flint.arm.linux.org.uk> References: <1096317629.4075.65.camel@mentorng.gurulabs.com> <20040927215304.E26680@flint.arm.linux.org.uk> Content-Type: text/plain Message-Id: <1096319165.4075.78.camel@mentorng.gurulabs.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 27 Sep 2004 15:06:05 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 9534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dax@gurulabs.com Precedence: bulk X-list: netdev Content-Length: 830 Lines: 23 On Mon, 2004-09-27 at 14:53, Russell King wrote: > On Mon, Sep 27, 2004 at 02:40:29PM -0600, Dax Kelson wrote: > > Myself and a co-worker have two ThinkPads bought a few months apart. The > > two model numbers are: > > > > 2373-KUU -- T42p 14" LCD > > 2373-CXU -- T42 15" LCD > > > > Both have the following onboard NIC and cardbus controller > > 02:01.0 Ethernet controller: Intel Corp. 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) > > 02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) > > 02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01) > > Can you also provide the output of lspci -n for the above two > cardbus bridges please? Sure.. # lspci -n | grep 02:00 02:00.0 Class 0607: 104c:ac46 (rev 01) 02:00.1 Class 0607: 104c:ac46 (rev 01) From davem@redhat.com Mon Sep 27 14:19:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 14:19:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RLJglx010956 for ; Mon, 27 Sep 2004 14:19:42 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8RLJMXa028404; Mon, 27 Sep 2004 17:19:23 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8RLJMr12232; Mon, 27 Sep 2004 17:19:22 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8RLJ9VO021310; Mon, 27 Sep 2004 17:19:09 -0400 Date: Mon, 27 Sep 2004 14:16:55 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: joe@Perches.com, netdev@oss.sgi.com Subject: Re: [PATCH] (2/3) tcp - diagnostics enhancement for westwood Message-Id: <20040927141655.5e53ca7a.davem@redhat.com> In-Reply-To: <20040927132418.509c689b@zqx3.pdx.osdl.net> References: <20040927112118.4c376303@zqx3.pdx.osdl.net> <20040927121746.7ab592d5.davem@redhat.com> <20040927132418.509c689b@zqx3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 223 Lines: 9 On Mon, 27 Sep 2004 13:24:18 -0700 Stephen Hemminger wrote: > Joe's suggestion, put jiffies_to_usecs in time.h and make it smarter > about HZ values math. Works for me. Applied, thanks Stephen/Joe. From herbert@gondor.apana.org.au Mon Sep 27 14:30:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 14:30:22 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RLUCia011517 for ; Mon, 27 Sep 2004 14:30:13 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC34F-0000J8-00; Tue, 28 Sep 2004 07:29:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC34D-0001uN-00; Tue, 28 Sep 2004 07:29:53 +1000 Date: Tue, 28 Sep 2004 07:29:53 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: Set truesize in pskb_expand_head Message-ID: <20040927212953.GB7243@gondor.apana.org.au> References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> <20040924233555.GA7962@gondor.apana.org.au> <20040924233713.GA8001@gondor.apana.org.au> <20040924164540.2d750572.davem@davemloft.net> <20040925000503.GA10873@gondor.apana.org.au> <20040927122700.4696e416.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927122700.4696e416.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 504 Lines: 12 On Mon, Sep 27, 2004 at 12:27:00PM -0700, David S. Miller wrote: > > Ok.. idea wise. But, why are you subtracting 'delta' from > skb->truesize? That's the amount actually used not the > amount trimmed by pskb_expand_head(). delta = skb->end - skb->tail which is the amount we want to trim. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 14:34:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 14:34:13 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RLY6Gq011932 for ; Mon, 27 Sep 2004 14:34:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC36u-0000Ms-00; Tue, 28 Sep 2004 07:32:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC36n-0001v4-00; Tue, 28 Sep 2004 07:32:33 +1000 Date: Tue, 28 Sep 2004 07:32:33 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040927213233.GC7243@gondor.apana.org.au> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927120154.09fdcadf.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 610 Lines: 15 On Mon, Sep 27, 2004 at 12:01:54PM -0700, David S. Miller wrote: > > > tcp_current_mss() doesn't call tcp_sync_mss() unless the PMTU changes. > > Good catch, probably we should make it do so when sk_route_caps > indicates we are doing TSO. Alternatively we could move the TSO code out of tcp_sync_mss() and put it in tcp_current_mss() instead. It seems to be the only one using the factor anyway. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 14:37:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 14:37:25 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RLbGJT012330 for ; Mon, 27 Sep 2004 14:37:17 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC3AR-0000P3-00; Tue, 28 Sep 2004 07:36:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC3AF-0001vq-00; Tue, 28 Sep 2004 07:36:07 +1000 Date: Tue, 28 Sep 2004 07:36:07 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040927213607.GD7243@gondor.apana.org.au> References: <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096289189.1075.37.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1128 Lines: 31 On Mon, Sep 27, 2004 at 08:46:30AM -0400, jamal wrote: > > > > 1) Request/response: > > > > No overruns should occur. > > Cant assume this. A request for an ACK is fine. A get is a different > ball game. What I meant is that this is a case where the maximum size of the reply can be known at compile time. So assuming that your socket receive size is set correctly, it should never overflow. > > 3) Async messages: > > > > Overruns may occur if the arrival rate exceeds the application's > > processing capacity or if the queue is too small for a burst. > > > > Now we were discussing about how we can do congestion control for 3). > > But to do that we need to know exactly what these messages are. For > > example if they're coming from an external source as is the case in > > ip_queue then you can't congestion control it at all. You still haven't told me what you're going to use 3) for yet... Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 14:42:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 14:42:09 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RLg0sq012771 for ; Mon, 27 Sep 2004 14:42:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC3Fb-0000UZ-00; Tue, 28 Sep 2004 07:41:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC3FW-0001wo-00; Tue, 28 Sep 2004 07:41:34 +1000 From: Herbert Xu To: davem@davemloft.net (David S. Miller) Subject: Re: [6/6]: jenkins hash for neigh Cc: herbert@gondor.apana.org.au, laforge@gnumonks.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040927111520.4f495b17.davem@davemloft.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 28 Sep 2004 07:41:34 +1000 X-archive-position: 9539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1231 Lines: 37 David S. Miller wrote: > On Mon, 27 Sep 2004 21:48:33 +1000 > Herbert Xu wrote: > >> > - if (tbl->entries > (tbl->hash_mask + 1)) >> > + if (tbl->entries > (tbl->hash_mask + 1)) { >> > + write_lock_bh(&tbl->lock); >> > neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); >> > + write_unlock_bh(&tbl->lock); >> > + } >> >> The locking should be outside the if block as otherwise you may grow >> unnecessarily or grow into the same size :) > > I'm not going to do that, because then we're grabbing that lock > twice on every neigh create operation and I was trying hard > to avoid that overhead. Please at least do something like this: size = tbl->hash_mask + 1; if (tbl->entries > size) { write_lock_bh(&tbl->lock); neigh_hash_grow(tbl, size << 1); write_unlock_bh(&tbl->lock); } That'll at least kill the first race. You can kill the race of growing into the same size by doing the if check again inside the locks. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 15:00:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:00:51 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RM0fU1013460 for ; Mon, 27 Sep 2004 15:00:42 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC3Xh-0000dx-00; Tue, 28 Sep 2004 08:00:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC3Xb-0001yY-00; Tue, 28 Sep 2004 08:00:15 +1000 From: Herbert Xu To: herbert@gondor.apana.org.au (Herbert Xu) Subject: Re: [6/6]: jenkins hash for neigh Cc: davem@davemloft.net, herbert@gondor.apana.org.au, laforge@gnumonks.org, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 28 Sep 2004 08:00:15 +1000 X-archive-position: 9540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 718 Lines: 22 Herbert Xu wrote: > > Please at least do something like this: > > size = tbl->hash_mask + 1; > if (tbl->entries > size) { > write_lock_bh(&tbl->lock); > neigh_hash_grow(tbl, size << 1); > write_unlock_bh(&tbl->lock); > } > > That'll at least kill the first race. You can kill the race of > growing into the same size by doing the if check again inside the > locks. Never mind. Unless you do the check again inside the lock this may actually shrink :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 15:02:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:03:05 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RM2wwq013818 for ; Mon, 27 Sep 2004 15:02:59 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC3Zx-0000gC-00; Tue, 28 Sep 2004 08:02:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC3Zx-0001zQ-00; Tue, 28 Sep 2004 08:02:41 +1000 Date: Tue, 28 Sep 2004 08:02:40 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [TCP] Fixed mss in tcp_init_cwnd Message-ID: <20040927220240.GA7633@gondor.apana.org.au> References: <20040927080828.GA12056@gondor.apana.org.au> <20040927120031.55fb4a49.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927120031.55fb4a49.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 651 Lines: 17 On Mon, Sep 27, 2004 at 12:00:31PM -0700, David S. Miller wrote: > On Mon, 27 Sep 2004 18:08:28 +1000 > Herbert Xu wrote: > > > The MSS in tcp_init_cwnd should be the real one instead of the TSO value. > > This happens too early in the connections lifetime > to make a difference for anything. I know. That's why I put it in a different thread. IMHO we should still fix it though at least for consistency. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Sep 27 15:08:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:08:10 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RM80hA014278 for ; Mon, 27 Sep 2004 15:08:01 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC3ek-0000ia-00; Tue, 28 Sep 2004 08:07:38 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC3ei-00020G-00; Tue, 28 Sep 2004 08:07:36 +1000 From: Herbert Xu To: shemminger@osdl.org (Stephen Hemminger) Subject: Re: [PATCH] (1/3) tcp - choose congestion algorithm at initialization Cc: davem@redhat.com, netdev@oss.sgi.com Organization: Core In-Reply-To: <20040927111834.48c7baab@zqx3.pdx.osdl.net> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 28 Sep 2004 08:07:36 +1000 X-archive-position: 9542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 487 Lines: 11 Stephen Hemminger wrote: > The choice of congestion algorithm needs to be made when connection > is setup to avoid problems when the sysctl values change later and the > necessary data hasn't been collected. Could this be chosen by a setsockopt as well? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From laforge@gnumonks.org Mon Sep 27 15:21:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:21:20 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RMLAbS014879 for ; Mon, 27 Sep 2004 15:21:11 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CC3rc-0001pZ-UI; Tue, 28 Sep 2004 00:20:57 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CC3rb-0007HN-WB; Tue, 28 Sep 2004 00:20:56 +0200 Date: Tue, 28 Sep 2004 00:20:55 +0200 From: Harald Welte To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] neighbour cache statistics like rt_stat Message-ID: <20040927222055.GD3236@sunbeam.de.gnumonks.org> References: <20040927093613.GH3236@sunbeam.de.gnumonks.org> <20040927162334.GV3236@sunbeam.de.gnumonks.org> <20040927122136.7016b2c1.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f+d0/Pr67PH7qeXv" Content-Disposition: inline In-Reply-To: <20040927122136.7016b2c1.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 11827 Lines: 421 --f+d0/Pr67PH7qeXv Content-Type: multipart/mixed; boundary="bXLrh1gl3UpYNtAG" Content-Disposition: inline --bXLrh1gl3UpYNtAG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! On Mon, Sep 27, 2004 at 12:21:36PM -0700, David S. Miller wrote: > 1) Please update the patch since I replaced "diff4" with > a patch simply removing the INCOMPLETE checks from neigh_forced_gc() >=20 > 2) I'd recommend using unsigned long for all the statistics. both updated in attached version. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --bXLrh1gl3UpYNtAG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="laforge-neigh_statistics.patch" Content-Transfer-Encoding: quoted-printable Add rtstat-like per-cpu statistics to the neighbour cache core. This will add=20 /proc/net/arp_cache_stat for ipv4 /proc/net/ndisc_cache_stat for ipv6 /proc/net/clip_arp_cache_stat for atm/clip=20 /proc/net/decnet_neigh_stat for decnet The format is similar to rt_stat, one line per cpu where each line is: Field 0: Total number of entries in table Field 1: Total number of neighbour allocations in this tbl Field 2: Total number of neighbour destroys in this tbl Field 3: Total number of hash bucket grows Field 4: Total number of failed neighbour resolves Field 5: Total number of cache lookups Field 6: Total number of cache hits Field 7: Total number of received multicast solicitations Field 8: Total number of received unicast solicitations Field 9: Total number of periodic garbage collector runs Field 10: Total number of forced garbage collector runs Signed-off-by: Harald Welte Index: linux-2.6.9-rc2-bk9-neigh1/include/net/neighbour.h =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/include/net/neighbour.h 2004-09-26 12:4= 5:38.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/include/net/neighbour.h 2004-09-28 00:07:55.= 544774240 +0200 @@ -7,6 +7,11 @@ * Authors: * Pedro Roque * Alexey Kuznetsov + * + * Changes: + * + * Harald Welte: + * - Add neighbour cache statistics like rtstat */ =20 /* The following flags & states are exported to user space, @@ -90,12 +95,25 @@ =20 struct neigh_statistics { - unsigned long allocs; - unsigned long res_failed; - unsigned long rcv_probes_mcast; - unsigned long rcv_probes_ucast; + unsigned long allocs; /* number of allocated neighs */ + unsigned long destroys; /* number of destroyed neighs */ + unsigned long hash_grows; /* number of hash resizes */ + + unsigned long res_failed; /* nomber of failed resolutions */ + + unsigned long lookups; /* number of lookups */ + unsigned long hits; /* number of hits (among lookups) */ + + unsigned long rcv_probes_mcast; /* number of received mcast ipv6 */ + unsigned long rcv_probes_ucast; /* number of received ucast ipv6 */ + + unsigned long periodic_gc_runs; /* number of periodic GC runs */ + unsigned long forced_gc_runs; /* number of forced GC runs */ }; =20 +#define NEIGH_CACHE_STAT_INC(tbl, field) \ + (per_cpu_ptr((tbl)->stats, smp_processor_id())->field++) + struct neighbour { struct neighbour *next; @@ -172,12 +190,15 @@ unsigned long last_rand; struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; - struct neigh_statistics stats; + struct neigh_statistics *stats; struct neighbour **hash_buckets; unsigned int hash_mask; __u32 hash_rnd; unsigned int hash_chain_gc; struct pneigh_entry **phash_buckets; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *pde; +#endif }; =20 /* flags for neigh_update() */ Index: linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/core/neighbour.c 2004-09-28 00:05:1= 9.555488216 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c 2004-09-28 00:15:51.372= 437440 +0200 @@ -12,6 +12,7 @@ * * Fixes: * Vitaly E. Lavrov releasing NULL neighbor in neigh_add. + * Harald Welte Add neighbour cache statistics like rtstat */ =20 #include @@ -21,6 +22,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -59,6 +61,7 @@ =20 static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; +static struct file_operations neigh_stat_seq_fops; =20 /* Neighbour hash table buckets are protected with rwlock tbl->lock. @@ -116,6 +119,8 @@ int shrunk =3D 0; int i; =20 + NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs); + write_lock_bh(&tbl->lock); for (i =3D 0; i <=3D tbl->hash_mask; i++) { struct neighbour *n, **np; @@ -273,7 +278,8 @@ init_timer(&n->timer); n->timer.function =3D neigh_timer_handler; n->timer.data =3D (unsigned long)n; - tbl->stats.allocs++; + + NEIGH_CACHE_STAT_INC(tbl, allocs); neigh_glbl_allocs++; tbl->entries++; n->tbl =3D tbl; @@ -315,6 +321,8 @@ struct neighbour **new_hash, **old_hash; unsigned int i, new_hash_mask, old_entries; =20 + NEIGH_CACHE_STAT_INC(tbl, hash_grows); + BUG_ON(new_entries & (new_entries - 1)); new_hash =3D neigh_hash_alloc(new_entries); if (!new_hash) @@ -349,11 +357,14 @@ struct neighbour *n; int key_len =3D tbl->key_len; u32 hash_val =3D tbl->hash(pkey, dev) & tbl->hash_mask; +=09 + NEIGH_CACHE_STAT_INC(tbl, lookups); =20 read_lock_bh(&tbl->lock); for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (dev =3D=3D n->dev && !memcmp(n->primary_key, pkey, key_len)) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -367,10 +378,13 @@ int key_len =3D tbl->key_len; u32 hash_val =3D tbl->hash(pkey, NULL) & tbl->hash_mask; =20 + NEIGH_CACHE_STAT_INC(tbl, lookups); + read_lock_bh(&tbl->lock); for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (!memcmp(n->primary_key, pkey, key_len)) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -555,6 +569,8 @@ { struct hh_cache *hh; =20 + NEIGH_CACHE_STAT_INC(neigh->tbl, destroys); + if (!neigh->dead) { printk(KERN_WARNING "Destroying alive neighbour %p\n", neigh); @@ -630,6 +646,8 @@ struct neighbour *n, **np; unsigned long expire, now =3D jiffies; =20 + NEIGH_CACHE_STAT_INC(tbl, periodic_gc_runs); + write_lock(&tbl->lock); =20 /* @@ -761,7 +779,7 @@ =20 neigh->nud_state =3D NUD_FAILED; notify =3D 1; - neigh->tbl->stats.res_failed++; + NEIGH_CACHE_STAT_INC(neigh->tbl, res_failed); NEIGH_PRINTK2("neigh %p is failed.\n", neigh); =20 /* It is very thin place. report_unreachable is very complicated @@ -1310,6 +1328,29 @@ if (!tbl->kmem_cachep) panic("cannot create neighbour cache"); =20 + tbl->stats =3D alloc_percpu(struct neigh_statistics); + if (!tbl->stats) + panic("cannot create neighbour cache statistics"); +=09 +#ifdef CONFIG_PROC_FS +#define NC_STAT_SUFFIX "_stat" + { + char *proc_stat_name; + proc_stat_name =3D kmalloc(strlen(tbl->id) +=20 + strlen(NC_STAT_SUFFIX) + 1, GFP_KERNEL); + if (!proc_stat_name) + panic("cannot allocate neighbour cache proc name buffer"); + strcpy(proc_stat_name, tbl->id); + strcat(proc_stat_name, NC_STAT_SUFFIX); + + tbl->pde =3D create_proc_entry(proc_stat_name, 0, proc_net); + if (!tbl->pde)=20 + panic("cannot create neighbour proc dir entry"); + tbl->pde->proc_fops =3D &neigh_stat_seq_fops; + tbl->pde->data =3D tbl; + } +#endif + tbl->hash_mask =3D 0x1f; tbl->hash_buckets =3D neigh_hash_alloc(tbl->hash_mask + 1); =20 @@ -1856,6 +1897,106 @@ } EXPORT_SYMBOL(neigh_seq_stop); =20 +/* statistics via seq_file */ + +static void *neigh_stat_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int cpu; + + if (*pos =3D=3D 0) + return SEQ_START_TOKEN; +=09 + for (cpu =3D *pos-1; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos =3D cpu+1; + return per_cpu_ptr(tbl->stats, cpu); + } + return NULL; +} + +static void *neigh_stat_seq_next(struct seq_file *seq, void *v, loff_t *po= s) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int cpu; + + for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { + if (!cpu_possible(cpu)) + continue; + *pos =3D cpu+1; + return per_cpu_ptr(tbl->stats, cpu); + } + return NULL; +} + +static void neigh_stat_seq_stop(struct seq_file *seq, void *v) +{ + +} + +static int neigh_stat_seq_show(struct seq_file *seq, void *v) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + struct neigh_statistics *st =3D v; + + if (v =3D=3D SEQ_START_TOKEN) { + seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_= failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs = forced_gc_goal_miss\n"); + return 0; + } + + seq_printf(seq, "%08x %08lx %08lx %08lx %08lx %08lx %08lx " + "%08lx %08lx %08lx %08lx\n", + tbl->entries, + + st->allocs, + st->destroys, + st->hash_grows, + + st->lookups, + st->hits, + + st->res_failed, + + st->rcv_probes_mcast, + st->rcv_probes_ucast, + + st->periodic_gc_runs, + st->forced_gc_runs + ); + + return 0; +} + +static struct seq_operations neigh_stat_seq_ops =3D { + .start =3D neigh_stat_seq_start, + .next =3D neigh_stat_seq_next, + .stop =3D neigh_stat_seq_stop, + .show =3D neigh_stat_seq_show, +}; + +static int neigh_stat_seq_open(struct inode *inode, struct file *file) +{ + int ret =3D seq_open(file, &neigh_stat_seq_ops); + + if (!ret) { + struct seq_file *sf =3D file->private_data; + sf->private =3D PDE(inode); + } + return ret; +}; + +static struct file_operations neigh_stat_seq_fops =3D { + .owner =3D THIS_MODULE, + .open =3D neigh_stat_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release, +}; + #endif /* CONFIG_PROC_FS */ =20 #ifdef CONFIG_ARPD Index: linux-2.6.9-rc2-bk9-neigh1/net/ipv6/ndisc.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/ipv6/ndisc.c 2004-09-26 12:29:03.00= 0000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/ipv6/ndisc.c 2004-09-28 00:05:29.9179128= 88 +0200 @@ -802,9 +802,9 @@ } =20 if (inc) - nd_tbl.stats.rcv_probes_mcast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_mcast); else - nd_tbl.stats.rcv_probes_ucast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_ucast); =20 /*=20 * update / create cache entry --bXLrh1gl3UpYNtAG-- --f+d0/Pr67PH7qeXv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWJJHXaXGVTD0i/8RAmCTAJ4+4ZnaIOs8C5rhlCFtScuzKzS+yQCeNFpp k5aeLwiZG1eAuJO9+wbJDFE= =UwDd -----END PGP SIGNATURE----- --f+d0/Pr67PH7qeXv-- From laforge@gnumonks.org Mon Sep 27 15:26:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:26:36 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RMQTOx015287 for ; Mon, 27 Sep 2004 15:26:30 -0700 Received: from dsl-082-082-094-050.arcor-ip.net ([82.82.94.50] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CC3wn-0001vK-GB; Tue, 28 Sep 2004 00:26:17 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CC3wj-0007Hl-AJ; Tue, 28 Sep 2004 00:26:13 +0200 Date: Tue, 28 Sep 2004 00:26:13 +0200 From: Harald Welte To: "David S. Miller" Cc: Herbert Xu , netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh / Statistics Message-ID: <20040927222613.GE3236@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YkFcLeXky5t3pWWo" Content-Disposition: inline In-Reply-To: <20040927121403.767e2308.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 2237 Lines: 62 --YkFcLeXky5t3pWWo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 27, 2004 at 12:14:03PM -0700, David S. Miller wrote: > Herbert Xu wrote: >=20 > > David S. Miller wrote: > > >=20 > > > 4) The controversial/RFC patch, dorking with neigh_forced_gc() > > > > > > + if (n->nud_state -=3D NUD_INCOMPLETE && > > > + reap_incomplete =3D=3D 0 && > > > + time_after(jiffies, > > > + n->used + n->parms->retrans_time)) { > > > + num_incomplete++; > > > + goto next_ent; > >=20 > > That should either be time_before, or you need to swap the arguments. >=20 > Good catch, and it means that the code basically behaved > as if the NUD_INCOMPLETE tests weren't even there. which also explains why my statistics code actually never catched a forced GC that didn't fulfill it's goal ;) to get back at the statistics code: As stated before, I would like to change rt_stat and ct_stat in order to include a first 'template' line, too. This way it is easier to write a generic foo_stat program, that could deal with any of those statistics files, even with new ones... but this of course would break existing rtstat binaries. I personally don't care, since it's a little-known and little-used feature, which to my knowledge is in a lot of distributions either non-existant [Debian] or incompatible [SuSE]. What do you think? --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --YkFcLeXky5t3pWWo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWJOFXaXGVTD0i/8RAttdAJ46y0WvHd7p5THuSvS2OQadK6fKtQCdH7ed 9c7s7nLPVCdrwYVGwMGb0AU= =2OoZ -----END PGP SIGNATURE----- --YkFcLeXky5t3pWWo-- From jheffner@psc.edu Mon Sep 27 15:39:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:39:16 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RMd4ck015905 for ; Mon, 27 Sep 2004 15:39:05 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8RMchVe029655 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 27 Sep 2004 18:38:43 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8RMcgvD017425; Mon, 27 Sep 2004 18:38:43 -0400 (EDT) Date: Mon, 27 Sep 2004 18:38:42 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Andi Kleen , , , , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: <20040923161141.4ea9be4c.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1055 Lines: 35 On Thu, 23 Sep 2004, David S. Miller wrote: > > I think I know what may be going on here. > > Let's say that we even get the congestion window openned up > so that we can build 64K TSO frames, that's around 43 or 44 > 1500 mtu frames. > > That means as the window fills up, we have to see 44 ACKs > before we are able to send the next TSO frame. Needless to > say that breaks ACK clocking completely. More specifically, I think it is an interaction with delayed ack (acking less than 1 virtual segment), and the small cwnd. This works for me, but I'm not sure that aren't some lurking problems still. ===== net/ipv4/tcp_output.c 1.58 vs edited ===== --- 1.58/net/ipv4/tcp_output.c 2004-09-14 00:39:17 -04:00 +++ edited/net/ipv4/tcp_output.c 2004-09-27 18:26:43 -04:00 @@ -642,8 +657,8 @@ * do not exceed congestion window. */ factor = large_mss / mss_now; - if (factor > tp->snd_cwnd) - factor = tp->snd_cwnd; + if (factor > (tp->snd_cwnd>>3)) + factor = max(tp->snd_cwnd>>3, 1); tp->mss_cache = mss_now * factor; } -John From cat@zip.com.au Mon Sep 27 15:51:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 15:51:15 -0700 (PDT) Received: from theirongiant.lochness.weebeastie.net (sol.linkinnovations.com [203.94.173.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RMpAkS016732 for ; Mon, 27 Sep 2004 15:51:10 -0700 Received: from theirongiant.lochness.weebeastie.net (localhost.localdomain [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.13.1/8.13.1/Debian-13) with ESMTP id i8RMnwTC008196; Tue, 28 Sep 2004 08:49:58 +1000 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.13.1/8.13.1/Debian-13) id i8RMnvxN008195; Tue, 28 Sep 2004 08:49:57 +1000 X-Authentication-Warning: theirongiant.lochness.weebeastie.net: hogarth set sender to cat@zip.com.au using -f Date: Tue, 28 Sep 2004 08:49:57 +1000 From: CaT To: Arnaldo Carvalho de Melo Cc: linux-kernel@vger.kernel.org, davem@davemloft.net, jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: strange network slowness in 2.6 unless pingflooding Message-ID: <20040927224957.GA1043@zip.com.au> References: <20040927090342.GA1794@zip.com.au> <41587A26.6020606@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41587A26.6020606@conectiva.com.br> Organisation: Furball Inc. User-Agent: Mutt/1.5.6+20040722i X-archive-position: 9546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev Content-Length: 764 Lines: 22 On Mon, Sep 27, 2004 at 05:37:58PM -0300, Arnaldo Carvalho de Melo wrote: > CaT wrote: > >Hi, > > > >This is still happening. I ran the same set of tests on a totally > >different network, with my xircom realport ethernet card (tulip > >driver - 16bit) and from linux to linux and windows to linux. Scrolling > >through a message in mutt eventually slows down and if I lift my finger > >off the enter key whilst it's slow the scrolling keeps going, as if it > >was all bufferd. If I do a pingflood (ping -f) from a machine to my > >laptop it's all fine. > > > >I am also now running 2.6.9-rc1-mm4. > > Have you tried FAQ: > > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling It does not help. Same problem as before. -- Red herrings strewn hither and yon. From davem@davemloft.net Mon Sep 27 16:04:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:04:57 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RN4jq9017379 for ; Mon, 27 Sep 2004 16:04:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC4XU-0000Kr-00; Mon, 27 Sep 2004 16:04:12 -0700 Date: Mon, 27 Sep 2004 16:04:11 -0700 From: "David S. Miller" To: John Heffner Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927160411.22b44f48.davem@davemloft.net> In-Reply-To: References: <20040923161141.4ea9be4c.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 2259 Lines: 62 On Mon, 27 Sep 2004 18:38:42 -0400 (EDT) John Heffner wrote: > On Thu, 23 Sep 2004, David S. Miller wrote: > > > > > I think I know what may be going on here. > > > > Let's say that we even get the congestion window openned up > > so that we can build 64K TSO frames, that's around 43 or 44 > > 1500 mtu frames. > > > > That means as the window fills up, we have to see 44 ACKs > > before we are able to send the next TSO frame. Needless to > > say that breaks ACK clocking completely. > > More specifically, I think it is an interaction with delayed ack (acking > less than 1 virtual segment), and the small cwnd. This works for me, but > I'm not sure that aren't some lurking problems still. Yes, this is supposed to work around the problem, but: 1) It is a hack :-) 2) It doesn't help Andi's case, and I think I know why. The reason Andi Kleen didn't see any improvements from limiting 'factor' is that he is using short lived connections. If you have a connection up for long enough, this allows the congestion window to grow and then it doesn't matter. Something like the following is what I have been talking about. I am able to reproduce the problem here locally and the following makes it go away. Andi, Anton, and niv, can you confirm it does so for you too? If tcp_clean_rtx_queue() doesn't return DATA acked then no congestion growth is allowed to occur. So we only get a snd_cwnd bump once for every tso_factor frames, that stinks :) This is not the final fix. I need to do something like record the upper-most virtual ACK within a TSO frame so we don't say DATA acked for dup-acks that happen to fall in the middle of a TSO frame. ===== net/ipv4/tcp_input.c 1.75 vs edited ===== --- 1.75/net/ipv4/tcp_input.c 2004-09-27 12:00:32 -07:00 +++ edited/net/ipv4/tcp_input.c 2004-09-27 15:35:12 -07:00 @@ -2373,8 +2373,12 @@ * discard it as it's confirmed to have arrived at * the other end. */ - if (after(scb->end_seq, tp->snd_una)) + if (after(scb->end_seq, tp->snd_una)) { + if (scb->tso_factor && + after(tp->snd_una, scb->seq)) + acked |= FLAG_DATA_ACKED; break; + } /* Initial outgoing SYN's get put onto the write_queue * just like anything else we transmit. It is not From davem@davemloft.net Mon Sep 27 16:05:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:05:32 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RN5Qc0017584 for ; Mon, 27 Sep 2004 16:05:26 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC4YA-0000LB-00; Mon, 27 Sep 2004 16:04:54 -0700 Date: Mon, 27 Sep 2004 16:04:54 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [TCP] Fixed mss in tcp_init_cwnd Message-Id: <20040927160454.67cd1e11.davem@davemloft.net> In-Reply-To: <20040927220240.GA7633@gondor.apana.org.au> References: <20040927080828.GA12056@gondor.apana.org.au> <20040927120031.55fb4a49.davem@davemloft.net> <20040927220240.GA7633@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 666 Lines: 18 On Tue, 28 Sep 2004 08:02:40 +1000 Herbert Xu wrote: > On Mon, Sep 27, 2004 at 12:00:31PM -0700, David S. Miller wrote: > > On Mon, 27 Sep 2004 18:08:28 +1000 > > Herbert Xu wrote: > > > > > The MSS in tcp_init_cwnd should be the real one instead of the TSO value. > > > > This happens too early in the connections lifetime > > to make a difference for anything. > > I know. That's why I put it in a different thread. > > IMHO we should still fix it though at least for consistency. That early on in the connection, it should be setting both values, right? If so your patch still needs a tweak. :) From davem@davemloft.net Mon Sep 27 16:07:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:07:06 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RN70ZI018120 for ; Mon, 27 Sep 2004 16:07:01 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC4Zo-0000La-00; Mon, 27 Sep 2004 16:06:36 -0700 Date: Mon, 27 Sep 2004 16:06:36 -0700 From: "David S. Miller" To: Harald Welte Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [6/6]: jenkins hash for neigh / Statistics Message-Id: <20040927160636.7741d973.davem@davemloft.net> In-Reply-To: <20040927222613.GE3236@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 776 Lines: 15 On Tue, 28 Sep 2004 00:26:13 +0200 Harald Welte wrote: > As stated before, I would like to change rt_stat and ct_stat in order to > include a first 'template' line, too. This way it is easier to write a > generic foo_stat program, that could deal with any of those statistics > files, even with new ones... but this of course would break existing > rtstat binaries. I personally don't care, since it's a little-known > and little-used feature, which to my knowledge is in a lot of > distributions either non-existant [Debian] or incompatible [SuSE]. What > do you think? I agree. And while we're add it let's get a fixed rtstat into iproute2 and make sure that binary gets installed by default so maybe the dists will start shipping it properly. From herbert@gondor.apana.org.au Mon Sep 27 16:09:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:10:06 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RN9uO7018501 for ; Mon, 27 Sep 2004 16:09:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC4cl-0001Li-00; Tue, 28 Sep 2004 09:09:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC4ck-00026H-00; Tue, 28 Sep 2004 09:09:38 +1000 Date: Tue, 28 Sep 2004 09:09:38 +1000 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [TCP] Fixed mss in tcp_init_cwnd Message-ID: <20040927230938.GA8022@gondor.apana.org.au> References: <20040927080828.GA12056@gondor.apana.org.au> <20040927120031.55fb4a49.davem@davemloft.net> <20040927220240.GA7633@gondor.apana.org.au> <20040927160454.67cd1e11.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927160454.67cd1e11.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 893 Lines: 23 On Mon, Sep 27, 2004 at 04:04:54PM -0700, David S. Miller wrote: > > > IMHO we should still fix it though at least for consistency. > > That early on in the connection, it should be setting both > values, right? If so your patch still needs a tweak. :) I'm not saying that this patch makes any difference in terms of run-time results. At that point both mss_cache and mss_cache_std should contain the same values. However, since the value that's intended here is the physical MSS, we should use mss_cache_std for the sake of consistency. The only reason I spotted this at all is because I grepped -w for mss_cache and found this function as one of the very few users. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon Sep 27 16:19:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:19:22 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RNJGo4022149 for ; Mon, 27 Sep 2004 16:19:17 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC4lZ-0000Mr-00; Mon, 27 Sep 2004 16:18:45 -0700 Date: Mon, 27 Sep 2004 16:18:45 -0700 From: "David S. Miller" To: CaT Cc: acme@conectiva.com.br, linux-kernel@vger.kernel.org, jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: strange network slowness in 2.6 unless pingflooding Message-Id: <20040927161845.1442bb4a.davem@davemloft.net> In-Reply-To: <20040927224957.GA1043@zip.com.au> References: <20040927090342.GA1794@zip.com.au> <41587A26.6020606@conectiva.com.br> <20040927224957.GA1043@zip.com.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 509 Lines: 14 On Tue, 28 Sep 2004 08:49:57 +1000 CaT wrote: > It does not help. Same problem as before. Please give us some exact specifics about your network setup so that someone can possibly reproduce your problem locally. In particular, if there are hubs or switches involved on your local network that might be getting the duplex wrong, or some NAT or firewall machines in the path in question, please specify their setup precisely. Otherwise there is zero chance of this problem ever being fixes. From ak@suse.de Mon Sep 27 16:26:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:26:20 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RNQD3X022580 for ; Mon, 27 Sep 2004 16:26:14 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0A7F4C879A0; Tue, 28 Sep 2004 01:25:56 +0200 (CEST) Date: Tue, 28 Sep 2004 01:25:55 +0200 From: Andi Kleen To: "David S. Miller" Cc: John Heffner , ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040927232554.GB15825@wotan.suse.de> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927160411.22b44f48.davem@davemloft.net> X-archive-position: 9552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 3222 Lines: 46 > The reason Andi Kleen didn't see any improvements from limiting > 'factor' is that he is using short lived connections. If you The netperf test is about 10s - not really short lived and should be enough for slow start. > have a connection up for long enough, this allows the congestion > window to grow and then it doesn't matter. > > Something like the following is what I have been talking about. > I am able to reproduce the problem here locally and the following Cool. > makes it go away. > > Andi, Anton, and niv, can you confirm it does so for you too? Unfortunately not - with the patch applied I still get 27MB/s Looking at the tcpdump the ack clock goes completely out of sync, the ratio is 4 packets per ack. The sender seems to send packets faster than the target can ack them. It eventually stops for a short time until it gets the ack 01:16:26.034669 10.23.202.31.32777 > 10.23.202.10.34491: P 1983065:1984513(1448) ack 1 win 1460 (DF) 01:16:26.034713 10.23.202.10.34491 > 10.23.202.31.32777: . ack 1984513 win 63712 (DF) 01:16:26.034902 10.23.202.31.32777 > 10.23.202.10.34491: . 1984513:1985961(1448) ack 1 win 1460 (DF) 01:16:26.034910 10.23.202.31.32777 > 10.23.202.10.34491: . 1985961:1987409(1448) ack 1 win 1460 (DF) 01:16:26.034916 10.23.202.31.32777 > 10.23.202.10.34491: . 1987409:1988857(1448) ack 1 win 1460 (DF) 01:16:26.034921 10.23.202.31.32777 > 10.23.202.10.34491: . 1988857:1990305(1448) ack 1 win 1460 (DF) 01:16:26.034926 10.23.202.31.32777 > 10.23.202.10.34491: . 1990305:1991753(1448) ack 1 win 1460 (DF) 01:16:26.034998 10.23.202.10.34491 > 10.23.202.31.32777: . ack 1991753 win 63712 (DF) 01:16:26.035144 10.23.202.31.32777 > 10.23.202.10.34491: . 1991753:1993201(1448) ack 1 win 1460 (DF) 01:16:26.035152 10.23.202.31.32777 > 10.23.202.10.34491: . 1993201:1994649(1448) ack 1 win 1460 (DF) 01:16:26.035158 10.23.202.31.32777 > 10.23.202.10.34491: . 1994649:1996097(1448) ack 1 win 1460 (DF) 01:16:26.035163 10.23.202.31.32777 > 10.23.202.10.34491: . 1996097:1997545(1448) ack 1 win 1460 (DF) 01:16:26.035169 10.23.202.31.32777 > 10.23.202.10.34491: P 1997545:1998993(1448) ack 1 win 1460 (DF) 01:16:26.035214 10.23.202.10.34491 > 10.23.202.31.32777: . ack 1998993 win 63712 (DF) 01:16:26.035393 10.23.202.31.32777 > 10.23.202.10.34491: . 1998993:2000441(1448) ack 1 win 1460 (DF) 01:16:26.035401 10.23.202.31.32777 > 10.23.202.10.34491: . 2000441:2001889(1448) ack 1 win 1460 (DF) 01:16:26.035406 10.23.202.31.32777 > 10.23.202.10.34491: . 2001889:2003337(1448) ack 1 win 1460 (DF) -Andi From shemminger@osdl.org Mon Sep 27 16:28:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:28:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RNSHo8022967 for ; Mon, 27 Sep 2004 16:28:18 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8RNRZv06673; Mon, 27 Sep 2004 16:27:35 -0700 Subject: Re: [6/6]: jenkins hash for neigh / Statistics From: Stephen Hemminger To: "David S. Miller" Cc: Harald Welte , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20040927160636.7741d973.davem@davemloft.net> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> Content-Type: text/plain Organization: Open Source Development Lab Date: Mon, 27 Sep 2004 16:27:38 -0700 Message-Id: <1096327658.1729.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 904 Lines: 19 On Mon, 2004-09-27 at 16:06 -0700, David S. Miller wrote: > On Tue, 28 Sep 2004 00:26:13 +0200 > Harald Welte wrote: > > > As stated before, I would like to change rt_stat and ct_stat in order to > > include a first 'template' line, too. This way it is easier to write a > > generic foo_stat program, that could deal with any of those statistics > > files, even with new ones... but this of course would break existing > > rtstat binaries. I personally don't care, since it's a little-known > > and little-used feature, which to my knowledge is in a lot of > > distributions either non-existant [Debian] or incompatible [SuSE]. What > > do you think? > > I agree. And while we're add it let's get a fixed rtstat into > iproute2 and make sure that binary gets installed by default > so maybe the dists will start shipping it properly. I have the old one in the repository. From herbert@gondor.apana.org.au Mon Sep 27 16:38:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:38:23 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RNcDOC023562 for ; Mon, 27 Sep 2004 16:38:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC531-0001VD-00; Tue, 28 Sep 2004 09:36:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC52t-0002BE-00; Tue, 28 Sep 2004 09:36:39 +1000 Date: Tue, 28 Sep 2004 09:36:39 +1000 To: "David S. Miller" Cc: John Heffner , ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040927233639.GA8333@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927160411.22b44f48.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1248 Lines: 35 On Mon, Sep 27, 2004 at 11:04:11PM +0000, David S. Miller wrote: > > If tcp_clean_rtx_queue() doesn't return DATA > acked then no congestion growth is allowed to occur. So we only > get a snd_cwnd bump once for every tso_factor frames, that stinks :) Yes that'll do it :) > ===== net/ipv4/tcp_input.c 1.75 vs edited ===== > --- 1.75/net/ipv4/tcp_input.c 2004-09-27 12:00:32 -07:00 > +++ edited/net/ipv4/tcp_input.c 2004-09-27 15:35:12 -07:00 > @@ -2373,8 +2373,12 @@ > * discard it as it's confirmed to have arrived at > * the other end. > */ > - if (after(scb->end_seq, tp->snd_una)) > + if (after(scb->end_seq, tp->snd_una)) { > + if (scb->tso_factor && > + after(tp->snd_una, scb->seq)) > + acked |= FLAG_DATA_ACKED; > break; I think you need to at least decrement packets_out here. Otherwise the prior_in_flight >= tp->snd_cwnd check in tcp_ack() might become incorrect for the next ack. Even better, you could move the skb->data pointer forward and forget about that segment altogether. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon Sep 27 16:38:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:38:20 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RNcFcI023569 for ; Mon, 27 Sep 2004 16:38:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC543-0000OL-00; Mon, 27 Sep 2004 16:37:51 -0700 Date: Mon, 27 Sep 2004 16:37:51 -0700 From: "David S. Miller" To: Andi Kleen Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927163751.274f6071.davem@davemloft.net> In-Reply-To: <20040927232554.GB15825@wotan.suse.de> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927232554.GB15825@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 584 Lines: 15 On Tue, 28 Sep 2004 01:25:55 +0200 Andi Kleen wrote: > Unfortunately not - with the patch applied I still get 27MB/s And without TSO you get? How exactly are you running netperf and are you going through a switch? I want to reproduce your test case exactly here although using tg3 instead of e1000 :) > Looking at the tcpdump the ack clock goes completely out of sync, > the ratio is 4 packets per ack. The sender seems to send packets > faster than the target can ack them. It eventually stops for a > short time until it gets the ack Hmmm, thanks for the trace. From ak@suse.de Mon Sep 27 16:51:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 16:51:51 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8RNpdGJ024708 for ; Mon, 27 Sep 2004 16:51:40 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 92C35C85502; Tue, 28 Sep 2004 01:51:18 +0200 (CEST) Date: Tue, 28 Sep 2004 01:51:17 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , jheffner@psc.edu, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040927235117.GC15825@wotan.suse.de> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927232554.GB15825@wotan.suse.de> <20040927163751.274f6071.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927163751.274f6071.davem@davemloft.net> X-archive-position: 9556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 853 Lines: 28 On Mon, Sep 27, 2004 at 04:37:51PM -0700, David S. Miller wrote: > On Tue, 28 Sep 2004 01:25:55 +0200 > Andi Kleen wrote: > > > Unfortunately not - with the patch applied I still get 27MB/s > > And without TSO you get? How exactly are you running netperf ~66MB/s > and are you going through a switch? I want to reproduce your Yes, a buffalo gigabit switch. > test case exactly here although using tg3 instead of e1000 :) I'm running the test from a e1000 through the switch to a tg3 (tg3 with an older kernel). I also tested it now from a tg3 machine to the other tg3 machine. That's 48MB/s (with your patch). The tg3 machine is slower though because the tg3 sits in a 33Mhz PCI slot, no CSA etc. From the tg3 machine with your patch the numbers are the same both with TSO on and off. Looks like the e1000 is too fast... -Andi From davem@davemloft.net Mon Sep 27 17:14:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 17:14:41 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S0EUm0025622 for ; Mon, 27 Sep 2004 17:14:30 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC5cy-0000QG-00; Mon, 27 Sep 2004 17:13:56 -0700 Date: Mon, 27 Sep 2004 17:13:56 -0700 From: "David S. Miller" To: Herbert Xu Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927171356.6a59d039.davem@davemloft.net> In-Reply-To: <20040927233639.GA8333@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 5495 Lines: 169 On Tue, 28 Sep 2004 09:36:39 +1000 Herbert Xu wrote: > I think you need to at least decrement packets_out here. Otherwise > the prior_in_flight >= tp->snd_cwnd check in tcp_ack() might become > incorrect for the next ack. > > Even better, you could move the skb->data pointer forward and forget > about that segment altogether. Bright minds think alike. :-) We have to keep all the other packet counts in sync as well. Andi, others, forget my previous hack patch to tcp_clean_rtx_queue() and give this more complete patch a try. I'm getting really good results here on my tg3<-->tg3 setup using this patch. ===== include/net/tcp.h 1.89 vs edited ===== --- 1.89/include/net/tcp.h 2004-09-27 11:57:52 -07:00 +++ edited/include/net/tcp.h 2004-09-27 15:56:24 -07:00 @@ -1180,7 +1180,8 @@ __u16 urg_ptr; /* Valid w/URG flags is set. */ __u32 ack_seq; /* Sequence number ACK'd */ - __u32 tso_factor; + __u16 tso_factor; /* If > 1, TSO frame */ + __u16 tso_offset; /* ACK within TSO frame */ }; #define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0])) ===== net/ipv4/tcp_input.c 1.75 vs edited ===== --- 1.75/net/ipv4/tcp_input.c 2004-09-27 12:00:32 -07:00 +++ edited/net/ipv4/tcp_input.c 2004-09-27 16:36:29 -07:00 @@ -2355,6 +2355,60 @@ } } +static int tcp_tso_acked(struct tcp_opt *tp, struct sk_buff *skb, + __u32 now, __s32 *seq_rtt) +{ + struct tcp_skb_cb *scb = TCP_SKB_CB(skb); + __u32 tso_seq = scb->seq + scb->tso_offset; + __u32 mss = tp->mss_cache_std; + __u32 snd_una = tp->snd_una; + int acked = 0; + + /* If we get here, the whole TSO packet has not been + * acked. + */ + BUG_ON(!after(scb->end_seq, snd_una) || + tso_seq == scb->end_seq); + + while (!after(tso_seq + mss, snd_una)) { + __u8 sacked = scb->sacked; + + tso_seq += mss; + acked |= FLAG_DATA_ACKED; + BUG_ON(pskb_pull(skb, mss) == NULL); + if (sacked) { + if (sacked & TCPCB_RETRANS) { + if(sacked & TCPCB_SACKED_RETRANS) + tcp_dec_pcount_explicit(&tp->retrans_out, 1); + acked |= FLAG_RETRANS_DATA_ACKED; + *seq_rtt = -1; + } else if (*seq_rtt < 0) + *seq_rtt = now - scb->when; + if (sacked & TCPCB_SACKED_ACKED) + tcp_dec_pcount_explicit(&tp->sacked_out, 1); + if (sacked & TCPCB_LOST) + tcp_dec_pcount_explicit(&tp->lost_out, 1); + /* We can only exit URG mode for full TSO packet ack, + * by definition, so we need not do that check here. + */ + } else if (*seq_rtt < 0) + *seq_rtt = now - scb->when; + + if (tcp_get_pcount(&tp->fackets_out)) + tcp_dec_pcount_explicit(&tp->fackets_out, 1); + tcp_dec_pcount_explicit(&tp->packets_out, 1); + scb->tso_factor--; + + BUG_ON(scb->tso_factor == 0); + BUG_ON(!before(tso_seq, scb->end_seq)); + } + + scb->tso_offset = (tso_seq - scb->seq); + + return acked; +} + + /* Remove acknowledged frames from the retransmission queue. */ static int tcp_clean_rtx_queue(struct sock *sk, __s32 *seq_rtt_p) { @@ -2373,8 +2427,12 @@ * discard it as it's confirmed to have arrived at * the other end. */ - if (after(scb->end_seq, tp->snd_una)) + if (after(scb->end_seq, tp->snd_una)) { + if (scb->tso_factor) + acked |= tcp_tso_acked(tp, skb, + now, &seq_rtt); break; + } /* Initial outgoing SYN's get put onto the write_queue * just like anything else we transmit. It is not ===== net/ipv4/tcp_output.c 1.59 vs edited ===== --- 1.59/net/ipv4/tcp_output.c 2004-09-27 11:57:52 -07:00 +++ edited/net/ipv4/tcp_output.c 2004-09-27 15:52:15 -07:00 @@ -436,6 +436,7 @@ factor /= mss_std; TCP_SKB_CB(skb)->tso_factor = factor; } + TCP_SKB_CB(skb)->tso_offset = 0; } /* Function to create two new TCP segments. Shrinks the given segment @@ -1191,6 +1192,7 @@ TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_FIN); TCP_SKB_CB(skb)->sacked = 0; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_offset = 1; /* FIN eats a sequence byte, write_seq advanced by tcp_queue_skb(). */ TCP_SKB_CB(skb)->seq = tp->write_seq; @@ -1223,6 +1225,7 @@ TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_RST); TCP_SKB_CB(skb)->sacked = 0; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_offset = 1; /* Send it off. */ TCP_SKB_CB(skb)->seq = tcp_acceptable_seq(sk, tp); @@ -1304,6 +1307,7 @@ TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(skb)->seq + 1; TCP_SKB_CB(skb)->sacked = 0; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_offset = 1; th->seq = htonl(TCP_SKB_CB(skb)->seq); th->ack_seq = htonl(req->rcv_isn + 1); if (req->rcv_wnd == 0) { /* ignored for retransmitted syns */ @@ -1406,6 +1410,7 @@ TCP_ECN_send_syn(sk, tp, buff); TCP_SKB_CB(buff)->sacked = 0; TCP_SKB_CB(buff)->tso_factor = 1; + TCP_SKB_CB(buff)->tso_offset = 1; buff->csum = 0; TCP_SKB_CB(buff)->seq = tp->write_seq++; TCP_SKB_CB(buff)->end_seq = tp->write_seq; @@ -1506,6 +1511,7 @@ TCP_SKB_CB(buff)->flags = TCPCB_FLAG_ACK; TCP_SKB_CB(buff)->sacked = 0; TCP_SKB_CB(buff)->tso_factor = 1; + TCP_SKB_CB(buff)->tso_offset = 1; /* Send it off, this clears delayed acks for us. */ TCP_SKB_CB(buff)->seq = TCP_SKB_CB(buff)->end_seq = tcp_acceptable_seq(sk, tp); @@ -1541,6 +1547,7 @@ TCP_SKB_CB(skb)->flags = TCPCB_FLAG_ACK; TCP_SKB_CB(skb)->sacked = urgent; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_offset = 1; /* Use a previous sequence. This should cause the other * end to send an ack. Don't queue or clone SKB, just From davem@davemloft.net Mon Sep 27 17:15:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 17:15:46 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S0Ffix025906 for ; Mon, 27 Sep 2004 17:15:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC5eK-0000QZ-00; Mon, 27 Sep 2004 17:15:20 -0700 Date: Mon, 27 Sep 2004 17:15:20 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, jheffner@psc.edu, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927171520.632714fa.davem@davemloft.net> In-Reply-To: <20040927235117.GC15825@wotan.suse.de> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927232554.GB15825@wotan.suse.de> <20040927163751.274f6071.davem@davemloft.net> <20040927235117.GC15825@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 405 Lines: 12 On Tue, 28 Sep 2004 01:51:17 +0200 Andi Kleen wrote: > Looks like the e1000 is too fast... Yes, the e1000 does TSO expansion much faster than the MIPS cpus on the tg3. I believe the e1000 implementation is in the ASIC instead of being implemented with a firmware runing on a general purpose on-board processor. In the 5705 and later revisions, the tg3 implements TSO in the ASIC as well. From herbert@gondor.apana.org.au Mon Sep 27 17:35:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 17:35:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S0Z0KI026764 for ; Mon, 27 Sep 2004 17:35:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC5wg-0001oa-00; Tue, 28 Sep 2004 10:34:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC5wa-0002I0-00; Tue, 28 Sep 2004 10:34:12 +1000 Date: Tue, 28 Sep 2004 10:34:12 +1000 To: "David S. Miller" Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040928003412.GA8755@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927171356.6a59d039.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1628 Lines: 53 On Mon, Sep 27, 2004 at 05:13:56PM -0700, David S. Miller wrote: > > I'm getting really good results here on my tg3<-->tg3 setup using > this patch. Yes this looks very good. Just a few minor things below. > ===== net/ipv4/tcp_input.c 1.75 vs edited ===== > --- 1.75/net/ipv4/tcp_input.c 2004-09-27 12:00:32 -07:00 > +++ edited/net/ipv4/tcp_input.c 2004-09-27 16:36:29 -07:00 > @@ -2355,6 +2355,60 @@ > } > } > > +static int tcp_tso_acked(struct tcp_opt *tp, struct sk_buff *skb, > + __u32 now, __s32 *seq_rtt) > +{ > + struct tcp_skb_cb *scb = TCP_SKB_CB(skb); > + __u32 tso_seq = scb->seq + scb->tso_offset; > + __u32 mss = tp->mss_cache_std; In future we should probably record the MSS in the scb just in case it changes. > @@ -2373,8 +2427,12 @@ > * discard it as it's confirmed to have arrived at > * the other end. > */ > - if (after(scb->end_seq, tp->snd_una)) > + if (after(scb->end_seq, tp->snd_una)) { > + if (scb->tso_factor) tso_factor > 1 > ===== net/ipv4/tcp_output.c 1.59 vs edited ===== > --- 1.59/net/ipv4/tcp_output.c 2004-09-27 11:57:52 -07:00 > +++ edited/net/ipv4/tcp_output.c 2004-09-27 15:52:15 -07:00 > @@ -1191,6 +1192,7 @@ > TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_FIN); > TCP_SKB_CB(skb)->sacked = 0; > TCP_SKB_CB(skb)->tso_factor = 1; > + TCP_SKB_CB(skb)->tso_offset = 1; Is this a clever trick that I don't understand? :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ravinandan.arakali@s2io.com Mon Sep 27 17:36:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 17:36:32 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S0aPTk027026 for ; Mon, 27 Sep 2004 17:36:26 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8S0a7je026464; Mon, 27 Sep 2004 20:36:07 -0400 (EDT) Received: from rarakali ([10.16.16.160]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id i8S0a139028172; Mon, 27 Sep 2004 20:36:02 -0400 (EDT) Reply-To: From: "Ravinandan Arakali" To: "'Jeff Garzik'" Cc: , , , Subject: RE: Patch submission for S2io Xframe driver to 2.6 kernel Date: Mon, 27 Sep 2004 17:42:51 -0700 Message-ID: <005801c4a4f4$1598d6d0$a010100a@S2IOtech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0059_01C4A4B9.6939FED0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <414A3562.2090803@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 9560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@s2io.com Precedence: bulk X-list: netdev Content-Length: 62340 Lines: 850 This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C4A4B9.6939FED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Attached are the updated patches. It is designed to work on the latest kernel. Also, this time the submission is split to 3 patches(they need to applied in the order mentioned below). s2io_styling_level1 - Contains a. styling related, function name changes. b. fix for 32-bit systems. c. modified Transmit descriptor allocation strategy. d. miscellaneous fixes. with_napi_level2 - Fixes/tunes NAPI feature with_2buff_level3 - Adds support for 2-buffer mode. Please review and get back with your comments. Thanks, Ravi -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Thursday, September 16, 2004 5:53 PM To: ravinandan.arakali@s2io.com Cc: netdev@oss.sgi.com; leonid.grossman@s2io.com; raghavendra.koushik@s2io.com; rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel Ravinandan Arakali wrote: > Jeff, > We tried it out with 2.6.7. Can you pls specify the kernel version > on which you tried and we will send a patch which works for that version. > We will also send a more detailed description of the changes along with > that. Always diff against the latest version of the kernel. You can find out the latest version by going to http://www.kernel.org/ You'll typically want the latest snapshot (preferably), or the latest pre-patch. Standard patch submission format is described at http://linux.yyz.us/patch-format.html and in Documentation/SubmittingPatches. When submitting a series of patches, it is normal patches to depend on preceding patches. Jeff ------=_NextPart_000_0059_01C4A4B9.6939FED0 Content-Type: application/x-compressed; name="s2io_submit_2_2.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="s2io_submit_2_2.tgz" H4sIAPmYWEEAA+Q8a3PayLL7lfyK2ZzaLJiHeRocb3KW8Eio2NgXyCZ7clIqIQ22YiERSdg4u/nv t7tnJPQEnN1T9966rooNo56e6fdjRjFVj7ue4q7nS8N1Dds6/uFv/6lWm9V2qwV/6Sf+lz7XqrX6 Sa3WbDTbP1RrjUb95AfW+vu3kvxZu57qMPaDY9veLrh9z/+P/pgJ+bt1w1Zc78E0rGvF5HfcrFVW qqfdfPca1Vq1etJspsu/2a7X6y1f/g3490O1Xq03Qf7Vv5HOzJ//5/LXjcWCldfOmN2plmGaahnk vt6U65WTSqdSO9Yd44477rHFPdKMisb2ATwpl8sHY8vVQQXK1dNyvc5q7efN1vNauxK4BVautqvV J8Vice+qMUSt0+eNegLRr7+y8kmtdMKK8LvNfv31CfuHYWnmWue/qO7yeK1qGnfdys3L0ANa+RiX A/OIPsI5sDiMFWPgK8fWlEUqpnvbuf2y5mtOD5+w4yNm2ppqMgnGjo7FRk9hi8V2tVQ7oZ0S5BSI ZX2inlnqkrNnzN8ZzmOgzZ6hMe0GlJosWXBKQdiPn9gL9hRHn549KWdBSnQC+DfxhdUqVZhTfOSc dqVVqeG8J0XY+pMiO2I91dFddm94N2xhm6Z9D16GgfdxH1yPLxVDZzfqHWcqyvuWqOHAF93QYGHb IhTA2rnJlyV2Uq2+ot89+t2H300aaVZ7TLV0/NCv0Jylqjk2m3NYkBk6tzxjYXCXeTfc5UyjPV0D JRaORLZD049BvDpfGBZnve6kP1Xej2ZvlGH33fnsd+V8NH6rjMb9Ua87u5xM8zDb0Avs30+KuVw+ L76yly9YdYP7LbBnz5gc/EUO9gsF9uefYgaLzmimzWjijAL7J6ux56yKiuHvTuxlqry7yt+p5kmz wPI/ik+gJ/luv3s1G0yU6aw7ezdVJhfdnjIZXFzOBoIWhntgOfhh9JMGf37Z654LcNgD6WkHNLTK iqfwp0aKKrXEsEzck2F5zNko8/ViAZpCASVvGZrigVjcVUk+nyuu8ZXLb6AThSfsD9gLfqUpoFhV UNqcsUAOrcovV7eeolneRwT+xMoBigJ7yWr1TgGmFw+EPinQWjl/ofPL97gUzfYB2S8sieeYdQoo tAOW+YVddD8okw+gPFfA0lfAx7dy2WDdq+541DtDhN9g/BsKNudwb+1YggdnxO7T01KzxYq1WhX/ Ir+/nSFo2Da5d+PZtqngmKvc8gf346ePA9DZ19PZZDR+rZwPxmirfwCZTz0wDmXhLN2npeCrrnqq Ymse9yKjjr2KQy41SB9iY/OUsZW6drmieY4Zf6JaDwp3nPjwnakrxiq5CTEe31VkxNCW4a8O7MbT wiPRb2tdfnN8/NutOKncoNGF5sb27aQwKcAZY1QwPk8ZNyzFoezLSlvBtOFZbCyVvWI/hosOjieo WqNmJkbt1NGFoyaW/KzO5zyxOWMV+ZJk243uEFERwIgMnagMnYjEnKTEEJvurGKjkiOWFxrD8L7y uB5dCucL/MXcHyFz+BYaCKtAZDyQdnh0K+vw6Dx1NC658LOIaYQfRI0j+SS5x9gYsTc84BtJeCz+ HRksv0dNJTyYwqmkuUQmxFmYYjLxJwlWZppN+PnWcMKjGQJIM57wo7D5hMftjPGtCYVHw0YUIWUV +5rG0pApJRgaRxCStxOTrZMm27BRpXALzCo8GjasOBa5kgxTfqoyrY8uKbPAWMSQZ/Yin4xbhWMW i1sUBGvNNibHtVan1BFpfBQtAk8ROkcDs8FUrHOUwAZbelKG7LRnW7Cq5UFSiIkiZpnXjrpcch1z EpsSww/cUn92mcOvDUgPHQLVbGthXK8dHspx/zIqBlgIqvtuVMFvkNkLujsdpBtqndIp0Z0bjPvK dPR6LPkbJWVhO2xobDDHRnQXqtbVdQcqHD+JZi6HpHdpu575wDC/TqPi0Vhw+11zdaNi3n0DYnF9 ImSSsoaEdGFsFHj8UeQhSFy9eoq1TrFeb5ROWunkURF0YetrE7JdW9VVWJ+tVGAvRzZSEeSXNutG nXJJxVovz7Zrw+gC4dFPfBRZmUL68uksOXUPzMJY2AJ9YtSfOfugDEfDS5wZ3gKkxCvHsKODnj8Y YOsw7NBY2oPiGUuo+SgNLgaV2NpyjWtLKBYzXVsBtUKOvGC1s3QgWUxx4D0sdgviFSjTYLVbd71U 7MXCBE7vRz3bDIHw8Xq5GwaYcQ4eugpQ/QFVEsQgtMa9k2o7druFqh8E1TgIqnkQVOsgqJODoNo7 oC7UzWzTR5mhak3fvlKGk+7raQb0ZDMBHd4tEAEz/UrymF50z8+hOHmr9MazfRN2ySIA2iWKAGiX JAKgXYIIgHbJIQDaJYYAaJcUphSeHL4AJ3hDhgnAzQzgUNSUkCetVqOVAb0MYG8QuQ25zpfqF2RQ rdN+xJzml/bOOS6UiRCu3ZVpBC7gH1DHijCq5xXFUE+ailLIWBKch5ireI5qIYYPg3FXmb2ZDAbK 9Op8NFNmk+542u3NRpdo1//gpssfiez9ZQYq8GGLdFwiT/UMU1lx8KQ64MpitXM4KPhlcr/KnUqd iM1wOMwGRZxfJVJ4nG17zuFonUegxS0AH6+5ohLW7g64hSaBalnKvsU23w8I6ARUfT86jQAbe9AJ qOYeKJ2gOllQzoEccSIc2YtsD0OcCEP2YtvDD+cgfjiZ/EjJJDaLTgQADdHhEOrnDx7l+ABUP5Od Z8rqMJsGH3FnaJx5mA5URObWaJXqp5C5nXZKDdEEvLjsvzsfKP3Bb6PeQJl1X50P8ivNKIm+sTc3 C+Gules5a81jACBbyuH2smhUiZ4k9rGfP8VtYAEvxgxdob0891EHTzA/lcOGZXiKZWjBM4cv7Tv+ XFGAHL6Bh6s8AcI4whWwiomsVsylLFTMpa5RzO1Hv03Y4Tfwlo2s1dpjXed6veSQdz+Xw33BbkgM 77Abfqc6huA8PZ2IBuFvqrnm/ozpu15vMJ1CKs7cNZ1oUDtctZi6gu0CJkRUvkNkMA3hFqphQuVR 8Zd0NcdYYcvdxzmDzH+xtjQcY6qJJxae6KDjN7YEcp0HBkFFdWVwkRPn3LvnsrM+HonGPH4Wsq0A YsP1jz5cSINAvcTituOWJI5JZDRAQcrjgv64bA4buq1Q9dKFanIJ4WRhgOqIxj8ER53Nbe+GzR8Y SolQQPjmfiCE/bOh5eYLlUi7H0oyT4UPUGNbOt/kIakvMXDBCofCpsDyOFD0v7MyqxXY8fa5KKeO qJwi3QgtVoYKiZhI/ITdjADAUE3jqxiyF+yCeEqzfwWVeZ6tCQgSkdn3SAuR/EVhIYqDZcXCtZoo TQxvSpsByvPSJZDRAPXsCK0mVPr4M0JMzZhDbXYsr7DLADaXu7MNnR15y5Vyp6hQypbCXxSLbzyE 0peqGMCsYqWsJOj2cwA52fQVIgoPNVYOV5wN+FDzFhzX+N35+Zk8yADn97kE1N+ia8U+vyjaPHn0 gZ9QdVbqNe1SEmNxT5Ee9wj+Ak4gqvwSPpIDzYnGFxScsDZ+RpV1bHlYUG9XsV/QAP8sjjtzaCBR xTMSijf70D9HMbPh6HLoUuGeo0MQyhNZDhsCeYO+MYP9IhsX5ZeihoF6A4aLxQIdL4iJxRchoN7i +qPxqYLFItQ7dOARB4KwrsWg6ESEjloI+CVVQN3fuqNzjC1QZven8kCl/+q1cgXV+iw/mEwU+FZi T38CdzqzPcizoFqfg2NAMjcM9+sycO6CWaelVgu41WyW2iKKpSPzblQojsGdzjm5ln9bTzGa5fzT miFs6t1kIPZcFsQdvRAbtxd5qOAUrwCm4lMrqzrAUQbwkBCREbpigt2Qz3hBAZLMGSFcbB1ZHkzB eJYntViBXpSYUKhnmZiU1c1DwT9O+zETTEpQUlUejC8vBhc47duubSruV9ipsDWkZ2taMJw560xC rvZC4uYRGj663MuHzbgqSKfUohwS3WgMRUSgCOeACJ0ru3rz+3PIgn4yzQ2IsISJTfklxnw8GwCm 5oPUCjvH9KsQsv8Cqq5vv+wg+Qp438rpzO811Eujfw0gbviohF0/ysjizKIWquMhq8CIAMl212c7 4AWsIIAdCVrv5Cw85wR/5fe22E5jlcAkMixIgWDJpGD+kd/0JSDyYFS6esSmHGlz8Ehs7HZJup+P oy2x18Mr5e1gMh6ci9mk1wkU4lA4zaZpGCT+9IJWoHQIxI4yCBAIK0fAuEHQiS38khqZWJcUM75p woXTDhe05CqqDjYdhQgi+UmmSCSF8mQ/EmuE64pphKKtHXi8Dmio2IsFEOeHgP3wW0URxsQyIwDm TcTEMFCCAgGVtfI1f9xOw/CP3Sk6tbCvKgbz8pkTj2LeAdyDPyktDOTCXvPvx38YrwGKdPOz0M3P oJu+6sG3QCVJJ29lDwm+xvMmMRrKucQAfcwIaaFYJvVWUBJ4SwhuhFsaJJk7IfT3lGnjaORpSzLf uFMjfsgfAAvPt64gzRcIZ5C7v4E5LH8LbIuYm79DcpDobj+D9KIQRXYr0SNlALTD2RYkXde2ZzNu gQOFWEnUSRQJd/TR/FSh73cGhAgRbn0HyITPhx3Axo+CkFTYiwsiTSqqVRaq22IxxC1x46UovFOE iucUDQ9JWycf+pS1Ygf3EVlr0CUPB1Tk+xZAGhvATDY6+4nlk5d5gMxawXfSoclOIK+DZrMMBcT8 FcoM2PQa1AaIDacrwoOnzkPSfgJmucyyoeply7XpGSvQS0Lh3/YydmHA8wZQTfYKKxyZ6KZkupQU JhL5GO9Sk/04iwgbaZooqohmygDi/jkumeNM3iZ8XkIuu+b6+/Hvdx2ylzJLIWH/NjKmieonnGiG XP5EuHzaaCTaYR1Kx5ixtByrnUbjpFSvsmKz1i7V/WonNjsZK8W+KNlID7Bpk3YF5DR4/+T1ECYn M4cUlqYkDk5KynIwcYfmRWnw/yHiZFvhf9RGsJXpe2mol7DThK2fyUa0fKRPTiQVfkfEzynQv/ia nrFcUvmFW4rUmnsyC1ElCxdIXvBZpLRjMvqGUYp+jgwRRO/IYprqkjuVLdQS9RW3fawCE/Hu+EgG xuxJ4VZWgUnnfITOWwM6uF5ikFNoN8y9sdem7F+q1sMWUvb1qD9xr7qi8wd5i2dIUQSQcl12o65W HCpc0cdvnFK7qNmuy2s1B3UWxG2dbVuByT7Nj+lQkn0HMi9BPHKR7qg8gpVJJIxmxxl5EP9SuUfj x5KJp8C9YrNTL9XqgosZ7Ap5ZMSc3SgJppzFGy90FD0C14LGgl9GshUYL95T8Bl7p7HdTRY8Mdb5 gk3HF1fK9N3V1eVkhqcmqC6W6F5PhR3vbBYVYQ7qWTaXimxXWNseCSMXs7o+mAnt6/qww7o+KOVm tVOq10HMp60gfMqkSB6/APu+PeqAhx98wDO+HA92nNSAugfNf4OulgkN33b+/UzaDQ4HdDZ/EPNR z6Ot+ELoLAEyb0mm4TF5me2WOxY36fQFacVTgJgNQpga4hbkAYRcUagIC51wPOqI47vJLMrrdfHj g0PpjJxcUGEb9Vr7ji6CKQeeXSQOD0qZRxmZBxd+bph6VBAcNojIr9CFOnYkvu09qdg6fNoyWUej jm+DFFs1sJJGwgmCR3hGXiK2C7Fg8NRfn8lO9b5GNQZ8Ymt6J6Hs16W7vNEhYAehErHwP9QgLv7v 6Bs+pkOEPAH1dVM7HqE2TrLF4M+Mdy1k52PucFW2S3YrQKh9FKJq13ohsOjS34vA75IUtk3jW9xw smdcOAveAfqOXJhs8IReHSy2Wh3/FUJEeFhM0tNj0qPvHPxcrv0cul/A8hioVYDhnkdtGsPSbMfh mlc48O6By7+s8QU+8OgP2yvTLuN3HDw+FRosHImYfysDYlDyjB38r34PPljCiiiURXwxsb/H7wxv 0eDCGE/eHL+HMGAv8YvhQLzBQpKuZLgVuSHBahBLFoMF2KPYnHrwPja0w4/crUxgild0ew+YqMhw AuFmrjp4wTSf8qggOx4AceCxN2l3pyUiTKdRqv0tEQZtYgoCwBsy3GFxDiKzQZDG4kHcZ8CXb+cP OBEFgNem/AvyV6MhG3Kul+cqSNy/4o++QNQteI/q8evQvEOWYVSJMJmbM0V5NXqtDMb9UXcsqESl lawFxACkrk0PN4B5jsrmwB+5KXDuSxWzDZvR7sUmvm8+biv6VN7usoAG6k4iBqjCvBugMCAjd+8Y Hv+Sr24WsR+oxKESRbWBauEeKzGH3uKR7q9Vo1r2BP7IWjbHpu+7V+g8e7PJOb18MlWGA/Zn2vh0 QB5Yrk7v0GatxsTd1rIoaQ3pAO45kzfmMSGdG+J1kKV6yzGjFC+aG/hYCDdQje/EQOzdXtUp4WcL UbjcBLOHMcAo0dmWicplQ91MWP3JWPVyKHwtkiSIw5cC8bPRxrL2pNHxXz05kDeyMiP2/EaKjRoM sT6h+eC4gKq1g04XaPKVXZiYyhagKNkm9SjUUWtKRe3rn3h9+gUBf8lLKlfGQnF0xSd2MSdlwfxF gP+ItyurtXqj2Tppd067r3r9wVC2joiZrVN6afrkpBZ4L1e74fheC93PtNde/s2/IOery4YKeqeB EN+EaxCZcONzx1Z1TXU9aq0Vc5BaoJMVRUHBFwm5wMX1WRYx8nlhC/Anvl/QE298v+p1pzPwH3jL JmQR9Kw3fK28HfwOxtnsVfuFQAkciRJf4aLjzFRV2a5bFABmPr9u1AtMggE122ePWzGGUErl5UsG 30osj3wqsmZhy9sJMCT0NpZhCZsLtS0zWQdRUVmq7q3vd9oNspN2YCf+TGo0LL112K+8Gs18rtRL rNaMUUQv6TyYOjaMC0GY6sncwo8E+JoY+A3Y+ULVqBeGr5dVhOEc+hO2pYMXIOhDFyAvM7MD7Dz8 JhwuUQLPhE018nPEITBNF+ya+z4KVgZWgtOSaZJ8oe7ejskOXwmDjGVtqo6cKZIzjVfYG/zDVHk1 9Ofp+9Gs94ZeMvuZ1p7jBUj5HoR46651KkRKjT0RSnI5HWsly8NTTBacvy51yIakrckTMV/UMk4q uqyx5PxPopiU9ZWUPT0TSYssjaZXg96oe65MBq+V95PRbLADn19zJJGV2LuhbG2nqnN0XZag8pv4 j0mqTWRHOxRZczlBeZwfcnM72OFz7KOPIJUh4uGBHElDGeNJGN8+psTWZkliJVvqFCDbjYZkS+TM ucQ+H1Kqs1zggv2DHPIRu26kgEODNY7Qt2FBeFqQHKw1CpDbZE+/cgwbhPFQ8s99IqCpl0JSlipm LBWdv10r+A9Gwpha4Pca0htTGDXwsCWf4BNdsfaD6Em7jR32YjtUAvgSfOSJ/z62B4doODGgheVb eLsByegUJAVprNyeo+2dLs55U8MlYKH/NoheEUUE24AQOnQDN6ea4k43ekv/RMMOTuOCwlSXiRVd l4ikUo9BJ2aEkEp08fTpkQJB+bbrTczgO42a72f280bmMZFk3Pjqx7HZhjn2Glu79hzCROTt62ol JQs/eCrFmKFh4v+ahrBYxU2ypqjiQoU8UIKJ2zvJ4kIyzRZ1u8tcOn2aXfYvw+l4u9GE/KLYadb9 /3YnqJQCroAJ3iu0BYW2oDTCNc0OuOaWh33DFUnnBjbCOaYEEEJVRwfh6f4p7wpSZ+5h6BRAeGRm h9mJuxef/gI+YtV/oZhZla5iWfa9THJoAUqBhdaJ/7qHLOW/23v37jSuZG/4/Ct/io7PiiMZkGlu QlKc58gSslnRbQAlnidPVi8ELYkIAaHBlmcm57O/uy771r0bGqRcZl4xEwu69/1Su6p21a94e4PL OcjD5Bdlf1CSnN1P9tXttLFGTe9ve3nWivlyRUzBTjFfKUuKL7rMbLrh8WAKsulXp1qGEk+lmrCg dlC70QkuL446oP5rnh9t1oHkIoICMMX4pXWeeIRO1allJD1ZRaF8HZep6DQpEHqweC9GXXDSET9Q JoNRn2m9AqAhdIfAv82QS1y4NVcrCVfRldhhnwf92a0HXpWsD5TbSw85SBydjwTxddlpngQ/HJwI 0aMKI48CkuudOd7OAuI+qnrInWXG/VTT9RKIcTIY3WFqOk3TCCH42d6zHxTJk/jw+nrQI0Z/Op/M XHqJ1cvAAW8L4fY+1McCqKE6zbhC1hp88T44Ougc+MFp4xRGsdM8bbR4mI+Pj2HYyPUhkfKydfY+ OBDJDmCm3K/fbYLr5rJCDjfBJdNZCjVHzJi9xRY023Qj1pOe1nrDjXdZ4ndG4qtliQ+NxD1crWjm EncwxtsVpQ5Y3PuU9TibDRAOyMc7OiIFPEyxQS+pFh4f4sT51phbr2HiSo6JsxLBvFXSyzjahFNg yzVvsaZIJ+nkqMYaJd2flyQ8lAl7SxIeyYQLNrwc4JIaYM/qz+HpERb5Y4MHQj5od1rn7xrBWeNH eLSw/N74/l7scGMKxd49BxEaiACosGnvinSTYTgLI1Q9eu0Z+MWiqM63HVyQSVMeU4xHGjziqbzP wCOJhHiHsu39GHqTsXhCh4Fgogx9gDh8+wNEk8QifgSNpygekoJS4GFwL+QMUVm1WLyP1HGiW4hI PdTIPBUh9s9g9g2Z2MpXoGWUKlg2JBAEcTzdZszE3bwv2LfdUj1f0ndzrItaQhhb1l5sLSCMiZQ2 YXS/jhNGdypNGFOakyCMC5o9dRLGtNZPXYQxrS9TF2FM69LUQRgTyAs2YVzS+1SBJZ00qiJLqnWS KJrDbb1FmpicMiuNJonO1w6SmNKQaYIkprRpmiCJKQ2bJkhiShOnS0nidAFJbMVJYmt1kjh9Jom/ E0kUkqyQ9ndrdaVVTLkRKSrbiCRzy5eqrB0WgvYFION4ChmHFMYgY6bytisUoS7d6iSXRnAHD5Lt oG/wusYN5tWV+Z95gxkD8UHUH75RqFfJ1HC3Xs3XSoasn+V6Y+mVT/xaGrqDQEWEDUEQdoNRFE5n iDGCCbCpBKPGWW/CEawGNLDzHuB2gIXxnLsFJpgg3wExUPFb73/prufi4LLdCD68Dy6ApvIN8JaR FMivI2H83n87BsFkXirFNneiUa7R6aiVcDK4523ynrovZSNjfHiF0U7t3kv/HaBReFUx+sI6jfCh F4b9yMM9JZJQRlNfsJ2GDiUaAIhPW29K1RplMydI7HU1O4lJQae9uM6jYpqOKcVoTuptN+cALQ28 RrEoqGhivGVKLw3Oakul+PZbUoCWSAkqfWLd4q17i+T+1N7AsD9Nb6Ck2IrrPBydHhAhj2bjibyl /FVQmhmQWFhSWncI+8tDIC28x6IiaFWFBMIxxPU6GQsKRhvVggFbvGEng551A6O24EXzEODiToL2 h4NW44ggu9qbVtHpWy5W7PpW1H235XCe3h54cEWroOTFNiVHgKaomU2z7udiUAWtuxdM3vUgBLyc vsp9Peze2LlDMaBTD30uyahi6vVZtwlDDQVHS0y4F1m8mcbNuADCAVYo6xhPZcVkyczqlsi2fQtH AGEbQDow0oK76mnkFaSKUhRyZLTZKiVpDpcYWUoDA7u3/gBTITC+e48YZ5dp3rpDSDZ6/XACViSi DWM687BpXV5222gFhV2Wj0xEEGgvFUM1vJF1ArnXQ2Jb+ckFQksjaWRuTubZoIc9d5rh5b25X8PG EaA+tDxhf+5cGisU93hLP8Wpgm5eUXDB5Ib3E0nNkf+p7+R9gLwvVivgsshXziqZRabopBuaVhlG YmQuiOBTgAR6y5SJEinS5CiqQF5fctf0kQ28OGx+zHvHw250m/dOj5rnea/J2EnvL5rndBmLhqhq e5m3Fxvy/oKIL1VA16qvV6uI8zjryRn18I83Zt+Pmm3E0QEA0OZZp9W2KLRjCM7G3mm76bXnk8l4 OgMmo/upOxgSIC/IHKPZ8Aua/oGil6Qc5bkFTVm9AI8ygn7E6CPadg1FMt5j5I0l+/ebB8Z5cFhu 4gZ++9aTXcVuSmc+Y1bhRCO6ItldXglQ65Q2vVq7aTOWXogxTYnCvEdMzEp7AiNJFHfypQrsq51d uMmS+FAeMB1NPcBSYU+nhqCIb6iPfNUJqQex1OStIbr2yut8DEQKbLr2/JMHEDE4Wcea9oe+YVs5 t6dNPDofuVXB6b40OpALhIzd9Pr4k6mNXFFAAoyBHtPBeCtOnYvjQ/0GhkKSFRgfjB2yHd9934fh JHOJMhNQmotD843cc1CpUZlcxwXDqCaxkCEmzf/SPIjqaC7YuGdRnv/djOVBpZHhpcKvD3WRxqjH FNwP4CyVHPKGZSgbeqfN9iEpKzzfHmkYKOl0YI/wWmWYBGDxwEH3ocgAoBr8RZ2cXBMQP3dxSTOP 3wWNQ9lQu5mHVlflcbWkmWIaqEhoKFfvbmbPauaatDsTTVBHcoy0mOOyWoGcyT4WMlPyxDLMRv+v 4wO2Iv2v+Gg/5fulsvIQ+lMp3YGgRy0cb1pnsVNeERtma9K4JzkbKxe3PpM0dczgOsu39djlm1i/ 2Up83Pp19X61daS0CZSLF2itBDZOvl+pKyOnP319nh5IKhgjkYsWVWxRrlwGc76gzJnMWJXD8fHm EcT8Gt0YEuy2uS94aWgjrOQBAzpUOCrNQG9NCACQPtwxw/fFQ41zuYPGfL5fK2mrYUPjSzkoxhyY v0BbGsHhh4Oz97hdFh1wGL9Ihpt53P6DmXk0679SISux/I5hT83D0eLK6Cbn+wBHUfmL7KGP7z+2 V9kAiuAtIPQrl7k+sX+4eYiegNafPsVS+71WmqOPq3EXftHnpVcqVv86S+90JcqbgcFYscD1V919 fOv/vmuO+7r+gluRsj1Ol+EXyxVSEpZKu/Dlz19tDe27yQbkcC0cU5UYHjHFB8sie0aWlFwoFPhN 8RsuNCIWkGTe11iFaHfno/3YkN/NxyiiR9vms8TCXtp2mRDaDnqgomqZboyun6q0xcYsvV5fCDQN UVdipROKkjXKjDHT26vtBOcorLobAPMBVHulalmhUP15u8Ex19OVV3jdaz1+gbvXKxadWK7pCzXR +PXFvccvVIfE9wetVOcwrLpSdwRzAIJBqVYHk8jVYEr42qhAV2d0A46IGt1+dwJMD0tIuoOUDSeo IC8awY+U7TM4G98Lgo0V4MABggcunVk48sZgoXUVigN9EUQXXrKlX/BKYA99wcl4IIMIe4E+Vjdj D7mG2bYowriNlHm4qJRGq/ZiEdJQbNKdDiJRRn8A8bh1fA4uC2DyoBZ1cTrpRhFHDhngHKjrThxD 0Uo5iGhVZoGAMY5FAOZAwa/zgRgG9L0teIe3IThWp3aeb4Vpdve87NOrb5NFtrWnl4qRc5y8W153 8qgoYwbXmjoqJT6Bq8+chMexp08v6D3PB7slmD3omTGBlEp+ipDqI6eC9uqUdIudM2LCz1IWxaa6 BE5cMsPPqYRYRaIhmDwSLcr+jmL22G5E/DFsRnQAHo43in5VAJ5T8CCoKfLlp92eh7CLMp6pGD2K XzoZdmcAYhIRRl002fMu0HoGLRLYMCKahL3BtQxihaFgPQusTixFNAY4Cz9DFb2wj87vY683DLsY o8iTrZKQFLIpkastoiw2D8CbfNENHZMVrN/grl20Cq/8CWvO7ruVZq17fAh2L6/x1cTJySkjIReT U95R1/UrA089OtpVwbfiWql14FFkDAKE6uA2NtzFRBZJvMD4xUu1ftkm846ltjtdsSIQzWWWrGrb e4ckhuxxKbeJaCgxS4FFaWnv0anlxJsAkIKtFkoLnnUbY7WDiuLWrNcYHCyYFo42xY7EAwuZcT5T gaeU36ukEIKMno+4HEnqZmbn8mZ3YlI47jMyODJqoMKGgsmZ4qBEnwczsDiGRXD1RbGKAxmzWRJr CTEVO3ViazOXfW0mALlwiWZF5FLr+c+G5PL9HXTEFzsfvkiNj/uyb9qjkOsjE+uuoORmBGs9LLRO jloHp9vewbU6JaWJLbUkD8bkbB5uWk6uXwjadKPlOzlv+2DzLnGDYb1CCL2Hwb1YsnxjitbSYJU5 EGtM57edUK9CZg3glbKcXwIzdN8LpsP+tHsf3E+jGD7PYUD9Cv522bgkWENG6QHnVPX2tNVW4D1p ODyxWnIObI0FORR+RrYuwHoSCwlw0cWuxlDv4WbnoP19cHkmxItGq3V50WmK9koJwd8tkixb3vXV NaW+OTg4OrgQueiGOd0XkTevCeTBYDpAG9DxfPTFm4wZUutEXq+EiduViJCyzNW2dhkegScACPVt 9xN4aEwmggDNJ94vZCyJFLlhLtled9pftmzM+xBBpWxwqq3UTenKZ+J2STZaElmD272SWGXiuBKp ImWu+SIB0bVWKeRUMlvScTnJJBbIBVTyfbxGrPgVAN1SZk7STx8B0pImTPL3gKKeg89r6+D4uIl3 Yy3wHko8EWn47kz8ekHo6S39DHag04gTjSytCvO2ERJsSrfBZoasPIc/Dma3YkgFreKDLsrTLeL9 4OYWDXO7Q5oJsfy6M3YSAm7XQsZ4TDE4i+/CHjonoPOSePdZcAvi8A/FBhiMp0BpyUWIp37YjQDO jvJ+BpvbLyhk3IQzrBc9mxBDUCwgsc36QxZl4HmvO4K0TJQJdEoQeYmjjx2AFXg/iKgBgEbRHkM9 wDeI3ddjY15aSZVivg4WExUIEcgHHJH7Hl/J9sefBSvVHozkA2Rx5IDgSYO2yKL5lHeYTiW8Lp5Y OErITr2QAAVKJ1UvFneKVb9qQVmkoEglqTrm9ym/31iQfzGNtytKbV1jYevm/XDY/bJZLWZsa2pp j26rfyxKrzy6rVlKW6WtdrXe+p4SHsk+q0tarNNCDQ/xtwi2LFp5NSdlBMO8d5FxD+di73QePPny cWLVgpKxyVIahiZ1Ht7RmzQGGgpcVJ6DocfCX+RQnZHTCO6684vY7yyxXGWi6A5L9F5Hd1fwmKMx zh76CFAzYDB4sXj/W5yRR413l++Dc4B2hTcUtLsILxl485Go76pAGWt2XYDdFSNaxnHFF4bkk1jj oCOHcXJEnDAiXOYUwJxC6GIAdjHrv2xxgD9CI9+E4grfHVJJgY8GzUfBSbPdCc5/PAtAeNqyAsJc e+IEIO+q23E0E4fzzQiYOL7sgwESYuU8pJsRhABP66s7Lp8JrM6d1RE7k2DkvzAKeRLEnNT1YpV5 b0nvDyMSX4QQ5NoKiLHl0ZC84MA5H0Qng0MLHg+D9EKxsXg5aYHNIJEHGV4ysv6GZwU3S808GMGu FTwUBeTDdEQUOcicDF8iWqwCl+gYiZxIzwijFMb2lUhBUH96T21sgMB8RzEc7q6gtxIaMEONJnKg XZm3YcUv6XDkQpodGCvgNAST9wWJD4gEX/dh5FBNCLvoawhGLDPoyCYeBo2AMG+yD7kVA2mmpU8P hZX9EmeN88i8ZUDfSFboAb4oukqia6R4JNPgsbOfXgmlss8demar0PpjQHR/6PZmLP0LiW0cAVSp 4Gc/33ZJhaV1MluyGKuE7WT4ElKvIfCybD81VrbNGgE6JpddMq3d9DNqeWGdlnMuswNJXzZImUXB pRL/rgoutycai4/lUo3MpKslZ0Sn1aHmzRvgmAsG3jkvfv/ni6b2tfZqsmk8b2w4LlqHjkGQT9eC 9Iz7MSc0j0kzVFEfYcG3Dll5diSVCeXyLl09VctVpU147O3GSpcboJockRpSlAPFFD5JtIb4jYck f9dC5AymJp/OGJ98QciYFXSUmL6/qS2mNBiFazTe81D7xa7oLhbeo8sII1pGVzXAqhzU42LoqFmT 2y/RQJAXvj7gOzJCPQHweu6N0tBDhFR6yE7uoJ2MxqRsY8U/T2MV4TP9amVXYsdCFeVt7xhg7LiQ +3E/jFgkaXR7t/iAsaEjwd59FmzmCM7i7g1OM9YxJSi8PqMvSBgWcsynsuYTajMBokCryJ9Y4TVQ YkxzUvZuxfoFHchJxfvAX2l1iAeT7pfhuMvAHCDRGE3nOLle1XyYt3LNonB4zaXZ9ZZ1t7a9Axx1 MEVHP6FIzPbQrgoykycnOGDmnrB1fE39uMbx1V+shbEzNe3KJuuOk5fdeH9t77gUx2q82qY9lF1S xAVcKWJ4C7+6u5tXrjsO3tF76WGcPwDyFR0nRhnSynjRkg99wU6Q05jAg/6QR8H5MYUckv6Qi+Oc cp9+3laChRFbFXhf6oNfAvSznA9BOmSYsI0NwUZ6X6fHO9pfpX7Jkqp2iAfSQnNKwhMOLMwUgv2r rD9Ri7ETLC/SEx01O4elSXMpLo6CMDkFJ3toS9wT56ShWBQ+zNi2uDvb876eKNbe5u2h2C01jQX3 NL6C8NhaZNWBqpckhGTrzbiSBnDInUuuwOIn9IZDtaI0hQGivbNGJ2heBAcnzfdnJDktSPyhcXAE uGuQODg5+Lv4TmjHJMeDgLYkvPb5fJXA2hYSNh5kXvv7d5HeX/HA8J6MkH13FYAyd/opBLEx7+6m nSS9cyxuTmPiphkUlyaYFGLFYDKToXHvu5OAaCWkQuHfDPR6dyXITXfWlTFfLw6b6Mh93Do/PWr8 0DxUF3SVapFMr2uVqrqge1oUl6VAKtq8A2XyaVwlSXaeLa2MVFYeYNOzijLSS5pV4BGvYk8alZhR J1Eb5NIs0qM00A8otpWuzmQrn0RgyUUnj7L6ST1rwLyHlZIDM/Yk4XOI/ZyHLgZKN0jLYMfHE6lW 2xF/cRFoEQhKzKILTPLxli5QtcJWlMWjzBsqsqV5E9HnzTDUcBS9Fcm/XnIaMe2HXuqTZABnyJ0M Kx4/Nl7wnVKlXs7jGbizazg5QjxvGUrjtxdkqEsKySX0WmoGl1KGmOorR8rINVWC00UqQewmhOPy 66KfO77vsPN1EQWlxoBFWZAcvQzGKo3vpNGdNO29mvfharCADLUGx5KQ8hzlahpyQlJcXIVkmBcB dk8fA99wcRCRBiwpgX8dz29use5vLsbD4UtFAGzq9Il2NWUvxk1/fL7+ntIN49kY6IVqnN0Sh2aH iz0c38vgN5MBdp94X1H22cFFUzK6Op4Nxv8Tj4AYbXvNGepyDE0NhpnDyGs0QtMHEP8/4HXqFBPn 0T4LblMxwI6+pIQ1JDgVaYwMSCyifKSJ3BNqW9e7EWLRKDknBvVGIoUwlQUYF13JLbcEtrPZQ7LL hAWyt3yBYFpeH3vrrw8shxZJ1vURj16MD55oEmU04+QUohomuF1lEqGw9abQex3bAPDkkctfClQc y/Dw/Oy4+T5ol5rnAYyQZVasls6m+1gjYes1zSoegESX6rt4au3s+vLUQgabWa56sRSUKP5uLvaq LZrA0WT5hZNFKuDxcB7d82YirZgYI79GrDvp5XOYLBhH93LCUhJCXZO7mRlriTht5MNZ4El/s1iy wiGhkIk5v+4rV+3XkqoK1pHqhvLFCEMcPLikJoTXTTHOSqfXCk14NXM3C5kdb8PSFY4x/aXDGiZD BQvVkstqUBwsXX3SZzQWvd3jUQJtMKiQ6iWNSsZ5fOJ3OS7k78r0Sj42vtvd9DMDrF/qDTxDmBqQ MECWlC1PN674AmfYa8O3hF+TqpADUEceRh4BlN0vYnnNRwVNZrEUxDy27xuoD49oTe4RrUk0Rhkk M0kWlPwuQhsjqZDsSnOjybDL2M7DbjRDwkfFQxNuu32WLeC2Y8LGypGQlkmrCDwZH2zn7dNvUGsq 55rNmvGAmIakiaSy8JYH9/3qkofFAmS7qIktwrUsIlzke8uyk3jEVQ/t3EoZNqzYuZUa+J5R9E23 8QUgHzIJFvMqxJIFt0UFKSxJzZG0oTAe5Zl8ykvSdY0zHmuNEb/jZiUYeOfFLrsLSMAMVz9yx7lB w7aR1/KVHXzeu0XvoM/sqQXLkqI4YmhVpAKSUSHlKTsmqgFVLjFg6VlQ90BkePgUTchtrNaG3CJr U7tBW6mmx8l0vA5368h61PHvvwnr8XS8hpabaTh2irV8CcZjV3wpK22wViWaRS9QArssGBaWlLM5 Kilqb0rPOIrCejeLtpQhzatX3qbcyd95yYSUcuNKrJc7Vv3lUkvNWJoq7DdmLozt+cS3jnAkWNzF LMFdqOhPC3iMdDO/VMWaONa7I6NM8IacdgcMqat8FQHSSoUVGJtcRkeKE0nGwTymB30xQIBCHOkD uSMO688UFRtVZ1QgtABUakRMrpUuEW8rKTliuaP9vrT0Fe37Juzri8mz5iFL29i1UXfIHlB8LD+y 1VSI2fb1ms2uro7Gp7Q7hZ1wcBOz1bmJWXZu4vdxb1rGihQ24lZTwcykMHnzhw+UxZH+RiWWdymZ bEGHk6WGKxAikghqpQhAr0hQgaH5JS8WxI2U4tZlQRabnxJHMXNxFI/mXYAnmD2KGzD5ikeWxPEE BXexAl+x0ItllpGvSKZb1cjWWJ5Jk9nEabofy+Kn5TFsAjEPLtcMNrkpJrnJM5uYlptVmi7Sy2Zl anZON3uRde2N3bCfVbQIh6mtkAKHoeAA0Kh4mMGq+NUrOSowMA7+6qu3FoWRowMZczrjTTKX7KqZ w9M5uH2WHl9eiYDLHKA3oCoWDh/EvYrkLTjFEnR2rxMcnh81ZPhUX/C3cOmfKxUBH0whNonyLyd9 HUrFCKNKd+FcEc4Fxk/dFhPIKkTJi9ovr76AmVHuLV1qDsNRknhtSHoFfJgrfQYr4GAw/VVaAmMG N6/sfgO8svn0eiAosqgamOV9adieaRetuo02bpJtdDyGBt64W5fbyLRZFPec3DUuw/TM5smq02nM Pby7ccgPDlPvVGMM4qW+RjeRC8GUgy2GYYTBbeghHdYrhGL6RZPBKIC1u/mKVxn+kvrWemknX9uB jVAq5XdY44p55iNnrt/B2NBk9rvD7vQ+zu8fwENGhV9Ro+gAUElo74BdHXF8DkONpy4HPCQ2EolA xhpbwCy7KjAkCO6pNxyTQSF44eWlds0CV5VDMAAe+NP4jrH8wO6P8NKNQTPqg6KIXtFlDMswcZVl fxBNht0v8lYJGYsuYskQfgLUGkVzZbHmMAJHhjvNBHztgS480UDzGFN5jxtoGmJDjFpvoONDrIwf 5UAXEsIL1pxBfiHnsETOv7hSND0SC/uBSwcwsBEUVAcHAY5nBwYxgWDCUNE5rUtY5qGu4kPxo4Ve 6chmyLJfLYINJq5FRRL8PJ5KegpHBUbLnknsMgVBoXrYbrRaksGBcFmgmofnPAcfQQGC7oMkZYNz jnhLIemNNbaNT1ib2RyJzSNvKSIIKiqGD+uwIEyk3XCLwjemiwsRjEM0nk97oe3oLwYG2h+0zy9b h43g4OzvPBppFnBHEjxFwmYlbeFcWa0+fPWV8sWi60F03sAx4tvBnHs6poIDoCCwxnzAIXdOEFtf JjhkMWQXuMq+CukCBbZXH+yA855CvsYhJznvAK61BXGCM1IQMR3MEELDRzOvMZ2CQiS6DeEumi+L dPgCxhXB9T3uCWaEw3FKVBgdbrP3pTckk6++ipMyu+VAgA7EL1g6CpUEft904Xaefb/VgqD8gmaj 2cDfFC7Oi8Vh23rOTeYOvSATmUvICOBw9A5jOJCFEZCKbi8NgcF0W94QydC5QkJ1YLS4Bhs7coO6 vQVQHVRGlqqybHQMykd7ce21hfsxg+1SNAHLJWaI7kNpNuGyTzExZuK2LGxcs6EODdOqRbtjQ9TW QFChoHffV5fyogHwPOJwrhws1ozZKmHzRGP3nqKxZGvvamqCSzmWLAXZ3bjb+SNqWlAfCZSeKzg4 Omp5ECNY6VikBYnsF531UwbrY6bHMOrnGHm4pfsugEUG3sN2AF+jVc6M7EccmG33Qp55KchPxwfN k8tWw3IbSDPyWmtsXKMi7bxWGpwFw2LYjS0dHcFJgVYNWn88nh7e9w+lrUgMqE6mSqzfp0Wr02CC PBV5w8XdxLIDwY01Np3WZYM1ZkxjpV4GGQ8YchVGunUE7neJx3Z0aZndlfL8+Ljd6GwW6QxND1ML gjKOE0ehTnF3c6VlF4GvCA5IuwJ8pYh+agfgZ+Nj4/Cy0zx7r3RCNKDa1jt29YVS7m6xiECvJb9Y i1uJW5iNfx1yiq9JSCgQHxZpCCZvdaK5mACOqQqjBtvKHC08wDZPGrAIzmrKN0GTqahK8GDg/tQF o5eLw6bC5aMY3dEErE80UehKRz9ZH4tDaP031Z09xFLMQrZdVG8h6G2CoGXua1o3ucQVOru4m8qu NtlZQrLFjkl7RPJKVqvjKSkU7ZUSOneV/FJVWuDJzd3+MWg1BIEAOObUm4HoMzVMgz8dMBCTkNZu wrzmbpt8jYFCdx9UXOp8yPNhrm9K1i+EcM5g9CWUEZk3jeG3LIQGn+fO2kLbXEJ7jIZd3b4EdoLQ 5Ci1K6QpbBscVqg3uDaqt7iEcBQhBqt4+1mfoC/lwL3UUQx4QupovV7yIcxATQE//Q0iMZNGK5Jm raLe6IvIeo86Ej68Mfzsw2Q46A3A+x4Bo6gIibFPzeDzVKJfxkLQXs2VkexcyCkMNsiWx/+HxE7t Ddn8pntPOHI3g0+ITueVqsX7yEMYIZyA2/FE2QsrEWVhCQiHuKAEbJFeEgAKwGOqr8JAHQN20+j+ CgtAiH3yTqyQHR2woLl9Bm/c/PB/vTdeBXn8ewJLEu3lmzG0GEViolYcwW4REWGD7sFoMBt0h4N/ dKdguU1yN7hLMSHiJsGGZUcp5dkS4MrFsxhpAxQViKwiMW/E37Fr7Y+NQrFY2uNdBIsb1TOo7RJE 9dNg9sU7aRzhEQh0e4BX1dS/aH4lCBr5r0xQ4hdPaBGzukkSJojAuwv7oFrPl32pqkYtlEgVMHpf gBjpwGKdtBt/qZPdONhhMqLP3ckE9duwUPlAkg9ZsAzl7kP6tY6oRHliLV1VPkptn6N5vbFYYwjz kYhi/Q38FMRTcPnfyBbTTDuPdXz0aFlm1V6ktx+LW9IH5YMdn+bkOZ3FA+6JsLH5xqYtug9+5KgC gl7AgMBlJ40pgaNrfw5BIiUkOBKt5jEv8WNxzBbQ7MCKbWBZTK5dl7aThApdVbFhJDtmeEHwrvk+ aJwdNQ/OsJ8dvRFADxZed+fDGc09nOFX4pznJgGkeXeGMA3Wc+xmX+ww0XqEd4TznhiHL+jlkuzv mpWyYk2/XVyrtAlVyIHXsY+J9ccrDxFHLKC/zfaPBxdgEok4I2KYg1Zw3EBolg3P8a4N74gG71YB uqJUKvraYdDOAlrwNhbnet5upNuUxNurXRiadDCKPamxOYF3uRqQ58599y5E7SUSCESmYXgLGs68 tP9FcE8CXRXPRXmhFYEWbdgG2hPL+9wdzZhwJKd87VZRdm7ays2i3PHG/ckro1Qs+bQyIAQWe6Rk nGU2zEISRTC9yAxdJwkHsLig/oaDz6BOXe9abBegEtLbI40qrVk8ZZaVJElRivobHJT68gAIrq9i VyRfvfWKD0W/VK5Uazv13YN3h0eNY8as8ziMV7KF6IgHJ1QeeXxWy43omrIf3t2NkXGkSYEouyDM laroActQM/JIjBhOBhBwh4Ll7gHrNB3xDak36U5nirEgsoSxH7zX635wsJZxY6t43Dr0ABDHKcYs xABUNgtbn+iG9gZudvUoDEageRyNt28l+thgmI5rBCd8QRxwgIyIf0Qfpl+o4fawMd+W0VM0YZ78 wuH2z6Lr4nrRbve+OwAqQmulS2VdGzyRgpAwsQMQHScKp6SguNf2uGyd7NFEURvHOhLMiCmXQnYy 1xBCDVmmBIa3ZtJdc41Zy7lnLcGXwbCluGoyc8bcWjQhzA+A7how/E2pWCN38lJpp5gv+ZYPT6rH DJK3UzgRUPj/Mp6T+TMKSiAMGVwDxAT6QtD+Z+BhGmnJMOzbBG31EilfslxFy+jqVPDC04GgWqIg 6VmJwhbYfdONFgmwbz28+z46//FM8ZlNVSrOO1xFN9+cG0oQlLWBEEL9CMU32UJySAphfeIvLCKn iiCAPqOMBRfNGCtJCdq4C2ChhE7wSkYx0XAqR40f1G09dJXiOjCjGytWLHtRWV7rHprtljqP1smI Jg3oUAIKfIj6EIKF2/RX8OyYEfcvfuVpkQ8iwVy0D4L2h2brb6QrIMweOZ1sxyCNIkvF+g6CDZbK oC4vK5gEQ3ygoCSzSLkwIsSV7NOiBCwWg0R0L1bkoCfWkeWyq6dcChyaIG17xxyNmsHRxcYC2LYp CWeCvPmQWkEnEP0yirPQ2vyiXwPvSLxqqmM1CJqRxuCt2yIqhNu1bpvkrowZrcNsptqs24AnOLe+ NHgt+zUD7iq51jcM1XLE0E4baGUK6wwT4xKjqSvwSwMlZsKWnQkoGFmYE5woBj57fM47VhQLBB5G cO9r1OB+3d9D+8eB3Kzd2fheUGtgvTZfSRSU+XUUDMNrsEzd2rJ2LEdegPv4oZCtYtFS5AJYmsrb 4HeoaqOK4QlvPn6Z9+JoJdaS51qMoIm0SpQpACsmIGaQopk6QM9kS9HLFUvK6ZIk7VxCNtuQFpYt lKAJZnz5yEG5GwyHelDonWNlLVpY7nWVtqzcNJrWfqmer/iw9iulfNWO2FZcrCF8E9lcqbQyJR7u D2FCnTyooUrsDUE8LNCfbCxovBeLOE5mNBFddzGjCSoLlHvno/5YYv2yH5uQWynQYddUvyf5V5CG 56LS2TeRN48oXtg0FBM9RSc8Kk1eqGGPFc6Jd3A/BtrLxhMoL9mWo8wJQ1fo3i23WtsWNy2X3rTV W0baUMYm1exzzJ/OPpKkSRkfOLFIAr8Lq72c08aRWIvVfpzyM805jZzQlNVFbsMizxj5MeL7Em04 j3xVNJUm8Dn9DmgXXOEwqSMr+TwVs6VhShJ2iET/+zq8M8yCmDj2qUrQfQVZPeEQAZaJfqJ9K5Sd 29AI1xPVsqZ1nSBPQbg/nY9GYnHl0VzGw3tC4PZo31DEKCD9bE0YY6fWKVRaHsaL1govspOxuIBN efDAUcQBmeQBl/kezDTdtS7C/KLkKBYcdziM5KyUiDml7Ce12KxNEtS8AIOAcUJwU/N6FgtVcPOU IPXwZAPD4+EcAEXA8Zb70cdRN4Qn2eJARo322STHyYwBH3DI8Q+ZxGFAXCwVxadcgqXMydjUhIgH TQpUc8hS0jaLfMSYeRvi4PlnqjlSIkIXA3SmBIVltWXKDeOWEpv8eilfrgn2ouIX82VmL37zeF36 +k7WZH2I/1swvYUFvBFmViFkxA5nJgn3D8bhBXaVnOSjCA4YVWAnzlCtURKvvFmcCTP6tAyLUjco weGtVEYuhR+0b4ZxrfIS98CgDgO+H6m1Fd3OZxw8iyiiJq4wAXz7nkbj12AmAVCnQHzVGB1f2HGe sYCkuCnmA/zkt5+AA33lWWE/FdZCp7FHQc+43B7cKZBXARo93QmWDI0w4BcuBPL4Uw5WaF5CpbFR zHzS7c/cAIIx1vUBXBgK0M04ZxljW2G89lYYr0XMbvye21ukX3U0zWB6AQwOaQ+j5UlEpnAKrQLl zmzcE/J6V2wdMYTXYRc0vCiLdYi3y3tAJgXr5x22z/Ne+40gsyft820JZ5BhejLMTs41O5mYw9iy SfJ3MIUJkE7EDV6H5ysgd4YYr7OHPjh5KrQA+oJPBnkaAoQ48PlHgK6yOSxgURaVmDAPsC7wz2Sg 6CTfaEMfTOgn+LMH4RDxruhNAG6prCAulfw8HggVCa7zBAGxHsENP0J9xP2pU3+qNRVaVzMInY8G e9Ac0a4Q63sqGCYhNSS1BKZX6hIGmriUTeKiaeoYogwZ6S3vX//yNr+Kaazv6F2Ck7EUGmr17kFb /4ZbiotO5WScgZfA8WOV8yK3YRwXOca9pS3NEgpcFICKFIMqQevIhRB5DzyQR+PPbByGltOU+dUr QJMQ+2isOJNSuQb3E2Lidkom7i3KNwQvvCn2y9YSSAIs/2flvIxZ/cV5lat0Ii/va6cvOXu7L4mi RkV6uRQ/cxxi3trrdTC3wQRhvT7mkpHR8OJEeaNT+p+4jQ4HdLkg3APlbrztFY+L6ABNhV+KlC/V rePNGFXP4Zex4KJf3oTGK6VgpBhrJgADbrNNQIFA/Czva01Gt0BqgAXB+21hAXJanIXwoC9SRJIH nDhaYePmAcEVkc87H4+ibYV+nyZyp8ZNW43dM7evR8Er2BLprNFpHgfHQad9DhRXHJ+I4hBEtzBR WJ8oMBoHAIctL2BEMr1f67sAflqqlsoSlC0eAvBfbxHO4v1B5wNYYpwfNYKTg3aHFg2fQo4lg+eV uX1gnymjj5SdFkxuv6jdhm4jm1ZEOTCp4d1MOw+3niw1w5oX5SvMhZitCHcFsGOOToILWqJ8eKh2 i5MHOwYjEMCwnF2ebvLhv0Vxp/D9cbMlEgDCibRWKYP9UhWGGmyq6/YZndaUk4EdbZAoIcFqcNyQ NbZqYUlsO4u6yIgWKCZdhFOwJRPyN9gTo2n6TOwIlPqltwKZQkcLnDRvwlE47Q7BT1xLxjlNQwmS Q+7c9fqYW7GPXJsyMF6Xki0jWeRXlWRlyEfqpaIvcLjAwUtk52IumIbiw9cP3vtwtgdfkGPAPMhP YtmKeclG9eLMCjeF+ZAVm0KZ4vztEvKo7kvK/i4pNKrVar68s959iSCkJLGJLzGHCiXOBoP+nli9 OLlJsxhtE2MakFDmyUww6lHCmEabB5CPgtR1inXdu0vcnAwiML6Gu3UJ/2BbUUs5clFXlKS5Vl8o 92QWrNWbhMG2W4ZN7SDe2nCEKxvcTxCIaDxSt55GUPBRny2JKNkw/AQSKQ9qOMVxY8afomN1UUgf jwSZ6X3x7kXBaJaO9x/Qsq4VC07hI3+Seh/p6jOYMvI7WcGRwRrKwF0wZCfcM2mbz0bvoHAbgSU3 m+GWql/LERhPBzcDgBTUcPJTXalWNqX7my10N1tjItxTwHeAWSciMQWUf+V5SJkB1vNknodFU8Co LJnngWy7mq2/BR8Ozo5OGkd7BuwBzA7cT12j+hRu8qTbvPTz4RHxjHIAvMZdiIXeAooT1HOP51Oe MNKDFHQMAOAaIXswU6RlE9GXQWuLNOE10QilF+FN772Gf9eDYKES93+fK7QC+g/wKkRAFsko3Hej O749E4zvyBkcQWFPo3dtTsX9tct8DALkY5Qai6/3CuS12KT9+IU9QwCr6BqFj/gWxATG9al15bV2 IejLlsC33fYOoZDIQRF64/kQDHn3Kau/DcpzFSWDXNy80jboEzT2Ap331d18DWy3q7u1fJVsg6Ru gSZLWyR3bhOATmMFfCT22sdw1OUICwvvKLUYJXciS1Oo/YAVZvUuaQkTW42pLO093ccVtGH8cexj Gsa7ciaA2rArbmhRujpFCCI7JkBHG+YoxQ1vhFfe+8YZxn4QMgzHhWDONAZcyyYwCWzaieLfFrSg O2JYhWT9m9AAIWWft7AZW1tQdxJ3iqt3wUrxpUtqrJSU/rbM/vJtnArsoS5fxSEyYXUfBXN3xu6I JsnAGiqiO4TXjgX/pTiM3o9I+cGKFlmrUXfiRbdjpernBWGseULbe206GeADXPKrLstcrDc6UIiz OzndnWQwY/EmCBKjp7Ufv9EaIa+aBQullWmptmJLdepcqomgDGqpWm4fbBmgbvuAmI04rIbNX0Ak VzE/Q74CFu2S5uuSpZCsAx7ZNolUKG8Y2zVP99JyoPgae0h8ChZll65MPxmkDaiCL7r+Txl8AWhF 0txh9U5RdnflWbpF+Rd0Lq1fDOaUeqqvGAIb4U4erlDdJbIstdPcl5kEMxvCia6udQN8gntCFshR ASTV2OQ8b72LgzNYlIBr/xVYdpxAiMuz4LLdUPSDcVjoqE83eRQz9+7Iux3M4lhkaZmwamo9B+PM LYqxmlp+aq5kBRL2dpNgUBKRfzF6Aioa2N5Wwqak9ZojkRLS+ksV4yFhJuzMD6pZIUwYOGwKRcYk jEyXGfF30aG9sZiLoDiCgGwdXA1mm0VNIW2zW4wbiJk5AVceNxHirhmcCcsa9ALNlO36kIGqlEv5 Eihua9Wycgjh85hCzQLaK3kzKpMhRaAtsyFNFhGMeITniOQPDaQVNkVZxCG5Bn4xn7OEY3MOywrG s2u7dMUyzgGiGdxjlTSEExgt8Le/4UmGkKyI8MxyrmqDwnnWZXi/g9vWPFvd0pRT+em/4OhM8r0J n5XAIQCH6vT7/TUGU976J6RQTvraHuP1PasqtTJGDSjVdnZgR+FGepyUZ0BxM5ZmTIPdhtfNESj4 Z4hXNfqCeITX0/to3ypimqEIhLzqCynOkV/5vSzL/2nYD+570YzLyGXpBr5GSdrZj1yWfphlxDuS y9KRRAGxnnh2K4bh6GZ2qxoDGDLis3BogJqrFiVSJ+o3kht2WkTbMPHWk5KwVApGykIHCIgeyoJl aQSMln4Hl2RgjkNU/w0bA2yvQqAyu5V2pa+v2RxS6N0AYBWBL0sj+btwOhJ8F5UFlkpoSp9ouSB5 92CndCUd5fuyExJ+CzGxsIIXRlg7dm9/QyA+E8H7DqLeHO61wK9sW/QnBjHSDwefRLfhtjbvfQ6l o6oYmPvBiHCjksMaaxrH64vXRmUNJAqSssgIZ710amtjd5nozA53uIV0c6CCYQMbQAFUkGhWizUE 7Nop6SiibnxAhveD56eHAOKFfyAFvSH+ZxXYPxCglc22xGOU6iX289xw4C9K+dANuqhsOJFc3Acw OMH1ECi8vy8fi/VBQxdMxkDJUnslh8nfpWEqV7INU6KSf4PhKaYOT1EOQ71Ew7C7owO/Ze/TCw6T gd0CIpXWK5RK3F2TYcJlCmcPl8kp3kEf9/2qIsqp3G2R9mLb4rGpFWmJQFTV57GJjY3YPgglUTdQ 6BbHUF+P/x+Fn4VI0hPpu968d9udxvOJBHDqK+qtLpuILkuoFuc5nIIm9WS+eYuuAzHgah+4dxnc +gZuNKBLHylOLKpmyG2aQr6KlLNb6DAVcyp6fUC9dvISvCbF0F1Q4ZFZujlmq4k2lBjy7j1mUpKW 12sMDDue2cNjj0xi7teaduXQl5z8DH5v5nykBgWf18FXXaTIIBrVqlWiTbVdSZsWnl7FdJwl92GV 5axaRreyUK00mmWt4HQHY2bhGf+NlMk0QEJ2RFSOupAd2aRLptbowCa5SvXO+P3hADmOyPU4SRa1 kI+rG689Q7QCuRHrfwSMdzi7nY2FNEzMMRWGqB9QIoCLgdMpPnaQQNO+3xBJsJVccBAR7HAb2PH+ AFSJ4HiFVej2sILkqZDbZRscsIT/A/1K0KnVBwrKSo4T1Owi2dqB14sWDgRQrE+DvhaK5hEMwUhe I1i2S2+wFU9UOhRlGRMlJZDYdFtyiKJW5rynUasXMoytVAPJTGKfe69hRJGK0V7cZbzt3WIlvhfj FmT/CbuQurbiRgQp0LX/hsGNRP3GPBTpZhL2Btc4Z7rkdTag3U+2hvHSQybg3ksyCdnHhxapHKPM +6/F2k3V+zDWe/EGoI8mIQA99+fimHlAUXwbIZapbnNTPGFRbOVEG0wua2ufJfgBuVluFuywxRtr MXsAwj/tuHLt/287jvVV1qJyn2s3/eknrl0uCs78ZPtrSWiS322bSQgKnnPnmMQ3mrk5jHFwbw/C jhJp0A04uT28BJXzFJUrLNziT1G1W70Wn/eFZ9tG4mSTqyV2uu1U6uBNJfaaYKpLjHVJSucR34i8 RS84xDwNThpnf7ENiIaHj9mA1xjAxpZA1Vhz6f35PYGZgCJ5MA01tv7Ha5DpCFJQWh/oMEB/QBSg /8EmPmaz4QCQbll0U/ofK4NtPc6Eyw5OzmiyAfPehXkfhTMaAeqEvOE1okaIZkDZ0pE6jYFwb62j +OArv1Y1Cw/HKFrDdbFCd0TWkjtLNiuMuDMNuwb3igNIPdt7VMcSJuz85LGtp2K4C9T4lNMbaUWc L3YQEFgxyznjBAXRJr7SDJhw+jUt2anzub2rAxH/lo1cgK87qMlY5cL7ZLXdE9/F4JIlmgnoBBAP z4yK0oXAJWISRniDLWPJnTSO1D0UtGfvke2RlyzJW+3Ebs5r0aiLQdPn5dI6m0XiXHVFqQjrhN70 i7uP5rp6CACeWYUZNd/Ji2uItWfdZRmInHDvNvoE9lhKXMBdRU0AfApGoPPflDBsoyi0L6PCi4bh LoAIfndgBCKeUdmUzti2lq/Iup3GkmI9X7PTWJTR87U7TevP0XXY1slNTWs8ZiEEi9fBZ0vY/i1M wMx23S+ivU+5WKrmy8wA3I/7FEOSLWf4V977RUj24NWR8xA9qBS/cv6zuQExLMt4AembQhPlPBmp LC0sOfnvQR8aIA7DsScmIRr0cOUNDBv5kQaoklEVnpAHX8KC95fyBFkGAsqyhEZr311GdKtt9t90 EoBl7RgA2BonIL/CliOXFRRnKSYf7igWYWKKomsZa9BuOpVKACOq7Nuu1NdfTvgLoWCOuTYoFQi+ 9wG3oaNcdPoZM9o94qCCOw1g5pHgH3nziUtWYMFw5uWVXZONYJNCu1cfzrSh1J5WS8czPpQGls76 Y8l7cfXBJCpqjpypi4gLRwmNBO7J9CuKckmTxsJGDE0vtxEL2ozo0DcTAP6bTYeBePM7uScRjh/G DmJEkQxhhHIbyfYljPTxpXbyJutaKv2VB94jW963gNu/s5UBaswsKBbmMB6QVqEA1Kt0kVEuArx4 ie+hE1B0pwcfg/bhh8bR5Ukj6DRPG+eXZMDRD4cczDj6MurZpxFeU9M9zeFB66gd/NjsfAiODy5P On+nINbNs6Pm4UHnvNWmTssbab5JSg6gtim1R07kWXm0JRzKX1RxFU4ySM3gRbFAdExVTYUzzBsQ V39BvmIo5NC/ZLKLZIGsP3vhRFPyP+IWJpxkkJmXd3+RFgqKNLue1mmv1510rwZDCCxmOlSvr4R6 gppdvKZzepepoVySJOZmH8hwssWkok5a3zLAe0utbwjWP/PZeBTepIRBS9lHf9A2eppd5BbzEEI4 xkC0+SB07rtCZO87zzQ3dC6Hp91vGS5gnmbbOW9ZmjNAlENYuEgZW4L5Iw1Ayn7A93I7MPQdzXoc 2+Dx5dOEcR3x4pO3ndb8F83ZT72RiTLvzGwbUx7ju34J0EDF3ixX8pXiX/pGBtBJCh7Dr3SluS9W A7tC2scCDzALR2kqloKJFShhWlnbhug0ynetEYJxLXCzzKVez82DERIHIaUp4K/Iq4jVDDoI0X1s E5Zl6Cup8X/45oSR28s+cpiH9WTNGSqtBC8Hk682L1hRc5hQTIgjRwFODeXmBleJUWfHUwlUkTzf fgQBB8twjmBM6ys7otxLjPWDhWh8zScpWM42l+spmRRLBy/Fz+yw2CcByIwn1GhctM5PvU8DEpA4 FC3K+dDgDa9ZOoSwtQo7wvzpsNVOrl/3pe5/k0UYXfEcNX4ImkcbG9UXBT78QWSCBtMiN+I+5j3C EL3eepEzpDFjtbsSkwz22pLCWCgTx3vBz3vhwwCd0aVMNlBh5guIvQTJ7TR2cMhHQktKAUgMb3B4 ftZpnZ/wqGwaIwR4XGYKsFnbROCjf7Epm/n23d87DZCMNosP5XjOVuPgyJkJJal256DVMfz9bdO3 QalniRvti8Zh8wDKfB/82Gp2Gunp897JMVv5MrSzGtNvveoiYdCulAXBRMMbZ0dUuXJT5Sk2U75v dIKjg84BpyQPyNdZE9KiIBvxjSvRxjvlGJ4dFp0Ot0o9X6rA4bZTzZf42mJDDgigInDEFXnikfY0 J3+i9+2/+xEoL2A6MhHqy5XNq5UUlknBO1MgN4pizqzMFIJQauTNYuiay7iuwfWtT0mViwHf6NKN YYGsSH5QGZI9fef6ZLrVxaflWselOi+XDDOlhXHee4JxRrFRsyrbAJKIcCrlrTT2x9ZX5u3jxHE8 YxUHq0+bvvCktsm2qtNv6UFXXNLON+osQ98vaFn6YaZ1hPQIsBcBPzBewtIjLlaEcnoyj668cbBZ hxhRpR3w28iVS8WStJH+XQ8nhpk037Ul3cXj+t/4mKIB3fXz5V0YUfD+2LVkGIuEE3098G7D4cS8 QZRi32D0KZwSD0vcoppx73oQDkk5g8+FzAp/2StQgnPNI62GbwEzyBKErAjzg2q+P4gmw67gE+fT yTgKFVgHVCcasan12YV/YlwVg2Xjw7HAhu40g3gUz+teD3TXeIgV5EFKoAvffuvVt7yc1yPAAuzT d9+99er4E+rEgvYJBUCfiARA8RtFc/hLHIHqLIm7iAMbT/gaWu9gWiWzKJyXVRiw/F0UEpieJaxi cUQBrEJUirVIXwsidA7CzOQ4jQYDvch2cdRCqVIJqFKMkp73vL7EUWHJL3Q9RI/Ie5k70obcWF6k SoTGzGzrGLDvxhXCtinfyAH4BuQNKWcpjWQUyjlAd9ip2Mysz9lKNb/iWVSCs5bBXT18Wh4gAwfA zUtotFZYZFhQpjWm+QdcZHsrLrIkwuZaq4ZdlpJLZ9VVY5k12Usn86rROm+LJcCN47w3TJow80G+ UFUWU5LxrL+mv+z5JDugdGblYrkG9hTivKlUlGHFBmUqfEdo6CiRkugftC8ODhvgOc8pJAS754Aq MkqBB7m3XoWpO4tPhswOvIldpiDwAyLw8miAW0C+G2OELCXFQ/ZNR35xXuNZIP03Xa5QeLqJncfK DdMP0wqeiXd2LL4V8ETH60/jvMnpp82zH+RTkUFs797ky+am2hfcNkyd9yoqutVfVFv5H3BOJWQF ms+EL+mi6DlagS3HYzZF9NgxMdx6TNQYSPlBSg5PL//9NQn//mMJP8lYnczjqw+DvNTd8lmABanr GVlEtnA87nWyzMAjykCvNxbTa0oTI9pEsetlErl2NfgEBXzDPJIAEefsSfppipRuYgmiVd5jilTc MgitJUxmzuwmt/LC9WWj86FzLmQzFK74dPEa0ynEuxsBwqmkv44yaBx2d9AnoFwuVpVPwF+UfrLa SsWIQo2IwT/A7RwEjRd1h11RCbdhFkYIxtsXhdHOpOI2sIEUEisbvYvbQEjz7gCrkIwrcDWsFcHN Cbu9B2BkXn8MAVOf2gF1sXEgK6EeO2hYGG98OWZpDnBw7yPHIHUIOmzkBvZmZftlnpdVqForbfAF hZKG+YA9SQb241HEejGYo4ECGHqKhuDQProdi31bE4ora211xERYuqe5SFKr4E9SCNg6q+TCXJwb acyj7Nls0zqkKn51N18HU7ByrZ7f9Z+pyipUhY4FSVNENyjOJzWs0aAbaDqqIfSntFRg+Il7QKb6 42yPYfT2Hj12yiF8MWn5wRoIPOsWDoRgUYDdMpSY6kpYYiBDxU9RLF0Im6Wut+1p8tfa9Ma6Wbrl CfkXWDGlnQ7kVZf5Rl7D6veM1Q0t9H5EwkrBrbozqWsqasyNr+IMUxH/X97aYmPOrxJckU4h2BZu hu+qVldYuTaqTNT4UDmGMh+KfqlcqdZ2zOqTtbtTW00pKODawC2Bi0KugXsDQZsrikvZXM8rWYir u5SPK/nqrdEo99josMK8iDHjzdgDsHgDWtU1OBJTHroLc54+MHbK5LS0wl/n8CuxKh52eosWxkNx 53D54rBSLVkgsiVWG657i5bKzvHhCkvFmXrVpSIKWbZUsJ4/f6lwdzMsFWfKDITjob6QdjwU6xno h5VqyRJJtuB6ySI9zrRIjzMv0mQL/OLiQRDvMzTBTLViEyrh4jGoNLKMgZkq0QBp+QFP959Zw/Tw 1yC+xO65bWbxCmL7MasILol3fBd/Gt6/g9jN+Irb1etO+97vYGn4OzOHXkbukDxDM4zBNgTPAFWW ENfGc3l9VQLvy4hcqGSUGtwloqsq8AwER0BHpgjhxkDDIt9RKWDWjMwjuECFg3Ef0FyhOxA1e0pj oHpJSnJm19dvPuR+dOuhkPUbv5jZdS1jN/sLy3kt5lftgwzS7rzuQXJpUsaWG3EzDRRkS7UKqccq O7W4euyvZwv2p9OrGHUqgLufpE4oxcoocQRpBOZ6shHQHy237v8xtOnxQ5WZNhm4aUtGApRRsGFM zH26VJWgFny1ijep35hQkMMv2uv2CapDl/nlta0n6UJL1trqalH9UYotSQvqBJ9Trhb9Z1X5qqry YX/aVUotwWkOwRKdDhLgPumc4O61hv1W997r3Q4mZnQQRR2eYgizqM3XHEAswRrFhQRCw9kPAAdD bUxrkOjsDQHimGq3dNtURpZBzGRbmaqTxklcTyOt5/8P3rZlv5b3wTajWi7CF44S6DQlvO/Jht5P CTadkv3rrXd6GLROjloHp8HfLhuXjaDd/L+NQLTl3Ukj1RwyXtxyg0grR967lCaRjmacttp/XP1s kinqYF+3b71SzCaz+FDlT1d8iuJzeXIi52AXLxdzZUAqL/217wPgKpmolJGzqxC0JMKwAt7Tl/+4 R9nyk+mmCs5qGA38eSQ6G5x0mrxp387zGHFLIq/mzRAPVnRUha3ABt+G3eEMm4/Cyx9ru8Fzufe4 ucx5yrwxPpWWpf8fe1ooBs+cAzwhNr2KOj2gfyXwQRM/tqzZMdaNniMlZFLPFr1MiRoSt+tI+pTj IbDcYTVm2oGD9Zpn1EyXOEKQ5FRKFQChECSnvKvRKAwTDwV3Hn0Wq18HA2VTj+QlLBxXaAf3U/Fn VH0l03HX7IRQGTe78B0EeImAkDc6H4JOo90Jjk8CAAXHoGTo0EQFIt4qRZ3M1lR9Nuv6y4mGGsdw LNkf00zjfkvX78ebaV5lxZKt0kyzYqVZ0OVV4tVqJUIs0YpjAwVCgHBySJMLsopBOsq1HSNIB1eh PEPY+Uw3SUlJukWleLO1QBRLtGKzecka9/iVnSq1ebfIbVYRfaT2JAUjp7ABEbCaHCAbxgHDWzHQ jRH8altFykL+JGMmHTCL2j67nxCC6U+DXA56oDJzVDEZx2tpQrQTGwtSPIt4EOBqpyYGYadeAtAK k3fZtNBSJUBaLmHKNp7gvpg9BL1onmrRZoAW5WRUAv4pJgfG9jrswumE03jW6DSPg+OgeREcti9P YfSQtiXSvnrr/W8ysfZphEtegK/RJDtGeceTCNoKTLf56C0uhm0MnxfOZoPRDTxLoEYDqd6OFiSK MBENNQX5KdeLdblHsPwpDVyieP1K1ZKSNIolvdHTIZIa82S8gHCf21FawshMmIsnXDD9qv7oJll1 dKPH6yZZIb7maNVyTjvtcx693Z18GVZqvVTOl83xU6PAIL8q7qH1Qqze/exRccDQFNcus1YSle96 ii8PRl7z/LBzouGRDYYO+SOwq2CjWIuxYw5dfLoecaXhrAvgiIo5k95Zk24UWajLMhKMwQZ7gEYO DZIStszch+CVo5v5ILoVPN7scxhyJDYV0IDZwwibq1sl7UFE5ZobpL5KlkwC6Wa74HmyKD4xVn0g yNhQ9L0Ri8+H7cV3kn3FcDqJ+aSXMKF7j5pPLOexc8lusveAdfjouSSD7EzzmCn8INgOSrAXGGFl +t2lgFYY0GwiZuv04NAILQhYosphV+pho/F96B29e6+bLOdsPhsAXLoEo3Ix4IfkCc+wqDxh1DBB w8feeMICfCQhSYW8IdZXF6QTuPdhnx/ZMSnDnF8AvoUQIC8uzludxpF0xE442+CaWxYoQCyp8Ffv 9fRXdpu977PeR3mJnF+I6qC2rGEumSj1XSSJQnPN5mBNd0shn047lx6G95ZjSxkTW6h32x3dhJzZ DCwJ12r4bkFRWDdvrnjD+KVs2V6GlmEOy6vrwBXyMnPL3oXieUiJJRI4ZDFkcOnXHs3Gk4nEanFR tScia9SwxNXhGiVhQzPHOVt3JONjyKVlHEl75+illrp9IC2vmOWhNcq1CjHv9R3lVa432EWjdarA Lt68hpBJ1hJUvvoXfz850jjmxp0RNH9j3Zxa/8r9MYN+vWt2pFqylPf8ypYdAey++xBMvgz7EIYX 5UvqbbVC6JOILbe7UMW4iLMJuhiILgYGHtdJwVLr33cpGhnSfHFqpR/6zjC6HFBdVPZuPJuN78Up MryWFTbbLSNMLjYqgVCesVGLTrABqadkU3h1X7nbI7PwbYPYbA+zcISxLXQqrayTyJ9KpyUfTNmF aTqX5x8E4KXryTECJuH3w4tLKGY4/rztHQyH8AU0hkKwnn3BFkdmteI0p7LgSJ9HtxRjfmx2b9s7 Fh0cATST0WfJRiBMk4LQmIbiuB4BP4F3KQ/svRpJy2D1RMwCjex4GqWfy0vC6XJb4tDeOPEqyp6b KsCdiOPNlsotqUG9ki/7Yn8wvhsrIFLD2p3PUV25aijO+/B+LAgojBL1iVxAARaIdyNB+hgwPqyU 89iI0Xv7FtzFmicnC8KFqkZhW8VktOAE+7rvIVc2HEIEvmTD89IXdkFbFLBQbxh2p8HVYLZZzHux mRHDS/i03EmUn+bRlvRARWKjyE3ivIndjYJgh/fyBUVMT5p8TT+PTHMFrNxQZUuugvXoTAnCBFYp RcSz7v/nmq9k0N/05SkbuBR6HpTwSez5BUtXpCx8J76ug+aFeenWD8Ap+JxR13954AVAM0vwTfHX aNluQjEX4DA7QOS2rhfdg39PPwRIDjlM4ugCdH9BEwejwQw4kT5gEksAZ2xOOoIzYI3kNrw1qvAg F6zG0XximXPhGzhLV8LAKu/AhSioCXYpHtCiC1GJB83rW+JKk0dKAO4Rwa/zgVhpIEvIQ1tOquh5 wKHJAwhyIAHCYJx7d4IOixc3xMhNp/MJoezhtiMS62vugeIP84Qmbm0FU4CcAb+nPc7cBD/TN5yO xFJnS0DS7eDywkA0Y3fQjFjZ+qY2hpNNb53XtMmCCq6CThpHwfkZvcxYjozIvCJmdkqHk0DZRivf XzTPg8NO6yTAb0V+72xoekHLa+TD4p+x6uODlF65e5R+Wz7Pxh5gTPTU9ZJ2qsbCwtJ2LO+iehlA oHx5T8XtUep9IKl5D+u7vKAmWAPxR0wy6JH/sFlO7f7R+Y9nWwr+Tw4CEhUMqhShWevfmCgJnk+Q DhpnQe3KIA/t1nfzlXIiYhGcyYZRkGC0Z93pLKDAH+gwEdlGNPLWN34oG6x57GCehu77XFuZZLHO mlOWTDTyiw/B5+6sd9sf32ABKm/3GhpR3K6yOfCYEYtlwynqVT/sMg7dVFTTY/shvKcWFVGYG+Ks sRZPVONNx/MZ3Ccr9h6S3o6HqN/qYgHRRLB94D+7gNM1hjWdm1iV02UuIy1cAxzSzKsFcAvGfgi0 vHrDcRRuiuS48uLp8IoLHvJxhqnly07rsqHKGU/CERfjpTCszK1+7kY8K2JKOw+enEkKIbSdDB69 Qqh6p/5rUQxXM+ScsapEUT/Kr8icTLuj6H4w88ASfNvWG1/opQ9B1OJSaTYNKizH6eDmJkRUIlp8 Ymz+Ng8BmCKSehPKSpBEk2lYkJqf7v14PiIreVi9Sp5sQsuuIfbaQFq9yzguYAyfSPILOXgOUP90 C1zaYDZHhWmebCG60/5ncPKWUjBN5KaYSb2athjYCFc6NO4GVOIqDawUsMSgAsaCl+qByrc7+gIq csEt3ZM+/X5wczsTNX4SAjkotHtdlFNZAJUtWSxzLhA59WSn6JsyqJh26nVAUc1ViuUq4Kq6osCl q2yf1qIr1aDLi+6uWPUbCeIE+44k95iWGGCaCgxxpYLAdSGDhN25g7u9gnd82PYEgaafnBDB4GX4 REESg9GY64RfBC0tQUNFJ1oPR0gHwgexs8DuJ32rplltxcy0EppNOS6JfYbgWkopIzaZZsAjwdd/ EuMuiT3cy4jNMZ7emwiu3vQhGEf3wa1oBmhzKC4Wp8Pri/M24Nug+KJvHBDV/vt3Sve9QshMY8ZT jb1EgWKe9xbNM6eDid5zTzSnoKndWzTTnFLO9d5Kc+3Q5fOzp5ktVn8vngsoT8yHIC6ow4Z7MGg+ xb7D+yYw4uGihJQK8UEhMgJAYwy/8LhIWq1GSTT5/Ps8QuSPQWEZ6QK5KFFnxHtJGsyBars3DYE+ RFK9RjMipF0g7LDg8aIuks3mwsymUiO3JWE3m/R5KliMPDQlUREXxNWF6AyJlebFTIa6QgutDpPJ eXTQ3oybNmFmPX04j+4/0L6y7aSFxC5WbB5WEz6cPvQZiJaXYAyc3dqiKxe1DhvGbJKh7xF8FGxB cXiInfmWjoy6vwO3EpVirZznwC/kIy0aUfjukKSAwPdeeZ3Di+C8FVweXQTHrYPTxpb36pWoWqRi Qw4pbg0r0uqi9fEIEcRPKsHh9+3L03ipGsZ8c1jmTG+9kzKlDs6/pzpUgeJdRb+T+OYsaii/Gt4C hzFCAbFABp8Ez5KjPPjXWzGvR3ko1gjsrTsPddi0Jbq93ngKHLjYj7w0ZY6uh1yqUlcfbfMbFofq 5TKInRXwlvZ9Gazr7qrw3WASiJYAG/TWO/zQoO6fnZ815H0R+6knJgxGvxMcnh81WMS0GXz8R2wc EP8W5EUBME0rLegC7dAfcLN5xYevh8MH1Pbm4rpekZBDc3nUMVq8coneXQWCL9kUf/Me3yRRMsGE zca98ZCsb4LZl0kYIP9LaYnHpzGsYBxtMYi7qFKDQfzvcNQfXKNGDduCscSmD6Iwjqe5/6Lw32L8 jhrvLt8H52cA5otLenKnMOgLshB+FeA7oEmEUA9P0WJnG94h4YocbwhDPPcWurdv1WO/gbZ2Z+N7 QSP6IQdeg+zz6ygYhtezn5gs/IxjRHP3YSy6xRMo5SS+bWPSJwUXvOGH5R2IY0awnW0IJGwQpC2y lzOTUIhmKw05bpZLnpizAKG3wXwJv/wKMkJAPTFiSIB0JqianKqdGl4PVvxSZSEi9ItCCsv6pBxr KsOKZy3dBQxGgz4EVBQzJeQZkW+qwideXrwBPQilj/GMUAJdNxUSd91JDgPkqugNSiqR5DBwQEWH JrAKxZ4VyWQD5BUC94DuEYyrXbpS7I8/YzQkIWqpa0abjzkYdqf3BiuD5Ul+EqQ3iIcrBg47zJfw OjXISxhDEvK9id+r8vCl9uyPdUHA1uxlmswkemMuKSivO2HUzEdOmMLc5YlYZ8YWX5HmWF7VgqrU /1ng+/DwkVwKkQVBuEu7QBYqQoBlpSAeb9gPYACU0nEB+C0cTRg9FQYyqcARuUQjBtdBrzudDsIp 0C3WFRXUO5jYAGdSqZG0jndpxZeTLNWOjFqhk0m6LGgt9BqIp2R3gHc5Go++mQkp5o58erCZyOR/ Dr07vlGfhpQcmA8hTwihCPhnsT6PxK75JFjeLkLicZo39IUaCAVbfS+YV7G/8cGGRykau5MD81tc BhlJ94QUZNpYwsBjRWuVw6aSk0wzRIsipBJc29cHIjuJrM0jV+4kRT5WccvHdhDgll0SXLdtxyge nIJ4DSdqDTAitlnI1FGAVN5NWHsn+n0kvml9XQoZWq2Vabs840DlDOuoWBfltp70BrCtvdcTraua 1z28i5X+C7ulHXA3FNvbCEnLpz7e+v5lDv2UQzzTGU53xcPBP0Ko9jr8LJsHcwtigvhb+OjR3fmc HTgVmCWViOEYhdQxFoz/SEECR/HlRjaeor5ADL9XaMqa1V7JVKWnFuGTBrxLPYSXnamPHEAsMXUA F6pnc2nqWTnGDiZYCBqw9sEUmhhvNOBr4EW7dwR3UhddtJEiYKeWaJM4mtEmR/aD3B4VXqGy5Xts Id4GtAwRzNhS47OQTzdlbOs85P0opLzT04OzI3BCbrY7jZbhzPeK0vYGD9A/sqeBIglgaqUyiQBU dvN+GQjAbhm+IAF4+jZaJpQXYsjgwnAyHomz+wp1TriS0sd9vaxZeiI7kvde8aLJOqYqp+FquSkX 3r/MFMHFQavZ+buerXWapIYQkcl1DHsFTX4iSMSo98XrwC2ZNXKZc5CqaUiPObA4MVeJ8QAJOdbs k4NO4+zw7xizvGXFPLZLlGdPrZyvAGtZKu7kd5XHH6+heBbbEvf0tPWONZ+CwoF6QW+8w4WraI2c 5mqGS34E7is/YucV9Hqxyv4XQOMdbvEVvzsFhCuj9QMzQOGfAGsg6+Jad+eC+4h32n0Y3IMSbj4T BJlkqWgyHJBb++zzGG8eR2CQivyra+T8Y7b2ylLqVZcsTz0yF/NA17RgVurHZKhmj9lb8QR6h0Zy pwcfg/PLTrsjhqB59j5oX5w0O20yoOv8eE6/g07r4Kx9cNhpnp+pa2+jwIVFwQRR80krhgWsuVL0 OrAmRpa4+lTn0qcaJ+V4PO0NroZfwGNIHHUwFcD0P8AsTPsh3t8kA6UT6lrKtFxfX/cfsVm8tCH4 HVZ7gRhe7/T86PKkERxcdj6ctzZftro3cMs86k+73vfjeXQ7uPO+neqH23f08H+AM9kWR9F3GFWA SzlpHjbO2o3Nl+8vTtDUl5+LQ+F0kzSH83shqvqFl14Q8Mt2Rwiy7zf9Le/lIJEJld0BXlE4c9Wd ubCqVTNdD67Hq7cPMq3cvIcAjNdXqmi2Rh7rYFma848Um8FgAzwx0b55QJiGkJ3SKAe6OAaGEPKj GdtkoOHC1XCpGO7wRhqFN6Jln2LuQC7pCkyk3KLBSJpKSwF4oBtL4mhCrgPHBeMGdmALTINRbzgn D0Gym4eWJtw64CEWBrmHXUPacpiaKQwSVOuNQvCdiEhKYlgGKovt7bSJLaJPys6i4RnZ7saxppRX RfPNORWl5TrHrJMAaa3QaMxmwXlehrn/HlyPwKX58PzsuClOGvCqPzu4aNoZByNSoZIH0N0s0vnp vsRKjfdpoGkDn5J4hWbCzsOx2NBnSAScb5vH5yfhKCguee8veV9a8r685H1lyfvqkve1Je93nO8F 9wIaPOe71gO4XaSNHL1t/yNl4NRr97ip1+5hU6/do6ZeuwdNvXaPmXrtHjL12j1iCGghDu7raRjd Ih12JkMj9AnYdKWnuVcpbqGw8bAf/Fr81d1lV9rKr+4mRrfdadhnNs5dWozLcyZCwAzwSg4EWUG4 2LR+LkskTjo8sAJBzdMSQBn/4ELAHNhV17JippmKgcqm6I3ZTX1/3VvwkjJfLcqc/pIyp7dMZF74 MmUalvRpuqhP0yV9mi7q03RJn6aL+jRd1Kc4r+NexpY0qVI5VJpk6p3UaRo+Ul5cff5YxogLm4Z7 j+aJUlWdT8TOYGlPxs/wTeLTMDSE5/A0HA1fU6SwNMvuNRK+606+M6b2hVuOAO8oRXNf2CvSed2R R1DumWe/AwP1QV+kmIYqNGmlWPbRzqdcKksvcPRdgTzgNwYOw/fd6G6TykV51vpcnpxIQyt9A9k8 a3b4CtJq7Z53iUaEtQooL49OD1QEUKjHspvPyZtW2RLEGReDPtKNIqt50Dsub1xaiDu0cAKLs/KO sjh781pv85DMJMWue0NqMgzsbV6Ss7LV1ssrbDNDf2SsXvuuYNIFkRbW07bpCrhSPnQDPB0rLPgo NF5LMBOtBTWCNHr9OSo2qIj7MXiWiDUn3pDPCN7GfcFLW34JLDPuFKMBYFZJJSQqp+veGf6nW8C1 oks3cThYDU/KbjFfA+1ouV7J11gxT50XKwRNkOiXjljxgM4HVpNQC0fpCt8RJ3uGhoBSrvf+j/66 hxFZZFwLKcQD4BnY/Klk33m+tPQTJGg0u9v8vtE6C8Sa8l6CoOAJXjmKdRUdEgRlhAZEyuP5ZowR 5MWCIax8HUodWmA0gKtjIHpqJMUBZlz6fU+lFk9+3vfQUGxLxfWVjZdX9ni3D6pTL/4m3ie+jqfP wv4pN+7EqCR77u47h/z9Ldk7amtiImU/ue36/eH1DQ7ENjT4BMMr2wO0KP2FxBB4y6NNTVK2FoV4 zqJZzxFFMg2giQD6tp+a3qinSFOfc65VJX/uGwkAKyxetSGKpie1a02k8t0F+ulJjQJdqUruAkvp SY0CXanK7gLL6UmNAl2pKu4CK+lJjQJdqaruAqvpSY0CXalq7gJr6UmNAl2pdtwF7qQnNQrcIZKr l2pT8FWdLxMwuOl8PArECRt0/n7RCC47zZP/C4d7PGS5YyMP1DZG2mTtl4Fu7bdercrGw7F2ikTX Z+P2aDyeeG/hPfIFZ+dB++z8/CIQDfP+5Zk/g3eXx8eNFt02mZXqAuO1ehbRSOv2BbgZN9sUxNzA jiBTpYJ1IjE50C3P2GQ9/Kx/ETnhPqb9/Tswhn/f3rdm6BggBZRDIp2XrWXnpdLegEE26+nFeam+ Wuel1K67TqvF1FxVk0LNW5o6i0Sth75sjpuYG8mh3AzEHOFK++qs3EQLobhRERoRoemb725g0Wje yUHrfSMAk/XDsw4f12aNC7K2Tw9OToysfBwmMsT6ZpFyc+L06BoJpupEUPVqZZxg4DZhKYk2tHEt vzs5P/zey3n+lruMRU2ZqqMiWZO/Wk1+oibfkarkqqm0Wk2lRE0lR6qyq6byajWVEzWVHakqrpoq q9VUSdRUcaSqumqqrlZTNVFT1ZGq5qqptlpNtURNNUeqHVdNO6vVtJOoaYcgcuMnm0HM+EQzTqqp Olgg0fkUJBm4bwvOW++RtOOCdiV/6HdQaWvwl+gQ86HVaH84PzlKybfoQGzZp0srdiC6GiFSdHt3 59fXAfpEf+qCZ0fn3RFZpxTcRMrdTVfi5Z105HKenIv65qw5vWc54xxtOc/R00HUC4fD7igcz6P4 aYqyrF8r5f2KkGUr1aJEiKa8hg1Iz5PeMobgjHoFA9camJP+EE6+5HlfsBPGrg8kYV6SJvYkkSPl wkHkTHmTqYTKrzspJYg3OAcJnQzieUn/XXvM0/nN2O4Epoz9mgCmPunXNPg57xW31Ewb2kJSL+It iVRlovM9a1UkVis64oNKRsXLhCLamO80hFCYjLYiXwV883KvX3rplv2nrEQdDsc9UgiRMK3QzRKg bCh2i8IDzKNkb1ympWI9Dx5Qld3dPDtAEVqVYIUQoLZH9vUYGe+VAv5Sr/Zlhr6EFpbJ8Jd6bWCm ygT6EV32wl1vu9EJGp0PnfPzk+D8oi1yx55sos7vVRJ5HA0XcspH7s1rUkthtA4xS+i1B2sS0O82 t1B54eme8oswilgfJramBFbkgB8eYDqEaO+K+wYzI8DHlvaM4UH1d8F9Mlep+j4QAT2sn0PEbxBs TKm+z7ZHynZMuwkW0pHd2++ByiVh3hdk2Oe15rr8zggjT/ph2Cu3ogOB1tuyVwgqc9NK+dB8/+Ho 9GDfCVK+oKvitWy6Ng9Y3GDMknC35IvE8VwvYgPpQu6EcpknrVTPk9vmBmq0fzxvfU90QkLeITQj o7dsonn25ust+vJabF8LHi/vKaUwYRlyUBBawZskYaCA4NrwR6QAplzT2HY3FIqqWFupSOZiUfdT yBBw2lBMK1PJsVJTPHk8yYsUeYWi44XlcfsA9q54TWAnCkVAHYAlAJIDP9hqua6ciX+TlRwPHpSC 9OXxcfTSRMGWkCeRN76KxMlM5pAHw8lt15sMuzO4OIuIvIpyxDF6QPlI/y4YtMGDuaVlLJJEdBJb Ub+ov3y3ZLaRletwbUT6e1t9/5jSJISfCuYRi5+SekLwyNeK+SqOfNXPV6UbN64TWZBaJ2xijCed 2R77Dg8ctNDdh6FSERYVotK56KS6SIPDka82+G5jUQ2YYJ0K5GhlDgYn8cZaojnBwdFRKzg8PQpO G6dBC1jI5ON2p3X+rhGcNX6ER96/oEqAeEgkPD8+FufVphh76Gqg3rc7B60Ov90yUY0tbLSpXLNg mgncAG7wz93BTAzL4X3/kDEe5TKHN+inB8l71ksOf5KEVdN1AEBWkWshfhMdPsUAzsulLQ9zyzfz iXq+ScV+950nftEeEmXQngInymvejsBjy7ow5jdAZY+vNyHQzAHERcEu2FnVps2SWdo8u6sUUjY2 ub4F1uPQg639xRlK8QzQx/qyXL4rl19blq3oylaqLMtWtbPhhGWqr+LOiDXmNhYNv3Mgl2RJHcol +dIHc0nG9OFcknHRgC7JumhIPQvuTd2LM94bC7pIDYE87BUfvi6WHgpp/yBnX4CsC1fU8jR+hjSl DGnKGdJUMqSp/kx6B5UobXbzGVL5mVKVMqUqZ0pVyZQKO2mI/oQX1e3NQIqTUHWOg1EcgB4dbMjD Is0mHYCkgvtEe3uTL5skgjG4dz425nmVQ9Lc9CyqD1Ym2fymLQtLtHQJHQ0SAbbYFLA3HZDYSsJO ml1MBiNAi4ykM81gFMBvtLEgLnwQTfER8XSOBIK3l++Zw/vYKBSLpT3QtqAhBUNeE1rObPAJ1Hsn jSOPr6c5FrZllbFmEShNCt5PmmgJyWvbUyyLhImWbLkLJRpZOohXWwJ7lZqQ1yvSbywLcKrB4J2C p/6JjvXdBXuWa69LQV7IfTavYRJPDNAGJoY6jpa/z9dJvVsC7ULwZ7al6psBZNCoScn3Z6cXAQeM YdHuK4qy149G9xOaRJSJbMAfTULJmecleaAeip4jt30xHfe8/mAa0rYCyQKqIiEpx60fQY/atFbp IsEhj3LSYxIuZTo2JZd7B4WnH8JphBiQ2AGa4OATPRQMYD3vlYrmhsNMZ4hCZOYgXCJOyrZbIK2C PnKGNzh9DMuFEux1v/tl89XsXh1PwyMCPZjdb88+iQ3XM1orMZlSRM4URKVlImcuTeQEUKWcuWce s95w38ShQlD/hkVJUaA7F5QGzOWQXlLmPgVs2JDotahxwWxaVkhD3kjDlFCAH5rvXHMvFF5YEUhe FNjPyxbM9kQl85Fr5kQe+sTGH0wO3SUJOXI8H913J5ssBPm6EPglROL7RcmLVvJiPDl94upF6AAg fVhqz33ZW8MGaA/kdZEwpgSVrm7kkhcyNaQbWe0GNwy7UYiBVsejyH6JZozTTyDlsKHgGdgFSnpa qSLcfaVW3cn7VQsDotA4Oz9q/PBXgBBJR3tYAgl50Rt46ighTGccK69rWBJTD+AEQ0wWwTWDNkbw IOP5tAchfod9eCiNjDm6EdbcG8/Fyyv0qJ5K13QsDmMpfxjPvMlwfgP60hFGkFG7nA9CQppGYf5+ DAoeBMgkrXoMX4LVNvdsin0MbZUjKzuC0NswFU9jfG2BcK4/1FiW0cz1hxpLig33uiONZVnD7QKc QNPj8GEws8Z/Ec5KGuYS77gaggGLHbdTy1ekUsp5AFG7EW9CNB627VdfKZNhGaPFw9MG6LUXizHr IDu5VGKaSyc/LjLoJKW/E6EqLDgDUvgpk5USM6YSa3049tU+ThC90Y49gxjV05QokbSuMuwTSBym FoCwsRLyEkuDd+m2xrh7TFcFgsAwLaNRkW3jBAUBceNGt1BRj2s2Z8YtwUsRUd39JjGfidNAPoFJ o2ZKmUNzc+7xRABwGM5DDtgiwXntEfEyjmlvYSk4rnLdiPJg6Iy3DjA1ap4eFlqXxtKjrPGO0rbe 9fMApbLj7+arOz5fc5vDYw49DA+/A9KyaVRvut/EZwQchBU46uJVEh9CcU7/sDSnc3lJGL/Ogwcm gXkVUAoSjhFHT2VWo4qolckFxaGbYQ8Ipkdey6P0s2ncbcF1WnHL+9e/vNhDf0ty7Gxn/dJ4z1cH 4QDb9I3/DZwC3xS/Uew61+kzi57uV8umcHGPWu87bxPxP/ATa4oyMnmZzActm4EQQOgrNyCtIfyg eP6PcCpOJcFSDUHngY9Kk/FnsczKpa3Upks5jIfOdaNpDGLa6+RwOlPywOJdBDqP0+imNY5GTxlu G+3Qz0ANGqtav4wNFx7RPhze9dQqo88DiMWha6DCe8B/1Pekkavpz6ubZT4U7fJ3SzIIjJ5Znloz aXorRQmqoVZLycod2rTjalPN1aZa9jbVHtemmqtNVVebqtnbVH1cm6quNlVcbapkb1PlcW2quNpU drWpnL1N5ce1qexqU8nVplL2NpUe16aSq02+q01+9jb5j2uT72pT0dWmYvY2Fdduk6KW0pAdbxOR Vson37LHlUEp5StV63Ws1nJpMW3WNtJAh7E6/chRoX6ZWuVy0qwKcZJmwzj1W7Iydw66kWzRoVrM Tn8N+9tMFSeI7GoV15IVV7NVnKCkq1VcTVZcyVZxglyuVnElWXE5W8UJmrhaxeVkxaVsFScI32oV l5IV+9kqTlC31Sr2kxUXs1WcIGGZK1ZEJYnskSQlmkl2pBYtAMdKwWlqVtiHUG1jIWgsJmhxvBBR c/HBL1LAivi7r4DYA9UTubEx8QTfEcrfcVrb4+md1L8GVLFWrZari5sexxKBphNJTrz5ztuJU+ZE GldbitCUnSXNSLFtxrFoJKpNSc1TGD70wrDvlaqV1SsFc+jslULqFSu1wSV5DcA6sd+IeeCj0X78 naihmhRDrTSuSajDJIisCxuXxHcUDIFjyu00qXNeXjwSFtAN1JQ4+O0U9kCX/YWlx5FtaFJj5ScS 2VX4i0crjrDjrCKRaKUqktA66AKP6yIBl6O84x00I1nOKy9ZgK3CeCmzey+12L28uQxkA60p7VBT Ddgdfszr3n7Z45cL+qBQcswiX3lmGbHlaPRCr0xRy+KOTN0dmS7qyDRrRyy4n6nVkelTd0TCIeHi BFQOPSMACmQ9lgeSBDJy5+nrxyn98zQGkwZU0uhIqhy7g87+4QnGWq9UdZSeMkdPp4t6OnX3dJq5 pxqZScMsacyk6ZP3lHXf8Fg8+i3VpEOqcK9H7wRndjSFu9H3bPQkL6T03Rvf26mkRtRQeCZz6Cs9 Qnvniz3S6I6vr8EAHYsC1awO4Rd2eyqUH+K3JC73SMFr6dh744nUFcvaCfGiZ10a4vjxXV0sTALj BqleRTMGSwLFfK877M2HGPIFEo3mEt1+cvslAjMGCb8UeVdfsLhJdxoZeDABwAN7N8PxlUirYJAg /B4Mib6WvAuno3DId4ikVZeJb7sc5rfbx8i8kInC/XUBokhUtp1+52nMbksUgIY3MiGOr1KFm7eJ ajnIC8RoJofntRyovOe+QSTt+QtlHGPdPYo1Ctdl+/q1mXuEQV1I8z46RABs1r2bAUwlnP6WeY/I FY7Acke2sPDdfSAteLQxjzbdSSbWNkKWxRBnMZOOlGFSzFQpkVCbJpmWSolk5CfWBqM6TqmfYHuR plzb7QVrIvAzG/ZfUpvRvggbq8x6jgdg8zYc0v0enNg6wq+KIcnX4XNcupQP5u1a5A16w24UbSuy IDG9MHI2bXBp3kNhHCCzMasGZljEoeQsHDRyJQBcZlGYWO6bm7RQkI5abdjcROT5k4N2OzhrdMDR B3zNGi3xAxDG61t5jzAAmAyP+guCCEHZN7HLXA00QVlpteL9ogSJEF/ZQMyciWh2cfvlQJCCn2jd /rytlt5IufflFT335JLaWFbIqCnyQ+Q5KmYAoxE+YFZKBDHjiOZby0mUdIjbh1LJQ+CNDBYdIwkQ HV2QF9f17wRJBsyMgs3r3gAI8DsrMisYMkxpCfTZFAC8JoS8IcOEwJ1iwYw0LV1DZwDJJ4ityELR ka+tYu7HWC5A3XlQNZcnDpKCeaJIOg6No7a420HA+gWDllMkPZEf3Tw4WSheUCAevicTg9OH1DAU MnY2VFAwA5nE17wiseYxJrI4TrIbCE5vn6MLTzJ9ZBONV+HjJSZepEHx3h01RRHY9O1UAxkVAEzd 7iPwGJw7ER/KlD00Dm2iAjTAMZmlcnfFSIvNa4jaSo+xqBH6eLJ94HRmjiDB+aHD6mRI00m3xGxu RXNuB/4Vww10SzYDYujKRcvHmwHSZ6/8zZ6QHcXZJKrJe/T9NbYpD+sqAKC2awpXRvFkWSsFD16L JZKn8/I1Bb7Ha+P0E1MdbSfUenmvnDjtVgyHBpWrgiS9KNKZqNiat97dPVr8bbJzTrydgni+P74I ABKscYLECYH9VH6mhbbYSna90rlZYUYqvtSwyjhtnEpKpdkLzUxI6qvOOdjHOTlWcMgVysXo60Kp GGGUtJe4U9j4CCgthQ9NnP1YqBzx3Fuv6se7Zh3ncNsM5WRuxglA41FuDmCKj8I+jQAAyjy2vMuR WWKiL2uNGPM2jkHjN866MtXWp9ok39OW8KfJuiQz9Mi6oFirc4Jzmo4p0NE7oO2iOSm81vo1O8YU eC/HgCqW7DGjeTZGWNnbL94BCRyO0aQzf+VFUlIdoqqMSjykJjzC5nPccPGaKqV9DbiiCVFeUzdH c/fl26+Y+CF7RM8KhTwTNIXTsrAffTUxuHFSeCssUPNW2dJqWmL1WArc4l84DqQIfgd2e4rAYDam hJzZwY9xnc8s2V+NJYuL+iY7lspNYWmKo2Jm6rW3BjuFJZks1SO5KU/1/+k4qtjazcRUvZD3ewZ3 tYCvMjkrUR2aG7+e8DeUpuXTdE6HU6RwOir/03E6bl5uchbOjkjTkXiLLiwRpQEuIIVnVFHZcXR7 pweHP5WKP+9Lh54LaDQh24gpwSVLxu80TwYB4YBITqKKVP/rgo/nQynib/pn7Nn6/6hDnI8b8GpS WxN+no77IfwFKEf4256EwE+IFweHnFWyTOLlcDzDo5l+Nlt/gz+H4+EAf5/CZuBMrQfJH4ivR9Px hL7hXNPXC4zMjnWrxJi1ozN0dIaOzLCl5qJU3pGWwLDHbmcKjv5q/EntNNRj9uU84UTQ3BinjShp P4tmTal+bPUJqWl4nUrSbMfgnMTUo1CIhP1A/Wc4+zye3intEemL0rUyDBMBNG52O5j2vS475HjS oYzqnkAYWYTmshqwDZ6mXdHqL1TOYCaVoVegix0Ofz/VEW0iQ9EFY0enMI8VWeXbGi5sywbv7zU1 Tyq3qXwCFfpgNA/jqQxHY7QXkBYUTD2A5ZIJb9ifN5J52VRC0j3kySTTpnKZCiel+DJy9GCn5nV6 yz0yVjjsYknAYq8Yo5VfSVusRBLZP5geNCVpHndoHvfoObm2JRqJ9CL/0i/S52VeNRBySM2eeoBF 72YqsrKgRF4OG+xOyOWlF+YZDdRDaCgeUXh2l3AhKKExDcpRXJ+ynu1W7i7mcPVirEkyXXZVHkE0 Z8HVYLYZBOiY2e4cdBoEsgLxQ2Vl6LzpKlRsXaDpYn3AJm6fnHc2J9Id/nqUkuMdKucp3dU8EisT mUvXmm/9zVrx018dicTxMaRA15QUOgmITPw0ci13CbpmZTGg2HLJPHzGWDkA7g4eOqqgM2gS9uMZ +vTYmQUPq0QVIT51ZqAjLZFjQo+d/eg4+jFL70fH2Y/Zon50XP2YLehHx9mPWaIfkhnq4VZ4CYge e2n/sKC5kdiKAILhJZ8y6IUrQ8mZoZyeoZL+ioA6rN44WDtm7vqKkeubP2PP1v9HieOOkybWZTxL HGnh4LCT4mng6j9TUpw8R0maPrneMqGJVUXExNmH1t9iaRWZcHZDbn3XS9757le8O9wvaR+43/GS d73spFfYWVRhZ0GFao8xUU4wr8oY01aYaJWJFNGWq0ziOBQx90fBpfXQONSWXL3/gRPBM3Ue+jrU 4OQmgml03FRqqRm/tzlIkBDJqbJIscpQIV1cNFqt81Zw0To/DBpnndbfvTfGk6Nmi8OzQxnopg1X KNz0ZGHp1hCJu5yYV/EQdchk1cBthQTgT0aGC0om5MtglkXewIs3YpDeaMQOVntoBA+pJwIoB5yc 2Zg1T6AsAVFnTvLolXG/1b2+5695b9jtTYTQP+yOyMV9NBnOyU8PG3wbAsaMYHyhuUa93SHoU754 4cMgEpQd4dtl78SSgJLkT3WrhYMpr8T4F+LCRNGgN8C0aGuhlDoQdMqyTRE5bBfCBCbKItMIJb6J cQ1EVwJS8b1ui0KOBtP99BTGPVJKChbw3VoDQ5p8C0tdSA2bMJ5iDZ4dnDak2UDzmFZO2iCjxumX ueBreIMim4tKX+4CnLDQMNF9hMgRRe178t1XWlBFdlLn4W+CVQsfZszqk822eiGkCwRVeiu7huKR NI39Clja+4mdPu8ZfcyrfFuxW31pH6aaY4hfYlAOaUOibkykMEaHmHz0cJRt0YXIJ7wKAxwWnKtN q1XtoHksfuTVuClBNBVVZ2VYnQ2lpLLpjyLLSm9gdNa4OYZ9QPvasAyTO2eMO4fzy+2jkSLf8Oh+ xbO+qa4V5TIwBwjthmmU3h0dN4WsoQap1QBAXfGtddlu5eWSUSMSN2zIexLn1TOl+xWRio6h9zCa fNvzaRpX+8VpvLmiVJ+l9m1Zny8Ojg4uFnVb91b2P6mDNRI96RCIaiK8Bso4BEh2OEn78vCw0W7r k/x14iSfhhC0pIXYF1HssgNHRx3itpY/ro1h4z6l4kZolscdoJcj8whVJxIZPQEzYBxNilhS8ERA +oyMw4eP1ilcDogVhWHr4XjBcnBVSPM8PGK0778BFrHwiHGojJefOlkOByYQ0HvZ+diRzB1HZNiZ RFgf8SBwfouvkaOB5RypchTd+Hc8WbKfLRIgBTYJLHrziLCIH+XdcqeMkwwjsVGxHLLYFUeyOKtf 6kjirmjHfvHftVeYT8+8T93RYDjsFoaD0fyhUNqubde3/Te0dyJkHmH5bt96yxK8KBQKmUvbKBWL lUJxVwirnr+zV6nu+TvbRfnxCsWdYvFFLpdbWmusoOruXrmUKAgANPwaBOIU/xKm338TICSEofCK +ue7ZmdzOO5tbWxsFh/qRfsjxh2ARzHBls7zCTJhyOMhHFvRP7Y2Njc357XKlni4BTrqzVqlIN4V xCuxcmS+5tkPm/0tQeQ3+6/ACH3r229LlS1xWIjc/e++q2/Jp35NPxXf5eP6FjwUz0QuegaIIBJ0 4t35+YnRL/GLL+wIToRw8yFiRtkaj4OT5vuzoN38vw0PQhz4pR31bkOI0x+Dw/PT04Ozo0Cca812 p9HaKD7USgDEIiuORxZQ/WXT9cZRgMpSkCc6wfFcEJRNH0bJL20ZkHoeBBZAqn81v1FwUtK0GiJy IsibLPyo8e7yfXB+hij5gP0mKB4s8nAKdxZ9LGQoiPaQo1jIPjEa0saGXgQb8ljd8HGsyjtViGBa 3qnLEK7zcsnT0dWAyzxT99+AYgLRGM1aMJhI5yNGLWx7dUS2mz0EGDRRYWdTuDIz5c8Ad3cRTgtc JoPwEG1N5OfAahkLoE6wozd2QXwXdH+b+8DmBH0+cwGFXvwUiU8oNy6ozsMPJwdnDQTxgKpg7Pe8 JsY29eCV1zzKe8cHJ23x+Gg8+mbGgU+twRGtbTX+FnSap43zSzHwDNqrPsWHogymi5Fki/E9TJGG AoiCg6Mbe46xhygMESTxPL9axCmYPgQY6kwNYUtNgSxOjaDEpDGnIJF/qqcgQwE8iC3nILZnYtgR xRHHcda9MexHp2iS7DGXaI1vlMwHVXGoHApG7FdiA/ihcXAkRqdeLAUl3vvmp5xI2T47uHAk9KqJ lNAKV8qKpguckijPycHfxfeykbKEVE1OafMsOO1ceu5PpWZP/sXfT45c6cQC4CW1SyOyW837Jd7b tYr3YRzNAg4YhJCTEMsAoyMARyNDzni/wX4IIDIL6rbaSgUluFrwHiUm+JbicH8aiGUPNzLoMIPR TWA3ITXKzb5MQqCdzOlBFJgAZLQAi4GjHgKB4IUhvxXF4m842UlIwMdQi3z+W6ycAC8uPELQNDa2 dQnqxZoSQPimGWJVZR8ZGNpqURwxu+KIgRAtVT22nBlClBpz1f6eY0gVzcWCJys5TOXFSVUzDl04 Zcwcm3jWevowpvS5WCW4HDsH743FYFYCkTTitcgssgbPrMWV4ezyNDW94D/K4pgr6BwQPut9vDNq kLY8ZCQ29RPvVXJYBFdRANRoz9MHYscq13eUKzLa5RrTQOm3kN2plQvouJtaeGnFwkt24ZUdKpzQ 0nCRkDVcMZjMpoDz5rXkPqOD3dhpt11QZk1gGY5IwxVb3VfgeBV3Z0POwi/V7bSSqcDlW/aJQyrv SNLAbZMrHsIAq1lsCI7o/JjD3OGZddw4tj6CeQSYQbMAH89dR1ogIPfd6Z0H+LgeBNdDQUtIslfD O8LrtgoqBZMzIR7hXsX+wtb8H+9kfIPWb2ATiIL2w0xn1jneDe8CaSmHexpGH8d+m6JJwyHTBINB wTFAYPnuVIwlGsZh4BV6Gnk6cXQrUUuLdFKu023Wgrx29T+Xof9p3c9l736809QkiXds9577rJPI 3vPyxXbRIraXMC1NVM/pOwiAqe85I9bh4qztQiyx6k6N4yfFiDZ4pKOK759Y15Rj0UYz0TPN/E0f +sS/AKRw9A9A9CRi/5pQO5J8jBpSsW3Q9onVOIwhb5xRVEJwcfslVopEor+Ya2tHbCoNA9qHgsaF for2GHZDYp8LQX8Q3QK2Kgcdm92KKRqFn5lh3abxqZfhWK/W6zLUGnBm8+kUjXfwQCRmzXzkaqgg Y66gffB4QUS+tNd2uD1cz9L/jkx1AXO2FwoRV91g5ClZP+yJCZSjQgaeiFaL8XGuSNUW4r3X9WAa zba98GaP08EQTWRoTXI0L3qbEF0sjGZbvG5x2Gr+DjDYtVJVCjrEWaDtEawSXAOioJtRd2iq8Ni2 kqL1cSgFvRZUdthmWMSFtsulSAzKdlVQcyLYapXq3LRE4Q64STP4GjFe4Ie1OBcWmrMKoMIHK5Ug 9rPcX3o7ax5KHUbSlRhdsRzhJ0K1nWvlEojhuVqlmC8VOYidHj+iHPIBnodgWMKxGGQrgAM9YvTz znwUx3Tlrpw1D4nj1HIzxQIF8TA4aZx5leJuzZDZzYDJG+WU8MU531BrWOGZN4SonyEPVfPu5Huu Jl6afOODVihGP60Bh0hW4oCfdUe90Oizi7NFrSwgXf/TFhoglpRSVYCwEBMqtBrjVAxc8/Cg3Wkn M1K8pm6P59CIy5JI+vO+lVT0ZlHSnF2qDoWyLLEod3FizwUtzVbN+C9GPZeLEkN84erd8ZFq1OVh hNsWbbFUfBKktjryZ4LSUvwROiE9GXZERh3hxxxsZN8UBy9a56fN9iEJddQaIdGVxF7aKVbzJSnS AVYS2hcFPXKpZcpuPxPs7eBaKZIkj/UwuZtJ6yd6NLMfYYDz0SzgAOjwc/oQezAzH+hi8cEimFgM 2QJ2nWy52r2KxsM5WEaMo4GJqT4xjlPxiM/nbb6+Ey0QCQKRad+KfQkyw8WwC7jo4oACMiH9VECO nAMlFJLrJEatw4guPFQkvvXLwENcMT2i1e8wJA1HjyjI5WiRO4iQJx9E9lL6ya3xwY0QI5mrF+Hh OFIZuGQSy5gGmuY1ucbJvN8YKRgB2fXOR+9ECOvfROgoBiP2g9QX4GjxTMYFepb6FfuiFX8oSmEk oT4GOZnmlZnHFcbTAaoI9ts8McMvnuAwBBG9/qIOCUUOsACKTTvoEwTVPuuUdoR8BGjzO9VivlzU +y0W2UOLShsqwseGH3t4ebGxUaJoKrBnutEdxj7dTwNhJw8KcO9iFwq6PLPRF+g+zQJ5wEcGmgOV w96TsqjhWBwnCMqwb2qlf/MQw8KiQq0G6rzhFhVsotRzCFZITz2IcY8hLlY4owuLz+iC+4yuLDhv C2uc0SRxe+dtpYNnIyNYNKzlZgKG0ZFUcANBuKEqEtQgbBIxk7CkGfycXrHvNKK+c4il4SYqynIe xemDF99++1aIWvLXv8x0eLuFahLPTGk+i6f3NMi8+INQ8riYa3hJtFMXZwerrNANa7jJIRlBpZP3 ZCHJlxytMe/pDhBQPVm/CXmSpcn7sWDnIT7pvQwABAvgtvspZFlH+m8NRjK8hVgoYljnQ7FW6dYZ jJseJmEPXLCmcPcq8k/7n7uCJ1JBYtFLDbOLo3869toXjcPmwQnc3gQ/tpqdhmn/JTKBe5wXzcFk CuqQQSwIlWAbFq+Y08i7PPY2L1H8PQZxYwsp1ol4eALA4vIhCjcyoIashKARvvAt+q/zAVRCzm5Y pbw7l0v18ljQCc0OHgOFUCs/3hu6hqOoaljaFijJ/5+8NKZxe/tWFLPl/XNDvlowyakpnDNNiX8j YzYsf43sy1uD17jonZ5pIPrz+/svW56OhMrFmeGbKeacDAKlb9uEtIh06WM46kpxpQ5KzKKXq1cr +fIOq8aggKPTA7pjE0XBsSWKsq/BOh9FkuDi+DBonnWCU2TbUJe5RfGKkB85PmRZSwWliqwFwYUc xgspbfEuSy1Cs42iBcA3AnUOfM9oB3FcchxMh1W8P7uG20q8T4GKRBsS9VjS1Qa08vhd0DjEqja0 thmgKcQwevX0GlmTBJl0MWRxus2RJfiK9GI6no1BugE9gaAPbINCQQ0Nb0+MNKOjdGBsqLRQM/p6 qTcW8pRnpwHBAIj5BBEA1g5nI8i50TxojxFOJialvaawVhbWlR1/ZmEGWcGZbotOKf6BQySW1IpU 4yw8F29N9iyqklF6g7xUycAahumDWD/TD4IEDyFq9fKWCtZXVD8NbhdmkdTBqmuWoS4rQ1esx/sV 2zfL1L5coppMvbJ2RDJazX5avJbYMo/Htk8z6nJmoxidm8oVGHlN6bHlzAKxi5T/UXpd5mqfPpxH 93LUGXhNnL5CDgD2PBzlPdb2giJ4Qg7cqA4ejWPrVKyXcXSvBnZ5WeIIt0szegIygVUEpISHdjKK Hq/T8XZw7gY8lCq7wLrVdyv5HRJD9PzC2LHiI2XoREfqYNxmD/9g+isxiYGkmNF0Ezfu9Ffl5i5m bdBXiHqTGcSeEqcN/GsWpaPVPIijNBB8Txj1wlEvBCbV4/Dk6JIvJB4YfyOHjm/DK1HJQzFTG1kb Nyac3c7G42EwnkRsZRkYjwyxxrnccKJiS5T9O1IEMoMf0VZo1sX7S3jxUqfTZnL8noyWjRSWeRyk YGNZI0nMJ0N9CqWiMxG5cqhEPkEoMtDA0fQTQgkY1v5uPKjf9q180kJYmnBKPyklXzIQCYuXv+0b eWXx/0yk9ZVUq4COzAKVyGqlMyRbfmJLxDI3yLaxrAzsYiQST7AfMmGiwyboSvVn58CoAY0PjI2F wG5kpizPHmTGT/AeM9uHXmMyS6K8Cw2vkHx5aLzk0pN6Au1bZj95ZyVptv5m/FKuZGY3bOdRfsqu Y/vmkyPtOKmeNZRrpHp0oXwf1dAkCus4CuskC+sYhcH/5Azax2QGJ5l9BylZbvds6Vck28Gu4kTl PwAnu6rJagFI8FK7VU61gvEq53giC1Z3aelmrKU6nnPwp66Namb9LqqykQ3aV6YKk14PH4s69g2S qoWSo3col2woixIplShLDFnEveBZ9mPPVG145+qX8M41YVzW+hhcHASHx++D5vuz81YjOG6dQq3G sQC1+1sLsqC92fll085SWpTl5OQwOOy0TuwsZePSKZmlFGsXZqlt0XjWvfkIlBh+6afiww5MCoSA OKqjcve/nj9/1AcxnYVwNr+6H0RAZd/AFXcw6k4GAWofStsTYMofU0fRLxZrlcp/8f6L/S35vl/9 L7/olyqVcmmnUhXpd2rF0n95xafq5KLPHAQWz/uv6Xg8W5Ru2ft/08/Krgu9ZU4EvVVcF3oWqd7d K5b2qqXtUrFaLlfKO7XsrguJgip75dp2zS9Xav5uqW7S/NIu3LDCHzJn4UMW7lkBBWE6GJuCrWJ0 ULIywluiw3aqTsGZPRlqknySpObQlccdDBJvRlzJjTiOi9LoUGqJ+xC6h/artTq6eFR3itLsB2g4 X0GD/n/zlRAoCZZD3UWzkPozKvS1YYf3Gr6zCda+vgpjW2+8tfFe06/Fd7i2CAXinSF6eVyptPV6 61ETY5Wz0bh8K6slvxZx4qJnCxja8o237STYkQGfv472PLB7Y61ld7bnfT1BlAdW9mnAaxTkcUyW RDLFK/qAblanv0bdTyGPMtw4w+M89ZkRGOWbyRiW0iZdp47G7vsnL4fxTnJgz76v6pqPZG3TEM3m 0ivUfCVdAECnCt9Js1Tfe4Xmt+c/ngUfhYC5Bcn+iWNhjD+uF7QUgwrwqlWuGbI283fKPpjj+TuV kmTKoDhgcrVvwGuwmIAuO15tedgBsqlQ18hRMBsHbNglMr6+mvdvQoC4oBtmfW1G10eeUiTQm4LL 6I3gHcniSdou5D05C3xPHs8kv+Y9OQJSeBB54eUVDTu85a/wlOqix/I7jhxsPmmDIRoMHCfSDGOb RXeQ6tp7Hd1dwWNWL8H88bLfqezmS7sw6rVivlIzbuvwjgPUKa9gQHH6ZtPu9fUA9vaMb//QNXGA I+UNvG95Xxe+U0EExWOCLi3Q0ikU4lPyLaF2gdXrzRgMTMfB9AFGVewY8Y8x1KIa54JSpocDtAHa ULvhrTlR29JuAaVmkQxGAfDhJS0jM4bBzz/J/D9zFuUN4OUgH1BDs1z6jkUyCttXy3YI+x3erNIx Tk80561aTXa3AHxtvrhQtf24ULXcwLV0nlKoWnAikZxjdtMZ/Lwt5rn1QBhFqYOq2u4aVXY0vYkP KfeZ0VTFrtcjsJDSpReYiQTHKOGWGifVEJMAx0mqI/d/SxRsq5BNPfSZeqNmR/dGxpdW+H8Zlt6r V7JAD7wmN40Rhgq9rzV52QKXYt1mBcmwcCfjhZu5lQm4zdtwHx5v31pm/1seHR28ktT9GcRKPCIq v2nrU7c8KpKSyo5pN4p9sqhPblmIHJHyyvv6LfcjmcX1HNLrlqZMJdcmyYuqXtGrr3lhmdZRvEuN zW+1gZZPWkZs0jLSwu4JmqzF6KaxGWOpEttr1foMMiOKM89PZwLVYa5Jg0J6GxIb0KQXLyQA3yp0 w004oAJxiPKCxDLjZ+yyhblhen1tyfN3B4USv17ckdbiFtvJjrXMdQKOKLRiEHmS2zTZza399Oxn cOc+GIF1INwjEngFTgRb8BT3kzvXUztXckROPyt7S5e4GciTAJkDLyaPuAkw2KjUVed3y/lyBXpf 8vOViur+BuIcgn3Ccev89KjxQ/OwwYUmL9Hykvnh+zdOyOyd3GTpu9+5+RfsYbnIHFQhSRQWlONp GlfgJbUyK5LKi+RSS1x2Dqcv/6X7Wm27LC1zVQFLDf5D0BieQJQmNK/uk51zRr4TWnI9GA4DklWv w2lESwZWSQH8A2Dr/DofA2b6W08ZE3sbLCbEno7C2eAaCuuN7ycA57HJl9MSpSMTK8xmVCkNgwOR QbSTCEgWOTifI5Qy4XC/zFt0IC0bk4CL8XD41VcaF0lDrBI8HRq9tgBxBtUObFYcs8/xNsJR0B9E AaQB4wC0HOCOtD4GndbB8XETDYxaeXHIH7w7aeCP9ta+thwsoiRBHyQ7e080vyvObu4/bw55hH20 nfSICUXCW6/4oOQQhFccPwxd8U+X38LiuDtIXTBk3aNE9eUidmZ5OibipgrCLpk5XQMQk+/zluqA RHhDfo8L7YZY75DflQYgpo9YV4fm8QzXfDC+zfm7xWK+vPu7yvXPIvqziP4fIKL/8aL0eiLxAklY Shqel2TJn4XgZyH4qYTgLMJvfC3GpF+59rE8jcZGh9cuciXi8KqWJHtCZcWBc5QQ/DiB8VlC/DeR EE2xXq6gzcTt6pZS0gB0oWSsvktew25tEX5RtVhHTKxqzZdaGOmS5b7kJdFiIjhwAIsEAy34DssF X3wOBxDn5i2Ao6BL/DGiQX5m/0M7zW4xkcRwKaHE12SMGIEL1lmj0zwOjoP2+31u/S7iNFRqlRrf 2JL8BsFjBt0hRFSWDsAROyTqy0awQ3sFkZPZMXhr8Qnsyuk4RrkF5Jna/tgoFIulPdDJCrYEvM3R dxKRc3uzwSeAVDhpHJHbxoCgDkLvr4WuqEwU/GK5XK75K5goJApiEwUxX35lp2SYKNTqOzCT8IdZ 9oye324X72UTyenl/FnT5/YNNwAOT8hx3wNosT/bmOX5s/Inxf6rBMc5GYCVH20Attj+q+qXazva /qtaRvuvnfKz/dcf8VmFuH7PhjNLU2Qkr5zaIov1vWptr1he0fbXVdLunr+zVy5u16r1nfquXy1Z NmA1pLD415del4JVgJiSI68/nl/N8l7U/eKdbYNWlzteguuO4PT8qCEo59V4PPReXkahV5LxRjGw 1xi1cgARtf0SD/mJIKYRPKYQExticG7D4UT8ET/OR6Rclfg2JYkVeo+xXsivF1GM+oRUKUGOkHYP BzMKbl5Ch+ZIPL8GYPqrEMoTjPA35CaMERDHAEdNGkYAo+9gfD3I1OUQFaH4ZwpRQDhYIhzM6tmk +wUs0CCS+QZihZOr8/V8CF0jL/aIo5tCxdihMfx/PhLMBwoEIquCrqCGQDQOhGaKvN74HjCZCINK tODTFwBa6kGc0g0xLQCiHWFEkmEI6PM8ObkXEPz0PhzN0WZvPJ/2Qu+luTZm47twBPK3XCUvV+co fmejx929Un27WCv61Wpp9xFGj35xz69sV4pF3y9WrQVfLqEvPvzxGVeC9Y2/gELzTmrEychRnAeC W8zjt0k4DSBokqFxTOqFtQY4Z/PK1o5B2/p7DMoBi/yg3yf1cNKAbx2NJ/LAJWLgAQLKZ3kROJY0 RZj3ZrHcBf7PBzrUqQGtcmWw0aQm/YXUpL9436oB9X7hW4IYA2aMCsrSwJqnS4AgpnMEV9T4bFmm JDI3iMFKVWSMqEghxjwgb0hQHPYGASKMwcBGoOkeoWeg4N/RdQ9nXgrtYvBeQe6J8qVkYcss0pba BTOLQnultpuvFaXMDnBJgJAnRkbMgsIu9GwNFwpAjNJ45KlGbCDgwvQO4AyMZ2/UuG64x9VdaQLe 0LzMj13c624GAHhoD6tVvBsB0Soa4DP0YHKB+rpz4dZREQfkaiSwovZsPBV7k1CC+ODQmEDiJMNC 8Cyh7ByGgNMK0i8objgc6uAkK1198TrX4V3W2mfSkPWqKzIYUYvlojdoBewFrnTLCOwRD2NMN8e6 UApxk4xMvHzjwnIXHbzTMTl1qT/9srC1WxBdmtdqqpotL5PEexDvgqiMeuHqhtRV34FyOVmVssa6 6iqjZ1noT3ccLRlfw/OgGIynYB2twqVwF/V4b4pVVUTsnJwBcU/RpA86QlA8lDE7sRdmudwJZy+A UKGhCOwUM5PxOvfWqNF4/uqt978UJsB4ryKHcllmp+ggst77mTrur9xxf52O+0/YcT/ZcXirtOe/ 6dti08j7jUVugHQMpCrJoEDiazQb9CITapLPJN4SGiNSuQUo9aACpEw5mhg+GK2jqrsVfaxTnDxc yxq1a0COB5Kapp65jzlxl5232SmoZ1DQ1DuLZSQKx6eK3oI138+X2GQ+66lyLEYRWBs+PCI6UNIO ke0/85BYg1inElErjnRm8mkyrSmUFPcVLk2L6rne+NYbay+aq1u1XNl0YLfip1s8h4xSY+xnyObe fLwaMVY4AK84WUN9qecuJIj+kaeLm/KOD2JGzq+IhVkyGXHQxZO9wWTaA+6pGIx410ISaW5BEGdG yt5sOpQpF3PTVMS/3noXLXJZDVoAUgBGR0cm37wonfcv42nz7D0WHpQt9s9pRBFvaqYt2JDyvyX7 Q8hNqANeoIjfggi9sGMA4ow3onO8pjIhLgHVzxQHXUiTZhCii7FPBdLnq3afHhZaJ0etg9Nt7+Aa LGcsjQZJinnBZyLy4Xg+o+ywnbtTQer6nl8s3kd5CVotuNLJZDp+GNx3Z+GQsM0gpwI4Ywe1nSJ5 atX05eAf6aGWNqOG5RHLDASRKL4LirW/WA42kYqhBBAkjGWX7m7odoyTF0g0YOL4BMeq2m5Z36bG LpbxyIF4J8tMUpTTlnErJ776Sw1kEhkXb2d1v57Bt026tqlsvpHPX5rRN8lDxnpNd7rMdVr1Kb1H ikGOHC/jhteeN+NalppCfoxF8mPcKda1QbnTjZEA48XWApA6MiOEtGj/LVoXc1p0i9orWK9k9QWU crOxOOGIpM6VKhgNxd8BX172VnuUN6S3sjek3Fp6yehBMG0cXOOQW2Eccu5xeGQRTisZmYPtSLVt 3sKKVPG6xrhNGlOUYtyWNeZMi9m+7qMnbfHh6+HwQcdMt7xplQWmfBdDVjK9LtSC3Fpp0BJmM3KX r7BN7XE3gwn9R7gBK9q1Om2Iewq7NpEZ7obgJLdM/ms9amIadaXSOXdXchushaMoKkeR1550RyOM Qtbt3aIxQ6hjUJjhNcaj4ReZk4OFRhAxPexDbtB1AtMzjMbe+POIoq0DCcEAq5wNi+0OP3e/wCUP FrG5WX892MqVCS+Wf9W2ZA4jEo8CEa/UPUBaN94hpC2MBgysaIzK3Is45M8AIEsLgkJAhFYopDzt mwVQDgz+LDmWzNtD7w7J94h1uQnU4rWXEMDZzId0HZuyri0wr4TgQ995deV3KJmvR+1T2RRtzSUX JxSdjcpvMNtnbUuyCTW0SqmUWEqHy/ujS/uJq0yYbZnypd0T51bbsDYHkywpBize8mQciBCMqM4R v1GfInruCk9n3We48iLpv5/NLa0bW6Fhn9+8NjSSr994pZJphMR6AFGSZELSHOvYDSPmgJGWg68w jZAtXvv7d5HmoeK6vgyclGhkwFcVYBOZTxswkVRUD6iOZL5YzCc2DLOUhe+M+F+sZbvvToJIrJwh O4LUKgT2UfeL+bIUDcTaZ/s62AXLTBRXPFf59FHTbitUkrv0J5GeGBNTVypGqPAd4CiqN0k1qVSS xh6rrG6l8LLBzdmDW3IPbs7c4Hy/JuvlNUbLulTKy8RuG9acczJlHrtaszqphcp7cofoe5MsFfkr VuRjRX6WinRVmv68NUIRciA8a5TMBupc/3qbjGAou5shB4fzEwsZTngE+N42TrRYPiKQmLQtVjIN U9C4n8y+ABi9ndM+I3jVJvyDYadvuRrqk+JGs0pS0GQRYN1NJ+ki60oGo95SVckGkeNZ94qIwm9M OXbKRDlqJWmrmOJr9XvoWpaYERg4QGCgmgoDBC9tFKB6iXq1U9HSMwkxvwh2I4uttgeFxky0XabU zIkusxH4fSETuNO71GnReQ19tPGLNLIGTb78/ptBulcUfGUxDj38b7ZChI7tLB5a5GuxhGRTJ3e5 k7uGXgQH6bF+/IYnQwabD9S1z0cGLUUTaiSlm1oJqN0nEtRfGWkY5wj70xcpOvuu+Ku075gy5whO nFNv07wqUtwqjBXAxzd0ga4rYK3rIzt7b3PpvZWvYudYauseW62fqNb/I6ot2dUmeYSFE6KMU8Bf ILgjFH3gvsWi5F3MNF9IeGS2b5F8vrXYwMsu6WHBCFF4+QrOOLt5n3Vuab6yzhCRbkfdxwJfLdxn Sf9ePUZZsLH+7FNrVfS6HTJr9XfrGkYkm0Noqv55mSeQt8R/0y3mrOcrmlZX+r0I+ZGVCOW3WC3m d9TBlt1LSR4RbqwKTQb/Qxxg/yiMquyetRvxlIai4k8DsoJ/s3tBSsLt9oKUbYh5QWKmbCBAOS4+ DhyRHQQorZv4N3GiGZKf40hLP7/18Z1+fj6mMj9emf87Vmad1e6jOr3ihAmJJrM/xYiBMtFzebGy +ypI4FKqTnM7zU7ypErU5ecv5QuZ5qlcR3NqG8TdY5kK4P7+KvH2a5fNzpbeubHk6h4qg3O2UjCm u3mrOlb1R1+1Canu30pDzHOyfFLihTpVxL+T8zjuOe29a+mVs8A+0YlOImquJOQ56b/ztNgwa7OV 6Szxo/BhvCfGh/lz+NPdIrld+bu7z/yp4k93axVyRquK0dk1lRLL/dZJViPIp/9MdvQvzDb+x7F/ dGH1zPo9s37PrN8z6/f7s36pwC2yjOUHYM44AGPMZFrpGY9VdarSVVfFL1aR6ayAiyPr1cVQeF6L rvkxvu8eP2tfHh422m30jQZTnyhCK52CD0+uu4PhfBpyUNlFrOZj4kZaUSMVX5CtxNSC8jw1Bo8I 1EeP+hr4kaCFZvhIBy+OCrjVbmgSNzM4QOWgJ3j1vDes4JfFPDB0WdRSDHBcxbcSfIMlpsNB3gqi 9lr8NTomn2r/NZt/5kYYCMon5eDw+/blaZypwXbjAk5yO53Di+C8FVweXYiz5eC0QSualflQ/pby xvXL9fwuQBoVy/my1H2m8RSCIQghnJ33Ay5l0wjTs9mLPCRkB4clogQOoZcZMhrzlJx5Sql5DPcE sq/A1aYc0tP9wO6u4LqcLG1EldgjLGECUaB7KOWIOQ0gHjTgY44iSqsi7bFPmFmObD92RjnutkJR ZH/eAyM7u0Tvej5CDITuEBCQgExM52hYSDkFwXChM3wjHnwDwUkHEJMQs90MPolhA8iFiLJekfeE imSPzlywd9CZ64V0+oVlBgu58N2t2JaROHWBAcZDFIXx+/C+dz/ZNFKw8crVdNztQxzGvNfofAgO wN5iS7LGYhAFjcVI2m+9i4PD72EiW+cHR4cH7Q4Sa+3D7k6NyEIyNQeCRyemtPbIqL9mc6gfKTWc dz40Wh/OuQaayfjkQx34xNrK6ZhgjA5NqB3G7Rvtx6pPEGPlXeXLiE0Ht/dgCuf7L4Pr60GIMj9v aTyrgHug63d4il5X2+ijg8Em8UBduNTNTGAEGoGtFNE0tYydadQezpl00CBqC28ULSMSp1GMIJF/ NYgvBuTw/WrVr1TWh/hKB+So+jv5UhEiPO7IeDs6kiKfDBU+GQRjsYUyKiDo069XHsSXPD7eUtEp FT1cvA5kJacH7e8tUsyCsIpdeXycL+b9mhEUMmFixe3CLOI7p5erKXNNKl8yg5/WNL+WmqeUlgdA Qcw8S/tTz9edyX138nibEpZs8QyqQQm0NezODycHZ0Hn4L2nP2Z3KvXk9MgssirPrM6V4ezyNDW9 6E+5tGUY+y5aT87TXZ/RZPm2uWlqYhJLbSu5eJYXW4+VmlhuW97/k+qXDQo7kVa87ygedlxa+b6r fBwyd/mlFcsvucq3lpjUqGxUitZD1Hxs+BaVBiJhaGUWs786sc+JjUclmZ8L/43EBfThBatIZIXn CCrVnYEjBBg0j2aRxM7RzgOMGUCOnyAMdweCH0IRCkz6rbRRBnEJDnd4xdy4gfHyT3NzJURX8+OX dtQdgTivfkom/5nO8moF1bbgh1raMcBpX2M/54Irm4rVADahkRfdjufDvqeTXIVeEbESaPBIGJ/p s3hRT3IZe1Kvvsgt64gRZt401oPsYms2jq3P5ckJLwQN4bOPbjHJtMCGAmiPxPNB9C/q+wAY2gEA RtwR/4lhkJ0AOmhme3H7xZuMIegEFDqikIt3ZGibGD5J3Ex4BrE9dmvQVXt1jr3bsZgUUIHMu0MD 82B8DSu9iDy1+OJDi1/kRMsBFtEAQohNkngpRGLkN8mg3MQvUU/8xJOi/X4feqXka4vVstpPuwad tSIFTXV6cOjJCxq88glngPMDKw0X7U4VF2296EsgMB6xjZPm2ffB0fmPQDfsh5cXGxul5X7sDIJ3 QMNIDWNraENbILoYxy3VGhuQumddIeCDs9m+YrLbZ6cXQfvy4uK81YEbJgg53zsTfaOA89Cver0G zs275R1pu5qInT57CD4DkmV/fJMePN2RTbRnGM5iLoZS0nBmASzjexmiPr2uwmO0Oy8Kln5nIdeX UemTQY2kCdTvo0cyFoMeTkAJtkpFlDrxEAZfJwOaNDPSbe2nS2l/Nuzm8+f58/x5/jx/nj/Pn+fP 8+f58/x5/jx/nj/Pn+fP8+f58/x5/jx/nj/Pn+fP8+f58/x5/jx/nj/Pn+fP8+f58/x5/jx/nj/P n+fP8+f5s9bn/wNySo4xACADAA== ------=_NextPart_000_0059_01C4A4B9.6939FED0-- From hadi@cyberus.ca Mon Sep 27 19:43:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 19:43:52 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S2hlnF030911 for ; Mon, 27 Sep 2004 19:43:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CC7xp-0005xH-3W for netdev@oss.sgi.com; Mon, 27 Sep 2004 22:43:37 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CC7xk-0000OE-91; Mon, 27 Sep 2004 22:43:32 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040927213607.GD7243@gondor.apana.org.au> References: <1095683660.1047.254.camel@jzny.localdomain> <414F1E12.6010808@eurodev.net> <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096339407.8660.33.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 22:43:27 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 325 Lines: 14 On Mon, 2004-09-27 at 17:36, Herbert Xu wrote: > You still haven't told me what you're going to use 3) for yet... Sorry, keep forgetting to retrieve it from other remote non-networked test machine. The idea is: Create something that generates lots of messages. Make socket buffer small (4096 is good nuf) cheers, jamal From herbert@gondor.apana.org.au Mon Sep 27 19:46:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 19:47:00 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S2kouC031299 for ; Mon, 27 Sep 2004 19:46:51 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC80R-0003Io-00; Tue, 28 Sep 2004 12:46:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC80M-0002aC-00; Tue, 28 Sep 2004 12:46:14 +1000 Date: Tue, 28 Sep 2004 12:46:14 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040928024614.GA9911@gondor.apana.org.au> References: <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096339407.8660.33.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 842 Lines: 22 On Mon, Sep 27, 2004 at 10:43:27PM -0400, jamal wrote: > On Mon, 2004-09-27 at 17:36, Herbert Xu wrote: > > > You still haven't told me what you're going to use 3) for yet... > > Sorry, keep forgetting to retrieve it from other remote non-networked > test machine. The idea is: > Create something that generates lots of messages. Make socket buffer > small (4096 is good nuf) No that's not what I meant. What I mean is what is the real-world scenario where you're going to be doing 3). Only when we know where the messages are coming from and what they are can we decide on a meaningful method of limiting their rate. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Sep 27 20:06:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 20:06:40 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S36ZCg032223 for ; Mon, 27 Sep 2004 20:06:35 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CC8Jt-0003V9-6p for netdev@oss.sgi.com; Mon, 27 Sep 2004 23:06:25 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CC8Jp-0002QH-Ey; Mon, 27 Sep 2004 23:06:21 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040928024614.GA9911@gondor.apana.org.au> References: <20040922000503.GA13218@gondor.apana.org.au> <4150E7E5.2000001@eurodev.net> <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096340772.8659.51.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 23:06:12 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1227 Lines: 42 On Mon, 2004-09-27 at 22:46, Herbert Xu wrote: > On Mon, Sep 27, 2004 at 10:43:27PM -0400, jamal wrote: > > On Mon, 2004-09-27 at 17:36, Herbert Xu wrote: > > > > > You still haven't told me what you're going to use 3) for yet... > > > > Sorry, keep forgetting to retrieve it from other remote non-networked > > test machine. The idea is: > > Create something that generates lots of messages. Make socket buffer > > small (4096 is good nuf) > > No that's not what I meant. What I mean is what is the real-world > scenario where you're going to be doing 3). The real world scenario is just that: Massive events generated from the kernel for example > Only when we know where the messages are coming from and what they > are can we decide on a meaningful method of limiting their rate. Ok, heres a sample testcase i created just now following those same instructions i gave you ;-> --- #!/bin/sh ifconfig dummy0 1.2.1.1 netmask 255.255.255.0 broadcast 1.2.1.255 up ifconfig dummy0:0 1.2.1.1 for ((i = 1 ; i <= $1 ; i++)) do ifconfig dummy0:$i 1.2.1.$i done --- pass 100 to it to create 100 aliases; you may not need to setsock to 4096, but thats what i did. down dummy0:0 and see the overrun. cheers, jamal From herbert@gondor.apana.org.au Mon Sep 27 20:24:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 20:24:11 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S3O1V6003725 for ; Mon, 27 Sep 2004 20:24:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC8aM-0003XO-00; Tue, 28 Sep 2004 13:23:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC8aH-0002gO-00; Tue, 28 Sep 2004 13:23:21 +1000 Date: Tue, 28 Sep 2004 13:23:21 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040928032321.GB10116@gondor.apana.org.au> References: <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096340772.8659.51.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1659 Lines: 50 On Mon, Sep 27, 2004 at 11:06:12PM -0400, jamal wrote: > > Ok, heres a sample testcase i created just now following those same > instructions i gave you ;-> > > --- > #!/bin/sh > > ifconfig dummy0 1.2.1.1 netmask 255.255.255.0 broadcast 1.2.1.255 up > ifconfig dummy0:0 1.2.1.1 > for ((i = 1 ; i <= $1 ; i++)) > do > ifconfig dummy0:$i 1.2.1.$i > done > --- > > pass 100 to it to create 100 aliases; you may not need to setsock to > 4096, but thats what i did. > > down dummy0:0 and see the overrun. But ifconfig doesn't use netlink. So I presume you're referring to some other application that's listening for interface/address/route events. Firstly thanks this is exactly what I've been asking for -- a real world scenario :) Now that we know where the events are coming from and what they are, we can decide on the solution. In this particular case, there is nothing you can do on the sending side. Stopping people from operating on networking objects just because some netlink listener can't keep up isn't going to work. So congestion control is out of the question. That leaves two options AFAICS. The easy way out is to increase the receive buffer size. Of course after a while this is not going to work. The second option which is the one I prefer: If so many events are occuring and you can't keep up, it's time to give up :) So just bite the bullet and reread the system state by issuing dump operations. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Mon Sep 27 20:45:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 20:45:51 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S3jjJx004546 for ; Mon, 27 Sep 2004 20:45:46 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CC8vm-0001NG-J0 for netdev@oss.sgi.com; Mon, 27 Sep 2004 23:45:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CC8vi-0006Ls-Rh; Mon, 27 Sep 2004 23:45:31 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040928032321.GB10116@gondor.apana.org.au> References: <20040922045239.GA19573@gondor.apana.org.au> <1095854920.1047.64.camel@jzny.localdomain> <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096343125.8661.96.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Sep 2004 23:45:25 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1715 Lines: 47 On Mon, 2004-09-27 at 23:23, Herbert Xu wrote: > But ifconfig doesn't use netlink. So I presume you're referring to > some other application that's listening for interface/address/route > events. Thats right. I think you should be able to run ip monitor to see the overrun. > Firstly thanks this is exactly what I've been asking for -- a real > world scenario :) I can assure you theres many more like this;-> My remote app is not this btw. > Now that we know where the events are coming from and what they are, > we can decide on the solution. In this particular case, there is > nothing you can do on the sending side. Stopping people from operating > on networking objects just because some netlink listener can't keep up > isn't going to work. So congestion control is out of the question. fixing the NLM_GOODSIZE issue is a very good first step. Adding congestion control would be harder but not out of question. The hard part is not in the maintaing state part (as the case of dump) its rather how you start getting slowed down (in a broadcast) by one slow (or buggy) app thats also decided its gonna have very low socket buffer sizes. > That leaves two options AFAICS. The easy way out is to increase the > receive buffer size. Of course after a while this is not going to > work. Indeed. It just postpones the overrun. > The second option which is the one I prefer: If so many events are > occuring and you can't keep up, it's time to give up :) > > So just bite the bullet and reread the system state by issuing dump > operations. We may as well choose to document it as being this mostly because of the issue i described above. We shouldnt give up so easily though ;-> cheers, jamal From herbert@gondor.apana.org.au Mon Sep 27 20:47:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 20:48:07 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S3lvlL004924 for ; Mon, 27 Sep 2004 20:47:58 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC8xn-0003eS-00; Tue, 28 Sep 2004 13:47:39 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC8xk-0002lD-00; Tue, 28 Sep 2004 13:47:36 +1000 Date: Tue, 28 Sep 2004 13:47:36 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [NETLINK] Kill export of netlink_broadcast_deliver Message-ID: <20040928034736.GA10589@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1157 Lines: 39 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: netlink_broadcast_deliver is marked as static as well as exported. It certainly isn't doing anything that should be needed by any netlink modules. There aren't any in-kernel users either. So let's remove the bogus export. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/netlink/af_netlink.c 1.53 vs edited ===== --- 1.53/net/netlink/af_netlink.c 2004-09-22 12:32:44 +10:00 +++ edited/net/netlink/af_netlink.c 2004-09-28 13:45:28 +10:00 @@ -1220,7 +1220,6 @@ EXPORT_SYMBOL(netlink_ack); EXPORT_SYMBOL(netlink_broadcast); -EXPORT_SYMBOL(netlink_broadcast_deliver); EXPORT_SYMBOL(netlink_dump_start); EXPORT_SYMBOL(netlink_kernel_create); EXPORT_SYMBOL(netlink_register_notifier); --4Ckj6UjgE2iN1+kY-- From rddunlap@osdl.org Mon Sep 27 20:57:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 20:57:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S3vJHO005499 for ; Mon, 27 Sep 2004 20:57:20 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i8S3uqv10358; Mon, 27 Sep 2004 20:56:52 -0700 Date: Mon, 27 Sep 2004 20:54:53 -0700 From: "Randy.Dunlap" To: Cc: jgarzik@pobox.com, netdev@oss.sgi.com, leonid.grossman@s2io.com, raghavendra.koushik@s2io.com, rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel Message-Id: <20040927205453.79f9628f.rddunlap@osdl.org> In-Reply-To: <005801c4a4f4$1598d6d0$a010100a@S2IOtech.com> References: <414A3562.2090803@pobox.com> <005801c4a4f4$1598d6d0$a010100a@S2IOtech.com> Organization: OSDL X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 2426 Lines: 65 On Mon, 27 Sep 2004 17:42:51 -0700 Ravinandan Arakali wrote: | Hi, | Attached are the updated patches. It is designed to work on the latest | kernel. Also, this time the submission is split to 3 patches(they need | to applied in the order mentioned below). | | s2io_styling_level1 - Contains | a. styling related, function name changes. | b. fix for 32-bit systems. | c. modified Transmit descriptor allocation | strategy. | d. miscellaneous fixes. | with_napi_level2 - Fixes/tunes NAPI feature | with_2buff_level3 - Adds support for 2-buffer mode. | | Please review and get back with your comments. The focused nature of the NAPI and 2BUFF patches are good IMO. It would be very helpful if the styling patch had all comments/whitespace/style changes split out from it (maybe 3000 of the 4000 lines of the patch). Then we (reviewers) could spend time focusing on the important parts of your patches, and the styling patch could go with some lighter review. I'd like to help Jeff with some review here, but it's become too painful & time-consuming for me to wade thru the patches looking for the more-important parts of such a large patch, so I'll have to leave it to Jeff and other netdev regulars. | Thanks, | Ravi | | -----Original Message----- | From: Jeff Garzik [mailto:jgarzik@pobox.com] | Sent: Thursday, September 16, 2004 5:53 PM | To: ravinandan.arakali@s2io.com | Cc: netdev@oss.sgi.com; leonid.grossman@s2io.com; | raghavendra.koushik@s2io.com; rapuru.sriram@s2io.com | Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel | | | Ravinandan Arakali wrote: | > Jeff, | > We tried it out with 2.6.7. Can you pls specify the kernel version | > on which you tried and we will send a patch which works for that version. | > We will also send a more detailed description of the changes along with | > that. | | | Always diff against the latest version of the kernel. You can find out | the latest version by going to http://www.kernel.org/ You'll typically | want the latest snapshot (preferably), or the latest pre-patch. | | Standard patch submission format is described at | http://linux.yyz.us/patch-format.html and in | Documentation/SubmittingPatches. | | When submitting a series of patches, it is normal patches to depend on | preceding patches. -- ~Randy From herbert@gondor.apana.org.au Mon Sep 27 20:59:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 21:00:05 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S3xtOG005886 for ; Mon, 27 Sep 2004 20:59:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CC99F-0003iL-00; Tue, 28 Sep 2004 13:59:29 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CC997-0002my-00; Tue, 28 Sep 2004 13:59:21 +1000 Date: Tue, 28 Sep 2004 13:59:21 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040928035921.GA10675@gondor.apana.org.au> References: <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096343125.8661.96.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1934 Lines: 44 On Mon, Sep 27, 2004 at 11:45:25PM -0400, jamal wrote: > > > Now that we know where the events are coming from and what they are, > > we can decide on the solution. In this particular case, there is > > nothing you can do on the sending side. Stopping people from operating > > on networking objects just because some netlink listener can't keep up > > isn't going to work. So congestion control is out of the question. > > fixing the NLM_GOODSIZE issue is a very good first step. Well I'm afraid that it doesn't help in your interface address example because rtmsg_ifa() already allocates a buffer of (approximately) the right size. That is, it doesn't use NLM_GOODSIZE at all. > Adding congestion control would be harder but not out of question. But the question is who are you going to throttle? If you throttle the source of the messages then you're going to stop people from adding or deleting IP addresses which can't be right. If you move the netlink sender into a different execution context and throttle that then that's just extending the receive queue length by stealth. So I'm afraid I don't see how congestion control could be applied in *this* particular context. > > So just bite the bullet and reread the system state by issuing dump > > operations. > > We may as well choose to document it as being this mostly because of the > issue i described above. We shouldnt give up so easily though ;-> Well IMHO this is not giving up at all. Think of it another way. Monitoring routes is like maintaining a program. Normally you just fix the bugs as they come. But if the bug reports are coming in so fast that you can't keep up, perhaps it's time to throw it away and rewrite it from scratch :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From roland@topspin.com Mon Sep 27 21:41:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 21:41:30 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S4fPJE007139 for ; Mon, 27 Sep 2004 21:41:25 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Sep 2004 21:41:13 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Sep 2004 21:41:13 -0700 Received: from roland by eddore with local (Exim 4.34) id 1CC9nc-0004h2-Nf; Mon, 27 Sep 2004 21:41:13 -0700 To: "David S. Miller" Cc: netdev@oss.sgi.com X-Message-Flag: Warning: May contain useful information References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> From: Roland Dreier Date: Mon, 27 Sep 2004 21:41:12 -0700 In-Reply-To: <20040919140133.60ea3fb3.davem@davemloft.net> (David S. Miller's message of "Sun, 19 Sep 2004 14:01:33 -0700") Message-ID: <52r7onc8ev.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 28 Sep 2004 04:41:13.0195 (UTC) FILETIME=[62197BB0:01C4A515] X-archive-position: 9569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 1870 Lines: 41 I've been mulling over the previous advice I got and reading over the networking code, and I hope I have some more intelligent questions now. It seems I really have two somewhat independent issues to resolve with respect to IP-over-IB address resolution: - IPoIB adds a second InfiniBand-specific path record lookup after the normal ARP/ND lookup. I think I have a handle on how this can be added to net/ipv4/arp.c. - For InfiniBand, the layer 2 header is built and parsed by the hardware without a chance for software to see it. In fact, once we have completed the 2 stage resolution as described above, the network driver has to pass this path information to the IB hardware and get an "address handle" back, which it uses to actually send packets. It seems the existing hard_header, hard_header_cache and header_cache_update are not really applicable. My ideal solution would be some way for the driver have the packets passed to its hard_start_xmit method with the address handle in the skb->cb field (or another field if it's acceptable/desirable to add a field for this to struct sk_buff -- I notice a number of #ifdef'ed fields in there already, but I'm not sure if that type of thing is just old cruft or still OK). Also it would be nice is that address handle could be taken directly from the struct neighbor -- after all, we should be able to get it without requiring the driver to do any lookup from HW address to address handle. Finally, address handles need to be freed eventually, and I don't see a way for a driver to find out when an ARP entry is being destroyed. Am I missing something, or is this something else I'll need to add? What would be an acceptable way to add this to the networking code? I'd really appreciate another dose of cluestick... Thanks, Roland From davem@davemloft.net Mon Sep 27 21:53:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 21:53:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S4r2tY007772 for ; Mon, 27 Sep 2004 21:53:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CC9ym-0000dq-00; Mon, 27 Sep 2004 21:52:44 -0700 Date: Mon, 27 Sep 2004 21:52:44 -0700 From: "David S. Miller" To: Roland Dreier Cc: netdev@oss.sgi.com Subject: Re: Advice needed on IP-over-InfiniBand driver Message-Id: <20040927215244.697aaa02.davem@davemloft.net> In-Reply-To: <52r7onc8ev.fsf@topspin.com> References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <52r7onc8ev.fsf@topspin.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 713 Lines: 17 On Mon, 27 Sep 2004 21:41:12 -0700 Roland Dreier wrote: > I've been mulling over the previous advice I got and reading over the > networking code, and I hope I have some more intelligent questions > now. It seems I really have two somewhat independent issues to > resolve with respect to IP-over-IB address resolution: > > - IPoIB adds a second InfiniBand-specific path record lookup after > the normal ARP/ND lookup. I think I have a handle on how this can > be added to net/ipv4/arp.c. I think you might learn something by having a look at what net/atm/clip.c is doing, it creates it's own neighbour layer for CLIP ATM neighbours. It is in a similar boat to your IPoIB stuff. From davem@davemloft.net Mon Sep 27 22:00:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 22:00:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S500JT008226 for ; Mon, 27 Sep 2004 22:00:00 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCA4r-0000eZ-00; Mon, 27 Sep 2004 21:59:01 -0700 Date: Mon, 27 Sep 2004 21:59:01 -0700 From: "David S. Miller" To: Herbert Xu Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927215901.6f65dc15.davem@davemloft.net> In-Reply-To: <20040928003412.GA8755@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> <20040928003412.GA8755@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 9640 Lines: 309 On Tue, 28 Sep 2004 10:34:12 +1000 Herbert Xu wrote: > Yes this looks very good. It's got a nasty bug though, I'm not updating TCP_SKB_CB(skb)->seq so retransmits have corrupted sequence numbers, doh! And hey if I update that then I do not need this tso_offset thingy. > > +static int tcp_tso_acked(struct tcp_opt *tp, struct sk_buff *skb, > > + __u32 now, __s32 *seq_rtt) > > +{ > > + struct tcp_skb_cb *scb = TCP_SKB_CB(skb); > > + __u32 tso_seq = scb->seq + scb->tso_offset; > > + __u32 mss = tp->mss_cache_std; > > In future we should probably record the MSS in the scb just in case > it changes. Fixed in my updated patch below, the above bug made me consider this exact issue. > > - if (after(scb->end_seq, tp->snd_una)) > > + if (after(scb->end_seq, tp->snd_una)) { > > + if (scb->tso_factor) > > tso_factor > 1 Good catch, fixed below as well. > > TCP_SKB_CB(skb)->tso_factor = 1; > > + TCP_SKB_CB(skb)->tso_offset = 1; > > Is this a clever trick that I don't understand? :) What a dumb bug, also fixed below. This should do it for RTX queue purging and congestion window growth. Next I'll work on the other issues. In particular: 1) Moving TSO mss calculations to tcp_current_mss() as you suggested. Also integrating the 'large' usage bug fixes you sent a patch for earlier. I'm making this thing non-inline too, it gets expanded a lot. 2) The tcp_init_metrics() consistency fix you made. 3) Consider limiting 'factor' such as jheffner and myself have suggested over the past few days. It might not be necessary, I'll do some tests. Note the trick below wrt. adjusting the SKB data area lazily. I defer it to tcp_retransmit_skb() otherwise we copy the data area around in the packet several times, and that would undo the gain of zerocopy + TSO wouldn't it? :-) I mention that we might want mess with skb->truesize and liberate space from sk->sk_wmem_alloc... but on further reflection that might not really gain us anything. We'll make less work for the process by waking up only on full TSO packet liberation. Please scream loudly if you can find a bug in this current patch. ===== include/net/tcp.h 1.89 vs edited ===== --- 1.89/include/net/tcp.h 2004-09-27 11:57:52 -07:00 +++ edited/include/net/tcp.h 2004-09-27 18:02:21 -07:00 @@ -1180,7 +1180,8 @@ __u16 urg_ptr; /* Valid w/URG flags is set. */ __u32 ack_seq; /* Sequence number ACK'd */ - __u32 tso_factor; + __u16 tso_factor; /* If > 1, TSO frame */ + __u16 tso_mss; /* MSS that FACTOR's in terms of*/ }; #define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0])) ===== net/ipv4/tcp_input.c 1.75 vs edited ===== --- 1.75/net/ipv4/tcp_input.c 2004-09-27 12:00:32 -07:00 +++ edited/net/ipv4/tcp_input.c 2004-09-27 21:27:08 -07:00 @@ -2355,6 +2355,86 @@ } } +/* There is one downside to this scheme. Although we keep the + * ACK clock ticking, adjusting packet counters and advancing + * congestion window, we do not liberate socket send buffer + * space. + * + * Mucking with skb->truesize and sk->sk_wmem_alloc et al. + * then making a write space wakeup callback is a possible + * future enhancement. WARNING: it is not trivial to make. + */ +static int tcp_tso_acked(struct tcp_opt *tp, struct sk_buff *skb, + __u32 now, __s32 *seq_rtt) +{ + struct tcp_skb_cb *scb = TCP_SKB_CB(skb); + __u32 mss = scb->tso_mss; + __u32 snd_una = tp->snd_una; + __u32 seq = scb->seq; + __u32 packets_acked = 0; + int acked = 0; + + /* If we get here, the whole TSO packet has not been + * acked. + */ + BUG_ON(!after(scb->end_seq, snd_una)); + + while (!after(seq + mss, snd_una)) { + packets_acked++; + seq += mss; + } + + if (packets_acked) { + __u8 sacked = scb->sacked; + + /* We adjust scb->seq but we do not pskb_pull() the + * SKB. We let tcp_retransmit_skb() handle this case + * by checking skb->len against the data sequence span. + * This way, we avoid the pskb_pull() work unless we + * actually need to retransmit the SKB. + */ + scb->seq = seq; + + acked |= FLAG_DATA_ACKED; + if (sacked) { + if (sacked & TCPCB_RETRANS) { + if (sacked & TCPCB_SACKED_RETRANS) + tcp_dec_pcount_explicit(&tp->retrans_out, + packets_acked); + acked |= FLAG_RETRANS_DATA_ACKED; + *seq_rtt = -1; + } else if (*seq_rtt < 0) + *seq_rtt = now - scb->when; + if (sacked & TCPCB_SACKED_ACKED) + tcp_dec_pcount_explicit(&tp->sacked_out, + packets_acked); + if (sacked & TCPCB_LOST) + tcp_dec_pcount_explicit(&tp->lost_out, + packets_acked); + if (sacked & TCPCB_URG) { + if (tp->urg_mode && + !before(scb->seq, tp->snd_up)) + tp->urg_mode = 0; + } + } else if (*seq_rtt < 0) + *seq_rtt = now - scb->when; + + if (tcp_get_pcount(&tp->fackets_out)) { + __u32 dval = min(tcp_get_pcount(&tp->fackets_out), + packets_acked); + tcp_dec_pcount_explicit(&tp->fackets_out, dval); + } + tcp_dec_pcount_explicit(&tp->packets_out, packets_acked); + scb->tso_factor -= packets_acked; + + BUG_ON(scb->tso_factor == 0); + BUG_ON(!before(scb->seq, scb->end_seq)); + } + + return acked; +} + + /* Remove acknowledged frames from the retransmission queue. */ static int tcp_clean_rtx_queue(struct sock *sk, __s32 *seq_rtt_p) { @@ -2373,8 +2453,12 @@ * discard it as it's confirmed to have arrived at * the other end. */ - if (after(scb->end_seq, tp->snd_una)) + if (after(scb->end_seq, tp->snd_una)) { + if (scb->tso_factor > 1) + acked |= tcp_tso_acked(tp, skb, + now, &seq_rtt); break; + } /* Initial outgoing SYN's get put onto the write_queue * just like anything else we transmit. It is not ===== net/ipv4/tcp_output.c 1.59 vs edited ===== --- 1.59/net/ipv4/tcp_output.c 2004-09-27 11:57:52 -07:00 +++ edited/net/ipv4/tcp_output.c 2004-09-27 21:27:50 -07:00 @@ -436,6 +436,7 @@ factor /= mss_std; TCP_SKB_CB(skb)->tso_factor = factor; } + TCP_SKB_CB(skb)->tso_mss = mss_std; } /* Function to create two new TCP segments. Shrinks the given segment @@ -552,7 +553,7 @@ return skb->tail; } -static int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) +static int __tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) { if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) @@ -565,11 +566,20 @@ return -ENOMEM; } - TCP_SKB_CB(skb)->seq += len; skb->ip_summed = CHECKSUM_HW; return 0; } +static inline int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) +{ + int err = __tcp_trim_head(sk, skb, len); + + if (!err) + TCP_SKB_CB(skb)->seq += len; + + return err; +} + /* This function synchronize snd mss to current pmtu/exthdr set. tp->user_mss is mss set by user by TCP_MAXSEG. It does NOT counts @@ -949,6 +959,7 @@ { struct tcp_opt *tp = tcp_sk(sk); unsigned int cur_mss = tcp_current_mss(sk, 0); + __u32 data_seq, data_end_seq; int err; /* Do not sent more than we queued. 1/4 is reserved for possible @@ -958,6 +969,22 @@ min(sk->sk_wmem_queued + (sk->sk_wmem_queued >> 2), sk->sk_sndbuf)) return -EAGAIN; + /* What is going on here? When TSO packets are partially ACK'd, + * we adjust the TCP_SKB_CB(skb)->seq value forward but we do + * not adjust the data area of the SKB. We defer that to here + * so that we can avoid the work unless we really retransmit + * the packet. + */ + data_seq = TCP_SKB_CB(skb)->seq; + data_end_seq = TCP_SKB_CB(skb)->end_seq; + if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + data_end_seq--; + + if (skb->len != (data_end_seq - data_seq)) { + if (__tcp_trim_head(sk, skb, data_end_seq - data_seq)) + return -ENOMEM; + } + if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) { if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) BUG(); @@ -1191,6 +1218,7 @@ TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_FIN); TCP_SKB_CB(skb)->sacked = 0; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; /* FIN eats a sequence byte, write_seq advanced by tcp_queue_skb(). */ TCP_SKB_CB(skb)->seq = tp->write_seq; @@ -1223,6 +1251,7 @@ TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_RST); TCP_SKB_CB(skb)->sacked = 0; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; /* Send it off. */ TCP_SKB_CB(skb)->seq = tcp_acceptable_seq(sk, tp); @@ -1304,6 +1333,7 @@ TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(skb)->seq + 1; TCP_SKB_CB(skb)->sacked = 0; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; th->seq = htonl(TCP_SKB_CB(skb)->seq); th->ack_seq = htonl(req->rcv_isn + 1); if (req->rcv_wnd == 0) { /* ignored for retransmitted syns */ @@ -1406,6 +1436,7 @@ TCP_ECN_send_syn(sk, tp, buff); TCP_SKB_CB(buff)->sacked = 0; TCP_SKB_CB(buff)->tso_factor = 1; + TCP_SKB_CB(buff)->tso_mss = tp->mss_cache_std; buff->csum = 0; TCP_SKB_CB(buff)->seq = tp->write_seq++; TCP_SKB_CB(buff)->end_seq = tp->write_seq; @@ -1506,6 +1537,7 @@ TCP_SKB_CB(buff)->flags = TCPCB_FLAG_ACK; TCP_SKB_CB(buff)->sacked = 0; TCP_SKB_CB(buff)->tso_factor = 1; + TCP_SKB_CB(buff)->tso_mss = tp->mss_cache_std; /* Send it off, this clears delayed acks for us. */ TCP_SKB_CB(buff)->seq = TCP_SKB_CB(buff)->end_seq = tcp_acceptable_seq(sk, tp); @@ -1541,6 +1573,7 @@ TCP_SKB_CB(skb)->flags = TCPCB_FLAG_ACK; TCP_SKB_CB(skb)->sacked = urgent; TCP_SKB_CB(skb)->tso_factor = 1; + TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; /* Use a previous sequence. This should cause the other * end to send an ack. Don't queue or clone SKB, just From herbert@gondor.apana.org.au Mon Sep 27 22:16:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 22:17:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S5GiQE008905 for ; Mon, 27 Sep 2004 22:16:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCAL8-000468-00; Tue, 28 Sep 2004 15:15:50 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCAKx-0002xX-00; Tue, 28 Sep 2004 15:15:39 +1000 Date: Tue, 28 Sep 2004 15:15:39 +1000 To: "David S. Miller" Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040928051539.GA11354@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> <20040928003412.GA8755@gondor.apana.org.au> <20040927215901.6f65dc15.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927215901.6f65dc15.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 740 Lines: 25 On Mon, Sep 27, 2004 at 09:59:01PM -0700, David S. Miller wrote: > > It's got a nasty bug though, I'm not updating > TCP_SKB_CB(skb)->seq so retransmits have corrupted > sequence numbers, doh! And hey if I update that > then I do not need this tso_offset thingy. Nice work. > + if (skb->len != (data_end_seq - data_seq)) { Please make that > so that I can sleep at night :) > + if (__tcp_trim_head(sk, skb, data_end_seq - data_seq)) The argument to __tcp_trim_head should be skb->len - (data_end_seq - data_seq) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon Sep 27 22:17:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 22:17:36 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S5HVBp009077 for ; Mon, 27 Sep 2004 22:17:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCAML-0000fv-00; Mon, 27 Sep 2004 22:17:05 -0700 Date: Mon, 27 Sep 2004 22:17:05 -0700 From: "David S. Miller" To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] neighbour cache statistics like rt_stat Message-Id: <20040927221705.53a629d1.davem@davemloft.net> In-Reply-To: <20040927222055.GD3236@sunbeam.de.gnumonks.org> References: <20040927093613.GH3236@sunbeam.de.gnumonks.org> <20040927162334.GV3236@sunbeam.de.gnumonks.org> <20040927122136.7016b2c1.davem@davemloft.net> <20040927222055.GD3236@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 420 Lines: 13 On Tue, 28 Sep 2004 00:20:55 +0200 Harald Welte wrote: > On Mon, Sep 27, 2004 at 12:21:36PM -0700, David S. Miller wrote: > > > 1) Please update the patch since I replaced "diff4" with > > a patch simply removing the INCOMPLETE checks from neigh_forced_gc() > > > > 2) I'd recommend using unsigned long for all the statistics. > > both updated in attached version. Applied, thanks Harald. From davem@davemloft.net Mon Sep 27 22:28:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 22:28:38 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S5SX4x009698 for ; Mon, 27 Sep 2004 22:28:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCAX0-0000id-00; Mon, 27 Sep 2004 22:28:06 -0700 Date: Mon, 27 Sep 2004 22:28:06 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] Kill export of netlink_broadcast_deliver Message-Id: <20040927222806.17277cf3.davem@davemloft.net> In-Reply-To: <20040928034736.GA10589@gondor.apana.org.au> References: <20040928034736.GA10589@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 344 Lines: 10 On Tue, 28 Sep 2004 13:47:36 +1000 Herbert Xu wrote: > netlink_broadcast_deliver is marked as static as well as exported. > It certainly isn't doing anything that should be needed by any > netlink modules. There aren't any in-kernel users either. > > So let's remove the bogus export. Applied, thanks Herbert. From davem@davemloft.net Mon Sep 27 22:59:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 22:59:37 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S5xWnK010543 for ; Mon, 27 Sep 2004 22:59:32 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCB0s-0000ko-00; Mon, 27 Sep 2004 22:58:58 -0700 Date: Mon, 27 Sep 2004 22:58:58 -0700 From: "David S. Miller" To: Herbert Xu Cc: shemminger@osdl.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] (1/3) tcp - choose congestion algorithm at initialization Message-Id: <20040927225858.3a1665f1.davem@davemloft.net> In-Reply-To: References: <20040927111834.48c7baab@zqx3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 539 Lines: 14 On Tue, 28 Sep 2004 08:07:36 +1000 Herbert Xu wrote: > Stephen Hemminger wrote: > > The choice of congestion algorithm needs to be made when connection > > is setup to avoid problems when the sysctl values change later and the > > necessary data hasn't been collected. > > Could this be chosen by a setsockopt as well? If we export such things with a user visible interface, that makes it harder to rip out the congestion control algorithm later. Such an action is very likely so... From davem@davemloft.net Mon Sep 27 22:58:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 22:59:05 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S5ws1q010441 for ; Mon, 27 Sep 2004 22:58:55 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCB0F-0000kZ-00; Mon, 27 Sep 2004 22:58:19 -0700 Date: Mon, 27 Sep 2004 22:58:19 -0700 From: "David S. Miller" To: Herbert Xu Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040927225819.5cf9ade9.davem@davemloft.net> In-Reply-To: <20040928051539.GA11354@gondor.apana.org.au> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> <20040928003412.GA8755@gondor.apana.org.au> <20040927215901.6f65dc15.davem@davemloft.net> <20040928051539.GA11354@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1343 Lines: 45 On Tue, 28 Sep 2004 15:15:39 +1000 Herbert Xu wrote: > > + if (skb->len != (data_end_seq - data_seq)) { > > Please make that > so that I can sleep at night :) > > > + if (__tcp_trim_head(sk, skb, data_end_seq - data_seq)) > > The argument to __tcp_trim_head should be > > skb->len - (data_end_seq - data_seq) Good catch, fixed as follows: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/27 22:37:27-07:00 davem@nuts.davemloft.net # [TCP]: Fix third arg to __tcp_trim_head(). # # Noted by Herbert Xu # # Signed-off-by: David S. Miller # # net/ipv4/tcp_output.c # 2004/09/27 22:36:41-07:00 davem@nuts.davemloft.net +4 -2 # [TCP]: Fix third arg to __tcp_trim_head(). # diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-27 22:37:55 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-27 22:37:55 -07:00 @@ -980,8 +980,10 @@ if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) data_end_seq--; - if (skb->len != (data_end_seq - data_seq)) { - if (__tcp_trim_head(sk, skb, data_end_seq - data_seq)) + if (skb->len > (data_end_seq - data_seq)) { + u32 to_trim = skb->len - (data_end_seq - data_seq); + + if (__tcp_trim_head(sk, skb, to_trim)) return -ENOMEM; } From yoshfuji@linux-ipv6.org Mon Sep 27 23:23:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 23:23:13 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S6N6Sm012995 for ; Mon, 27 Sep 2004 23:23:07 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 4F9FE33CE7; Tue, 28 Sep 2004 15:23:12 +0900 (JST) Date: Tue, 28 Sep 2004 15:23:06 +0900 (JST) Message-Id: <20040928.152306.74843215.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [BK PATCH 2.6] IPV6 Fixes From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2766 Lines: 97 Hello. Please pull following changesets from Thanks. HEADLINES --------- ChangeSet@1.1995, 2004-09-28 11:25:48+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix routing header handling. ChangeSet@1.1996, 2004-09-28 13:55:20+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix skb allocation size for RST and ACK. CHANGESETS ---------- ChangeSet@1.1995, 2004-09-28 11:25:48+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix routing header handling. We need to rewind skb pointers when we forward a packet to other host because dst_input() assumes that skb->data points head of ipv6 protocol header. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c --- a/net/ipv6/exthdrs.c 2004-09-28 14:28:37 +09:00 +++ b/net/ipv6/exthdrs.c 2004-09-28 14:28:37 +09:00 @@ -314,9 +314,11 @@ dst_release(xchg(&skb->dst, NULL)); ip6_route_input(skb); if (skb->dst->error) { + skb_push(skb, skb->data - skb->nh.raw); dst_input(skb); return -1; } + if (skb->dst->dev->flags&IFF_LOOPBACK) { if (skb->nh.ipv6h->hop_limit <= 1) { IP6_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS); @@ -329,6 +331,7 @@ goto looped_back; } + skb_push(skb, skb->data - skb->nh.raw); dst_input(skb); return -1; } ChangeSet@1.1996, 2004-09-28 13:55:20+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix skb allocation size for RST and ACK. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c 2004-09-28 14:28:41 +09:00 +++ b/net/ipv6/tcp_ipv6.c 2004-09-28 14:28:41 +09:00 @@ -1003,11 +1003,12 @@ * and then put it into the queue to be sent. */ - buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr), GFP_ATOMIC); + buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr) + sizeof(struct tcphdr), + GFP_ATOMIC); if (buff == NULL) return; - skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr)); + skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr) + sizeof(struct tcphdr)); t1 = (struct tcphdr *) skb_push(buff,sizeof(struct tcphdr)); @@ -1065,14 +1066,15 @@ struct flowi fl; int tot_len = sizeof(struct tcphdr); - buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr), GFP_ATOMIC); + if (ts) + tot_len += 3*4; + + buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr) + tot_len, + GFP_ATOMIC); if (buff == NULL) return; - skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr)); - - if (ts) - tot_len += 3*4; + skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr) + tot_len); t1 = (struct tcphdr *) skb_push(buff,tot_len); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Mon Sep 27 23:24:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 23:24:44 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S6OdTQ013346 for ; Mon, 27 Sep 2004 23:24:40 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id EA18433CE7; Tue, 28 Sep 2004 15:24:45 +0900 (JST) Date: Tue, 28 Sep 2004 15:24:40 +0900 (JST) Message-Id: <20040928.152440.97383178.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [BK PATCH 2.4] IPV6 Fixes From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2781 Lines: 95 Hello. Please pull following changesets from Thanks. HEADLINES --------- ChangeSet@1.1568, 2004-09-28 12:52:40+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix routing header handling. ChangeSet@1.1569, 2004-09-28 13:04:31+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix skb allocation size for RST and ACK. CHANGESETS ---------- ChangeSet@1.1568, 2004-09-28 12:52:40+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix routing header handling. We need to rewind skb pointers when we forward a packet to other host because dst_input() assumes that skb->data points head of ipv6 protocol header. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c --- a/net/ipv6/exthdrs.c 2004-09-28 13:24:48 +09:00 +++ b/net/ipv6/exthdrs.c 2004-09-28 13:24:48 +09:00 @@ -293,9 +293,11 @@ dst_release(xchg(&skb->dst, NULL)); ip6_route_input(skb); if (skb->dst->error) { + skb_push(skb, skb->data - skb->nh.raw); skb->dst->input(skb); return -1; } + if (skb->dst->dev->flags&IFF_LOOPBACK) { if (skb->nh.ipv6h->hop_limit <= 1) { icmpv6_send(skb, ICMPV6_TIME_EXCEED, ICMPV6_EXC_HOPLIMIT, @@ -307,6 +309,7 @@ goto looped_back; } + skb_push(skb, skb->data - skb->nh.raw); skb->dst->input(skb); return -1; } ChangeSet@1.1569, 2004-09-28 13:04:31+09:00, yoshfuji@linux-ipv6.org [IPV6] Fix skb allocation size for RST and ACK. Signed-off-by: Hideaki YOSHIFUJI diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c 2004-09-28 13:24:49 +09:00 +++ b/net/ipv6/tcp_ipv6.c 2004-09-28 13:24:49 +09:00 @@ -978,11 +978,11 @@ * and then put it into the queue to be sent. */ - buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr), GFP_ATOMIC); + buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr) + sizeof(struct tcphdr), GFP_ATOMIC); if (buff == NULL) return; - skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr)); + skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr) + sizeof(struct tcphdr)); t1 = (struct tcphdr *) skb_push(buff,sizeof(struct tcphdr)); @@ -1037,14 +1037,14 @@ struct flowi fl; int tot_len = sizeof(struct tcphdr); - buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr), GFP_ATOMIC); + if (ts) + tot_len += 3*4; + + buff = alloc_skb(MAX_HEADER + sizeof(struct ipv6hdr) + tot_len, GFP_ATOMIC); if (buff == NULL) return; - skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr)); - - if (ts) - tot_len += 3*4; + skb_reserve(buff, MAX_HEADER + sizeof(struct ipv6hdr) + tot_len); t1 = (struct tcphdr *) skb_push(buff,tot_len); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From niv@us.ibm.com Mon Sep 27 23:46:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 27 Sep 2004 23:46:24 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S6kAxC014095 for ; Mon, 27 Sep 2004 23:46:17 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (rwcrmhc13) with ESMTP id <20040928064550015008sbsbe>; Tue, 28 Sep 2004 06:45:51 +0000 Message-ID: <41590898.3060900@us.ibm.com> Date: Mon, 27 Sep 2004 23:45:44 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , jheffner@psc.edu, ak@suse.de, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> <20040928003412.GA8755@gondor.apana.org.au> <20040927215901.6f65dc15.davem@davemloft.net> In-Reply-To: <20040927215901.6f65dc15.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 577 Lines: 18 David S. Miller wrote: > It's got a nasty bug though, I'm not updating > TCP_SKB_CB(skb)->seq so retransmits have corrupted > sequence numbers, doh! And hey if I update that > then I do not need this tso_offset thingy. Hmm, I got sidetracked by seeing corrupted sequence numbers in my tcpdump traces from before, although that shouldn't have been the case..(sorry, don't have access to boxes at the moment, will post it tmrw). Was seeing the sequence numbers go backwards (simple scp testing, bk10).. Will redo testing in the morning on latest patches... thanks, Nivedita From niv@us.ibm.com Tue Sep 28 00:21:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 00:21:27 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S7LG9G018215 for ; Tue, 28 Sep 2004 00:21:22 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (sccrmhc12) with ESMTP id <2004092807205701200ql1pue>; Tue, 28 Sep 2004 07:20:59 +0000 Message-ID: <415910D2.7010808@us.ibm.com> Date: Tue, 28 Sep 2004 00:20:50 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , jheffner@psc.edu, ak@suse.de, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> In-Reply-To: <20040927171356.6a59d039.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 429 Lines: 16 David S. Miller wrote: > Bright minds think alike. :-) We have to keep all the other > packet counts in sync as well. > > Andi, others, forget my previous hack patch to tcp_clean_rtx_queue() > and give this more complete patch a try. > > I'm getting really good results here on my tg3<-->tg3 setup using > this patch. Dave, were you seeing a significant number of retransmissions and sacks in your tests? thanks, Nivedita From niv@us.ibm.com Tue Sep 28 00:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 00:24:08 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S7O1Hb018598 for ; Tue, 28 Sep 2004 00:24:02 -0700 Received: from [192.168.1.3] (c-67-171-167-143.client.comcast.net[67.171.167.143]) by comcast.net (sccrmhc12) with ESMTP id <2004092807234401200qncpte>; Tue, 28 Sep 2004 07:23:45 +0000 Message-ID: <4159117A.4010904@us.ibm.com> Date: Tue, 28 Sep 2004 00:23:38 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Heffner CC: "David S. Miller" , Andi Kleen , andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1946 Lines: 56 John Heffner wrote: > On Thu, 23 Sep 2004, David S. Miller wrote: > > >>I think I know what may be going on here. >> >>Let's say that we even get the congestion window openned up >>so that we can build 64K TSO frames, that's around 43 or 44 >>1500 mtu frames. >> >>That means as the window fills up, we have to see 44 ACKs >>before we are able to send the next TSO frame. Needless to >>say that breaks ACK clocking completely. > > > > More specifically, I think it is an interaction with delayed ack (acking > less than 1 virtual segment), and the small cwnd. This works for me, but > I'm not sure that aren't some lurking problems still. In terms of what goes out over the wire from the sender, there is (or should be) no difference between the TSO and non-TSO case. The sequence of regular sized packets should be the same, and the only difference might be the delays between the frames, at most. So the sequence of acks coming back from the receiver should be the same, TSO and non-TSO case. If we've sent out say 44 1500MTU frames, we should probably see 22 acks back, roughly (acking every second packet if delayed acks are on) in both the TSO and non-TSO case. In terms of overall throughput, assuming we were doing no other work other than this connection, we would see a gain in the TSO case only if by the time the congestion window opened fully for us to send another virtual MTU frame, the application had written another frame's worth of data (minus the extra delta that would take for driver handoff and send at that point). In the non-TSO case, the finer granularity is helping us to utilize the channel more efficiently, (although not the path down the stack or the CPU).. actually, I think - although that is just another way to say ack clocking is bumpy. But I guess my question is - don't we need some heuristics to figure out when we should send partial (i.e. abandoning waiting for full TSO)? thanks, Nivedita From buytenh@wantstofly.org Tue Sep 28 01:12:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 01:13:07 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S8CtdN019824 for ; Tue, 28 Sep 2004 01:12:56 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id E8A952B0EE; Tue, 28 Sep 2004 10:12:42 +0200 (MEST) Date: Tue, 28 Sep 2004 10:12:42 +0200 From: Lennert Buytenhek To: Harald Welte Cc: netdev@oss.sgi.com Subject: Re: recommendations for NIC HW(/SW) design? Message-ID: <20040928081242.GB6886@xi.wantstofly.org> References: <20040926152955.GD17043@xi.wantstofly.org> <20040927155144.GU3236@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927155144.GU3236@sunbeam.de.gnumonks.org> User-Agent: Mutt/1.4.1i X-archive-position: 9582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 424 Lines: 13 On Mon, Sep 27, 2004 at 05:51:44PM +0200, Harald Welte wrote: > > (Since the Intel IXP processor is just an ARM processor with a network > > interface grafted onto the chip, a bunch of things that apply to PCI > > NIC design might not apply here.) > > I think this IXP is only a UP architecture, is it? Yeah, it's a single-core ARM with a big fat pipe (either 4 or 10 Gb/s depending on model) grafted onto the CPU. --L From herbert@gondor.apana.org.au Tue Sep 28 01:24:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 01:24:42 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S8OQqn026262 for ; Tue, 28 Sep 2004 01:24:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCDGo-00057B-00; Tue, 28 Sep 2004 18:23:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCDGd-0003HW-00; Tue, 28 Sep 2004 18:23:23 +1000 From: Herbert Xu To: niv@us.ibm.com (Nivedita Singhvi) Subject: Re: bad TSO performance in 2.6.9-rc2-BK Cc: jheffner@psc.edu, davem@davemloft.net, ak@suse.de, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Organization: Core In-Reply-To: <4159117A.4010904@us.ibm.com> X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Tue, 28 Sep 2004 18:23:23 +1000 X-archive-position: 9583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 447 Lines: 12 Nivedita Singhvi wrote: > > But I guess my question is - don't we need some > heuristics to figure out when we should send partial > (i.e. abandoning waiting for full TSO)? Currently we're relying on Nagle to do that. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From Robert.Olsson@data.slu.se Tue Sep 28 01:45:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 01:45:26 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S8jJhs006520 for ; Tue, 28 Sep 2004 01:45:21 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8S8iUY2002475; Tue, 28 Sep 2004 10:44:30 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 2811D90265; Tue, 28 Sep 2004 10:44:30 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16729.9326.93269.422940@robur.slu.se> Date: Tue, 28 Sep 2004 10:44:30 +0200 To: Stephen Hemminger Cc: "David S. Miller" , Harald Welte , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh / Statistics In-Reply-To: <1096327658.1729.19.camel@localhost.localdomain> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1048 Lines: 26 Stephen Hemminger writes: > > Harald Welte wrote: > > > > > As stated before, I would like to change rt_stat and ct_stat in order to > > > include a first 'template' line, too. This way it is easier to write a > > > generic foo_stat program, that could deal with any of those statistics > > > files, even with new ones... but this of course would break existing > > > rtstat binaries. I personally don't care, since it's a little-known > > > and little-used feature, which to my knowledge is in a lot of > > > distributions either non-existant [Debian] or incompatible [SuSE]. What > > > do you think? > > > > I agree. And while we're add it let's get a fixed rtstat into > > iproute2 and make sure that binary gets installed by default > > so maybe the dists will start shipping it properly. > > I have the old one in the repository. I sent you the latest rtstat (Martin sent ctstat) during netfilter workshop. Remember? Having a common foo_stat sounds like a good idea. Cheers. --ro From zilvinas@gemtek.lt Tue Sep 28 02:37:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 02:37:31 -0700 (PDT) Received: from barclay.balt.net (root@barclay.balt.net [195.14.162.78]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8S9bOiR014723 for ; Tue, 28 Sep 2004 02:37:26 -0700 Received: from [192.168.3.3] ([192.168.2.249]) by barclay.balt.net (8.12.11/8.12.11/Debian-5) with ESMTP id i8S9b5pR012892; Tue, 28 Sep 2004 12:37:06 +0300 Subject: Re: Crypto tests via tcrypt.o modules failes From: Zilvinas Valinskas Reply-To: zilvinas@gemtek.lt To: James Morris Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Gemtek Baltic Date: Tue, 28 Sep 2004 12:37:09 +0300 Message-Id: <1096364229.5548.6.camel@swoop.gemtek.lt> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zilvinas@gemtek.lt Precedence: bulk X-list: netdev Content-Length: 1032 Lines: 28 Hello, apparently IPsec and crypto algorithms are ok on IXP 425 (big endian) system. Not sure what exactly went wrong - I've rm -rf / whole tree , applied patches and result - it works .. (I could suspect dependencies somehow had been broken and not all files were compiled - as a result miscompilation ? ...) Anyway, linux 2.4.27 + ipsec (from Herbert) + IXP 425 bits (from ucLinux) seems is working fine (all crypto modules, not sure only about cast5 and cast6 algos - as I am not using them here ...) Zilvinas Valinskas On Fri, 2004-09-17 at 12:09 -0400, James Morris wrote: > On Fri, 17 Sep 2004, Zilvinas Valinskas wrote: > > > > I've had a report that all is well on an Xscale PXA (SoC) system, with a > > > 2.6.7-rc2 kernel. Are there any significant differences between that and > > > what you have? > > 2.4.27 and 2.6.7-rc2 I think quite different - can you tell me which > > parts to check for differencies ? > > It should work on either kernel (btw, the PXA is little endian, so they > are different). > From hadi@cyberus.ca Tue Sep 28 03:36:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 03:36:53 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SAalN3023955 for ; Tue, 28 Sep 2004 03:36:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CCFLU-0007aW-Ch for netdev@oss.sgi.com; Tue, 28 Sep 2004 06:36:32 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCFLR-00040i-7w; Tue, 28 Sep 2004 06:36:29 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040928035921.GA10675@gondor.apana.org.au> References: <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096367787.8662.146.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 06:36:27 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3443 Lines: 76 On Mon, 2004-09-27 at 23:59, Herbert Xu wrote: > On Mon, Sep 27, 2004 at 11:45:25PM -0400, jamal wrote: > > fixing the NLM_GOODSIZE issue is a very good first step. > > Well I'm afraid that it doesn't help in your interface address example > because rtmsg_ifa() already allocates a buffer of (approximately) the > right size. That is, it doesn't use NLM_GOODSIZE at all. er, what about the host scope route msgs generated by same script? ;-> I am not sure if the IFAs cause any issues - they definetley contribute. > > Adding congestion control would be harder but not out of question. > > But the question is who are you going to throttle? If you throttle > the source of the messages then you're going to stop people from adding > or deleting IP addresses which can't be right. The state is per socket. You may need an intermediate queue etc which feeds to each user socket registered for the event. The socket queue acts as a essentially a retransmitQ for broadcast state. Just waving my hands throwing ideas here of course. > If you move the netlink sender into a different execution context and > throttle that then that's just extending the receive queue length by > stealth. > > So I'm afraid I don't see how congestion control could be applied in > *this* particular context. > We cant control the user space script for example that caused those events. We shouldnt infact. Congestion control in this context equates to desire to not overlaod the reader (of events). In other words if you know the reader's capacity for swallowing events, then you dont exceed that rate of sending to said reader. Knowing the capacity requires even more state: So on that thought, lets continue on the handwaving approach of an intermidiate queue. Congestion control would mean the puck stops at this queue and usre space doesnt get bogged down reading meaningless state, The problem is, like i said earlier, that your rate of consumption of events is going to be bottlenecked by the slowest and most socket buff deprived reader. If you create the intermediate queue i described above, then it gets to absorb the massive messages before any socket sees them. If this queue gets full then there is no point in sending any message to any waiting socket. Just overrun them immediately and they (readers) get forced to reread the state. Of course this queue will have to be larger than any of the active sockets recv queues. You will need to have one such queue per event - and yes there maybe scalability issues. The moral of this is: you could do it if you wanted - aint trivial. > > > So just bite the bullet and reread the system state by issuing dump > > > operations. > > > > We may as well choose to document it as being this mostly because of the > > issue i described above. We shouldnt give up so easily though ;-> > > Well IMHO this is not giving up at all. > > Think of it another way. Monitoring routes is like maintaining a > program. Normally you just fix the bugs as they come. But if the > bug reports are coming in so fast that you can't keep up, perhaps > it's time to throw it away and rewrite it from scratch :) Except if you drop incoming bug reports and drop them early (point of that intermidiate queue). BTW, Davem gets away with this congestion control alg all the time. Heck i think his sanity survives because of it - I bet you hes got this thread under congestion controlled right now;-> cheers, jamal From hadi@cyberus.ca Tue Sep 28 03:40:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 03:40:12 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SAe5gV024357 for ; Tue, 28 Sep 2004 03:40:07 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CCFOg-0001qF-R7 for netdev@oss.sgi.com; Tue, 28 Sep 2004 06:39:50 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCFOb-0004Jm-PA; Tue, 28 Sep 2004 06:39:46 -0400 Subject: Re: [PATCH 2.6] natsemi.c NAPI From: jamal Reply-To: hadi@cyberus.ca To: Manfred Spraul Cc: Harald Welte , netdev@oss.sgi.com In-Reply-To: <4158E74C.7030709@colorfullife.com> References: <20040919163642.GC1307@sunbeam.de.gnumonks.org> <4155D781.8050700@colorfullife.com> <20040927081411.GC3236@sunbeam.de.gnumonks.org> <1096343829.8660.107.camel@jzny.localdomain> <4158E74C.7030709@colorfullife.com> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096367984.8659.149.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 06:39:44 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 641 Lines: 21 On Tue, 2004-09-28 at 00:23, Manfred Spraul wrote: > jamal wrote: [..] > >Does this mean that the interupt clears when read? > >Why would reading a NIC register clear a soundcard interupt? > > > > > > > No, of course not. But each soundcard interrupt would cause a > netif_rx_schedule, with the following callback from tasklet context. > IMHO the overhead of that operation is too large. Additionally it breaks > the stuck irq detection. Ok, In such a case it is advised that a e1000 style NAPI is used (as opposed to the tulip varinat). Sorry, I should actually read the code first - I ma hoping i am in context here. cheers, jamal From herbert@gondor.apana.org.au Tue Sep 28 04:12:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 04:13:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SBCf1P025459 for ; Tue, 28 Sep 2004 04:12:42 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCFtx-0006Pb-00; Tue, 28 Sep 2004 21:12:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCFtn-0004pU-00; Tue, 28 Sep 2004 21:11:59 +1000 Date: Tue, 28 Sep 2004 21:11:59 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040928111159.GA18421@gondor.apana.org.au> References: <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096367787.8662.146.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 4353 Lines: 94 On Tue, Sep 28, 2004 at 06:36:27AM -0400, jamal wrote: > > er, what about the host scope route msgs generated by same script? ;-> You mean rtmsg_fib()? It also allocates a size much less than NLM_GOODSIZE, namely sizeof(struct rtmsg) + 256. However, the trim function might be able to shave a bit off there since the 256 bytes is mostly reserved for multiple nexthops. AFAIK, no async netlink event function uses NLM_GOODSIZE at all for obvious reasons. > The state is per socket. You may need an intermediate queue etc which > feeds to each user socket registered for the event. The socket queue > acts as a essentially a retransmitQ for broadcast state. Just waving my > hands throwing ideas here of course. Aha, you've fallen into my trap :) Now let me demonstrate why having an intermediate queue doesn't help at all. Holding the packet on the intermediate queue is exactly the same as holding it on the receive queue of the destination socket. The reason is that we're simply cloning the packets. So moving it from one queue to another does not reduce system resource usage by much. There is the cost in cloning the skbs. However, that's an orthogonal issue altogether. We can reduce the cost there by making the packets bigger. This can either be done at the sender end by coalescing successive messages. Or we can merge them in netlink_broadcast. Granted having an intermediate queue will avoid overruns if it is large enough. However, having all the receive queues to be as big as your intermediate queue will have exactly the same effect. In fact this has an advantage over the intermediate queue. With the latter, you need to hold the packet in place whether the applications need it or not. While currently, the application can choose whether it wants to receive a large batch of events and if so how large. Remember just because one application overruns, it doesn't mean that the other recipients of the same skb will overrun. They can continue to receive messages as long as their receive queue allows it. So applications that really want to see every event should have a very large receive queue. Those that can recover easily should use with a much smaller queue. > We cant control the user space script for example that caused those > events. We shouldnt infact. Congestion control in this context equates > to desire to not overlaod the reader (of events). In other words if you > know the reader's capacity for swallowing events, then you dont exceed > that rate of sending to said reader. Knowing the capacity requires even > more state: I understand what you mean. But unless you can quench the source of the messages/events, all you can do is batch them up somewhere. What I'm arguing about is that batching them up in the middle is no better than batching them up at the destination. In fact it's worse in that it takes away choice from the receiving application. > any waiting socket. Just overrun them immediately and they (readers) get > forced to reread the state. Of course this queue will have to be larger > than any of the active sockets recv queues. Jamal, maybe I've got the wrong impression but it almost seems that you think that if one applications overruns, then everyone else on that multicast address will overrun as well. This is definitely not the case. With an intermediate queue, you will in fact impose overruns on everyone when it overflows which seems to be a step backwards. > The moral of this is: you could do it if you wanted - aint trivial. Well this is not what I'd call congestion control :) Let's take a TCP analogy. This is like batching up TCP packets on a router in the middle rather than shutting down the sender. Congestion control is where you shut the sender up. > Except if you drop incoming bug reports and drop them early (point of > that intermidiate queue). Nah. Dropping them early is overruning early. > BTW, Davem gets away with this congestion control alg all the time. > Heck i think his sanity survives because of it - I bet you hes got this > thread under congestion controlled right now;-> Yep, his overrun flag sure is set :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From laforge@gnumonks.org Tue Sep 28 04:19:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 04:19:35 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SBJNrK029117 for ; Tue, 28 Sep 2004 04:19:23 -0700 Received: from dsl-213-023-152-188.arcor-ip.net ([213.23.152.188] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CCG0i-0003QD-Aa; Tue, 28 Sep 2004 13:19:08 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CCG0g-0007pc-Ra; Tue, 28 Sep 2004 13:19:06 +0200 Date: Tue, 28 Sep 2004 13:19:06 +0200 From: Harald Welte To: Robert Olsson Cc: Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) Message-ID: <20040928111906.GB29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <16729.9326.93269.422940@robur.slu.se> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 11457 Lines: 334 --O5XBE6gyVG5Rl6Rj Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2004 at 10:44:30AM +0200, Robert Olsson wrote: >=20 > Stephen Hemminger writes: >=20 > > > Harald Welte wrote: > > >=20 > > > > As stated before, I would like to change rt_stat and ct_stat in or= der to > > > > include a first 'template' line, too. This way it is easier to wr= ite a > > > > generic foo_stat program, that could deal with any of those statis= tics > > > > files, even with new ones... but this of course would break exist= ing > > > > rtstat binaries. I personally don't care, since it's a little-kn= own > > > > and little-used feature, which to my knowledge is in a lot of > > > > distributions either non-existant [Debian] or incompatible [SuSE].= What > > > > do you think? > > >=20 > > > I agree. And while we're add it let's get a fixed rtstat into > > > iproute2 and make sure that binary gets installed by default > > > so maybe the dists will start shipping it properly. > >=20 > > I have the old one in the repository. >=20 > I sent you the latest rtstat (Martin sent ctstat) during netfilter works= hop.=20 > Remember? Having a common foo_stat sounds like a good idea. I'm working on this right now. The plan is to make the parser code shared between a commandline tool and some daemon that can be run on production systems to gather long-term statistics. You can select the fields you're interested in with keys like "rt_stat:entries". Maybe I'll even add stuff like mysql/pgsql-logging like ulogd has, but that future plans for now. I've called it lnstat for now (as in linux networking statistics), but I'm open to better suggestions on the name ;) Please find the current kernel-part patch attached to this mail, it adds teplate-headerlines and moves all statistics files to /proc/net/stat. It even cleans up the neigh_stat code a bit. Depends on my latest neighbour statistics patch that davem has already merged. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="laforge-rtstat-ctstat-template.patch" Content-Transfer-Encoding: quoted-printable This patch moves the following files in /proc: /proc/net/rt_cache_stat /proc/net/stat/rt_cache /proc/net/ip_conntrack_stat /proc/net/stat/ip_conntrack /proc/net/arp_cache_stat /proc/net/stat/arp_cache /proc/net/clip_arp_cache_stat /proc/net/stat/clib_arp_cache /proc/net/dn_neigh_cache_stat /proc/net/stat/dn_neigh_cache This allows a generic statistics tool to scan for all available statistics by doing readdir(2) on /proc/net/stat It also adds a special first "template" line to rt_cache and ip_conntrack in order to facilitate compatibility once somebody adds new fields to the output lines. WARNING:=20 This breaks existing rtstat.c and ctstat.c userspace programs (hopefully for the last time). rtstat is non-existant or broken in major distributions anyway, and ctstat is too new for any distros having it picked up. Therefore, we justify this breakage. A new unified statistics tool for routing cache, connection tracking and neighbour cache is under development and will be included with iproute2. Signed-off-by: Harald Welte Index: linux-2.6.9-rc2-bk9-neigh1/net/ipv4/netfilter/ip_conntrack_standalon= e.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/ipv4/netfilter/ip_conntrack_standal= one.c 2004-09-28 10:33:07.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/ipv4/netfilter/ip_conntrack_standalone.c= 2004-09-28 10:55:17.000000000 +0200 @@ -270,10 +270,13 @@ { int cpu; =20 - for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { + if (*pos =3D=3D 0) + return SEQ_START_TOKEN; + + for (cpu =3D *pos-1; cpu < NR_CPUS; ++cpu) { if (!cpu_possible(cpu)) continue; - *pos =3D cpu; + *pos =3D cpu+1; return &per_cpu(ip_conntrack_stat, cpu); } =20 @@ -284,10 +287,10 @@ { int cpu; =20 - for (cpu =3D *pos + 1; cpu < NR_CPUS; ++cpu) { + for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { if (!cpu_possible(cpu)) continue; - *pos =3D cpu; + *pos =3D cpu+1; return &per_cpu(ip_conntrack_stat, cpu); } =20 @@ -303,6 +306,11 @@ unsigned int nr_conntracks =3D atomic_read(&ip_conntrack_count); struct ip_conntrack_stat *st =3D v; =20 + if (v =3D=3D SEQ_START_TOKEN) { + seq_printf(seq, "entries searched found new invalid ignore delete delet= e_list insert insert_failed drop early_drop icmp_error expect_new expect_c= reate expect_delete\n"); + return 0; + } + seq_printf(seq, "%08x %08x %08x %08x %08x %08x %08x %08x " "%08x %08x %08x %08x %08x %08x %08x %08x \n", nr_conntracks, @@ -729,10 +737,11 @@ &exp_file_ops); if (!proc_exp) goto cleanup_proc; =20 - proc_stat =3D proc_net_fops_create("ip_conntrack_stat", S_IRUGO, - &ct_cpu_seq_fops); + proc_stat =3D create_proc_entry("ip_conntrack", S_IRUGO, proc_net_stat); if (!proc_stat) goto cleanup_proc_exp; + + proc_stat->proc_fops =3D &ct_cpu_seq_fops; proc_stat->owner =3D THIS_MODULE; #endif =20 Index: linux-2.6.9-rc2-bk9-neigh1/net/ipv4/route.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/ipv4/route.c 2004-09-26 12:11:20.00= 0000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/ipv4/route.c 2004-09-28 12:12:42.0000000= 00 +0200 @@ -356,10 +356,13 @@ { int cpu; =20 - for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { + if (*pos =3D=3D 0) + return SEQ_START_TOKEN; + + for (cpu =3D *pos-1; cpu < NR_CPUS; ++cpu) { if (!cpu_possible(cpu)) continue; - *pos =3D cpu; + *pos =3D cpu+1; return per_cpu_ptr(rt_cache_stat, cpu); } return NULL; @@ -369,10 +372,10 @@ { int cpu; =20 - for (cpu =3D *pos + 1; cpu < NR_CPUS; ++cpu) { + for (cpu =3D *pos; cpu < NR_CPUS; ++cpu) { if (!cpu_possible(cpu)) continue; - *pos =3D cpu; + *pos =3D cpu+1; return per_cpu_ptr(rt_cache_stat, cpu); } return NULL; @@ -387,6 +390,11 @@ static int rt_cpu_seq_show(struct seq_file *seq, void *v) { struct rt_cache_stat *st =3D v; + + if (v =3D=3D SEQ_START_TOKEN) { + seq_printf(seq, "entries in_hit in_slow_tot in_no_route in_brd in_marti= an_dst in_martian_src out_hit out_slow_tot out_slow_mc gc_total gc_ignore= d gc_goal_miss gc_dst_overflow in_hlist_search out_hlist_search\n"); + return 0; + } =09 seq_printf(seq,"%08x %08x %08x %08x %08x %08x %08x %08x " " %08x %08x %08x %08x %08x %08x %08x %08x %08x \n", @@ -2783,12 +2791,16 @@ add_timer(&rt_secret_timer); =20 #ifdef CONFIG_PROC_FS + { + struct proc_dir_entry *rtstat_pde =3D NULL; /* keep gcc happy */ if (!proc_net_fops_create("rt_cache", S_IRUGO, &rt_cache_seq_fops) || - !proc_net_fops_create("rt_cache_stat", S_IRUGO, &rt_cpu_seq_fops)) { + !(rtstat_pde =3D create_proc_entry("rt_cache", S_IRUGO,=20 + proc_net_stat))) { free_percpu(rt_cache_stat); return -ENOMEM; } - + rtstat_pde->proc_fops =3D &rt_cpu_seq_fops; + } #ifdef CONFIG_NET_CLS_ROUTE create_proc_read_entry("rt_acct", 0, proc_net, ip_rt_acct_read, NULL); #endif Index: linux-2.6.9-rc2-bk9-neigh1/fs/proc/root.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/fs/proc/root.c 2004-09-13 07:33:11.0000= 00000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/fs/proc/root.c 2004-09-28 11:41:10.000000000= +0200 @@ -18,7 +18,7 @@ #include #include =20 -struct proc_dir_entry *proc_net, *proc_bus, *proc_root_fs, *proc_root_driv= er; +struct proc_dir_entry *proc_net, *proc_net_stat, *proc_bus, *proc_root_fs,= *proc_root_driver; =20 #ifdef CONFIG_SYSCTL struct proc_dir_entry *proc_sys_root; @@ -53,6 +53,8 @@ } proc_misc_init(); proc_net =3D proc_mkdir("net", NULL); + proc_net_stat =3D proc_mkdir("net/stat", NULL); + #ifdef CONFIG_SYSVIPC proc_mkdir("sysvipc", NULL); #endif @@ -157,5 +159,6 @@ EXPORT_SYMBOL(proc_root); EXPORT_SYMBOL(proc_root_fs); EXPORT_SYMBOL(proc_net); +EXPORT_SYMBOL(proc_net_stat); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); Index: linux-2.6.9-rc2-bk9-neigh1/include/linux/proc_fs.h =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/include/linux/proc_fs.h 2004-09-13 07:3= 3:39.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/include/linux/proc_fs.h 2004-09-28 10:47:17.= 000000000 +0200 @@ -79,6 +79,7 @@ extern struct proc_dir_entry proc_root; extern struct proc_dir_entry *proc_root_fs; extern struct proc_dir_entry *proc_net; +extern struct proc_dir_entry *proc_net_stat; extern struct proc_dir_entry *proc_bus; extern struct proc_dir_entry *proc_root_driver; extern struct proc_dir_entry *proc_root_kcore; Index: linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c =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=3D=3D=3D=3D=3D=3D=3D --- linux-2.6.9-rc2-bk9-neigh1.orig/net/core/neighbour.c 2004-09-28 00:15:5= 1.000000000 +0200 +++ linux-2.6.9-rc2-bk9-neigh1/net/core/neighbour.c 2004-09-28 10:56:44.000= 000000 +0200 @@ -1333,22 +1333,11 @@ panic("cannot create neighbour cache statistics"); =09 #ifdef CONFIG_PROC_FS -#define NC_STAT_SUFFIX "_stat" - { - char *proc_stat_name; - proc_stat_name =3D kmalloc(strlen(tbl->id) +=20 - strlen(NC_STAT_SUFFIX) + 1, GFP_KERNEL); - if (!proc_stat_name) - panic("cannot allocate neighbour cache proc name buffer"); - strcpy(proc_stat_name, tbl->id); - strcat(proc_stat_name, NC_STAT_SUFFIX); - - tbl->pde =3D create_proc_entry(proc_stat_name, 0, proc_net); + tbl->pde =3D create_proc_entry(tbl->id, 0, proc_net_stat); if (!tbl->pde)=20 panic("cannot create neighbour proc dir entry"); tbl->pde->proc_fops =3D &neigh_stat_seq_fops; tbl->pde->data =3D tbl; - } #endif =20 tbl->hash_mask =3D 0x1f; --YZ5djTAD1cGYuMQK-- --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWUiqXaXGVTD0i/8RAjFKAKCUo+k3hIQQP3mZAobRwH6c+/avIACfRLVN S6mXt6Z4qSsj5/dENKb2Px4= =qISG -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From herbert@gondor.apana.org.au Tue Sep 28 05:17:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 05:17:49 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SCHdhd030299 for ; Tue, 28 Sep 2004 05:17:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCGuo-0006ln-00; Tue, 28 Sep 2004 22:17:06 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCGuV-0005Uu-00; Tue, 28 Sep 2004 22:16:47 +1000 Date: Tue, 28 Sep 2004 22:16:47 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040928121647.GA21121@gondor.apana.org.au> References: <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040928111159.GA18421@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 613 Lines: 15 On Tue, Sep 28, 2004 at 09:11:59PM +1000, herbert wrote: > > > BTW, Davem gets away with this congestion control alg all the time. > > Heck i think his sanity survives because of it - I bet you hes got this > > thread under congestion controlled right now;-> > > Yep, his overrun flag sure is set :) Now if he puts his mailing admin hat on and tells us to shut up, that would be congestion control :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mcgrof@studorgs.rutgers.edu Tue Sep 28 05:20:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 05:20:45 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SCKefx030667 for ; Tue, 28 Sep 2004 05:20:40 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 2548BF99BD; Tue, 28 Sep 2004 08:20:28 -0400 (EDT) Date: Tue, 28 Sep 2004 08:20:28 -0400 To: greg chesson Cc: Vladimir Kondratiev , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-ID: <20040928122028.GK30131@ruslug.rutgers.edu> Mail-Followup-To: greg chesson , Vladimir Kondratiev , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com, vda@port.imtp.ilyichevsk.odessa.ua References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <1094628909.1097.145.camel@jzny.localdomain> <413F2D33.1000508@atheros.com> <200409082251.45771.vkondra@mail.ru> <413F70F0.6020709@atheros.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pk/CTwBz1VvfPIDp" Content-Disposition: inline In-Reply-To: <413F70F0.6020709@atheros.com> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1618 Lines: 57 --Pk/CTwBz1VvfPIDp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 08, 2004 at 01:52:00PM -0700, greg chesson wrote: >=20 >=20 > Vladimir Kondratiev wrote: > >Greg, > >you missed one important point. Besides data packets, that every driver= =20 > >now convert .11<->.3 using almost the same code, there is whole story of= =20 > >management. Many modern cards are "softmac" and do all management on hos= t.=20 > >I see no point for every driver to implement its own scanning and=20 > >association.=20 >=20 > Yes, Quite right. No disagreement. > It is standard practice on NDIS and Apple Darwin that a common GUI-based > application controls scanning, association, and manages=20 > keys+authentication+crypto. >=20 > Linux does the same thing (driver is configured by application code) > although there does not yet exist a single app > that can serve as a common point of control for multiple vendor drivers. > I believe that achieving that goal is the real payoff for wireless Linux= =20 > users. >=20 <-- snip --> RFC: what are the chances we can implement our own generic "softmac" that m= ay be usable by the different chipsets out there? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --Pk/CTwBz1VvfPIDp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWVcMat1JN+IKUl4RAu4NAJoDo42bsPBum54qQZ+Z1bqDSz5ibgCfROrd IQ2LOtHHbfTgIdxSXjLPRLk= =aWPg -----END PGP SIGNATURE----- --Pk/CTwBz1VvfPIDp-- From hadi@cyberus.ca Tue Sep 28 05:32:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 05:32:43 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SCWbDw031158 for ; Tue, 28 Sep 2004 05:32:37 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CCH9a-0004eN-QS for netdev@oss.sgi.com; Tue, 28 Sep 2004 08:32:22 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCH9X-0006y1-PF; Tue, 28 Sep 2004 08:32:20 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040928111159.GA18421@gondor.apana.org.au> References: <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096374736.8663.217.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 08:32:17 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 5580 Lines: 127 On Tue, 2004-09-28 at 07:11, Herbert Xu wrote: > On Tue, Sep 28, 2004 at 06:36:27AM -0400, jamal wrote: > > > > er, what about the host scope route msgs generated by same script? ;-> > AFAIK, no async netlink event function uses NLM_GOODSIZE at all for > obvious reasons. Actually i just examined the events generated by the script, they are IFLA and ROUTE events and not IFA. So take a look at:rtmsg_ifinfo() > > The state is per socket. You may need an intermediate queue etc which > > feeds to each user socket registered for the event. The socket queue > > acts as a essentially a retransmitQ for broadcast state. Just waving my > > hands throwing ideas here of course. > > Aha, you've fallen into my trap :) Oh, goody ;-> > Now let me demonstrate why having > an intermediate queue doesn't help at all. > > Holding the packet on the intermediate queue is exactly the same as > holding it on the receive queue of the destination socket. The reason > is that we're simply cloning the packets. So moving it from one queue > to another does not reduce system resource usage by much. Ah, but theres clearly benefit into saving packets from crossing to user space in particular in the case of overload. You do save on system resources for sure in that case. In the case of normal operation, no overload case, you end up using a little more system resource - but thats a price tag that comes with the benefits (needs to be weighed out). > There is the cost in cloning the skbs. However, that's an orthogonal > issue altogether. We can reduce the cost there by making the packets > bigger. This can either be done at the sender end by coalescing > successive messages. Or we can merge them in netlink_broadcast. > > Granted having an intermediate queue will avoid overruns if it is > large enough. However, having all the receive queues to be as big > as your intermediate queue will have exactly the same effect. Agreed it will postpone the problem, and not cure it. Where i saw the benefit is if this queue is full/overloaded then you dont bother transfering skbs to the sock receiveQ - instead you overrun the event listeners (on purpose) before giving them any data. This assumes you only start feeding the listeners when the event generation is complete (in multi message batch when DONE is processed). In the case of overrunning the listeners you should alos flush the intermediate queue. Again, I am handwaving - there maybe a lot of practical issues whcih become obvious with actually get hands dirty. I actually tried to implement this a while back for socket packet tap listeners; cant find my patches. What i was trying to get feedback that i could feed all the way down to NAPI - it provide to be futile because i would need to have hardware drop selectively and such NICs dont exist. > In fact this has an advantage over the intermediate queue. With the > latter, you need to hold the packet in place whether the applications > need it or not. While currently, the application can choose whether > it wants to receive a large batch of events and if so how large. > Right, but only find out after reading a subset of messages which cross into user space. Which is wasted cycles really. Now if you could say from user space "please continue where you left over" the messages before overrun wont be a waste. I do think thats not wise for events(you should be able a summary of the issue some other way as in overruns at the moment) but is definetely need for large get results. > Remember just because one application overruns, it doesn't mean that > the other recipients of the same skb will overrun. They can continue > to receive messages as long as their receive queue allows it. > Agreed. Note thats a design choice and the truth of which is a better scheme only comes out by testing both schemes. Easier to leave whats already in place - but what fun is that now?;-> Also to note this only applies to broadcasts. > So applications that really want to see every event should have a > very large receive queue. Those that can recover easily should use > with a much smaller queue. Depending on how you look at it (since i am drinking the write variant of cofee right now, lets look at it from a philosphoical view: is it the area of the light radiated or the circumference of darkness surrounding the light? ;-> Choose your metric ;-> ): A large queue may actually be a problem if it also gets overflown since it takes relatively longer to find out. You still have to read the damn state to find out details. [..] > Jamal, maybe I've got the wrong impression but it almost seems > that you think that if one applications overruns, then everyone > else on that multicast address will overrun as well. This is > definitely not the case. I think its fair to assume that if the intermidiate queue is overflown all listeners will be. > With an intermediate queue, you will in fact impose overruns on > everyone when it overflows which seems to be a step backwards. Refer to above assumption. > > The moral of this is: you could do it if you wanted - aint trivial. > > Well this is not what I'd call congestion control :) Let's take a > TCP analogy. This is like batching up TCP packets on a router in > the middle rather than shutting down the sender. Congestion control > is where you shut the sender up. Its actually worse than that -->which is a shame since we have more control over what can be sent to user. Congestion could be driven by receiver as well. Look at TCP zero windows for example. Or even ECN. cheers, jamal From hadi@cyberus.ca Tue Sep 28 05:40:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 05:40:12 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SCe6S9031566 for ; Tue, 28 Sep 2004 05:40:07 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CCHGq-0002ft-H7 for netdev@oss.sgi.com; Tue, 28 Sep 2004 08:39:52 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCHGo-0007sY-M5; Tue, 28 Sep 2004 08:39:50 -0400 Subject: On DaveMs congestion control algorithm WAS(Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040928121647.GA21121@gondor.apana.org.au> References: <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <20040928121647.GA21121@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096375188.8663.226.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 08:39:49 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 591 Lines: 20 On Tue, 2004-09-28 at 08:16, Herbert Xu wrote: > On Tue, Sep 28, 2004 at 09:11:59PM +1000, herbert wrote: > > > > > BTW, Davem gets away with this congestion control alg all the time. > > > Heck i think his sanity survives because of it - I bet you hes got this > > > thread under congestion controlled right now;-> > > > > Yep, his overrun flag sure is set :) > > Now if he puts his mailing admin hat on and tells us to shut up, that > would be congestion control :) Hed have to go and read all the emails first ;-> i.e the overrun flag requires that you reread state. cheers, jamal From hadi@cyberus.ca Tue Sep 28 05:48:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 05:48:53 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SCmiMc032020 for ; Tue, 28 Sep 2004 05:48:44 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CCHPC-00046M-9C for netdev@oss.sgi.com; Tue, 28 Sep 2004 08:48:30 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCHP5-0000Su-BM; Tue, 28 Sep 2004 08:48:23 -0400 Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) From: jamal Reply-To: hadi@cyberus.ca To: Harald Welte Cc: Robert Olsson , Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20040928111906.GB29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> Content-Type: multipart/mixed; boundary="=-s7RWREjdDMQt9EjRhH8q" Organization: jamalopolous Message-Id: <1096375700.8659.235.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 08:48:20 -0400 X-archive-position: 9594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 9895 Lines: 378 --=-s7RWREjdDMQt9EjRhH8q Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks for changing the subject Harald (I wanted to catchup with that thread at some point). Speaking of generic stats; i have a patch netlink ready which may need some extensions. I did post it a while back on netdev but didnt get feedback. cheers, jamal --=-s7RWREjdDMQt9EjRhH8q Content-Disposition: attachment; filename=stats1.patch Content-Type: text/plain; name=stats1.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- 268rc3/net/core/Makefile 2004/08/09 02:44:08 1.1 +++ 268rc3/net/core/Makefile 2004/08/09 02:46:01 @@ -2,7 +2,7 @@ # Makefile for the Linux networking core. # -obj-y := sock.o skbuff.o iovec.o datagram.o stream.o scm.o +obj-y := sock.o skbuff.o iovec.o datagram.o stream.o scm.o gen_stats.o gen_estimator.o obj-$(CONFIG_SYSCTL) += sysctl_net_core.o --- /dev/null 1998-05-05 16:32:27.000000000 -0400 +++ 268rc3/net/core/gen_stats.c 2004-08-09 09:22:21.000000000 -0400 @@ -0,0 +1,105 @@ +/* + * net/core/gen_stats.c + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Alexey Kuznetsov, + * + * Changes: + * Jamal Hadi Salim adapted from net_sched_api for gen purpose use + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +/* + * USAGE: + * + * declare in mystruct: + * struct gen_stats mystats; + * + * increment as appropriate,eg : + * + * mystruct->mystats.packets++; + * + * update is lockless + * + * passing to user space: + * + * in routine my_dump(): + * + * if (gen_copy_stats(skb, &mystruct->mystats,MYSTAT_V), my_lock) + * goto rtattr_failure; + * + * + * locks: + * + * You are responsible for making sure that stats lock is + * initialized to something valid + * (typically the table lock -- i.e updates happen only when + * you are dumping like here) + * */ +int gen_copy_stats(struct sk_buff *skb, struct gnet_stats *st,int type, spinlock_t *lock) +{ + spin_lock_bh(lock); + RTA_PUT(skb, type, sizeof(struct gnet_stats), st); + spin_unlock_bh(lock); + return 0; + +rtattr_failure: + spin_unlock_bh(lock); + return -1; +} + +/* + * USAGE: + * + * declare your own private formated in mystruct: + * struct mypriv_stats mystats; + * + * passing to user space: + * + * in routine my_dump(): + * + * if (gen_copy_xstats(skb, (void *)&mystruct->mystats,sizeof(struct mypriv_stats), MYPSTAT_V),my_lock) + * goto rtattr_failure; + * + * Lock rules apply the same as in general stats + */ +int gen_copy_xstats(struct sk_buff *skb, void *st, int size, int type, spinlock_t *lock) +{ + spin_lock_bh(lock); + RTA_PUT(skb, type, size, st); + spin_unlock_bh(lock); + return 0; + +rtattr_failure: + spin_unlock_bh(lock); + return -1; +} + +EXPORT_SYMBOL(gen_copy_stats); +EXPORT_SYMBOL(gen_copy_xstats); --- /dev/null 1998-05-05 16:32:27.000000000 -0400 +++ 268rc3/net/core/gen_estimator.c 2004-08-09 09:00:56.000000000 -0400 @@ -0,0 +1,207 @@ +/* + * net/sched/estimator.c Simple rate estimator. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Alexey Kuznetsov, + * + * Changes: + * Jamal Hadi Salim - moved it to net/core and reshulfed + * names to make it usable in general net subsystem. + * + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + This code is NOT intended to be used for statistics collection, + its purpose is to provide a base for statistical multiplexing + for controlled load service. + If you need only statistics, run a user level daemon which + periodically reads byte counters. + + Unfortunately, rate estimation is not a very easy task. + F.e. I did not find a simple way to estimate the current peak rate + and even failed to formulate the problem 8)8) + + So I preferred not to built an estimator into the scheduler, + but run this task separately. + Ideally, it should be kernel thread(s), but for now it runs + from timers, which puts apparent top bounds on the number of rated + flows, has minimal overhead on small, but is enough + to handle controlled load service, sets of aggregates. + + We measure rate over A=(1<next) { + struct gnet_stats *st = e->stats; + u64 nbytes; + u32 npackets; + u32 rate; + + spin_lock(e->stats_lock); + nbytes = st->bytes; + npackets = st->packets; + rate = (nbytes - e->last_bytes)<<(7 - idx); + e->last_bytes = nbytes; + e->avbps += ((long)rate - (long)e->avbps) >> e->ewma_log; + st->bps = (e->avbps+0xF)>>5; + + rate = (npackets - e->last_packets)<<(12 - idx); + e->last_packets = npackets; + e->avpps += ((long)rate - (long)e->avpps) >> e->ewma_log; + e->stats->pps = (e->avpps+0x1FF)>>10; + spin_unlock(e->stats_lock); + } + + mod_timer(&elist[idx].timer, jiffies + ((HZ/4)<interval < -2 || parm->interval > 3) + return -EINVAL; + + est = kmalloc(sizeof(*est), GFP_KERNEL); + if (est == NULL) + return -ENOBUFS; + + memset(est, 0, sizeof(*est)); + est->interval = parm->interval + 2; + est->stats = stats; + est->stats_lock = stats_lock; + est->ewma_log = parm->ewma_log; + est->last_bytes = stats->bytes; + est->avbps = stats->bps<<5; + est->last_packets = stats->packets; + est->avpps = stats->pps<<10; + + est->next = elist[est->interval].list; + if (est->next == NULL) { + init_timer(&elist[est->interval].timer); + elist[est->interval].timer.data = est->interval; + elist[est->interval].timer.expires = jiffies + ((HZ/4)<interval); + elist[est->interval].timer.function = est_timer; + add_timer(&elist[est->interval].timer); + } + write_lock_bh(&est_lock); + elist[est->interval].list = est; + write_unlock_bh(&est_lock); + return 0; +} + +void gen_kill_estimator(struct gnet_stats *stats) +{ + int idx; + struct gen_estimator *est, **pest; + + for (idx=0; idx <= EST_MAX_INTERVAL; idx++) { + int killed = 0; + pest = &elist[idx].list; + while ((est=*pest) != NULL) { + if (est->stats != stats) { + pest = &est->next; + continue; + } + + write_lock_bh(&est_lock); + *pest = est->next; + write_unlock_bh(&est_lock); + + kfree(est); + killed++; + } + if (killed && elist[idx].list == NULL) + del_timer(&elist[idx].timer); + } +} + +EXPORT_SYMBOL(gen_kill_estimator); +EXPORT_SYMBOL(gen_new_estimator); --- /dev/null 1998-05-05 16:32:27.000000000 -0400 +++ 268rc3/include/linux/gen_stats.h 2004-08-09 09:06:29.000000000 -0400 @@ -0,0 +1,21 @@ +#ifndef __LINUX_GEN_STATS_H +#define __LINUX_GEN_STATS_H + +struct gnet_stats +{ + __u64 bytes; /* Number of seen bytes */ + __u32 packets; /* Number of seen packets */ + __u32 drops; /* Packets dropped */ + __u32 bps; /* Current flow byte rate */ + __u32 pps; /* Current flow packet rate */ + __u32 qlen; + __u32 backlog; +}; + +struct gnet_estimator +{ + signed char interval; + unsigned char ewma_log; +}; + +#endif --=-s7RWREjdDMQt9EjRhH8q-- From jheffner@psc.edu Tue Sep 28 05:53:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 05:53:30 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SCrOb4032416 for ; Tue, 28 Sep 2004 05:53:24 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8SCr4qk014375 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 28 Sep 2004 08:53:04 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8SCr3FH023165; Tue, 28 Sep 2004 08:53:03 -0400 (EDT) Date: Tue, 28 Sep 2004 08:53:03 -0400 (EDT) From: John Heffner To: Nivedita Singhvi cc: "David S. Miller" , Andi Kleen , , , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: <4159117A.4010904@us.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1379 Lines: 33 On Tue, 28 Sep 2004, Nivedita Singhvi wrote: > John Heffner wrote: > > > > More specifically, I think it is an interaction with delayed ack (acking > > less than 1 virtual segment), and the small cwnd. This works for me, but > > I'm not sure that aren't some lurking problems still. > > In terms of what goes out over the wire from the > sender, there is (or should be) no difference between > the TSO and non-TSO case. The sequence of regular sized > packets should be the same, and the only difference > might be the delays between the frames, at most. > > So the sequence of acks coming back from the > receiver should be the same, TSO and non-TSO case. > If we've sent out say 44 1500MTU frames, we should > probably see 22 acks back, roughly (acking every > second packet if delayed acks are on) in both > the TSO and non-TSO case. I was referring to a problem I saw that had really terrible performance (around 1 Mbit). It would send out one virtual segment, and all but the last of its real segments would be acked. The receiver will wait for the delayed ack timer to go off before acking the last segment, and the sender will wait for that last segment to be acked before sending out the next virtual segment if the cwnd is equal to 1 virtual segment. Dave's patch seems to correct this problem for me, but I'm not convinced this state could never occur. -John From tgr@reeler.org Tue Sep 28 06:34:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 06:34:27 -0700 (PDT) Received: from rei.rakuen (217-162-107-144.dclient.hispeed.ch [217.162.107.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SDYLxU000991 for ; Tue, 28 Sep 2004 06:34:21 -0700 Received: from tgr by rei.rakuen with local (Exim 4.34) id 1CCI6o-00081g-Hp; Tue, 28 Sep 2004 15:33:34 +0200 Date: Tue, 28 Sep 2004 15:33:34 +0200 From: Thomas Graf To: jamal Cc: Harald Welte , Robert Olsson , Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) Message-ID: <20040928133334.GW31616@rei.reeler.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <1096375700.8659.235.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096375700.8659.235.camel@jzny.localdomain> X-archive-position: 9596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 597 Lines: 12 > Speaking of generic stats; i have a patch netlink ready which may need > some extensions. I did post it a while back on netdev but didnt get > feedback. The code looks good and I couldn't spot any errors but I'm not sure if the locking in gen_copy_[x]stats is a good thing. Shouldn't that be done earlier by the caller? This prevents corruption but it allows duplicated TLVs in an skb. I suggest to make the caller have a lock on his data and only allow one dumper at the same time until the dump is complete, or at least provide a lockless variant for callers doing the locking on their own. From Robert.Olsson@data.slu.se Tue Sep 28 07:23:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 07:23:56 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SENiap002016 for ; Tue, 28 Sep 2004 07:23:45 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8SEMxY2016065; Tue, 28 Sep 2004 16:22:59 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 0665590265; Tue, 28 Sep 2004 16:22:59 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16729.29634.992171.862677@robur.slu.se> Date: Tue, 28 Sep 2004 16:22:58 +0200 To: hadi@cyberus.ca Cc: Harald Welte , Robert Olsson , Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) In-Reply-To: <1096375700.8659.235.camel@jzny.localdomain> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <1096375700.8659.235.camel@jzny.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 959 Lines: 26 jamal writes: > > Thanks for changing the subject Harald (I wanted to catchup with that > thread at some point). > Speaking of generic stats; i have a patch netlink ready which may need > some extensions. I did post it a while back on netdev but didnt get > feedback. OK it's EWMA calc in kernel. For another purpose I tried another approach to satisfy some users that wanted Cisco like average stats on our routers. User app/daemon reads stats via netlink and does average calc. looks like: ifstat2 eth* RX -------------------------- TX ------------------------- eth0 389.4 M bit/s 40 k pps 20.7 M bit/s 40 k pps eth1 3.1 k bit/s 4 pps 686.5 k bit/s 65 pps eth2 19.3 M bit/s 37 k pps 363.5 M bit/s 38 k pps As usual most code is honestly stolen from Alexey. :-) ftp://robur.slu.se/pub/Linux/net-development/ifstat2/ Cheers. --ro From laforge@gnumonks.org Tue Sep 28 07:55:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 07:55:27 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SEtKko002824 for ; Tue, 28 Sep 2004 07:55:21 -0700 Received: from dsl-213-023-152-188.arcor-ip.net ([213.23.152.188] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CCJNj-0006aY-UT; Tue, 28 Sep 2004 16:55:08 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CCJNh-0007zm-V6; Tue, 28 Sep 2004 16:55:06 +0200 Date: Tue, 28 Sep 2004 16:55:05 +0200 From: Harald Welte To: Robert Olsson Cc: Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) Message-ID: <20040928145505.GH29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uuKVzAmB+c+zQlhu" Content-Disposition: inline In-Reply-To: <20040928111906.GB29961@sunbeam.de.gnumonks.org> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 9674 Lines: 415 --uuKVzAmB+c+zQlhu Content-Type: multipart/mixed; boundary="fU0UwhtRbpo05rnG" Content-Disposition: inline --fU0UwhtRbpo05rnG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here goes some initial client code, so you can actually test the new proc files from kernel. As stated above, I'll continue working on this until it's somewhat more feature-complete. it's a multicall-binary so rtstat equals lnstat -f rt_cache ctstat equals lnstat -f ip_conntrack I do not suggest inclusion of this current code into iproute2 at this point, it's still under a lot of flux. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --fU0UwhtRbpo05rnG Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="lnstat.c" Content-Transfer-Encoding: quoted-printable /* lnstat.c: Unified linux network statistics * * Copyright (C) 2004 by Harald Welte * * Development of this code was funded by Astaro AG, http://www.astaro.com/ * * Based on original concept and ideas from predecessor rtstat.c: * * Copyright 2001 by Robert Olsson * Uppsala University, Sweden * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * */ #include #include #include #include #include #include #include #include #include #include #define LNSTAT_VERSION "0.01 040928" #define PROC_NET_STAT "/proc/net/stat" #define LNSTAT_MAX_FILES 32 #define LNSTAT_MAX_FIELDS_PER_LINE 32 #define LNSTAT_MAX_FIELD_NAME_LEN 32 struct lnstat_file; struct lnstat_field { struct lnstat_file *file; unsigned int num; /* field number in line */ char name[LNSTAT_MAX_FIELD_NAME_LEN+1]; unsigned long values[2]; /* two buffers for values */ }; struct lnstat_file { struct lnstat_file *next; char path[PATH_MAX+1]; char basename[NAME_MAX+1]; struct timeval last_read; /* last time of read */ struct timeval interval; /* interval */ FILE *fp; unsigned int num_fields; /* number of fields */ struct lnstat_field fields[LNSTAT_MAX_FIELDS_PER_LINE]; }; /* Read (and summarize for SMP) the different stats vars. */ static int scan_lines(struct lnstat_file *lf, int i) { int j, num_lines =3D 0; for (j =3D 0; j < lf->num_fields; j++) lf->fields[j].values[i] =3D 0; while(!feof(lf->fp)) { #define FGETS_BUF_SIZE 512 char buf[FGETS_BUF_SIZE]; char *ptr =3D buf; num_lines++; fgets(buf, FGETS_BUF_SIZE-1, lf->fp);=20 gettimeofday(&lf->last_read, NULL); for (j =3D 0; j < lf->num_fields; j++) lf->fields[j].values[i] +=3D strtoul(ptr, &ptr, 16); } return num_lines; } static int time_after(struct timeval *last,=20 struct timeval *tout,=20 struct timeval *now) { if (now->tv_sec > last->tv_sec + tout->tv_sec) return 1; if (now->tv_sec =3D=3D last->tv_sec + tout->tv_sec) { if (now->tv_usec > last->tv_usec + tout->tv_usec) return 1; } return 0; } int lnstat_update(struct lnstat_file *lnstat_files, void (*print_cb)(struct lnstat_file *, void *), void *v) { struct lnstat_file *lf; char buf[FGETS_BUF_SIZE]; struct timeval tv; /* FIXME: for more precision we need to move this into the loop */ gettimeofday(&tv, NULL); for (lf =3D lnstat_files; lf; lf =3D lf->next) { if (time_after(&lf->last_read, &lf->interval, &tv)) { rewind(lf->fp); fgets(buf, FGETS_BUF_SIZE-1, lf->fp); scan_lines(lf, 1); (print_cb)(lf, v); rewind(lf->fp); fgets(buf, FGETS_BUF_SIZE-1, lf->fp); scan_lines(lf, 0); } } return 0; } /* scan first template line and fill in per-field data structures */ static int lnstat_scan_fields(struct lnstat_file *lf) { char buf[FGETS_BUF_SIZE]; char *tok; int i; rewind(lf->fp); fgets(buf, FGETS_BUF_SIZE-1, lf->fp); tok =3D strtok(buf, " \t\n"); for (i =3D 0; i < LNSTAT_MAX_FIELDS_PER_LINE; i++) { lf->fields[i].file =3D lf; strncpy(lf->fields[i].name, tok, LNSTAT_MAX_FIELD_NAME_LEN); /* has to be null-terminate since we initialize to zero * and field size is NAME_LEN + 1 */ tok =3D strtok(NULL, " \t\n"); if (!tok) { lf->num_fields =3D i+1; return 0; } } return 0; } /* find out whether string 'name; is in given string array */ static int name_in_array(const int num, const char **arr, const char *name) { int i; for (i =3D 0; i < num; i++) { if (!strcmp(arr[i], name)) return 1; } return 0; } /* allocate lnstat_file and open given file */ static struct lnstat_file *alloc_and_open(const char *path, const char *fil= e) { struct lnstat_file *lf; /* allocate */ lf =3D malloc(sizeof(*lf)); if (!lf) return NULL; /* initialize */ memset(lf, 0, sizeof(*lf)); /* de->d_name is guaranteed to be <=3D NAME_MAX */ strcpy(lf->basename, file); strcpy(lf->path, path); strcat(lf->path, "/"); strcat(lf->path, lf->basename); /* open */ lf->fp =3D fopen(lf->path, "r"); if (!lf->fp) { free(lf); return NULL; } return lf; } /* lnstat_scan_dir - find and parse all available statistics files/fields */ struct lnstat_file *lnstat_scan_dir(const char *path, const int num_req_fil= es, const char **req_files) { DIR *dir; struct lnstat_file *lnstat_files =3D NULL; struct dirent *de; if (!path) path =3D PROC_NET_STAT; =09 dir =3D opendir(path); if (!dir) return NULL; while (de =3D readdir(dir)) { struct lnstat_file *lf; if (de->d_type !=3D DT_REG) continue; if (num_req_files && !name_in_array(num_req_files, req_files, de->d_name)) continue; lf =3D alloc_and_open(path, de->d_name); if (!lf) return NULL; /* fill in field structure */ if (lnstat_scan_fields(lf) < 0) return NULL; /* prepend to global list */ lf->next =3D lnstat_files; lnstat_files =3D lf; } closedir(dir); return lnstat_files; } int lnstat_dump(FILE *outfd, struct lnstat_file *lnstat_files) { struct lnstat_file *lf; for (lf =3D lnstat_files; lf; lf =3D lf->next) { int i; fprintf(outfd, "%s:\n", lf->path); for (i =3D 0; i < lf->num_fields; i++) fprintf(outfd, "\t%2u: %s\n", i+1, lf->fields[i].name); } return 0; } static struct option opts[] =3D { { "version", 0, NULL, 'V' }, { "help", 0, NULL, 'h' }, { "interval", 1, NULL, 'i' }, { "subject", 1, NULL, 's' }, { "file", 1, NULL, 'f' }, { "key", 1, NULL, 'k' }, }; static int usage(char *name, int exit_code) { fprintf(stderr, "%s Version %s\n", name, LNSTAT_VERSION); fprintf(stderr, "Copyright (C) 2004 by Harald Welte " "\n"); fprintf(stderr, "This program is free software with ABSOLUTELY NO " "WARRANTY.\n\n"); fprintf(stderr, "Parameters:\n"); fprintf(stderr, "\t-h --help\t\tThis help message\n"); fprintf(stderr, "\t-i --interval\t\tSet interval\n"); fprintf(stderr, "\t-s --subject [0-2]\t?\n");=09 fprintf(stderr, "\t-f --file\t\tStatistics file to use\n");=09 fprintf(stderr, "\n");=09 exit(exit_code); } static void print_cb(struct lnstat_file *lf, void *v) { int i; int *interval =3D v; for (i =3D 0; i < lf->num_fields; i++) { unsigned long val =3D (lf->fields[i].values[1] -lf->fields[i].values[0])/(*interval); fprintf(stdout, "%5lu ", val); } fputc('\n', stdout); } int main(int argc, char **argv) { char *basename; int c, i =3D 1, interval =3D 2, hdr =3D 2; struct lnstat_file *lnstat_files; int num_req_files =3D 0, num_req_keys =3D 0; char *req_files[LNSTAT_MAX_FILES]; char *req_keys[LNSTAT_MAX_FILES*LNSTAT_MAX_FIELDS_PER_LINE]; =20 /* backwards compatibility mode for old tools */ basename =3D strrchr(argv[0], '/') + 1; if (!strcmp(basename, "rtstat")) { /* rtstat compatibility mode */ req_files[0] =3D "rt_cache"; num_req_files =3D 1; } else if (!strcmp(basename, "ctstat")) { /* ctstat compatibility mode */ req_files[0] =3D "ip_conntrack"; num_req_files =3D 1; } while ((c =3D getopt_long(argc, argv,"Vh?s:i:f:k:", opts, NULL)) !=3D -1) switch (c) { case '?': case 'h': =20 usage(argv[0], 0); case 'i': sscanf(optarg, "%u", &interval); break; case 's': sscanf(optarg, "%u", &hdr); break; case 'f': req_files[num_req_files++] =3D strdup(optarg); break; case 'k': req_keys[num_req_keys++] =3D strdup(optarg); break; default: usage(argv[0], 1); } if (interval < 1 )=20 interval=3D1; lnstat_files =3D lnstat_scan_dir(PROC_NET_STAT, num_req_files, req_files); lnstat_dump(stderr, lnstat_files); for (; 1; i++) { #if 0 if (hdr > 1 && (! (i % 20))) print_hdr_line(); #endif lnstat_update(lnstat_files, &print_cb, &interval); sleep(interval); } return 1; } --fU0UwhtRbpo05rnG-- --uuKVzAmB+c+zQlhu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWXtJXaXGVTD0i/8RAiJQAJ9Zfau0Ju3Mtkt0IYO+YYBMdlp0UACfcdXR gCe+jopUPtxzHY1eaI35pNY= =zDdd -----END PGP SIGNATURE----- --uuKVzAmB+c+zQlhu-- From jgarzik@pobox.com Tue Sep 28 08:05:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 08:05:40 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SF5Y86003388 for ; Tue, 28 Sep 2004 08:05:35 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCJXd-0004Kw-Ni; Tue, 28 Sep 2004 16:05:21 +0100 Message-ID: <41597DA4.5040200@pobox.com> Date: Tue, 28 Sep 2004 11:05:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ravinandan.arakali@s2io.com CC: netdev@oss.sgi.com, leonid.grossman@s2io.com, raghavendra.koushik@s2io.com, rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel References: <005801c4a4f4$1598d6d0$a010100a@S2IOtech.com> In-Reply-To: <005801c4a4f4$1598d6d0$a010100a@S2IOtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 846 Lines: 25 Ravinandan Arakali wrote: > Hi, > Attached are the updated patches. It is designed to work on the latest > kernel. Also, this time the submission is split to 3 patches(they need > to applied in the order mentioned below). > > s2io_styling_level1 - Contains > a. styling related, function name changes. > b. fix for 32-bit systems. > c. modified Transmit descriptor allocation > strategy. > d. miscellaneous fixes. When we say "separate logical changes", we mean it :) This means that your level1 patch should be split into at least 4 patches. Second, send each patch in a separate email, as described in http://linux.yyz.us/patch-format.html (and Documentation/SubmittingPatches) rather than sending as a tarball. Jeff From Robert.Olsson@data.slu.se Tue Sep 28 08:18:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 08:18:28 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SFIMmb003831 for ; Tue, 28 Sep 2004 08:18:23 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8SFHpY2021637; Tue, 28 Sep 2004 17:17:51 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 5E23E90265; Tue, 28 Sep 2004 17:17:51 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16729.32927.352234.634227@robur.slu.se> Date: Tue, 28 Sep 2004 17:17:51 +0200 To: Harald Welte Cc: Robert Olsson , Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) In-Reply-To: <20040928145505.GH29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <20040928145505.GH29961@sunbeam.de.gnumonks.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 396 Lines: 13 Harald Welte writes: > Here goes some initial client code, so you can actually test the new > proc files from kernel. > > As stated above, I'll continue working on this until it's somewhat > more feature-complete. OK! Seems pretty generic, maybe the stats info for headers could be read from current kernels /proc? to keep kernel stats in sync with this user app? Cheers. --ro From shemminger@osdl.org Tue Sep 28 09:09:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 09:09:40 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SG9WGw008656 for ; Tue, 28 Sep 2004 09:09:33 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8SG8pv13560; Tue, 28 Sep 2004 09:08:51 -0700 Subject: Re: [PATCH] (1/3) tcp - choose congestion algorithm at initialization From: Stephen Hemminger To: "David S. Miller" Cc: Herbert Xu , davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <20040927225858.3a1665f1.davem@davemloft.net> References: <20040927111834.48c7baab@zqx3.pdx.osdl.net> <20040927225858.3a1665f1.davem@davemloft.net> Content-Type: text/plain Organization: Open Source Development Lab Date: Tue, 28 Sep 2004 09:08:54 -0700 Message-Id: <1096387734.21799.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 864 Lines: 21 On Mon, 2004-09-27 at 22:58 -0700, David S. Miller wrote: > On Tue, 28 Sep 2004 08:07:36 +1000 > Herbert Xu wrote: > > > Stephen Hemminger wrote: > > > The choice of congestion algorithm needs to be made when connection > > > is setup to avoid problems when the sysctl values change later and the > > > necessary data hasn't been collected. > > > > Could this be chosen by a setsockopt as well? > > If we export such things with a user visible > interface, that makes it harder to rip out the > congestion control algorithm later. Such an > action is very likely so... The current set of algorithm's is because we haven't found the right one. If it turns out there are multiple algortihm's that make sense to support long term, then the choice should be done in as route hints not as part of the user API. From laforge@gnumonks.org Tue Sep 28 09:24:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 09:25:04 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SGOmbH009285 for ; Tue, 28 Sep 2004 09:24:49 -0700 Received: from dsl-213-023-152-188.arcor-ip.net ([213.23.152.188] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CCKmK-0007hP-5G; Tue, 28 Sep 2004 18:24:36 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CCKmF-00083H-F0; Tue, 28 Sep 2004 18:24:31 +0200 Date: Tue, 28 Sep 2004 18:24:31 +0200 From: Harald Welte To: Robert Olsson Cc: Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) Message-ID: <20040928162431.GK29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <20040928145505.GH29961@sunbeam.de.gnumonks.org> <16729.32927.352234.634227@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CaPKgh3XHpq3rEUV" Content-Disposition: inline In-Reply-To: <16729.32927.352234.634227@robur.slu.se> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1731 Lines: 54 --CaPKgh3XHpq3rEUV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2004 at 05:17:51PM +0200, Robert Olsson wrote: >=20 > Harald Welte writes: > > Here goes some initial client code, so you can actually test the new > > proc files from kernel. > >=20 > > As stated above, I'll continue working on this until it's somewhat > > more feature-complete. >=20 > OK! Seems pretty generic, maybe the stats info for headers could be read= =20 > from current kernels /proc? to keep kernel stats in sync with this user = app? that's what it intends to do. The field names are all stored in 'lnstat_field.name', so it is easy to build that line. However, it has to be multiple-line, since the field names from the kernel are sometimes quite long... The only difference is that it won't show you "IN: hits" but rather "in_hits" which I think we can safely ignore. > Cheers. > --ro --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --CaPKgh3XHpq3rEUV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWZA/XaXGVTD0i/8RAiG5AJ9cf++NW+ZRlCGCXgEY1Q4q59XCgQCfWvUD CkMigVE1ZLiuIAzQODinuc0= =EG7I -----END PGP SIGNATURE----- --CaPKgh3XHpq3rEUV-- From shemminger@osdl.org Tue Sep 28 09:28:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 09:28:27 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SGSLSi009633 for ; Tue, 28 Sep 2004 09:28:21 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8SGRYv16998; Tue, 28 Sep 2004 09:27:34 -0700 Subject: Re: [6/6]: jenkins hash for neigh / Statistics From: Stephen Hemminger To: Robert Olsson Cc: "David S. Miller" , Harald Welte , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <16729.9326.93269.422940@robur.slu.se> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> Content-Type: text/plain Organization: Open Source Development Lab Date: Tue, 28 Sep 2004 09:27:37 -0700 Message-Id: <1096388857.21799.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1245 Lines: 26 On Tue, 2004-09-28 at 10:44 +0200, Robert Olsson wrote: > Stephen Hemminger writes: > > > > Harald Welte wrote: > > > > > > > As stated before, I would like to change rt_stat and ct_stat in order to > > > > include a first 'template' line, too. This way it is easier to write a > > > > generic foo_stat program, that could deal with any of those statistics > > > > files, even with new ones... but this of course would break existing > > > > rtstat binaries. I personally don't care, since it's a little-known > > > > and little-used feature, which to my knowledge is in a lot of > > > > distributions either non-existant [Debian] or incompatible [SuSE]. What > > > > do you think? > > > > > > I agree. And while we're add it let's get a fixed rtstat into > > > iproute2 and make sure that binary gets installed by default > > > so maybe the dists will start shipping it properly. > > > > I have the old one in the repository. > > I sent you the latest rtstat (Martin sent ctstat) during netfilter workshop. > Remember? Having a common foo_stat sounds like a good idea. I have the newer rtstat/ctstat queued for inclusion this week unless Harald get's his newer one done sooner (hint, hint) From greearb@candelatech.com Tue Sep 28 09:52:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 09:53:08 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SGquFD011809 for ; Tue, 28 Sep 2004 09:52:56 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8SGuiLH005537; Tue, 28 Sep 2004 09:56:45 -0700 Message-ID: <415996DC.4030509@candelatech.com> Date: Tue, 28 Sep 2004 09:52:44 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral , "'netdev@oss.sgi.com'" Subject: Re: small change References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1627 Lines: 66 Vishwas Manral wrote: > Hi Ben, > > I am going through the 2.4 code. We can make small changes in br_input.c > to make the code slightly better and slightly more optimized. Maybe when > you are changing something else you can club it along. Please send this to the netdev mailing list: netdev@oss.sgi.com I don't maintain the bridging code but there are people on that list who do. They would also prefer a unified diff instead of the cut-n-paste like you sent. Thanks, Ben > > Thanks, > Vishwas > > ======================================================================== > ======= > Change from -> > > 87 if (dst != NULL && dst->is_local) { > 88 if (!passedup) > 89 br_pass_frame_up(br, skb); > 90 else > 91 kfree_skb(skb); > 92 br_fdb_put(dst); > 93 goto out; > 94 } > 95 > 96 if (dst != NULL) { > 97 br_forward(dst->dst, skb); > 98 br_fdb_put(dst); > 99 goto out; > 100 } > > To -> > > 87 if (dst != NULL) { > if(dst->is_local) { > 88 if (!passedup) > 89 br_pass_frame_up(br, skb); > 90 else > 91 kfree_skb(skb); > } else { > 97 br_forward(dst->dst, skb); > } > 92 br_fdb_put(dst); > 93 goto out; > 94 } > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ravinandan.arakali@s2io.com Tue Sep 28 10:07:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 10:07:40 -0700 (PDT) Received: from ns1.s2io.com ([142.46.200.198]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SH7YQe012435 for ; Tue, 28 Sep 2004 10:07:35 -0700 Received: from guinness.s2io.com (sentry [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i8SH74je005349; Tue, 28 Sep 2004 13:07:05 -0400 (EDT) Received: from rarakali ([10.16.16.160]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id i8SH6u39012134; Tue, 28 Sep 2004 13:07:02 -0400 (EDT) Reply-To: From: "Ravinandan Arakali" To: "'Jeff Garzik'" Cc: , , , Subject: RE: Patch submission for S2io Xframe driver to 2.6 kernel Date: Tue, 28 Sep 2004 10:13:48 -0700 Message-ID: <002b01c4a57e$84da0700$a010100a@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41597DA4.5040200@pobox.com> Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 9606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@s2io.com Precedence: bulk X-list: netdev Content-Length: 1342 Lines: 42 Hi Jeff, Randy, We are sorry about that. We will split the first patch into multiple smaller patches and resubmit them one-by-one. We appreciate all your patience. Regards, Ravi -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Tuesday, September 28, 2004 8:05 AM To: ravinandan.arakali@s2io.com Cc: netdev@oss.sgi.com; leonid.grossman@s2io.com; raghavendra.koushik@s2io.com; rapuru.sriram@s2io.com Subject: Re: Patch submission for S2io Xframe driver to 2.6 kernel Ravinandan Arakali wrote: > Hi, > Attached are the updated patches. It is designed to work on the latest > kernel. Also, this time the submission is split to 3 patches(they need > to applied in the order mentioned below). > > s2io_styling_level1 - Contains > a. styling related, function name changes. > b. fix for 32-bit systems. > c. modified Transmit descriptor allocation > strategy. > d. miscellaneous fixes. When we say "separate logical changes", we mean it :) This means that your level1 patch should be split into at least 4 patches. Second, send each patch in a separate email, as described in http://linux.yyz.us/patch-format.html (and Documentation/SubmittingPatches) rather than sending as a tarball. Jeff From laforge@gnumonks.org Tue Sep 28 10:07:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 10:07:05 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SH6xBT012327 for ; Tue, 28 Sep 2004 10:07:00 -0700 Received: from dsl-213-023-152-188.arcor-ip.net ([213.23.152.188] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CCLR8-0008Hj-Hh; Tue, 28 Sep 2004 19:06:46 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CCLR6-00084j-EV; Tue, 28 Sep 2004 19:06:44 +0200 Date: Tue, 28 Sep 2004 19:06:44 +0200 From: Harald Welte To: Stephen Hemminger Cc: Robert Olsson , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [6/6]: jenkins hash for neigh / Statistics Message-ID: <20040928170644.GL29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <1096388857.21799.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qse+WBH4guesipZ+" Content-Disposition: inline In-Reply-To: <1096388857.21799.5.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1186 Lines: 37 --qse+WBH4guesipZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =20 > I have the newer rtstat/ctstat queued for inclusion this week unless > Harald get's his newer one done sooner (hint, hint) well, the new version currently provides backwards compatibility for the old commands, but it doesn't support old kernels... I'll see how I can integrate that. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --qse+WBH4guesipZ+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWZokXaXGVTD0i/8RAvbBAJ9b2KR+CJ12RHX6LG+oOF2a5XAluwCgiBau rzwkovKFFNyXFq1iDGhFtus= =JRPQ -----END PGP SIGNATURE----- --qse+WBH4guesipZ+-- From jgarzik@pobox.com Tue Sep 28 11:07:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 11:07:07 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SI6xUh013781 for ; Tue, 28 Sep 2004 11:07:00 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCMNB-0001E8-E5; Tue, 28 Sep 2004 19:06:45 +0100 Message-ID: <4159A828.2060508@pobox.com> Date: Tue, 28 Sep 2004 14:06:32 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear , Vishwas Manral CC: "'netdev@oss.sgi.com'" Subject: Re: small change References: <415996DC.4030509@candelatech.com> In-Reply-To: <415996DC.4030509@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 730 Lines: 29 Ben Greear wrote: > Vishwas Manral wrote: > >> Hi Ben, >> >> I am going through the 2.4 code. We can make small changes in br_input.c >> to make the code slightly better and slightly more optimized. Maybe when >> you are changing something else you can club it along. > > > Please send this to the netdev mailing list: > > netdev@oss.sgi.com > > I don't maintain the bridging code but there are people on > that list who do. > > They would also prefer a unified diff instead of the cut-n-paste > like you sent. Regarding submission of patches, more specifically: http://linux.yyz.us/patch-format.html http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and Documentation/SubmittingPatches in the kernel tree. Jeff From davem@davemloft.net Tue Sep 28 11:25:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 11:25:33 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SIPIKX014310 for ; Tue, 28 Sep 2004 11:25:19 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCMeO-00077n-00; Tue, 28 Sep 2004 11:24:32 -0700 Date: Tue, 28 Sep 2004 11:24:32 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, pablo@eurodev.net, netdev@oss.sgi.com Subject: Re: On DaveMs congestion control algorithm WAS(Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040928112432.238f433c.davem@davemloft.net> In-Reply-To: <1096375188.8663.226.camel@jzny.localdomain> References: <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <20040928121647.GA21121@gondor.apana.org.au> <1096375188.8663.226.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 843 Lines: 22 On 28 Sep 2004 08:39:49 -0400 jamal wrote: > On Tue, 2004-09-28 at 08:16, Herbert Xu wrote: > > On Tue, Sep 28, 2004 at 09:11:59PM +1000, herbert wrote: > > > > > > > BTW, Davem gets away with this congestion control alg all the time. > > > > Heck i think his sanity survives because of it - I bet you hes got this > > > > thread under congestion controlled right now;-> > > > > > > Yep, his overrun flag sure is set :) > > > > Now if he puts his mailing admin hat on and tells us to shut up, that > > would be congestion control :) > > Hed have to go and read all the emails first ;-> i.e the overrun flag > requires that you reread state. When I see two guys going at it like you too, I just wait for the dust to settle in the form of a patch and then I reread the thread as if it were the latest drama show on TV :-) From shemminger@osdl.org Tue Sep 28 11:47:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 11:47:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SIl09o015727 for ; Tue, 28 Sep 2004 11:47:01 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8SIkYv10861; Tue, 28 Sep 2004 11:46:36 -0700 Subject: Re: [PATCH] [iproute2] XFRM: support ICMP/ICMPv6's type and code From: Stephen Hemminger To: Masahide Nakamura Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20040906164742.54795bf4@localhost> References: <20040906164742.54795bf4@localhost> Content-Type: text/plain Organization: Open Source Development Lab Date: Tue, 28 Sep 2004 11:46:37 -0700 Message-Id: <1096397197.21799.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 256 Lines: 6 On Mon, 2004-09-06 at 16:47 +0900, Masahide Nakamura wrote: > This patch supports ICMP/ICMPv6's type and code in IPsec > selector. Kernel has supported this feature from 2.6.9-rc1. The set of XFRM related patches are in the latest version due this week. From jt@bougret.hpl.hp.com Tue Sep 28 11:46:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 11:46:43 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SIkcHx015680 for ; Tue, 28 Sep 2004 11:46:38 -0700 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 7D23B546A; Tue, 28 Sep 2004 11:46:26 -0700 (PDT) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id LAA14022; Tue, 28 Sep 2004 11:49:55 -0700 (PDT) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1CCMzZ-0002Aj-00; Tue, 28 Sep 2004 11:46:25 -0700 Date: Tue, 28 Sep 2004 11:46:25 -0700 To: Jeff Garzik , netdev@oss.sgi.com Subject: WE-17 typo fix Message-ID: <20040928184625.GA8299@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 9609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 784 Lines: 25 Hi Jeff, Felix R. found a typo in the WE-17 patch I sent you and is pending in your tree (more correctly, an overzealous search&replace). The patch below fix this mistake. I would appreciate you adding this patch to your tree ;-) Have fun... Jean ------------------------------------------------------------------ diff -u -p linux/net/core/wireless.we17.c linux/net/core/wireless.c --- linux/net/core/wireless.we17.c Tue Sep 28 11:34:04 2004 +++ linux/net/core/wireless.c Tue Sep 28 11:34:33 2004 @@ -867,7 +867,7 @@ static inline int ioctl_private_call(str return -EFAULT; /* Does it fits within bounds ? */ - if(iwr->u.data.length > (descr->get_args & + if(iwr->u.data.length > (descr->set_args & IW_PRIV_SIZE_MASK)) return -E2BIG; } else { From linville@ra.tuxdriver.com Tue Sep 28 13:08:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 13:08:37 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SK8Mq3021785 for ; Tue, 28 Sep 2004 13:08:22 -0700 Received: (from linville@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) id i8SIsuZ16323; Tue, 28 Sep 2004 14:54:56 -0400 Date: Tue, 28 Sep 2004 14:54:55 -0400 From: "John W. Linville" To: akpm@osdl.org Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod Message-ID: <20040928145455.C12480@tuxdriver.com> Mail-Followup-To: akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 9611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 1110 Lines: 30 Some (earlier?) versions of the 3c905(B) card get confused and refuse to work again after the 3c59x module is removed (even after reloading the module). Changing vortex_remove_one() to allow the auto-initialize state machine logic to be reset when the module is removed alleviates this problem. Signed-off-by: John W. Linville --- See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133388 for more details. If anyone can suggest a better way to fix this problem, please do so. I'll be happy to pursue it. drivers/net/3c59x.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) This patch should apply (with a little fuzz) to 2.4 as well... --- linux-2.6/drivers/net/3c59x.c.orig +++ linux-2.6/drivers/net/3c59x.c @@ -3162,7 +3162,7 @@ static void __devexit vortex_remove_one pci_restore_state(VORTEX_PCI(vp), vp->power_state); } /* Should really use issue_and_wait() here */ - outw(TotalReset|0x14, dev->base_addr + EL3_CMD); + outw(TotalReset|0x04, dev->base_addr + EL3_CMD); pci_free_consistent(pdev, sizeof(struct boom_rx_desc) * RX_RING_SIZE From vkondra@mail.ru Tue Sep 28 13:30:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 13:31:12 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SKUrEG022343 for ; Tue, 28 Sep 2004 13:30:53 -0700 Received: from [81.218.92.214] (port=27397 helo=[192.168.10.2]) by mx2.mail.ru with esmtp id 1CCOcP-000Jtp-00; Wed, 29 Sep 2004 00:30:39 +0400 From: Vladimir Kondratiev To: "Luis R. Rodriguez" Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Tue, 28 Sep 2004 22:29:48 +0200 User-Agent: KMail/1.7 Cc: greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <413F70F0.6020709@atheros.com> <20040928122028.GK30131@ruslug.rutgers.edu> In-Reply-To: <20040928122028.GK30131@ruslug.rutgers.edu> MIME-Version: 1.0 Message-Id: <200409282229.53349.vkondra@mail.ru> Content-Type: multipart/signed; boundary="nextPart15673523.bRENPlNFVd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-archive-position: 9612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 1085 Lines: 38 --nextPart15673523.bRENPlNFVd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote: LR> RFC: what are the chances we can implement our own generic "softmac" th= at may LR> be usable by the different chipsets out there? Coming days, I will submit "framework" consisting of stack based on Dave's= =20 code and debug driver which will be able to imitate Rx. I have working basi= c=20 Tx/Rx. Then, I'd like to concentrate on interfaces stack-driver and=20 stack-upper layers. It would be great if someone will do MAC algorithms. I'= ll=20 appreciate this for sure. Vladimir. P.S. My ... provider complains about "too many recipients". I removed one o= r=20 2. Sorry. --nextPart15673523.bRENPlNFVd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBWcnBqxdj7mhC6o0RAsZVAJ0ZEXrrodpotOLgYIWN8x8+w7oeLACfXfvE zVu9wkndLuqAVfgxYV856eQ= =gsqL -----END PGP SIGNATURE----- --nextPart15673523.bRENPlNFVd-- From davem@davemloft.net Tue Sep 28 13:39:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 13:40:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SKdrrH022779 for ; Tue, 28 Sep 2004 13:39:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCOk3-0000Dh-00; Tue, 28 Sep 2004 13:38:31 -0700 Date: Tue, 28 Sep 2004 13:38:30 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: herbert@gondor.apana.org.au, jheffner@psc.edu, ak@suse.de, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040928133830.1eba4476.davem@davemloft.net> In-Reply-To: <415910D2.7010808@us.ibm.com> References: <20040923161141.4ea9be4c.davem@davemloft.net> <20040927160411.22b44f48.davem@davemloft.net> <20040927233639.GA8333@gondor.apana.org.au> <20040927171356.6a59d039.davem@davemloft.net> <415910D2.7010808@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 755 Lines: 22 On Tue, 28 Sep 2004 00:20:50 -0700 Nivedita Singhvi wrote: > David S. Miller wrote: > > > Bright minds think alike. :-) We have to keep all the other > > packet counts in sync as well. > > > > Andi, others, forget my previous hack patch to tcp_clean_rtx_queue() > > and give this more complete patch a try. > > > > I'm getting really good results here on my tg3<-->tg3 setup using > > this patch. > > Dave, were you seeing a significant number of retransmissions > and sacks in your tests? None. I am working on a local network through a gigabit switch. I will work on making sure cases involving loss work correctly, via the netem module, before I submit these fixes upstream to Linus. Likely I will complete this work today. From pablo@eurodev.net Tue Sep 28 14:09:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:09:47 -0700 (PDT) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SL9TkC023526 for ; Tue, 28 Sep 2004 14:09:30 -0700 Received: from eurodev.net ([217.217.186.148]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040928210909.QMDY10464.smtp09.retemail.es@eurodev.net>; Tue, 28 Sep 2004 23:09:09 +0200 Message-ID: <4159D278.4060809@eurodev.net> Date: Tue, 28 Sep 2004 23:07:04 +0200 From: Pablo Neira User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets References: <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> In-Reply-To: <1096367787.8662.146.camel@jzny.localdomain> Content-Type: multipart/mixed; boundary="------------000001000007080107080702" X-archive-position: 9614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pablo@eurodev.net Precedence: bulk X-list: netdev Content-Length: 1426 Lines: 41 This is a multi-part message in MIME format. --------------000001000007080107080702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, If buffer overruns we lost all the messages which are enqueued, so before enqueing the packet, we can check if there's space available in the buffer. I think that this way we can save these messages at least. I'm also thinking in doing something with netlink_ack's since they can be drop if buffer is full. We could give more priority to error messages in some way, for example, check if there's space for an error message in the buffer, if there's not, drop as many packets in buffer as we get space to enqueue the error message. regards, Pablo --------------000001000007080107080702 Content-Type: text/x-patch; name="unicast-dont-overrun.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unicast-dont-overrun.patch" ===== net/netlink/af_netlink.c 1.58 vs edited ===== --- 1.58/net/netlink/af_netlink.c Sat Sep 25 17:43:43 2004 +++ edited/net/netlink/af_netlink.c Tue Sep 28 22:23:44 2004 @@ -475,7 +475,7 @@ if (nlk->handler) return 0; #endif - if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf || + if (atomic_read(&sk->sk_rmem_alloc) + skb->len > sk->sk_rcvbuf || test_bit(0, &nlk->state)) { DECLARE_WAITQUEUE(wait, current); if (!timeo) { --------------000001000007080107080702-- From davem@davemloft.net Tue Sep 28 14:14:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:14:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLEFkM023910 for ; Tue, 28 Sep 2004 14:14:16 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCPEY-0000H2-00; Tue, 28 Sep 2004 14:10:02 -0700 Date: Tue, 28 Sep 2004 14:10:02 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040928141002.164c60af.davem@davemloft.net> In-Reply-To: <20040927213233.GC7243@gondor.apana.org.au> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__28_Sep_2004_14_10_02_-0700_PMi3HGoCMW+xeS.N" X-archive-position: 9615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 10239 Lines: 165 This is a multi-part message in MIME format. --Multipart=_Tue__28_Sep_2004_14_10_02_-0700_PMi3HGoCMW+xeS.N Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 28 Sep 2004 07:32:33 +1000 Herbert Xu wrote: > On Mon, Sep 27, 2004 at 12:01:54PM -0700, David S. Miller wrote: > > > > > tcp_current_mss() doesn't call tcp_sync_mss() unless the PMTU changes. > > > > Good catch, probably we should make it do so when sk_route_caps > > indicates we are doing TSO. > > Alternatively we could move the TSO code out of tcp_sync_mss() and > put it in tcp_current_mss() instead. It seems to be the only one > using the factor anyway. Ok, here are 2 patches incorporating all of the things we discussed in this area: 1) Uninline tcp_current_mss(), fix tcp_sync_mss() return value to match tcp_current_mss()'s 2) Fix the do_large calculation bug in tcp_current_mss() as per Herbert's original patch. 3) Move TSO mss calculation work to tcp_current_mss(). We have to do something like this since tcp_sync_mss() is only invoked when the PMTU changes whereas the TSO MTU is dependant upon both the path and the current congestion window. So, this patch should wrap up these issues. --Multipart=_Tue__28_Sep_2004_14_10_02_-0700_PMi3HGoCMW+xeS.N Content-Type: application/octet-stream; name="diff1" Content-Disposition: attachment; filename="diff1" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMTM6MjY6NTQtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IFVuaW5saW5lIHRjcF9jdXJyZW50X21zcygpLgojICAgCiMg ICBBbHNvIGZpeCB0aGUgcmV0dXJuIHZhbHVlIG9mIHRjcF9zeW5jX21zcygpIHRvCiMgICBiZSB1 bnNpZ25lZC4KIyAgIAojICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBk YXZlbWxvZnQubmV0PgojIAojIG5ldC9pcHY0L3RjcF9vdXRwdXQuYwojICAgMjAwNC8wOS8yOCAx MzoyNjowMS0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzMxIC0xCiMgICBbVENQXTog VW5pbmxpbmUgdGNwX2N1cnJlbnRfbXNzKCkuCiMgCiMgaW5jbHVkZS9uZXQvdGNwLmgKIyAgIDIw MDQvMDkvMjggMTM6MjY6MDAtMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsyIC0zMgoj ICAgW1RDUF06IFVuaW5saW5lIHRjcF9jdXJyZW50X21zcygpLgojIApkaWZmIC1OcnUgYS9pbmNs dWRlL25ldC90Y3AuaCBiL2luY2x1ZGUvbmV0L3RjcC5oCi0tLSBhL2luY2x1ZGUvbmV0L3RjcC5o CTIwMDQtMDktMjggMTM6NDk6MjIgLTA3OjAwCisrKyBiL2luY2x1ZGUvbmV0L3RjcC5oCTIwMDQt MDktMjggMTM6NDk6MjIgLTA3OjAwCkBAIC05NjEsNyArOTYxLDggQEAKIAogZXh0ZXJuIHZvaWQg dGNwX2RlbGV0ZV9rZWVwYWxpdmVfdGltZXIgKHN0cnVjdCBzb2NrICopOwogZXh0ZXJuIHZvaWQg dGNwX3Jlc2V0X2tlZXBhbGl2ZV90aW1lciAoc3RydWN0IHNvY2sgKiwgdW5zaWduZWQgbG9uZyk7 Ci1leHRlcm4gaW50IHRjcF9zeW5jX21zcyhzdHJ1Y3Qgc29jayAqc2ssIHUzMiBwbXR1KTsKK2V4 dGVybiB1bnNpZ25lZCBpbnQgdGNwX3N5bmNfbXNzKHN0cnVjdCBzb2NrICpzaywgdTMyIHBtdHUp OworZXh0ZXJuIHVuc2lnbmVkIGludCB0Y3BfY3VycmVudF9tc3Moc3RydWN0IHNvY2sgKnNrLCBp bnQgbGFyZ2UpOwogCiBleHRlcm4gY29uc3QgY2hhciB0aW1lcl9idWdfbXNnW107CiAKQEAgLTEw MzMsMzcgKzEwMzQsNiBAQAogCWRlZmF1bHQ6CiAJCXByaW50ayh0aW1lcl9idWdfbXNnKTsKIAl9 OwotfQotCi0vKiBDb21wdXRlIHRoZSBjdXJyZW50IGVmZmVjdGl2ZSBNU1MsIHRha2luZyBTQUNL cyBhbmQgSVAgb3B0aW9ucywKLSAqIGFuZCBldmVuIFBNVFUgZGlzY292ZXJ5IGV2ZW50cyBpbnRv IGFjY291bnQuCi0gKgotICogTEFSR0VTRU5EIG5vdGU6ICF1cmdfbW9kZSBpcyBvdmVya2lsbCwg b25seSBmcmFtZXMgdXAgdG8gc25kX3VwCi0gKiBjYW5ub3QgYmUgbGFyZ2UuIEhvd2V2ZXIsIHRh a2luZyBpbnRvIGFjY291bnQgcmFyZSB1c2Ugb2YgVVJHLCB0aGlzCi0gKiBpcyBub3QgYSBiaWcg Zmxhdy4KLSAqLwotCi1zdGF0aWMgaW5saW5lIHVuc2lnbmVkIGludCB0Y3BfY3VycmVudF9tc3Mo c3RydWN0IHNvY2sgKnNrLCBpbnQgbGFyZ2UpCi17Ci0Jc3RydWN0IHRjcF9vcHQgKnRwID0gdGNw X3NrKHNrKTsKLQlzdHJ1Y3QgZHN0X2VudHJ5ICpkc3QgPSBfX3NrX2RzdF9nZXQoc2spOwotCWlu dCBkb19sYXJnZSwgbXNzX25vdzsKLQotCWRvX2xhcmdlID0gKGxhcmdlICYmCi0JCSAgICAoc2st PnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykgJiYKLQkJICAgICF0cC0+dXJnX21vZGUpOwot CW1zc19ub3cgPSBkb19sYXJnZSA/IHRwLT5tc3NfY2FjaGUgOiB0cC0+bXNzX2NhY2hlX3N0ZDsK LQotCWlmIChkc3QpIHsKLQkJdTMyIG10dSA9IGRzdF9wbXR1KGRzdCk7Ci0JCWlmIChtdHUgIT0g dHAtPnBtdHVfY29va2llIHx8Ci0JCSAgICB0cC0+ZXh0Ml9oZWFkZXJfbGVuICE9IGRzdC0+aGVh ZGVyX2xlbikKLQkJCW1zc19ub3cgPSB0Y3Bfc3luY19tc3Moc2ssIG10dSk7Ci0JfQotCWlmICh0 cC0+ZWZmX3NhY2tzKQotCQltc3Nfbm93IC09IChUQ1BPTEVOX1NBQ0tfQkFTRV9BTElHTkVEICsK LQkJCSAgICAodHAtPmVmZl9zYWNrcyAqIFRDUE9MRU5fU0FDS19QRVJCTE9DSykpOwotCXJldHVy biBtc3Nfbm93OwogfQogCiAvKiBJbml0aWFsaXplIFJDVl9NU1MgdmFsdWUuCmRpZmYgLU5ydSBh L25ldC9pcHY0L3RjcF9vdXRwdXQuYyBiL25ldC9pcHY0L3RjcF9vdXRwdXQuYwotLS0gYS9uZXQv aXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0yOCAxMzo0OToyMiAtMDc6MDAKKysrIGIvbmV0L2lw djQvdGNwX291dHB1dC5jCTIwMDQtMDktMjggMTM6NDk6MjIgLTA3OjAwCkBAIC02MDMsNyArNjAz LDcgQEAKICAgIHRoaXMgZnVuY3Rpb24uCQkJLS1BTksgKDk4MDczMSkKICAqLwogCi1pbnQgdGNw X3N5bmNfbXNzKHN0cnVjdCBzb2NrICpzaywgdTMyIHBtdHUpCit1bnNpZ25lZCBpbnQgdGNwX3N5 bmNfbXNzKHN0cnVjdCBzb2NrICpzaywgdTMyIHBtdHUpCiB7CiAJc3RydWN0IHRjcF9vcHQgKnRw ID0gdGNwX3NrKHNrKTsKIAlzdHJ1Y3QgZHN0X2VudHJ5ICpkc3QgPSBfX3NrX2RzdF9nZXQoc2sp OwpAQCAtNjYxLDYgKzY2MSwzNiBAQAogCXJldHVybiBtc3Nfbm93OwogfQogCisvKiBDb21wdXRl IHRoZSBjdXJyZW50IGVmZmVjdGl2ZSBNU1MsIHRha2luZyBTQUNLcyBhbmQgSVAgb3B0aW9ucywK KyAqIGFuZCBldmVuIFBNVFUgZGlzY292ZXJ5IGV2ZW50cyBpbnRvIGFjY291bnQuCisgKgorICog TEFSR0VTRU5EIG5vdGU6ICF1cmdfbW9kZSBpcyBvdmVya2lsbCwgb25seSBmcmFtZXMgdXAgdG8g c25kX3VwCisgKiBjYW5ub3QgYmUgbGFyZ2UuIEhvd2V2ZXIsIHRha2luZyBpbnRvIGFjY291bnQg cmFyZSB1c2Ugb2YgVVJHLCB0aGlzCisgKiBpcyBub3QgYSBiaWcgZmxhdy4KKyAqLworCit1bnNp Z25lZCBpbnQgdGNwX2N1cnJlbnRfbXNzKHN0cnVjdCBzb2NrICpzaywgaW50IGxhcmdlKQorewor CXN0cnVjdCB0Y3Bfb3B0ICp0cCA9IHRjcF9zayhzayk7CisJc3RydWN0IGRzdF9lbnRyeSAqZHN0 ID0gX19za19kc3RfZ2V0KHNrKTsKKwlpbnQgZG9fbGFyZ2UsIG1zc19ub3c7CisKKwlkb19sYXJn ZSA9IChsYXJnZSAmJgorCQkgICAgKHNrLT5za19yb3V0ZV9jYXBzICYgTkVUSUZfRl9UU08pICYm CisJCSAgICAhdHAtPnVyZ19tb2RlKTsKKwltc3Nfbm93ID0gZG9fbGFyZ2UgPyB0cC0+bXNzX2Nh Y2hlIDogdHAtPm1zc19jYWNoZV9zdGQ7CisKKwlpZiAoZHN0KSB7CisJCXUzMiBtdHUgPSBkc3Rf cG10dShkc3QpOworCQlpZiAobXR1ICE9IHRwLT5wbXR1X2Nvb2tpZSB8fAorCQkgICAgdHAtPmV4 dDJfaGVhZGVyX2xlbiAhPSBkc3QtPmhlYWRlcl9sZW4pCisJCQltc3Nfbm93ID0gdGNwX3N5bmNf bXNzKHNrLCBtdHUpOworCX0KKwlpZiAodHAtPmVmZl9zYWNrcykKKwkJbXNzX25vdyAtPSAoVENQ T0xFTl9TQUNLX0JBU0VfQUxJR05FRCArCisJCQkgICAgKHRwLT5lZmZfc2Fja3MgKiBUQ1BPTEVO X1NBQ0tfUEVSQkxPQ0spKTsKKwlyZXR1cm4gbXNzX25vdzsKK30KIAogLyogVGhpcyByb3V0aW5l IHdyaXRlcyBwYWNrZXRzIHRvIHRoZSBuZXR3b3JrLiAgSXQgYWR2YW5jZXMgdGhlCiAgKiBzZW5k X2hlYWQuICBUaGlzIGhhcHBlbnMgYXMgaW5jb21pbmcgYWNrcyBvcGVuIHVwIHRoZSByZW1vdGUK --Multipart=_Tue__28_Sep_2004_14_10_02_-0700_PMi3HGoCMW+xeS.N Content-Type: application/octet-stream; name="diff2" Content-Disposition: attachment; filename="diff2" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMTM6NDY6NTgtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IE1vdmUgVFNPIG1zcyBjYWxjcyB0byB0Y3BfY3VycmVudF9t c3MoKQojICAgCiMgICBCYXNlZCB1cG9uIGEgYnVnIGZpeCBwYXRjaCBhbmQgc3VnZ2VzdGlvbnMg ZnJvbQojICAgSGVyYmVydCBYdSA8aGVyYmVydEBnb25kb3IuYXBhbmEub3JnLmF1PgojICAgCiMg ICBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+CiMg CiMgbmV0L2lwdjQvdGNwX291dHB1dC5jCiMgICAyMDA0LzA5LzI4IDEzOjQ2OjI4LTA3OjAwIGRh dmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArMjkgLTI0CiMgICBbVENQXTogTW92ZSBUU08gbXNzIGNh bGNzIHRvIHRjcF9jdXJyZW50X21zcygpCiMgICAKIyAgIEJhc2VkIHVwb24gYSBidWcgZml4IHBh dGNoIGFuZCBzdWdnZXN0aW9ucyBmcm9tCiMgICBIZXJiZXJ0IFh1IDxoZXJiZXJ0QGdvbmRvci5h cGFuYS5vcmcuYXU+CiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2 ZW1AZGF2ZW1sb2Z0Lm5ldD4KIyAKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvdGNwX291dHB1dC5jIGIv bmV0L2lwdjQvdGNwX291dHB1dC5jCi0tLSBhL25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA0LTA5 LTI4IDEzOjQ5OjM3IC0wNzowMAorKysgYi9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0y OCAxMzo0OTozNyAtMDc6MDAKQEAgLTYzOSwyNSArNjM5LDYgQEAKIAl0cC0+cG10dV9jb29raWUg PSBwbXR1OwogCXRwLT5tc3NfY2FjaGUgPSB0cC0+bXNzX2NhY2hlX3N0ZCA9IG1zc19ub3c7CiAK LQlpZiAoc2stPnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykgewotCQlpbnQgbGFyZ2VfbXNz LCBmYWN0b3I7Ci0KLQkJbGFyZ2VfbXNzID0gNjU1MzUgLSB0cC0+YWZfc3BlY2lmaWMtPm5ldF9o ZWFkZXJfbGVuIC0KLQkJCXRwLT5leHRfaGVhZGVyX2xlbiAtIHRwLT5leHQyX2hlYWRlcl9sZW4g LSB0cC0+dGNwX2hlYWRlcl9sZW47Ci0KLQkJaWYgKHRwLT5tYXhfd2luZG93ICYmIGxhcmdlX21z cyA+ICh0cC0+bWF4X3dpbmRvdz4+MSkpCi0JCQlsYXJnZV9tc3MgPSBtYXgoKHRwLT5tYXhfd2lu ZG93Pj4xKSwgNjhVIC0gdHAtPnRjcF9oZWFkZXJfbGVuKTsKLQotCQkvKiBBbHdheXMga2VlcCBs YXJnZSBtc3MgbXVsdGlwbGUgb2YgcmVhbCBtc3MsIGJ1dAotCQkgKiBkbyBub3QgZXhjZWVkIGNv bmdlc3Rpb24gd2luZG93LgotCQkgKi8KLQkJZmFjdG9yID0gbGFyZ2VfbXNzIC8gbXNzX25vdzsK LQkJaWYgKGZhY3RvciA+IHRwLT5zbmRfY3duZCkKLQkJCWZhY3RvciA9IHRwLT5zbmRfY3duZDsK LQotCQl0cC0+bXNzX2NhY2hlID0gbXNzX25vdyAqIGZhY3RvcjsKLQl9Ci0KIAlyZXR1cm4gbXNz X25vdzsKIH0KIApAQCAtNjc1LDE3ICs2NTYsNDEgQEAKIAlzdHJ1Y3QgZHN0X2VudHJ5ICpkc3Qg PSBfX3NrX2RzdF9nZXQoc2spOwogCWludCBkb19sYXJnZSwgbXNzX25vdzsKIAotCWRvX2xhcmdl ID0gKGxhcmdlICYmCi0JCSAgICAoc2stPnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykgJiYK LQkJICAgICF0cC0+dXJnX21vZGUpOwotCW1zc19ub3cgPSBkb19sYXJnZSA/IHRwLT5tc3NfY2Fj aGUgOiB0cC0+bXNzX2NhY2hlX3N0ZDsKLQorCW1zc19ub3cgPSB0cC0+bXNzX2NhY2hlX3N0ZDsK IAlpZiAoZHN0KSB7CiAJCXUzMiBtdHUgPSBkc3RfcG10dShkc3QpOwogCQlpZiAobXR1ICE9IHRw LT5wbXR1X2Nvb2tpZSB8fAogCQkgICAgdHAtPmV4dDJfaGVhZGVyX2xlbiAhPSBkc3QtPmhlYWRl cl9sZW4pCiAJCQltc3Nfbm93ID0gdGNwX3N5bmNfbXNzKHNrLCBtdHUpOwogCX0KKworCWRvX2xh cmdlID0gKGxhcmdlICYmCisJCSAgICAoc2stPnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykg JiYKKwkJICAgICF0cC0+dXJnX21vZGUpOworCisJaWYgKGRvX2xhcmdlKSB7CisJCWludCBsYXJn ZV9tc3MsIGZhY3RvcjsKKworCQlsYXJnZV9tc3MgPSA2NTUzNSAtIHRwLT5hZl9zcGVjaWZpYy0+ bmV0X2hlYWRlcl9sZW4gLQorCQkJdHAtPmV4dF9oZWFkZXJfbGVuIC0gdHAtPmV4dDJfaGVhZGVy X2xlbiAtCisJCQl0cC0+dGNwX2hlYWRlcl9sZW47CisKKwkJaWYgKHRwLT5tYXhfd2luZG93ICYm IGxhcmdlX21zcyA+ICh0cC0+bWF4X3dpbmRvdz4+MSkpCisJCQlsYXJnZV9tc3MgPSBtYXgoKHRw LT5tYXhfd2luZG93Pj4xKSwKKwkJCQkJNjhVIC0gdHAtPnRjcF9oZWFkZXJfbGVuKTsKKworCQkv KiBBbHdheXMga2VlcCBsYXJnZSBtc3MgbXVsdGlwbGUgb2YgcmVhbCBtc3MsIGJ1dAorCQkgKiBk byBub3QgZXhjZWVkIGNvbmdlc3Rpb24gd2luZG93LgorCQkgKi8KKwkJZmFjdG9yID0gbGFyZ2Vf bXNzIC8gbXNzX25vdzsKKwkJaWYgKGZhY3RvciA+IHRwLT5zbmRfY3duZCkKKwkJCWZhY3RvciA9 IHRwLT5zbmRfY3duZDsKKworCQl0cC0+bXNzX2NhY2hlID0gbXNzX25vdyAqIGZhY3RvcjsKKwor CQltc3Nfbm93ID0gdHAtPm1zc19jYWNoZTsKKwl9CisKIAlpZiAodHAtPmVmZl9zYWNrcykKIAkJ bXNzX25vdyAtPSAoVENQT0xFTl9TQUNLX0JBU0VfQUxJR05FRCArCiAJCQkgICAgKHRwLT5lZmZf c2Fja3MgKiBUQ1BPTEVOX1NBQ0tfUEVSQkxPQ0spKTsK --Multipart=_Tue__28_Sep_2004_14_10_02_-0700_PMi3HGoCMW+xeS.N-- From davem@davemloft.net Tue Sep 28 14:19:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:19:53 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLJnJA024303 for ; Tue, 28 Sep 2004 14:19:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCPNL-0000ID-00; Tue, 28 Sep 2004 14:19:07 -0700 Date: Tue, 28 Sep 2004 14:19:07 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [RESEND PATCH 2.6 PKT_SCHED] Report qdisc parent to userspace Message-Id: <20040928141907.114e5da1.davem@davemloft.net> In-Reply-To: <20040924140039.GA4079@postel.suug.ch> References: <20040924123710.GB3944@postel.suug.ch> <20040924125240.GT31616@rei.reeler.org> <20040924140039.GA4079@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 491 Lines: 15 On Fri, 24 Sep 2004 16:00:39 +0200 Thomas Graf wrote: > This patch should be better, sorry for the brain dead patch before. > > Report parent classid of a qdisc back to userspace. Without this there > is no way for userspace to see if the qdisc is attached to a class > other than parsing all class trees of the link and check all tcm_info > fields in the leaf classes. > > Signed-off-by: Thomas Graf This patch looks fine to me, applied. Thanks Thomas. From davem@davemloft.net Tue Sep 28 14:28:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:28:43 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLSc8Q024726 for ; Tue, 28 Sep 2004 14:28:38 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCPVz-0000Jy-00; Tue, 28 Sep 2004 14:28:04 -0700 Date: Tue, 28 Sep 2004 14:28:03 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6 PKT_SCHED] Remove unneeded line Message-Id: <20040928142803.36330eab.davem@davemloft.net> In-Reply-To: <20040924162826.GB4079@postel.suug.ch> References: <20040924162826.GB4079@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 168 Lines: 8 On Fri, 24 Sep 2004 18:28:26 +0200 Thomas Graf wrote: > Remove unneeded line. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From ak@suse.de Tue Sep 28 14:34:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:34:39 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLYWiJ025130 for ; Tue, 28 Sep 2004 14:34:33 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id ACF18C92CAE; Tue, 28 Sep 2004 23:34:15 +0200 (CEST) Date: Tue, 28 Sep 2004 23:34:15 +0200 From: Andi Kleen To: "David S. Miller" Cc: Herbert Xu , ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040928213415.GA4646@wotan.suse.de> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040928141002.164c60af.davem@davemloft.net> X-archive-position: 9618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 171 Lines: 8 I admit I lost track of all your patches now - can you give me a big diff against the latest BK so that I can check that the problem is gone for me too? Thanks, -Andi From davem@davemloft.net Tue Sep 28 14:37:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:37:13 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLb8O9025475 for ; Tue, 28 Sep 2004 14:37:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCPeE-0000Lr-00; Tue, 28 Sep 2004 14:36:34 -0700 Date: Tue, 28 Sep 2004 14:36:33 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [BK PATCH 2.6] IPV6 Fixes Message-Id: <20040928143633.0cd77d31.davem@davemloft.net> In-Reply-To: <20040928.152306.74843215.yoshfuji@linux-ipv6.org> References: <20040928.152306.74843215.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i8SLb8O9025475 X-archive-position: 9619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 261 Lines: 9 On Tue, 28 Sep 2004 15:23:06 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > bk://bk.skbuff.net:20609/linux-2.6-inet6-20040928/ ... > bk://bk.skbuff.net:20428/linux-2.4-inet6-20040928/ Both pulled, thank you Yoshifuji-san. From davem@davemloft.net Tue Sep 28 14:44:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:44:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLijlW025865 for ; Tue, 28 Sep 2004 14:44:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCPlM-0000Mw-00; Tue, 28 Sep 2004 14:43:56 -0700 Date: Tue, 28 Sep 2004 14:43:56 -0700 From: "David S. Miller" To: Harald Welte Cc: Robert.Olsson@data.slu.se, shemminger@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) Message-Id: <20040928144356.371ef3d4.davem@davemloft.net> In-Reply-To: <20040928111906.GB29961@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 594 Lines: 16 On Tue, 28 Sep 2004 13:19:06 +0200 Harald Welte wrote: > Please find the current kernel-part patch attached to this mail, > it adds teplate-headerlines and moves all statistics files to > /proc/net/stat. It even cleans up the neigh_stat code a bit. > Depends on my latest neighbour statistics patch that davem has already > merged. I like this patch a lot and have applied it. Thanks Harald. Harald, we've created a lot of churn over the past week or two. Can I expect a set of 2.4.x patches for all the neigh stuff and this generic statistics thing sometime soon? From davem@davemloft.net Tue Sep 28 14:55:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 14:55:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SLtKZ0026386 for ; Tue, 28 Sep 2004 14:55:21 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCPur-0000OC-00; Tue, 28 Sep 2004 14:53:45 -0700 Date: Tue, 28 Sep 2004 14:53:45 -0700 From: "David S. Miller" To: Andi Kleen Cc: herbert@gondor.apana.org.au, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040928145345.2530d30e.davem@davemloft.net> In-Reply-To: <20040928213415.GA4646@wotan.suse.de> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt" X-archive-position: 9621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 23897 Lines: 348 This is a multi-part message in MIME format. --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 28 Sep 2004 23:34:15 +0200 Andi Kleen wrote: > I admit I lost track of all your patches now - can you give me a big > diff against the latest BK so that I can check that the problem > is gone for me too? Here are all of the pending TCP bug fixes, attached in order. I'll be pushing these to Linus some time today. --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt Content-Type: application/octet-stream; name="diff1" Content-Disposition: attachment; filename="diff1" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjcgMjE6NTA6MTEtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IEZpeCBjb25nZXN0aW9uIHdpbmRvdyBleHBhbnNpb24gd2hl biB1c2luZyBUU08uCiMgICAKIyAgIFdlIG9ubHkgZG8gY29uZ2VzdGlvbiB3aW5kb3cgZXhwYW5z aW9uIG9uIGZ1bGwgcGFja2V0CiMgICBBQ0tzLiAgV2Ugc2hvdWxkIGRvIGl0IGZvciBBQ0tzIG9m IHN1Yi1wYWNrZXRzIG9mIGEKIyAgIFRTTyBmcmFtZSBhcyB3ZWxsLgojICAgCiMgICBTaWduZWQt b2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+CiMgCiMgbmV0L2lw djQvdGNwX291dHB1dC5jCiMgICAyMDA0LzA5LzI3IDIxOjQ4OjU5LTA3OjAwIGRhdmVtQG51dHMu ZGF2ZW1sb2Z0Lm5ldCArMzUgLTIKIyAgIFtUQ1BdOiBGaXggY29uZ2VzdGlvbiB3aW5kb3cgZXhw YW5zaW9uIHdoZW4gdXNpbmcgVFNPLgojIAojIG5ldC9pcHY0L3RjcF9pbnB1dC5jCiMgICAyMDA0 LzA5LzI3IDIxOjQ4OjU5LTA3OjAwIGRhdmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArODUgLTEKIyAg IFtUQ1BdOiBGaXggY29uZ2VzdGlvbiB3aW5kb3cgZXhwYW5zaW9uIHdoZW4gdXNpbmcgVFNPLgoj IAojIGluY2x1ZGUvbmV0L3RjcC5oCiMgICAyMDA0LzA5LzI3IDIxOjQ4OjU5LTA3OjAwIGRhdmVt QG51dHMuZGF2ZW1sb2Z0Lm5ldCArMiAtMQojICAgW1RDUF06IEZpeCBjb25nZXN0aW9uIHdpbmRv dyBleHBhbnNpb24gd2hlbiB1c2luZyBUU08uCiMgCmRpZmYgLU5ydSBhL2luY2x1ZGUvbmV0L3Rj cC5oIGIvaW5jbHVkZS9uZXQvdGNwLmgKLS0tIGEvaW5jbHVkZS9uZXQvdGNwLmgJMjAwNC0wOS0y OCAxNDozMDoyOCAtMDc6MDAKKysrIGIvaW5jbHVkZS9uZXQvdGNwLmgJMjAwNC0wOS0yOCAxNDoz MDoyOCAtMDc6MDAKQEAgLTExODAsNyArMTE4MCw4IEBACiAKIAlfX3UxNgkJdXJnX3B0cjsJLyog VmFsaWQgdy9VUkcgZmxhZ3MgaXMgc2V0LgkqLwogCV9fdTMyCQlhY2tfc2VxOwkvKiBTZXF1ZW5j ZSBudW1iZXIgQUNLJ2QJKi8KLQlfX3UzMgkJdHNvX2ZhY3RvcjsKKwlfX3UxNgkJdHNvX2ZhY3Rv cjsJLyogSWYgPiAxLCBUU08gZnJhbWUJCSovCisJX191MTYJCXRzb19tc3M7CS8qIE1TUyB0aGF0 IEZBQ1RPUidzIGluIHRlcm1zIG9mKi8KIH07CiAKICNkZWZpbmUgVENQX1NLQl9DQihfX3NrYikJ KChzdHJ1Y3QgdGNwX3NrYl9jYiAqKSYoKF9fc2tiKS0+Y2JbMF0pKQpkaWZmIC1OcnUgYS9uZXQv aXB2NC90Y3BfaW5wdXQuYyBiL25ldC9pcHY0L3RjcF9pbnB1dC5jCi0tLSBhL25ldC9pcHY0L3Rj cF9pbnB1dC5jCTIwMDQtMDktMjggMTQ6MzA6MjggLTA3OjAwCisrKyBiL25ldC9pcHY0L3RjcF9p bnB1dC5jCTIwMDQtMDktMjggMTQ6MzA6MjggLTA3OjAwCkBAIC0yMzU1LDYgKzIzNTUsODYgQEAK IAl9CiB9CiAKKy8qIFRoZXJlIGlzIG9uZSBkb3duc2lkZSB0byB0aGlzIHNjaGVtZS4gIEFsdGhv dWdoIHdlIGtlZXAgdGhlCisgKiBBQ0sgY2xvY2sgdGlja2luZywgYWRqdXN0aW5nIHBhY2tldCBj b3VudGVycyBhbmQgYWR2YW5jaW5nCisgKiBjb25nZXN0aW9uIHdpbmRvdywgd2UgZG8gbm90IGxp YmVyYXRlIHNvY2tldCBzZW5kIGJ1ZmZlcgorICogc3BhY2UuCisgKgorICogTXVja2luZyB3aXRo IHNrYi0+dHJ1ZXNpemUgYW5kIHNrLT5za193bWVtX2FsbG9jIGV0IGFsLgorICogdGhlbiBtYWtp bmcgYSB3cml0ZSBzcGFjZSB3YWtldXAgY2FsbGJhY2sgaXMgYSBwb3NzaWJsZQorICogZnV0dXJl IGVuaGFuY2VtZW50LiAgV0FSTklORzogaXQgaXMgbm90IHRyaXZpYWwgdG8gbWFrZS4KKyAqLwor c3RhdGljIGludCB0Y3BfdHNvX2Fja2VkKHN0cnVjdCB0Y3Bfb3B0ICp0cCwgc3RydWN0IHNrX2J1 ZmYgKnNrYiwKKwkJCSBfX3UzMiBub3csIF9fczMyICpzZXFfcnR0KQoreworCXN0cnVjdCB0Y3Bf c2tiX2NiICpzY2IgPSBUQ1BfU0tCX0NCKHNrYik7IAorCV9fdTMyIG1zcyA9IHNjYi0+dHNvX21z czsKKwlfX3UzMiBzbmRfdW5hID0gdHAtPnNuZF91bmE7CisJX191MzIgc2VxID0gc2NiLT5zZXE7 CisJX191MzIgcGFja2V0c19hY2tlZCA9IDA7CisJaW50IGFja2VkID0gMDsKKworCS8qIElmIHdl IGdldCBoZXJlLCB0aGUgd2hvbGUgVFNPIHBhY2tldCBoYXMgbm90IGJlZW4KKwkgKiBhY2tlZC4K KwkgKi8KKwlCVUdfT04oIWFmdGVyKHNjYi0+ZW5kX3NlcSwgc25kX3VuYSkpOworCisJd2hpbGUg KCFhZnRlcihzZXEgKyBtc3MsIHNuZF91bmEpKSB7CisJCXBhY2tldHNfYWNrZWQrKzsKKwkJc2Vx ICs9IG1zczsKKwl9CisKKwlpZiAocGFja2V0c19hY2tlZCkgeworCQlfX3U4IHNhY2tlZCA9IHNj Yi0+c2Fja2VkOworCisJCS8qIFdlIGFkanVzdCBzY2ItPnNlcSBidXQgd2UgZG8gbm90IHBza2Jf cHVsbCgpIHRoZQorCQkgKiBTS0IuICBXZSBsZXQgdGNwX3JldHJhbnNtaXRfc2tiKCkgaGFuZGxl IHRoaXMgY2FzZQorCQkgKiBieSBjaGVja2luZyBza2ItPmxlbiBhZ2FpbnN0IHRoZSBkYXRhIHNl cXVlbmNlIHNwYW4uCisJCSAqIFRoaXMgd2F5LCB3ZSBhdm9pZCB0aGUgcHNrYl9wdWxsKCkgd29y ayB1bmxlc3Mgd2UKKwkJICogYWN0dWFsbHkgbmVlZCB0byByZXRyYW5zbWl0IHRoZSBTS0IuCisJ CSAqLworCQlzY2ItPnNlcSA9IHNlcTsKKworCQlhY2tlZCB8PSBGTEFHX0RBVEFfQUNLRUQ7CisJ CWlmIChzYWNrZWQpIHsKKwkJCWlmIChzYWNrZWQgJiBUQ1BDQl9SRVRSQU5TKSB7CisJCQkJaWYg KHNhY2tlZCAmIFRDUENCX1NBQ0tFRF9SRVRSQU5TKQorCQkJCQl0Y3BfZGVjX3Bjb3VudF9leHBs aWNpdCgmdHAtPnJldHJhbnNfb3V0LAorCQkJCQkJCQlwYWNrZXRzX2Fja2VkKTsKKwkJCQlhY2tl ZCB8PSBGTEFHX1JFVFJBTlNfREFUQV9BQ0tFRDsKKwkJCQkqc2VxX3J0dCA9IC0xOworCQkJfSBl bHNlIGlmICgqc2VxX3J0dCA8IDApCisJCQkJKnNlcV9ydHQgPSBub3cgLSBzY2ItPndoZW47CisJ CQlpZiAoc2Fja2VkICYgVENQQ0JfU0FDS0VEX0FDS0VEKQorCQkJCXRjcF9kZWNfcGNvdW50X2V4 cGxpY2l0KCZ0cC0+c2Fja2VkX291dCwKKwkJCQkJCQlwYWNrZXRzX2Fja2VkKTsKKwkJCWlmIChz YWNrZWQgJiBUQ1BDQl9MT1NUKQorCQkJCXRjcF9kZWNfcGNvdW50X2V4cGxpY2l0KCZ0cC0+bG9z dF9vdXQsCisJCQkJCQkJcGFja2V0c19hY2tlZCk7CisJCQlpZiAoc2Fja2VkICYgVENQQ0JfVVJH KSB7CisJCQkJaWYgKHRwLT51cmdfbW9kZSAmJgorCQkJCSAgICAhYmVmb3JlKHNjYi0+c2VxLCB0 cC0+c25kX3VwKSkKKwkJCQkJdHAtPnVyZ19tb2RlID0gMDsKKwkJCX0KKwkJfSBlbHNlIGlmICgq c2VxX3J0dCA8IDApCisJCQkqc2VxX3J0dCA9IG5vdyAtIHNjYi0+d2hlbjsKKworCQlpZiAodGNw X2dldF9wY291bnQoJnRwLT5mYWNrZXRzX291dCkpIHsKKwkJCV9fdTMyIGR2YWwgPSBtaW4odGNw X2dldF9wY291bnQoJnRwLT5mYWNrZXRzX291dCksCisJCQkJCSBwYWNrZXRzX2Fja2VkKTsKKwkJ CXRjcF9kZWNfcGNvdW50X2V4cGxpY2l0KCZ0cC0+ZmFja2V0c19vdXQsIGR2YWwpOworCQl9CisJ CXRjcF9kZWNfcGNvdW50X2V4cGxpY2l0KCZ0cC0+cGFja2V0c19vdXQsIHBhY2tldHNfYWNrZWQp OworCQlzY2ItPnRzb19mYWN0b3IgLT0gcGFja2V0c19hY2tlZDsKKworCQlCVUdfT04oc2NiLT50 c29fZmFjdG9yID09IDApOworCQlCVUdfT04oIWJlZm9yZShzY2ItPnNlcSwgc2NiLT5lbmRfc2Vx KSk7CisJfQorCisJcmV0dXJuIGFja2VkOworfQorCisKIC8qIFJlbW92ZSBhY2tub3dsZWRnZWQg ZnJhbWVzIGZyb20gdGhlIHJldHJhbnNtaXNzaW9uIHF1ZXVlLiAqLwogc3RhdGljIGludCB0Y3Bf Y2xlYW5fcnR4X3F1ZXVlKHN0cnVjdCBzb2NrICpzaywgX19zMzIgKnNlcV9ydHRfcCkKIHsKQEAg LTIzNzMsOCArMjQ1MywxMiBAQAogCQkgKiBkaXNjYXJkIGl0IGFzIGl0J3MgY29uZmlybWVkIHRv IGhhdmUgYXJyaXZlZCBhdAogCQkgKiB0aGUgb3RoZXIgZW5kLgogCQkgKi8KLQkJaWYgKGFmdGVy KHNjYi0+ZW5kX3NlcSwgdHAtPnNuZF91bmEpKQorCQlpZiAoYWZ0ZXIoc2NiLT5lbmRfc2VxLCB0 cC0+c25kX3VuYSkpIHsKKwkJCWlmIChzY2ItPnRzb19mYWN0b3IgPiAxKQorCQkJCWFja2VkIHw9 IHRjcF90c29fYWNrZWQodHAsIHNrYiwKKwkJCQkJCSAgICAgICBub3csICZzZXFfcnR0KTsKIAkJ CWJyZWFrOworCQl9CiAKIAkJLyogSW5pdGlhbCBvdXRnb2luZyBTWU4ncyBnZXQgcHV0IG9udG8g dGhlIHdyaXRlX3F1ZXVlCiAJCSAqIGp1c3QgbGlrZSBhbnl0aGluZyBlbHNlIHdlIHRyYW5zbWl0 LiAgSXQgaXMgbm90CmRpZmYgLU5ydSBhL25ldC9pcHY0L3RjcF9vdXRwdXQuYyBiL25ldC9pcHY0 L3RjcF9vdXRwdXQuYwotLS0gYS9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0yOCAxNDoz MDoyOCAtMDc6MDAKKysrIGIvbmV0L2lwdjQvdGNwX291dHB1dC5jCTIwMDQtMDktMjggMTQ6MzA6 MjggLTA3OjAwCkBAIC00MzYsNiArNDM2LDcgQEAKIAkJZmFjdG9yIC89IG1zc19zdGQ7CiAJCVRD UF9TS0JfQ0Ioc2tiKS0+dHNvX2ZhY3RvciA9IGZhY3RvcjsKIAl9CisJVENQX1NLQl9DQihza2Ip LT50c29fbXNzID0gbXNzX3N0ZDsKIH0KIAogLyogRnVuY3Rpb24gdG8gY3JlYXRlIHR3byBuZXcg VENQIHNlZ21lbnRzLiAgU2hyaW5rcyB0aGUgZ2l2ZW4gc2VnbWVudApAQCAtNTUyLDcgKzU1Myw3 IEBACiAJcmV0dXJuIHNrYi0+dGFpbDsKIH0KIAotc3RhdGljIGludCB0Y3BfdHJpbV9oZWFkKHN0 cnVjdCBzb2NrICpzaywgc3RydWN0IHNrX2J1ZmYgKnNrYiwgdTMyIGxlbikKK3N0YXRpYyBpbnQg X190Y3BfdHJpbV9oZWFkKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHNrX2J1ZmYgKnNrYiwgdTMy IGxlbikKIHsKIAlpZiAoc2tiX2Nsb25lZChza2IpICYmCiAJICAgIHBza2JfZXhwYW5kX2hlYWQo c2tiLCAwLCAwLCBHRlBfQVRPTUlDKSkKQEAgLTU2NSwxMSArNTY2LDIwIEBACiAJCQlyZXR1cm4g LUVOT01FTTsKIAl9CiAKLQlUQ1BfU0tCX0NCKHNrYiktPnNlcSArPSBsZW47CiAJc2tiLT5pcF9z dW1tZWQgPSBDSEVDS1NVTV9IVzsKIAlyZXR1cm4gMDsKIH0KIAorc3RhdGljIGlubGluZSBpbnQg dGNwX3RyaW1faGVhZChzdHJ1Y3Qgc29jayAqc2ssIHN0cnVjdCBza19idWZmICpza2IsIHUzMiBs ZW4pCit7CisJaW50IGVyciA9IF9fdGNwX3RyaW1faGVhZChzaywgc2tiLCBsZW4pOworCisJaWYg KCFlcnIpCisJCVRDUF9TS0JfQ0Ioc2tiKS0+c2VxICs9IGxlbjsKKworCXJldHVybiBlcnI7Cit9 CisKIC8qIFRoaXMgZnVuY3Rpb24gc3luY2hyb25pemUgc25kIG1zcyB0byBjdXJyZW50IHBtdHUv ZXh0aGRyIHNldC4KIAogICAgdHAtPnVzZXJfbXNzIGlzIG1zcyBzZXQgYnkgdXNlciBieSBUQ1Bf TUFYU0VHLiBJdCBkb2VzIE5PVCBjb3VudHMKQEAgLTk0OSw2ICs5NTksNyBAQAogewogCXN0cnVj dCB0Y3Bfb3B0ICp0cCA9IHRjcF9zayhzayk7CiAgCXVuc2lnbmVkIGludCBjdXJfbXNzID0gdGNw X2N1cnJlbnRfbXNzKHNrLCAwKTsKKwlfX3UzMiBkYXRhX3NlcSwgZGF0YV9lbmRfc2VxOwogCWlu dCBlcnI7CiAKIAkvKiBEbyBub3Qgc2VudCBtb3JlIHRoYW4gd2UgcXVldWVkLiAxLzQgaXMgcmVz ZXJ2ZWQgZm9yIHBvc3NpYmxlCkBAIC05NTgsNiArOTY5LDIyIEBACiAJICAgIG1pbihzay0+c2tf d21lbV9xdWV1ZWQgKyAoc2stPnNrX3dtZW1fcXVldWVkID4+IDIpLCBzay0+c2tfc25kYnVmKSkK IAkJcmV0dXJuIC1FQUdBSU47CiAKKwkvKiBXaGF0IGlzIGdvaW5nIG9uIGhlcmU/ICBXaGVuIFRT TyBwYWNrZXRzIGFyZSBwYXJ0aWFsbHkgQUNLJ2QsCisJICogd2UgYWRqdXN0IHRoZSBUQ1BfU0tC X0NCKHNrYiktPnNlcSB2YWx1ZSBmb3J3YXJkIGJ1dCB3ZSBkbworCSAqIG5vdCBhZGp1c3QgdGhl IGRhdGEgYXJlYSBvZiB0aGUgU0tCLiAgV2UgZGVmZXIgdGhhdCB0byBoZXJlCisJICogc28gdGhh dCB3ZSBjYW4gYXZvaWQgdGhlIHdvcmsgdW5sZXNzIHdlIHJlYWxseSByZXRyYW5zbWl0CisJICog dGhlIHBhY2tldC4KKwkgKi8KKwlkYXRhX3NlcSA9IFRDUF9TS0JfQ0Ioc2tiKS0+c2VxOworCWRh dGFfZW5kX3NlcSA9IFRDUF9TS0JfQ0Ioc2tiKS0+ZW5kX3NlcTsKKwlpZiAoVENQX1NLQl9DQihz a2IpLT5mbGFncyAmIFRDUENCX0ZMQUdfRklOKQorCQlkYXRhX2VuZF9zZXEtLTsKKworCWlmIChz a2ItPmxlbiAhPSAoZGF0YV9lbmRfc2VxIC0gZGF0YV9zZXEpKSB7CisJCWlmIChfX3RjcF90cmlt X2hlYWQoc2ssIHNrYiwgZGF0YV9lbmRfc2VxIC0gZGF0YV9zZXEpKQorCQkJcmV0dXJuIC1FTk9N RU07CisJfQkJCisKIAlpZiAoYmVmb3JlKFRDUF9TS0JfQ0Ioc2tiKS0+c2VxLCB0cC0+c25kX3Vu YSkpIHsKIAkJaWYgKGJlZm9yZShUQ1BfU0tCX0NCKHNrYiktPmVuZF9zZXEsIHRwLT5zbmRfdW5h KSkKIAkJCUJVRygpOwpAQCAtMTE5MSw2ICsxMjE4LDcgQEAKIAkJVENQX1NLQl9DQihza2IpLT5m bGFncyA9IChUQ1BDQl9GTEFHX0FDSyB8IFRDUENCX0ZMQUdfRklOKTsKIAkJVENQX1NLQl9DQihz a2IpLT5zYWNrZWQgPSAwOwogCQlUQ1BfU0tCX0NCKHNrYiktPnRzb19mYWN0b3IgPSAxOworCQlU Q1BfU0tCX0NCKHNrYiktPnRzb19tc3MgPSB0cC0+bXNzX2NhY2hlX3N0ZDsKIAogCQkvKiBGSU4g ZWF0cyBhIHNlcXVlbmNlIGJ5dGUsIHdyaXRlX3NlcSBhZHZhbmNlZCBieSB0Y3BfcXVldWVfc2ti KCkuICovCiAJCVRDUF9TS0JfQ0Ioc2tiKS0+c2VxID0gdHAtPndyaXRlX3NlcTsKQEAgLTEyMjMs NiArMTI1MSw3IEBACiAJVENQX1NLQl9DQihza2IpLT5mbGFncyA9IChUQ1BDQl9GTEFHX0FDSyB8 IFRDUENCX0ZMQUdfUlNUKTsKIAlUQ1BfU0tCX0NCKHNrYiktPnNhY2tlZCA9IDA7CiAJVENQX1NL Ql9DQihza2IpLT50c29fZmFjdG9yID0gMTsKKwlUQ1BfU0tCX0NCKHNrYiktPnRzb19tc3MgPSB0 cC0+bXNzX2NhY2hlX3N0ZDsKIAogCS8qIFNlbmQgaXQgb2ZmLiAqLwogCVRDUF9TS0JfQ0Ioc2ti KS0+c2VxID0gdGNwX2FjY2VwdGFibGVfc2VxKHNrLCB0cCk7CkBAIC0xMzA0LDYgKzEzMzMsNyBA QAogCVRDUF9TS0JfQ0Ioc2tiKS0+ZW5kX3NlcSA9IFRDUF9TS0JfQ0Ioc2tiKS0+c2VxICsgMTsK IAlUQ1BfU0tCX0NCKHNrYiktPnNhY2tlZCA9IDA7CiAJVENQX1NLQl9DQihza2IpLT50c29fZmFj dG9yID0gMTsKKwlUQ1BfU0tCX0NCKHNrYiktPnRzb19tc3MgPSB0cC0+bXNzX2NhY2hlX3N0ZDsK IAl0aC0+c2VxID0gaHRvbmwoVENQX1NLQl9DQihza2IpLT5zZXEpOwogCXRoLT5hY2tfc2VxID0g aHRvbmwocmVxLT5yY3ZfaXNuICsgMSk7CiAJaWYgKHJlcS0+cmN2X3duZCA9PSAwKSB7IC8qIGln bm9yZWQgZm9yIHJldHJhbnNtaXR0ZWQgc3lucyAqLwpAQCAtMTQwNiw2ICsxNDM2LDcgQEAKIAlU Q1BfRUNOX3NlbmRfc3luKHNrLCB0cCwgYnVmZik7CiAJVENQX1NLQl9DQihidWZmKS0+c2Fja2Vk ID0gMDsKIAlUQ1BfU0tCX0NCKGJ1ZmYpLT50c29fZmFjdG9yID0gMTsKKwlUQ1BfU0tCX0NCKGJ1 ZmYpLT50c29fbXNzID0gdHAtPm1zc19jYWNoZV9zdGQ7CiAJYnVmZi0+Y3N1bSA9IDA7CiAJVENQ X1NLQl9DQihidWZmKS0+c2VxID0gdHAtPndyaXRlX3NlcSsrOwogCVRDUF9TS0JfQ0IoYnVmZikt PmVuZF9zZXEgPSB0cC0+d3JpdGVfc2VxOwpAQCAtMTUwNiw2ICsxNTM3LDcgQEAKIAkJVENQX1NL Ql9DQihidWZmKS0+ZmxhZ3MgPSBUQ1BDQl9GTEFHX0FDSzsKIAkJVENQX1NLQl9DQihidWZmKS0+ c2Fja2VkID0gMDsKIAkJVENQX1NLQl9DQihidWZmKS0+dHNvX2ZhY3RvciA9IDE7CisJCVRDUF9T S0JfQ0IoYnVmZiktPnRzb19tc3MgPSB0cC0+bXNzX2NhY2hlX3N0ZDsKIAogCQkvKiBTZW5kIGl0 IG9mZiwgdGhpcyBjbGVhcnMgZGVsYXllZCBhY2tzIGZvciB1cy4gKi8KIAkJVENQX1NLQl9DQihi dWZmKS0+c2VxID0gVENQX1NLQl9DQihidWZmKS0+ZW5kX3NlcSA9IHRjcF9hY2NlcHRhYmxlX3Nl cShzaywgdHApOwpAQCAtMTU0MSw2ICsxNTczLDcgQEAKIAlUQ1BfU0tCX0NCKHNrYiktPmZsYWdz ID0gVENQQ0JfRkxBR19BQ0s7CiAJVENQX1NLQl9DQihza2IpLT5zYWNrZWQgPSB1cmdlbnQ7CiAJ VENQX1NLQl9DQihza2IpLT50c29fZmFjdG9yID0gMTsKKwlUQ1BfU0tCX0NCKHNrYiktPnRzb19t c3MgPSB0cC0+bXNzX2NhY2hlX3N0ZDsKIAogCS8qIFVzZSBhIHByZXZpb3VzIHNlcXVlbmNlLiAg VGhpcyBzaG91bGQgY2F1c2UgdGhlIG90aGVyCiAJICogZW5kIHRvIHNlbmQgYW4gYWNrLiAgRG9u J3QgcXVldWUgb3IgY2xvbmUgU0tCLCBqdXN0Cg== --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt Content-Type: application/octet-stream; name="diff2" Content-Disposition: attachment; filename="diff2" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjcgMjI6MDA6MTgtMDc6MDAgaGVyYmVydEBnb25kb3Iu YXBhbmEub3JnLmF1IAojICAgW1RDUF06IFVzZSBtc3NfY2FjaGVfc3RkIGluIHRjcF9pbml0X21l dHJpY3MoKS4KIyAgIAojICAgU2lnbmVkLW9mZi1ieTogSGVyYmVydCBYdSA8aGVyYmVydEBnb25k b3IuYXBhbmEub3JnLmF1PgojICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZl bUBkYXZlbWxvZnQubmV0PgojIAojIG5ldC9pcHY0L3RjcF9pbnB1dC5jCiMgICAyMDA0LzA5LzI3 IDIxOjU5OjM4LTA3OjAwIGhlcmJlcnRAZ29uZG9yLmFwYW5hLm9yZy5hdSArMiAtMgojICAgW1RD UF06IFVzZSBtc3NfY2FjaGVfc3RkIGluIHRjcF9pbml0X21ldHJpY3MoKS4KIyAKZGlmZiAtTnJ1 IGEvbmV0L2lwdjQvdGNwX2lucHV0LmMgYi9uZXQvaXB2NC90Y3BfaW5wdXQuYwotLS0gYS9uZXQv aXB2NC90Y3BfaW5wdXQuYwkyMDA0LTA5LTI4IDE0OjMxOjEyIC0wNzowMAorKysgYi9uZXQvaXB2 NC90Y3BfaW5wdXQuYwkyMDA0LTA5LTI4IDE0OjMxOjEyIC0wNzowMApAQCAtODAyLDEwICs4MDIs MTAgQEAKIAlfX3UzMiBjd25kID0gKGRzdCA/IGRzdF9tZXRyaWMoZHN0LCBSVEFYX0lOSVRDV05E KSA6IDApOwogCiAJaWYgKCFjd25kKSB7Ci0JCWlmICh0cC0+bXNzX2NhY2hlID4gMTQ2MCkKKwkJ aWYgKHRwLT5tc3NfY2FjaGVfc3RkID4gMTQ2MCkKIAkJCWN3bmQgPSAyOwogCQllbHNlCi0JCQlj d25kID0gKHRwLT5tc3NfY2FjaGUgPiAxMDk1KSA/IDMgOiA0OworCQkJY3duZCA9ICh0cC0+bXNz X2NhY2hlX3N0ZCA+IDEwOTUpID8gMyA6IDQ7CiAJfQogCXJldHVybiBtaW5fdChfX3UzMiwgY3du ZCwgdHAtPnNuZF9jd25kX2NsYW1wKTsKIH0K --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt Content-Type: application/octet-stream; name="diff3" Content-Disposition: attachment; filename="diff3" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjcgMjI6Mzc6MjctMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IEZpeCB0aGlyZCBhcmcgdG8gX190Y3BfdHJpbV9oZWFkKCku CiMgICAKIyAgIE5vdGVkIGJ5IEhlcmJlcnQgWHUgPGhlcmJlcnRAZ29uZG9yLmFwYW5hLm9yZy5h dT4KIyAgIAojICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBkYXZlbWxv ZnQubmV0PgojIAojIG5ldC9pcHY0L3RjcF9vdXRwdXQuYwojICAgMjAwNC8wOS8yNyAyMjozNjo0 MS0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzQgLTIKIyAgIFtUQ1BdOiBGaXggdGhp cmQgYXJnIHRvIF9fdGNwX3RyaW1faGVhZCgpLgojIApkaWZmIC1OcnUgYS9uZXQvaXB2NC90Y3Bf b3V0cHV0LmMgYi9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMKLS0tIGEvbmV0L2lwdjQvdGNwX291dHB1 dC5jCTIwMDQtMDktMjggMTQ6MzE6NDAgLTA3OjAwCisrKyBiL25ldC9pcHY0L3RjcF9vdXRwdXQu YwkyMDA0LTA5LTI4IDE0OjMxOjQwIC0wNzowMApAQCAtOTgwLDggKzk4MCwxMCBAQAogCWlmIChU Q1BfU0tCX0NCKHNrYiktPmZsYWdzICYgVENQQ0JfRkxBR19GSU4pCiAJCWRhdGFfZW5kX3NlcS0t OwogCi0JaWYgKHNrYi0+bGVuICE9IChkYXRhX2VuZF9zZXEgLSBkYXRhX3NlcSkpIHsKLQkJaWYg KF9fdGNwX3RyaW1faGVhZChzaywgc2tiLCBkYXRhX2VuZF9zZXEgLSBkYXRhX3NlcSkpCisJaWYg KHNrYi0+bGVuID4gKGRhdGFfZW5kX3NlcSAtIGRhdGFfc2VxKSkgeworCQl1MzIgdG9fdHJpbSA9 IHNrYi0+bGVuIC0gKGRhdGFfZW5kX3NlcSAtIGRhdGFfc2VxKTsKKworCQlpZiAoX190Y3BfdHJp bV9oZWFkKHNrLCBza2IsIHRvX3RyaW0pKQogCQkJcmV0dXJuIC1FTk9NRU07CiAJfQkJCiAK --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt Content-Type: application/octet-stream; name="diff4" Content-Disposition: attachment; filename="diff4" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMTM6MjY6NTQtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IFVuaW5saW5lIHRjcF9jdXJyZW50X21zcygpLgojICAgCiMg ICBBbHNvIGZpeCB0aGUgcmV0dXJuIHZhbHVlIG9mIHRjcF9zeW5jX21zcygpIHRvCiMgICBiZSB1 bnNpZ25lZC4KIyAgIAojICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBk YXZlbWxvZnQubmV0PgojIAojIG5ldC9pcHY0L3RjcF9vdXRwdXQuYwojICAgMjAwNC8wOS8yOCAx MzoyNjowMS0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzMxIC0xCiMgICBbVENQXTog VW5pbmxpbmUgdGNwX2N1cnJlbnRfbXNzKCkuCiMgCiMgaW5jbHVkZS9uZXQvdGNwLmgKIyAgIDIw MDQvMDkvMjggMTM6MjY6MDAtMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsyIC0zMgoj ICAgW1RDUF06IFVuaW5saW5lIHRjcF9jdXJyZW50X21zcygpLgojIApkaWZmIC1OcnUgYS9pbmNs dWRlL25ldC90Y3AuaCBiL2luY2x1ZGUvbmV0L3RjcC5oCi0tLSBhL2luY2x1ZGUvbmV0L3RjcC5o CTIwMDQtMDktMjggMTQ6MzI6MDcgLTA3OjAwCisrKyBiL2luY2x1ZGUvbmV0L3RjcC5oCTIwMDQt MDktMjggMTQ6MzI6MDcgLTA3OjAwCkBAIC05NjEsNyArOTYxLDggQEAKIAogZXh0ZXJuIHZvaWQg dGNwX2RlbGV0ZV9rZWVwYWxpdmVfdGltZXIgKHN0cnVjdCBzb2NrICopOwogZXh0ZXJuIHZvaWQg dGNwX3Jlc2V0X2tlZXBhbGl2ZV90aW1lciAoc3RydWN0IHNvY2sgKiwgdW5zaWduZWQgbG9uZyk7 Ci1leHRlcm4gaW50IHRjcF9zeW5jX21zcyhzdHJ1Y3Qgc29jayAqc2ssIHUzMiBwbXR1KTsKK2V4 dGVybiB1bnNpZ25lZCBpbnQgdGNwX3N5bmNfbXNzKHN0cnVjdCBzb2NrICpzaywgdTMyIHBtdHUp OworZXh0ZXJuIHVuc2lnbmVkIGludCB0Y3BfY3VycmVudF9tc3Moc3RydWN0IHNvY2sgKnNrLCBp bnQgbGFyZ2UpOwogCiBleHRlcm4gY29uc3QgY2hhciB0aW1lcl9idWdfbXNnW107CiAKQEAgLTEw MzMsMzcgKzEwMzQsNiBAQAogCWRlZmF1bHQ6CiAJCXByaW50ayh0aW1lcl9idWdfbXNnKTsKIAl9 OwotfQotCi0vKiBDb21wdXRlIHRoZSBjdXJyZW50IGVmZmVjdGl2ZSBNU1MsIHRha2luZyBTQUNL cyBhbmQgSVAgb3B0aW9ucywKLSAqIGFuZCBldmVuIFBNVFUgZGlzY292ZXJ5IGV2ZW50cyBpbnRv IGFjY291bnQuCi0gKgotICogTEFSR0VTRU5EIG5vdGU6ICF1cmdfbW9kZSBpcyBvdmVya2lsbCwg b25seSBmcmFtZXMgdXAgdG8gc25kX3VwCi0gKiBjYW5ub3QgYmUgbGFyZ2UuIEhvd2V2ZXIsIHRh a2luZyBpbnRvIGFjY291bnQgcmFyZSB1c2Ugb2YgVVJHLCB0aGlzCi0gKiBpcyBub3QgYSBiaWcg Zmxhdy4KLSAqLwotCi1zdGF0aWMgaW5saW5lIHVuc2lnbmVkIGludCB0Y3BfY3VycmVudF9tc3Mo c3RydWN0IHNvY2sgKnNrLCBpbnQgbGFyZ2UpCi17Ci0Jc3RydWN0IHRjcF9vcHQgKnRwID0gdGNw X3NrKHNrKTsKLQlzdHJ1Y3QgZHN0X2VudHJ5ICpkc3QgPSBfX3NrX2RzdF9nZXQoc2spOwotCWlu dCBkb19sYXJnZSwgbXNzX25vdzsKLQotCWRvX2xhcmdlID0gKGxhcmdlICYmCi0JCSAgICAoc2st PnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykgJiYKLQkJICAgICF0cC0+dXJnX21vZGUpOwot CW1zc19ub3cgPSBkb19sYXJnZSA/IHRwLT5tc3NfY2FjaGUgOiB0cC0+bXNzX2NhY2hlX3N0ZDsK LQotCWlmIChkc3QpIHsKLQkJdTMyIG10dSA9IGRzdF9wbXR1KGRzdCk7Ci0JCWlmIChtdHUgIT0g dHAtPnBtdHVfY29va2llIHx8Ci0JCSAgICB0cC0+ZXh0Ml9oZWFkZXJfbGVuICE9IGRzdC0+aGVh ZGVyX2xlbikKLQkJCW1zc19ub3cgPSB0Y3Bfc3luY19tc3Moc2ssIG10dSk7Ci0JfQotCWlmICh0 cC0+ZWZmX3NhY2tzKQotCQltc3Nfbm93IC09IChUQ1BPTEVOX1NBQ0tfQkFTRV9BTElHTkVEICsK LQkJCSAgICAodHAtPmVmZl9zYWNrcyAqIFRDUE9MRU5fU0FDS19QRVJCTE9DSykpOwotCXJldHVy biBtc3Nfbm93OwogfQogCiAvKiBJbml0aWFsaXplIFJDVl9NU1MgdmFsdWUuCmRpZmYgLU5ydSBh L25ldC9pcHY0L3RjcF9vdXRwdXQuYyBiL25ldC9pcHY0L3RjcF9vdXRwdXQuYwotLS0gYS9uZXQv aXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0yOCAxNDozMjowNyAtMDc6MDAKKysrIGIvbmV0L2lw djQvdGNwX291dHB1dC5jCTIwMDQtMDktMjggMTQ6MzI6MDcgLTA3OjAwCkBAIC02MDMsNyArNjAz LDcgQEAKICAgIHRoaXMgZnVuY3Rpb24uCQkJLS1BTksgKDk4MDczMSkKICAqLwogCi1pbnQgdGNw X3N5bmNfbXNzKHN0cnVjdCBzb2NrICpzaywgdTMyIHBtdHUpCit1bnNpZ25lZCBpbnQgdGNwX3N5 bmNfbXNzKHN0cnVjdCBzb2NrICpzaywgdTMyIHBtdHUpCiB7CiAJc3RydWN0IHRjcF9vcHQgKnRw ID0gdGNwX3NrKHNrKTsKIAlzdHJ1Y3QgZHN0X2VudHJ5ICpkc3QgPSBfX3NrX2RzdF9nZXQoc2sp OwpAQCAtNjYxLDYgKzY2MSwzNiBAQAogCXJldHVybiBtc3Nfbm93OwogfQogCisvKiBDb21wdXRl IHRoZSBjdXJyZW50IGVmZmVjdGl2ZSBNU1MsIHRha2luZyBTQUNLcyBhbmQgSVAgb3B0aW9ucywK KyAqIGFuZCBldmVuIFBNVFUgZGlzY292ZXJ5IGV2ZW50cyBpbnRvIGFjY291bnQuCisgKgorICog TEFSR0VTRU5EIG5vdGU6ICF1cmdfbW9kZSBpcyBvdmVya2lsbCwgb25seSBmcmFtZXMgdXAgdG8g c25kX3VwCisgKiBjYW5ub3QgYmUgbGFyZ2UuIEhvd2V2ZXIsIHRha2luZyBpbnRvIGFjY291bnQg cmFyZSB1c2Ugb2YgVVJHLCB0aGlzCisgKiBpcyBub3QgYSBiaWcgZmxhdy4KKyAqLworCit1bnNp Z25lZCBpbnQgdGNwX2N1cnJlbnRfbXNzKHN0cnVjdCBzb2NrICpzaywgaW50IGxhcmdlKQorewor CXN0cnVjdCB0Y3Bfb3B0ICp0cCA9IHRjcF9zayhzayk7CisJc3RydWN0IGRzdF9lbnRyeSAqZHN0 ID0gX19za19kc3RfZ2V0KHNrKTsKKwlpbnQgZG9fbGFyZ2UsIG1zc19ub3c7CisKKwlkb19sYXJn ZSA9IChsYXJnZSAmJgorCQkgICAgKHNrLT5za19yb3V0ZV9jYXBzICYgTkVUSUZfRl9UU08pICYm CisJCSAgICAhdHAtPnVyZ19tb2RlKTsKKwltc3Nfbm93ID0gZG9fbGFyZ2UgPyB0cC0+bXNzX2Nh Y2hlIDogdHAtPm1zc19jYWNoZV9zdGQ7CisKKwlpZiAoZHN0KSB7CisJCXUzMiBtdHUgPSBkc3Rf cG10dShkc3QpOworCQlpZiAobXR1ICE9IHRwLT5wbXR1X2Nvb2tpZSB8fAorCQkgICAgdHAtPmV4 dDJfaGVhZGVyX2xlbiAhPSBkc3QtPmhlYWRlcl9sZW4pCisJCQltc3Nfbm93ID0gdGNwX3N5bmNf bXNzKHNrLCBtdHUpOworCX0KKwlpZiAodHAtPmVmZl9zYWNrcykKKwkJbXNzX25vdyAtPSAoVENQ T0xFTl9TQUNLX0JBU0VfQUxJR05FRCArCisJCQkgICAgKHRwLT5lZmZfc2Fja3MgKiBUQ1BPTEVO X1NBQ0tfUEVSQkxPQ0spKTsKKwlyZXR1cm4gbXNzX25vdzsKK30KIAogLyogVGhpcyByb3V0aW5l IHdyaXRlcyBwYWNrZXRzIHRvIHRoZSBuZXR3b3JrLiAgSXQgYWR2YW5jZXMgdGhlCiAgKiBzZW5k X2hlYWQuICBUaGlzIGhhcHBlbnMgYXMgaW5jb21pbmcgYWNrcyBvcGVuIHVwIHRoZSByZW1vdGUK --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt Content-Type: application/octet-stream; name="diff5" Content-Disposition: attachment; filename="diff5" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMTM6NDY6NTgtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IE1vdmUgVFNPIG1zcyBjYWxjcyB0byB0Y3BfY3VycmVudF9t c3MoKQojICAgCiMgICBCYXNlZCB1cG9uIGEgYnVnIGZpeCBwYXRjaCBhbmQgc3VnZ2VzdGlvbnMg ZnJvbQojICAgSGVyYmVydCBYdSA8aGVyYmVydEBnb25kb3IuYXBhbmEub3JnLmF1PgojICAgCiMg ICBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+CiMg CiMgbmV0L2lwdjQvdGNwX291dHB1dC5jCiMgICAyMDA0LzA5LzI4IDEzOjQ2OjI4LTA3OjAwIGRh dmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArMjkgLTI0CiMgICBbVENQXTogTW92ZSBUU08gbXNzIGNh bGNzIHRvIHRjcF9jdXJyZW50X21zcygpCiMgICAKIyAgIEJhc2VkIHVwb24gYSBidWcgZml4IHBh dGNoIGFuZCBzdWdnZXN0aW9ucyBmcm9tCiMgICBIZXJiZXJ0IFh1IDxoZXJiZXJ0QGdvbmRvci5h cGFuYS5vcmcuYXU+CiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2 ZW1AZGF2ZW1sb2Z0Lm5ldD4KIyAKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvdGNwX291dHB1dC5jIGIv bmV0L2lwdjQvdGNwX291dHB1dC5jCi0tLSBhL25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA0LTA5 LTI4IDE0OjMyOjM0IC0wNzowMAorKysgYi9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0y OCAxNDozMjozNCAtMDc6MDAKQEAgLTYzOSwyNSArNjM5LDYgQEAKIAl0cC0+cG10dV9jb29raWUg PSBwbXR1OwogCXRwLT5tc3NfY2FjaGUgPSB0cC0+bXNzX2NhY2hlX3N0ZCA9IG1zc19ub3c7CiAK LQlpZiAoc2stPnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykgewotCQlpbnQgbGFyZ2VfbXNz LCBmYWN0b3I7Ci0KLQkJbGFyZ2VfbXNzID0gNjU1MzUgLSB0cC0+YWZfc3BlY2lmaWMtPm5ldF9o ZWFkZXJfbGVuIC0KLQkJCXRwLT5leHRfaGVhZGVyX2xlbiAtIHRwLT5leHQyX2hlYWRlcl9sZW4g LSB0cC0+dGNwX2hlYWRlcl9sZW47Ci0KLQkJaWYgKHRwLT5tYXhfd2luZG93ICYmIGxhcmdlX21z cyA+ICh0cC0+bWF4X3dpbmRvdz4+MSkpCi0JCQlsYXJnZV9tc3MgPSBtYXgoKHRwLT5tYXhfd2lu ZG93Pj4xKSwgNjhVIC0gdHAtPnRjcF9oZWFkZXJfbGVuKTsKLQotCQkvKiBBbHdheXMga2VlcCBs YXJnZSBtc3MgbXVsdGlwbGUgb2YgcmVhbCBtc3MsIGJ1dAotCQkgKiBkbyBub3QgZXhjZWVkIGNv bmdlc3Rpb24gd2luZG93LgotCQkgKi8KLQkJZmFjdG9yID0gbGFyZ2VfbXNzIC8gbXNzX25vdzsK LQkJaWYgKGZhY3RvciA+IHRwLT5zbmRfY3duZCkKLQkJCWZhY3RvciA9IHRwLT5zbmRfY3duZDsK LQotCQl0cC0+bXNzX2NhY2hlID0gbXNzX25vdyAqIGZhY3RvcjsKLQl9Ci0KIAlyZXR1cm4gbXNz X25vdzsKIH0KIApAQCAtNjc1LDE3ICs2NTYsNDEgQEAKIAlzdHJ1Y3QgZHN0X2VudHJ5ICpkc3Qg PSBfX3NrX2RzdF9nZXQoc2spOwogCWludCBkb19sYXJnZSwgbXNzX25vdzsKIAotCWRvX2xhcmdl ID0gKGxhcmdlICYmCi0JCSAgICAoc2stPnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykgJiYK LQkJICAgICF0cC0+dXJnX21vZGUpOwotCW1zc19ub3cgPSBkb19sYXJnZSA/IHRwLT5tc3NfY2Fj aGUgOiB0cC0+bXNzX2NhY2hlX3N0ZDsKLQorCW1zc19ub3cgPSB0cC0+bXNzX2NhY2hlX3N0ZDsK IAlpZiAoZHN0KSB7CiAJCXUzMiBtdHUgPSBkc3RfcG10dShkc3QpOwogCQlpZiAobXR1ICE9IHRw LT5wbXR1X2Nvb2tpZSB8fAogCQkgICAgdHAtPmV4dDJfaGVhZGVyX2xlbiAhPSBkc3QtPmhlYWRl cl9sZW4pCiAJCQltc3Nfbm93ID0gdGNwX3N5bmNfbXNzKHNrLCBtdHUpOwogCX0KKworCWRvX2xh cmdlID0gKGxhcmdlICYmCisJCSAgICAoc2stPnNrX3JvdXRlX2NhcHMgJiBORVRJRl9GX1RTTykg JiYKKwkJICAgICF0cC0+dXJnX21vZGUpOworCisJaWYgKGRvX2xhcmdlKSB7CisJCWludCBsYXJn ZV9tc3MsIGZhY3RvcjsKKworCQlsYXJnZV9tc3MgPSA2NTUzNSAtIHRwLT5hZl9zcGVjaWZpYy0+ bmV0X2hlYWRlcl9sZW4gLQorCQkJdHAtPmV4dF9oZWFkZXJfbGVuIC0gdHAtPmV4dDJfaGVhZGVy X2xlbiAtCisJCQl0cC0+dGNwX2hlYWRlcl9sZW47CisKKwkJaWYgKHRwLT5tYXhfd2luZG93ICYm IGxhcmdlX21zcyA+ICh0cC0+bWF4X3dpbmRvdz4+MSkpCisJCQlsYXJnZV9tc3MgPSBtYXgoKHRw LT5tYXhfd2luZG93Pj4xKSwKKwkJCQkJNjhVIC0gdHAtPnRjcF9oZWFkZXJfbGVuKTsKKworCQkv KiBBbHdheXMga2VlcCBsYXJnZSBtc3MgbXVsdGlwbGUgb2YgcmVhbCBtc3MsIGJ1dAorCQkgKiBk byBub3QgZXhjZWVkIGNvbmdlc3Rpb24gd2luZG93LgorCQkgKi8KKwkJZmFjdG9yID0gbGFyZ2Vf bXNzIC8gbXNzX25vdzsKKwkJaWYgKGZhY3RvciA+IHRwLT5zbmRfY3duZCkKKwkJCWZhY3RvciA9 IHRwLT5zbmRfY3duZDsKKworCQl0cC0+bXNzX2NhY2hlID0gbXNzX25vdyAqIGZhY3RvcjsKKwor CQltc3Nfbm93ID0gdHAtPm1zc19jYWNoZTsKKwl9CisKIAlpZiAodHAtPmVmZl9zYWNrcykKIAkJ bXNzX25vdyAtPSAoVENQT0xFTl9TQUNLX0JBU0VfQUxJR05FRCArCiAJCQkgICAgKHRwLT5lZmZf c2Fja3MgKiBUQ1BPTEVOX1NBQ0tfUEVSQkxPQ0spKTsK --Multipart=_Tue__28_Sep_2004_14_53_45_-0700_2eQioA_ZEUtD7SAt-- From ak@suse.de Tue Sep 28 15:37:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 15:37:49 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SMbbtp027446 for ; Tue, 28 Sep 2004 15:37:38 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 73BEAC90AAC; Wed, 29 Sep 2004 00:33:47 +0200 (CEST) Date: Wed, 29 Sep 2004 00:33:44 +0200 From: Andi Kleen To: "David S. Miller" Cc: Andi Kleen , herbert@gondor.apana.org.au, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040928223344.GC2975@wotan.suse.de> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> <20040928145345.2530d30e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040928145345.2530d30e.davem@davemloft.net> X-archive-position: 9622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 894 Lines: 24 On Tue, Sep 28, 2004 at 02:53:45PM -0700, David S. Miller wrote: > On Tue, 28 Sep 2004 23:34:15 +0200 > Andi Kleen wrote: > > > I admit I lost track of all your patches now - can you give me a big > > diff against the latest BK so that I can check that the problem > > is gone for me too? > > Here are all of the pending TCP bug fixes, attached in order. > I'll be pushing these to Linus some time today. I'm afraid I must report it's still not completely solved for me yet. 10s netperf with TSO on with your patches gives now ~10MB/s less than with TSO off (57 vs 67). It's better than before, but not really fixed yet. Looking at my tcpdumps and comparing TSO on/off I see a quite strange effect. It only acks on every ~25th packet with TSO off but every ~16th packet with TSO on. Receiver is a 2.6.5 kernel, it's weird that it violates the ack every two MSS rule. -Andi From davem@davemloft.net Tue Sep 28 15:58:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 15:58:16 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SMw42q027989 for ; Tue, 28 Sep 2004 15:58:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCQuA-0000VZ-00; Tue, 28 Sep 2004 15:57:06 -0700 Date: Tue, 28 Sep 2004 15:57:06 -0700 From: "David S. Miller" To: Andi Kleen Cc: ak@suse.de, herbert@gondor.apana.org.au, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040928155706.65405e88.davem@davemloft.net> In-Reply-To: <20040928223344.GC2975@wotan.suse.de> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> <20040928145345.2530d30e.davem@davemloft.net> <20040928223344.GC2975@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 781 Lines: 22 On Wed, 29 Sep 2004 00:33:44 +0200 Andi Kleen wrote: > Looking at my tcpdumps and comparing TSO on/off I see a quite > strange effect. It only acks on every ~25th packet with TSO off > but every ~16th packet with TSO on. > > Receiver is a 2.6.5 kernel, it's weird that it violates the > ack every two MSS rule. Your system is SMP and packet reordering is occuring? If so, you can lock the interrupts of the card to a specific cpu to see if that makes the problem go away. Another possibility is tcpdump dropping some of the ACKs or some bug in the TCP code of your "interesting experiment based upon 2.6.5" kernel :-) On my sparc64 box here, TSO makes performance go up quite clearly, from 55MB/sec-->63MB/sec, and the sender is a tg3 card on a 32-bit/33Mhz bus. From shemminger@osdl.org Tue Sep 28 16:11:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:11:09 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNB2h1028496 for ; Tue, 28 Sep 2004 16:11:03 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8SNA6v24802; Tue, 28 Sep 2004 16:10:06 -0700 Subject: Re: RFC/PATCH capture qdisc requeue event in stats From: Stephen Hemminger To: hadi@cyberus.ca Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <1093799632.1073.410.camel@jzny.localdomain> References: <1093799632.1073.410.camel@jzny.localdomain> Content-Type: text/plain Organization: Open Source Development Lab Date: Tue, 28 Sep 2004 16:10:09 -0700 Message-Id: <1096413009.27967.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 530 Lines: 13 On Sun, 2004-08-29 at 13:13 -0400, jamal wrote: > > The requeue event is useful in finding out when a device is overloaded > on the egress (bus or bandwidth). > Atached patch introduces this. I would have used the overlimit bits > but at the moment thats being used for different semantical reasons. > I have not done extensive testing on it. > > Opinions welcome - If all is good, Dave please apply. Dave, what happened to this? I put the stuff into iproute2 but the requeue stat never made it into 2.6. Is it a bad idea? From herbert@gondor.apana.org.au Tue Sep 28 16:19:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:19:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNJmn2032210 for ; Tue, 28 Sep 2004 16:19:49 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCRFa-00052H-00; Wed, 29 Sep 2004 09:19:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCRFS-0006ab-00; Wed, 29 Sep 2004 09:19:06 +1000 Date: Wed, 29 Sep 2004 09:19:06 +1000 To: Pablo Neira Cc: hadi@cyberus.ca, "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040928231906.GA25293@gondor.apana.org.au> References: <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <4159D278.4060809@eurodev.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4159D278.4060809@eurodev.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 973 Lines: 27 On Tue, Sep 28, 2004 at 11:07:04PM +0200, Pablo Neira wrote: > > If buffer overruns we lost all the messages which are enqueued, so This is not true. You will get an ENOBUFS error but the packets that have already been queued are still on the queue if you want to read them. > ===== net/netlink/af_netlink.c 1.58 vs edited ===== > --- 1.58/net/netlink/af_netlink.c Sat Sep 25 17:43:43 2004 > +++ edited/net/netlink/af_netlink.c Tue Sep 28 22:23:44 2004 > @@ -475,7 +475,7 @@ > if (nlk->handler) > return 0; > #endif > - if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf || > + if (atomic_read(&sk->sk_rmem_alloc) + skb->len > sk->sk_rcvbuf || I don't see the point of this patch. All it does is make the overrun happen one packet earlier. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue Sep 28 16:19:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:19:31 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNJPTZ032128 for ; Tue, 28 Sep 2004 16:19:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCRF0-0000Xh-00; Tue, 28 Sep 2004 16:18:38 -0700 Date: Tue, 28 Sep 2004 16:18:38 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: RFC/PATCH capture qdisc requeue event in stats Message-Id: <20040928161838.3d19a17d.davem@davemloft.net> In-Reply-To: <1096413009.27967.1.camel@localhost.localdomain> References: <1093799632.1073.410.camel@jzny.localdomain> <1096413009.27967.1.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 655 Lines: 17 On Tue, 28 Sep 2004 16:10:09 -0700 Stephen Hemminger wrote: > On Sun, 2004-08-29 at 13:13 -0400, jamal wrote: > > > > The requeue event is useful in finding out when a device is overloaded > > on the egress (bus or bandwidth). > > Atached patch introduces this. I would have used the overlimit bits > > but at the moment thats being used for different semantical reasons. > > I have not done extensive testing on it. > > > > Opinions welcome - If all is good, Dave please apply. > > Dave, what happened to this? I put the stuff into iproute2 but the > requeue stat never made it into 2.6. Is it a bad idea? Yes, API breaker. From davem@davemloft.net Tue Sep 28 16:21:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:21:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNLKEe000330 for ; Tue, 28 Sep 2004 16:21:20 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCRGp-0000Y9-00; Tue, 28 Sep 2004 16:20:31 -0700 Date: Tue, 28 Sep 2004 16:20:31 -0700 From: "David S. Miller" To: Herbert Xu Cc: pablo@eurodev.net, hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040928162031.1ec28e32.davem@davemloft.net> In-Reply-To: <20040928231906.GA25293@gondor.apana.org.au> References: <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <4159D278.4060809@eurodev.net> <20040928231906.GA25293@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 612 Lines: 17 On Wed, 29 Sep 2004 09:19:06 +1000 Herbert Xu wrote: > > ===== net/netlink/af_netlink.c 1.58 vs edited ===== > > --- 1.58/net/netlink/af_netlink.c Sat Sep 25 17:43:43 2004 > > +++ edited/net/netlink/af_netlink.c Tue Sep 28 22:23:44 2004 > > @@ -475,7 +475,7 @@ > > if (nlk->handler) > > return 0; > > #endif > > - if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf || > > + if (atomic_read(&sk->sk_rmem_alloc) + skb->len > sk->sk_rcvbuf || > > I don't see the point of this patch. All it does is make the overrun > happen one packet earlier. That's my sentiment as well. From ak@suse.de Tue Sep 28 16:28:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:28:25 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNSGNv000736 for ; Tue, 28 Sep 2004 16:28:17 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D93D1C93AE1; Wed, 29 Sep 2004 01:27:59 +0200 (CEST) Date: Wed, 29 Sep 2004 01:27:57 +0200 From: Andi Kleen To: "David S. Miller" Cc: herbert@gondor.apana.org.au, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929012757.5d0dff61.ak@suse.de> In-Reply-To: <20040928155706.65405e88.davem@davemloft.net> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> <20040928145345.2530d30e.davem@davemloft.net> <20040928223344.GC2975@wotan.suse.de> <20040928155706.65405e88.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1253 Lines: 40 On Tue, 28 Sep 2004 15:57:06 -0700 "David S. Miller" wrote: > On Wed, 29 Sep 2004 00:33:44 +0200 > Andi Kleen wrote: > > > Looking at my tcpdumps and comparing TSO on/off I see a quite > > strange effect. It only acks on every ~25th packet with TSO off > > but every ~16th packet with TSO on. > > > > Receiver is a 2.6.5 kernel, it's weird that it violates the > > ack every two MSS rule. > > Your system is SMP and packet reordering is occuring? The sender is SMP, but the receiver is UP. I tcpdumped at the receiver. > If so, you can lock the interrupts of the card > to a specific cpu to see if that makes the problem go > away. > > Another possibility is tcpdump dropping some of the ACKs Possible, unfortunately there are no counters for this (anyone on netdev motivated to add them to each packet drop in PF_PACKET and dev.c?) > or some bug in the TCP code of your "interesting experiment > based upon 2.6.5" kernel :-) Possible. I tried to re-test it but I didn't get very far because the kernel with your patch crashes regularly during netperf. No serial console, but the backtrace is {tcp_ack+877} {tcp_rcv_established+350} ... Before that there are a few "retrans out leaked" messages. -Andi From davem@davemloft.net Tue Sep 28 16:36:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:36:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNa5lJ001165 for ; Tue, 28 Sep 2004 16:36:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCRV0-0000Zc-00; Tue, 28 Sep 2004 16:35:10 -0700 Date: Tue, 28 Sep 2004 16:35:09 -0700 From: "David S. Miller" To: Andi Kleen Cc: herbert@gondor.apana.org.au, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040928163509.624a748b.davem@davemloft.net> In-Reply-To: <20040929012757.5d0dff61.ak@suse.de> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> <20040928145345.2530d30e.davem@davemloft.net> <20040928223344.GC2975@wotan.suse.de> <20040928155706.65405e88.davem@davemloft.net> <20040929012757.5d0dff61.ak@suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 724 Lines: 16 On Wed, 29 Sep 2004 01:27:57 +0200 Andi Kleen wrote: > I tried to re-test it but I didn't get very far because the kernel > with your patch crashes regularly during netperf. No serial console, > but the backtrace is {tcp_ack+877} {tcp_rcv_established+350} ... > Before that there are a few "retrans out leaked" messages. You might be missing the topmost part of the backtrace which is probably in tcp_clean_rtx_queue() or even more likely tcp_tso_acked() where there are several assertions present. I guess your compiler is auto-inlining those functions for you, can you reproduce the crash with perhaps the noinline attribute added to those two functions I mention above so we can get a precise backtrace? From speattle@yahoo.com Tue Sep 28 16:41:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:42:04 -0700 (PDT) Received: from smtp104.mail.sc5.yahoo.com (smtp104.mail.sc5.yahoo.com [66.163.169.223]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8SNfvcA001564 for ; Tue, 28 Sep 2004 16:41:57 -0700 Date: Tue, 28 Sep 2004 16:41:57 -0700 Message-Id: <200409282341.i8SNfvcA001564@oss.sgi.com> Received: from unknown (HELO MMT) (speattle@166.220.36.68 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 28 Sep 2004 23:41:41 -0000 From: speattle@yahoo.com To: "David S. Miller" ; Cc: netdev@oss.sgi.com; Subject: RE: Re: On DaveMs congestion control algorithm WAS(Re: [PATCH] Improvebehaviour of Netlink Sockets MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 9630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: speattle@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1352 Lines: 46 did you say drama or a game show? huhu... i thought you usually can't wait to dive in for more drama LOL. about time i go hide in dugout . -----Original Message----- From: "David S. Miller" Date: 09/28/04 11:26 AM To: hadi@cyberus.ca Cc: herbert@gondor.apana.org.au, pablo@eurodev.net, netdev@oss.sgi.com Subject: Re: On DaveMs congestion control algorithm WAS(Re: [PATCH] Improvebehaviour of Netlink Sockets On 28 Sep 2004 08:39:49 -0400 jamal wrote: > On Tue, 2004-09-28 at 08:16, Herbert Xu wrote: > > On Tue, Sep 28, 2004 at 09:11:59PM +1000, herbert wrote: > > > > > > > BTW, Davem gets away with this congestion control alg all the time. > > > > Heck i think his sanity survives because of it - I bet you hes got this > > > > thread under congestion controlled right now;-> > > > > > > Yep, his overrun flag sure is set :) > > > > Now if he puts his mailing admin hat on and tells us to shut up, that > > would be congestion control :) > > Hed have to go and read all the emails first ;-> i.e the overrun flag > requires that you reread state. When I see two guys going at it like you too, I just wait for the dust to settle in the form of a patch and then I reread the thread as if it were the latest drama show on TV :-) These words brought to you by Ogo. Find out more at www.ogo.com From ak@suse.de Tue Sep 28 16:58:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 16:59:03 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8SNwqSY002206 for ; Tue, 28 Sep 2004 16:58:53 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id AE1A8C8FC47; Wed, 29 Sep 2004 01:55:36 +0200 (CEST) Date: Wed, 29 Sep 2004 01:55:34 +0200 From: Andi Kleen To: "David S. Miller" Cc: herbert@gondor.apana.org.au, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929015534.3b39b720.ak@suse.de> In-Reply-To: <20040928163509.624a748b.davem@davemloft.net> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> <20040928145345.2530d30e.davem@davemloft.net> <20040928223344.GC2975@wotan.suse.de> <20040928155706.65405e88.davem@davemloft.net> <20040929012757.5d0dff61.ak@suse.de> <20040928163509.624a748b.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 950 Lines: 24 On Tue, 28 Sep 2004 16:35:09 -0700 "David S. Miller" wrote: > On Wed, 29 Sep 2004 01:27:57 +0200 > Andi Kleen wrote: > > > I tried to re-test it but I didn't get very far because the kernel > > with your patch crashes regularly during netperf. No serial console, > > but the backtrace is {tcp_ack+877} {tcp_rcv_established+350} ... > > Before that there are a few "retrans out leaked" messages. > > You might be missing the topmost part of the backtrace which is probably > in tcp_clean_rtx_queue() or even more likely tcp_tso_acked() where there > are several assertions present. > > I guess your compiler is auto-inlining those functions for you, > can you reproduce the crash with perhaps the noinline attribute > added to those two functions I mention above so we can get a > precise backtrace? Hmpf, it stopped crashing after I recompiled without -funit-at-a-time Maybe it is some compiler issue. -Andi From tgraf@suug.ch Tue Sep 28 17:01:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:01:49 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T01gGP002606 for ; Tue, 28 Sep 2004 17:01:43 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 6DF5481; Wed, 29 Sep 2004 02:01:07 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id 65CB51C0E8; Wed, 29 Sep 2004 02:01:50 +0200 (CEST) Date: Wed, 29 Sep 2004 02:01:50 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2.4 PKT_SCHED] Report qdisc parent to userspace Message-ID: <20040929000150.GA9113@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 9632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1304 Lines: 37 Report parent classid of a qdisc back to userspace. Without this there is no way for userspace to see if the qdisc is attached to a class other than parsing all class trees of the link and check all tcm_info fields in the leaf classes. Signed-off-by: Thomas Graf --- linux-2.4.28-pre3-bk4.orig/include/net/pkt_sched.h 2004-09-29 00:42:01.000000000 +0200 +++ linux-2.4.28-pre3-bk4/include/net/pkt_sched.h 2004-09-29 00:54:46.000000000 +0200 @@ -81,6 +81,7 @@ #define TCQ_F_INGRES 4 struct Qdisc_ops *ops; u32 handle; + u32 parent; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; --- linux-2.4.28-pre3-bk4.orig/net/sched/sch_api.c 2004-09-29 00:42:03.000000000 +0200 +++ linux-2.4.28-pre3-bk4/net/sched/sch_api.c 2004-09-29 00:59:36.000000000 +0200 @@ -371,6 +371,8 @@ unsigned long cl = cops->get(parent, classid); if (cl) { err = cops->graft(parent, cl, new, old); + if (new) + new->parent = classid; cops->put(parent, cl); } } @@ -812,7 +814,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, 0, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock(&qdisc_tree_lock); goto done; From shemminger@osdl.org Tue Sep 28 17:02:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:02:48 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T02gNh002952 for ; Tue, 28 Sep 2004 17:02:42 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8T01cv01295; Tue, 28 Sep 2004 17:01:38 -0700 Subject: Re: RFC/PATCH capture qdisc requeue event in stats From: Stephen Hemminger To: "David S. Miller" Cc: hadi@cyberus.ca, davem@redhat.com, netdev@oss.sgi.com In-Reply-To: <20040928161838.3d19a17d.davem@davemloft.net> References: <1093799632.1073.410.camel@jzny.localdomain> <1096413009.27967.1.camel@localhost.localdomain> <20040928161838.3d19a17d.davem@davemloft.net> Content-Type: text/plain Organization: Open Source Development Lab Date: Tue, 28 Sep 2004 17:01:41 -0700 Message-Id: <1096416101.27967.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 901 Lines: 29 On Tue, 2004-09-28 at 16:18 -0700, David S. Miller wrote: > On Tue, 28 Sep 2004 16:10:09 -0700 > Stephen Hemminger wrote: > > > On Sun, 2004-08-29 at 13:13 -0400, jamal wrote: > > > > > > The requeue event is useful in finding out when a device is overloaded > > > on the egress (bus or bandwidth). > > > Atached patch introduces this. I would have used the overlimit bits > > > but at the moment thats being used for different semantical reasons. > > > I have not done extensive testing on it. > > > > > > Opinions welcome - If all is good, Dave please apply. > > > > Dave, what happened to this? I put the stuff into iproute2 but the > > requeue stat never made it into 2.6. Is it a bad idea? > > Yes, API breaker. Well it seems to work for me: kernel New Old tc New Ok Ok(0) Old Ok(0) Ok Because tc correctly handles the returned TLV size. From davem@davemloft.net Tue Sep 28 17:03:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:03:58 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T03rVl003291 for ; Tue, 28 Sep 2004 17:03:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCRwB-0000bp-00; Tue, 28 Sep 2004 17:03:15 -0700 Date: Tue, 28 Sep 2004 17:03:15 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: RFC/PATCH capture qdisc requeue event in stats Message-Id: <20040928170315.760b9851.davem@davemloft.net> In-Reply-To: <1096416101.27967.10.camel@localhost.localdomain> References: <1093799632.1073.410.camel@jzny.localdomain> <1096413009.27967.1.camel@localhost.localdomain> <20040928161838.3d19a17d.davem@davemloft.net> <1096416101.27967.10.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1263 Lines: 37 On Tue, 28 Sep 2004 17:01:41 -0700 Stephen Hemminger wrote: > On Tue, 2004-09-28 at 16:18 -0700, David S. Miller wrote: > > On Tue, 28 Sep 2004 16:10:09 -0700 > > Stephen Hemminger wrote: > > > > > On Sun, 2004-08-29 at 13:13 -0400, jamal wrote: > > > > > > > > The requeue event is useful in finding out when a device is overloaded > > > > on the egress (bus or bandwidth). > > > > Atached patch introduces this. I would have used the overlimit bits > > > > but at the moment thats being used for different semantical reasons. > > > > I have not done extensive testing on it. > > > > > > > > Opinions welcome - If all is good, Dave please apply. > > > > > > Dave, what happened to this? I put the stuff into iproute2 but the > > > requeue stat never made it into 2.6. Is it a bad idea? > > > > Yes, API breaker. > > Well it seems to work for me: > kernel > New Old > tc New Ok Ok(0) > Old Ok(0) Ok > > Because tc correctly handles the returned TLV size. Because tc has all the length checking stuff added to it, other applications using netlink might not. The whole world is not 'tc'. I'm just rehashing how the most recent thread between Jamal and myself ended about this topic. From davem@davemloft.net Tue Sep 28 17:05:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:05:25 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T05KIo003646 for ; Tue, 28 Sep 2004 17:05:21 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCRxE-0000c9-00; Tue, 28 Sep 2004 17:04:20 -0700 Date: Tue, 28 Sep 2004 17:04:20 -0700 From: "David S. Miller" To: Andi Kleen Cc: herbert@gondor.apana.org.au, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040928170420.7f8a6612.davem@davemloft.net> In-Reply-To: <20040929015534.3b39b720.ak@suse.de> References: <20040923164149.5368d291.davem@davemloft.net> <20040927025048.GA6723@gondor.apana.org.au> <20040926210029.22750d47.davem@davemloft.net> <20040927054541.GA8858@gondor.apana.org.au> <20040927120154.09fdcadf.davem@davemloft.net> <20040927213233.GC7243@gondor.apana.org.au> <20040928141002.164c60af.davem@davemloft.net> <20040928213415.GA4646@wotan.suse.de> <20040928145345.2530d30e.davem@davemloft.net> <20040928223344.GC2975@wotan.suse.de> <20040928155706.65405e88.davem@davemloft.net> <20040929012757.5d0dff61.ak@suse.de> <20040928163509.624a748b.davem@davemloft.net> <20040929015534.3b39b720.ak@suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 310 Lines: 9 On Wed, 29 Sep 2004 01:55:34 +0200 Andi Kleen wrote: > Hmpf, it stopped crashing after I recompiled without -funit-at-a-time > Maybe it is some compiler issue. Could be, I was studying all of the retransmit queue state handling and tried to find some hole in the TSO case and I could not do so. From herbert@gondor.apana.org.au Tue Sep 28 17:14:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:14:11 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T0E2Ff004107 for ; Tue, 28 Sep 2004 17:14:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCS6B-0005Vu-00; Wed, 29 Sep 2004 10:13:35 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCS63-0006gE-00; Wed, 29 Sep 2004 10:13:27 +1000 Date: Wed, 29 Sep 2004 10:13:27 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040929001327.GB25293@gondor.apana.org.au> References: <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096374736.8663.217.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3083 Lines: 70 On Tue, Sep 28, 2004 at 08:32:17AM -0400, jamal wrote: > > Actually i just examined the events generated by the script, they are > IFLA and ROUTE events and not IFA. > So take a look at:rtmsg_ifinfo() You're right. rtmsg_info() is using GOODISZE unnecessarily. I'll write up a patch. > Ah, but theres clearly benefit into saving packets from crossing to user > space in particular in the case of overload. You do save on system > resources for sure in that case. Can you please elaborate on those benefites/resources? > Agreed it will postpone the problem, and not cure it. > Where i saw the benefit is if this queue is full/overloaded then you > dont bother transfering skbs to the sock receiveQ - instead you overrun > the event listeners (on purpose) before giving them any data. This If you do this when only one listener's queue is full, then doesn't this mean that you penalise everyone just because one task's receive queue is small? > > In fact this has an advantage over the intermediate queue. With the > > latter, you need to hold the packet in place whether the applications > > need it or not. While currently, the application can choose whether > > it wants to receive a large batch of events and if so how large. > > Right, but only find out after reading a subset of messages which cross > into user space. Which is wasted cycles really. Can you please elaborate on "crossing into user space"? I don't think I understand where these cycles are being wasted. > Now if you could say from user space "please continue where you left > over" the messages before overrun wont be a waste. I do think thats not > wise for events(you should be able a summary of the issue some other way > as in overruns at the moment) but is definetely need for large get > results. What do you mean by large get results? I thought we've agreed that scenarios 1) and 2) (get and dump) cannot generate overruns unless you're doing something silly like sharing your unicast socket with multicast. Please point me to a netlink get function that returns an unbounded or unreasonably large skb. > A large queue may actually be a problem if it also gets overflown since > it takes relatively longer to find out. You still have to read the damn > state to find out details. Not quite. Overrun errors are reported immediately. What we don't have is an easy way to flush out the unread messages from before the overrun. Well actually you could just close the socket and reopen it. > Its actually worse than that -->which is a shame since we have more > control over what can be sent to user. > Congestion could be driven by receiver as well. Look at TCP zero windows > for example. Or even ECN. Yes but the end result is that the sender stops sending. I'm not aware of any existing TCP mechanisms that result in packets being queued in a router on the way. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgr@reeler.org Tue Sep 28 17:37:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:37:22 -0700 (PDT) Received: from rei.rakuen (217-162-107-144.dclient.hispeed.ch [217.162.107.144]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T0bG2P005214 for ; Tue, 28 Sep 2004 17:37:17 -0700 Received: from tgr by rei.rakuen with local (Exim 4.34) id 1CCSSm-0002mp-TW; Wed, 29 Sep 2004 02:36:56 +0200 Date: Wed, 29 Sep 2004 02:36:56 +0200 From: Thomas Graf To: "David S. Miller" Cc: hadi@cyberus.ca, netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: RFC/PATCH capture qdisc requeue event in stats Message-ID: <20040929003656.GX31616@rei.reeler.org> References: <1093799632.1073.410.camel@jzny.localdomain> <20040830144033.2265a6e6.davem@redhat.com> <1093904088.1043.12.camel@jzny.localdomain> <20040830154430.769d1d59.davem@redhat.com> <1093906592.1037.32.camel@jzny.localdomain> <20040830160052.548c4846.davem@redhat.com> <1093916592.1037.51.camel@jzny.localdomain> <20040830191716.0d002f91.davem@redhat.com> <1093919823.1043.80.camel@jzny.localdomain> <20040830212910.78047bcd.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830212910.78047bcd.davem@davemloft.net> X-archive-position: 9637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 790 Lines: 23 * David S. Miller <20040830212910.78047bcd.davem@davemloft.net> 2004-08-30 21:29 > Look, let's get real about this topic. We can't be breaking shit > like this all the time. We're nearly letting it happen a lot > lately. > > These data structures are user visible APIs, they are just like > system call data structures, and if we cannot modify > them without potentially breaking some existing application we > cannot make that change. Why not do it by using nested TLVs?: TCA_STATS2 [ TCA_STAT_BYTES TCA_STAT_PACKETS TCA_STAT_DROPS ... ] This way we can add as many new stats as we want without even thinking about backward compatibility in the future. This would also allow to implement dynamic size statistics or introduce TCA_STAT_*_64 if ever needed. From mcgrof@studorgs.rutgers.edu Tue Sep 28 17:48:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 17:48:26 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T0mKQi005675 for ; Tue, 28 Sep 2004 17:48:21 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 837A8F99BD; Tue, 28 Sep 2004 20:48:08 -0400 (EDT) Date: Tue, 28 Sep 2004 20:48:08 -0400 To: Vladimir Kondratiev Cc: "Luis R. Rodriguez" , greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-ID: <20040929004808.GN30131@ruslug.rutgers.edu> Mail-Followup-To: Vladimir Kondratiev , "Luis R. Rodriguez" , greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org, sam@errno.com References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <413F70F0.6020709@atheros.com> <20040928122028.GK30131@ruslug.rutgers.edu> <200409282229.53349.vkondra@mail.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwXh6gFRjCd3qPCM" Content-Disposition: inline In-Reply-To: <200409282229.53349.vkondra@mail.ru> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 1315 Lines: 43 --OwXh6gFRjCd3qPCM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote: > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote: > LR> RFC: what are the chances we can implement our own generic "softmac" = that may > LR> be usable by the different chipsets out there? >=20 > Coming days, I will submit "framework" consisting of stack based on Dave'= s=20 > code and debug driver which will be able to imitate Rx. I have working ba= sic=20 > Tx/Rx. Then, I'd like to concentrate on interfaces stack-driver and=20 > stack-upper layers. It would be great if someone will do MAC algorithms. = I'll=20 > appreciate this for sure. But would it be possible? Would it work, if we write our own softmac interface? Or are softmac interaces/libraries strictly dependent on a chipset being used? Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --OwXh6gFRjCd3qPCM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWgZIat1JN+IKUl4RAn8AAKCDiw8wWMQF04IZBAlcEBhSvqGZuQCdEacr jGiIIsQzZ7YanJksfluH37Q= =hT92 -----END PGP SIGNATURE----- --OwXh6gFRjCd3qPCM-- From hadi@cyberus.ca Tue Sep 28 19:16:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:16:48 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2Gghd011782 for ; Tue, 28 Sep 2004 19:16:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CCU16-0004vA-5z for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:16:28 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCU0u-0007Za-1h; Tue, 28 Sep 2004 22:16:16 -0400 Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) From: jamal Reply-To: hadi@cyberus.ca To: Robert Olsson Cc: Harald Welte , Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <16729.29634.992171.862677@robur.slu.se> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <1096375700.8659.235.camel@jzny.localdomain> <16729.29634.992171.862677@robur.slu.se> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096424171.1041.87.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:16:12 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 390 Lines: 14 On Tue, 2004-09-28 at 10:22, Robert Olsson wrote: > OK it's EWMA calc in kernel. [..] > As usual most code is honestly stolen from Alexey. :-) >From the maestro himself ;-> Why reinvent music my friend? You are probably using the same code. I just ripped it from netsched and made it available to the general masses. BTW, if you see any missing tricks there let me know cheers, jamal From hadi@cyberus.ca Tue Sep 28 19:22:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:22:34 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2MTMW012178 for ; Tue, 28 Sep 2004 19:22:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CCU6j-0000qr-DT for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:22:17 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCU6d-0008E7-Tb; Tue, 28 Sep 2004 22:22:12 -0400 Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Harald Welte , Robert Olsson , Stephen Hemminger , "David S. Miller" , herbert@gondor.apana.org.au, netdev@oss.sgi.com In-Reply-To: <20040928133334.GW31616@rei.reeler.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <1096375700.8659.235.camel@jzny.localdomain> <20040928133334.GW31616@rei.reeler.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096424527.1044.94.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:22:07 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1187 Lines: 32 On Tue, 2004-09-28 at 09:33, Thomas Graf wrote: > > Speaking of generic stats; i have a patch netlink ready which may need > > some extensions. I did post it a while back on netdev but didnt get > > feedback. > > The code looks good and I couldn't spot any errors but I'm not > sure if the locking in gen_copy_[x]stats is a good thing. > Shouldn't that be done earlier by the caller? In the netsched code that became a portability issue; Dave fixed it there, so i just replicated here. If you feel like doing something clever you are welcome to submit a patch. > This prevents > corruption but it allows duplicated TLVs in an skb. I suggest > to make the caller have a lock on his data and only allow one > dumper at the same time until the dump is complete, or at least > provide a lockless variant for callers doing the locking on > their own. > Reminds me: gnet_stats needs to have TLVs embedded in it. bytes,drops, packets are generic enough; others are not. So if we add a length field then we can add TLVs for things like QSTATS = { qlen, backlog} etc. This means we could then allow for adding a lot of different stats. A big lesson from current tc_stats. cheers, jamal From hadi@cyberus.ca Tue Sep 28 19:24:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:24:21 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2OGsW013041 for ; Tue, 28 Sep 2004 19:24:16 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CCU8T-000578-P4 for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:24:05 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCU8P-0008R6-NI; Tue, 28 Sep 2004 22:24:01 -0400 Subject: Re: On DaveMs congestion control algorithm WAS(Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: herbert@gondor.apana.org.au, pablo@eurodev.net, netdev@oss.sgi.com In-Reply-To: <20040928112432.238f433c.davem@davemloft.net> References: <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <20040928121647.GA21121@gondor.apana.org.au> <1096375188.8663.226.camel@jzny.localdomain> <20040928112432.238f433c.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096424636.1043.97.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:23:56 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 351 Lines: 14 On Tue, 2004-09-28 at 14:24, David S. Miller wrote: > I just wait > for the dust to settle in the form of a patch and then I > reread the thread as if it were the latest drama show on TV > :-) Ok, turn on your Tivo and go back to your regularly scheduled programme ;-> Herbert is one determined dude, so the drama aint over yet ;-> cheers, jamal From hadi@cyberus.ca Tue Sep 28 19:28:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:28:58 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2Sr7n013443 for ; Tue, 28 Sep 2004 19:28:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CCUCw-0003ap-LJ for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:28:42 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCUCs-0000SV-Iq; Tue, 28 Sep 2004 22:28:38 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Pablo Neira Cc: Herbert Xu , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <4159D278.4060809@eurodev.net> References: <20040923120707.GB32624@gondor.apana.org.au> <1095995042.1044.34.camel@jzny.localdomain> <20040924032440.GB6384@gondor.apana.org.au> <1096289189.1075.37.camel@jzny.localdomain> <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <4159D278.4060809@eurodev.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096424914.1043.103.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:28:34 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 632 Lines: 16 On Tue, 2004-09-28 at 17:07, Pablo Neira wrote: > I'm also thinking in doing something with netlink_ack's since they can > be drop if buffer is full. We could give more priority to error messages > in some way, for example, check if there's space for an error message in > the buffer, if there's not, drop as many packets in buffer as we get > space to enqueue the error message. Being able to prioritize control (errors and ACKs) would be valuable. Would require mucking around with the socket queue. Something along what we do for a basic default 3 band queue (proabably two band in this case) should work. cheers, jamal From hadi@cyberus.ca Tue Sep 28 19:31:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:31:47 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2VhO2013832 for ; Tue, 28 Sep 2004 19:31:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CCUFg-0004hC-0R for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:31:32 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCUFd-0000k1-7z; Tue, 28 Sep 2004 22:31:29 -0400 Subject: Re: RFC/PATCH capture qdisc requeue event in stats From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: Stephen Hemminger , netdev@oss.sgi.com In-Reply-To: <20040928170315.760b9851.davem@davemloft.net> References: <1093799632.1073.410.camel@jzny.localdomain> <1096413009.27967.1.camel@localhost.localdomain> <20040928161838.3d19a17d.davem@davemloft.net> <1096416101.27967.10.camel@localhost.localdomain> <20040928170315.760b9851.davem@davemloft.net> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096425085.1041.107.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:31:25 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 680 Lines: 25 On Tue, 2004-09-28 at 20:03, David S. Miller wrote: > > > > Well it seems to work for me: > > kernel > > New Old > > tc New Ok Ok(0) > > Old Ok(0) Ok > > > > Because tc correctly handles the returned TLV size. > > Because tc has all the length checking stuff added to > it, other applications using netlink might not. The > whole world is not 'tc'. > > I'm just rehashing how the most recent thread between > Jamal and myself ended about this topic. Steve just kill it for now - Dave is right. I think maybe something based out of a cleaned gnet_stats patch i posted earlier would be the best path forward. I will try to clean it up. cheers, jamal From herbert@gondor.apana.org.au Tue Sep 28 19:31:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:31:37 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2VRhP013812 for ; Tue, 28 Sep 2004 19:31:28 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCUF5-0006Ns-00; Wed, 29 Sep 2004 12:30:55 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCUF1-0006xF-00; Wed, 29 Sep 2004 12:30:51 +1000 Date: Wed, 29 Sep 2004 12:30:51 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040929023051.GA26716@gondor.apana.org.au> References: <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <4159D278.4060809@eurodev.net> <1096424914.1043.103.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096424914.1043.103.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 680 Lines: 16 On Tue, Sep 28, 2004 at 10:28:34PM -0400, jamal wrote: > > Being able to prioritize control (errors and ACKs) would be valuable. > Would require mucking around with the socket queue. > Something along what we do for a basic default 3 band queue (proabably > two band in this case) should work. Obviously neither of you have taken my tip :) You should never use your unicast socket to receive multicast messages. Otherwise you get to keep both pieces when it breaks. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hadi@cyberus.ca Tue Sep 28 19:52:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:52:28 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2qOtY014909 for ; Tue, 28 Sep 2004 19:52:24 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CCUZh-0008JO-Hf for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:52:13 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCUZd-0002lE-AH; Tue, 28 Sep 2004 22:52:09 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040929001327.GB25293@gondor.apana.org.au> References: <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> <20040929001327.GB25293@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096426324.1044.129.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:52:05 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3564 Lines: 88 On Tue, 2004-09-28 at 20:13, Herbert Xu wrote: > On Tue, Sep 28, 2004 at 08:32:17AM -0400, jamal wrote: > > > > Actually i just examined the events generated by the script, they are > > IFLA and ROUTE events and not IFA. > > So take a look at:rtmsg_ifinfo() > > You're right. rtmsg_info() is using GOODISZE unnecessarily. I'll > write up a patch. But why? ;-> > > Ah, but theres clearly benefit into saving packets from crossing to user > > space in particular in the case of overload. You do save on system > > resources for sure in that case. > > Can you please elaborate on those benefites/resources? Well, if you are gonna overrun the socket anyways, is there a point in delivering all that incomplete info? If you go ahead and deliver it anyways, you will be crossing kernel->userspace. Its a worthy cause to do so. > If you do this when only one listener's queue is full, then doesn't this > mean that you penalise everyone just because one task's receive queue is > small? Yes, thats part of the issues. > > Right, but only find out after reading a subset of messages which cross > > into user space. Which is wasted cycles really. > > Can you please elaborate on "crossing into user space"? I don't think > I understand where these cycles are being wasted. delivering messages which get obsoleted by an overun from kernel to user space for uses up unnecessary cycles. > > Now if you could say from user space "please continue where you left > > over" the messages before overrun wont be a waste. I do think thats not > > wise for events(you should be able a summary of the issue some other way > > as in overruns at the moment) but is definetely need for large get > > results. > > What do you mean by large get results? I thought we've agreed that > scenarios 1) and 2) (get and dump) cannot generate overruns unless > you're doing something silly like sharing your unicast socket with > multicast. Please point me to a netlink get function that returns > an unbounded or unreasonably large skb. A dump may be harder given it keeps state. A get item which generates a huge dataset (dont ask me to give you an example) is going to cause overruns. Think a multi message formated data. > > A large queue may actually be a problem if it also gets overflown since > > it takes relatively longer to find out. You still have to read the damn > > state to find out details. > > Not quite. Overrun errors are reported immediately. Yes, except they get reported sooner (by virtue of queue getting filled sooner) if you have a 4K sock buffer vs 1M if you are registered for the same events. I Know its a digression - just making a point. > What we don't > have is an easy way to flush out the unread messages from before the > overrun. Well actually you could just close the socket and reopen it. I think you you should be able to purge queue from the kernel side. I have a feeling we are talking two different things. > Yes but the end result is that the sender stops sending. I'm not aware > of any existing TCP mechanisms that result in packets being queued in a > router on the way. I think you are taking it too literal Herbet ;-> The end goal is what counts i.e the cause of congestion is alleviated. Intermidiate buffering is a very well known/used trick to alleviate congestion - especially in a local scenario. Of course such queues have finite buffers - you just engineer it so the queue doesnt overflow and head of line blocking is tolerable. Either of those concerns not addressed, shit will hit the fan. cheers, jamal From hadi@cyberus.ca Tue Sep 28 19:54:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:54:49 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2sjDG015241 for ; Tue, 28 Sep 2004 19:54:45 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CCUby-0005fs-8d for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:54:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCUbu-0002xH-Ar; Tue, 28 Sep 2004 22:54:30 -0400 Subject: Re: RFC/PATCH capture qdisc requeue event in stats From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com, shemminger@osdl.org In-Reply-To: <20040929003656.GX31616@rei.reeler.org> References: <1093799632.1073.410.camel@jzny.localdomain> <20040830144033.2265a6e6.davem@redhat.com> <1093904088.1043.12.camel@jzny.localdomain> <20040830154430.769d1d59.davem@redhat.com> <1093906592.1037.32.camel@jzny.localdomain> <20040830160052.548c4846.davem@redhat.com> <1093916592.1037.51.camel@jzny.localdomain> <20040830191716.0d002f91.davem@redhat.com> <1093919823.1043.80.camel@jzny.localdomain> <20040830212910.78047bcd.davem@davemloft.net> <20040929003656.GX31616@rei.reeler.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096426464.1045.133.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:54:24 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 36 On Tue, 2004-09-28 at 20:36, Thomas Graf wrote: > * David S. Miller <20040830212910.78047bcd.davem@davemloft.net> 2004-08-30 21:29 > > Look, let's get real about this topic. We can't be breaking shit > > like this all the time. We're nearly letting it happen a lot > > lately. > > > > These data structures are user visible APIs, they are just like > > system call data structures, and if we cannot modify > > them without potentially breaking some existing application we > > cannot make that change. > > Why not do it by using nested TLVs?: > > TCA_STATS2 [ > TCA_STAT_BYTES > TCA_STAT_PACKETS > TCA_STAT_DROPS > ... > ] Refer to my earlier email; i think this is a noble approach. Lets do it on gnet stats though so we can make it more accessible. I think your granularity maybe too thin: bytes,packets, drops may need to be in the same TLV. > This way we can add as many new stats as we want without > even thinking about backward compatibility in the future. > This would also allow to implement dynamic size statistics > or introduce TCA_STAT_*_64 if ever needed. Yep. do you have cycles to run with that patch? cheers, jamal From hadi@cyberus.ca Tue Sep 28 19:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 19:59:46 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T2xgCA015620 for ; Tue, 28 Sep 2004 19:59:42 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CCUgl-0001Nk-2a for netdev@oss.sgi.com; Tue, 28 Sep 2004 22:59:31 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCUgf-0003PM-CS; Tue, 28 Sep 2004 22:59:25 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040929023051.GA26716@gondor.apana.org.au> References: <20040927213607.GD7243@gondor.apana.org.au> <1096339407.8660.33.camel@jzny.localdomain> <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <4159D278.4060809@eurodev.net> <1096424914.1043.103.camel@jzny.localdomain> <20040929023051.GA26716@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096426760.1042.136.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 Sep 2004 22:59:20 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 607 Lines: 18 On Tue, 2004-09-28 at 22:30, Herbert Xu wrote: > On Tue, Sep 28, 2004 at 10:28:34PM -0400, jamal wrote: > > > > Being able to prioritize control (errors and ACKs) would be valuable. > > Would require mucking around with the socket queue. > > Something along what we do for a basic default 3 band queue (proabably > > two band in this case) should work. > > Obviously neither of you have taken my tip :) > > You should never use your unicast socket to receive multicast messages. > Otherwise you get to keep both pieces when it breaks. Ok, good point as long as it is common knowledge. cheers, jamal From herbert@gondor.apana.org.au Tue Sep 28 20:28:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 20:28:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T3SEcg019642 for ; Tue, 28 Sep 2004 20:28:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCV7u-0006d7-00; Wed, 29 Sep 2004 13:27:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCV7k-00077A-00; Wed, 29 Sep 2004 13:27:24 +1000 Date: Wed, 29 Sep 2004 13:27:24 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040929032724.GA26959@gondor.apana.org.au> References: <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> <20040929001327.GB25293@gondor.apana.org.au> <1096426324.1044.129.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <1096426324.1044.129.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 3750 Lines: 101 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 28, 2004 at 10:52:05PM -0400, jamal wrote: > > > You're right. rtmsg_info() is using GOODISZE unnecessarily. I'll > > write up a patch. > > But why? ;-> So that the alloc_skb() is slightly less likely to fail. The dumpers gain a lot by using GOODSIZE since they can fill it up. As rtmsg_info has no chance of getting anywhere near GOODSIZE we should provide a more accruate estimate. It also means that with netlink_trim() you'll save a realloc/copy. Signed-off-by: Herbert Xu Dave, you can stop reading now :) > Well, if you are gonna overrun the socket anyways, is there a point > in delivering all that incomplete info? > > If you go ahead and deliver it anyways, you will be crossing > kernel->userspace. Its a worthy cause to do so. Hang on a second, if we're going to overrun anyway, then we *can't* deliver it to user-space. If we could deliver then we wouldn't be having an overrun. > > Can you please elaborate on "crossing into user space"? I don't think > > I understand where these cycles are being wasted. > > delivering messages which get obsoleted by an overun from kernel to user > space for uses up unnecessary cycles. You'll have to spell it out for me I'm afraid :) If we're overrunning then we can't deliver the message at hand. If you are referring to the messages afterwards then the only way we can deliver them is if the appliation lets us by clearing the queue. If you are referring to the messages that are already on the queue then we've done the work already so why shouldn't they stay? > A dump may be harder given it keeps state. A get item which generates > a huge dataset (dont ask me to give you an example) is going to cause > overruns. Think a multi message formated data. That's a completely different story. For that problem I'd suggest that we extend the dump paradigm to cover get as well. However, to design the interface, we need to look at potential users of this. So please give me an example :) > > Not quite. Overrun errors are reported immediately. > > Yes, except they get reported sooner (by virtue of queue getting filled > sooner) if you have a 4K sock buffer vs 1M if you are registered for the > same events. I Know its a digression - just making a point. The one with the 1M buffer may not overrun at all if it can process the events fast enough. > congestion - especially in a local scenario. Of course such queues have > finite buffers - you just engineer it so the queue doesnt overflow and > head of line blocking is tolerable. Either of those concerns not > addressed, shit will hit the fan. I don't see how you can engineer it so that it doesn't overflow. In the example that you gave with interface address, the number of messages generated is practically unbounded. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== net/core/rtnetlink.c 1.28 vs edited ===== --- 1.28/net/core/rtnetlink.c 2004-09-22 12:16:43 +10:00 +++ edited/net/core/rtnetlink.c 2004-09-29 13:23:43 +10:00 @@ -412,7 +412,9 @@ void rtmsg_ifinfo(int type, struct net_device *dev, unsigned change) { struct sk_buff *skb; - int size = NLMSG_GOODSIZE; + int size = NLMSG_SPACE(sizeof(struct ifinfomsg) + + sizeof(struct rtnl_link_ifmap) + + sizeof(struct rtnl_link_stats) + 128); skb = alloc_skb(size, GFP_KERNEL); if (!skb) --UlVJffcvxoiEqYs2-- From jheffner@psc.edu Tue Sep 28 20:27:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 20:27:40 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T3RZV6019556 for ; Tue, 28 Sep 2004 20:27:36 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i8T3RMt4010254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 28 Sep 2004 23:27:22 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8T3RLFH027996; Tue, 28 Sep 2004 23:27:21 -0400 (EDT) Date: Tue, 28 Sep 2004 23:27:21 -0400 (EDT) From: John Heffner To: Andi Kleen cc: Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: <20040928223344.GC2975@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer1.psc.edu X-Virus-Status: Clean X-archive-position: 9648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1077 Lines: 29 On Wed, 29 Sep 2004, Andi Kleen wrote: > I'm afraid I must report it's still not completely solved for me yet. > 10s netperf with TSO on with your patches gives now ~10MB/s less than > with TSO off (57 vs 67). It's better than before, but not really > fixed yet. > > Looking at my tcpdumps and comparing TSO on/off I see a quite > strange effect. It only acks on every ~25th packet with TSO off > but every ~16th packet with TSO on. > > Receiver is a 2.6.5 kernel, it's weird that it violates the > ack every two MSS rule. Does this help? ===== net/ipv4/tcp_input.c 1.73 vs edited ===== --- 1.73/net/ipv4/tcp_input.c 2004-09-12 20:30:58 -04:00 +++ edited/net/ipv4/tcp_input.c 2004-09-28 23:23:40 -04:00 @@ -3936,7 +4048,7 @@ /* ... and right edge of window advances far enough. * (tcp_recvmsg() will send ACK otherwise). Or... */ - && __tcp_select_window(sk) >= tp->rcv_wnd) || + /* && __tcp_select_window(sk) >= tp->rcv_wnd */) || /* We ACK each frame or... */ tcp_in_quickack_mode(tp) || /* We have out of order data. */ From davem@davemloft.net Tue Sep 28 20:57:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 20:57:41 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T3vaEn020649 for ; Tue, 28 Sep 2004 20:57:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCVaE-0000rG-00; Tue, 28 Sep 2004 20:56:50 -0700 Date: Tue, 28 Sep 2004 20:56:50 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4 PKT_SCHED] Report qdisc parent to userspace Message-Id: <20040928205650.243d4e96.davem@davemloft.net> In-Reply-To: <20040929000150.GA9113@postel.suug.ch> References: <20040929000150.GA9113@postel.suug.ch> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 388 Lines: 11 On Wed, 29 Sep 2004 02:01:50 +0200 Thomas Graf wrote: > Report parent classid of a qdisc back to userspace. Without this there > is no way for userspace to see if the qdisc is attached to a class > other than parsing all class trees of the link and check all tcm_info > fields in the leaf classes. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Tue Sep 28 21:03:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 21:03:41 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T43aCV021051 for ; Tue, 28 Sep 2004 21:03:36 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCVfe-0000sR-00; Tue, 28 Sep 2004 21:02:26 -0700 Date: Tue, 28 Sep 2004 21:02:25 -0700 From: "David S. Miller" To: Herbert Xu Cc: hadi@cyberus.ca, pablo@eurodev.net, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-Id: <20040928210225.47b6038e.davem@davemloft.net> In-Reply-To: <20040929032724.GA26959@gondor.apana.org.au> References: <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> <20040929001327.GB25293@gondor.apana.org.au> <1096426324.1044.129.camel@jzny.localdomain> <20040929032724.GA26959@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 718 Lines: 24 On Wed, 29 Sep 2004 13:27:24 +1000 Herbert Xu wrote: > On Tue, Sep 28, 2004 at 10:52:05PM -0400, jamal wrote: > > > > > You're right. rtmsg_info() is using GOODISZE unnecessarily. I'll > > > write up a patch. > > > > But why? ;-> > > So that the alloc_skb() is slightly less likely to fail. The dumpers > gain a lot by using GOODSIZE since they can fill it up. As rtmsg_info > has no chance of getting anywhere near GOODSIZE we should provide a > more accruate estimate. > > It also means that with netlink_trim() you'll save a realloc/copy. > > Signed-off-by: Herbert Xu > > Dave, you can stop reading now :) Hehe, ok. Patch applied :-) Thanks. From jgarzik@pobox.com Tue Sep 28 21:13:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 21:13:14 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T4D5Tc021552 for ; Tue, 28 Sep 2004 21:13:06 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCVpk-0000WS-8w for netdev@oss.sgi.com; Wed, 29 Sep 2004 05:12:53 +0100 Message-ID: <415A3635.4070000@pobox.com> Date: Wed, 29 Sep 2004 00:12:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Tons of "BUG: dst overflow ..." messages Content-Type: multipart/mixed; boundary="------------080107040402060201000809" X-archive-position: 9652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 32519 Lines: 1403 This is a multi-part message in MIME format. --------------080107040402060201000809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Just logged into my router, which is running 2.6.9-rc2-bk1 (or -bk2, not sure), and saw a buttload of the following messages: [jgarzik@pretzel g]$ dmesg -s123000 |grep -c BUG 488 [jgarzik@pretzel g]$ dmesg -s123000 |grep BUG|sort|uniq BUG: dst underflow 0: cf5dd180 at f8c0be5d BUG: dst underflow 0: cf5dd180 at f8c0d15c BUG: dst underflow 0: cf5dd180 at f8c1656f router seems to be working fine regardless of these BUGs. ifconfig, .config, and lspci attached. Is this a known, already-fixed issue? Jeff --------------080107040402060201000809 Content-Type: text/plain; name="ifconfig.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifconfig.txt" eth0 Link encap:Ethernet HWaddr 00:00:21:DE:DE:B5 inet addr:24.74.155.169 Bcast:255.255.255.255 Mask:255.255.248.0 inet6 addr: fe80::200:21ff:fede:deb5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:46100088 errors:0 dropped:0 overruns:0 frame:0 TX packets:1501545 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4090350518 (3900.8 Mb) TX bytes:186842893 (178.1 Mb) Interrupt:209 Base address:0xcc00 eth1 Link encap:Ethernet HWaddr 00:C0:9F:39:CD:B0 inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0 inet6 addr: 2002:184a:9ba9:1010::1/128 Scope:Global inet6 addr: fe80::2c0:9fff:fe39:cdb0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9121472 errors:0 dropped:0 overruns:0 frame:0 TX packets:13244271 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2187962670 (2086.6 Mb) TX bytes:2779065013 (2650.3 Mb) Base address:0xece0 Memory:fe3e0000-fe400000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4425 errors:0 dropped:0 overruns:0 frame:0 TX packets:4425 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1177649 (1.1 Mb) TX bytes:1177649 (1.1 Mb) tun6to4 Link encap:IPv6-in-IPv4 inet6 addr: 2002:184a:9ba9::1/16 Scope:Global UP RUNNING NOARP MTU:1480 Metric:1 RX packets:393018 errors:0 dropped:0 overruns:0 frame:0 TX packets:401199 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:316294018 (301.6 Mb) TX bytes:43501485 (41.4 Mb) --------------080107040402060201000809 Content-Type: text/plain; name="lspci.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspci.txt" 00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02) 00:03.0 PCI bridge: Intel Corp. 82875P Processor to PCI to CSA Bridge (rev 02) 00:1c.0 PCI bridge: Intel Corp. 6300ESB 64-bit PCI-X Bridge (rev 02) 00:1d.0 USB Controller: Intel Corp. 6300ESB USB Universal Host Controller (rev 02) 00:1d.4 System peripheral: Intel Corp. 6300ESB Watchdog Timer (rev 02) 00:1d.5 PIC: Intel Corp. 6300ESB I/O Advanced Programmable Interrupt Controller (rev 02) 00:1d.7 USB Controller: Intel Corp. 6300ESB USB2 Enhanced Host Controller (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev 0a) 00:1f.0 ISA bridge: Intel Corp. 6300ESB LPC Interface Controller (rev 02) 00:1f.2 IDE interface: Intel Corp. 6300ESB SATA Storage Controller (rev 02) 00:1f.3 SMBus: Intel Corp. 6300ESB SMBus Controller (rev 02) 01:01.0 Ethernet controller: Intel Corp. 82547GI Gigabit Ethernet Controller 02:03.0 RAID bus controller: Promise Technology, Inc.: Unknown device 3371 (rev 02) 03:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 03:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) --------------080107040402060201000809 Content-Type: text/plain; name="config.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="config.txt" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.9-rc1 # Sun Aug 29 19:45:11 2004 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=16 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_SCHED_SMT=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_X86_PAE=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_PROC_INTF is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y # CONFIG_CPU_FREQ_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_GOV_ONDEMAND is not set CONFIG_CPU_FREQ_TABLE=y # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=y # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_SPEEDSTEP_ICH=y # CONFIG_X86_SPEEDSTEP_SMI is not set CONFIG_X86_P4_CLOCKMOD=y CONFIG_X86_SPEEDSTEP_LIB=y # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set CONFIG_PCI_GODIRECT=y # CONFIG_PCI_GOANY is not set CONFIG_PCI_DIRECT=y CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_NAMES is not set CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_IDE_TASK_IOCTL=y CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_IDE_GENERIC is not set # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_SVW=m CONFIG_SCSI_ATA_PIIX=m CONFIG_SCSI_SATA_NV=m CONFIG_SCSI_SATA_PROMISE=m CONFIG_SCSI_SATA_SX4=m CONFIG_SCSI_SATA_SIL=m CONFIG_SCSI_SATA_SIS=m CONFIG_SCSI_SATA_VIA=m CONFIG_SCSI_SATA_VITESSE=m # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set CONFIG_SCSI_DEBUG=m # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID5=m CONFIG_MD_RAID6=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y CONFIG_INET_TUNNEL=y # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m CONFIG_IPV6_TUNNEL=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_COMPAT_IPFWADM=m # CONFIG_IP_NF_TARGET_NOTRACK is not set CONFIG_IP_NF_RAW=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m # CONFIG_IP_NF_CT_ACCT is not set # CONFIG_IP_NF_MATCH_SCTP is not set # CONFIG_IP_NF_CT_PROTO_SCTP is not set # # IPv6: Netfilter Configuration # CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_IP6_NF_RAW=m CONFIG_XFRM=y CONFIG_XFRM_USER=y # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set CONFIG_SCTP_HMAC_SHA1=y # CONFIG_SCTP_HMAC_MD5 is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set CONFIG_LLC=y CONFIG_LLC2=y # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set CONFIG_NET_CLS_ROUTE=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=y # CONFIG_ETHERTAP is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set CONFIG_8139TOO_TUNE_TWISTER=y # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m CONFIG_E1000_NAPI=y # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_UINPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_INTEL_MCH is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y # CONFIG_HANGCHECK_TIMER is not set # # I2C support # # CONFIG_I2C is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set # CONFIG_VIDEO_SELECT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # # CONFIG_SND is not set # # Open Sound System # CONFIG_SOUND_PRIME=y # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set CONFIG_SOUND_ICH=m # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_AD1980 is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_RW_DETECT=y # CONFIG_USB_STORAGE_DATAFAB is not set CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y # CONFIG_USB_STORAGE_HP8200e is not set CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m # CONFIG_VFAT_FS is not set CONFIG_FAT_DEFAULT_CODEPAGE=437 # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS_XATTR=y # CONFIG_DEVPTS_FS_SECURITY is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_RPCSEC_GSS_SPKM3=m # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_INFO is not set # CONFIG_FRAME_POINTER is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set CONFIG_SCHEDSTATS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_WHIRLPOOL is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_SERPENT is not set CONFIG_CRYPTO_AES_586=y # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_KHAZAD is not set CONFIG_CRYPTO_DEFLATE=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_TEST is not set # # Library routines # # CONFIG_CRC_CCITT is not set CONFIG_CRC32=m # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --------------080107040402060201000809-- From davem@davemloft.net Tue Sep 28 21:41:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 21:41:42 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T4fb3p022430 for ; Tue, 28 Sep 2004 21:41:37 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCWGt-0000uy-00; Tue, 28 Sep 2004 21:40:55 -0700 Date: Tue, 28 Sep 2004 21:40:55 -0700 From: "David S. Miller" To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: Re: Tons of "BUG: dst overflow ..." messages Message-Id: <20040928214055.609f7715.davem@davemloft.net> In-Reply-To: <415A3635.4070000@pobox.com> References: <415A3635.4070000@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 291 Lines: 9 On Wed, 29 Sep 2004 00:12:37 -0400 Jeff Garzik wrote: > BUG: dst underflow 0: cf5dd180 at f8c0be5d > BUG: dst underflow 0: cf5dd180 at f8c0d15c > BUG: dst underflow 0: cf5dd180 at f8c1656f Can you match up the 0xf8xxxxxx addresses to spots in your System.map? Thanks. From davem@davemloft.net Tue Sep 28 21:48:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 21:48:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T4m2Il022828 for ; Tue, 28 Sep 2004 21:48:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCWN9-0000vi-00; Tue, 28 Sep 2004 21:47:23 -0700 Date: Tue, 28 Sep 2004 21:47:22 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Cc: robert.olsson@data.slu.se Subject: Move fib_alias out of fib_hash.c Message-Id: <20040928214722.11aef8e0.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__28_Sep_2004_21_47_22_-0700_xboskaUt20hTw6lG" X-archive-position: 9654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 16333 Lines: 240 This is a multi-part message in MIME format. --Multipart=_Tue__28_Sep_2004_21_47_22_-0700_xboskaUt20hTw6lG Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Ok, this begins the movement of fib_alias object handling out of fib_hash.c The idea is to make fib_hash.c purely a longest-matching-prefix lookup implementation. Look at fn_hash_lookup() after these changes, and you'll get an idea of how I want the whole fib_hash.c file to look in the end. I'll work on insert/delete tomorrow. --Multipart=_Tue__28_Sep_2004_21_47_22_-0700_xboskaUt20hTw6lG Content-Type: application/octet-stream; name="diff1" Content-Disposition: attachment; filename="diff1" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMjA6NDk6NTItMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW0lQVjRdOiBEZWZpbmUgZmliX2FsaWFzIGluIG5ldyBoZWFkZXIgZmli X2xvb2t1cC5oCiMgICAKIyAgIEFsc28gcy9GTl9TX0FDQ0VTU0VEL0ZBX1NfQUNDRVNTRUQvCiMg ICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5l dD4KIyAKIyBuZXQvaXB2NC9maWJfaGFzaC5jCiMgICAyMDA0LzA5LzI4IDIwOjQ5OjEzLTA3OjAw IGRhdmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArNyAtMTYKIyAgIFtJUFY0XTogRGVmaW5lIGZpYl9h bGlhcyBpbiBuZXcgaGVhZGVyIGZpYl9sb29rdXAuaAojIAojIG5ldC9pcHY0L2ZpYl9sb29rdXAu aAojICAgMjAwNC8wOS8yOCAyMDo0OTowNy0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQg KzE5IC0wCiMgICBbSVBWNF06IERlZmluZSBmaWJfYWxpYXMgaW4gbmV3IGhlYWRlciBmaWJfbG9v a3VwLmgKIyAKIyBuZXQvaXB2NC9maWJfbG9va3VwLmgKIyAgIDIwMDQvMDkvMjggMjA6NDk6MDct MDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICswIC0wCiMgICBCaXRLZWVwZXIgZmlsZSAv ZGlzazEvQksvbmV0LTIuNi9uZXQvaXB2NC9maWJfbG9va3VwLmgKIyAKZGlmZiAtTnJ1IGEvbmV0 L2lwdjQvZmliX2hhc2guYyBiL25ldC9pcHY0L2ZpYl9oYXNoLmMKLS0tIGEvbmV0L2lwdjQvZmli X2hhc2guYwkyMDA0LTA5LTI4IDIxOjI0OjQ2IC0wNzowMAorKysgYi9uZXQvaXB2NC9maWJfaGFz aC5jCTIwMDQtMDktMjggMjE6MjQ6NDYgLTA3OjAwCkBAIC00Myw2ICs0Myw4IEBACiAjaW5jbHVk ZSA8bmV0L3NvY2suaD4KICNpbmNsdWRlIDxuZXQvaXBfZmliLmg+CiAKKyNpbmNsdWRlICJmaWJf bG9va3VwLmgiCisKIHN0YXRpYyBrbWVtX2NhY2hlX3QgKmZuX2hhc2hfa21lbTsKIHN0YXRpYyBr bWVtX2NhY2hlX3QgKmZuX2FsaWFzX2ttZW07CiAKQEAgLTUyLDE3ICs1NCw2IEBACiAJdTMyCQkJ Zm5fa2V5OwogfTsKIAotc3RydWN0IGZpYl9hbGlhcyB7Ci0Jc3RydWN0IGxpc3RfaGVhZAlmYV9s aXN0OwotCXN0cnVjdCBmaWJfaW5mbwkJKmZhX2luZm87Ci0JdTgJCQlmYV90b3M7Ci0JdTgJCQlm YV90eXBlOwotCXU4CQkJZmFfc2NvcGU7Ci0JdTgJCQlmYV9zdGF0ZTsKLX07Ci0KLSNkZWZpbmUg Rk5fU19BQ0NFU1NFRAkxCi0KIHN0cnVjdCBmbl96b25lIHsKIAlzdHJ1Y3QgZm5fem9uZQkJKmZ6 X25leHQ7CS8qIE5leHQgbm90IGVtcHR5IHpvbmUJKi8KIAlzdHJ1Y3QgaGxpc3RfaGVhZAkqZnpf aGFzaDsJLyogSGFzaCB0YWJsZSBwb2ludGVyCSovCkBAIC0yNzcsNyArMjY4LDcgQEAKIAkJCQlp ZiAoZmEtPmZhX3Njb3BlIDwgZmxwLT5mbDRfc2NvcGUpCiAJCQkJCWNvbnRpbnVlOwogCi0JCQkJ ZmEtPmZhX3N0YXRlIHw9IEZOX1NfQUNDRVNTRUQ7CisJCQkJZmEtPmZhX3N0YXRlIHw9IEZBX1Nf QUNDRVNTRUQ7CiAKIAkJCQllcnIgPSBmaWJfc2VtYW50aWNfbWF0Y2goZmEtPmZhX3R5cGUsCiAJ CQkJCQkJIGZhLT5mYV9pbmZvLApAQCAtMzU4LDcgKzM0OSw3IEBACiAJCQlpZiAoIW5leHRfZmkt PmZpYl9uaFswXS5uaF9ndyB8fAogCQkJICAgIG5leHRfZmktPmZpYl9uaFswXS5uaF9zY29wZSAh PSBSVF9TQ09QRV9MSU5LKQogCQkJCWNvbnRpbnVlOwotCQkJZmEtPmZhX3N0YXRlIHw9IEZOX1Nf QUNDRVNTRUQ7CisJCQlmYS0+ZmFfc3RhdGUgfD0gRkFfU19BQ0NFU1NFRDsKIAogCQkJaWYgKGZp ID09IE5VTEwpIHsKIAkJCQlpZiAobmV4dF9maSAhPSByZXMtPmZpKQpAQCAtNTIxLDExICs1MTIs MTEgQEAKIAkJCWZhLT5mYV90eXBlID0gdHlwZTsKIAkJCWZhLT5mYV9zY29wZSA9IHItPnJ0bV9z Y29wZTsKIAkJCXN0YXRlID0gZmEtPmZhX3N0YXRlOwotCQkJZmEtPmZhX3N0YXRlICY9IH5GTl9T X0FDQ0VTU0VEOworCQkJZmEtPmZhX3N0YXRlICY9IH5GQV9TX0FDQ0VTU0VEOwogCQkJd3JpdGVf dW5sb2NrX2JoKCZmaWJfaGFzaF9sb2NrKTsKIAogCQkJZmliX3JlbGVhc2VfaW5mbyhmaV9kcm9w KTsKLQkJCWlmIChzdGF0ZSAmIEZOX1NfQUNDRVNTRUQpCisJCQlpZiAoc3RhdGUgJiBGQV9TX0FD Q0VTU0VEKQogCQkJCXJ0X2NhY2hlX2ZsdXNoKC0xKTsKIAkJCXJldHVybiAwOwogCQl9CkBAIC02 NjksNyArNjYwLDcgQEAKIAkJfQogCQl3cml0ZV91bmxvY2tfYmgoJmZpYl9oYXNoX2xvY2spOwog Ci0JCWlmIChmYS0+ZmFfc3RhdGUgJiBGTl9TX0FDQ0VTU0VEKQorCQlpZiAoZmEtPmZhX3N0YXRl ICYgRkFfU19BQ0NFU1NFRCkKIAkJCXJ0X2NhY2hlX2ZsdXNoKC0xKTsKIAkJZm5fZnJlZV9hbGlh cyhmYSk7CiAJCWlmIChraWxsX2ZuKSB7CmRpZmYgLU5ydSBhL25ldC9pcHY0L2ZpYl9sb29rdXAu aCBiL25ldC9pcHY0L2ZpYl9sb29rdXAuaAotLS0gL2Rldi9udWxsCVdlZCBEZWMgMzEgMTY6MDA6 MDAgMTk2OTAwCisrKyBiL25ldC9pcHY0L2ZpYl9sb29rdXAuaAkyMDA0LTA5LTI4IDIxOjI0OjQ2 IC0wNzowMApAQCAtMCwwICsxLDE5IEBACisjaWZuZGVmIF9GSUJfTE9PS1VQX0gKKyNkZWZpbmUg X0ZJQl9MT09LVVBfSAorCisjaW5jbHVkZSA8bGludXgvdHlwZXMuaD4KKyNpbmNsdWRlIDxsaW51 eC9saXN0Lmg+CisjaW5jbHVkZSA8bmV0L2lwX2ZpYi5oPgorCitzdHJ1Y3QgZmliX2FsaWFzIHsK KwlzdHJ1Y3QgbGlzdF9oZWFkCWZhX2xpc3Q7CisJc3RydWN0IGZpYl9pbmZvCQkqZmFfaW5mbzsK Kwl1OAkJCWZhX3RvczsKKwl1OAkJCWZhX3R5cGU7CisJdTgJCQlmYV9zY29wZTsKKwl1OAkJCWZh X3N0YXRlOworfTsKKworI2RlZmluZSBGQV9TX0FDQ0VTU0VECTB4MDEKKworI2VuZGlmIC8qIF9G SUJfTE9PS1VQX0ggKi8K --Multipart=_Tue__28_Sep_2004_21_47_22_-0700_xboskaUt20hTw6lG Content-Type: application/octet-stream; name="diff2" Content-Disposition: attachment; filename="diff2" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMjA6NTk6MDUtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW0lQVjRdOiBNb3ZlIHNvbWUgZmliX3NlbWFudGljcyBleHBvcnRzIGlu dG8gZmliX2xvb2t1cC5oCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8 ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4KIyAKIyBuZXQvaXB2NC9maWJfc2VtYW50aWNzLmMKIyAgIDIw MDQvMDkvMjggMjA6NTg6MzMtMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsyIC0wCiMg ICBbSVBWNF06IE1vdmUgc29tZSBmaWJfc2VtYW50aWNzIGV4cG9ydHMgaW50byBmaWJfbG9va3Vw LmgKIyAKIyBuZXQvaXB2NC9maWJfbG9va3VwLmgKIyAgIDIwMDQvMDkvMjggMjA6NTg6MzMtMDc6 MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsxNCAtMAojICAgW0lQVjRdOiBNb3ZlIHNvbWUg ZmliX3NlbWFudGljcyBleHBvcnRzIGludG8gZmliX2xvb2t1cC5oCiMgCiMgaW5jbHVkZS9uZXQv aXBfZmliLmgKIyAgIDIwMDQvMDkvMjggMjA6NTg6MzMtMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxv ZnQubmV0ICsxIC0xMgojICAgW0lQVjRdOiBNb3ZlIHNvbWUgZmliX3NlbWFudGljcyBleHBvcnRz IGludG8gZmliX2xvb2t1cC5oCiMgCmRpZmYgLU5ydSBhL2luY2x1ZGUvbmV0L2lwX2ZpYi5oIGIv aW5jbHVkZS9uZXQvaXBfZmliLmgKLS0tIGEvaW5jbHVkZS9uZXQvaXBfZmliLmgJMjAwNC0wOS0y OCAyMToyNTowMyAtMDc6MDAKKysrIGIvaW5jbHVkZS9uZXQvaXBfZmliLmgJMjAwNC0wOS0yOCAy MToyNTowMyAtMDc6MDAKQEAgLTIxMCwyMiArMjEwLDExIEBACiBleHRlcm4gdm9pZCBmaWJfc2Vs ZWN0X211bHRpcGF0aChjb25zdCBzdHJ1Y3QgZmxvd2kgKmZscCwgc3RydWN0IGZpYl9yZXN1bHQg KnJlcyk7CiAKIC8qIEV4cG9ydGVkIGJ5IGZpYl9zZW1hbnRpY3MuYyAqLwotZXh0ZXJuIGludCAJ CWlwX2ZpYl9jaGVja19kZWZhdWx0KHUzMiBndywgc3RydWN0IG5ldF9kZXZpY2UgKmRldik7Ci1l eHRlcm4gdm9pZAkJZmliX3JlbGVhc2VfaW5mbyhzdHJ1Y3QgZmliX2luZm8gKik7Ci1leHRlcm4g aW50CQlmaWJfc2VtYW50aWNfbWF0Y2goaW50IHR5cGUsIHN0cnVjdCBmaWJfaW5mbyAqLAotCQkJ CQkgICBjb25zdCBzdHJ1Y3QgZmxvd2kgKiwgc3RydWN0IGZpYl9yZXN1bHQqKTsKLWV4dGVybiBz dHJ1Y3QgZmliX2luZm8JKmZpYl9jcmVhdGVfaW5mbyhjb25zdCBzdHJ1Y3QgcnRtc2cgKnIsIHN0 cnVjdCBrZXJuX3J0YSAqcnRhLAotCQkJCQkgY29uc3Qgc3RydWN0IG5sbXNnaGRyICosIGludCAq ZXJyKTsKLWV4dGVybiBpbnQgZmliX25oX21hdGNoKHN0cnVjdCBydG1zZyAqciwgc3RydWN0IG5s bXNnaGRyICosIHN0cnVjdCBrZXJuX3J0YSAqcnRhLCBzdHJ1Y3QgZmliX2luZm8gKmZpKTsKLWV4 dGVybiBpbnQgZmliX2R1bXBfaW5mbyhzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCB1MzIgcGlkLCB1MzIg c2VxLCBpbnQgZXZlbnQsCi0JCQkgdTggdGJfaWQsIHU4IHR5cGUsIHU4IHNjb3BlLCB2b2lkICpk c3QsIGludCBkc3RfbGVuLCB1OCB0b3MsCi0JCQkgc3RydWN0IGZpYl9pbmZvICpmaSk7CitleHRl cm4gaW50IGlwX2ZpYl9jaGVja19kZWZhdWx0KHUzMiBndywgc3RydWN0IG5ldF9kZXZpY2UgKmRl dik7CiBleHRlcm4gaW50IGZpYl9zeW5jX2Rvd24odTMyIGxvY2FsLCBzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBpbnQgZm9yY2UpOwogZXh0ZXJuIGludCBmaWJfc3luY191cChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KTsKIGV4dGVybiBpbnQgZmliX2NvbnZlcnRfcnRlbnRyeShpbnQgY21kLCBzdHJ1 Y3Qgbmxtc2doZHIgKm5sLCBzdHJ1Y3QgcnRtc2cgKnJ0bSwKIAkJCSAgICAgICBzdHJ1Y3Qga2Vy bl9ydGEgKnJ0YSwgc3RydWN0IHJ0ZW50cnkgKnIpOwotZXh0ZXJuIHZvaWQgZmliX25vZGVfc2Vx X3Nob3coc3RydWN0IHNlcV9maWxlICpzZXEsIGludCB0eXBlLCBpbnQgZGVhZCwKLQkJCSAgICAg IHN0cnVjdCBmaWJfaW5mbyAqZmksIHUzMiBwcmVmaXgsIHUzMiBtYXNrKTsKIGV4dGVybiB1MzIg IF9fZmliX3Jlc19wcmVmc3JjKHN0cnVjdCBmaWJfcmVzdWx0ICpyZXMpOwogCiAvKiBFeHBvcnRl ZCBieSBmaWJfaGFzaC5jICovCmRpZmYgLU5ydSBhL25ldC9pcHY0L2ZpYl9sb29rdXAuaCBiL25l dC9pcHY0L2ZpYl9sb29rdXAuaAotLS0gYS9uZXQvaXB2NC9maWJfbG9va3VwLmgJMjAwNC0wOS0y OCAyMToyNTowMyAtMDc6MDAKKysrIGIvbmV0L2lwdjQvZmliX2xvb2t1cC5oCTIwMDQtMDktMjgg MjE6MjU6MDMgLTA3OjAwCkBAIC0xNiw0ICsxNiwxOCBAQAogCiAjZGVmaW5lIEZBX1NfQUNDRVNT RUQJMHgwMQogCisvKiBFeHBvcnRlZCBieSBmaWJfc2VtYW50aWNzLmMgKi8KK2V4dGVybiBpbnQg ZmliX3NlbWFudGljX21hdGNoKGludCB0eXBlLCBzdHJ1Y3QgZmliX2luZm8gKiwKKwkJCSAgICAg IGNvbnN0IHN0cnVjdCBmbG93aSAqLCBzdHJ1Y3QgZmliX3Jlc3VsdCAqKTsKK2V4dGVybiB2b2lk IGZpYl9yZWxlYXNlX2luZm8oc3RydWN0IGZpYl9pbmZvICopOworZXh0ZXJuIHN0cnVjdCBmaWJf aW5mbyAqZmliX2NyZWF0ZV9pbmZvKGNvbnN0IHN0cnVjdCBydG1zZyAqciwKKwkJCQkJc3RydWN0 IGtlcm5fcnRhICpydGEsCisJCQkJCWNvbnN0IHN0cnVjdCBubG1zZ2hkciAqLAorCQkJCQlpbnQg KmVycik7CitleHRlcm4gaW50IGZpYl9uaF9tYXRjaChzdHJ1Y3QgcnRtc2cgKnIsIHN0cnVjdCBu bG1zZ2hkciAqLAorCQkJc3RydWN0IGtlcm5fcnRhICpydGEsIHN0cnVjdCBmaWJfaW5mbyAqZmkp OworZXh0ZXJuIGludCBmaWJfZHVtcF9pbmZvKHN0cnVjdCBza19idWZmICpza2IsIHUzMiBwaWQs IHUzMiBzZXEsIGludCBldmVudCwKKwkJCSB1OCB0Yl9pZCwgdTggdHlwZSwgdTggc2NvcGUsIHZv aWQgKmRzdCwKKwkJCSBpbnQgZHN0X2xlbiwgdTggdG9zLCBzdHJ1Y3QgZmliX2luZm8gKmZpKTsK KwogI2VuZGlmIC8qIF9GSUJfTE9PS1VQX0ggKi8KZGlmZiAtTnJ1IGEvbmV0L2lwdjQvZmliX3Nl bWFudGljcy5jIGIvbmV0L2lwdjQvZmliX3NlbWFudGljcy5jCi0tLSBhL25ldC9pcHY0L2ZpYl9z ZW1hbnRpY3MuYwkyMDA0LTA5LTI4IDIxOjI1OjAzIC0wNzowMAorKysgYi9uZXQvaXB2NC9maWJf c2VtYW50aWNzLmMJMjAwNC0wOS0yOCAyMToyNTowMyAtMDc6MDAKQEAgLTQzLDYgKzQzLDggQEAK ICNpbmNsdWRlIDxuZXQvc29jay5oPgogI2luY2x1ZGUgPG5ldC9pcF9maWIuaD4KIAorI2luY2x1 ZGUgImZpYl9sb29rdXAuaCIKKwogI2RlZmluZSBGU3ByaW50ayhhLi4uKQogCiBzdGF0aWMgcnds b2NrX3QgZmliX2luZm9fbG9jayA9IFJXX0xPQ0tfVU5MT0NLRUQ7Cg== --Multipart=_Tue__28_Sep_2004_21_47_22_-0700_xboskaUt20hTw6lG Content-Type: application/octet-stream; name="diff3" Content-Disposition: attachment; filename="diff3" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjggMjE6MjM6NDAtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW0lQVjRdOiBEbyBmaWJfYWxpYXMgbG9va3VwIHdhbGsgZGlyZWN0bHkg aW4gZmliX3NlbWFudGljX21hdGNoKCkuCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMu IE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4KIyAKIyBuZXQvaXB2NC9maWJfc2VtYW50aWNz LmMKIyAgIDIwMDQvMDkvMjggMjE6MjM6MDctMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0 ICs2MCAtMzgKIyAgIFtJUFY0XTogRG8gZmliX2FsaWFzIGxvb2t1cCB3YWxrIGRpcmVjdGx5IGlu IGZpYl9zZW1hbnRpY19tYXRjaCgpLgojIAojIG5ldC9pcHY0L2ZpYl9sb29rdXAuaAojICAgMjAw NC8wOS8yOCAyMToyMzowNy0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzMgLTIKIyAg IFtJUFY0XTogRG8gZmliX2FsaWFzIGxvb2t1cCB3YWxrIGRpcmVjdGx5IGluIGZpYl9zZW1hbnRp Y19tYXRjaCgpLgojIAojIG5ldC9pcHY0L2ZpYl9oYXNoLmMKIyAgIDIwMDQvMDkvMjggMjE6MjM6 MDctMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICs1IC0yMwojICAgW0lQVjRdOiBEbyBm aWJfYWxpYXMgbG9va3VwIHdhbGsgZGlyZWN0bHkgaW4gZmliX3NlbWFudGljX21hdGNoKCkuCiMg CmRpZmYgLU5ydSBhL25ldC9pcHY0L2ZpYl9oYXNoLmMgYi9uZXQvaXB2NC9maWJfaGFzaC5jCi0t LSBhL25ldC9pcHY0L2ZpYl9oYXNoLmMJMjAwNC0wOS0yOCAyMToyNToyMCAtMDc6MDAKKysrIGIv bmV0L2lwdjQvZmliX2hhc2guYwkyMDA0LTA5LTI4IDIxOjI1OjIwIC0wNzowMApAQCAtMjU2LDMy ICsyNTYsMTQgQEAKIAogCQloZWFkID0gJmZ6LT5mel9oYXNoW2ZuX2hhc2goaywgZnopXTsKIAkJ aGxpc3RfZm9yX2VhY2hfZW50cnkoZiwgbm9kZSwgaGVhZCwgZm5faGFzaCkgewotCQkJc3RydWN0 IGZpYl9hbGlhcyAqZmE7Ci0KIAkJCWlmIChmLT5mbl9rZXkgIT0gaykKIAkJCQljb250aW51ZTsK IAotCQkJbGlzdF9mb3JfZWFjaF9lbnRyeShmYSwgJmYtPmZuX2FsaWFzLCBmYV9saXN0KSB7Ci0J CQkJaWYgKGZhLT5mYV90b3MgJiYKLQkJCQkgICAgZmEtPmZhX3RvcyAhPSBmbHAtPmZsNF90b3Mp Ci0JCQkJCWNvbnRpbnVlOwotCQkJCWlmIChmYS0+ZmFfc2NvcGUgPCBmbHAtPmZsNF9zY29wZSkK LQkJCQkJY29udGludWU7Ci0KLQkJCQlmYS0+ZmFfc3RhdGUgfD0gRkFfU19BQ0NFU1NFRDsKLQot CQkJCWVyciA9IGZpYl9zZW1hbnRpY19tYXRjaChmYS0+ZmFfdHlwZSwKLQkJCQkJCQkgZmEtPmZh X2luZm8sCi0JCQkJCQkJIGZscCwgcmVzKTsKLQkJCQlpZiAoZXJyID09IDApIHsKLQkJCQkJcmVz LT50eXBlID0gZmEtPmZhX3R5cGU7Ci0JCQkJCXJlcy0+c2NvcGUgPSBmYS0+ZmFfc2NvcGU7Ci0J CQkJCXJlcy0+cHJlZml4bGVuID0gZnotPmZ6X29yZGVyOwotCQkJCQlnb3RvIG91dDsKLQkJCQl9 Ci0JCQkJaWYgKGVyciA8IDApCi0JCQkJCWdvdG8gb3V0OwotCQkJfQorCQkJZXJyID0gZmliX3Nl bWFudGljX21hdGNoKCZmLT5mbl9hbGlhcywKKwkJCQkJCSBmbHAsIHJlcywKKwkJCQkJCSBmei0+ Znpfb3JkZXIpOworCQkJaWYgKGVyciA8PSAwKQorCQkJCWdvdG8gb3V0OwogCQl9CiAJfQogCWVy ciA9IDE7CmRpZmYgLU5ydSBhL25ldC9pcHY0L2ZpYl9sb29rdXAuaCBiL25ldC9pcHY0L2ZpYl9s b29rdXAuaAotLS0gYS9uZXQvaXB2NC9maWJfbG9va3VwLmgJMjAwNC0wOS0yOCAyMToyNToyMCAt MDc6MDAKKysrIGIvbmV0L2lwdjQvZmliX2xvb2t1cC5oCTIwMDQtMDktMjggMjE6MjU6MjAgLTA3 OjAwCkBAIC0xNyw4ICsxNyw5IEBACiAjZGVmaW5lIEZBX1NfQUNDRVNTRUQJMHgwMQogCiAvKiBF eHBvcnRlZCBieSBmaWJfc2VtYW50aWNzLmMgKi8KLWV4dGVybiBpbnQgZmliX3NlbWFudGljX21h dGNoKGludCB0eXBlLCBzdHJ1Y3QgZmliX2luZm8gKiwKLQkJCSAgICAgIGNvbnN0IHN0cnVjdCBm bG93aSAqLCBzdHJ1Y3QgZmliX3Jlc3VsdCAqKTsKK2V4dGVybiBpbnQgZmliX3NlbWFudGljX21h dGNoKHN0cnVjdCBsaXN0X2hlYWQgKmhlYWQsCisJCQkgICAgICBjb25zdCBzdHJ1Y3QgZmxvd2kg KmZscCwKKwkJCSAgICAgIHN0cnVjdCBmaWJfcmVzdWx0ICpyZXMsIGludCBwcmVmaXhsZW4pOwog ZXh0ZXJuIHZvaWQgZmliX3JlbGVhc2VfaW5mbyhzdHJ1Y3QgZmliX2luZm8gKik7CiBleHRlcm4g c3RydWN0IGZpYl9pbmZvICpmaWJfY3JlYXRlX2luZm8oY29uc3Qgc3RydWN0IHJ0bXNnICpyLAog CQkJCQlzdHJ1Y3Qga2Vybl9ydGEgKnJ0YSwKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvZmliX3NlbWFu dGljcy5jIGIvbmV0L2lwdjQvZmliX3NlbWFudGljcy5jCi0tLSBhL25ldC9pcHY0L2ZpYl9zZW1h bnRpY3MuYwkyMDA0LTA5LTI4IDIxOjI1OjIwIC0wNzowMAorKysgYi9uZXQvaXB2NC9maWJfc2Vt YW50aWNzLmMJMjAwNC0wOS0yOCAyMToyNToyMCAtMDc6MDAKQEAgLTc2MCw1MSArNzYwLDczIEBA CiAJcmV0dXJuIE5VTEw7CiB9CiAKLWludCAKLWZpYl9zZW1hbnRpY19tYXRjaChpbnQgdHlwZSwg c3RydWN0IGZpYl9pbmZvICpmaSwgY29uc3Qgc3RydWN0IGZsb3dpICpmbHAsIHN0cnVjdCBmaWJf cmVzdWx0ICpyZXMpCitpbnQgZmliX3NlbWFudGljX21hdGNoKHN0cnVjdCBsaXN0X2hlYWQgKmhl YWQsIGNvbnN0IHN0cnVjdCBmbG93aSAqZmxwLAorCQkgICAgICAgc3RydWN0IGZpYl9yZXN1bHQg KnJlcywgaW50IHByZWZpeGxlbikKIHsKLQlpbnQgZXJyID0gZmliX3Byb3BzW3R5cGVdLmVycm9y OworCXN0cnVjdCBmaWJfYWxpYXMgKmZhOworCWludCBuaF9zZWwgPSAwOwogCi0JaWYgKGVyciA9 PSAwKSB7Ci0JCWlmIChmaS0+ZmliX2ZsYWdzJlJUTkhfRl9ERUFEKQotCQkJcmV0dXJuIDE7Ci0K LQkJcmVzLT5maSA9IGZpOwotCi0JCXN3aXRjaCAodHlwZSkgewotCQljYXNlIFJUTl9VTklDQVNU OgotCQljYXNlIFJUTl9MT0NBTDoKLQkJY2FzZSBSVE5fQlJPQURDQVNUOgotCQljYXNlIFJUTl9B TllDQVNUOgotCQljYXNlIFJUTl9NVUxUSUNBU1Q6Ci0JCQlmb3JfbmV4dGhvcHMoZmkpIHsKLQkJ CQlpZiAobmgtPm5oX2ZsYWdzJlJUTkhfRl9ERUFEKQotCQkJCQljb250aW51ZTsKLQkJCQlpZiAo IWZscC0+b2lmIHx8IGZscC0+b2lmID09IG5oLT5uaF9vaWYpCi0JCQkJCWJyZWFrOwotCQkJfQor CWxpc3RfZm9yX2VhY2hfZW50cnkoZmEsIGhlYWQsIGZhX2xpc3QpIHsKKwkJaW50IGVycjsKKwor CQlpZiAoZmEtPmZhX3RvcyAmJgorCQkgICAgZmEtPmZhX3RvcyAhPSBmbHAtPmZsNF90b3MpCisJ CQljb250aW51ZTsKKworCQlpZiAoZmEtPmZhX3Njb3BlIDwgZmxwLT5mbDRfc2NvcGUpCisJCQlj b250aW51ZTsKKworCQlmYS0+ZmFfc3RhdGUgfD0gRkFfU19BQ0NFU1NFRDsKKworCQllcnIgPSBm aWJfcHJvcHNbZmEtPmZhX3R5cGVdLmVycm9yOworCQlpZiAoZXJyID09IDApIHsKKwkJCXN0cnVj dCBmaWJfaW5mbyAqZmkgPSBmYS0+ZmFfaW5mbzsKKworCQkJaWYgKGZpLT5maWJfZmxhZ3MgJiBS VE5IX0ZfREVBRCkKKwkJCQljb250aW51ZTsKKworCQkJc3dpdGNoIChmYS0+ZmFfdHlwZSkgewor CQkJY2FzZSBSVE5fVU5JQ0FTVDoKKwkJCWNhc2UgUlROX0xPQ0FMOgorCQkJY2FzZSBSVE5fQlJP QURDQVNUOgorCQkJY2FzZSBSVE5fQU5ZQ0FTVDoKKwkJCWNhc2UgUlROX01VTFRJQ0FTVDoKKwkJ CQlmb3JfbmV4dGhvcHMoZmkpIHsKKwkJCQkJaWYgKG5oLT5uaF9mbGFncyZSVE5IX0ZfREVBRCkK KwkJCQkJCWNvbnRpbnVlOworCQkJCQlpZiAoIWZscC0+b2lmIHx8IGZscC0+b2lmID09IG5oLT5u aF9vaWYpCisJCQkJCQlicmVhazsKKwkJCQl9CiAjaWZkZWYgQ09ORklHX0lQX1JPVVRFX01VTFRJ UEFUSAotCQkJaWYgKG5oc2VsIDwgZmktPmZpYl9uaHMpIHsKLQkJCQlyZXMtPm5oX3NlbCA9IG5o c2VsOwotCQkJCWF0b21pY19pbmMoJmZpLT5maWJfY2xudHJlZik7Ci0JCQkJcmV0dXJuIDA7Ci0J CQl9CisJCQkJaWYgKG5oc2VsIDwgZmktPmZpYl9uaHMpIHsKKwkJCQkJbmhfc2VsID0gbmhzZWw7 CisJCQkJCWdvdG8gb3V0X2ZpbGxfcmVzOworCQkJCX0KICNlbHNlCi0JCQlpZiAobmhzZWwgPCAx KSB7Ci0JCQkJYXRvbWljX2luYygmZmktPmZpYl9jbG50cmVmKTsKLQkJCQlyZXR1cm4gMDsKLQkJ CX0KKwkJCQlpZiAobmhzZWwgPCAxKSB7CisJCQkJCWdvdG8gb3V0X2ZpbGxfcmVzOworCQkJCX0K ICNlbmRpZgotCQkJZW5kZm9yX25leHRob3BzKGZpKTsKLQkJCXJlcy0+ZmkgPSBOVUxMOwotCQkJ cmV0dXJuIDE7Ci0JCWRlZmF1bHQ6Ci0JCQlyZXMtPmZpID0gTlVMTDsKLQkJCXByaW50ayhLRVJO X0RFQlVHICJpbXBvc3NpYmxlIDEwMlxuIik7Ci0JCQlyZXR1cm4gLUVJTlZBTDsKKwkJCQllbmRm b3JfbmV4dGhvcHMoZmkpOworCQkJCWNvbnRpbnVlOworCisJCQlkZWZhdWx0OgorCQkJCXByaW50 ayhLRVJOX0RFQlVHICJpbXBvc3NpYmxlIDEwMlxuIik7CisJCQkJcmV0dXJuIC1FSU5WQUw7CisJ CQl9OwogCQl9CisJCXJldHVybiBlcnI7CiAJfQotCXJldHVybiBlcnI7CisJcmV0dXJuIDE7CisK K291dF9maWxsX3JlczoKKwlyZXMtPnByZWZpeGxlbiA9IHByZWZpeGxlbjsKKwlyZXMtPm5oX3Nl bCA9IG5oX3NlbDsKKwlyZXMtPnR5cGUgPSBmYS0+ZmFfdHlwZTsKKwlyZXMtPnNjb3BlID0gZmEt PmZhX3Njb3BlOworCXJlcy0+ZmkgPSBmYS0+ZmFfaW5mbzsKKwlhdG9taWNfaW5jKCZyZXMtPmZp LT5maWJfY2xudHJlZik7CisJcmV0dXJuIDA7CiB9CiAKIC8qIEZpbmQgYXBwcm9wcmlhdGUgc291 cmNlIGFkZHJlc3MgdG8gdGhpcyBkZXN0aW5hdGlvbiAqLwo= --Multipart=_Tue__28_Sep_2004_21_47_22_-0700_xboskaUt20hTw6lG-- From jgarzik@pobox.com Tue Sep 28 21:58:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 21:58:25 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T4wHFk023351 for ; Tue, 28 Sep 2004 21:58:17 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCWXU-0001rf-RS; Wed, 29 Sep 2004 05:58:05 +0100 Message-ID: <415A40D0.7040403@pobox.com> Date: Wed, 29 Sep 2004 00:57:52 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com Subject: Re: Tons of "BUG: dst overflow ..." messages References: <415A3635.4070000@pobox.com> <20040928214055.609f7715.davem@davemloft.net> In-Reply-To: <20040928214055.609f7715.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1612 Lines: 48 David S. Miller wrote: > On Wed, 29 Sep 2004 00:12:37 -0400 > Jeff Garzik wrote: > > >>BUG: dst underflow 0: cf5dd180 at f8c0be5d >>BUG: dst underflow 0: cf5dd180 at f8c0d15c >>BUG: dst underflow 0: cf5dd180 at f8c1656f > > > Can you match up the 0xf8xxxxxx addresses to spots > in your System.map? Thanks. All my addresses in System.map start with 0xc0xxxxxx. But /proc/modules OTOH... nfsd 212256 9 - Live 0xf8c96000 exportfs 5248 1 nfsd, Live 0xf8bcb000 e1000 80132 0 - Live 0xf8be3000 8139too 21504 0 - Live 0xf8bc4000 crc32 4480 1 8139too, Live 0xf8b68000 ipv6 232192 38 - Live 0xf8c01000 ^^^^ appears to be this ip_nat_irc 4080 0 - Live 0xf8839000 ip_conntrack_irc 70960 1 ip_nat_irc, Live 0xf8ba9000 ip_nat_ftp 4592 0 - Live 0xf8b47000 ip_conntrack_ftp 71856 1 ip_nat_ftp, Live 0xf8b96000 ipt_MASQUERADE 3584 1 - Live 0xf8b66000 iptable_nat 20644 4 ip_nat_irc,ip_nat_ftp,ipt_MASQUERADE, Live 0xf8b6e000 iptable_mangle 2688 0 - Live 0xf8830000 ipt_LOG 6656 1 - Live 0xf8b41000 ipt_limit 2432 1 - Live 0xf883d000 ipt_state 2048 3 - Live 0xf883b000 ip_conntrack 38200 7 ip_nat_irc,ip_conntrack_irc,ip_nat_ftp,ip_conntrack_ftp,ipt_MASQUERADE,iptable_nat,ipt_state, Live 0xf8b4a000 iptable_filter 2688 1 - Live 0xf8810000 ip_tables 16256 7 ipt_MASQUERADE,iptable_nat,iptable_mangle,ipt_LOG,ipt_limit,ipt_state,iptable_filter, Live 0xf8827000 dm_mod 48896 0 - Live 0xf8840000 battery 10252 0 - Live 0xf882c000 raid1 13824 2 - Live 0xf8815000 ata_piix 7044 5 - Live 0xf8824000 sata_promise 7556 2 - Live 0xf8812000 libata 36612 2 ata_piix,sata_promise, Live 0xf881a000 From yoshfuji@linux-ipv6.org Tue Sep 28 22:32:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 22:32:15 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T5WAbj024340 for ; Tue, 28 Sep 2004 22:32:10 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 0FFD833CE5; Wed, 29 Sep 2004 14:32:17 +0900 (JST) Date: Wed, 29 Sep 2004 14:32:16 +0900 (JST) Message-Id: <20040929.143216.55773467.yoshfuji@linux-ipv6.org> To: jgarzik@pobox.com Cc: davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Tons of "BUG: dst overflow ..." messages From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <415A40D0.7040403@pobox.com> References: <415A3635.4070000@pobox.com> <20040928214055.609f7715.davem@davemloft.net> <415A40D0.7040403@pobox.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 613 Lines: 22 In article <415A40D0.7040403@pobox.com> (at Wed, 29 Sep 2004 00:57:52 -0400), Jeff Garzik says: > David S. Miller wrote: > > On Wed, 29 Sep 2004 00:12:37 -0400 > > Jeff Garzik wrote: > > > > > >>BUG: dst underflow 0: cf5dd180 at f8c0be5d : > > Can you match up the 0xf8xxxxxx addresses to spots > > in your System.map? Thanks. : > ipv6 232192 38 - Live 0xf8c01000 > ^^^^ appears to be this Hmm, I haven't met this (during TAHI test against latest tree). Would you try latest bk tree? Plus, if you know how to reproduce this, tell me. Thank you. --yoshfuji From cat@zip.com.au Tue Sep 28 22:51:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 28 Sep 2004 22:51:22 -0700 (PDT) Received: from theirongiant.lochness.weebeastie.net (sol.linkinnovations.com [203.94.173.142]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T5pHNp025011 for ; Tue, 28 Sep 2004 22:51:18 -0700 Received: from theirongiant.lochness.weebeastie.net (localhost.localdomain [127.0.0.1]) by theirongiant.lochness.weebeastie.net (8.13.1/8.13.1/Debian-13) with ESMTP id i8T5oiU7026436; Wed, 29 Sep 2004 15:50:44 +1000 Received: (from hogarth@localhost) by theirongiant.lochness.weebeastie.net (8.13.1/8.13.1/Debian-13) id i8T5obrt026435; Wed, 29 Sep 2004 15:50:37 +1000 X-Authentication-Warning: theirongiant.lochness.weebeastie.net: hogarth set sender to cat@zip.com.au using -f Date: Wed, 29 Sep 2004 15:50:37 +1000 From: CaT To: "David S. Miller" Cc: acme@conectiva.com.br, linux-kernel@vger.kernel.org, jgarzik@pobox.com, linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: strange network slowness in 2.6 unless pingflooding Message-ID: <20040929055036.GA25016@zip.com.au> References: <20040927090342.GA1794@zip.com.au> <41587A26.6020606@conectiva.com.br> <20040927224957.GA1043@zip.com.au> <20040927161845.1442bb4a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927161845.1442bb4a.davem@davemloft.net> Organisation: Furball Inc. User-Agent: Mutt/1.5.6+20040722i X-archive-position: 9657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cat@zip.com.au Precedence: bulk X-list: netdev Content-Length: 855 Lines: 22 On Mon, Sep 27, 2004 at 04:18:45PM -0700, David S. Miller wrote: > In particular, if there are hubs or switches involved on > your local network that might be getting the duplex wrong, > or some NAT or firewall machines in the path in question, > please specify their setup precisely. > > Otherwise there is zero chance of this problem ever being > fixes. Well I was going to do a few more tests and send a nice email doing just that but in going through my package list with dpkg I spotted cpudyn and cpufreqd installed. I've uninstalled them and now I cannot reproduce the problem. As such, and I hope I'm not speaking to you, it appears 'solved'. They must've been interfering with the network layer somehow (or something) and now that they are gone all's well. My apologies if anyones time was wasted. -- Red herrings strewn hither and yon. From vkondra@mail.ru Wed Sep 29 00:11:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 00:11:32 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T7BPcc027741 for ; Wed, 29 Sep 2004 00:11:26 -0700 Received: from [81.218.92.214] (port=29922 helo=[192.168.10.2]) by mx1.mail.ru with esmtp id 1CCYc4-000C1p-00; Wed, 29 Sep 2004 11:10:58 +0400 From: Vladimir Kondratiev To: "Luis R. Rodriguez" Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Date: Wed, 29 Sep 2004 09:10:08 +0200 User-Agent: KMail/1.7 Cc: "Luis R. Rodriguez" , greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409282229.53349.vkondra@mail.ru> <20040929004808.GN30131@ruslug.rutgers.edu> In-Reply-To: <20040929004808.GN30131@ruslug.rutgers.edu> MIME-Version: 1.0 Message-Id: <200409290910.13201.vkondra@mail.ru> Content-Type: multipart/signed; boundary="nextPart1664376.XdjzlfJnxg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-archive-position: 9658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vkondra@mail.ru Precedence: bulk X-list: netdev Content-Length: 2784 Lines: 72 --nextPart1664376.XdjzlfJnxg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote: LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote: LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote: LR> > LR> RFC: what are the chances we can implement our own generic "softmac" that may LR> > LR> be usable by the different chipsets out there? LR> > LR> > Coming days, I will submit "framework" consisting of stack based on Dave's LR> > code and debug driver which will be able to imitate Rx. I have working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces stack-driver and LR> > stack-upper layers. It would be great if someone wi= ll do MAC algorithms. I'll LR> > appreciate this for sure. LR> LR> But would it be possible? Would it work, if we write our own softmac LR> interface? Or are softmac interaces/libraries strictly dependent on a LR> chipset being used? LR> LR> Luis LR> In idea yes, 802.11 stack should serve any low level driver provided it can= =20 Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The=20 difference is, 802.11 stack is not written yet, we need to make sure we do = it=20 in smart way and with reasonable assumptions about what low level driver ca= n=20 do. Thus far, I assume, low level driver (and NIC, of course) can: =2DTx/Rx arbitrary data and management packets. Control frames generated by= NIC. =2DNIC can perform scanning and report beacons or probe resp. to the stack. =2DNIC can report some basic PHY data per packet: rate, RSSI, maybe somethi= ng=20 else. =2DNIC accept some basic PHY data per packet on Tx: rate, retry count,=20 protection, maybe Tx power and some others =2DNIC can do crypto transformations on both Tx and Rx. For this, crypto ke= y=20 need be provided per packet for Tx and some ,mechanism to provide key for=20 each peer need to be established for Rx. =2DNIC may choose to not do fragmentation/reassembly, stack will handle it. =2DNIC may have many Tx queues for QoS, it will be able to start/stop each = one. To not raise unsupported expectations: 802.11 stack is only skeleton for no= w.=20 I will do interface parts first. For actual algorithms to handle management= s=20 flows, help required. But, I believe it is wise to write these algorithms=20 once for this stack rather to implement whole stack with each driver. Vladimir. --nextPart1664376.XdjzlfJnxg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBWl/Vqxdj7mhC6o0RAsdcAJ0Xh/rMiTIkCJTmT0j5N6zDzorbBwCeIMdp MHSGANCTe8mnVhSrzgAJaFY= =cRqX -----END PGP SIGNATURE----- --nextPart1664376.XdjzlfJnxg-- From mcgrof@studorgs.rutgers.edu Wed Sep 29 01:00:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 01:00:29 -0700 (PDT) Received: from ruslug.rutgers.edu (studorgs.rutgers.edu [128.6.24.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T80NJh031988 for ; Wed, 29 Sep 2004 01:00:24 -0700 Received: by ruslug.rutgers.edu (Postfix, from userid 503) id 8B298F99BD; Wed, 29 Sep 2004 04:00:11 -0400 (EDT) Date: Wed, 29 Sep 2004 04:00:11 -0400 To: Vladimir Kondratiev Cc: "Luis R. Rodriguez" , greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack Message-ID: <20040929080011.GO30131@ruslug.rutgers.edu> Mail-Followup-To: Vladimir Kondratiev , "Luis R. Rodriguez" , greg chesson , netdev@oss.sgi.com, "David S. Miller" , acx100-devel@lists.sourceforge.net, hadi@cyberus.ca, jgarzik@pobox.com, jkmaline@cc.hut.fi, prism54-devel@prism54.org References: <200408312111.02438.vda@port.imtp.ilyichevsk.odessa.ua> <200409282229.53349.vkondra@mail.ru> <20040929004808.GN30131@ruslug.rutgers.edu> <200409290910.13201.vkondra@mail.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p6hDAtPN9q+ZnUca" Content-Disposition: inline In-Reply-To: <200409290910.13201.vkondra@mail.ru> User-Agent: Mutt/1.3.28i X-Operating-System: 2.4.18-1-686 Organization: Rutgers University Student Linux Users Group From: mcgrof@studorgs.rutgers.edu (Luis R. Rodriguez) X-archive-position: 9659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcgrof@studorgs.rutgers.edu Precedence: bulk X-list: netdev Content-Length: 3315 Lines: 88 --p6hDAtPN9q+ZnUca Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 29, 2004 at 09:10:08AM +0200, Vladimir Kondratiev wrote: > On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote: > LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote: > LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote: > LR> > LR> RFC: what are the chances we can implement our own generic > "softmac" that may LR> > LR> be usable by the different chipsets out the= re? > LR> > > LR> > Coming days, I will submit "framework" consisting of stack based on > Dave's LR> > code and debug driver which will be able to imitate Rx. I h= ave > working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces > stack-driver and LR> > stack-upper layers. It would be great if someone = will > do MAC algorithms. I'll LR> > appreciate this for sure. > LR> > LR> But would it be possible? Would it work, if we write our own softmac > LR> interface? Or are softmac interaces/libraries strictly dependent on a > LR> chipset being used? > LR> > LR> Luis > LR> > In idea yes, 802.11 stack should serve any low level driver provided it c= an=20 > Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The= =20 > difference is, 802.11 stack is not written yet, we need to make sure we d= o it=20 > in smart way and with reasonable assumptions about what low level driver = can=20 > do. >=20 > Thus far, I assume, low level driver (and NIC, of course) can: > -Tx/Rx arbitrary data and management packets. Control frames generated by= NIC. > -NIC can perform scanning and report beacons or probe resp. to the stack. > -NIC can report some basic PHY data per packet: rate, RSSI, maybe somethi= ng=20 > else. > -NIC accept some basic PHY data per packet on Tx: rate, retry count,=20 > protection, maybe Tx power and some others > -NIC can do crypto transformations on both Tx and Rx. For this, crypto ke= y=20 > need be provided per packet for Tx and some ,mechanism to provide key for= =20 > each peer need to be established for Rx. > -NIC may choose to not do fragmentation/reassembly, stack will handle it. > -NIC may have many Tx queues for QoS, it will be able to start/stop each = one. >=20 > To not raise unsupported expectations: 802.11 stack is only skeleton for = now.=20 > I will do interface parts first. For actual algorithms to handle manageme= nts=20 > flows, help required. But, I believe it is wise to write these algorithms= =20 > once for this stack rather to implement whole stack with each driver. OK great, then I'll try working Conexant to push for this as our goal for a softmac driver for linux. Currently they use their own libraries (not even a separate module, as atheros with its HAL). This is unacceptable for kernel inclusion and that simply just sucks. Hopefully this will be possible :) Luis --=20 GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E --p6hDAtPN9q+ZnUca Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWmuLat1JN+IKUl4RAvCDAJ9x7VrJ0vwo7MtnsVsrOkdT5dlHNQCgsTjI JqV/phopJHvpk9mc7nJcCjk= =Cgbr -----END PGP SIGNATURE----- --p6hDAtPN9q+ZnUca-- From buytenh@wantstofly.org Wed Sep 29 01:03:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 01:03:35 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T83TSK032425 for ; Wed, 29 Sep 2004 01:03:29 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id C7B722B0EE; Wed, 29 Sep 2004 10:03:16 +0200 (MEST) Date: Wed, 29 Sep 2004 10:03:16 +0200 From: Lennert Buytenhek To: Jeff Garzik Cc: Netdev Subject: Re: Tons of "BUG: dst overflow ..." messages Message-ID: <20040929080316.GA19331@xi.wantstofly.org> References: <415A3635.4070000@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415A3635.4070000@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 9660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 868 Lines: 26 On Wed, Sep 29, 2004 at 12:12:37AM -0400, Jeff Garzik wrote: > Just logged into my router, which is running 2.6.9-rc2-bk1 (or -bk2, not > sure), and saw a buttload of the following messages: I've been seeing this too for a week or two on 2.6.8-1.521smp, which is some kind of Red Hat bastardized version of 2.6.8 that comes with Fedora Core 2. BUG: dst underflow 0: 3bcf9a80 at 42350024 ipt_state 5569 1 - Live 0x4231e000 iptable_mangle 6209 0 - Live 0x42321000 mii 7617 2 usbnet,e100, Live 0x42324000 ip_conntrack 30929 3 ipt_MASQUERADE,iptable_nat,ipt_state, Live 0x42329000 ipv6 233701 50 - Live 0x42345000 <==== ipt_mark 5441 1 - Live 0x423f9000 ipt_MASQUERADE 6849 1 - Live 0x423fc000 e100 33861 0 - Live 0x423ff000 I'm running 6to4 on this machine, but not using it as a router. Any easy way to find out which symbol in ipv6.ko this address is in? --L From laforge@gnumonks.org Wed Sep 29 01:04:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 01:04:44 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T84dB9032751 for ; Wed, 29 Sep 2004 01:04:40 -0700 Received: from dsl-213-023-153-112.arcor-ip.net ([213.23.153.112] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CCZRq-0003CC-DM; Wed, 29 Sep 2004 10:04:26 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CCZRo-0000DU-5C; Wed, 29 Sep 2004 10:04:24 +0200 Date: Wed, 29 Sep 2004 10:04:24 +0200 From: Harald Welte To: "David S. Miller" Cc: Robert.Olsson@data.slu.se, shemminger@osdl.org, herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH 2.6] generic network statistics (was Re: [6/6]: jenkins hash for neigh / Statistics) Message-ID: <20040929080424.GE31674@sunbeam.de.gnumonks.org> References: <20040925005623.2faf8faf.davem@davemloft.net> <20040927121403.767e2308.davem@davemloft.net> <20040927222613.GE3236@sunbeam.de.gnumonks.org> <20040927160636.7741d973.davem@davemloft.net> <1096327658.1729.19.camel@localhost.localdomain> <16729.9326.93269.422940@robur.slu.se> <20040928111906.GB29961@sunbeam.de.gnumonks.org> <20040928144356.371ef3d4.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: <20040928144356.371ef3d4.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 1282 Lines: 42 --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2004 at 02:43:56PM -0700, David S. Miller wrote: > I like this patch a lot and have applied it. thanks :) > Harald, we've created a lot of churn over the past week or > two. Can I expect a set of 2.4.x patches for all the neigh > stuff and this generic statistics thing sometime soon? Yes, I'll be working on this today or tomorrow, so you can expect a patch soon. --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBWmyIXaXGVTD0i/8RAoqOAJ4oRQDUOmgxFDERiJhDPvWZa0deTgCgquEV BIbrXjtUwx4St9r0H9vMZ+0= =Qvb9 -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- From ak@suse.de Wed Sep 29 02:01:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 02:01:27 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T91Lcs001625 for ; Wed, 29 Sep 2004 02:01:22 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0A152C97662; Wed, 29 Sep 2004 11:01:04 +0200 (CEST) Date: Wed, 29 Sep 2004 11:01:03 +0200 From: Andi Kleen To: John Heffner Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040929090103.GB18671@wotan.suse.de> References: <20040928223344.GC2975@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 9662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 162 Lines: 8 > Does this help? Possible. I don't have any plans to change the receiver because it works well for most cases. The problem must be still in the sender. -Andi From jchapman@katalix.com Wed Sep 29 02:54:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 02:54:36 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8T9sPvp005065 for ; Wed, 29 Sep 2004 02:54:25 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1CCb9b-0008RJ-PG; Wed, 29 Sep 2004 04:53:44 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Wed, 29 Sep 2004 10:53:43 +0100 Message-ID: <1096451623.415a862783d87@www.katalix.com> Date: Wed, 29 Sep 2004 10:53:43 +0100 From: James Chapman To: hadi@cyberus.ca, herbert@gondor.apana.org.au Cc: pablo@eurodev.net, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 3239 Lines: 89 Re: async netlink messages Is it possible to deliver async messages to userspace using a polling mechanism to help solve the overrun problem? - Have the kernel keep a list of async messages sent towards each socket rather than trying to deliver each message to the app immediately. Have the kernel send a netlink event message (say, NETLINK_EVENT_WAKEUP) to the app when this queue first goes non-empty. No new NETLINK_EVENT_WAKEUP messages are sent until the event queue goes empty again. - On receipt of NETLINK_EVENT_WAKEUP, a process issues a netlink GET (or DUMP?) on its netlink socket to read its queued events. - If the socket event queue overruns, discard new events and flag the event queue as having lost messages. When the userspace app reads the event queue, it will discover that messages have been lost and can then re-read state from the kernel. - Use a setsockopt on the netlink socket to have the socket configured in this polled-event mode. Just a thought. /james -----Original Message----- From: Herbert Xu [mailto:herbert@gondor.apana.org.au] Sent: 28 September 2004 04:59 To: hadi@cyberus.ca Cc: pablo@eurodev.net, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets On Mon, Sep 27, 2004 at 11:45:25PM -0400, jamal wrote: > > > Now that we know where the events are coming from and what they are, > > we can decide on the solution. In this particular case, there is > > nothing you can do on the sending side. Stopping people from operating > > on networking objects just because some netlink listener can't keep up > > isn't going to work. So congestion control is out of the question. > > fixing the NLM_GOODSIZE issue is a very good first step. Well I'm afraid that it doesn't help in your interface address example because rtmsg_ifa() already allocates a buffer of (approximately) the right size. That is, it doesn't use NLM_GOODSIZE at all. > Adding congestion control would be harder but not out of question. But the question is who are you going to throttle? If you throttle the source of the messages then you're going to stop people from adding or deleting IP addresses which can't be right. If you move the netlink sender into a different execution context and throttle that then that's just extending the receive queue length by stealth. So I'm afraid I don't see how congestion control could be applied in *this* particular context. > > So just bite the bullet and reread the system state by issuing dump > > operations. > > We may as well choose to document it as being this mostly because of the > issue i described above. We shouldnt give up so easily though ;-> Well IMHO this is not giving up at all. Think of it another way. Monitoring routes is like maintaining a program. Normally you just fix the bugs as they come. But if the bug reports are coming in so fast that you can't keep up, perhaps it's time to throw it away and rewrite it from scratch :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ----- End forwarded message ----- From herbert@gondor.apana.org.au Wed Sep 29 03:00:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 03:00:26 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TA0GWZ005500 for ; Wed, 29 Sep 2004 03:00:18 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCbFR-0000U0-00; Wed, 29 Sep 2004 19:59:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCbFJ-0008QX-00; Wed, 29 Sep 2004 19:59:37 +1000 Date: Wed, 29 Sep 2004 19:59:36 +1000 To: James Chapman Cc: hadi@cyberus.ca, pablo@eurodev.net, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040929095936.GB29516@gondor.apana.org.au> References: <1096451623.415a862783d87@www.katalix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096451623.415a862783d87@www.katalix.com> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1188 Lines: 26 On Wed, Sep 29, 2004 at 10:53:43AM +0100, James Chapman wrote: > > - Have the kernel keep a list of async messages sent towards each > socket rather than trying to deliver each message to the app > immediately. Have the kernel send a netlink event message (say, > NETLINK_EVENT_WAKEUP) to the app when this queue first goes > non-empty. No new NETLINK_EVENT_WAKEUP messages are sent until the > event queue goes empty again. > > - On receipt of NETLINK_EVENT_WAKEUP, a process issues a netlink > GET (or DUMP?) on its netlink socket to read its queued events. > > - If the socket event queue overruns, discard new events and flag the > event queue as having lost messages. When the userspace app reads > the event queue, it will discover that messages have been lost and > can then re-read state from the kernel. > > - Use a setsockopt on the netlink socket to have the socket configured > in this polled-event mode. That's basically how it works now. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From gnb@melbourne.sgi.com Wed Sep 29 03:24:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 03:25:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8TAOplG006308 for ; Wed, 29 Sep 2004 03:24:53 -0700 Received: from hole.melbourne.sgi.com (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA27963; Wed, 29 Sep 2004 20:24:25 +1000 Received: by hole.melbourne.sgi.com (Postfix, from userid 16345) id 064FA1C0187A0; Wed, 29 Sep 2004 20:36:47 +1000 (EST) Date: Wed, 29 Sep 2004 20:36:46 +1000 From: Greg Banks To: Jesse Barnes Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, jeremy@sgi.com, John Partridge , "David S. Miller" , Linux Network Development List Subject: Re: [PATCH] I/O space write barrier Message-ID: <20040929103646.GA4682@sgi.com> References: <200409271103.39913.jbarnes@engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409271103.39913.jbarnes@engr.sgi.com> User-Agent: Mutt/1.5.5.1i X-archive-position: 9665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@sgi.com Precedence: bulk X-list: netdev Content-Length: 2553 Lines: 75 G'day, On Mon, Sep 27, 2004 at 11:03:39AM -0700, Jesse Barnes wrote: > On some platforms (e.g. SGI Challenge, Origin, and Altix machines), writes to > I/O space aren't ordered coming from different CPUs. For the most part, this > isn't a problem since drivers generally spinlock around code that does writeX > calls, but if the last operation a driver does before it releases a lock is a > write and some other CPU takes the lock and immediately does a write, it's > possible the second CPU's write could arrive before the first's. > > This patch adds a mmiowb() call to deal with this sort of situation, and > adds some documentation describing I/O ordering issues to deviceiobook.tmpl. > The idea is to mirror the regular, cacheable memory barrier operation, wmb. >[...] > Patches to use this new primitive in various drivers will come separately, > probably via the SCSI tree. Ok, here's a patch for the tg3 network driver to use mmiowb(). Tests over the last couple of days has shown that it solves the oopses in tg3_tx() that I reported and attempted to patch some time ago: http://marc.theaimsgroup.com/?l=linux-netdev&m=108538612421774&w=2 The CPU usage of the mmiowb() approach is also significantly better than doing PCI reads to flush the writes (by setting the existing TG3_FLAG_MBOX_WRITE_REORDER flag). In an artificial CPU-constrained test on a ProPack kernel, the same amount of CPU work for the REORDER solution pushes 85.1 MB/s over 2 NICs compared to 146.5 MB/s for the mmiowb() solution. --- linux.orig/drivers/net/tg3.c 2004-09-22 17:20:45.%N +1000 +++ linux/drivers/net/tg3.c 2004-09-29 19:45:16.%N +1000 @@ -44,6 +44,19 @@ #include #endif +#ifndef mmiowb +/* + * mmiowb() is a memory-mapped I/O write boundary, useful for + * preserving send ring update ordering between multiple CPUs + * Define it if it doesn't exist. + */ +#ifdef CONFIG_IA64_SGI_SN2 +#define mmiowb() sn_mmiob() +#else +#define mmiowb() +#endif +#endif + #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) #define TG3_VLAN_TAG_USED 1 #else @@ -2725,6 +2738,7 @@ next_pkt_nopost: tw32_rx_mbox(MAILBOX_RCV_JUMBO_PROD_IDX + TG3_64BIT_REG_LOW, sw_idx); } + mmiowb(); return received; } @@ -3172,6 +3186,7 @@ static int tg3_start_xmit(struct sk_buff netif_stop_queue(dev); out_unlock: + mmiowb(); spin_unlock_irqrestore(&tp->tx_lock, flags); dev->trans_start = jiffies; Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From hadi@cyberus.ca Wed Sep 29 03:51:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 03:51:11 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TAp5oS007270 for ; Wed, 29 Sep 2004 03:51:06 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CCc2s-0005nH-I7 for netdev@oss.sgi.com; Wed, 29 Sep 2004 06:50:50 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCc2q-00044a-At; Wed, 29 Sep 2004 06:50:48 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040929032724.GA26959@gondor.apana.org.au> References: <20040928024614.GA9911@gondor.apana.org.au> <1096340772.8659.51.camel@jzny.localdomain> <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> <20040929001327.GB25293@gondor.apana.org.au> <1096426324.1044.129.camel@jzny.localdomain> <20040929032724.GA26959@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096455046.1044.189.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Sep 2004 06:50:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3874 Lines: 98 On Tue, 2004-09-28 at 23:27, Herbert Xu wrote: > On Tue, Sep 28, 2004 at 10:52:05PM -0400, jamal wrote: > > > > > You're right. rtmsg_info() is using GOODISZE unnecessarily. I'll > > > write up a patch. > > > > But why? ;-> > > So that the alloc_skb() is slightly less likely to fail. [..] Ok, You fell into my trap. I just had to say that ;-> We are even. > > Well, if you are gonna overrun the socket anyways, is there a point > > in delivering all that incomplete info? > > > > If you go ahead and deliver it anyways, you will be crossing > > kernel->userspace. Its a worthy cause to do so. > > Hang on a second, if we're going to overrun anyway, then we *can't* > deliver it to user-space. If we could deliver then we wouldn't be > having an overrun. Assume you are delivering a huge atomic multi message; lets say it constitutes 50 pkts. --> You deliver up to 15 and then overrun. --> The 15 pkts are a waste, really. User will have to poll for the info for all details to be sure i.e you dont know what was lost for sure if you get an overrun. In otherwise the transaction was not delivered to its completion. > > > Can you please elaborate on "crossing into user space"? I don't think > > > I understand where these cycles are being wasted. > > > > delivering messages which get obsoleted by an overun from kernel to user > > space for uses up unnecessary cycles. > > You'll have to spell it out for me I'm afraid :) See above. > If we're overrunning then we can't deliver the message at hand. If you > are referring to the messages afterwards then the only way we can deliver > them is if the appliation lets us by clearing the queue. If you are > referring to the messages that are already on the queue then we've done > the work already so why shouldn't they stay? I was refering to above scenario. To continue that example: --> 15 pkst made it --> some gap then lost skbs (maybe due to allocation issues etc) --> If you recover and have the last 10 out of 50, then they are obsolete. If you already did the work of collecting them, then reduce the mess by not having the user copy them. I dont think 10 are a big deal but multiply by some factor and the cost is clear to quantify. [..] > we extend the dump paradigm to cover get as well. However, to design the > interface, we need to look at potential users of this. So please give > me an example :) extending get to do the dumplike approach is not a bad idea. I said dont ask me for an example ;-> You provide the mechanism, you be ready for the consequences - people will use it. Thats a good enough reason;-> If you insist however, heres one i can visualize thats a legit get from a semantic view: A get of a table entry which itself happens to be a table (and if you want to be funnier maybe three level deep table). You do a get on a table entry, you get a _whole table_ back. > > > Not quite. Overrun errors are reported immediately. > > > > Yes, except they get reported sooner (by virtue of queue getting filled > > sooner) if you have a 4K sock buffer vs 1M if you are registered for the > > same events. I Know its a digression - just making a point. > > The one with the 1M buffer may not overrun at all if it can process the > events fast enough. Ok, i will agree to that but the assumption in the example is both will be overrun by the same set of messages. To argue (for the sake of arguing) say the 4K buffer user was faster;-> Lets drop this bit. > > congestion - especially in a local scenario. Of course such queues have > > finite buffers - you just engineer it so the queue doesnt overflow and > > head of line blocking is tolerable. Either of those concerns not > > addressed, shit will hit the fan. > > I don't see how you can engineer it so that it doesn't overflow. Sorry, you cant. I meant you have to get the two to work together. cheers, jamal From herbert@gondor.apana.org.au Wed Sep 29 04:43:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 04:43:24 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TBhDqA004528 for ; Wed, 29 Sep 2004 04:43:14 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCcr7-00012G-00; Wed, 29 Sep 2004 21:42:45 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCcqw-0000w0-00; Wed, 29 Sep 2004 21:42:34 +1000 Date: Wed, 29 Sep 2004 21:42:34 +1000 To: jamal Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets Message-ID: <20040929114234.GD29516@gondor.apana.org.au> References: <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> <20040929001327.GB25293@gondor.apana.org.au> <1096426324.1044.129.camel@jzny.localdomain> <20040929032724.GA26959@gondor.apana.org.au> <1096455046.1044.189.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096455046.1044.189.camel@jzny.localdomain> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 2120 Lines: 52 On Wed, Sep 29, 2004 at 06:50:46AM -0400, jamal wrote: > > Ok, You fell into my trap. I just had to say that ;-> We are even. Fair enough :) > Assume you are delivering a huge atomic multi message; lets say it > constitutes 50 pkts. > --> You deliver up to 15 and then overrun. > --> The 15 pkts are a waste, really. User will have to poll > for the info for all details to be sure i.e you dont know what was lost > for sure if you get an overrun. In otherwise the transaction was not > delivered to its completion. I presume that the ifdown script you posted fits this description? I agree this is suboptimal. However, I don't see how the intermediate queue can help here. Hmm, I suspect that there is something broken here that's causing the overruns. Let me have a play with your script/ip monitor and get back to you. > I dont think 10 are a big deal but multiply by some factor and the cost > is clear to quantify. Agreed. Perhaps what we need is a way to identify these messages as related. If you can do that then the kernel can forget about them when an overrun occurs. I still don't see this as a big deal though since the application can always weather the storm by closing the socket after an overrun, sleeping for a while and then reopen it to listen again. > If you insist however, heres one i can visualize thats a legit get from > a semantic view: > A get of a table entry which itself happens to be a table (and if you > want to be funnier maybe three level deep table). You do a get on a > table entry, you get a _whole table_ back. That's easy :) Anything that's a table should use dump. Remember that dump can take parameters just like get. So there's nothing wrong with using dump to get an entry which happens to be a table. PS We've managed to cut down the size of our emails by half. Shows that congestion control is certainly working on this mailing list :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From tgraf@suug.ch Wed Sep 29 05:48:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 05:48:30 -0700 (PDT) Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TCmP6M007095 for ; Wed, 29 Sep 2004 05:48:26 -0700 Received: from postel.suug.ch (unknown [195.134.158.23]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by b.mx.projectdream.org (Postfix) with ESMTP id 5187481; Wed, 29 Sep 2004 14:47:50 +0200 (CEST) Received: by postel.suug.ch (Postfix, from userid 10001) id C99CE1C0E8; Wed, 29 Sep 2004 14:48:32 +0200 (CEST) Date: Wed, 29 Sep 2004 14:48:32 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: RFC/PATCH capture qdisc requeue event in stats Message-ID: <20040929124832.GA9634@postel.suug.ch> References: <1093904088.1043.12.camel@jzny.localdomain> <20040830154430.769d1d59.davem@redhat.com> <1093906592.1037.32.camel@jzny.localdomain> <20040830160052.548c4846.davem@redhat.com> <1093916592.1037.51.camel@jzny.localdomain> <20040830191716.0d002f91.davem@redhat.com> <1093919823.1043.80.camel@jzny.localdomain> <20040830212910.78047bcd.davem@davemloft.net> <20040929003656.GX31616@rei.reeler.org> <1096426464.1045.133.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096426464.1045.133.camel@jzny.localdomain> X-archive-position: 9668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1236 Lines: 31 * jamal <1096426464.1045.133.camel@jzny.localdomain> 2004-09-28 22:54 > Lets do it on gnet stats though so we can make it more accessible. > I think your granularity maybe too thin: bytes,packets, drops > may need to be in the same TLV. I partially agree as long as no structs visible to userspace will ever change after introduction. I'd really like to avoid maintaining different structs for collection and transfer which must be kept in sync. Having the application do its own struct and fill it based on if (tb[TCA_STATS_*]) conditions avoids all possible compatibility issues. It would be possible for the application to choose between the original and a _64 variant if we ever introduce them. So this would be my approach: Leave gnet_stats as-is and extend it as needed but hide it from userspace. Extend gen_copy_stats to add a nested TLV for every stat in the structure. We could even introduce a bitmap to allow the struct gnet_stats user to define which statistics are defined and which aren't. This way we could avoid the mess with pfifo and bfifo both using backlog but with a different unit in mind (packets/bytes). > do you have cycles to run with that patch? Yes, it is related to my work so it's not a problem. From hadi@cyberus.ca Wed Sep 29 06:55:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 06:55:35 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TDtTmI009817 for ; Wed, 29 Sep 2004 06:55:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1CCevJ-0000Ov-En for netdev@oss.sgi.com; Wed, 29 Sep 2004 09:55:13 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCevF-0007w3-7z; Wed, 29 Sep 2004 09:55:09 -0400 Subject: Re: [PATCH] Improve behaviour of Netlink Sockets From: jamal Reply-To: hadi@cyberus.ca To: Herbert Xu Cc: Pablo Neira , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20040929114234.GD29516@gondor.apana.org.au> References: <20040928032321.GB10116@gondor.apana.org.au> <1096343125.8661.96.camel@jzny.localdomain> <20040928035921.GA10675@gondor.apana.org.au> <1096367787.8662.146.camel@jzny.localdomain> <20040928111159.GA18421@gondor.apana.org.au> <1096374736.8663.217.camel@jzny.localdomain> <20040929001327.GB25293@gondor.apana.org.au> <1096426324.1044.129.camel@jzny.localdomain> <20040929032724.GA26959@gondor.apana.org.au> <1096455046.1044.189.camel@jzny.localdomain> <20040929114234.GD29516@gondor.apana.org.au> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096466106.1024.29.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Sep 2004 09:55:06 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3486 Lines: 78 On Wed, 2004-09-29 at 07:42, Herbert Xu wrote: > I presume that the ifdown script you posted fits this description? Probably not a good fit. A good fit (not sure how to create the race) is to have (handwave to illustrate) 1000 netdevices getting downed. You get notified of first 50, overrun happens, then you get last 30 of last 50 and then another overrun. And somewhere in the second overrun you lost notification that the netdevices 5-8 infact came up. A scheme which polls every X seconds from user space will catch this of course but depending on how you do it the latency will vary. > I agree this is suboptimal. However, I don't see how the intermediate > queue can help here. > The intermidiate queue was just brainstorming. It is based on something that i tried with taps - may not be the best approach and at the end we may just say we are better off leaving things as they are. The intermidiate queue is a classical approach to manage disparity between speed and buffer mismatching in a case when you either have multiple senders or receivers (in our case). The idea behind it being that if i am going to overflow it with 1000 events then i am pretty sure that none of the user space apps cannot handle that load. > Hmm, I suspect that there is something broken here that's causing the > overruns. Let me have a play with your script/ip monitor and get back > to you. > > > I dont think 10 are a big deal but multiply by some factor and the cost > > is clear to quantify. > > Agreed. Perhaps what we need is a way to identify these messages as > related. If you can do that then the kernel can forget about them > when an overrun occurs. Theres a lot of things that netlink needs to improve on, this being one. I dont wanna go over the laundry list but it will need major surgery and will break backward compatibility. I know you are a fireman and will go fixing things - so i aint telling you yet ;-> (more worried we'll put solutions that may get us going as bandaids and postpone the surgery). In all fairness you could use the sequenece number as a transaction identifier will require more management. > I still don't see this as a big deal though since the application can > always weather the storm by closing the socket after an overrun, > sleeping for a while and then reopen it to listen again. > > > If you insist however, heres one i can visualize thats a legit get from > > a semantic view: > > A get of a table entry which itself happens to be a table (and if you > > want to be funnier maybe three level deep table). You do a get on a > > table entry, you get a _whole table_ back. > > That's easy :) Anything that's a table should use dump. Thats why i emphasized "legit get from a semantic view" ;-> Assuming you know the item you are getting is a table, yes indeed; however, it does get tiring and abuse of human intelligence to say "dump table X which is found in entry a of table B which is found in entry c of table D which is found in entry e of table F which itself is found it table G entry h .." instead of just saying "get entry a of table X" > Remember that > dump can take parameters just like get. So there's nothing wrong with > using dump to get an entry which happens to be a table. > PS We've managed to cut down the size of our emails by half. Shows that > congestion control is certainly working on this mailing list :) Shall we include brazillian coffee as a parameter in congestion control?;-> cheers, jamal From hadi@cyberus.ca Wed Sep 29 07:09:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 07:09:10 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TE955S010376 for ; Wed, 29 Sep 2004 07:09:05 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1CCf8U-0003Eo-Pv for netdev@oss.sgi.com; Wed, 29 Sep 2004 10:08:50 -0400 Received: from [216.209.86.2] (helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CCf8S-0001RC-0d; Wed, 29 Sep 2004 10:08:48 -0400 Subject: Re: RFC/PATCH capture qdisc requeue event in stats From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com, shemminger@osdl.org In-Reply-To: <20040929124832.GA9634@postel.suug.ch> References: <1093904088.1043.12.camel@jzny.localdomain> <20040830154430.769d1d59.davem@redhat.com> <1093906592.1037.32.camel@jzny.localdomain> <20040830160052.548c4846.davem@redhat.com> <1093916592.1037.51.camel@jzny.localdomain> <20040830191716.0d002f91.davem@redhat.com> <1093919823.1043.80.camel@jzny.localdomain> <20040830212910.78047bcd.davem@davemloft.net> <20040929003656.GX31616@rei.reeler.org> <1096426464.1045.133.camel@jzny.localdomain> <20040929124832.GA9634@postel.suug.ch> Content-Type: text/plain Organization: jamalopolous Message-Id: <1096466925.1022.43.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Sep 2004 10:08:45 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 9670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2414 Lines: 63 On Wed, 2004-09-29 at 08:48, Thomas Graf wrote: > * jamal <1096426464.1045.133.camel@jzny.localdomain> 2004-09-28 22:54 > > Lets do it on gnet stats though so we can make it more accessible. > > I think your granularity maybe too thin: bytes,packets, drops > > may need to be in the same TLV. > > I partially agree as long as no structs visible to userspace will > ever change after introduction. > Note, this comes as a lesson from the current TC_STAT maintainance headache. We messed up there but didnt have the hindsight we do now. Adding a new user space visible entry becomes a matter of intrioducing a new TLV. > I'd really like to avoid maintaining different structs for collection > and transfer which must be kept in sync. As a general principle i agree with you - this is why tc_stat got us in trouble to begin with. The side effect is the cost of TLV 32 bit header to transport a 32 bit or worse 8 bit. Putting entries into semantical groups will help reduce the overhead but should only be done when makes sense to do so. ex i see someone counting packets will also count bytes and maybe count drops. Essentially if things dont make sense grouping, then dont group. Later we figure it was a mistake, sure add a new TLV. The problem with tc_stat is it was too fat. > Having the application do its own struct and fill it based on > if (tb[TCA_STATS_*]) conditions avoids all possible compatibility > issues. It would be possible for the application to choose between > the original and a _64 variant if we ever introduce them. Well, same principle applies to XSTAT; but thats app specific. > So this would be my approach: > > Leave gnet_stats as-is and extend it as needed but hide it from > userspace. Its too fat ;-> I dont see why an action which doesnt queue need to have access to queue stats. > Extend gen_copy_stats to add a nested TLV for every stat in > the structure. We could even introduce a bitmap to allow the > struct gnet_stats user to define which statistics are defined > and which aren't. This way we could avoid the mess with pfifo > and bfifo both using backlog but with a different unit in mind > (packets/bytes). > I think we should kill gnet_stat in its current form. The lessons of tc_stat still haunt me. > > do you have cycles to run with that patch? > > Yes, it is related to my work so it's not a problem. Thanks. We can talk offline then. cheers, jamal From Robert.Olsson@data.slu.se Wed Sep 29 08:21:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 08:21:06 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TFL09G018337 for ; Wed, 29 Sep 2004 08:21:01 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8TFKjY2018198; Wed, 29 Sep 2004 17:20:45 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 8C1D690265; Wed, 29 Sep 2004 17:20:45 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16730.53965.503605.943263@robur.slu.se> Date: Wed, 29 Sep 2004 17:20:45 +0200 To: "David S. Miller" Cc: netdev@oss.sgi.com, robert.olsson@data.slu.se Subject: Move fib_alias out of fib_hash.c In-Reply-To: <20040928214722.11aef8e0.davem@davemloft.net> References: <20040928214722.11aef8e0.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 784 Lines: 35 David S. Miller writes: > > Ok, this begins the movement of fib_alias object handling > out of fib_hash.c The idea is to make fib_hash.c purely > a longest-matching-prefix lookup implementation. > > Look at fn_hash_lookup() after these changes, and you'll > get an idea of how I want the whole fib_hash.c file to look > in the end. Exactly, we can interface new lookups cleanly. For a trie something like: static int fn_trie_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) { struct trie *t = (struct trie *) tb->tb_data; struct list_head *fah=NULL; int err=1, plen, r; r = trie_pfx_get(t, flp->fl4_dst, &fah, &plen); if (r && fah) err = fib_semantic_match(fah, flp, res, plen); return err; } Cheers. --ro From becker@scyld.com Wed Sep 29 10:16:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 10:16:32 -0700 (PDT) Received: from bluewest.scyld.com (bluewest.scyld.com [64.240.166.233]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8THGQON031501 for ; Wed, 29 Sep 2004 10:16:26 -0700 Received: from training.scyld.com (h-66-134-106-242.mclnva23.covad.net [66.134.106.242]) by bluewest.scyld.com (8.12.11/8.12.11) with ESMTP id i8TH8M3t025722; Wed, 29 Sep 2004 10:08:22 -0700 Received: from localhost (becker@localhost) by training.scyld.com (8.11.6/8.11.6) with ESMTP id i8THG1E08004; Wed, 29 Sep 2004 13:16:02 -0400 X-Authentication-Warning: training.scyld.com: becker owned process doing -bs Date: Wed, 29 Sep 2004 13:16:01 -0400 (EDT) From: Donald Becker To: "John W. Linville" cc: akpm@osdl.org, , Subject: Re: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod In-Reply-To: <20040928145455.C12480@tuxdriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-archive-position: 9672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev Content-Length: 1799 Lines: 47 On Tue, 28 Sep 2004, John W. Linville wrote: > Date: Tue, 28 Sep 2004 14:54:55 -0400 > From: John W. Linville > To: akpm@osdl.org > Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org > Subject: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod > > Some (earlier?) versions of the 3c905(B) card get confused and refuse to > work again after the 3c59x module is removed (even after reloading the > module). Changing vortex_remove_one() to allow the auto-initialize > state machine logic to be reset when the module is removed alleviates > this problem. ...and creates a new problem: resetting the link causes operational problems on many networks. The most obvious example is spanning tree detection delays on switches, where the switch does not pass traffic. This 3c59x.c code was changed in 2001 to mask the transceiver reset and shut the chip down cleanly. This occurred in two steps, with a discussion on the vortex mailing list for each. 3c59x.c:v0.99Uc 12/5/2001 3c59x.c:v0.99T 7/16/2001 The December change was noted as specifically for the 3c905B. The correct solution is to reset the transceiver (and thus cause re-autonegotiation) only if a problem is detected, not an unconditional or proactive reset. > --- linux-2.6/drivers/net/3c59x.c.orig > +++ linux-2.6/drivers/net/3c59x.c > @@ -3162,7 +3162,7 @@ static void __devexit vortex_remove_one > pci_restore_state(VORTEX_PCI(vp), vp->power_state); > } > /* Should really use issue_and_wait() here */ > - outw(TotalReset|0x14, dev->base_addr + EL3_CMD); > + outw(TotalReset|0x04, dev->base_addr + EL3_CMD); > -- Donald Becker becker@scyld.com Scyld Software Scyld Beowulf cluster systems 914 Bay Ridge Road, Suite 220 www.scyld.com Annapolis MD 21403 410-990-9993 From shemminger@osdl.org Wed Sep 29 11:04:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 11:04:17 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TI42tj000907 for ; Wed, 29 Sep 2004 11:04:02 -0700 Received: from [172.20.1.60] (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i8TI3dv32483; Wed, 29 Sep 2004 11:03:39 -0700 Subject: Please route new work through -mm tree? From: Stephen Hemminger To: davem@redhat.com Cc: netdev@oss.sgi.com Content-Type: text/plain Organization: Open Source Development Lab Date: Wed, 29 Sep 2004 11:03:43 -0700 Message-Id: <1096481023.8636.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-archive-position: 9673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 312 Lines: 6 There is lots of stuff going on that has a potential to make things less stable. How about routing any future TCP, fib, statistics, stuff through Andrew's tree and not directly to Linus. That way we have some buffer and can stablize some more. Alternatively, Dave you could publize your staging area some more. From niv@us.ibm.com Wed Sep 29 11:14:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 11:14:45 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TIEUlX001444 for ; Wed, 29 Sep 2004 11:14:30 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8TIDvvx713978; Wed, 29 Sep 2004 14:13:57 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8TIFAeR088834; Wed, 29 Sep 2004 14:15:11 -0400 Message-ID: <415AFB63.7010107@us.ibm.com> Date: Wed, 29 Sep 2004 11:13:55 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: davem@redhat.com, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? References: <1096481023.8636.7.camel@localhost.localdomain> In-Reply-To: <1096481023.8636.7.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 782 Lines: 20 Stephen Hemminger wrote: > There is lots of stuff going on that has a potential to make things less > stable. How about routing any future TCP, fib, statistics, stuff through > Andrew's tree and not directly to Linus. That way we have some buffer > and can stablize some more. Alternatively, Dave you could publize your > staging area some more. That would help us out a bit - we're testing mainline and -mm regularly. This came up for me yesterday, too, with Dave's tso patches (which I'm testing right now, after getting past some hw issues). I was going to suggest a separate bk tree or something that would hold this stuff till it stabilized, before it needed to go into mainline. Having that picked up by mm would help us to increase coverage quite a bit. thanks, Nivedita From marado@student.dei.uc.pt Wed Sep 29 11:26:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 11:26:21 -0700 (PDT) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TIQ7EX001977 for ; Wed, 29 Sep 2004 11:26:08 -0700 Received: from student.dei.uc.pt (student.dei.uc.pt [10.1.0.1]) by smtp.dei.uc.pt (8.12.8/8.12.8) with ESMTP id i8TINKB4023543; Wed, 29 Sep 2004 19:23:20 +0100 Received: from student.dei.uc.pt (localhost.localdomain [127.0.0.1]) by student.dei.uc.pt (8.12.8/8.12.8) with ESMTP id i8TINJTx018317; Wed, 29 Sep 2004 19:23:19 +0100 Received: from localhost (marado@localhost) by student.dei.uc.pt (8.12.8/8.12.8/Submit) with ESMTP id i8TINJ1J006627; Wed, 29 Sep 2004 19:23:19 +0100 Date: Wed, 29 Sep 2004 19:23:15 +0100 (WEST) From: "Marcos D. Marado Torres" To: Nivedita Singhvi cc: Stephen Hemminger , davem@redhat.com, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? In-Reply-To: <415AFB63.7010107@us.ibm.com> Message-ID: References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-UC-FCTUC-DEI-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-UC-FCTUC-DEI-MailScanner: Found to be clean X-MailScanner-From: marado@student.dei.uc.pt X-archive-position: 9675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marado@student.dei.uc.pt Precedence: bulk X-list: netdev Content-Length: 1077 Lines: 32 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 29 Sep 2004, Nivedita Singhvi wrote: > I was going to > suggest a separate bk tree or something that would > hold this stuff till it stabilized, before it needed > to go into mainline. Having that picked up by mm would > help us to increase coverage quite a bit. What about doing a -mm*-net* tree? Mind Booster Noori - -- /* *************************************************************** */ Marcos Daniel Marado Torres AKA Mind Booster Noori http://student.dei.uc.pt/~marado - marado@student.dei.uc.pt () Join the ASCII ribbon campaign against html email, Microsoft /\ attachments and Software patents. They endanger the World. Sign a petition against patents: http://petition.eurolinux.org /* *************************************************************** */ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFBWv2XmNlq8m+oD34RAie+AKDR+MbEBQ0nrNVVZb3lM6oEisRt9wCfc7cI 8yFjdsZ2gXcb81yVpY8Ukgo= =LjKk -----END PGP SIGNATURE----- From jgarzik@pobox.com Wed Sep 29 12:36:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 12:36:54 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TJalRN006860 for ; Wed, 29 Sep 2004 12:36:48 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCkFe-0004kg-2g; Wed, 29 Sep 2004 20:36:34 +0100 Message-ID: <415B0EB5.3010809@pobox.com> Date: Wed, 29 Sep 2004 15:36:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yoshfuji@linux-ipv6.org CC: jgarzik@pobox.com, davem@davemloft.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Tons of "BUG: dst overflow ..." messages References: <415A3635.4070000@pobox.com> <20040928214055.609f7715.davem@davemloft.net> <415A40D0.7040403@pobox.com> <20040929.143216.55773467.yoshfuji@linux-ipv6.org> In-Reply-To: <20040929.143216.55773467.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 9676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 801 Lines: 41 YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž wrote: > In article <415A40D0.7040403@pobox.com> (at Wed, 29 Sep 2004 00:57:52 -0400), Jeff Garzik says: > > >>David S. Miller wrote: >> >>>On Wed, 29 Sep 2004 00:12:37 -0400 >>>Jeff Garzik wrote: >>> >>> >>> >>>>BUG: dst underflow 0: cf5dd180 at f8c0be5d > > : > >>>Can you match up the 0xf8xxxxxx addresses to spots >>>in your System.map? Thanks. > > : > >>ipv6 232192 38 - Live 0xf8c01000 >> ^^^^ appears to be this > > > Hmm, I haven't met this (during TAHI test against latest tree). > Would you try latest bk tree? I will try soon... it's my fileserver and router, so does not get upgraded very often. > Plus, if you know how to reproduce this, tell me. Sorry, I do not know :( Regards, Jeff From wsonguci@yahoo.com Wed Sep 29 12:37:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 12:37:45 -0700 (PDT) Received: from web40006.mail.yahoo.com (web40006.mail.yahoo.com [66.218.78.24]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8TJbbhu007019 for ; Wed, 29 Sep 2004 12:37:38 -0700 Message-ID: <20040929193721.81884.qmail@web40006.mail.yahoo.com> Received: from [63.87.1.243] by web40006.mail.yahoo.com via HTTP; Wed, 29 Sep 2004 12:37:21 PDT Date: Wed, 29 Sep 2004 12:37:21 -0700 (PDT) From: Song Wang Subject: Re: [Routing] Performance Comparison between 2.6 and 2.4 kernel To: hadi@cyberus.ca, "David S. Miller" Cc: Song Wang , netdev@oss.sgi.com In-Reply-To: <1095334258.1065.158.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wsonguci@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1179 Lines: 49 Hi, jamal, Could you please kindly point where the gettimeofday patch is? Is it in 2.6.8.1 kernel? BTW, what is the packet size for you performance number, 64 bytes? I appreciate it. -Song --- jamal wrote: > On Wed, 2004-09-15 at 14:08, David S. Miller wrote: > > On Wed, 15 Sep 2004 11:06:03 -0700 (PDT) > > Song Wang wrote: > > > > > The mips CPU on the board is MIPS32 compatible. > > > I don't think it's NAPI based. > > > > NAPI is an attribute of the network adapter, not > > the cpu. > > > > Although I would very much anticipate this being > > a MIPS or network adapter specific problem since > > on x86 routing is pretty fast in 2.6.x > > Note, I could hit 4-500Kpps on a bcom sb1250 800Mhz; > trying to simulate > Andis gettimeofday changes (which are in 2.6 since i > havent seen a 2.6 > port for that board ) gives another 100Kpps. Theres > still room for > improvement just havent had time. > You are right though it could be a 2.6.x arch > specific issue. Bacchus? > > cheers, > jamal > > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From davem@davemloft.net Wed Sep 29 12:54:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 12:55:01 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TJssS6007762 for ; Wed, 29 Sep 2004 12:54:55 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCkWV-000214-00; Wed, 29 Sep 2004 12:53:59 -0700 Date: Wed, 29 Sep 2004 12:53:59 -0700 From: "David S. Miller" To: Robert Olsson Cc: netdev@oss.sgi.com, robert.olsson@data.slu.se Subject: Re: Move fib_alias out of fib_hash.c Message-Id: <20040929125359.12a00ba7.davem@davemloft.net> In-Reply-To: <16730.53965.503605.943263@robur.slu.se> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1042 Lines: 26 On Wed, 29 Sep 2004 17:20:45 +0200 Robert Olsson wrote: > we can interface new lookups cleanly. For a trie something like: You are already making a critical logic error. You cannot find the longest matching prefix and just use that. Rather, you must iterate through all matching prefixes in the table from longest to shortest, trying fib_semantic_match() on each one until it says OK. If you don't do that, then you're not providing the same behavior of the current code. If next hops go down, you have to try the next longest matching prefix and so on and so forth. It can also be the case that the longest matching prefix entry has no matching TOS key, whereas a shorter prefix does. This makes using a new algorithm very non-trivial. Probably what you should do is keep an array on the function stack, recording shorter prefix entries you see on your walk down to the longest matching prefix. Then you process the array one entry at a time back to the root, trying fib_semantic_match() on each one. From davem@davemloft.net Wed Sep 29 12:57:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 12:57:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TJvj1p008116 for ; Wed, 29 Sep 2004 12:57:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCkZA-00021L-00; Wed, 29 Sep 2004 12:56:44 -0700 Date: Wed, 29 Sep 2004 12:56:44 -0700 From: "David S. Miller" To: Andi Kleen Cc: jheffner@psc.edu, ak@suse.de, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929125644.40358b42.davem@davemloft.net> In-Reply-To: <20040929090103.GB18671@wotan.suse.de> References: <20040928223344.GC2975@wotan.suse.de> <20040929090103.GB18671@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 582 Lines: 19 On Wed, 29 Sep 2004 11:01:03 +0200 Andi Kleen wrote: > > Does this help? > > Possible. I don't have any plans to change the receiver because > it works well for most cases. > > The problem must be still in the sender. "Must"? So you've proven that the ack-every-22 packets behavior is due entirely to the sender? If you put 2.6.9-current on both ends and this makes things go smoothly that is an important data point and nobody else is seeing the behavior you are at the moment. Personally, all of my bets are on the 2.6.5 frankenstein kernel as the culprit :-) From olh@suse.de Wed Sep 29 13:02:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:02:34 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TK2SMF008487 for ; Wed, 29 Sep 2004 13:02:28 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id C22A9C9D0E5; Wed, 29 Sep 2004 22:01:58 +0200 (CEST) Date: Wed, 29 Sep 2004 22:01:58 +0200 From: Olaf Hering To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH] allow CONFIG_NET=n on ppc64 Message-ID: <20040929200158.GA16366@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-DOS: I got your 640K Real Mode Right Here Buddy! X-Homeland-Security: You are not supposed to read this line! You are a terrorist! User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) X-archive-position: 9680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olh@suse.de Precedence: bulk X-list: netdev Content-Length: 3230 Lines: 125 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit The attached minimal config does not compile on ppc64. I was able to boot the resulting binary with this patch. Signed-off-by: Olaf Hering diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.9-rc2/arch/ppc64/kernel/misc.S linux-2.6.9-rc2.ppc64/arch/ppc64/kernel/misc.S --- linux-2.6.9-rc2/arch/ppc64/kernel/misc.S 2004-09-13 07:33:23.000000000 +0200 +++ linux-2.6.9-rc2.ppc64/arch/ppc64/kernel/misc.S 2004-09-29 21:00:44.909074755 +0200 @@ -703,7 +703,11 @@ _GLOBAL(sys_call_table32) .llong .compat_sys_statfs .llong .compat_sys_fstatfs /* 100 */ .llong .sys_ni_syscall /* old ioperm syscall */ +#ifdef CONFIG_NET .llong .compat_sys_socketcall +#else + .llong .sys_ni_syscall /* old ioperm syscall */ +#endif .llong .sys32_syslog .llong .compat_sys_setitimer .llong .compat_sys_getitimer /* 105 */ diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.9-rc2/include/net/sock.h linux-2.6.9-rc2.ppc64/include/net/sock.h --- linux-2.6.9-rc2/include/net/sock.h 2004-09-13 07:33:11.000000000 +0200 +++ linux-2.6.9-rc2.ppc64/include/net/sock.h 2004-09-29 21:06:03.544933591 +0200 @@ -1327,6 +1327,13 @@ static inline void sock_valbool_flag(str extern __u32 sysctl_wmem_max; extern __u32 sysctl_rmem_max; +#ifdef CONFIG_NET int siocdevprivate_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg); +#else +static inline int siocdevprivate_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg) +{ + return -ENODEV; +} +#endif #endif /* _SOCK_H */ -- USB is for mice, FireWire is for men! sUse lINUX ag, nÃœRNBERG --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="minimal.config" CONFIG_64BIT=y CONFIG_MMU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_ISA_DMA=y CONFIG_HAVE_DEC_LOCK=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_FRAME_POINTER=y CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCALVERSION="" CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_SHMEM=y CONFIG_SYSVIPC_COMPAT=y CONFIG_PPC_PSERIES=y CONFIG_PPC=y CONFIG_PPC64=y CONFIG_PPC_OF=y CONFIG_IOMMU_VMERGE=y CONFIG_SMP=y CONFIG_IRQ_ALL_CPUS=y CONFIG_NR_CPUS=128 CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="panic=1" CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_DUMMY_CONSOLE=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_MSDOS_PARTITION=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUGGER=y CONFIG_XMON=y CONFIG_XMON_DEFAULT=y CONFIG_LIBCRC32C=y --h31gzZEtNLTqOjlF-- From ak@suse.de Wed Sep 29 13:17:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:17:52 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKHjCD009096 for ; Wed, 29 Sep 2004 13:17:46 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 7E5B5C9D6D3; Wed, 29 Sep 2004 22:15:25 +0200 (CEST) Date: Wed, 29 Sep 2004 22:15:25 +0200 From: Andi Kleen To: Olaf Hering Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] allow CONFIG_NET=n on ppc64 Message-ID: <20040929201524.GA14615@wotan.suse.de> References: <20040929200158.GA16366@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929200158.GA16366@suse.de> X-archive-position: 9681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 951 Lines: 24 On Wed, Sep 29, 2004 at 10:01:58PM +0200, Olaf Hering wrote: > > The attached minimal config does not compile on ppc64. > I was able to boot the resulting binary with this patch. I already fixed this some time ago, but the patch must have disappeared. > diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.9-rc2/arch/ppc64/kernel/misc.S linux-2.6.9-rc2.ppc64/arch/ppc64/kernel/misc.S > --- linux-2.6.9-rc2/arch/ppc64/kernel/misc.S 2004-09-13 07:33:23.000000000 +0200 > +++ linux-2.6.9-rc2.ppc64/arch/ppc64/kernel/misc.S 2004-09-29 21:00:44.909074755 +0200 > @@ -703,7 +703,11 @@ _GLOBAL(sys_call_table32) > .llong .compat_sys_statfs > .llong .compat_sys_fstatfs /* 100 */ > .llong .sys_ni_syscall /* old ioperm syscall */ > +#ifdef CONFIG_NET > .llong .compat_sys_socketcall > +#else > + .llong .sys_ni_syscall /* old ioperm syscall */ > +#endif Right fix is to declare compat_sys_socketcall as as cond_syscall() in sys.c -Andi From davem@redhat.com Wed Sep 29 13:20:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:20:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKKpOC009468 for ; Wed, 29 Sep 2004 13:20:52 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8TKKUoX031944; Wed, 29 Sep 2004 16:20:30 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8TKKTr07518; Wed, 29 Sep 2004 16:20:29 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i8TKKF6S007672; Wed, 29 Sep 2004 16:20:15 -0400 Date: Wed, 29 Sep 2004 13:19:47 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? Message-Id: <20040929131947.03c3e9e5.davem@redhat.com> In-Reply-To: <1096481023.8636.7.camel@localhost.localdomain> References: <1096481023.8636.7.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1157 Lines: 25 On Wed, 29 Sep 2004 11:03:43 -0700 Stephen Hemminger wrote: > There is lots of stuff going on that has a potential to make things less > stable. How about routing any future TCP, fib, statistics, stuff through > Andrew's tree and not directly to Linus. That way we have some buffer > and can stablize some more. Alternatively, Dave you could publize your > staging area some more. I'm not changing how I do things because: 1) Putting the net stuff into -mm makes debugging of networking changes harder, as -mm has a ton of experimental stuff in it as well. -mm frequently makes machines unbootable, and particularly this is felt on non-x86 platforms such as sparc64 which is where I do all of my work. 2) I am more than happy to post the location of my net-2.6 tree but last time I used this actively (whilst Linus was away for 2 weeks) the IBM folks complained that this gave them too many trees to work from. Furthermore, I've never put any change into my tree that I didn't think was ready for upstream. When I post something here before pushing to Linus, that's the chance for folks to test things out. From davem@davemloft.net Wed Sep 29 13:24:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:24:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKOYY2009822 for ; Wed, 29 Sep 2004 13:24:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCkyO-000250-00; Wed, 29 Sep 2004 13:22:48 -0700 Date: Wed, 29 Sep 2004 13:22:47 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? Message-Id: <20040929132247.227fffcd.davem@davemloft.net> In-Reply-To: <415AFB63.7010107@us.ibm.com> References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 822 Lines: 22 On Wed, 29 Sep 2004 11:13:55 -0700 Nivedita Singhvi wrote: > I was going to suggest a separate bk tree or something that would > hold this stuff till it stabilized, before it needed > to go into mainline. Nivedita, it was you specifically who complained to me when I used a seperate BK tree for networking changes last month whilst Linus was away for 2 weeks. You said that this gave IBM too many trees to work from, so I told you that what I was doing was a temporary thing until Linus came back from his trip. Now you're suggesting that I specifically do what you asked me not to do a month ago. So figure out what you really want. And I have to warn people if they think that the churn is fast and the rate of change in the networking is high right now, you have seen absolutely nothing yet. :-) From davem@davemloft.net Wed Sep 29 13:36:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:36:18 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKa9ux010335 for ; Wed, 29 Sep 2004 13:36:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CClAC-00026X-00; Wed, 29 Sep 2004 13:35:00 -0700 Date: Wed, 29 Sep 2004 13:35:00 -0700 From: "David S. Miller" To: Greg Banks Cc: jbarnes@engr.sgi.com, akpm@osdl.org, linux-kernel@vger.kernel.org, jeremy@sgi.com, johnip@sgi.com, netdev@oss.sgi.com Subject: Re: [PATCH] I/O space write barrier Message-Id: <20040929133500.59d78765.davem@davemloft.net> In-Reply-To: <20040929103646.GA4682@sgi.com> References: <200409271103.39913.jbarnes@engr.sgi.com> <20040929103646.GA4682@sgi.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 22 On Wed, 29 Sep 2004 20:36:46 +1000 Greg Banks wrote: > Ok, here's a patch for the tg3 network driver to use mmiowb(). Tests > over the last couple of days has shown that it solves the oopses in > tg3_tx() that I reported and attempted to patch some time ago: > > http://marc.theaimsgroup.com/?l=linux-netdev&m=108538612421774&w=2 > > The CPU usage of the mmiowb() approach is also significantly better > than doing PCI reads to flush the writes (by setting the existing > TG3_FLAG_MBOX_WRITE_REORDER flag). In an artificial CPU-constrained > test on a ProPack kernel, the same amount of CPU work for the REORDER > solution pushes 85.1 MB/s over 2 NICs compared to 146.5 MB/s for the > mmiowb() solution. Please put this macro in asm/io.h or similar and make sure every platform has it implemented or provides a NOP version. A lot of people are going to get this wrong btw. The only way it's really going to be cured across the board is if someone like yourself who understands this audits all of the drivers. From jbarnes@engr.sgi.com Wed Sep 29 13:44:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:44:20 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKiFaP010811 for ; Wed, 29 Sep 2004 13:44:15 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i8TLsPpk029155 for ; Wed, 29 Sep 2004 14:54:25 -0700 Received: from spamtin.engr.sgi.com (postfix@spamtin.engr.sgi.com [163.154.6.130]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i8TKhuY914773292; Wed, 29 Sep 2004 13:43:59 -0700 (PDT) Received: by spamtin.engr.sgi.com (Postfix, from userid 35197) id 46CD62404087; Wed, 29 Sep 2004 13:43:56 -0700 (PDT) From: Jesse Barnes To: "David S. Miller" Subject: Re: [PATCH] I/O space write barrier Date: Wed, 29 Sep 2004 13:43:55 -0700 User-Agent: KMail/1.7 Cc: Greg Banks , akpm@osdl.org, linux-kernel@vger.kernel.org, jeremy@sgi.com, johnip@sgi.com, netdev@oss.sgi.com References: <200409271103.39913.jbarnes@engr.sgi.com> <20040929103646.GA4682@sgi.com> <20040929133500.59d78765.davem@davemloft.net> In-Reply-To: <20040929133500.59d78765.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409291343.55863.jbarnes@engr.sgi.com> X-archive-position: 9685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbarnes@engr.sgi.com Precedence: bulk X-list: netdev Content-Length: 1463 Lines: 33 On Wednesday, September 29, 2004 1:35 pm, David S. Miller wrote: > On Wed, 29 Sep 2004 20:36:46 +1000 > > Greg Banks wrote: > > Ok, here's a patch for the tg3 network driver to use mmiowb(). Tests > > over the last couple of days has shown that it solves the oopses in > > tg3_tx() that I reported and attempted to patch some time ago: > > > > http://marc.theaimsgroup.com/?l=linux-netdev&m=108538612421774&w=2 > > > > The CPU usage of the mmiowb() approach is also significantly better > > than doing PCI reads to flush the writes (by setting the existing > > TG3_FLAG_MBOX_WRITE_REORDER flag). In an artificial CPU-constrained > > test on a ProPack kernel, the same amount of CPU work for the REORDER > > solution pushes 85.1 MB/s over 2 NICs compared to 146.5 MB/s for the > > mmiowb() solution. > > Please put this macro in asm/io.h or similar and make sure > every platform has it implemented or provides a NOP version. The patch that actually implements mmiowb() already does this, I think Greg just used his patch for testing. The proper way to do it of course is to just use mmiowb() where needed in tg3 after the write barrier patch gets in. > A lot of people are going to get this wrong btw. The only > way it's really going to be cured across the board is if someone > like yourself who understands this audits all of the drivers. Yep, just like PCI posting (though many people seem to have a grasp on that now). Thanks, Jesse From davem@davemloft.net Wed Sep 29 13:51:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:51:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKpYxn011226 for ; Wed, 29 Sep 2004 13:51:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CClPB-00029Z-00; Wed, 29 Sep 2004 13:50:29 -0700 Date: Wed, 29 Sep 2004 13:50:29 -0700 From: "David S. Miller" To: Jesse Barnes Cc: gnb@sgi.com, akpm@osdl.org, linux-kernel@vger.kernel.org, jeremy@sgi.com, johnip@sgi.com, netdev@oss.sgi.com Subject: Re: [PATCH] I/O space write barrier Message-Id: <20040929135029.38444afd.davem@davemloft.net> In-Reply-To: <200409291343.55863.jbarnes@engr.sgi.com> References: <200409271103.39913.jbarnes@engr.sgi.com> <20040929103646.GA4682@sgi.com> <20040929133500.59d78765.davem@davemloft.net> <200409291343.55863.jbarnes@engr.sgi.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 407 Lines: 11 On Wed, 29 Sep 2004 13:43:55 -0700 Jesse Barnes wrote: > The patch that actually implements mmiowb() already does this, I think Greg > just used his patch for testing. The proper way to do it of course is to > just use mmiowb() where needed in tg3 after the write barrier patch gets in. Perfect, please send me a tg3 patch once the mmiowb() bits go into the tree. Thanks a lot. From ak@suse.de Wed Sep 29 13:56:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:57:03 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKusfa011636 for ; Wed, 29 Sep 2004 13:56:55 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 73E1AC9E2AB; Wed, 29 Sep 2004 22:56:37 +0200 (CEST) Date: Wed, 29 Sep 2004 22:56:35 +0200 From: Andi Kleen To: "David S. Miller" Cc: jheffner@psc.edu, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929225635.061f2405.ak@suse.de> In-Reply-To: <20040929125644.40358b42.davem@davemloft.net> References: <20040928223344.GC2975@wotan.suse.de> <20040929090103.GB18671@wotan.suse.de> <20040929125644.40358b42.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 7529 Lines: 100 On Wed, 29 Sep 2004 12:56:44 -0700 "David S. Miller" wrote: > On Wed, 29 Sep 2004 11:01:03 +0200 > Andi Kleen wrote: > > > > Does this help? > > > > Possible. I don't have any plans to change the receiver because > > it works well for most cases. > > > > The problem must be still in the sender. > > "Must"? So you've proven that the ack-every-22 packets behavior > is due entirely to the sender? Just saying the the kernel was tested in a very wide range of very wide range of workloads and environments and there are no known TCP issues. Also the test that John wanted to diable has been in Linux practically forever (irc dates back to Eric Schenk's work in 2.0) And other kernels talking to it get ok performance, all the problems only started with the TSO changes in 2.6.9rc. > > If you put 2.6.9-current on both ends and this makes things go smoothly > that is an important data point and nobody else is seeing the behavior > you are at the moment. > > Personally, all of my bets are on the 2.6.5 frankenstein kernel > as the culprit :-) Umm, the TCP stack is pretty vanilla 2.6.5. Ok, I ran it talking to a 2.6.9rc2bk11+instanto-oops-patchkit bandaided to avoid oops kernel with a tg3. Actually I tried to, with TSO on on the sender it doesn't finish the normal 10s netperf standard test even in 30s. Then the sender eventually crashed even with unit-at-a-time turned off. And the crash starts looking a bit less like a compiler issue. Does it really work for you? Part of the trace. It looks like the new kernel has really bad problems with acking. 22:45:06.065031 10.23.202.15.32777 > 10.23.202.31.32775: . ack 11585 win 7240 (DF) 22:45:06.065042 10.23.202.15.32777 > 10.23.202.31.32775: . ack 13033 win 7964 (DF) 22:45:06.065047 10.23.202.15.32777 > 10.23.202.31.32775: . ack 14481 win 8688 (DF) 22:45:06.065052 10.23.202.15.32777 > 10.23.202.31.32775: . ack 15929 win 9412 (DF) 22:45:06.065061 10.23.202.15.32777 > 10.23.202.31.32775: . ack 17377 win 10136 (DF) 22:45:06.065066 10.23.202.15.32777 > 10.23.202.31.32775: . ack 18825 win 10860 (DF) 22:45:06.065091 10.23.202.15.32777 > 10.23.202.31.32775: . ack 20273 win 11584 (DF) 22:45:06.065254 10.23.202.31.32775 > 10.23.202.15.32777: . 20273:21721(1448) ack 1 win 1460 (DF) 22:45:06.065317 10.23.202.15.32777 > 10.23.202.31.32775: . ack 21721 win 12308 (DF) 22:45:06.065322 10.23.202.31.32775 > 10.23.202.15.32777: . 21721:23169(1448) ack 1 win 1460 (DF) 22:45:06.065327 10.23.202.31.32775 > 10.23.202.15.32777: . 23169:24617(1448) ack 1 win 1460 (DF) 22:45:06.065331 10.23.202.31.32775 > 10.23.202.15.32777: . 24617:26065(1448) ack 1 win 1460 (DF) 22:45:06.065335 10.23.202.31.32775 > 10.23.202.15.32777: . 26065:27513(1448) ack 1 win 1460 (DF) 22:45:06.065339 10.23.202.31.32775 > 10.23.202.15.32777: P 27513:28961(1448) ack 1 win 1460 (DF) 22:45:06.065348 10.23.202.15.32777 > 10.23.202.31.32775: . ack 23169 win 13032 (DF) 22:45:06.065353 10.23.202.15.32777 > 10.23.202.31.32775: . ack 24617 win 13756 (DF) 22:45:06.065358 10.23.202.15.32777 > 10.23.202.31.32775: . ack 26065 win 14480 (DF) 22:45:06.065368 10.23.202.15.32777 > 10.23.202.31.32775: . ack 27513 win 15204 (DF) 22:45:06.065372 10.23.202.15.32777 > 10.23.202.31.32775: . ack 28961 win 15928 (DF) 22:45:06.065529 10.23.202.31.32775 > 10.23.202.15.32777: . 28961:30409(1448) ack 1 win 1460 (DF) 22:45:06.065534 10.23.202.31.32775 > 10.23.202.15.32777: . 30409:31857(1448) ack 1 win 1460 (DF) 22:45:06.065540 10.23.202.31.32775 > 10.23.202.15.32777: . 31857:33305(1448) ack 1 win 1460 (DF) 22:45:06.065577 10.23.202.31.32775 > 10.23.202.15.32777: . 33305:34753(1448) ack 1 win 1460 (DF) 22:45:06.065581 10.23.202.31.32775 > 10.23.202.15.32777: . 34753:36201(1448) ack 1 win 1460 (DF) 22:45:06.065585 10.23.202.31.32775 > 10.23.202.15.32777: P 36201:37649(1448) ack 1 win 1460 (DF) 22:45:06.065603 10.23.202.15.32777 > 10.23.202.31.32775: . ack 30409 win 16022 (DF) 22:45:06.065608 10.23.202.15.32777 > 10.23.202.31.32775: . ack 31857 win 16022 (DF) 22:45:06.065613 10.23.202.15.32777 > 10.23.202.31.32775: . ack 33305 win 16022 (DF) 22:45:06.065622 10.23.202.15.32777 > 10.23.202.31.32775: . ack 37649 win 16022 (DF) 22:45:06.065771 10.23.202.31.32775 > 10.23.202.15.32777: . 37649:39097(1448) ack 1 win 1460 (DF) 22:45:06.065778 10.23.202.31.32775 > 10.23.202.15.32777: . 39097:40545(1448) ack 1 win 1460 (DF) 22:45:06.065784 10.23.202.31.32775 > 10.23.202.15.32777: . 40545:41993(1448) ack 1 win 1460 (DF) 22:45:06.065847 10.23.202.31.32775 > 10.23.202.15.32777: . 41993:43441(1448) ack 1 win 1460 (DF) 22:45:06.065851 10.23.202.31.32775 > 10.23.202.15.32777: . 43441:44889(1448) ack 1 win 1460 (DF) 22:45:06.065855 10.23.202.31.32775 > 10.23.202.15.32777: . 44889:46337(1448) ack 1 win 1460 (DF) 22:45:06.065858 10.23.202.31.32775 > 10.23.202.15.32777: . 46337:47785(1448) ack 1 win 1460 (DF) 22:45:06.065862 10.23.202.31.32775 > 10.23.202.15.32777: . 47785:49233(1448) ack 1 win 1460 (DF) 22:45:06.065900 10.23.202.15.32777 > 10.23.202.31.32775: . ack 49233 win 16022 (DF) 22:45:06.066152 10.23.202.31.32775 > 10.23.202.15.32777: . 49233:50681(1448) ack 1 win 1460 (DF) 22:45:06.066159 10.23.202.31.32775 > 10.23.202.15.32777: . 50681:52129(1448) ack 1 win 1460 (DF) 22:45:06.066165 10.23.202.31.32775 > 10.23.202.15.32777: . 52129:53577(1448) ack 1 win 1460 (DF) 22:45:06.066172 10.23.202.31.32775 > 10.23.202.15.32777: . 53577:55025(1448) ack 1 win 1460 (DF) 22:45:06.066208 10.23.202.31.32775 > 10.23.202.15.32777: . 55025:56473(1448) ack 1 win 1460 (DF) 22:45:06.066212 10.23.202.31.32775 > 10.23.202.15.32777: . 56473:57921(1448) ack 1 win 1460 (DF) 22:45:06.066216 10.23.202.31.32775 > 10.23.202.15.32777: . 57921:59369(1448) ack 1 win 1460 (DF) 22:45:06.066219 10.23.202.31.32775 > 10.23.202.15.32777: P 59369:60817(1448) ack 1 win 1460 (DF) 22:45:06.066263 10.23.202.15.32777 > 10.23.202.31.32775: . ack 60817 win 16022 (DF) -Andi From jheffner@psc.edu Wed Sep 29 13:58:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 13:58:37 -0700 (PDT) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKwVnv011968 for ; Wed, 29 Sep 2004 13:58:31 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i8TKwHeX005011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Sep 2004 16:58:17 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8TKwGxS006370; Wed, 29 Sep 2004 16:58:16 -0400 (EDT) Date: Wed, 29 Sep 2004 16:58:16 -0400 (EDT) From: John Heffner To: Andi Kleen cc: "David S. Miller" , , , , , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: <20040929012757.5d0dff61.ak@suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer1.psc.edu X-Virus-Status: Clean X-archive-position: 9688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 519 Lines: 15 On Wed, 29 Sep 2004, Andi Kleen wrote: > I tried to re-test it but I didn't get very far because the kernel > with your patch crashes regularly during netperf. No serial console, > but the backtrace is {tcp_ack+877} {tcp_rcv_established+350} ... > Before that there are a few "retrans out leaked" messages. I just tried to re-create this situation, and I got the same problem. Latest bk tree with dave's 5 patches, gcc 3.3.4, uni-processor p4/e1000 to a slow-ish p3/sk98lin (dual-cpu but with maxcpus=1). -John From niv@us.ibm.com Wed Sep 29 13:59:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:00:01 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TKxuGB012308 for ; Wed, 29 Sep 2004 13:59:56 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8TKwwVR442338; Wed, 29 Sep 2004 16:58:58 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8TL0B9B175874; Wed, 29 Sep 2004 17:00:12 -0400 Message-ID: <415B220F.4040102@us.ibm.com> Date: Wed, 29 Sep 2004 13:58:55 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> <20040929132247.227fffcd.davem@davemloft.net> In-Reply-To: <20040929132247.227fffcd.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1700 Lines: 53 David S. Miller wrote: > Nivedita, it was you specifically who complained to me > when I used a seperate BK tree for networking changes > last month whilst Linus was away for 2 weeks. You said "complained" ? no, no, honestly, it was just a very polite inquiry :) :) > And I have to warn people if they think that the churn is fast > and the rate of change in the networking is high right now, you > have seen absolutely nothing yet. :-) yep, this is to some extent driving this, and things like picking up the tso patches where we needed to test prior to you checking them in. Sure, we'd benefit from having fewer trees to test, and since the -mm tree is already getting tested and consuming the hw resources, we'd have benefited from having the networking tree go into -mm. Hence my previous inquiry to see if you could go through -mm. If you're feeding to Linus immediately, then we could just as well test mainline. There is a need to have mainline stable, but that can be solved by stretching out the bk snapshots and increasing the number of rc releases so mainline releases are fairly stable (something Andrew Morton mentioned yesterday). That has been a separate ongoing discussion among a lot of people. Your point about there being a lot of other stuff in -mm and it not being stable is taken, and it would be nice to have a networking contained tree. Which brings us to having your interim bk tree available to test - which would be fine with me :) What we're setting up is throwing the nightly release onto 2 big boxes and running some heavy duty networking stress tests. All in the spirit of wanting to be helpful, honestly :). Any suggestions welcome.. thanks, Nivedita From davem@davemloft.net Wed Sep 29 14:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:01:22 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TL1G6b012655 for ; Wed, 29 Sep 2004 14:01:16 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CClYe-0002B0-00; Wed, 29 Sep 2004 14:00:16 -0700 Date: Wed, 29 Sep 2004 14:00:16 -0700 From: "David S. Miller" To: John Heffner Cc: ak@suse.de, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929140016.7ffa4e8b.davem@davemloft.net> In-Reply-To: References: <20040928223344.GC2975@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 969 Lines: 28 On Tue, 28 Sep 2004 23:27:21 -0400 (EDT) John Heffner wrote: > On Wed, 29 Sep 2004, Andi Kleen wrote: > > > I'm afraid I must report it's still not completely solved for me yet. > > 10s netperf with TSO on with your patches gives now ~10MB/s less than > > with TSO off (57 vs 67). It's better than before, but not really > > fixed yet. > > > > Looking at my tcpdumps and comparing TSO on/off I see a quite > > strange effect. It only acks on every ~25th packet with TSO off > > but every ~16th packet with TSO on. > > > > Receiver is a 2.6.5 kernel, it's weird that it violates the > > ack every two MSS rule. > > Does this help? I think you hit the jackpot John... or at least you're on the right trail. It seems I'll have to do some send buffer liberation when we partially ACK TSO frames. Since that isn't happening currently, this window advancing test never passes until the full TSO frame is freed up at the sender side. Patch coming... From niv@us.ibm.com Wed Sep 29 14:12:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:12:29 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLCNkq013135 for ; Wed, 29 Sep 2004 14:12:24 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8TLASvx702582; Wed, 29 Sep 2004 17:10:28 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8TLBeeR012486; Wed, 29 Sep 2004 17:11:41 -0400 Message-ID: <415B24C0.2020208@us.ibm.com> Date: Wed, 29 Sep 2004 14:10:24 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Heffner CC: Andi Kleen , "David S. Miller" , herbert@gondor.apana.org.au, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 774 Lines: 25 John Heffner wrote: > On Wed, 29 Sep 2004, Andi Kleen wrote: > > >>I tried to re-test it but I didn't get very far because the kernel >>with your patch crashes regularly during netperf. No serial console, >>but the backtrace is {tcp_ack+877} {tcp_rcv_established+350} ... >>Before that there are a few "retrans out leaked" messages. > > > I just tried to re-create this situation, and I got the same problem. > Latest bk tree with dave's 5 patches, gcc 3.3.4, uni-processor p4/e1000 to > a slow-ish p3/sk98lin (dual-cpu but with maxcpus=1). I just crashed too, no backtrace. netperf tcp stream test, and was on bk14 + dave's 5 patches, p4/e1000 -> Intel Pentium M proc (1.7GHz). Going to repeat on slower SMPs with serial console, get more info.. thanks, Nivedita From gerrit@us.ibm.com Wed Sep 29 14:13:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:13:35 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLDSJ6013352 for ; Wed, 29 Sep 2004 14:13:28 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8TLCXsB432254; Wed, 29 Sep 2004 17:12:33 -0400 Received: from w-gerrit.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8TLCVP0123290; Wed, 29 Sep 2004 15:12:32 -0600 Received: from localhost ([127.0.0.1] helo=us.ibm.com ident=gerrit) by w-gerrit.beaverton.ibm.com with esmtp (Exim 3.36 #1 (Debian)) id 1CClkI-0001m2-00; Wed, 29 Sep 2004 14:12:18 -0700 To: "David S. Miller" cc: Nivedita Singhvi , shemminger@osdl.org, netdev@oss.sgi.com Reply-To: Gerrit Huizenga From: Gerrit Huizenga Subject: Re: Please route new work through -mm tree? In-reply-to: Your message of Wed, 29 Sep 2004 13:22:47 PDT. <20040929132247.227fffcd.davem@davemloft.net> Date: Wed, 29 Sep 2004 14:12:18 -0700 Message-Id: X-archive-position: 9692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gh@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1494 Lines: 38 On Wed, 29 Sep 2004 13:22:47 PDT, "David S. Miller" wrote: > On Wed, 29 Sep 2004 11:13:55 -0700 > Nivedita Singhvi wrote: > > > I was going to suggest a separate bk tree or something that would > > hold this stuff till it stabilized, before it needed > > to go into mainline. > > Nivedita, it was you specifically who complained to me > when I used a seperate BK tree for networking changes > last month whilst Linus was away for 2 weeks. You said > that this gave IBM too many trees to work from, so I told > you that what I was doing was a temporary thing until Linus > came back from his trip. > > Now you're suggesting that I specifically do what you asked > me not to do a month ago. > > So figure out what you really want. > > And I have to warn people if they think that the churn is fast > and the rate of change in the networking is high right now, you > have seen absolutely nothing yet. :-) Hi Dave, having a bk tree which akpm can merge into his would mean that all of our standard testing would get run over networking changes as well as everything else. We typically run some pretty exhaustive tests on a small number of trees. We try to focus on -rc trees from Linus and the -mm trees. As a result, networking testing (by us) is done really late in the cycle compared to your rate of change in pushing to Linus. So, ideally, if you had your own tree published in such a way that akpm could pull in, we'd probably have the best of all worlds. gerrit From niv@us.ibm.com Wed Sep 29 14:17:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:17:26 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLHKtf013872 for ; Wed, 29 Sep 2004 14:17:21 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8TLH3VR407242; Wed, 29 Sep 2004 17:17:03 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8TLIB9B095378; Wed, 29 Sep 2004 17:18:17 -0400 Message-ID: <415B2647.8080803@us.ibm.com> Date: Wed, 29 Sep 2004 14:16:55 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: John Heffner , ak@suse.de, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK References: <20040928223344.GC2975@wotan.suse.de> <20040929140016.7ffa4e8b.davem@davemloft.net> In-Reply-To: <20040929140016.7ffa4e8b.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 710 Lines: 27 David S. Miller wrote: > I think you hit the jackpot John... or at least you're > on the right trail. > > It seems I'll have to do some send buffer liberation when > we partially ACK TSO frames. Since that isn't happening > currently, this window advancing test never passes until > the full TSO frame is freed up at the sender side. > > Patch coming... That was my point to Herbert, Dave - that we can't rely on Nagle - either we're triggering too early and not utilizing TSO MTU or we're triggering too late (waiting for the full TSO frame) depending on whether we use standard or TSO mss.. We need some heuristic to do partial sends under TSO. Is that what you are addressing? thanks, Nivedita From davem@davemloft.net Wed Sep 29 14:18:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:18:39 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLIYen014194 for ; Wed, 29 Sep 2004 14:18:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CClpL-0002CT-00; Wed, 29 Sep 2004 14:17:31 -0700 Date: Wed, 29 Sep 2004 14:17:31 -0700 From: "David S. Miller" To: Andi Kleen Cc: jheffner@psc.edu, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929141731.2685e561.davem@davemloft.net> In-Reply-To: <20040929225635.061f2405.ak@suse.de> References: <20040928223344.GC2975@wotan.suse.de> <20040929090103.GB18671@wotan.suse.de> <20040929125644.40358b42.davem@davemloft.net> <20040929225635.061f2405.ak@suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 639 Lines: 16 On Wed, 29 Sep 2004 22:56:35 +0200 Andi Kleen wrote: > Also the test that John wanted to diable has been in Linux practically > forever (irc dates back to Eric Schenk's work in 2.0) Yes, but it could prove something about either the sender or the receiver, namely that the receive window is not openning up fast enough for some reason, thus delaying the ACKs. > Part of the trace. It looks like the new kernel has really > bad problems with acking. It looks, again, like the receiver's window is not openning up fast enough, which controls ACK response decisions, and that is what jheffner's patch is supposed to verify. From slblake@petri-meat.com Wed Sep 29 14:21:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:21:10 -0700 (PDT) Received: from server26.totalchoicehosting.com (server26.totalchoicehosting.com [209.152.177.32]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLL3XX014548 for ; Wed, 29 Sep 2004 14:21:04 -0700 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1CClsV-0000yH-L2; Wed, 29 Sep 2004 17:20:47 -0400 Subject: Re: Move fib_alias out of fib_hash.c From: Steven Blake To: "David S. Miller" Cc: Robert Olsson , netdev@oss.sgi.com In-Reply-To: <20040929125359.12a00ba7.davem@davemloft.net> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> Content-Type: text/plain Message-Id: <1096492842.2344.57.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 29 Sep 2004 17:20:43 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 9695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: slblake@petri-meat.com Precedence: bulk X-list: netdev Content-Length: 1318 Lines: 38 On Wed, 2004-09-29 at 15:53, David S. Miller wrote: > On Wed, 29 Sep 2004 17:20:45 +0200 > Robert Olsson wrote: > > > we can interface new lookups cleanly. For a trie something like: > > You are already making a critical logic error. > > You cannot find the longest matching prefix and just use that. > > Rather, you must iterate through all matching prefixes in the > table from longest to shortest, trying fib_semantic_match() on > each one until it says OK. > > If you don't do that, then you're not providing the same behavior > of the current code. If next hops go down, you have to try the > next longest matching prefix and so on and so forth. I'm not criticizing the current design, but it is very typical of routers to put the burden of fixing up the FIB in the event of a next-hop state change on the routing daemon, and not the dataplane. Which is one reason why having a FIB datastructure that can be updated very efficiently is important. > It can also > be the case that the longest matching prefix entry has no matching > TOS key, whereas a shorter prefix does. No routing protocols are distributing TOS-specific routes, and there is no prospect of that feature ever coming back. Why pay the cost of matching TOS on every packet forwarded? Regards, // Steve From davem@davemloft.net Wed Sep 29 14:23:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:23:57 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLNroL014921 for ; Wed, 29 Sep 2004 14:23:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCluW-0002D4-00; Wed, 29 Sep 2004 14:22:52 -0700 Date: Wed, 29 Sep 2004 14:22:52 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: jheffner@psc.edu, ak@suse.de, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929142252.393a976d.davem@davemloft.net> In-Reply-To: <415B2647.8080803@us.ibm.com> References: <20040928223344.GC2975@wotan.suse.de> <20040929140016.7ffa4e8b.davem@davemloft.net> <415B2647.8080803@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1240 Lines: 35 On Wed, 29 Sep 2004 14:16:55 -0700 Nivedita Singhvi wrote: > That was my point to Herbert, Dave - that we can't > rely on Nagle - either we're triggering too early > and not utilizing TSO MTU or we're triggering too > late (waiting for the full TSO frame) depending > on whether we use standard or TSO mss.. > > We need some heuristic to do partial sends under > TSO. Is that what you are addressing? It's partial "ACK" of a TSO frame that cause congestion window and socket buffer allocation issues. We handle partial sends by just limiting the TSO mss to never be larger than the congestion window. We need to handle ACK'ing issues by: 1) Keeping track of "real mss" packet ACKs of TSO frames. This is implemented currently by advancing the sequence number of the TSO SKB in the retransmit queue. 2) What I'm working on now, which is to liberate send buffer socket space when we do partial acking in #1 I need to see the crash folks are seeing. Does it only happen when you have tcpdump attached to the interface running the test? Does it happen only on the sender or the receiver in the netperf test? Those would be a good clues, indicating some SKB sharing bug I've created or similar. Thanks. From davem@davemloft.net Wed Sep 29 14:24:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:25:04 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLOx3M015252 for ; Wed, 29 Sep 2004 14:24:59 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CClvd-0002DS-00; Wed, 29 Sep 2004 14:24:01 -0700 Date: Wed, 29 Sep 2004 14:24:01 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? Message-Id: <20040929142401.664d8fd7.davem@davemloft.net> In-Reply-To: <415B220F.4040102@us.ibm.com> References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> <20040929132247.227fffcd.davem@davemloft.net> <415B220F.4040102@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 571 Lines: 17 On Wed, 29 Sep 2004 13:58:55 -0700 Nivedita Singhvi wrote: > Which brings us to having your interim bk tree > available to test - which would be fine with me :) There are people who know the location of it and are pulling from it all the time :-) bk://kernel.bkbits.net/davem/net-2.6 I know for a fact that people such as Herbert Xu ping that tree multiple times a day. When I don't have any networking work present, that tree is simply deleted. So if you pull and get a URL error, that just means no changes pending and Linus has everything. :-) From davem@davemloft.net Wed Sep 29 14:28:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:28:54 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLSnCk015633 for ; Wed, 29 Sep 2004 14:28:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CClzK-0002Dr-00; Wed, 29 Sep 2004 14:27:50 -0700 Date: Wed, 29 Sep 2004 14:27:50 -0700 From: "David S. Miller" To: Steven Blake Cc: Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c Message-Id: <20040929142750.27b35952.davem@davemloft.net> In-Reply-To: <1096492842.2344.57.camel@localhost.localdomain> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> <1096492842.2344.57.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 535 Lines: 14 On Wed, 29 Sep 2004 17:20:43 -0400 Steven Blake wrote: > > It can also > > be the case that the longest matching prefix entry has no matching > > TOS key, whereas a shorter prefix does. > > No routing protocols are distributing TOS-specific routes, and there is > no prospect of that feature ever coming back. Why pay the cost of > matching TOS on every packet forwarded? Because once we add functionality to the kernel we can't simply rip it out. People do use TOS routing, via static routes or similar. From Robert.Olsson@data.slu.se Wed Sep 29 14:31:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:31:07 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLV2pu016000 for ; Wed, 29 Sep 2004 14:31:02 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8TLUmY2016290; Wed, 29 Sep 2004 23:30:48 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 4F7C990265; Wed, 29 Sep 2004 23:30:48 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16731.10632.290408.265135@robur.slu.se> Date: Wed, 29 Sep 2004 23:30:48 +0200 To: "David S. Miller" Cc: Robert Olsson , netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c In-Reply-To: <20040929125359.12a00ba7.davem@davemloft.net> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1126 Lines: 32 David S. Miller writes: > You cannot find the longest matching prefix and just use that. > > Rather, you must iterate through all matching prefixes in the > table from longest to shortest, trying fib_semantic_match() on > each one until it says OK. You're right we have to match semantics then first after that return longest prefix to comply w. current matching. > This makes using a new algorithm very non-trivial. Yes and will take resources compared to simple longest prefix. > Probably what you should do is keep an array on the function > stack, recording shorter prefix entries you see on your walk > down to the longest matching prefix. Then you process the array > one entry at a time back to the root, trying fib_semantic_match() > on each one. We have backtracking as we search to leaves and as leaves does not always has a matching prefix. So we have to look into how semantics match can be done here instead and backtrack until we got a semantics match. Was about to test w. ipv6 to start with due to ipv4 complexity. Anyway ipv4 fib-code is cleaner now. Cheers. --ro From jgarzik@pobox.com Wed Sep 29 14:38:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:38:20 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLcDl9016479 for ; Wed, 29 Sep 2004 14:38:14 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCm9A-0001di-Pr; Wed, 29 Sep 2004 22:38:00 +0100 Message-ID: <415B2B2B.5050904@pobox.com> Date: Wed, 29 Sep 2004 17:37:47 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: Nivedita Singhvi , shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> <20040929132247.227fffcd.davem@davemloft.net> <415B220F.4040102@us.ibm.com> <20040929142401.664d8fd7.davem@davemloft.net> In-Reply-To: <20040929142401.664d8fd7.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 478 Lines: 15 David S. Miller wrote: > When I don't have any networking work present, that tree is > simply deleted. So if you pull and get a URL error, that just > means no changes pending and Linus has everything. :-) No need to delete it. When Linus merges your stuff, net-2.6 tree becomes equivalent to linux-2.6 tree. When you next create and push local changes, a few days later, it is guaranteed that there will be no conflicts between your local and bkbits.net trees. Jeff From ak@suse.de Wed Sep 29 14:44:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:44:14 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLi8d7017346 for ; Wed, 29 Sep 2004 14:44:08 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D7865C9EAB1; Wed, 29 Sep 2004 23:43:50 +0200 (CEST) Date: Wed, 29 Sep 2004 23:43:50 +0200 From: Andi Kleen To: "David S. Miller" Cc: Nivedita Singhvi , jheffner@psc.edu, ak@suse.de, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040929214350.GA26714@wotan.suse.de> References: <20040928223344.GC2975@wotan.suse.de> <20040929140016.7ffa4e8b.davem@davemloft.net> <415B2647.8080803@us.ibm.com> <20040929142252.393a976d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929142252.393a976d.davem@davemloft.net> X-archive-position: 9702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 345 Lines: 11 > I need to see the crash folks are seeing. Does it only happen > when you have tcpdump attached to the interface running the > test? Does it happen only on the sender or the receiver It happens without tcpdump too. > in the netperf test? Those would be a good clues, indicating The sender first gets slow, then eventually crashes. -Andi From Robert.Olsson@data.slu.se Wed Sep 29 14:44:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:44:09 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLi3Kf017348 for ; Wed, 29 Sep 2004 14:44:04 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i8TLhnY2020995; Wed, 29 Sep 2004 23:43:49 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 5896290265; Wed, 29 Sep 2004 23:43:49 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16731.11413.331685.70763@robur.slu.se> Date: Wed, 29 Sep 2004 23:43:49 +0200 To: Steven Blake Cc: "David S. Miller" , Robert Olsson , netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c In-Reply-To: <1096492842.2344.57.camel@localhost.localdomain> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> <1096492842.2344.57.camel@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 9701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 374 Lines: 12 Steven Blake writes: > No routing protocols are distributing TOS-specific routes, and there is > no prospect of that feature ever coming back. Why pay the cost of > matching TOS on every packet forwarded? Well you may be right but with a pluggable lookup algo we could choose between TOS-capable/complex and more lightweight and speedy things. Cheers. --ro From davem@davemloft.net Wed Sep 29 14:45:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:45:32 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLjP1L017768 for ; Wed, 29 Sep 2004 14:45:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCmFH-0002Fm-00; Wed, 29 Sep 2004 14:44:19 -0700 Date: Wed, 29 Sep 2004 14:44:19 -0700 From: "David S. Miller" To: Jeff Garzik Cc: niv@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? Message-Id: <20040929144419.6b455343.davem@davemloft.net> In-Reply-To: <415B2B2B.5050904@pobox.com> References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> <20040929132247.227fffcd.davem@davemloft.net> <415B220F.4040102@us.ibm.com> <20040929142401.664d8fd7.davem@davemloft.net> <415B2B2B.5050904@pobox.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 619 Lines: 16 On Wed, 29 Sep 2004 17:37:47 -0400 Jeff Garzik wrote: > David S. Miller wrote: > > When I don't have any networking work present, that tree is > > simply deleted. So if you pull and get a URL error, that just > > means no changes pending and Linus has everything. :-) > > No need to delete it. When Linus merges your stuff, net-2.6 tree > becomes equivalent to linux-2.6 tree. > > When you next create and push local changes, a few days later, it is > guaranteed that there will be no conflicts between your local and > bkbits.net trees. Ok, works for me. I'll try to do this from now on. From jheffner@psc.edu Wed Sep 29 14:51:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:51:45 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLpdcB018690 for ; Wed, 29 Sep 2004 14:51:39 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8TLpNcN024020 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Sep 2004 17:51:23 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8TLpMxS006831; Wed, 29 Sep 2004 17:51:23 -0400 (EDT) Date: Wed, 29 Sep 2004 17:51:22 -0400 (EDT) From: John Heffner To: Andi Kleen cc: "David S. Miller" , Nivedita Singhvi , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: <20040929214350.GA26714@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 945 Lines: 26 On Wed, 29 Sep 2004, Andi Kleen wrote: > > I need to see the crash folks are seeing. Does it only happen > > when you have tcpdump attached to the interface running the > > test? Does it happen only on the sender or the receiver > > It happens without tcpdump too. Ditto. > > in the netperf test? Those would be a good clues, indicating > > The sender first gets slow, then eventually crashes. I managed to get a tcpdump of one flow. I accidentally deleted it, but from memory what I saw was it ramped up to large virtual segments, then got a partial ack for it (all but the last real segment -- delayed ack here) then later after the full ack got back sent one small segment. This segment was acked, but it never seemed to recognize this ack and repeatedly retransmitted it after timeouts. (Generating the retrans_out leaked messages when the d-sacks came back.) I can't conveniently get a backtrace of the crash right now. -John From davem@davemloft.net Wed Sep 29 14:52:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:52:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLqUXO018945 for ; Wed, 29 Sep 2004 14:52:30 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCmLb-0002GL-00; Wed, 29 Sep 2004 14:50:51 -0700 Date: Wed, 29 Sep 2004 14:50:50 -0700 From: "David S. Miller" To: Nivedita Singhvi Cc: jheffner@psc.edu, ak@suse.de, herbert@gondor.apana.org.au, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929145050.71afa1ac.davem@davemloft.net> In-Reply-To: <415B24C0.2020208@us.ibm.com> References: <415B24C0.2020208@us.ibm.com> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 514 Lines: 13 On Wed, 29 Sep 2004 14:10:24 -0700 Nivedita Singhvi wrote: > I just crashed too, no backtrace. netperf tcp stream test, > and was on bk14 + dave's 5 patches, p4/e1000 -> Intel Pentium > M proc (1.7GHz). Going to repeat on slower SMPs with serial > console, get more info.. I can reproduce this now, it has to do with some weird combinations of packet loss and SACK'ing. It's one of the BUG_ON() assertions triggering in tcp_tso_acked() as I suspected in Andi's first report. Working on a fix. From davem@davemloft.net Wed Sep 29 14:53:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:54:11 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLrwiE019419 for ; Wed, 29 Sep 2004 14:53:58 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCmNS-0002Gi-00; Wed, 29 Sep 2004 14:52:46 -0700 Date: Wed, 29 Sep 2004 14:52:46 -0700 From: "David S. Miller" To: John Heffner Cc: ak@suse.de, niv@us.ibm.com, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929145246.6633187c.davem@davemloft.net> In-Reply-To: References: <20040929214350.GA26714@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 704 Lines: 15 On Wed, 29 Sep 2004 17:51:22 -0400 (EDT) John Heffner wrote: > I managed to get a tcpdump of one flow. I accidentally deleted it, but > from memory what I saw was it ramped up to large virtual segments, then > got a partial ack for it (all but the last real segment -- delayed ack > here) then later after the full ack got back sent one small segment. > This segment was acked, but it never seemed to recognize this ack and > repeatedly retransmitted it after timeouts. (Generating the retrans_out > leaked messages when the d-sacks came back.) > > I can't conveniently get a backtrace of the crash right now. I can get one now, thanks for the trace description it's a good clue. From ak@suse.de Wed Sep 29 14:58:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 14:58:43 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TLwcj2019820 for ; Wed, 29 Sep 2004 14:58:38 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 23DB9C9EB35; Wed, 29 Sep 2004 23:56:14 +0200 (CEST) Date: Wed, 29 Sep 2004 23:56:13 +0200 From: Andi Kleen To: "David S. Miller" Cc: Nivedita Singhvi , jheffner@psc.edu, ak@suse.de, herbert@gondor.apana.org.au, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040929215613.GC26714@wotan.suse.de> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929145050.71afa1ac.davem@davemloft.net> X-archive-position: 9707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 2819 Lines: 57 On Wed, Sep 29, 2004 at 02:50:50PM -0700, David S. Miller wrote: > On Wed, 29 Sep 2004 14:10:24 -0700 > Nivedita Singhvi wrote: > > > I just crashed too, no backtrace. netperf tcp stream test, > > and was on bk14 + dave's 5 patches, p4/e1000 -> Intel Pentium > > M proc (1.7GHz). Going to repeat on slower SMPs with serial > > console, get more info.. > > I can reproduce this now, it has to do with some weird combinations > of packet loss and SACK'ing. It's one of the BUG_ON() assertions > triggering in tcp_tso_acked() as I suspected in Andi's first report. > > Working on a fix. Yes, it's a BUG. Here's a full oops I found from yesterday in some log. 2427 is BUG_ON(scb->tso_factor == 0); ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at tcp_input:2427 invalid operand: 0000 [1] SMP CPU 0 Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.9-rc2-bk11 RIP: 0010:[] {tcp_ack+877} RSP: 0018:ffffffff8053e128 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 000001007df44a18 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000001007dd884f0 RDI: 000000004d083811 RBP: 000001007df44700 R08: 00000000000005a8 R09: 000000000000000c R10: ffffffff8053e138 R11: 0000000000000004 R12: 0000000000000000 R13: 0000000000000002 R14: 000001007df447b8 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffffffff805bd280(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000522000 CR3: 0000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, threadinfo ffffffff805c0000, task ffffffff8047c280) Stack: 0000000c0000000c 4d07f4314d083811 0000010000000001 000001007df44a18 000001007da6a034 000001007d64a080 000001007df44700 0000000000000020 0000000000000000 ffffffff8039a2be Call Trace: {tcp_rcv_established+350} {ret_from_intr+0} {tcp_v4_do_rcv+63} {tcp_v4_rcv+1659} {e1000_intr+1936} {timer_interrupt+1045} {ip_local_deliver+193} {ip_rcv+910} {netif_receive_skb+428} {process_backlog+150} {net_rx_action+132} {__do_softirq+113} {do_softirq+53} {do_IRQ+335} {ret_from_intr+0} {mwait_idle+86} {cpu_idle+29} {start_kernel+485} {_sinittext+480} Code: 0f 0b 30 b8 45 80 ff ff ff ff 7b 09 8b 56 14 39 56 10 78 0c RIP {tcp_ack+877} RSP <0>Kernel panic - not syncing: Aiee, killing interrupt handler! From ak@suse.de Wed Sep 29 15:13:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 15:13:44 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TMDcuB025889 for ; Wed, 29 Sep 2004 15:13:39 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id A8616C9D041; Thu, 30 Sep 2004 00:09:27 +0200 (CEST) Date: Thu, 30 Sep 2004 00:09:26 +0200 From: Andi Kleen To: "David S. Miller" Cc: Steven Blake , Robert.Olsson@data.slu.se, netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c Message-ID: <20040929220926.GE26714@wotan.suse.de> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> <1096492842.2344.57.camel@localhost.localdomain> <20040929142750.27b35952.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929142750.27b35952.davem@davemloft.net> X-archive-position: 9708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 744 Lines: 20 On Wed, Sep 29, 2004 at 02:27:50PM -0700, David S. Miller wrote: > On Wed, 29 Sep 2004 17:20:43 -0400 > Steven Blake wrote: > > > > It can also > > > be the case that the longest matching prefix entry has no matching > > > TOS key, whereas a shorter prefix does. > > > > No routing protocols are distributing TOS-specific routes, and there is > > no prospect of that feature ever coming back. Why pay the cost of > > matching TOS on every packet forwarded? > > Because once we add functionality to the kernel we can't simply > rip it out. People do use TOS routing, via static routes or > similar. I'm not so sure anybody uses it really. How about adding a printk for it and seeing if anybody complains? -Andi From greearb@candelatech.com Wed Sep 29 15:25:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 15:25:14 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TMP7MT026735 for ; Wed, 29 Sep 2004 15:25:07 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8TMT4LH029077; Wed, 29 Sep 2004 15:29:05 -0700 Message-ID: <415B3637.9060700@candelatech.com> Date: Wed, 29 Sep 2004 15:24:55 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> <1096492842.2344.57.camel@localhost.localdomain> <20040929142750.27b35952.davem@davemloft.net> <20040929220926.GE26714@wotan.suse.de> In-Reply-To: <20040929220926.GE26714@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 745 Lines: 24 Andi Kleen wrote: > On Wed, Sep 29, 2004 at 02:27:50PM -0700, David S. Miller wrote: >>Because once we add functionality to the kernel we can't simply >>rip it out. People do use TOS routing, via static routes or >>similar. > > > I'm not so sure anybody uses it really. How about adding a printk for it > and seeing if anybody complains? I don't think you should remove existing features in the middle of a stable release cycle. If you want to have a compile option, that defaults to off, allows some new algorithm, then that sounds more reasonable... And I don't think the majority of people would see the printk untill way too late. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Wed Sep 29 15:30:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 15:30:35 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TMUSpu027126 for ; Wed, 29 Sep 2004 15:30:29 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CCmxk-0004ee-2b; Wed, 29 Sep 2004 23:30:16 +0100 Message-ID: <415B376B.9090704@pobox.com> Date: Wed, 29 Sep 2004 18:30:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: niv@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: Please route new work through -mm tree? References: <1096481023.8636.7.camel@localhost.localdomain> <415AFB63.7010107@us.ibm.com> <20040929132247.227fffcd.davem@davemloft.net> <415B220F.4040102@us.ibm.com> <20040929142401.664d8fd7.davem@davemloft.net> <415B2B2B.5050904@pobox.com> <20040929144419.6b455343.davem@davemloft.net> In-Reply-To: <20040929144419.6b455343.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 777 Lines: 28 David S. Miller wrote: > On Wed, 29 Sep 2004 17:37:47 -0400 > Jeff Garzik wrote: > > >>David S. Miller wrote: >> >>>When I don't have any networking work present, that tree is >>>simply deleted. So if you pull and get a URL error, that just >>>means no changes pending and Linus has everything. :-) >> >>No need to delete it. When Linus merges your stuff, net-2.6 tree >>becomes equivalent to linux-2.6 tree. >> >>When you next create and push local changes, a few days later, it is >>guaranteed that there will be no conflicts between your local and >>bkbits.net trees. > > > Ok, works for me. I'll try to do this from now on. Cool. FWIW the only time you should need to blow away and reclone a tree is when you reorder changesets.. Jeff From jheffner@psc.edu Wed Sep 29 15:39:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 15:39:13 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TMd7Bs027565 for ; Wed, 29 Sep 2004 15:39:08 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8TMcqcN024713 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Sep 2004 18:38:52 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8TMcqxS007089; Wed, 29 Sep 2004 18:38:52 -0400 (EDT) Date: Wed, 29 Sep 2004 18:38:52 -0400 (EDT) From: John Heffner To: cc: Subject: TSO and MSS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 987 Lines: 26 While playing with TSO I noticed that two machines on the same ethernet with dissimilar MTUs don't work with TSO enabled. One could argue the incorrecness of this situation, but I think it's still important. Looks like the segment size is only set from the path MTU, and the TCP MSS is ignored. Here's the offending code. net/ipv4/ip_output.c:ip_queue_xmit(): mtu = dst_pmtu(&rt->u.dst); if (skb->len > mtu && (sk->sk_route_caps & NETIF_F_TSO)) { unsigned int hlen; /* Hack zone: all this must be done by TCP. */ hlen = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); skb_shinfo(skb)->tso_size = mtu - hlen; skb_shinfo(skb)->tso_segs = (skb->len - hlen + skb_shinfo(skb)->tso_size - 1)/ skb_shinfo(skb)->tso_size - 1; } Does the "Hack zone" comment indicate this case has already been considered? Thanks, -John From davem@davemloft.net Wed Sep 29 15:47:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 15:47:51 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TMljYw028023 for ; Wed, 29 Sep 2004 15:47:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCnDh-0002Lz-00; Wed, 29 Sep 2004 15:46:45 -0700 Date: Wed, 29 Sep 2004 15:46:45 -0700 From: "David S. Miller" To: John Heffner Cc: netdev@oss.sgi.com Subject: Re: TSO and MSS Message-Id: <20040929154645.4e8987d2.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1344 Lines: 31 On Wed, 29 Sep 2004 18:38:52 -0400 (EDT) John Heffner wrote: > net/ipv4/ip_output.c:ip_queue_xmit(): > > mtu = dst_pmtu(&rt->u.dst); > if (skb->len > mtu && (sk->sk_route_caps & NETIF_F_TSO)) { > unsigned int hlen; > > /* Hack zone: all this must be done by TCP. */ > hlen = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); > skb_shinfo(skb)->tso_size = mtu - hlen; > skb_shinfo(skb)->tso_segs = > (skb->len - hlen + skb_shinfo(skb)->tso_size - 1)/ > skb_shinfo(skb)->tso_size - 1; > } > > Does the "Hack zone" comment indicate this case has already been > considered? The "Hack zone" comment is saying that we should be doing this work in tcp_transmit_skb() but cannot because ip_queue_xmit() is where a route is hooked up if sk->sk_dst_cache is NULL. If you are on ethernet using different MTU's, shouldn't you be getting ICMP messages back when trying to communicate with that host which will decrease the PMTU of the path? TCP's MSS is determined in terms of this, so I can't see what the issue is. Note I would like to move this "Hack zone" code up into tcp_transmit_skb() for another reason, it would make the TSO stuff in tcp_skb_cb[] redundant. From jheffner@psc.edu Wed Sep 29 15:51:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 15:51:57 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TMpqSt028376 for ; Wed, 29 Sep 2004 15:51:52 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8TMpbcN024915 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Sep 2004 18:51:37 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8TMpaxS007175; Wed, 29 Sep 2004 18:51:36 -0400 (EDT) Date: Wed, 29 Sep 2004 18:51:36 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Subject: Re: TSO and MSS In-Reply-To: <20040929154645.4e8987d2.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 632 Lines: 16 On Wed, 29 Sep 2004, David S. Miller wrote: > If you are on ethernet using different MTU's, shouldn't you be > getting ICMP messages back when trying to communicate with that > host which will decrease the PMTU of the path? TCP's MSS is > determined in terms of this, so I can't see what the issue is. Unfortunately no. If there's no router in between, the frame gets smashed and no ICMP is generated. Proper communication relies on honoring the MSS value for directly connected machines. Regardless, it is probably a good idea to honor the MSS value anyway, because I think you're violating the TCP spec otherwise. -John From davem@davemloft.net Wed Sep 29 16:31:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 16:32:04 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TNVpEw000300 for ; Wed, 29 Sep 2004 16:31:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCnsy-0002Qo-00; Wed, 29 Sep 2004 16:29:24 -0700 Date: Wed, 29 Sep 2004 16:29:23 -0700 From: "David S. Miller" To: Andi Kleen Cc: niv@us.ibm.com, jheffner@psc.edu, ak@suse.de, herbert@gondor.apana.org.au, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929162923.796d142e.davem@davemloft.net> In-Reply-To: <20040929215613.GC26714@wotan.suse.de> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 4784 Lines: 145 Ok, found the bug. This bug was in the existing code and the assertions in the new code was merely discovering it. What happens is that we set TCP_SKB_CB(skb)->tso_factor, for tcp_snd_test() or similar, for example. But this packet does not go out, and tcp_sendmsg() or tcp_sendpages() tacks more data onto the tail of the SKB without updating TCP_SKB_CB(skb)->tso_factor. Simply setting the tso_factor to zero in these cases gets it recalculated, and reduces the number of tso_factor recalculations. This works because by definition these SKBs have not been sent for the first time yet. We never tack data onto the end of retransmitted SKBs. And because of that invariante there will be a tcp_set_skb_tso_factor() call before it gets to tcp_transmit_skb() (which will BUG otherwise). I've also audited other spots that don't update the tso_factor when they should, tcp_trim_head() was another such spot. Finally, I added an assertion to retransmit queue collapsing to make sure we don't collapse SKBs with non-1 TSO factors. And the Solaris FIN workaround pskb_trim() needs to reset the TSO factor as well. Let me know if this cures the issue, and if it does we can move back to Andi's performance issue and the MSS stuff John Heffner just discovered. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/29 16:09:18-07:00 davem@nuts.davemloft.net # [TCP]: Fix inaccuracies in tso_factor settings. # # 1) If tcp_{sendmsg,sendpage} tacks on more data to an # existing SKB, this can make tso_factor inaccurate. # Invalidate it, which forces it to be recalculated, # by simply setting it to zero. # 2) __tcp_trim_head() changes skb->len thus we need # to recalculate tso_factor # 3) BUG check that tcp_retrans_try_collapse() does not # try to collapse packets with non-1 tso_factor # 4) The Solaris FIN workaround in tcp_retransmit_skb() # changes packet size, need to fixup tso_factor # # Signed-off-by: David S. Miller # # net/ipv4/tcp_output.c # 2004/09/29 16:06:54-07:00 davem@nuts.davemloft.net +15 -5 # [TCP]: Fix inaccuracies in tso_factor settings. # # net/ipv4/tcp.c # 2004/09/29 16:06:54-07:00 davem@nuts.davemloft.net +2 -0 # [TCP]: Fix inaccuracies in tso_factor settings. # diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c 2004-09-29 16:09:42 -07:00 +++ b/net/ipv4/tcp.c 2004-09-29 16:09:42 -07:00 @@ -691,6 +691,7 @@ skb->ip_summed = CHECKSUM_HW; tp->write_seq += copy; TCP_SKB_CB(skb)->end_seq += copy; + TCP_SKB_CB(skb)->tso_factor = 0; if (!copied) TCP_SKB_CB(skb)->flags &= ~TCPCB_FLAG_PSH; @@ -937,6 +938,7 @@ tp->write_seq += copy; TCP_SKB_CB(skb)->end_seq += copy; + TCP_SKB_CB(skb)->tso_factor = 0; from += copy; copied += copy; diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-29 16:09:42 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-29 16:09:42 -07:00 @@ -553,7 +553,7 @@ return skb->tail; } -static int __tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) +static int __tcp_trim_head(struct tcp_opt *tp, struct sk_buff *skb, u32 len) { if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) @@ -567,12 +567,18 @@ } skb->ip_summed = CHECKSUM_HW; + + /* Any change of skb->len requires recalculation of tso + * factor and mss. + */ + tcp_set_skb_tso_factor(skb, tp->mss_cache_std); + return 0; } -static inline int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) +static inline int tcp_trim_head(struct tcp_opt *tp, struct sk_buff *skb, u32 len) { - int err = __tcp_trim_head(sk, skb, len); + int err = __tcp_trim_head(tp, skb, len); if (!err) TCP_SKB_CB(skb)->seq += len; @@ -897,6 +903,9 @@ ((skb_size + next_skb_size) > mss_now)) return; + BUG_ON(TCP_SKB_CB(skb)->tso_factor != 1 || + TCP_SKB_CB(next_skb)->tso_factor != 1); + /* Ok. We will be able to collapse the packet. */ __skb_unlink(next_skb, next_skb->list); @@ -1018,7 +1027,7 @@ if (skb->len > (data_end_seq - data_seq)) { u32 to_trim = skb->len - (data_end_seq - data_seq); - if (__tcp_trim_head(sk, skb, to_trim)) + if (__tcp_trim_head(tp, skb, to_trim)) return -ENOMEM; } @@ -1032,7 +1041,7 @@ tp->mss_cache = tp->mss_cache_std; } - if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) + if (tcp_trim_head(tp, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) return -ENOMEM; } @@ -1080,6 +1089,7 @@ tp->snd_una == (TCP_SKB_CB(skb)->end_seq - 1)) { if (!pskb_trim(skb, 0)) { TCP_SKB_CB(skb)->seq = TCP_SKB_CB(skb)->end_seq - 1; + TCP_SKB_CB(skb)->tso_factor = 1; skb->ip_summed = CHECKSUM_NONE; skb->csum = 0; } From jheffner@psc.edu Wed Sep 29 16:51:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 16:51:48 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8TNpbLP001009 for ; Wed, 29 Sep 2004 16:51:38 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8TNpMcN025763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Sep 2004 19:51:23 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8TNpMxS007433; Wed, 29 Sep 2004 19:51:22 -0400 (EDT) Date: Wed, 29 Sep 2004 19:51:21 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Andi Kleen , , , , , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: <20040929162923.796d142e.davem@davemloft.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 360 Lines: 13 On Wed, 29 Sep 2004, David S. Miller wrote: > Let me know if this cures the issue, and if it does we can > move back to Andi's performance issue and the MSS stuff > John Heffner just discovered. Seems to work for me. Using iperf, I'm getting ~ the same speed to a slow p3 receiver (680 Mbits) with TSO on or off right now. Haven't tried netperf. -John From davem@davemloft.net Wed Sep 29 17:04:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 17:04:40 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U04Z9Q001526 for ; Wed, 29 Sep 2004 17:04:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCoPf-0002UV-00; Wed, 29 Sep 2004 17:03:11 -0700 Date: Wed, 29 Sep 2004 17:03:10 -0700 From: "David S. Miller" To: John Heffner Cc: ak@suse.de, niv@us.ibm.com, herbert@gondor.apana.org.au, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929170310.46c58095.davem@davemloft.net> In-Reply-To: References: <20040929162923.796d142e.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1437 Lines: 38 On Wed, 29 Sep 2004 19:51:21 -0400 (EDT) John Heffner wrote: > On Wed, 29 Sep 2004, David S. Miller wrote: > > > Let me know if this cures the issue, and if it does we can > > move back to Andi's performance issue and the MSS stuff > > John Heffner just discovered. > > Seems to work for me. > > Using iperf, I'm getting ~ the same speed to a slow p3 receiver (680 > Mbits) with TSO on or off right now. Haven't tried netperf. Great, thanks for testing. I just pushed these changes into my tree at: bk://kernel.bkbits.net/davem/net-2.6 and asked Linus to pull them in. I think I'm going to make tcp_tso_acked() call tcp_trim_head() direclty so that skb->len and (end_seq - seq) are kept in sync. This will also correct a bug in tcp_tso_acked() wrt. URG processing. It uses the wrong sequence number currently. Luckily that code never runs currently because all URG packets are built non-TSO. Better to fix this than to let it bite us later. I think there are some other things we can do to make TSO work even better. We turn off TSO currently when we get SACKs, that stinks and is really unnecessary. We can keep track of sacking of sub-TSO frames by simply using a bitmask of some kind. I will have space for this if I move the tso_factor/tso_mss out of tcp_skb_cb[] and just use the tso_{size,segs} in skb_shinfo(skb) Anyways, I'll work on that stuff while the dust settles on the current bug fix. From herbert@gondor.apana.org.au Wed Sep 29 17:06:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 17:06:30 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U06Kr1001909 for ; Wed, 29 Sep 2004 17:06:21 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCoRo-0008Vw-00; Thu, 30 Sep 2004 10:05:24 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCoRf-0002kv-00; Thu, 30 Sep 2004 10:05:15 +1000 Date: Thu, 30 Sep 2004 10:05:15 +1000 To: "David S. Miller" Cc: Andi Kleen , niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040930000515.GA10496@gondor.apana.org.au> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929162923.796d142e.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 672 Lines: 22 On Wed, Sep 29, 2004 at 04:29:23PM -0700, David S. Miller wrote: > > @@ -567,12 +567,18 @@ > } > > skb->ip_summed = CHECKSUM_HW; > + > + /* Any change of skb->len requires recalculation of tso > + * factor and mss. > + */ > + tcp_set_skb_tso_factor(skb, tp->mss_cache_std); Minor optimsations: __tcp_trim_head is only called directly when tso_factor has already been adjusted by tcp_tso_acked. So you can move this setting into tcp_trim_head. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From jheffner@psc.edu Wed Sep 29 17:10:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 17:11:02 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U0AvYc002332 for ; Wed, 29 Sep 2004 17:10:58 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8U0AgcN026279 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 29 Sep 2004 20:10:42 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8U0AfxS007607; Wed, 29 Sep 2004 20:10:41 -0400 (EDT) Date: Wed, 29 Sep 2004 20:10:41 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Andi Kleen , , , , , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 261 Lines: 9 On Wed, 29 Sep 2004, John Heffner wrote: > Using iperf, I'm getting ~ the same speed to a slow p3 receiver (680 > Mbits) with TSO on or off right now. Haven't tried netperf. Netperf does not work well for me (350 Mbits). Something to investigate. -John From herbert@gondor.apana.org.au Wed Sep 29 17:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 17:13:02 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U0CjK0002658 for ; Wed, 29 Sep 2004 17:12:53 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCoWP-000078-00; Thu, 30 Sep 2004 10:10:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCoWN-0002lp-00; Thu, 30 Sep 2004 10:10:07 +1000 Date: Thu, 30 Sep 2004 10:10:07 +1000 To: "David S. Miller" Cc: John Heffner , ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040930001007.GB10496@gondor.apana.org.au> References: <20040929162923.796d142e.davem@davemloft.net> <20040929170310.46c58095.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929170310.46c58095.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 603 Lines: 16 On Wed, Sep 29, 2004 at 05:03:10PM -0700, David S. Miller wrote: > > I think there are some other things we can do to make TSO work > even better. We turn off TSO currently when we get SACKs, that Great. This way we can also fix the fack_count in tcp_sacktag_write_queue(). Currently it always counts tso_factor packets even though the sack may only cover part of the TSO packet. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From mikecck@singnet.com.sg Wed Sep 29 17:51:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 17:52:01 -0700 (PDT) Received: from smtp25.singnet.com.sg (smtp25.singnet.com.sg [165.21.101.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U0psNG003672 for ; Wed, 29 Sep 2004 17:51:55 -0700 Received: from Thinkpad (bb220-255-16-143.singnet.com.sg [220.255.16.143]) by smtp25.singnet.com.sg (8.13.1/8.13.1) with ESMTP id i8U0pfBj018832 for ; Thu, 30 Sep 2004 08:51:41 +0800 Message-Id: <200409300051.i8U0pfBj018832@smtp25.singnet.com.sg> From: "Mike Chan" To: Subject: Survey on Open Source Date: Thu, 30 Sep 2004 08:51:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSjaiqw0fk/bfqgQxiJs7t++8yOOQAAP4nAAASXEiAAAARyAADCfkLg X-archive-position: 9720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mikecck@singnet.com.sg Precedence: bulk X-list: netdev Content-Length: 890 Lines: 35 Dear all, I am conducting a survey on open source software. This is for my academic coursework and dissertation. It will be great to have your support and participation in this survey. This survey has two separate questionnaires, focusing on the following areas: 1) OSS development (Developers or those who contribute in coding or documentation), and 2) IT/IS costs (CIOs or IT Managers). You are free to go for the questionnaire that is appropriate for you. Below are the links: 1) Brief introduction page: http://web.singnet.com.sg/~mikecck/opensource/Introduction1.htm 2) Questionnaire 1(Open Source Development): http://web.singnet.com.sg/~mikecck/opensource/WebFormA1.htm 3) Questionnaire 2(Open Source and IT/IS Cost): http://web.singnet.com.sg/~mikecck/opensource/WebFormB1.htm Thank you for your time. Mike Chan Student Curtin University of Technology From gnb@melbourne.sgi.com Wed Sep 29 19:11:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 19:11:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i8U2BiGi005604 for ; Wed, 29 Sep 2004 19:11:45 -0700 Received: from [134.14.55.176] (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA18140; Thu, 30 Sep 2004 12:11:11 +1000 Subject: Re: [PATCH] I/O space write barrier From: Greg Banks To: "David S. Miller" Cc: Jesse Barnes , akpm@osdl.org, linux-kernel@vger.kernel.org, Jeremy Higdon , John Partridge , Linux Network Development list In-Reply-To: <20040929135029.38444afd.davem@davemloft.net> References: <200409271103.39913.jbarnes@engr.sgi.com> <20040929103646.GA4682@sgi.com> <20040929133500.59d78765.davem@davemloft.net> <200409291343.55863.jbarnes@engr.sgi.com> <20040929135029.38444afd.davem@davemloft.net> Content-Type: text/plain Organization: Silicon Graphics Inc, Australian Software Group. Message-Id: <1096511023.3620.3314.camel@hole.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Thu, 30 Sep 2004 12:23:43 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 9721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: netdev Content-Length: 642 Lines: 23 On Thu, 2004-09-30 at 06:50, David S. Miller wrote: > On Wed, 29 Sep 2004 13:43:55 -0700 > Jesse Barnes wrote: > > > The patch that actually implements mmiowb() already does this, I think Greg > > just used his patch for testing. Yes, that hunk will be unnecessary when Jesse's patch goes in. > The proper way to do it of course is to > > just use mmiowb() where needed in tg3 after the write barrier patch gets in. > > Perfect, please send me a tg3 patch once the mmiowb() bits > go into the tree. Will do. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From davem@davemloft.net Wed Sep 29 21:34:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 21:35:09 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U4YohO011997 for ; Wed, 29 Sep 2004 21:34:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCscw-00037h-00; Wed, 29 Sep 2004 21:33:10 -0700 Date: Wed, 29 Sep 2004 21:33:10 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040929213310.40f5f33a.davem@davemloft.net> In-Reply-To: <20040930000515.GA10496@gondor.apana.org.au> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> <20040930000515.GA10496@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 8986 Lines: 292 On Thu, 30 Sep 2004 10:05:15 +1000 Herbert Xu wrote: > On Wed, Sep 29, 2004 at 04:29:23PM -0700, David S. Miller wrote: > > > > @@ -567,12 +567,18 @@ > > skb->ip_summed = CHECKSUM_HW; > > + > > + /* Any change of skb->len requires recalculation of tso > > + * factor and mss. > > + */ > > + tcp_set_skb_tso_factor(skb, tp->mss_cache_std); > > Minor optimsations: __tcp_trim_head is only called directly when > tso_factor has already been adjusted by tcp_tso_acked. So you can > move this setting into tcp_trim_head. Right. This patch below combines that with adjustment of socket send queue usage when we trim the head. I also added John Heffner's snd_cwnd TSO factor tweak. I adjusted it down to 1/4 of the congestion window because it gave the best ramp-up performance for a cross-continental transfer test. John, this might make your netperf case go better. Give it a try and let me know how it goes. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/29 21:12:18-07:00 davem@nuts.davemloft.net # [TCP]: Smooth out TSO ack clocking. # # - Export tcp_trim_head() and call it directly from # tcp_tso_acked(). This also fixes URG handling. # # - Make tcp_trim_head() adjust the skb->truesize of # the packet and liberate that space from the socket # send buffer. # # - In tcp_current_mss(), limit TSO factor to 1/4 of # snd_cwnd. The idea is from John Heffner. # # Signed-off-by: David S. Miller # # net/ipv4/tcp_output.c # 2004/09/29 21:11:53-07:00 davem@nuts.davemloft.net +15 -35 # [TCP]: Smooth out TSO ack clocking. # # - Export tcp_trim_head() and call it directly from # tcp_tso_acked(). This also fixes URG handling. # # - Make tcp_trim_head() adjust the skb->truesize of # the packet and liberate that space from the socket # send buffer. # # - In tcp_current_mss(), limit TSO factor to 1/4 of # snd_cwnd. The idea is from John Heffner. # # Signed-off-by: David S. Miller # # net/ipv4/tcp_input.c # 2004/09/29 21:11:53-07:00 davem@nuts.davemloft.net +9 -13 # [TCP]: Smooth out TSO ack clocking. # # - Export tcp_trim_head() and call it directly from # tcp_tso_acked(). This also fixes URG handling. # # - Make tcp_trim_head() adjust the skb->truesize of # the packet and liberate that space from the socket # send buffer. # # - In tcp_current_mss(), limit TSO factor to 1/4 of # snd_cwnd. The idea is from John Heffner. # # Signed-off-by: David S. Miller # # include/net/tcp.h # 2004/09/29 21:11:52-07:00 davem@nuts.davemloft.net +1 -0 # [TCP]: Smooth out TSO ack clocking. # # - Export tcp_trim_head() and call it directly from # tcp_tso_acked(). This also fixes URG handling. # # - Make tcp_trim_head() adjust the skb->truesize of # the packet and liberate that space from the socket # send buffer. # # - In tcp_current_mss(), limit TSO factor to 1/4 of # snd_cwnd. The idea is from John Heffner. # # Signed-off-by: David S. Miller # diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-09-29 21:12:59 -07:00 +++ b/include/net/tcp.h 2004-09-29 21:12:59 -07:00 @@ -944,6 +944,7 @@ extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); +extern int tcp_trim_head(struct sock *, struct sk_buff *, u32); extern void tcp_send_probe0(struct sock *); extern void tcp_send_partial(struct sock *); diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-09-29 21:12:59 -07:00 +++ b/net/ipv4/tcp_input.c 2004-09-29 21:12:59 -07:00 @@ -2364,13 +2364,14 @@ * then making a write space wakeup callback is a possible * future enhancement. WARNING: it is not trivial to make. */ -static int tcp_tso_acked(struct tcp_opt *tp, struct sk_buff *skb, +static int tcp_tso_acked(struct sock *sk, struct sk_buff *skb, __u32 now, __s32 *seq_rtt) { + struct tcp_opt *tp = tcp_sk(sk); struct tcp_skb_cb *scb = TCP_SKB_CB(skb); __u32 mss = scb->tso_mss; __u32 snd_una = tp->snd_una; - __u32 seq = scb->seq; + __u32 orig_seq, seq; __u32 packets_acked = 0; int acked = 0; @@ -2379,22 +2380,18 @@ */ BUG_ON(!after(scb->end_seq, snd_una)); + seq = orig_seq = scb->seq; while (!after(seq + mss, snd_una)) { packets_acked++; seq += mss; } + if (tcp_trim_head(sk, skb, (seq - orig_seq))) + return 0; + if (packets_acked) { __u8 sacked = scb->sacked; - /* We adjust scb->seq but we do not pskb_pull() the - * SKB. We let tcp_retransmit_skb() handle this case - * by checking skb->len against the data sequence span. - * This way, we avoid the pskb_pull() work unless we - * actually need to retransmit the SKB. - */ - scb->seq = seq; - acked |= FLAG_DATA_ACKED; if (sacked) { if (sacked & TCPCB_RETRANS) { @@ -2413,7 +2410,7 @@ packets_acked); if (sacked & TCPCB_URG) { if (tp->urg_mode && - !before(scb->seq, tp->snd_up)) + !before(orig_seq, tp->snd_up)) tp->urg_mode = 0; } } else if (*seq_rtt < 0) @@ -2425,7 +2422,6 @@ tcp_dec_pcount_explicit(&tp->fackets_out, dval); } tcp_dec_pcount_explicit(&tp->packets_out, packets_acked); - scb->tso_factor -= packets_acked; BUG_ON(scb->tso_factor == 0); BUG_ON(!before(scb->seq, scb->end_seq)); @@ -2455,7 +2451,7 @@ */ if (after(scb->end_seq, tp->snd_una)) { if (scb->tso_factor > 1) - acked |= tcp_tso_acked(tp, skb, + acked |= tcp_tso_acked(sk, skb, now, &seq_rtt); break; } diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-29 21:12:59 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-29 21:12:59 -07:00 @@ -525,7 +525,7 @@ * eventually). The difference is that pulled data not copied, but * immediately discarded. */ -unsigned char * __pskb_trim_head(struct sk_buff *skb, int len) +static unsigned char *__pskb_trim_head(struct sk_buff *skb, int len) { int i, k, eat; @@ -553,8 +553,10 @@ return skb->tail; } -static int __tcp_trim_head(struct tcp_opt *tp, struct sk_buff *skb, u32 len) +int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len) { + struct tcp_opt *tp = tcp_sk(sk); + if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) return -ENOMEM; @@ -566,8 +568,14 @@ return -ENOMEM; } + TCP_SKB_CB(skb)->seq += len; skb->ip_summed = CHECKSUM_HW; + skb->truesize -= len; + sk->sk_queue_shrunk = 1; + sk->sk_wmem_queued -= len; + sk->sk_forward_alloc += len; + /* Any change of skb->len requires recalculation of tso * factor and mss. */ @@ -576,16 +584,6 @@ return 0; } -static inline int tcp_trim_head(struct tcp_opt *tp, struct sk_buff *skb, u32 len) -{ - int err = __tcp_trim_head(tp, skb, len); - - if (!err) - TCP_SKB_CB(skb)->seq += len; - - return err; -} - /* This function synchronize snd mss to current pmtu/exthdr set. tp->user_mss is mss set by user by TCP_MAXSEG. It does NOT counts @@ -686,11 +684,12 @@ 68U - tp->tcp_header_len); /* Always keep large mss multiple of real mss, but - * do not exceed congestion window. + * do not exceed 1/4 of the congestion window so we + * can keep the ACK clock ticking. */ factor = large_mss / mss_now; - if (factor > tp->snd_cwnd) - factor = tp->snd_cwnd; + if (factor > (tp->snd_cwnd >> 2)) + factor = max(1, tp->snd_cwnd >> 2); tp->mss_cache = mss_now * factor; @@ -1003,7 +1002,6 @@ { struct tcp_opt *tp = tcp_sk(sk); unsigned int cur_mss = tcp_current_mss(sk, 0); - __u32 data_seq, data_end_seq; int err; /* Do not sent more than we queued. 1/4 is reserved for possible @@ -1013,24 +1011,6 @@ min(sk->sk_wmem_queued + (sk->sk_wmem_queued >> 2), sk->sk_sndbuf)) return -EAGAIN; - /* What is going on here? When TSO packets are partially ACK'd, - * we adjust the TCP_SKB_CB(skb)->seq value forward but we do - * not adjust the data area of the SKB. We defer that to here - * so that we can avoid the work unless we really retransmit - * the packet. - */ - data_seq = TCP_SKB_CB(skb)->seq; - data_end_seq = TCP_SKB_CB(skb)->end_seq; - if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) - data_end_seq--; - - if (skb->len > (data_end_seq - data_seq)) { - u32 to_trim = skb->len - (data_end_seq - data_seq); - - if (__tcp_trim_head(tp, skb, to_trim)) - return -ENOMEM; - } - if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) { if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una)) BUG(); @@ -1041,7 +1021,7 @@ tp->mss_cache = tp->mss_cache_std; } - if (tcp_trim_head(tp, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) + if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq)) return -ENOMEM; } From herbert@gondor.apana.org.au Wed Sep 29 22:48:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 29 Sep 2004 22:48:58 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U5mhqf013709 for ; Wed, 29 Sep 2004 22:48:44 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCtn9-0001Y0-00; Thu, 30 Sep 2004 15:47:47 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCtn0-0003If-00; Thu, 30 Sep 2004 15:47:38 +1000 Date: Thu, 30 Sep 2004 15:47:38 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040930054738.GA12667@gondor.apana.org.au> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> <20040930000515.GA10496@gondor.apana.org.au> <20040929213310.40f5f33a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20040929213310.40f5f33a.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1350 Lines: 45 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 29, 2004 at 09:33:10PM -0700, David S. Miller wrote: > > @@ -2413,7 +2410,7 @@ > packets_acked); > if (sacked & TCPCB_URG) { > if (tp->urg_mode && > - !before(scb->seq, tp->snd_up)) > + !before(orig_seq, tp->snd_up)) > tp->urg_mode = 0; That looks like a typo. We should check against the new starting sequence number, not the original. We should also change the !before to after since the original check applied to end_seq. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- net-2.6/net/ipv4/tcp_input.c.orig 2004-09-30 15:41:46.000000000 +1000 +++ net-2.6/net/ipv4/tcp_input.c 2004-09-30 15:44:27.000000000 +1000 @@ -2410,7 +2410,7 @@ packets_acked); if (sacked & TCPCB_URG) { if (tp->urg_mode && - !before(orig_seq, tp->snd_up)) + after(seq, tp->snd_up)) tp->urg_mode = 0; } } else if (*seq_rtt < 0) --17pEHd4RhPHOinZp-- From davem@davemloft.net Thu Sep 30 00:40:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 00:41:07 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U7eqbo019244 for ; Thu, 30 Sep 2004 00:40:53 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CCvX9-0003L2-00; Thu, 30 Sep 2004 00:39:23 -0700 Date: Thu, 30 Sep 2004 00:39:22 -0700 From: "David S. Miller" To: Herbert Xu Cc: ak@suse.de, niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040930003922.3076f00f.davem@davemloft.net> In-Reply-To: <20040930054738.GA12667@gondor.apana.org.au> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> <20040930000515.GA10496@gondor.apana.org.au> <20040929213310.40f5f33a.davem@davemloft.net> <20040930054738.GA12667@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 795 Lines: 22 On Thu, 30 Sep 2004 15:47:38 +1000 Herbert Xu wrote: > On Wed, Sep 29, 2004 at 09:33:10PM -0700, David S. Miller wrote: > > > > @@ -2413,7 +2410,7 @@ > > packets_acked); > > if (sacked & TCPCB_URG) { > > if (tp->urg_mode && > > - !before(scb->seq, tp->snd_up)) > > + !before(orig_seq, tp->snd_up)) > > tp->urg_mode = 0; > > That looks like a typo. We should check against the new starting > sequence number, not the original. We should also change the !before > to after since the original check applied to end_seq. I agree about the first part, but the second I do not. The new 'seq' is equivalent to what end_seq would be of the TSO sub-packet. Therefore the correct test type would be !before(seq, tp->snd_up), right? From yoshfuji@linux-ipv6.org Thu Sep 30 01:07:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 01:07:28 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U87MIx020063 for ; Thu, 30 Sep 2004 01:07:22 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 613C733CE5; Thu, 30 Sep 2004 17:07:29 +0900 (JST) Date: Thu, 30 Sep 2004 17:07:29 +0900 (JST) Message-Id: <20040930.170729.51800585.yoshfuji@linux-ipv6.org> To: davem@davemloft.net Cc: netdev@oss.sgi.com Subject: [PATCH] [NET] NEIGHBOUR: hold refcnt of net_device from proxy neighbor entries. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1113 Lines: 51 Hello. [NET] NEIGHBOUR: hold refcnt of net_device from proxy neighbor entries. We did not hold refcnt of net_device from proxy neighbor entries while we did from neighbor entries. Signed-off-by: Hideaki YOSHIFUJI Thanks. diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c 2004-09-30 16:32:24 +09:00 +++ b/net/core/neighbour.c 2004-09-30 16:32:24 +09:00 @@ -496,8 +496,12 @@ memcpy(n->key, pkey, key_len); n->dev = dev; + if (dev) + dev_hold(dev); if (tbl->pconstructor && tbl->pconstructor(n)) { + if (dev) + dev_put(dev); kfree(n); n = NULL; goto out; @@ -532,6 +536,8 @@ write_unlock_bh(&tbl->lock); if (tbl->pdestructor) tbl->pdestructor(n); + if (n->dev) + dev_put(n->dev); kfree(n); return 0; } @@ -552,6 +558,8 @@ *np = n->next; if (tbl->pdestructor) tbl->pdestructor(n); + if (n->dev) + dev_put(n->dev); kfree(n); continue; } -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ak@suse.de Thu Sep 30 01:08:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 01:08:33 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U88SCa020278 for ; Thu, 30 Sep 2004 01:08:28 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 938CBCA34AD; Thu, 30 Sep 2004 10:08:10 +0200 (CEST) Date: Thu, 30 Sep 2004 10:08:10 +0200 From: Andi Kleen To: Ben Greear Cc: Andi Kleen , netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c Message-ID: <20040930080810.GB20106@wotan.suse.de> References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> <1096492842.2344.57.camel@localhost.localdomain> <20040929142750.27b35952.davem@davemloft.net> <20040929220926.GE26714@wotan.suse.de> <415B3637.9060700@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415B3637.9060700@candelatech.com> X-archive-position: 9726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 905 Lines: 28 On Wed, Sep 29, 2004 at 03:24:55PM -0700, Ben Greear wrote: > Andi Kleen wrote: > >On Wed, Sep 29, 2004 at 02:27:50PM -0700, David S. Miller wrote: > > >>Because once we add functionality to the kernel we can't simply > >>rip it out. People do use TOS routing, via static routes or > >>similar. > > > > > >I'm not so sure anybody uses it really. How about adding a printk for it > >and seeing if anybody complains? > > I don't think you should remove existing features in the middle of a stable > release cycle. If you want to have a compile option, that defaults to off, There is no stable release cycle anymore. Linus has abolished that. Maybe we will get it back at some point if the current way doesn't work out, but currently it's unlimited hacking time. > And I don't think the majority of people would see the printk untill way > too late. That was always the case, nothing new. -Andi From herbert@gondor.apana.org.au Thu Sep 30 01:10:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 01:11:00 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U8ApdA020775 for ; Thu, 30 Sep 2004 01:10:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1CCw0s-0002LD-00; Thu, 30 Sep 2004 18:10:06 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1CCw0j-0003Uj-00; Thu, 30 Sep 2004 18:09:57 +1000 Date: Thu, 30 Sep 2004 18:09:57 +1000 To: "David S. Miller" Cc: ak@suse.de, niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040930080957.GA13401@gondor.apana.org.au> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> <20040930000515.GA10496@gondor.apana.org.au> <20040929213310.40f5f33a.davem@davemloft.net> <20040930054738.GA12667@gondor.apana.org.au> <20040930003922.3076f00f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040930003922.3076f00f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 470 Lines: 14 On Thu, Sep 30, 2004 at 12:39:22AM -0700, David S. Miller wrote: > > The new 'seq' is equivalent to what end_seq would be of the > TSO sub-packet. Therefore the correct test type would be > !before(seq, tp->snd_up), right? You're absolutely right. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From ak@suse.de Thu Sep 30 02:29:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 02:30:02 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U9TpxU022676 for ; Thu, 30 Sep 2004 02:29:52 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 43406CA3F3A; Thu, 30 Sep 2004 11:29:34 +0200 (CEST) Date: Thu, 30 Sep 2004 11:29:26 +0200 From: Andi Kleen To: "David S. Miller" Cc: Herbert Xu , ak@suse.de, niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-ID: <20040930092926.GA18353@wotan.suse.de> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> <20040930000515.GA10496@gondor.apana.org.au> <20040929213310.40f5f33a.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040929213310.40f5f33a.davem@davemloft.net> X-archive-position: 9728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 20722 Lines: 189 > Right. This patch below combines that with adjustment of socket > send queue usage when we trim the head. I tested this patch on rc3. First it doesn't crash anymore. Thanks. Talking to another rc3 kernel with tg3 tso on is as fast as tso off now. Unfortunately the ACKs still look funny. Talking to a 2.6.5 kernel tso on is still about 20 MB/s slower than the non TSO case, so the problem seems to be still there. -Andi 2.6.9rc3/e1000/CSA/TSO -> 2.6.9rc3/tg3/33MhzPCI Fast. Still stretch ack. 11:13:25.721704 10.23.202.15.32777 > 10.23.202.31.32784: . ack 7241 win 5068 (DF) 11:13:25.721709 10.23.202.15.32777 > 10.23.202.31.32784: . ack 8689 win 5792 (DF) 11:13:25.721715 10.23.202.15.32777 > 10.23.202.31.32784: . ack 10137 win 6516 (DF) 11:13:25.721726 10.23.202.15.32777 > 10.23.202.31.32784: . ack 11585 win 7240 (DF) 11:13:25.721731 10.23.202.15.32777 > 10.23.202.31.32784: . ack 13033 win 7964 (DF) 11:13:25.721882 10.23.202.31.32784 > 10.23.202.15.32777: . 13033:14481(1448) ack 1 win 1460 (DF) 11:13:25.721887 10.23.202.31.32784 > 10.23.202.15.32777: . 14481:15929(1448) ack 1 win 1460 (DF) 11:13:25.721893 10.23.202.31.32784 > 10.23.202.15.32777: P 15929:16385(456) ack 1 win 1460 (DF) 11:13:25.721940 10.23.202.31.32784 > 10.23.202.15.32777: . 16385:17833(1448) ack 1 win 1460 (DF) 11:13:25.721943 10.23.202.31.32784 > 10.23.202.15.32777: . 17833:19281(1448) ack 1 win 1460 (DF) 11:13:25.721947 10.23.202.31.32784 > 10.23.202.15.32777: . 19281:20729(1448) ack 1 win 1460 (DF) 11:13:25.721951 10.23.202.31.32784 > 10.23.202.15.32777: . 20729:22177(1448) ack 1 win 1460 (DF) 11:13:25.721970 10.23.202.15.32777 > 10.23.202.31.32784: . ack 14481 win 8688 (DF) 11:13:25.721975 10.23.202.15.32777 > 10.23.202.31.32784: . ack 15929 win 9412 (DF) 11:13:25.721980 10.23.202.15.32777 > 10.23.202.31.32784: . ack 16385 win 9412 (DF) 11:13:25.721985 10.23.202.15.32777 > 10.23.202.31.32784: . ack 17833 win 10136 (DF) 11:13:25.721991 10.23.202.15.32777 > 10.23.202.31.32784: . ack 19281 win 10860 (DF) 11:13:25.721996 10.23.202.15.32777 > 10.23.202.31.32784: . ack 20729 win 11584 (DF) 11:13:25.722018 10.23.202.15.32777 > 10.23.202.31.32784: . ack 22177 win 12308 (DF) 11:13:25.722127 10.23.202.31.32784 > 10.23.202.15.32777: . 22177:23625(1448) ack 1 win 1460 (DF) 11:13:25.722134 10.23.202.15.32777 > 10.23.202.31.32784: . ack 23625 win 13032 (DF) 11:13:25.722139 10.23.202.31.32784 > 10.23.202.15.32777: . 23625:25073(1448) ack 1 win 1460 (DF) 11:13:25.722142 10.23.202.15.32777 > 10.23.202.31.32784: . ack 25073 win 13756 (DF) 11:13:25.722147 10.23.202.31.32784 > 10.23.202.15.32777: . 25073:26521(1448) ack 1 win 1460 (DF) 11:13:25.722151 10.23.202.15.32777 > 10.23.202.31.32784: . ack 26521 win 14480 (DF) 11:13:25.722156 10.23.202.31.32784 > 10.23.202.15.32777: . 26521:27969(1448) ack 1 win 1460 (DF) 11:13:25.722160 10.23.202.15.32777 > 10.23.202.31.32784: . ack 27969 win 14962 (DF) 11:13:25.722228 10.23.202.31.32784 > 10.23.202.15.32777: . 27969:29417(1448) ack 1 win 1460 (DF) 11:13:25.722236 10.23.202.31.32784 > 10.23.202.15.32777: . 29417:30865(1448) ack 1 win 1460 (DF) 11:13:25.722243 10.23.202.31.32784 > 10.23.202.15.32777: . 30865:32313(1448) ack 1 win 1460 (DF) 11:13:25.722249 10.23.202.31.32784 > 10.23.202.15.32777: . 32313:33761(1448) ack 1 win 1460 (DF) 11:13:25.722273 10.23.202.31.32784 > 10.23.202.15.32777: P 33761:35209(1448) ack 1 win 1460 (DF) 11:13:25.722277 10.23.202.31.32784 > 10.23.202.15.32777: . 35209:36657(1448) ack 1 win 1460 (DF) 11:13:25.722282 10.23.202.31.32784 > 10.23.202.15.32777: . 36657:38105(1448) ack 1 win 1460 (DF) 11:13:25.722339 10.23.202.15.32777 > 10.23.202.31.32784: . ack 38105 win 15204 (DF) 11:13:25.722415 10.23.202.31.32784 > 10.23.202.15.32777: . 38105:39553(1448) ack 1 win 1460 (DF) 11:13:25.722419 10.23.202.31.32784 > 10.23.202.15.32777: . 39553:41001(1448) ack 1 win 1460 (DF) 11:13:25.722425 10.23.202.31.32784 > 10.23.202.15.32777: . 41001:42449(1448) ack 1 win 1460 (DF) 11:13:25.722429 10.23.202.31.32784 > 10.23.202.15.32777: . 42449:43897(1448) ack 1 win 1460 (DF) 11:13:25.722433 10.23.202.31.32784 > 10.23.202.15.32777: . 43897:45345(1448) ack 1 win 1460 (DF) 11:13:25.722436 10.23.202.31.32784 > 10.23.202.15.32777: . 45345:46793(1448) ack 1 win 1460 (DF) 11:13:25.722459 10.23.202.31.32784 > 10.23.202.15.32777: . 46793:48241(1448) ack 1 win 1460 (DF) 11:13:25.722463 10.23.202.31.32784 > 10.23.202.15.32777: . 48241:49689(1448) ack 1 win 1460 (DF) 11:13:25.722472 10.23.202.15.32777 > 10.23.202.31.32784: . ack 39553 win 15928 (DF) 11:13:25.722504 10.23.202.15.32777 > 10.23.202.31.32784: . ack 49689 win 15928 (DF) 11:13:25.722616 10.23.202.31.32784 > 10.23.202.15.32777: . 49689:51137(1448) ack 1 win 1460 (DF) 11:13:25.722622 10.23.202.31.32784 > 10.23.202.15.32777: . 51137:52585(1448) ack 1 win 1460 (DF) 11:13:25.722690 10.23.202.31.32784 > 10.23.202.15.32777: . 52585:54033(1448) ack 1 win 1460 (DF) 11:13:25.722697 10.23.202.31.32784 > 10.23.202.15.32777: . 54033:55481(1448) ack 1 win 1460 (DF) 11:13:25.722703 10.23.202.31.32784 > 10.23.202.15.32777: . 55481:56929(1448) ack 1 win 1460 (DF) 11:13:25.722710 10.23.202.31.32784 > 10.23.202.15.32777: . 56929:58377(1448) ack 1 win 1460 (DF) 11:13:25.722716 10.23.202.31.32784 > 10.23.202.15.32777: . 58377:59825(1448) ack 1 win 1460 (DF) 11:13:25.722786 10.23.202.31.32784 > 10.23.202.15.32777: P 59825:61273(1448) ack 1 win 1460 (DF) 11:13:25.722793 10.23.202.31.32784 > 10.23.202.15.32777: . 61273:62721(1448) ack 1 win 1460 (DF) 11:13:25.722798 10.23.202.31.32784 > 10.23.202.15.32777: . 62721:64169(1448) ack 1 win 1460 (DF) 2.6.9rc3/e1000/CSA/TSO -> 2.6.5/tg3/33MhzPCI Slow. Extreme stretch ack: 11:19:45.486497 10.23.202.31.32782 > 10.23.202.10.32978: . 27969:29417(1448) ack 1 win 1460 (DF) 11:19:45.486506 10.23.202.10.32978 > 10.23.202.31.32782: . ack 29417 win 62264 (DF) 11:19:45.486510 10.23.202.31.32782 > 10.23.202.10.32978: P 29417:30865(1448) ack 1 win 1460 (DF) 11:19:45.486536 10.23.202.31.32782 > 10.23.202.10.32978: . 30865:32313(1448) ack 1 win 1460 (DF) 11:19:45.486543 10.23.202.31.32782 > 10.23.202.10.32978: . 32313:33761(1448) ack 1 win 1460 (DF) 11:19:45.486642 10.23.202.10.32978 > 10.23.202.31.32782: . ack 33761 win 63712 (DF) 11:19:45.486678 10.23.202.31.32782 > 10.23.202.10.32978: . 33761:35209(1448) ack 1 win 1460 (DF) 11:19:45.486686 10.23.202.10.32978 > 10.23.202.31.32782: . ack 35209 win 63712 (DF) 11:19:45.486691 10.23.202.31.32782 > 10.23.202.10.32978: . 35209:36657(1448) ack 1 win 1460 (DF) 11:19:45.486697 10.23.202.31.32782 > 10.23.202.10.32978: . 36657:38105(1448) ack 1 win 1460 (DF) 11:19:45.486704 10.23.202.31.32782 > 10.23.202.10.32978: . 38105:39553(1448) ack 1 win 1460 (DF) 11:19:45.486710 10.23.202.31.32782 > 10.23.202.10.32978: . 39553:41001(1448) ack 1 win 1460 (DF) 11:19:45.486716 10.23.202.31.32782 > 10.23.202.10.32978: . 41001:42449(1448) ack 1 win 1460 (DF) 11:19:45.486722 10.23.202.31.32782 > 10.23.202.10.32978: . 42449:43897(1448) ack 1 win 1460 (DF) 11:19:45.486747 10.23.202.31.32782 > 10.23.202.10.32978: . 43897:45345(1448) ack 1 win 1460 (DF) 11:19:45.486754 10.23.202.31.32782 > 10.23.202.10.32978: . 45345:46793(1448) ack 1 win 1460 (DF) 11:19:45.486761 10.23.202.31.32782 > 10.23.202.10.32978: . 46793:48241(1448) ack 1 win 1460 (DF) 11:19:45.486768 10.23.202.31.32782 > 10.23.202.10.32978: . 48241:49689(1448) ack 1 win 1460 (DF) 11:19:45.486775 10.23.202.31.32782 > 10.23.202.10.32978: . 49689:51137(1448) ack 1 win 1460 (DF) 11:19:45.486859 10.23.202.31.32782 > 10.23.202.10.32978: . 51137:52585(1448) ack 1 win 1460 (DF) 11:19:45.486867 10.23.202.31.32782 > 10.23.202.10.32978: . 52585:54033(1448) ack 1 win 1460 (DF) 11:19:45.486873 10.23.202.31.32782 > 10.23.202.10.32978: . 54033:55481(1448) ack 1 win 1460 (DF) 11:19:45.486880 10.23.202.31.32782 > 10.23.202.10.32978: P 55481:56929(1448) ack 1 win 1460 (DF) 11:19:45.487018 10.23.202.10.32978 > 10.23.202.31.32782: . ack 56929 win 63712 (DF) 11:19:45.487279 10.23.202.31.32782 > 10.23.202.10.32978: . 56929:58377(1448) ack 1 win 1460 (DF) 11:19:45.487288 10.23.202.31.32782 > 10.23.202.10.32978: . 58377:59825(1448) ack 1 win 1460 (DF) 11:19:45.487294 10.23.202.31.32782 > 10.23.202.10.32978: . 59825:61273(1448) ack 1 win 1460 (DF) 11:19:45.487299 10.23.202.31.32782 > 10.23.202.10.32978: . 61273:62721(1448) ack 1 win 1460 (DF) 11:19:45.487305 10.23.202.31.32782 > 10.23.202.10.32978: . 62721:64169(1448) ack 1 win 1460 (DF) 11:19:45.487311 10.23.202.31.32782 > 10.23.202.10.32978: . 64169:65617(1448) ack 1 win 1460 (DF) 11:19:45.487316 10.23.202.31.32782 > 10.23.202.10.32978: . 65617:67065(1448) ack 1 win 1460 (DF) 11:19:45.487370 10.23.202.31.32782 > 10.23.202.10.32978: . 67065:68513(1448) ack 1 win 1460 (DF) 11:19:45.487376 10.23.202.31.32782 > 10.23.202.10.32978: . 68513:69961(1448) ack 1 win 1460 (DF) 11:19:45.487382 10.23.202.31.32782 > 10.23.202.10.32978: . 69961:71409(1448) ack 1 win 1460 (DF) 11:19:45.487388 10.23.202.31.32782 > 10.23.202.10.32978: . 71409:72857(1448) ack 1 win 1460 (DF) 11:19:45.487393 10.23.202.31.32782 > 10.23.202.10.32978: . 72857:74305(1448) ack 1 win 1460 (DF) 11:19:45.487398 10.23.202.31.32782 > 10.23.202.10.32978: . 74305:75753(1448) ack 1 win 1460 (DF) 11:19:45.487421 10.23.202.31.32782 > 10.23.202.10.32978: . 75753:77201(1448) ack 1 win 1460 (DF) 11:19:45.487427 10.23.202.31.32782 > 10.23.202.10.32978: . 77201:78649(1448) ack 1 win 1460 (DF) 11:19:45.487433 10.23.202.31.32782 > 10.23.202.10.32978: . 78649:80097(1448) ack 1 win 1460 (DF) 11:19:45.487563 10.23.202.10.32978 > 10.23.202.31.32782: . ack 80097 win 63712 (DF) 2.6.9rc3/e1000/CSA/noTSO -> 2.6.5/tg3/33MhzPCI Fast. Also stretch ACK, but less extreme. 11:26:12.886397 10.23.202.10.32979 > 10.23.202.31.32788: . ack 8689 win 23168 (DF) 11:26:12.886405 10.23.202.10.32979 > 10.23.202.31.32788: . ack 10137 win 26064 (DF) 11:26:12.886420 10.23.202.10.32979 > 10.23.202.31.32788: . ack 11585 win 28960 (DF) 11:26:12.886440 10.23.202.10.32979 > 10.23.202.31.32788: . ack 13033 win 31856 (DF) 11:26:12.886488 10.23.202.31.32788 > 10.23.202.10.32979: . 13033:14481(1448) ack 1 win 1460 (DF) 11:26:12.886500 10.23.202.10.32979 > 10.23.202.31.32788: . ack 14481 win 34752 (DF) 11:26:12.886504 10.23.202.31.32788 > 10.23.202.10.32979: . 14481:15929(1448) ack 1 win 1460 (DF) 11:26:12.886513 10.23.202.10.32979 > 10.23.202.31.32788: . ack 15929 win 37648 (DF) 11:26:12.886749 10.23.202.31.32788 > 10.23.202.10.32979: . 15929:17377(1448) ack 1 win 1460 (DF) 11:26:12.886757 10.23.202.31.32788 > 10.23.202.10.32979: . 17377:18825(1448) ack 1 win 1460 (DF) 11:26:12.886763 10.23.202.31.32788 > 10.23.202.10.32979: . 18825:20273(1448) ack 1 win 1460 (DF) 11:26:12.886769 10.23.202.31.32788 > 10.23.202.10.32979: . 20273:21721(1448) ack 1 win 1460 (DF) 11:26:12.886775 10.23.202.31.32788 > 10.23.202.10.32979: . 21721:23169(1448) ack 1 win 1460 (DF) 11:26:12.886780 10.23.202.31.32788 > 10.23.202.10.32979: . 23169:24617(1448) ack 1 win 1460 (DF) 11:26:12.886786 10.23.202.31.32788 > 10.23.202.10.32979: P 24617:26065(1448) ack 1 win 1460 (DF) 11:26:12.886792 10.23.202.31.32788 > 10.23.202.10.32979: P 26065:27513(1448) ack 1 win 1460 (DF) 11:26:12.886798 10.23.202.31.32788 > 10.23.202.10.32979: . 27513:28961(1448) ack 1 win 1460 (DF) 11:26:12.886805 10.23.202.31.32788 > 10.23.202.10.32979: . 28961:30409(1448) ack 1 win 1460 (DF) 11:26:12.886810 10.23.202.31.32788 > 10.23.202.10.32979: . 30409:31857(1448) ack 1 win 1460 (DF) 11:26:12.886816 10.23.202.31.32788 > 10.23.202.10.32979: P 31857:32769(912) ack 1 win 1460 (DF) 11:26:12.886892 10.23.202.10.32979 > 10.23.202.31.32788: . ack 17377 win 40544 (DF) 11:26:12.886901 10.23.202.10.32979 > 10.23.202.31.32788: . ack 18825 win 43440 (DF) 11:26:12.886910 10.23.202.10.32979 > 10.23.202.31.32788: . ack 20273 win 46336 (DF) 11:26:12.886917 10.23.202.10.32979 > 10.23.202.31.32788: . ack 21721 win 49232 (DF) 11:26:12.886925 10.23.202.10.32979 > 10.23.202.31.32788: . ack 23169 win 52128 (DF) 11:26:12.886933 10.23.202.10.32979 > 10.23.202.31.32788: . ack 24617 win 55024 (DF) 11:26:12.886960 10.23.202.10.32979 > 10.23.202.31.32788: . ack 26065 win 57920 (DF) 11:26:12.886976 10.23.202.10.32979 > 10.23.202.31.32788: . ack 27513 win 60816 (DF) 11:26:12.886985 10.23.202.10.32979 > 10.23.202.31.32788: . ack 28961 win 63712 (DF) 11:26:12.886995 10.23.202.10.32979 > 10.23.202.31.32788: . ack 30409 win 63712 (DF) 11:26:12.887027 10.23.202.10.32979 > 10.23.202.31.32788: . ack 31857 win 63712 (DF) 11:26:12.887035 10.23.202.10.32979 > 10.23.202.31.32788: . ack 32769 win 63712 (DF) 11:26:12.887151 10.23.202.31.32788 > 10.23.202.10.32979: . 32769:34217(1448) ack 1 win 1460 (DF) 11:26:12.887161 10.23.202.31.32788 > 10.23.202.10.32979: . 34217:35665(1448) ack 1 win 1460 (DF) 11:26:12.887167 10.23.202.31.32788 > 10.23.202.10.32979: . 35665:37113(1448) ack 1 win 1460 (DF) 11:26:12.887172 10.23.202.31.32788 > 10.23.202.10.32979: . 37113:38561(1448) ack 1 win 1460 (DF) 11:26:12.887225 10.23.202.31.32788 > 10.23.202.10.32979: . 38561:40009(1448) ack 1 win 1460 (DF) 11:26:12.887231 10.23.202.31.32788 > 10.23.202.10.32979: . 40009:41457(1448) ack 1 win 1460 (DF) 11:26:12.887237 10.23.202.31.32788 > 10.23.202.10.32979: . 41457:42905(1448) ack 1 win 1460 (DF) 11:26:12.887283 10.23.202.31.32788 > 10.23.202.10.32979: . 42905:44353(1448) ack 1 win 1460 (DF) 11:26:12.887289 10.23.202.31.32788 > 10.23.202.10.32979: . 44353:45801(1448) ack 1 win 1460 (DF) 11:26:12.887343 10.23.202.31.32788 > 10.23.202.10.32979: . 45801:47249(1448) ack 1 win 1460 (DF) 11:26:12.887349 10.23.202.31.32788 > 10.23.202.10.32979: . 47249:48697(1448) ack 1 win 1460 (DF) 11:26:12.887355 10.23.202.31.32788 > 10.23.202.10.32979: . 48697:50145(1448) ack 1 win 1460 (DF) 11:26:12.887362 10.23.202.31.32788 > 10.23.202.10.32979: P 50145:51593(1448) ack 1 win 1460 (DF) 11:26:12.887369 10.23.202.31.32788 > 10.23.202.10.32979: . 51593:53041(1448) ack 1 win 1460 (DF) 11:26:12.887377 10.23.202.31.32788 > 10.23.202.10.32979: . 53041:54489(1448) ack 1 win 1460 (DF) 11:26:12.887383 10.23.202.31.32788 > 10.23.202.10.32979: . 54489:55937(1448) ack 1 win 1460 (DF) 11:26:12.887389 10.23.202.31.32788 > 10.23.202.10.32979: . 55937:57385(1448) ack 1 win 1460 (DF) 11:26:12.887413 10.23.202.31.32788 > 10.23.202.10.32979: . 57385:58833(1448) ack 1 win 1460 (DF) 11:26:12.887419 10.23.202.31.32788 > 10.23.202.10.32979: . 58833:60281(1448) ack 1 win 1460 (DF) 11:26:12.887425 10.23.202.31.32788 > 10.23.202.10.32979: . 60281:61729(1448) ack 1 win 1460 (DF) 11:26:12.887431 10.23.202.31.32788 > 10.23.202.10.32979: . 61729:63177(1448) ack 1 win 1460 (DF) 11:26:12.887622 10.23.202.10.32979 > 10.23.202.31.32788: . ack 63177 win 63712 (DF) 11:26:12.887765 10.23.202.31.32788 > 10.23.202.10.32979: . 63177:64625(1448) ack 1 win 1460 (DF) 11:26:12.887774 10.23.202.31.32788 > 10.23.202.10.32979: . 64625:66073(1448) ack 1 win 1460 (DF) From jchapman@katalix.com Thu Sep 30 02:50:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 02:50:35 -0700 (PDT) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8U9oUeS028034 for ; Thu, 30 Sep 2004 02:50:30 -0700 Received: from cpanel by s14.s14avahost.net with local (Exim 4.42) id 1CCxZh-0008TH-EJ; Thu, 30 Sep 2004 04:50:09 -0500 Received: from 212.56.89.216 ([212.56.89.216]) by www.katalix.com (IMP) with HTTP for ; Thu, 30 Sep 2004 10:50:09 +0100 Message-ID: <1096537809.415bd6d13f7b3@www.katalix.com> Date: Thu, 30 Sep 2004 10:50:09 +0100 From: James Chapman To: herbert@gondor.apana.org.au Cc: hadi@cyberus.ca, pablo@eurodev.net, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Improve behaviour of Netlink Sockets MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.56.89.216 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32001 960] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/horde/imp/compose.php X-Source-Dir: :/base/horde/imp X-archive-position: 9729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 1445 Lines: 32 > On Wed, Sep 29, 2004 at 10:53:43AM +0100, James Chapman wrote: > > > > - Have the kernel keep a list of async messages sent towards each > > socket rather than trying to deliver each message to the app > > immediately. Have the kernel send a netlink event message (say, > > NETLINK_EVENT_WAKEUP) to the app when this queue first goes > > non-empty. No new NETLINK_EVENT_WAKEUP messages are sent until the > > event queue goes empty again. > > > > - On receipt of NETLINK_EVENT_WAKEUP, a process issues a netlink > > GET (or DUMP?) on its netlink socket to read its queued events. > > > > - If the socket event queue overruns, discard new events and flag the > > event queue as having lost messages. When the userspace app reads > > the event queue, it will discover that messages have been lost and > > can then re-read state from the kernel. > > > > - Use a setsockopt on the netlink socket to have the socket configured > > in this polled-event mode. > > That's basically how it works now. Looks like I was proposing something similar to Jamal's intermediate queue. With the above scheme, there would be no need for userspace to periodically poll for events since that would be kicked off by the wakeup message. Also, while events are held in the kernel, they wouldn't be charged to the netlink socket -- instead they'd be limited by a system-wide count, sharing the event resource across all netlink sockets. /james From yasuyuki.kozakai@toshiba.co.jp Thu Sep 30 03:24:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 03:24:05 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UANwVG030332 for ; Thu, 30 Sep 2004 03:23:59 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i8UANTbv006474; Thu, 30 Sep 2004 19:23:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i8UANTg0014894; Thu, 30 Sep 2004 19:23:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id VAA14890 ; Thu, 30 Sep 2004 19:23:29 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id TAA24040; Thu, 30 Sep 2004 19:23:28 +0900 (JST) Received: by toshiba.co.jp id i8UANRGp002783; Thu, 30 Sep 2004 19:23:27 +0900 (JST) Date: Thu, 30 Sep 2004 19:23:26 +0900 (JST) Message-Id: <200409301023.i8UANRGp002783@toshiba.co.jp> To: netdev@oss.sgi.com Cc: usagi-core@linux-ipv6.org Subject: [PATCH]: fixed typo of reassembly.c From: Yasuyuki Kozakai X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev Content-Length: 787 Lines: 23 Hi, This patch fixes byte ordering. Please apply this. Signed-off-by: Yasuyuki KOZAKAI Regards, diff -X dontdiff -Nurp linux-2.6.9-rc3/net/ipv6/reassembly.c linux-2.6.9-rc3-fixed/net/ipv6/reassembly.c --- linux-2.6.9-rc3/net/ipv6/reassembly.c 2004-09-30 18:45:24.014851224 +0900 +++ linux-2.6.9-rc3-fixed/net/ipv6/reassembly.c 2004-09-30 18:51:58.019953344 +0900 @@ -665,7 +665,7 @@ static int ip6_frag_reasm(struct frag_qu head->next = NULL; head->dev = dev; head->stamp = fq->stamp; - head->nh.ipv6h->payload_len = ntohs(payload_len); + head->nh.ipv6h->payload_len = htons(payload_len); *skb_in = head; ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project From okir@suse.de Thu Sep 30 05:14:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 05:14:40 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UCEYeM005108 for ; Thu, 30 Sep 2004 05:14:35 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 3AB81CA53FD; Thu, 30 Sep 2004 14:14:17 +0200 (CEST) Date: Thu, 30 Sep 2004 14:14:08 +0200 From: Olaf Kirch To: netdev@oss.sgi.com Cc: netfilter-devel@lists.netfilter.org Subject: [PATCH] netfilter6 ip6_packet_match doesn't properly skip exthdrs Message-ID: <20040930121408.GG19083@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 9731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 1008 Lines: 24 This patch fixes a bug in the ip6_tables code that tries to skip extension headers. Packets with extension headers were usually not matched because the code was looking at the wrong offset inside the skb. Signed-off-by: Olaf Kirch Index: linux-2.6.8.nf/net/ipv6/netfilter/ip6_tables.c =================================================================== --- linux-2.6.8.nf.orig/net/ipv6/netfilter/ip6_tables.c 2004-09-30 14:07:51.000000000 +0200 +++ linux-2.6.8.nf/net/ipv6/netfilter/ip6_tables.c 2004-09-30 14:07:57.000000000 +0200 @@ -219,7 +219,7 @@ u_int16_t ptr; /* Header offset in skb */ u_int16_t hdrlen; /* Header */ - ptr = IPV6_HDR_LEN; + ptr = ((char *) ipv6 - (char *) skb->data) + IPV6_HDR_LEN; while (ip6t_ext_hdr(currenthdr)) { /* Is there enough space for the next ext header? */ -- Olaf Kirch | Things that make Monday morning interesting, #1: okir@suse.de | "I want to use NFS over AX25, can you help me?" ---------------+ From okir@suse.de Thu Sep 30 05:16:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 05:16:42 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UCGbva005384 for ; Thu, 30 Sep 2004 05:16:37 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 7F2FACA549F; Thu, 30 Sep 2004 14:16:20 +0200 (CEST) Date: Thu, 30 Sep 2004 14:16:20 +0200 From: Olaf Kirch To: netdev@oss.sgi.com Cc: netfilter-devel@lists.netfilter.org Subject: [PATCH] netfilter6: Skip extension headers when matching icmp6-type Message-ID: <20040930121620.GH19083@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 9732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 1834 Lines: 55 This patch fixes a bug in the ip6_tables code when matching ICMP type and code within ICMPv6 packets. The icmpv6 packet matcher expects the nexthdr to be ICMPv6 and does not deal with hop-by-hop headers etc. Signed-off-by: Olaf Kirch Index: linux-2.6.8.nf/net/ipv6/netfilter/ip6_tables.c =================================================================== --- linux-2.6.8.nf.orig/net/ipv6/netfilter/ip6_tables.c 2004-08-26 13:22:35.000000000 +0200 +++ linux-2.6.8.nf/net/ipv6/netfilter/ip6_tables.c 2004-09-30 14:07:51.000000000 +0200 @@ -1751,10 +1751,23 @@ u_int16_t datalen, int *hotdrop) { - const struct icmp6hdr *icmp = hdr; + struct icmp6hdr icmph; const struct ip6t_icmp *icmpinfo = matchinfo; + int hdroff; + u8 nexthdr = skb->nh.ipv6h->nexthdr; - if (offset == 0 && datalen < 2) { + /* Must not be a fragment. */ + if (offset) + return 0; + + hdroff = (u8*)(skb->nh.ipv6h+1) - skb->data; + hdroff = ipv6_skip_exthdr(skb, hdroff, &nexthdr, skb->len - hdroff); + if (hdroff < 0 || hdroff > skb->len || nexthdr != IPPROTO_ICMPV6) { + *hotdrop = 1; + return 0; + } + + if (skb_copy_bits(skb, hdroff, &icmph, sizeof(icmph)) < 0) { /* We've been asked to examine this packet, and we can't. Hence, no choice but to drop. */ duprintf("Dropping evil ICMP tinygram.\n"); @@ -1763,11 +1776,10 @@ } /* Must not be a fragment. */ - return !offset - && icmp6_type_code_match(icmpinfo->type, + return icmp6_type_code_match(icmpinfo->type, icmpinfo->code[0], icmpinfo->code[1], - icmp->icmp6_type, icmp->icmp6_code, + icmph.icmp6_type, icmph.icmp6_code, !!(icmpinfo->invflags&IP6T_ICMP_INV)); } -- Olaf Kirch | Things that make Monday morning interesting, #1: okir@suse.de | "I want to use NFS over AX25, can you help me?" ---------------+ From yoshfuji@linux-ipv6.org Thu Sep 30 05:28:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 05:29:00 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UCSsWE012055 for ; Thu, 30 Sep 2004 05:28:55 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 6351433CE5; Thu, 30 Sep 2004 21:29:02 +0900 (JST) Date: Thu, 30 Sep 2004 21:29:01 +0900 (JST) Message-Id: <20040930.212901.81655011.yoshfuji@linux-ipv6.org> To: okir@suse.de Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040930121620.GH19083@suse.de> References: <20040930121620.GH19083@suse.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 507 Lines: 13 In article <20040930121620.GH19083@suse.de> (at Thu, 30 Sep 2004 14:16:20 +0200), Olaf Kirch says: > + > + if (skb_copy_bits(skb, hdroff, &icmph, sizeof(icmph)) < 0) { > /* We've been asked to examine this packet, and we > can't. Hence, no choice but to drop. */ > duprintf("Dropping evil ICMP tinygram.\n"); Please use skb_header_pointer(). Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yasuyuki.kozakai@toshiba.co.jp Thu Sep 30 05:39:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 05:39:54 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UCdmBP012531 for ; Thu, 30 Sep 2004 05:39:49 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i8UCdBbv019544; Thu, 30 Sep 2004 21:39:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i8UCdBV9010355; Thu, 30 Sep 2004 21:39:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id XAA10354 ; Thu, 30 Sep 2004 21:39:11 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id VAA14854; Thu, 30 Sep 2004 21:39:10 +0900 (JST) Received: by toshiba.co.jp id i8UCdACm005816; Thu, 30 Sep 2004 21:39:10 +0900 (JST) Date: Thu, 30 Sep 2004 21:39:09 +0900 (JST) Message-Id: <200409301239.i8UCdACm005816@toshiba.co.jp> To: okir@suse.de Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type From: Yasuyuki Kozakai In-Reply-To: <20040930121620.GH19083@suse.de> References: <20040930121620.GH19083@suse.de> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev Content-Length: 2482 Lines: 78 Thanks. and maybe current kernel has same problem in ip6t_multiport.c, too. But I already sent a patch which fixes this problem to this ml. See https://lists.netfilter.org/pipermail/netfilter-devel/2004-September/016783.html and https://lists.netfilter.org/pipermail/netfilter-devel/2004-September/016851.html Regards, ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project From: Olaf Kirch Date: Thu, 30 Sep 2004 14:16:20 +0200 > > This patch fixes a bug in the ip6_tables code when matching ICMP type and > code within ICMPv6 packets. The icmpv6 packet matcher expects the nexthdr > to be ICMPv6 and does not deal with hop-by-hop headers etc. > > Signed-off-by: Olaf Kirch > > Index: linux-2.6.8.nf/net/ipv6/netfilter/ip6_tables.c > =================================================================== > --- linux-2.6.8.nf.orig/net/ipv6/netfilter/ip6_tables.c 2004-08-26 13:22:35.000000000 +0200 > +++ linux-2.6.8.nf/net/ipv6/netfilter/ip6_tables.c 2004-09-30 14:07:51.000000000 +0200 > @@ -1751,10 +1751,23 @@ > u_int16_t datalen, > int *hotdrop) > { > - const struct icmp6hdr *icmp = hdr; > + struct icmp6hdr icmph; > const struct ip6t_icmp *icmpinfo = matchinfo; > + int hdroff; > + u8 nexthdr = skb->nh.ipv6h->nexthdr; > > - if (offset == 0 && datalen < 2) { > + /* Must not be a fragment. */ > + if (offset) > + return 0; > + > + hdroff = (u8*)(skb->nh.ipv6h+1) - skb->data; > + hdroff = ipv6_skip_exthdr(skb, hdroff, &nexthdr, skb->len - hdroff); > + if (hdroff < 0 || hdroff > skb->len || nexthdr != IPPROTO_ICMPV6) { > + *hotdrop = 1; > + return 0; > + } > + > + if (skb_copy_bits(skb, hdroff, &icmph, sizeof(icmph)) < 0) { > /* We've been asked to examine this packet, and we > can't. Hence, no choice but to drop. */ > duprintf("Dropping evil ICMP tinygram.\n"); > @@ -1763,11 +1776,10 @@ > } > > /* Must not be a fragment. */ > - return !offset > - && icmp6_type_code_match(icmpinfo->type, > + return icmp6_type_code_match(icmpinfo->type, > icmpinfo->code[0], > icmpinfo->code[1], > - icmp->icmp6_type, icmp->icmp6_code, > + icmph.icmp6_type, icmph.icmp6_code, > !!(icmpinfo->invflags&IP6T_ICMP_INV)); > } > > -- > Olaf Kirch | Things that make Monday morning interesting, #1: > okir@suse.de | "I want to use NFS over AX25, can you help me?" > ---------------+ > > From yasuyuki.kozakai@toshiba.co.jp Thu Sep 30 05:44:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 05:45:04 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UCiw7X012935 for ; Thu, 30 Sep 2004 05:44:58 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i8UCiebv022400; Thu, 30 Sep 2004 21:44:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i8UCieRc014218; Thu, 30 Sep 2004 21:44:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id XAA14217 ; Thu, 30 Sep 2004 21:44:40 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id VAA17397; Thu, 30 Sep 2004 21:44:40 +0900 (JST) Received: by toshiba.co.jp id i8UCid17009482; Thu, 30 Sep 2004 21:44:40 +0900 (JST) Date: Thu, 30 Sep 2004 21:44:38 +0900 (JST) Message-Id: <200409301244.i8UCid17009482@toshiba.co.jp> To: yasuyuki.kozakai@toshiba.co.jp Cc: okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type From: Yasuyuki Kozakai In-Reply-To: <200409301239.i8UCdACm005816@toshiba.co.jp> References: <20040930121620.GH19083@suse.de> <200409301239.i8UCdACm005816@toshiba.co.jp> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev Content-Length: 498 Lines: 13 From: Yasuyuki Kozakai Date: Thu, 30 Sep 2004 21:39:09 +0900 (JST) > Thanks. and maybe current kernel has same problem in ip6t_multiport.c, too. > But I already sent a patch which fixes this problem to this ml. Sorry, I sent it to only netfilter-devel ml because I wanted someone to test it more before sending it to netdev ml. ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project From linville@ra.tuxdriver.com Thu Sep 30 07:27:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 07:27:58 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UERp6o015266 for ; Thu, 30 Sep 2004 07:27:52 -0700 Received: (from linville@localhost) by ra.tuxdriver.com (8.11.6/8.11.6) id i8UDE7v11701; Thu, 30 Sep 2004 09:14:07 -0400 Date: Thu, 30 Sep 2004 09:14:07 -0400 From: "John W. Linville" To: Donald Becker Cc: netdev@oss.sgi.com Subject: Re: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod Message-ID: <20040930091407.A10417@tuxdriver.com> Mail-Followup-To: Donald Becker , netdev@oss.sgi.com References: <20040928145455.C12480@tuxdriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from becker@scyld.com on Wed, Sep 29, 2004 at 01:16:01PM -0400 X-archive-position: 9736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 2530 Lines: 60 On Wed, Sep 29, 2004 at 01:16:01PM -0400, Donald Becker wrote: > This 3c59x.c code was changed in 2001 to mask the transceiver reset and > shut the chip down cleanly. This occurred in two steps, with a > discussion on the vortex mailing list for each. > 3c59x.c:v0.99Uc 12/5/2001 > 3c59x.c:v0.99T 7/16/2001 > The December change was noted as specifically for the 3c905B. Don, I'm having trouble finding the discussions you referenced. I think I found the discussion related to the v0.99T change in the vortex-bug archives, but I never did find the discussion for the v0.99Uc in either the vortex or vortex-bug archives (or any of the other lists that looked to possibly be related). Since you seem to have already found them, would you mind sending me a more precise link? Thanks! Also, how can I look at the version history for the 3c59x.c that you maintain? Is it in CVS (or BK or something similar) where I may access it? > > module). Changing vortex_remove_one() to allow the auto-initialize > > state machine logic to be reset when the module is removed alleviates > > this problem. > > ...and creates a new problem: resetting the link causes operational > problems on many networks. The most obvious example is spanning tree > detection delays on switches, where the switch does not pass traffic. To be clear, were you looking at the version of the patch I posted on the netdev list? Or the version in Red Hat's Bugzilla? In the bugzilla patch, I had none of the bits masked, while in the netdev patch I left the networkReset bit masked. Does allowing the aismReset to occur cause the link to go down? I guess I presumed that was what the networkReset bit was there to prevent. Even if the link does go down, is that really such a bit deal on an rmmod? I can see wanting to avoid it on a normal close, but an rmmod would seem like a more rare event. > The correct solution is to reset the transceiver (and thus cause > re-autonegotiation) only if a problem is detected, not an unconditional > or proactive reset. The reset is already there, I was just letting it do more. The cards that have this problem just don't come back w/o this reset. There is a TxReset that occurs on the transmit underrun condition. Are you suggesting that a TotalReset should occur instead? John P.S. The current state of the reset at rmmod seems to have come in the 2.4.9 timeframe. Prior to that, FWIW all but one card left the aismReset bit unmasked just as in my patch. -- John W. Linville linville@tuxdriver.com From kaber@trash.net Thu Sep 30 07:49:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 07:49:14 -0700 (PDT) Received: from gw.localnet ([62.206.217.67]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UEn8Xx016033 for ; Thu, 30 Sep 2004 07:49:09 -0700 Received: from [172.16.1.123] (helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1CD2LH-0000Ih-00; Thu, 30 Sep 2004 16:55:35 +0200 Message-ID: <415C1CC9.2090604@trash.net> Date: Thu, 30 Sep 2004 16:48:41 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Yasuyuki Kozakai CC: okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type References: <20040930121620.GH19083@suse.de> <200409301239.i8UCdACm005816@toshiba.co.jp> <200409301244.i8UCid17009482@toshiba.co.jp> In-Reply-To: <200409301244.i8UCid17009482@toshiba.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 569 Lines: 24 Yasuyuki Kozakai wrote: >From: Yasuyuki Kozakai >Date: Thu, 30 Sep 2004 21:39:09 +0900 (JST) > > > >>Thanks. and maybe current kernel has same problem in ip6t_multiport.c, too. >>But I already sent a patch which fixes this problem to this ml. >> >> > >Sorry, I sent it to only netfilter-devel ml because I wanted someone to test >it more before sending it to netdev ml. > > I've reviewed the patch, I think we can push it soon. Did you do any changes besides the u_int8_t fix since the last patch you sent ? Regards Patrick From laforge@gnumonks.org Thu Sep 30 08:48:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 08:48:29 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UFmHRM020446 for ; Thu, 30 Sep 2004 08:48:18 -0700 Received: from dsl-213-023-154-128.arcor-ip.net ([213.23.154.128] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1CD39z-0007We-AK; Thu, 30 Sep 2004 17:47:59 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1CD39t-0001XY-AM; Thu, 30 Sep 2004 17:47:53 +0200 Date: Thu, 30 Sep 2004 17:47:53 +0200 From: Harald Welte To: David Miller Cc: Linux Netdev List Subject: [PATCH 2.4] backport neighbour cache redesign Message-ID: <20040930154753.GD1860@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+vcRm3WFmV0Q/ShD" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i X-archive-position: 9738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@gnumonks.org Precedence: bulk X-list: netdev Content-Length: 61880 Lines: 2338 --+vcRm3WFmV0Q/ShD Content-Type: multipart/mixed; boundary="7tPHY7RFL01rOa8z" Content-Disposition: inline --7tPHY7RFL01rOa8z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! I've now finished the 2.4.x backport of the neighbour cache redesign. The patch applies to 2.4.28-pre3-bk5. It compiles cleanly, and ipv4/ipv6 are working as expected. I don't have a decnet or atm test setup, so I leave testing to somebody else ;) Let's hope I didn't introduce new bugs, the merging got a bit ugly since percpu is missing and (more important) 2.4.x networking didn't yet use seq_file. So in some cases like ATM, clip is now using seq_file, while everything else uses the old get_info() proc methods. Cheers, Harald --=20 - Harald Welte http://www.gnumonks.org/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Programming is like sex: One mistake and you have to support it your lifeti= me --7tPHY7RFL01rOa8z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="2.4.28-pre3-bk5-neigh26.patch" Content-Transfer-Encoding: quoted-printable diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/drivers/net/bonding/bond_main.c linux-2.4.28-pre3-bk5-= neigh/drivers/net/bonding/bond_main.c --- linux-2.4.28-pre3-bk5-plain/drivers/net/bonding/bond_main.c 2004-04-14 = 15:05:30.000000000 +0200 +++ linux-2.4.28-pre3-bk5-neigh/drivers/net/bonding/bond_main.c 2004-09-30 = 14:16:12.000000000 +0200 @@ -3086,8 +3086,6 @@ =20 #ifdef CONFIG_PROC_FS =20 -#define SEQ_START_TOKEN ((void *)1) - static void *bond_info_seq_start(struct seq_file *seq, loff_t *pos) { struct bonding *bond =3D seq->private; diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/fs/proc/root.c linux-2.4.28-pre3-bk5-neigh/fs/proc/roo= t.c --- linux-2.4.28-pre3-bk5-plain/fs/proc/root.c 2002-08-03 02:39:45.00000000= 0 +0200 +++ linux-2.4.28-pre3-bk5-neigh/fs/proc/root.c 2004-09-30 11:35:52.00000000= 0 +0200 @@ -17,7 +17,7 @@ #include #include =20 -struct proc_dir_entry *proc_net, *proc_bus, *proc_root_fs, *proc_root_driv= er; +struct proc_dir_entry *proc_net, *proc_net_stat, *proc_bus, *proc_root_fs,= *proc_root_driver; =20 #ifdef CONFIG_SYSCTL struct proc_dir_entry *proc_sys_root; @@ -38,6 +38,8 @@ } proc_misc_init(); proc_net =3D proc_mkdir("net", 0); + proc_net_stat =3D proc_mkdir("net/stat", NULL); + #ifdef CONFIG_SYSVIPC proc_mkdir("sysvipc", 0); #endif @@ -143,5 +145,6 @@ EXPORT_SYMBOL(proc_root); EXPORT_SYMBOL(proc_root_fs); EXPORT_SYMBOL(proc_net); +EXPORT_SYMBOL(proc_net_stat); EXPORT_SYMBOL(proc_bus); EXPORT_SYMBOL(proc_root_driver); diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/include/linux/proc_fs.h linux-2.4.28-pre3-bk5-neigh/in= clude/linux/proc_fs.h --- linux-2.4.28-pre3-bk5-plain/include/linux/proc_fs.h 2003-11-28 19:26:21= =2E000000000 +0100 +++ linux-2.4.28-pre3-bk5-neigh/include/linux/proc_fs.h 2004-09-30 16:34:36= =2E000000000 +0200 @@ -79,6 +79,7 @@ extern struct proc_dir_entry proc_root; extern struct proc_dir_entry *proc_root_fs; extern struct proc_dir_entry *proc_net; +extern struct proc_dir_entry *proc_net_stat; extern struct proc_dir_entry *proc_bus; extern struct proc_dir_entry *proc_root_driver; extern struct proc_dir_entry *proc_root_kcore; @@ -170,6 +171,16 @@ return create_proc_info_entry(name,mode,proc_net,get_info); } =20 +static inline struct proc_dir_entry *proc_net_fops_create(const char *name, + mode_t mode, struct file_operations *fops) +{ + struct proc_dir_entry *res =3D create_proc_entry(name, mode, proc_net); + + if (res) + res->proc_fops =3D fops; + return res; +} + static inline void proc_net_remove(const char *name) { remove_proc_entry(name,proc_net); diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/include/linux/seq_file.h linux-2.4.28-pre3-bk5-neigh/i= nclude/linux/seq_file.h --- linux-2.4.28-pre3-bk5-plain/include/linux/seq_file.h 2004-09-30 14:08:5= 3.000000000 +0200 +++ linux-2.4.28-pre3-bk5-neigh/include/linux/seq_file.h 2004-09-30 14:15:3= 5.000000000 +0200 @@ -65,5 +65,8 @@ int single_open(struct file *, int (*)(struct seq_file *, void *), void *); int single_release(struct inode *, struct file *); int seq_release_private(struct inode *, struct file *); + +#define SEQ_START_TOKEN ((void *)1) + #endif #endif diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/include/net/dn_neigh.h linux-2.4.28-pre3-bk5-neigh/inc= lude/net/dn_neigh.h --- linux-2.4.28-pre3-bk5-plain/include/net/dn_neigh.h 2000-03-02 19:13:16.= 000000000 +0100 +++ linux-2.4.28-pre3-bk5-neigh/include/net/dn_neigh.h 2004-09-30 11:36:35.= 000000000 +0200 @@ -18,7 +18,6 @@ =20 extern void dn_neigh_init(void); extern void dn_neigh_cleanup(void); -extern struct neighbour *dn_neigh_lookup(struct neigh_table *tbl, void *pt= r); extern int dn_neigh_router_hello(struct sk_buff *skb); extern int dn_neigh_endnode_hello(struct sk_buff *skb); extern void dn_neigh_pointopoint_hello(struct sk_buff *skb); diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/include/net/neighbour.h linux-2.4.28-pre3-bk5-neigh/in= clude/net/neighbour.h --- linux-2.4.28-pre3-bk5-plain/include/net/neighbour.h 2004-09-30 11:31:17= =2E000000000 +0200 +++ linux-2.4.28-pre3-bk5-neigh/include/net/neighbour.h 2004-09-30 14:16:33= =2E000000000 +0200 @@ -7,6 +7,11 @@ * Authors: * Pedro Roque * Alexey Kuznetsov + * + * Changes: + * + * Harald Welte: + * - Add neighbour cache statistics like rtstat */ =20 /* The following flags & states are exported to user space, @@ -45,6 +50,7 @@ =20 #include #include +#include =20 #define NUD_IN_TIMER (NUD_INCOMPLETE|NUD_DELAY|NUD_PROBE) #define NUD_VALID (NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STA= LE|NUD_DELAY) @@ -78,12 +84,25 @@ =20 struct neigh_statistics { - unsigned long allocs; - unsigned long res_failed; - unsigned long rcv_probes_mcast; - unsigned long rcv_probes_ucast; + unsigned long allocs; /* number of allocated neighs */ + unsigned long destroys; /* number of destroyed neighs */ + unsigned long hash_grows; /* number of hash resizes */ + + unsigned long res_failed; /* nomber of failed resolutions */ + + unsigned long lookups; /* number of lookups */ + unsigned long hits; /* number of hits (among lookups) */ + + unsigned long rcv_probes_mcast; /* number of received mcast ipv6 */ + unsigned long rcv_probes_ucast; /* number of received ucast ipv6 */ + + unsigned long periodic_gc_runs; /* number of periodic GC runs */ + unsigned long forced_gc_runs; /* number of forced GC runs */ }; =20 +#define NEIGH_CACHE_STAT_INC(tbl, field) \ + ((tbl)->stats[smp_processor_id()].field++) + struct neighbour { struct neighbour *next; @@ -128,9 +147,6 @@ u8 key[0]; }; =20 -#define NEIGH_HASHMASK 0x1F -#define PNEIGH_HASHMASK 0xF - /* * neighbour table manipulation */ @@ -164,9 +180,15 @@ struct neigh_parms *parms_list; kmem_cache_t *kmem_cachep; struct tasklet_struct gc_task; - struct neigh_statistics stats; - struct neighbour *hash_buckets[NEIGH_HASHMASK+1]; - struct pneigh_entry *phash_buckets[PNEIGH_HASHMASK+1]; + struct neigh_statistics stats[NR_CPUS]; + struct neighbour **hash_buckets; + unsigned int hash_mask; + __u32 hash_rnd; + unsigned int hash_chain_gc; + struct pneigh_entry **phash_buckets; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *pde; +#endif }; =20 extern void neigh_table_init(struct neigh_table *tbl); @@ -174,6 +196,8 @@ extern struct neighbour * neigh_lookup(struct neigh_table *tbl, const void *pkey, struct net_device *dev); +extern struct neighbour * neigh_lookup_nodev(struct neigh_table *tbl, + const void *pkey); extern struct neighbour * neigh_create(struct neigh_table *tbl, const void *pkey, struct net_device *dev); @@ -205,6 +229,24 @@ extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *a= rg); extern void neigh_app_ns(struct neighbour *n); =20 +extern void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neig= hbour *, void *), void *cookie); +extern void __neigh_for_each_release(struct neigh_table *tbl, int (*cb)(st= ruct neighbour *)); +extern void pneigh_for_each(struct neigh_table *tbl, void (*cb)(struct pne= igh_entry *)); + +struct neigh_seq_state { + struct neigh_table *tbl; + void *(*neigh_sub_iter)(struct neigh_seq_state *state, + struct neighbour *n, loff_t *pos); + unsigned int bucket; + unsigned int flags; +#define NEIGH_SEQ_NEIGH_ONLY 0x00000001 +#define NEIGH_SEQ_IS_PNEIGH 0x00000002 +#define NEIGH_SEQ_SKIP_NOARP 0x00000004 +}; +extern void *neigh_seq_start(struct seq_file *, loff_t *, struct neigh_tab= le *, unsigned int); +extern void *neigh_seq_next(struct seq_file *, void *, loff_t *); +extern void neigh_seq_stop(struct seq_file *, void *); + extern int neigh_sysctl_register(struct net_device *dev, struct neigh_pa= rms *p, int p_id, int pdev_id, char *p_name); extern void neigh_sysctl_unregister(struct neigh_parms *p); diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/atm/clip.c linux-2.4.28-pre3-bk5-neigh/net/atm/cli= p.c --- linux-2.4.28-pre3-bk5-plain/net/atm/clip.c 2004-02-18 14:36:32.00000000= 0 +0100 +++ linux-2.4.28-pre3-bk5-neigh/net/atm/clip.c 2004-09-30 12:50:09.00000000= 0 +0200 @@ -1,6 +1,10 @@ /* net/atm/clip.c - RFC1577 Classical IP over ATM */ =20 -/* Written 1995-2000 by Werner Almesberger, EPFL LRC/ICA */ +/* Written 1995-2000 by Werner Almesberger, EPFL LRC/ICA=20 + * + * Changes: + * Harald Welte : + * - backport DaveM's generalized neighbour cache from 2.6.9-rcX */ =20 =20 #include @@ -24,6 +28,7 @@ #include /* for IFF_UP */ #include #include +#include #include /* for struct rtable and routing */ #include /* icmp_send */ #include /* for HZ */ @@ -119,64 +124,49 @@ spin_unlock_bh(&entry->neigh->dev->xmit_lock); } =20 - -static void idle_timer_check(unsigned long dummy) +/* The neighbour entry n->lock is held. */ +static int neigh_check_cb(struct neighbour *n) { - int i; + struct atmarp_entry *entry =3D NEIGH2ENTRY(n); + struct clip_vcc *cv; =20 - /*DPRINTK("idle_timer_check\n");*/ - write_lock(&clip_tbl.lock); - for (i =3D 0; i <=3D NEIGH_HASHMASK; i++) { - struct neighbour **np; + for (cv =3D entry->vccs; cv; cv =3D cv->next) { + unsigned long exp =3D cv->last_use + cv->idle_timeout; =20 - for (np =3D &clip_tbl.hash_buckets[i]; *np;) { - struct neighbour *n =3D *np; - struct atmarp_entry *entry =3D NEIGH2ENTRY(n); - struct clip_vcc *clip_vcc; - - write_lock(&n->lock); - - for (clip_vcc =3D entry->vccs; clip_vcc; - clip_vcc =3D clip_vcc->next) - if (clip_vcc->idle_timeout && - time_after(jiffies, clip_vcc->last_use+ - clip_vcc->idle_timeout)) { - DPRINTK("releasing vcc %p->%p of " - "entry %p\n",clip_vcc,clip_vcc->vcc, - entry); - vcc_release_async(clip_vcc->vcc, - -ETIMEDOUT); - } - if (entry->vccs || - time_before(jiffies, entry->expires)) { - np =3D &n->next; - write_unlock(&n->lock); - continue; - } - if (atomic_read(&n->refcnt) > 1) { - struct sk_buff *skb; - - DPRINTK("destruction postponed with ref %d\n", - atomic_read(&n->refcnt)); - while ((skb =3D skb_dequeue(&n->arp_queue)) !=3D - NULL)=20 - dev_kfree_skb(skb); - np =3D &n->next; - write_unlock(&n->lock); - continue; - } - *np =3D n->next; - DPRINTK("expired neigh %p\n",n); - n->dead =3D 1; - write_unlock(&n->lock); - neigh_release(n); + if (cv->idle_timeout && time_after(jiffies, exp)) { + DPRINTK("releasing vcc %p->%p of entry %p\n", + cv, cv->vcc, entry); + vcc_release_async(cv->vcc, -ETIMEDOUT); } } + + if (entry->vccs || time_before(jiffies, entry->expires)) + return 0; + + if (atomic_read(&n->refcnt) > 1) { + struct sk_buff *skb; + + DPRINTK("destruction postponed with ref %d\n", + atomic_read(&n->refcnt)); + + while ((skb =3D skb_dequeue(&n->arp_queue)) !=3D NULL)=20 + dev_kfree_skb(skb); + + return 0; + } + + DPRINTK("expired neigh %p\n",n); + return 1; +} + +static void idle_timer_check(unsigned long dummy) +{ + write_lock(&clip_tbl.lock); + __neigh_for_each_release(&clip_tbl, neigh_check_cb); mod_timer(&idle_timer, jiffies+CLIP_CHECK_INTERVAL*HZ); write_unlock(&clip_tbl.lock); } =20 - static int clip_arp_rcv(struct sk_buff *skb) { struct atm_vcc *vcc; @@ -320,15 +310,7 @@ =20 static u32 clip_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val =3D *(u32*)pkey; - hash_val ^=3D (hash_val>>16); - hash_val ^=3D hash_val>>8; - hash_val ^=3D hash_val>>3; - hash_val =3D (hash_val^dev->ifindex)&NEIGH_HASHMASK; - - return hash_val; + return jhash_2words(*(u32 *)pkey, dev->ifindex, clip_tbl.hash_rnd); } =20 =20 diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/atm/proc.c linux-2.4.28-pre3-bk5-neigh/net/atm/pro= c.c --- linux-2.4.28-pre3-bk5-plain/net/atm/proc.c 2003-11-28 19:26:21.00000000= 0 +0100 +++ linux-2.4.28-pre3-bk5-neigh/net/atm/proc.c 2004-09-30 15:01:36.00000000= 0 +0200 @@ -90,74 +90,202 @@ =20 #if defined(CONFIG_ATM_CLIP) || defined(CONFIG_ATM_CLIP_MODULE) =20 +#define SEQ_NO_VCC_TOKEN ((void *) 2) =20 -static int svc_addr(char *buf,struct sockaddr_atmsvc *addr) +static void svc_addr(struct seq_file *seq, struct sockaddr_atmsvc *addr) { static int code[] =3D { 1,2,10,6,1,0 }; static int e164[] =3D { 1,8,4,6,1,0 }; - int *fields; - int len,i,j,pos; =20 - len =3D 0; if (*addr->sas_addr.pub) { - strcpy(buf,addr->sas_addr.pub); - len =3D strlen(addr->sas_addr.pub); - buf +=3D len; - if (*addr->sas_addr.prv) { - *buf++ =3D '+'; - len++; - } + seq_printf(seq, "%s", addr->sas_addr.pub); + if (*addr->sas_addr.prv) + seq_putc(seq, '+'); + } else if (!*addr->sas_addr.prv) { + seq_printf(seq, "%s", "(none)"); + return; } - else if (!*addr->sas_addr.prv) { - strcpy(buf,"(none)"); - return strlen(buf); - } if (*addr->sas_addr.prv) { - len +=3D 44; - pos =3D 0; - fields =3D *addr->sas_addr.prv =3D=3D ATM_AFI_E164 ? e164 : code; + unsigned char *prv =3D addr->sas_addr.prv; + int *fields; + int i, j; + + fields =3D *prv =3D=3D ATM_AFI_E164 ? e164 : code; for (i =3D 0; fields[i]; i++) { - for (j =3D fields[i]; j; j--) { - sprintf(buf,"%02X",addr->sas_addr.prv[pos++]); - buf +=3D 2; - } - if (fields[i+1]) *buf++ =3D '.'; + for (j =3D fields[i]; j; j--) + seq_printf(seq, "%02X", *prv++); + if (fields[i+1])=20 + seq_putc(seq, '.'); } } - return len; } =20 =20 -static void atmarp_info(struct net_device *dev,struct atmarp_entry *entry, - struct clip_vcc *clip_vcc,char *buf) -{ - unsigned char *ip; - int svc,off,ip_len; +static void atmarp_info(struct seq_file *seq, struct net_device *dev,struct + atmarp_entry *entry, struct clip_vcc *clip_vcc) { + unsigned long exp; + char buf[17]; + int svc, llc, off; + + svc =3D ((clip_vcc =3D=3D SEQ_NO_VCC_TOKEN) || + (clip_vcc->vcc->sk->family =3D=3D AF_ATMSVC)); + + llc =3D ((clip_vcc =3D=3D SEQ_NO_VCC_TOKEN) || + (clip_vcc->encap)); + + if (clip_vcc =3D=3D SEQ_NO_VCC_TOKEN) + exp =3D entry->neigh->used; + else + exp =3D clip_vcc->last_use; + + exp =3D (jiffies - exp) / HZ; + + seq_printf(seq, "%-6s%-4s%-4s%5ld ", + dev->name, + svc ? "SVC" : "PVC", + llc ? "LLC" : "NULL", + exp); =20 - svc =3D !clip_vcc || clip_vcc->vcc->sk->family =3D=3D AF_ATMSVC; - off =3D sprintf(buf,"%-6s%-4s%-4s%5ld ",dev->name,svc ? "SVC" : "PVC", - !clip_vcc || clip_vcc->encap ? "LLC" : "NULL", - (jiffies-(clip_vcc ? clip_vcc->last_use : entry->neigh->used))/ - HZ); - ip =3D (unsigned char *) &entry->ip; - ip_len =3D sprintf(buf+off,"%d.%d.%d.%d",ip[0],ip[1],ip[2],ip[3]); - off +=3D ip_len; - while (ip_len++ < 16) buf[off++] =3D ' '; - if (!clip_vcc) + off =3D snprintf(buf, sizeof(buf)-1, "%d.%d.%d.%d", NIPQUAD(entry->ip)); + while (off < 16) + buf[off++] =3D ' '; + buf[off] =3D '\0'; + seq_printf(seq, "%s", buf); + + if (clip_vcc =3D=3D SEQ_NO_VCC_TOKEN) { if (time_before(jiffies, entry->expires)) - strcpy(buf+off,"(resolving)\n"); - else sprintf(buf+off,"(expired, ref %d)\n", - atomic_read(&entry->neigh->refcnt)); - else if (!svc) - sprintf(buf+off,"%d.%d.%d\n",clip_vcc->vcc->dev->number, - clip_vcc->vcc->vpi,clip_vcc->vcc->vci); - else { - off +=3D svc_addr(buf+off,&clip_vcc->vcc->remote); - strcpy(buf+off,"\n"); + seq_printf(seq, "(resolving)\n"); + else + seq_printf(seq, "(expired, ref %d)\n", + atomic_read(&entry->neigh->refcnt)); + } else if (!svc) { + seq_printf(seq, "%d.%d.%d\n", + clip_vcc->vcc->dev->number, + clip_vcc->vcc->vpi, + clip_vcc->vcc->vci); + } else { + svc_addr(seq, &clip_vcc->vcc->remote); + seq_putc(seq, '\n'); + } +} + +struct clip_seq_state { + /* This member must be first. */ + struct neigh_seq_state ns; + + /* Local to clip specific iteration. */ + struct clip_vcc *vcc; +}; + +static struct clip_vcc *clip_seq_next_vcc(struct atmarp_entry *e, + struct clip_vcc *curr) +{ + if (!curr) { + curr =3D e->vccs; + if (!curr) + return SEQ_NO_VCC_TOKEN; + return curr; + } + + if (curr =3D=3D SEQ_NO_VCC_TOKEN) + return NULL; + + curr =3D curr->next; + + return curr; +} + +static void *clip_seq_vcc_walk(struct clip_seq_state *state, + struct atmarp_entry *e, loff_t *pos) +{ + struct clip_vcc *vcc =3D state->vcc; + + vcc =3D clip_seq_next_vcc(e, vcc); + if (vcc && pos !=3D NULL) { + while (*pos) { + vcc =3D clip_seq_next_vcc(e, vcc); + if (!vcc) + break; + --(*pos); } + } + state->vcc =3D vcc; + + return vcc; } =20 +static void *clip_seq_sub_iter(struct neigh_seq_state *_state, + struct neighbour *n, loff_t *pos) +{ + struct clip_seq_state *state =3D (struct clip_seq_state *) _state; =20 + return clip_seq_vcc_walk(state, NEIGH2ENTRY(n), pos); +} + +static void *clip_seq_start(struct seq_file *seq, loff_t *pos) +{ + return neigh_seq_start(seq, pos, clip_tbl_hook, NEIGH_SEQ_NEIGH_ONLY); +} + +static int clip_seq_show(struct seq_file *seq, void *v) +{ + static char atm_arp_banner[] =3D=20 + "IPitf TypeEncp Idle IP address ATM address\n"; + + if (v =3D=3D SEQ_START_TOKEN) { + seq_puts(seq, atm_arp_banner); + } else { + struct clip_seq_state *state =3D seq->private; + struct neighbour *n =3D v; + struct clip_vcc *vcc =3D state->vcc; + + atmarp_info(seq, n->dev, NEIGH2ENTRY(n), vcc); + } + return 0; +} + +static struct seq_operations arp_seq_ops =3D { + .start =3D clip_seq_start, + .next =3D neigh_seq_next, + .stop =3D neigh_seq_stop, + .show =3D clip_seq_show, +}; + +static int arp_seq_open(struct inode *inode, struct file *file) +{ + struct clip_seq_state *state; + struct seq_file *seq; + int rc =3D -EAGAIN; + + state =3D kmalloc(sizeof(*state), GFP_KERNEL); + if (!state) { + rc =3D -ENOMEM; + goto out_kfree; + } + memset(state, 0, sizeof(*state)); + state->ns.neigh_sub_iter =3D clip_seq_sub_iter; + + rc =3D seq_open(file, &arp_seq_ops); + if (rc) + goto out_kfree; + + seq =3D file->private_data; + seq->private =3D state; +out: + return rc; + +out_kfree: + kfree(state); + goto out; +} + +static struct file_operations arp_seq_fops =3D { + .open =3D arp_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release_private, + .owner =3D THIS_MODULE, +}; #endif =20 =20 @@ -416,6 +544,7 @@ return 0; } =20 +#if 0 #if defined(CONFIG_ATM_CLIP) || defined(CONFIG_ATM_CLIP_MODULE) static int atm_arp_info(loff_t pos,char *buf) { @@ -459,6 +588,7 @@ return 0; } #endif +#endif =20 #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) static int atm_lec_info(loff_t pos,char *buf) @@ -666,7 +796,10 @@ CREATE_ENTRY(svc); CREATE_ENTRY(vc); #if defined(CONFIG_ATM_CLIP) || defined(CONFIG_ATM_CLIP_MODULE) - CREATE_ENTRY(arp); + arp =3D create_proc_entry("arp", S_IRUGO, atm_proc_root); + if (!arp) + goto cleanup; + arp->proc_fops =3D &arp_seq_fops; #endif #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) CREATE_ENTRY(lec); diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/core/neighbour.c linux-2.4.28-pre3-bk5-neigh/net/c= ore/neighbour.c --- linux-2.4.28-pre3-bk5-plain/net/core/neighbour.c 2004-09-30 11:31:17.00= 0000000 +0200 +++ linux-2.4.28-pre3-bk5-neigh/net/core/neighbour.c 2004-09-30 14:21:06.00= 0000000 +0200 @@ -12,6 +12,8 @@ * * Fixes: * Vitaly E. Lavrov releasing NULL neighbor in neigh_add. + * Harald Welte Add neighbour cache statistics like rtstat + * Harald Welte port neighbour cache rework from 2.6.9-rcX */ =20 #include @@ -20,6 +22,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -27,6 +30,7 @@ #include #include #include +#include =20 #define NEIGH_DEBUG 1 =20 @@ -45,6 +49,8 @@ #define NEIGH_PRINTK2 NEIGH_PRINTK #endif =20 +#define PNEIGH_HASHMASK 0xF + static void neigh_timer_handler(unsigned long arg); #ifdef CONFIG_ARPD static void neigh_app_notify(struct neighbour *n); @@ -54,6 +60,7 @@ =20 static int neigh_glbl_allocs; static struct neigh_table *neigh_tables; +static struct file_operations neigh_stat_seq_fops; =20 /* Neighbour hash table buckets are protected with rwlock tbl->lock. @@ -111,27 +118,21 @@ int shrunk =3D 0; int i; =20 - for (i=3D0; i<=3DNEIGH_HASHMASK; i++) { + NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs); + + write_lock_bh(&tbl->lock); + for (i =3D 0; i <=3D tbl->hash_mask; i++) { struct neighbour *n, **np; =20 np =3D &tbl->hash_buckets[i]; - write_lock_bh(&tbl->lock); while ((n =3D *np) !=3D NULL) { /* Neighbour record may be discarded if: - - nobody refers to it. - - it is not permanent - - (NEW and probably wrong) - INCOMPLETE entries are kept at least for - n->parms->retrans_time, otherwise we could - flood network with resolution requests. - It is not clear, what is better table overflow - or flooding. + * - nobody refers to it. + * - it is not permanent */ write_lock(&n->lock); if (atomic_read(&n->refcnt) =3D=3D 1 && - !(n->nud_state&NUD_PERMANENT) && - (n->nud_state !=3D NUD_INCOMPLETE || - jiffies - n->used > n->parms->retrans_time)) { + !(n->nud_state&NUD_PERMANENT)) { *np =3D n->next; n->dead =3D 1; shrunk =3D 1; @@ -142,10 +143,12 @@ write_unlock(&n->lock); np =3D &n->next; } - write_unlock_bh(&tbl->lock); } =09 tbl->last_flush =3D jiffies; + + write_unlock_bh(&tbl->lock); + return shrunk; } =20 @@ -176,7 +179,7 @@ =20 write_lock_bh(&tbl->lock); =20 - for (i=3D0; i <=3D NEIGH_HASHMASK; i++) { + for (i=3D0; i <=3D tbl->hash_mask; i++) { struct neighbour *n, **np; =20 np =3D &tbl->hash_buckets[i]; @@ -203,7 +206,7 @@ =20 write_lock_bh(&tbl->lock); =20 - for (i=3D0; i<=3DNEIGH_HASHMASK; i++) { + for (i =3D 0; i <=3D tbl->hash_mask; i++) { struct neighbour *n, **np; =20 np =3D &tbl->hash_buckets[i]; @@ -277,7 +280,7 @@ init_timer(&n->timer); n->timer.function =3D neigh_timer_handler; n->timer.data =3D (unsigned long)n; - tbl->stats.allocs++; + NEIGH_CACHE_STAT_INC(tbl, allocs); neigh_glbl_allocs++; tbl->entries++; n->tbl =3D tbl; @@ -286,20 +289,103 @@ return n; } =20 +static struct neighbour **neigh_hash_alloc(unsigned int entries) +{ + unsigned long size =3D entries * sizeof(struct neighbour *); + struct neighbour **ret; + + if (size <=3D PAGE_SIZE) { + ret =3D kmalloc(size, GFP_ATOMIC); + } else { + ret =3D (struct neighbour **) + __get_free_pages(GFP_ATOMIC, get_order(size)); + } + if (ret) + memset(ret, 0, size); + + return ret; +} + +static void neigh_hash_free(struct neighbour **hash, unsigned int entries) +{ + unsigned long size =3D entries * sizeof(struct neighbour *); + + if (size <=3D PAGE_SIZE) + kfree(hash); + else + free_pages((unsigned long)hash, get_order(size)); +} + +static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_ent= ries) +{ + struct neighbour **new_hash, **old_hash; + unsigned int i, new_hash_mask, old_entries; + + NEIGH_CACHE_STAT_INC(tbl, hash_grows); + + BUG_ON(new_entries & (new_entries - 1)); + new_hash =3D neigh_hash_alloc(new_entries); + if (!new_hash) + return; + + old_entries =3D tbl->hash_mask + 1; + new_hash_mask =3D new_entries - 1; + old_hash =3D tbl->hash_buckets; + + for (i =3D 0; i < old_entries; i++) { + struct neighbour *n, *next; + + for (n =3D old_hash[i]; n; n =3D next) { + unsigned int hash_val =3D tbl->hash(n->primary_key, n->dev); + + hash_val &=3D new_hash_mask; + next =3D n->next; + + n->next =3D new_hash[hash_val]; + new_hash[hash_val] =3D n; + } + } + tbl->hash_buckets =3D new_hash; + tbl->hash_mask =3D new_hash_mask; + + neigh_hash_free(old_hash, old_entries); +} + struct neighbour *neigh_lookup(struct neigh_table *tbl, const void *pkey, struct net_device *dev) { struct neighbour *n; - u32 hash_val; int key_len =3D tbl->key_len; + u32 hash_val =3D tbl->hash(pkey, dev) & tbl->hash_mask; =20 - hash_val =3D tbl->hash(pkey, dev); + NEIGH_CACHE_STAT_INC(tbl, lookups); =20 read_lock_bh(&tbl->lock); for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { if (dev =3D=3D n->dev && memcmp(n->primary_key, pkey, key_len) =3D=3D 0) { neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); + break; + } + } + read_unlock_bh(&tbl->lock); + return n; +} + +struct neighbour *neigh_lookup_nodev(struct neigh_table *tbl, const void *= pkey) +{ + struct neighbour *n; + int key_len =3D tbl->key_len; + u32 hash_val =3D tbl->hash(pkey, NULL) & tbl->hash_mask; + + NEIGH_CACHE_STAT_INC(tbl, lookups); + + read_lock_bh(&tbl->lock); + for (n =3D tbl->hash_buckets[hash_val]; n; n =3D n->next) { + if (!memcmp(n->primary_key, pkey, key_len)) { + neigh_hold(n); + NEIGH_CACHE_STAT_INC(tbl, hits); break; } } @@ -319,6 +405,12 @@ if (n =3D=3D NULL) return ERR_PTR(-ENOBUFS); =20 + if (tbl->entries > (tbl->hash_mask + 1)) { + write_lock_bh(&tbl->lock); + neigh_hash_grow(tbl, (tbl->hash_mask + 1) << 1); + write_unlock_bh(&tbl->lock); + } + memcpy(n->primary_key, pkey, key_len); n->dev =3D dev; dev_hold(dev); @@ -338,7 +430,7 @@ =20 n->confirmed =3D jiffies - (n->parms->base_reachable_time<<1); =20 - hash_val =3D tbl->hash(pkey, dev); + hash_val =3D tbl->hash(pkey, dev) & tbl->hash_mask; =20 write_lock_bh(&tbl->lock); for (n1 =3D tbl->hash_buckets[hash_val]; n1; n1 =3D n1->next) { @@ -418,9 +510,9 @@ hash_val ^=3D hash_val>>4; hash_val &=3D PNEIGH_HASHMASK; =20 + write_lock_bh(&tbl->lock); for (np =3D &tbl->phash_buckets[hash_val]; (n=3D*np) !=3D NULL; np =3D &n= ->next) { if (memcmp(n->key, pkey, key_len) =3D=3D 0 && n->dev =3D=3D dev) { - write_lock_bh(&tbl->lock); *np =3D n->next; write_unlock_bh(&tbl->lock); if (tbl->pdestructor) @@ -429,6 +521,7 @@ return 0; } } + write_unlock_bh(&tbl->lock); return -ENOENT; } =20 @@ -462,6 +555,8 @@ {=09 struct hh_cache *hh; =20 + NEIGH_CACHE_STAT_INC(neigh->tbl, destroys); + if (!neigh->dead) { printk("Destroying alive neighbour %p\n", neigh); dump_stack(); @@ -566,9 +661,10 @@ static void SMP_TIMER_NAME(neigh_periodic_timer)(unsigned long arg) { struct neigh_table *tbl =3D (struct neigh_table*)arg; - unsigned long now =3D jiffies; - int i; + struct neighbour *n, **np; + unsigned long expire, now =3D jiffies; =20 + NEIGH_CACHE_STAT_INC(tbl, periodic_gc_runs); =20 write_lock(&tbl->lock); =20 @@ -583,46 +679,49 @@ p->reachable_time =3D neigh_rand_reach_time(p->base_reachable_time); } =20 - for (i=3D0; i <=3D NEIGH_HASHMASK; i++) { - struct neighbour *n, **np; - - np =3D &tbl->hash_buckets[i]; - while ((n =3D *np) !=3D NULL) { - unsigned state; - - write_lock(&n->lock); + np =3D &tbl->hash_buckets[tbl->hash_chain_gc]; + tbl->hash_chain_gc =3D ((tbl->hash_chain_gc + 1) & tbl->hash_mask); =20 - state =3D n->nud_state; - if (state&(NUD_PERMANENT|NUD_IN_TIMER)) { - write_unlock(&n->lock); - goto next_elt; - } + while ((n =3D *np) !=3D NULL) { + unsigned int state; =20 - if ((long)(n->used - n->confirmed) < 0) - n->used =3D n->confirmed; + write_lock(&n->lock); + =20 + state =3D n->nud_state; + if (state & (NUD_PERMANENT | NUD_IN_TIMER)) { + write_unlock(&n->lock); + goto next_elt; + } =20 - if (atomic_read(&n->refcnt) =3D=3D 1 && - (state =3D=3D NUD_FAILED || now - n->used > n->parms->gc_staletime)= ) { - *np =3D n->next; - n->dead =3D 1; - write_unlock(&n->lock); - neigh_release(n); - continue; - } + if (time_before(n->used, n->confirmed)) + n->used =3D n->confirmed; =20 - if (n->nud_state&NUD_REACHABLE && - now - n->confirmed > n->parms->reachable_time) { - n->nud_state =3D NUD_STALE; - neigh_suspect(n); - } + if (atomic_read(&n->refcnt) =3D=3D 1 && + (state =3D=3D NUD_FAILED || + time_after(now, n->used + n->parms->gc_staletime))) { + *np =3D n->next; + n->dead =3D 1; write_unlock(&n->lock); + neigh_release(n); + continue; + } + write_unlock(&n->lock); =20 next_elt: - np =3D &n->next; - } + np =3D &n->next; } + =20 + /* Cycle through all hash buckets every base_reachable_time/2 ticks. + * ARP entry timeouts range from 1/2 base_reachable_time to 3/2 + * base_reachable_time. + */ + expire =3D tbl->parms.base_reachable_time >> 1; + expire /=3D (tbl->hash_mask + 1); + if (!expire) + expire =3D 1; + + mod_timer(&tbl->gc_timer, now + expire); =20 - mod_timer(&tbl->gc_timer, now + tbl->gc_interval); write_unlock(&tbl->lock); } =20 @@ -680,7 +779,7 @@ =20 neigh->nud_state =3D NUD_FAILED; notify =3D 1; - neigh->tbl->stats.res_failed++; + NEIGH_CACHE_STAT_INC(neigh->tbl, res_failed); NEIGH_PRINTK2("neigh %p is failed.\n", neigh); =20 /* It is very thin place. report_unreachable is very complicated @@ -1132,6 +1231,7 @@ void neigh_table_init(struct neigh_table *tbl) { unsigned long now =3D jiffies; + unsigned long phsize; =20 tbl->parms.reachable_time =3D neigh_rand_reach_time(tbl->parms.base_reach= able_time); =20 @@ -1141,6 +1241,30 @@ 0, SLAB_HWCACHE_ALIGN, NULL, NULL); =20 + if (!tbl->kmem_cachep) + panic("cannot create neighbour cache"); + +#ifdef CONFIG_PROC_FS + tbl->pde =3D create_proc_entry(tbl->id, 0, proc_net_stat); + if (!tbl->pde)=20 + panic("cannot create neighbour proc dir entry"); + tbl->pde->proc_fops =3D &neigh_stat_seq_fops; + tbl->pde->data =3D tbl; +#endif + + tbl->hash_mask =3D 0x1f; + tbl->hash_buckets =3D neigh_hash_alloc(tbl->hash_mask + 1); + + phsize =3D (PNEIGH_HASHMASK + 1) * sizeof(struct pneigh_entry *); + tbl->phash_buckets =3D kmalloc(phsize, GFP_KERNEL); + + if (!tbl->hash_buckets || !tbl->phash_buckets) + panic("cannot allocate neighbour cache hashes"); + + memset(tbl->phash_buckets, 0, phsize); + + get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd)); + #ifdef CONFIG_SMP tasklet_init(&tbl->gc_task, SMP_TIMER_NAME(neigh_periodic_timer), (unsign= ed long)tbl); #endif @@ -1148,7 +1272,7 @@ tbl->lock =3D RW_LOCK_UNLOCKED; tbl->gc_timer.data =3D (unsigned long)tbl; tbl->gc_timer.function =3D neigh_periodic_timer; - tbl->gc_timer.expires =3D now + tbl->gc_interval + tbl->parms.reachable_t= ime; + tbl->gc_timer.expires =3D now + 1; add_timer(&tbl->gc_timer); =20 init_timer(&tbl->proxy_timer); @@ -1184,6 +1308,13 @@ } } write_unlock(&neigh_tbl_lock); + + neigh_hash_free(tbl->hash_buckets, tbl->hash_mask + 1); + tbl->hash_buckets =3D NULL; + + kfree(tbl->phash_buckets); + tbl->phash_buckets =3D NULL; + #ifdef CONFIG_SYSCTL neigh_sysctl_unregister(&tbl->parms); #endif @@ -1364,7 +1495,7 @@ =20 s_h =3D cb->args[1]; s_idx =3D idx =3D cb->args[2]; - for (h=3D0; h <=3D NEIGH_HASHMASK; h++) { + for (h=3D0; h <=3D tbl->hash_mask; h++) { if (h < s_h) continue; if (h > s_h) s_idx =3D 0; @@ -1415,6 +1546,359 @@ return skb->len; } =20 +void neigh_for_each(struct neigh_table *tbl, void (*cb)(struct neighbour *= , void *), void *cookie) +{ + int chain; + + read_lock_bh(&tbl->lock); + for (chain =3D 0; chain <=3D tbl->hash_mask; chain++) { + struct neighbour *n; + + for (n =3D tbl->hash_buckets[chain]; n; n =3D n->next) + cb(n, cookie); + } + read_unlock_bh(&tbl->lock); +} + +/* The tbl->lock must be held as a writer and BH disabled. */ +void __neigh_for_each_release(struct neigh_table *tbl, + int (*cb)(struct neighbour *)) +{ + int chain; + + for (chain =3D 0; chain <=3D tbl->hash_mask; chain++) { + struct neighbour *n, **np; + + np =3D &tbl->hash_buckets[chain]; + while ((n =3D *np) !=3D NULL) { + int release; + + write_lock(&n->lock); + release =3D cb(n); + if (release) { + *np =3D n->next; + n->dead =3D 1; + } else + np =3D &n->next; + write_unlock(&n->lock); + if (release) + neigh_release(n); + } + } +} + +#ifdef CONFIG_PROC_FS + +static struct neighbour *neigh_get_first(struct seq_file *seq) +{ + struct neigh_seq_state *state =3D seq->private; + struct neigh_table *tbl =3D state->tbl; + struct neighbour *n =3D NULL; + int bucket =3D state->bucket; + + state->flags &=3D ~NEIGH_SEQ_IS_PNEIGH; + for (bucket =3D 0; bucket <=3D tbl->hash_mask; bucket++) { + n =3D tbl->hash_buckets[bucket]; + + while (n) { + if (state->neigh_sub_iter) { + loff_t fakep =3D 0; + void *v; + + v =3D state->neigh_sub_iter(state, n, &fakep); + if (!v) + goto next; + } + if (!(state->flags & NEIGH_SEQ_SKIP_NOARP)) + break; + if (n->nud_state & ~NUD_NOARP) + break; + next: + n =3D n->next; + } + + if (n) + break; + } + state->bucket =3D bucket; + + return n; +} + +static struct neighbour *neigh_get_next(struct seq_file *seq, + struct neighbour *n, + loff_t *pos) +{ + struct neigh_seq_state *state =3D seq->private; + struct neigh_table *tbl =3D state->tbl; + + if (state->neigh_sub_iter) { + void *v =3D state->neigh_sub_iter(state, n, pos); + if (v) + return n; + } + n =3D n->next; + + while (1) { + while (n) { + if (state->neigh_sub_iter) { + void *v =3D state->neigh_sub_iter(state, n, pos); + if (v) + return n; + goto next; + } + if (!(state->flags & NEIGH_SEQ_SKIP_NOARP)) + break; + + if (n->nud_state & ~NUD_NOARP) + break; + next: + n =3D n->next; + } + + if (n) + break; + + if (++state->bucket > tbl->hash_mask) + break; + + n =3D tbl->hash_buckets[state->bucket]; + } + + if (n && pos) + --(*pos); + return n; +} + +static struct neighbour *neigh_get_idx(struct seq_file *seq, loff_t *pos) +{ + struct neighbour *n =3D neigh_get_first(seq); + + if (n) { + while (*pos) { + n =3D neigh_get_next(seq, n, pos); + if (!n) + break; + } + } + return *pos ? NULL : n; +} + +static struct pneigh_entry *pneigh_get_first(struct seq_file *seq) +{ + struct neigh_seq_state *state =3D seq->private; + struct neigh_table *tbl =3D state->tbl; + struct pneigh_entry *pn =3D NULL; + int bucket =3D state->bucket; + + state->flags |=3D NEIGH_SEQ_IS_PNEIGH; + for (bucket =3D 0; bucket <=3D PNEIGH_HASHMASK; bucket++) { + pn =3D tbl->phash_buckets[bucket]; + if (pn) + break; + } + state->bucket =3D bucket; + + return pn; +} + +static struct pneigh_entry *pneigh_get_next(struct seq_file *seq, + struct pneigh_entry *pn, + loff_t *pos) +{ + struct neigh_seq_state *state =3D seq->private; + struct neigh_table *tbl =3D state->tbl; + + pn =3D pn->next; + while (!pn) { + if (++state->bucket > PNEIGH_HASHMASK) + break; + pn =3D tbl->phash_buckets[state->bucket]; + if (pn) + break; + } + + if (pn && pos) + --(*pos); + + return pn; +} + +static struct pneigh_entry *pneigh_get_idx(struct seq_file *seq, loff_t *p= os) +{ + struct pneigh_entry *pn =3D pneigh_get_first(seq); + + if (pn) { + while (*pos) { + pn =3D pneigh_get_next(seq, pn, pos); + if (!pn) + break; + } + } + return *pos ? NULL : pn; +} + +static void *neigh_get_idx_any(struct seq_file *seq, loff_t *pos) +{ + struct neigh_seq_state *state =3D seq->private; + void *rc; + + rc =3D neigh_get_idx(seq, pos); + if (!rc && !(state->flags & NEIGH_SEQ_NEIGH_ONLY)) + rc =3D pneigh_get_idx(seq, pos); + + return rc; +} + +void *neigh_seq_start(struct seq_file *seq, loff_t *pos, struct neigh_tabl= e *tbl, unsigned int neigh_seq_flags) +{ + struct neigh_seq_state *state =3D seq->private; + loff_t pos_minus_one; + + state->tbl =3D tbl; + state->bucket =3D 0; + state->flags =3D (neigh_seq_flags & ~NEIGH_SEQ_IS_PNEIGH); + + read_lock_bh(&tbl->lock); + + pos_minus_one =3D *pos - 1; + return *pos ? neigh_get_idx_any(seq, &pos_minus_one) : SEQ_START_TOKEN; +} + +void *neigh_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct neigh_seq_state *state; + void *rc; + + if (v =3D=3D SEQ_START_TOKEN) { + rc =3D neigh_get_idx(seq, pos); + goto out; + } + + state =3D seq->private; + if (!(state->flags & NEIGH_SEQ_IS_PNEIGH)) { + rc =3D neigh_get_next(seq, v, NULL); + if (rc) + goto out; + if (!(state->flags & NEIGH_SEQ_NEIGH_ONLY)) + rc =3D pneigh_get_first(seq); + } else { + BUG_ON(state->flags & NEIGH_SEQ_NEIGH_ONLY); + rc =3D pneigh_get_next(seq, v, NULL); + } +out: + ++(*pos); + return rc; +} + +void neigh_seq_stop(struct seq_file *seq, void *v) +{ + struct neigh_seq_state *state =3D seq->private; + struct neigh_table *tbl =3D state->tbl; + + read_unlock_bh(&tbl->lock); +} + +/* statistics via seq_file */ + +static void *neigh_stat_seq_start(struct seq_file *seq, loff_t *pos) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int lcpu; + + if (*pos =3D=3D 0) + return SEQ_START_TOKEN; +=09 + for (lcpu =3D *pos-1; lcpu < smp_num_cpus; ++lcpu) { + int i =3D cpu_logical_map(lcpu); + *pos =3D lcpu+1; + return &tbl->stats[i]; + } + return NULL; +} + +static void *neigh_stat_seq_next(struct seq_file *seq, void *v, loff_t *po= s) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + int lcpu; + + for (lcpu =3D *pos; lcpu < smp_num_cpus; ++lcpu) { + int i =3D cpu_logical_map(lcpu); + *pos =3D lcpu+1; + return &tbl->stats[i]; + } + return NULL; +} + +static void neigh_stat_seq_stop(struct seq_file *seq, void *v) +{ + +} + +static int neigh_stat_seq_show(struct seq_file *seq, void *v) +{ + struct proc_dir_entry *pde =3D seq->private; + struct neigh_table *tbl =3D pde->data; + struct neigh_statistics *st =3D v; + + if (v =3D=3D SEQ_START_TOKEN) { + seq_printf(seq, "entries allocs destroys hash_grows lookups hits res_= failed rcv_probes_mcast rcv_probes_ucast periodic_gc_runs forced_gc_runs = forced_gc_goal_miss\n"); + return 0; + } + + seq_printf(seq, "%08x %08lx %08lx %08lx %08lx %08lx %08lx " + "%08lx %08lx %08lx %08lx\n", + tbl->entries, + + st->allocs, + st->destroys, + st->hash_grows, + + st->lookups, + st->hits, + + st->res_failed, + + st->rcv_probes_mcast, + st->rcv_probes_ucast, + + st->periodic_gc_runs, + st->forced_gc_runs + ); + + return 0; +} + +static struct seq_operations neigh_stat_seq_ops =3D { + .start =3D neigh_stat_seq_start, + .next =3D neigh_stat_seq_next, + .stop =3D neigh_stat_seq_stop, + .show =3D neigh_stat_seq_show, +}; + +static int neigh_stat_seq_open(struct inode *inode, struct file *file) +{ + int ret =3D seq_open(file, &neigh_stat_seq_ops); + + if (!ret) { + struct seq_file *sf =3D file->private_data; + sf->private =3D PDE(inode); + } + return ret; +}; + +static struct file_operations neigh_stat_seq_fops =3D { + .owner =3D THIS_MODULE, + .open =3D neigh_stat_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release, +}; + +#endif /* CONFIG_PROC_FS */ + #ifdef CONFIG_ARPD void neigh_app_ns(struct neighbour *n) { diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/decnet/dn_neigh.c linux-2.4.28-pre3-bk5-neigh/net/= decnet/dn_neigh.c --- linux-2.4.28-pre3-bk5-plain/net/decnet/dn_neigh.c 2004-02-18 14:36:32.0= 00000000 +0100 +++ linux-2.4.28-pre3-bk5-neigh/net/decnet/dn_neigh.c 2004-09-30 15:29:46.0= 00000000 +0200 @@ -20,6 +20,7 @@ * Steve Whitehouse : Fixed neighbour states (for now anyway). * Steve Whitehouse : Made error_report functions dummies. This * is not the right place to return skbs. + * Harald Welte : Port to DaveM's generalized ncache from 2.6.x * */ =20 @@ -33,6 +34,8 @@ #include #include #include +#include +#include #include #include #include @@ -118,13 +121,7 @@ =20 static u32 dn_neigh_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val =3D *(dn_address *)pkey; - hash_val ^=3D (hash_val >> 10); - hash_val ^=3D (hash_val >> 3); - - return hash_val & NEIGH_HASHMASK; + return jhash_2words(*(dn_address *)pkey, 0, dn_neigh_table.hash_rnd); } =20 static int dn_neigh_construct(struct neighbour *neigh) @@ -322,33 +319,6 @@ } =20 /* - * Unfortunately, the neighbour code uses the device in its hash - * function, so we don't get any advantage from it. This function - * basically does a neigh_lookup(), but without comparing the device - * field. This is required for the On-Ethernet cache - */ -struct neighbour *dn_neigh_lookup(struct neigh_table *tbl, void *ptr) -{ - struct neighbour *neigh; - u32 hash_val; - - hash_val =3D tbl->hash(ptr, NULL); - - read_lock_bh(&tbl->lock); - for(neigh =3D tbl->hash_buckets[hash_val]; neigh !=3D NULL; neigh =3D nei= gh->next) { - if (memcmp(neigh->primary_key, ptr, tbl->key_len) =3D=3D 0) { - atomic_inc(&neigh->refcnt); - read_unlock_bh(&tbl->lock); - return neigh; - } - } - read_unlock_bh(&tbl->lock); - - return NULL; -} - - -/* * Any traffic on a pointopoint link causes the timer to be reset * for the entry in the neighbour table. */ @@ -484,113 +454,146 @@ return (*min < priority) ? (min - 6) : NULL; } =20 -int dn_neigh_elist(struct net_device *dev, unsigned char *ptr, int n) +struct elist_cb_state { + struct net_device *dev; + unsigned char *ptr; + unsigned char *rs; + int t, n; +}; + +static void neigh_elist_cb(struct neighbour *neigh, void *_info) { - int t =3D 0; - int i; - struct neighbour *neigh; + struct elist_cb_state *s =3D _info; + struct dn_dev *dn_db; struct dn_neigh *dn; - struct neigh_table *tbl =3D &dn_neigh_table; - unsigned char *rs =3D ptr; - struct dn_dev *dn_db =3D (struct dn_dev *)dev->dn_ptr; =20 - read_lock_bh(&tbl->lock); + if (neigh->dev !=3D s->dev) + return; =20 - for(i =3D 0; i < NEIGH_HASHMASK; i++) { - for(neigh =3D tbl->hash_buckets[i]; neigh !=3D NULL; neigh =3D neigh->ne= xt) { - if (neigh->dev !=3D dev) - continue; - dn =3D (struct dn_neigh *)neigh; - if (!(dn->flags & (DN_NDFLAG_R1|DN_NDFLAG_R2))) - continue; - if (dn_db->parms.forwarding =3D=3D 1 && (dn->flags & DN_NDFLAG_R2)) - continue; - if (t =3D=3D n) - rs =3D dn_find_slot(ptr, n, dn->priority); - else - t++; - if (rs =3D=3D NULL) - continue; - dn_dn2eth(rs, dn->addr); - rs +=3D 6; - *rs =3D neigh->nud_state & NUD_CONNECTED ? 0x80 : 0x0; - *rs |=3D dn->priority; - rs++; - } - } + dn =3D (struct dn_neigh *) neigh; + if (!(dn->flags & (DN_NDFLAG_R1|DN_NDFLAG_R2))) + return; + + dn_db =3D (struct dn_dev *) s->dev->dn_ptr; + if (dn_db->parms.forwarding =3D=3D 1 && (dn->flags & DN_NDFLAG_R2)) + return; =20 - read_unlock_bh(&tbl->lock); + if (s->t =3D=3D s->n) + s->rs =3D dn_find_slot(s->ptr, s->n, dn->priority); + else + s->t++; + if (s->rs =3D=3D NULL) + return; + + dn_dn2eth(s->rs, dn->addr); + s->rs +=3D 6; + *(s->rs) =3D neigh->nud_state & NUD_CONNECTED ? 0x80 : 0x0; + *(s->rs) |=3D dn->priority; + s->rs++; +} + =20 +int dn_neigh_elist(struct net_device *dev, unsigned char *ptr, int n) +{ + struct elist_cb_state state; + + state.dev =3D dev; + state.t =3D 0; + state.n =3D n; + state.ptr =3D ptr; + state.rs =3D ptr; + + neigh_for_each(&dn_neigh_table, neigh_elist_cb, &state); =20 - return t; + return state.t; } + #endif /* CONFIG_DECNET_ROUTER */ =20 =20 =20 #ifdef CONFIG_PROC_FS -static int dn_neigh_get_info(char *buffer, char **start, off_t offset, int= length) + +static inline void dn_neigh_format_entry(struct seq_file *seq, + struct neighbour *n) { - int len =3D 0; - off_t pos =3D 0; - off_t begin =3D 0; - struct neighbour *n; - int i; + struct dn_neigh *dn =3D (struct dn_neigh *) n; char buf[DN_ASCBUF_LEN]; =20 - len +=3D sprintf(buffer + len, "Addr Flags State Use Blksize Dev\n"); - - for(i=3D0;i <=3D NEIGH_HASHMASK; i++) { - read_lock_bh(&dn_neigh_table.lock); - n =3D dn_neigh_table.hash_buckets[i]; - for(; n !=3D NULL; n =3D n->next) { - struct dn_neigh *dn =3D (struct dn_neigh *)n; - - read_lock(&n->lock); - len +=3D sprintf(buffer+len, "%-7s %s%s%s %02x %02d %07ld %-8s\n", - dn_addr2asc(dn_ntohs(dn->addr), buf), - (dn->flags&DN_NDFLAG_R1) ? "1" : "-", - (dn->flags&DN_NDFLAG_R2) ? "2" : "-", - (dn->flags&DN_NDFLAG_P3) ? "3" : "-", - dn->n.nud_state, - atomic_read(&dn->n.refcnt), - dn->blksize, - (dn->n.dev) ? dn->n.dev->name : "?"); - read_unlock(&n->lock); - - pos =3D begin + len; - - if (pos < offset) { - len =3D 0; - begin =3D pos; - } - - if (pos > offset + length) { - read_unlock_bh(&dn_neigh_table.lock); - goto done; - } - } - read_unlock_bh(&dn_neigh_table.lock); + read_lock(&n->lock); + seq_printf(seq, "%-7s %s%s%s %02x %02d %07ld %-8s\n", + dn_addr2asc(dn_ntohs(dn->addr), buf), + (dn->flags&DN_NDFLAG_R1) ? "1" : "-", + (dn->flags&DN_NDFLAG_R2) ? "2" : "-", + (dn->flags&DN_NDFLAG_P3) ? "3" : "-", + dn->n.nud_state, + atomic_read(&dn->n.refcnt), + dn->blksize, + (dn->n.dev) ? dn->n.dev->name : "?"); + read_unlock(&n->lock); +} + +static int dn_neigh_seq_show(struct seq_file *seq, void *v) +{ + if (v =3D=3D SEQ_START_TOKEN) { + seq_puts(seq, "Addr Flags State Use Blksize Dev\n"); + } else { + dn_neigh_format_entry(seq, v); } =20 -done: + return 0; +} =20 - *start =3D buffer + (offset - begin); - len -=3D offset - begin; +static void *dn_neigh_seq_start(struct seq_file *seq, loff_t *pos) +{ + return neigh_seq_start(seq, pos, &dn_neigh_table, + NEIGH_SEQ_NEIGH_ONLY); +} =20 - if (len > length) len =3D length; +static struct seq_operations dn_neigh_seq_ops =3D { + .start =3D dn_neigh_seq_start, + .next =3D neigh_seq_next, + .stop =3D neigh_seq_stop, + .show =3D dn_neigh_seq_show, +}; =20 - return len; -} +static int dn_neigh_seq_open(struct inode *inode, struct file *file) +{ + struct seq_file *seq; + int rc =3D -ENOMEM; + struct neigh_seq_state *s =3D kmalloc(sizeof(*s), GFP_KERNEL); + + if (!s) + goto out; + + memset(s, 0, sizeof(*s)); + rc =3D seq_open(file, &dn_neigh_seq_ops); + if (rc) + goto out_kfree; + + seq =3D file->private_data; + seq->private =3D s; + memset(s, 0, sizeof(*s)); +out: + return rc; +out_kfree: + kfree(s); + goto out; +} + +static struct file_operations dn_neigh_seq_fops =3D { + .owner =3D THIS_MODULE, + .open =3D dn_neigh_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release_private, +}; =20 #endif =20 void __init dn_neigh_init(void) { neigh_table_init(&dn_neigh_table); - -#ifdef CONFIG_PROC_FS - proc_net_create("decnet_neigh",0,dn_neigh_get_info); -#endif /* CONFIG_PROC_FS */ + proc_net_fops_create("decnet_neigh", S_IRUGO, &dn_neigh_seq_fops); } =20 void __exit dn_neigh_cleanup(void) diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/decnet/dn_route.c linux-2.4.28-pre3-bk5-neigh/net/= decnet/dn_route.c --- linux-2.4.28-pre3-bk5-plain/net/decnet/dn_route.c 2002-11-29 00:53:15.0= 00000000 +0100 +++ linux-2.4.28-pre3-bk5-neigh/net/decnet/dn_route.c 2004-09-30 12:13:03.0= 00000000 +0200 @@ -761,7 +761,7 @@ =20 /* Look in On-Ethernet cache first */ if (!(flags & MSG_TRYHARD)) { - if ((neigh =3D dn_neigh_lookup(&dn_neigh_table, &dst)) !=3D NULL) + if ((neigh =3D neigh_lookup_nodev(&dn_neigh_table, &dst)) !=3D NULL) goto got_route; } =20 diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/ipv4/arp.c linux-2.4.28-pre3-bk5-neigh/net/ipv4/ar= p.c --- linux-2.4.28-pre3-bk5-plain/net/ipv4/arp.c 2004-04-14 15:05:41.00000000= 0 +0200 +++ linux-2.4.28-pre3-bk5-neigh/net/ipv4/arp.c 2004-09-30 17:07:25.00000000= 0 +0200 @@ -70,6 +70,7 @@ * arp_xmit so intermediate drivers like * bonding can change the skb before * sending (e.g. insert 8021q tag). + * Harald Welte : convert to make use of jenkins hash */ =20 #include @@ -92,6 +93,7 @@ #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -218,15 +220,7 @@ =20 static u32 arp_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; - - hash_val =3D *(u32*)pkey; - hash_val ^=3D (hash_val>>16); - hash_val ^=3D hash_val>>8; - hash_val ^=3D hash_val>>3; - hash_val =3D (hash_val^dev->ifindex)&NEIGH_HASHMASK; - - return hash_val; + return jhash_2words(*(u32 *)pkey, dev->ifindex, arp_tbl.hash_rnd); } =20 static int arp_constructor(struct neighbour *neigh) @@ -1185,129 +1179,155 @@ return err; } =20 +#ifdef CONFIG_PROC_FS +#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) + +/* -----------------------------------------------------------------------= - */ /* - * Write the contents of the ARP cache to a PROCfs file. + * ax25 -> ASCII conversion */ -#ifndef CONFIG_PROC_FS -static int arp_get_info(char *buffer, char **start, off_t offset, int leng= th) { return 0; } -#else -#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) -static char *ax2asc2(ax25_address *a, char *buf); -#endif +static char *ax2asc2(ax25_address *a, char *buf) +{ + char c, *s; + int n; + + for (n =3D 0, s =3D buf; n < 6; n++) { + c =3D (a->ax25_call[n] >> 1) & 0x7F; + + if (c !=3D ' ') *s++ =3D c; + } +=09 + *s++ =3D '-'; + + if ((n =3D ((a->ax25_call[6] >> 1) & 0x0F)) > 9) { + *s++ =3D '1'; + n -=3D 10; + } +=09 + *s++ =3D n + '0'; + *s++ =3D '\0'; + + if (*buf =3D=3D '\0' || *buf =3D=3D '-') + return "*"; + + return buf; + +} +#endif /* CONFIG_AX25 */ + #define HBUFFERLEN 30 =20 -static int arp_get_info(char *buffer, char **start, off_t offset, int leng= th) +static void arp_format_neigh_entry(struct seq_file *seq, + struct neighbour *n) { - int len=3D0; - off_t pos=3D0; - int size; char hbuffer[HBUFFERLEN]; - int i,j,k; const char hexbuf[] =3D "0123456789ABCDEF"; + int k, j; + char tbuf[16]; + struct net_device *dev =3D n->dev; + int hatype =3D dev->type; =20 - size =3D sprintf(buffer,"IP address HW type Flags HW addr= ess Mask Device\n"); - - pos+=3Dsize; - len+=3Dsize; + read_lock(&n->lock); =20 - for(i=3D0; i<=3DNEIGH_HASHMASK; i++) { - struct neighbour *n; - read_lock_bh(&arp_tbl.lock); - for (n=3Darp_tbl.hash_buckets[i]; n; n=3Dn->next) { - struct net_device *dev =3D n->dev; - int hatype =3D dev->type; - - /* Do not confuse users "arp -a" with magic entries */ - if (!(n->nud_state&~NUD_NOARP)) - continue; - - read_lock(&n->lock); - -/* - * Convert hardware address to XX:XX:XX:XX ... form. - */ + /* Convert hardware address to XX:XX:XX:XX ... form. */ #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) - if (hatype =3D=3D ARPHRD_AX25 || hatype =3D=3D ARPHRD_NETROM) - ax2asc2((ax25_address *)n->ha, hbuffer); - else { -#endif - for (k=3D0,j=3D0;kaddr_len;j++) { - hbuffer[k++]=3Dhexbuf[(n->ha[j]>>4)&15 ]; - hbuffer[k++]=3Dhexbuf[n->ha[j]&15 ]; - hbuffer[k++]=3D':'; - } - hbuffer[--k]=3D0; - + if (hatype =3D=3D ARPHRD_AX25 || hatype =3D=3D ARPHRD_NETROM) + ax2asc2((ax25_address *)n->ha, hbuffer); + else { +#endif + for (k=3D0,j=3D0;kaddr_len;j++) { + hbuffer[k++]=3Dhexbuf[(n->ha[j]>>4)&15 ]; + hbuffer[k++]=3Dhexbuf[n->ha[j]&15 ]; + hbuffer[k++]=3D':'; + } + hbuffer[--k]=3D0; #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) - } + } #endif + sprintf(tbuf, "%u.%u.%u.%u", NIPQUAD(*(u32*)n->primary_key)); + seq_printf(seq, "%-16s 0x%-10x0x%-10x%s * %s\n", + tbuf, hatype, arp_state_to_flags(n), hbuffer, dev->name); + read_unlock(&n->lock); +} =20 - { - char tbuf[16]; - sprintf(tbuf, "%u.%u.%u.%u", NIPQUAD(*(u32*)n->primary_key)); - size =3D sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s" - " * %s\n", - tbuf, - hatype, - arp_state_to_flags(n),=20 - hbuffer, - dev->name); - } +static void arp_format_pneigh_entry(struct seq_file *seq, + struct pneigh_entry *n) +{ + struct net_device *dev =3D n->dev; + int hatype =3D dev ? dev->type : 0; + char tbuf[16]; =20 - read_unlock(&n->lock); + sprintf(tbuf, "%u.%u.%u.%u", NIPQUAD(*(u32*)n->key)); + seq_printf(seq, "%-16s 0x%-10x0x%-10x%s * %s\n", + tbuf, hatype, ATF_PUBL | ATF_PERM, "00:00:00:00:00:00", + dev ? dev->name : "*"); +} =20 - len +=3D size; - pos +=3D size; - =20 - if (pos <=3D offset) - len=3D0; - if (pos >=3D offset+length) { - read_unlock_bh(&arp_tbl.lock); - goto done; - } - } - read_unlock_bh(&arp_tbl.lock); +static int arp_seq_show(struct seq_file *seq, void *v) +{ + if (v =3D=3D SEQ_START_TOKEN) { + seq_puts(seq, "IP address HW type Flags " + "HW address Mask Device\n"); + } else { + struct neigh_seq_state *state =3D seq->private; + + if (state->flags & NEIGH_SEQ_IS_PNEIGH) + arp_format_pneigh_entry(seq, v); + else + arp_format_neigh_entry(seq, v); } =20 - for (i=3D0; i<=3DPNEIGH_HASHMASK; i++) { - struct pneigh_entry *n; - for (n=3Darp_tbl.phash_buckets[i]; n; n=3Dn->next) { - struct net_device *dev =3D n->dev; - int hatype =3D dev ? dev->type : 0; - - { - char tbuf[16]; - sprintf(tbuf, "%u.%u.%u.%u", NIPQUAD(*(u32*)n->key)); - size =3D sprintf(buffer+len, "%-16s 0x%-10x0x%-10x%s" - " * %s\n", - tbuf, - hatype, - ATF_PUBL|ATF_PERM, - "00:00:00:00:00:00", - dev ? dev->name : "*"); - } + return 0; +} =20 - len +=3D size; - pos +=3D size; - =20 - if (pos <=3D offset) - len=3D0; - if (pos >=3D offset+length) - goto done; - } - } +static void *arp_seq_start(struct seq_file *seq, loff_t *pos) +{ + /* Don't want to confuse "arp -a" w/ magic entries, + * so we tell the generic iterator to skip NUD_NOARP. + */ + return neigh_seq_start(seq, pos, &arp_tbl, NEIGH_SEQ_SKIP_NOARP); +} + +/* -----------------------------------------------------------------------= - */ + +static struct seq_operations arp_seq_ops =3D { + .start =3D arp_seq_start, + .next =3D neigh_seq_next, + .stop =3D neigh_seq_stop, + .show =3D arp_seq_show, +}; + +static int arp_seq_open(struct inode *inode, struct file *file) +{ + struct seq_file *seq; + int rc =3D -ENOMEM; + struct neigh_seq_state *s =3D kmalloc(sizeof(*s), GFP_KERNEL); + + if (!s) + goto out; + + memset(s, 0, sizeof(*s)); + rc =3D seq_open(file, &arp_seq_ops); + if (rc) + goto out_kfree; =20 -done: - =20 - *start =3D buffer+len-(pos-offset); /* Start of wanted data */ - len =3D pos-offset; /* Start slop */ - if (len>length) - len =3D length; /* Ending slop */ - if (len<0) - len =3D 0; - return len; + seq =3D file->private_data; + seq->private =3D s; +out: + return rc; +out_kfree: + kfree(s); + goto out; } -#endif + +static struct file_operations arp_seq_fops =3D { + .owner =3D THIS_MODULE, + .open =3D arp_seq_open, + .read =3D seq_read, + .llseek =3D seq_lseek, + .release =3D seq_release_private, +}; +#endif /* CONFIG_PROC_FS */ =20 static int arp_netdev_event(struct notifier_block *this, unsigned long eve= nt, void *ptr) { @@ -1355,8 +1375,10 @@ =20 dev_add_pack(&arp_packet_type); =20 - proc_net_create ("arp", 0, arp_get_info); - +#ifdef CONFIG_PROC_FS + if (!proc_net_fops_create("arp", S_IRUGO, &arp_seq_fops)) + panic("unable to create arp proc entry"); +#endif #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, NET_IPV4_NEIGH, "ip= v4"); #endif @@ -1364,39 +1386,3 @@ } =20 =20 -#ifdef CONFIG_PROC_FS -#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) - -/* - * ax25 -> ASCII conversion - */ -char *ax2asc2(ax25_address *a, char *buf) -{ - char c, *s; - int n; - - for (n =3D 0, s =3D buf; n < 6; n++) { - c =3D (a->ax25_call[n] >> 1) & 0x7F; - - if (c !=3D ' ') *s++ =3D c; - } -=09 - *s++ =3D '-'; - - if ((n =3D ((a->ax25_call[6] >> 1) & 0x0F)) > 9) { - *s++ =3D '1'; - n -=3D 10; - } -=09 - *s++ =3D n + '0'; - *s++ =3D '\0'; - - if (*buf =3D=3D '\0' || *buf =3D=3D '-') - return "*"; - - return buf; - -} - -#endif -#endif diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/ipv4/route.c linux-2.4.28-pre3-bk5-neigh/net/ipv4/= route.c --- linux-2.4.28-pre3-bk5-plain/net/ipv4/route.c 2003-11-28 19:26:21.000000= 000 +0100 +++ linux-2.4.28-pre3-bk5-neigh/net/ipv4/route.c 2004-09-30 16:33:07.000000= 000 +0200 @@ -284,6 +284,7 @@ int i, lcpu; int len =3D 0; =20 + len +=3D sprintf(buffer+len, "entries in_hit in_slow_tot in_slow_mc in_= no_route in_brd in_martian_dst in_martian_src out_hit out_slow_tot out_slo= w_mc gc_total gc_ignored gc_goal_miss gc_dst_overflow in_hlist_search out_= hlist_search\n"); for (lcpu =3D 0; lcpu < smp_num_cpus; lcpu++) { i =3D cpu_logical_map(lcpu); =20 @@ -2625,7 +2626,8 @@ add_timer(&rt_secret_timer); =20 proc_net_create ("rt_cache", 0, rt_cache_get_info); - proc_net_create ("rt_cache_stat", 0, rt_cache_stat_get_info); + create_proc_info_entry ("rt_cache", 0, proc_net_stat,=20 + rt_cache_stat_get_info); #ifdef CONFIG_NET_CLS_ROUTE create_proc_read_entry("net/rt_acct", 0, 0, ip_rt_acct_read, NULL); #endif diff -Nru --exclude-from=3D/sunbeam/home/laforge/scripts/dontdiff linux-2.4= =2E28-pre3-bk5-plain/net/ipv6/ndisc.c linux-2.4.28-pre3-bk5-neigh/net/ipv6/= ndisc.c --- linux-2.4.28-pre3-bk5-plain/net/ipv6/ndisc.c 2004-09-30 11:31:18.000000= 000 +0200 +++ linux-2.4.28-pre3-bk5-neigh/net/ipv6/ndisc.c 2004-09-30 16:12:47.000000= 000 +0200 @@ -60,6 +60,7 @@ #include #include #include +#include =20 #include #include @@ -240,15 +241,14 @@ =20 static u32 ndisc_hash(const void *pkey, const struct net_device *dev) { - u32 hash_val; + const u32 *p32 =3D pkey; + u32 addr_hash, i; =20 - hash_val =3D *(u32*)(pkey + sizeof(struct in6_addr) - 4); - hash_val ^=3D (hash_val>>16); - hash_val ^=3D hash_val>>8; - hash_val ^=3D hash_val>>3; - hash_val =3D (hash_val^dev->ifindex)&NEIGH_HASHMASK; + addr_hash =3D 0; + for (i =3D 0; i < (sizeof(struct in6_addr) / sizeof(u32)); i++) + addr_hash ^=3D *p32++; =20 - return hash_val; + return jhash_2words(addr_hash, dev->ifindex, nd_tbl.hash_rnd); } =20 static int ndisc_constructor(struct neighbour *neigh) @@ -696,9 +696,9 @@ int inc =3D ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; =20 if (inc) - nd_tbl.stats.rcv_probes_mcast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_mcast); else - nd_tbl.stats.rcv_probes_ucast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_ucast); =20 /*=20 * update / create cache entry @@ -741,9 +741,9 @@ if (addr_type & IPV6_ADDR_UNICAST) { int inc =3D ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; if (inc) =20 - nd_tbl.stats.rcv_probes_mcast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_mcast); else - nd_tbl.stats.rcv_probes_ucast++; + NEIGH_CACHE_STAT_INC(&nd_tbl, rcv_probes_ucast); =20 /* * update / create cache entry @@ -775,9 +775,11 @@ inc =3D=3D 0 || in6_dev->nd_parms->proxy_delay =3D=3D 0) { if (inc) - nd_tbl.stats.rcv_probes_mcast++; + NEIGH_CACHE_STAT_INC(&nd_tbl,=20 + rcv_probes_mcast); else - nd_tbl.stats.rcv_probes_ucast++; + NEIGH_CACHE_STAT_INC(&nd_tbl,=20 + rcv_probes_ucast); =09 neigh =3D neigh_event_ns(&nd_tbl, lladdr, saddr, dev); =20 --7tPHY7RFL01rOa8z-- --+vcRm3WFmV0Q/ShD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBXCqpXaXGVTD0i/8RAqaQAJ9+HDM8zxG/9joEvip49uYGS3gybQCcCAFS kPB1qiIT2RwLlSAgll2KfKI= =E2L8 -----END PGP SIGNATURE----- --+vcRm3WFmV0Q/ShD-- From greearb@candelatech.com Thu Sep 30 08:51:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 08:51:45 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UFpckG020818 for ; Thu, 30 Sep 2004 08:51:39 -0700 Received: from [4.35.49.74] (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i8UFtfLH009750; Thu, 30 Sep 2004 08:55:41 -0700 Message-ID: <415C2B7E.8060807@candelatech.com> Date: Thu, 30 Sep 2004 08:51:26 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com Subject: Re: Move fib_alias out of fib_hash.c References: <20040928214722.11aef8e0.davem@davemloft.net> <16730.53965.503605.943263@robur.slu.se> <20040929125359.12a00ba7.davem@davemloft.net> <1096492842.2344.57.camel@localhost.localdomain> <20040929142750.27b35952.davem@davemloft.net> <20040929220926.GE26714@wotan.suse.de> <415B3637.9060700@candelatech.com> <20040930080810.GB20106@wotan.suse.de> In-Reply-To: <20040930080810.GB20106@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 467 Lines: 17 Andi Kleen wrote: > There is no stable release cycle anymore. Linus has abolished that. > > Maybe we will get it back at some point if the current way doesn't > work out, but currently it's unlimited hacking time. Sounds fun for the programmers and a pain in the ass for everyone else. But, maybe I can shove some of my patches into the tree with less friction! Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jheffner@psc.edu Thu Sep 30 10:26:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 10:26:26 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UHQFWI023615 for ; Thu, 30 Sep 2004 10:26:15 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.12.10/8.12.5) with ESMTP id i8UHPlpu015179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 30 Sep 2004 13:25:47 -0400 (EDT) Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by dexter.psc.edu (8.12.10/8.12.5) with ESMTP id i8UHPkqZ014490; Thu, 30 Sep 2004 13:25:46 -0400 (EDT) Date: Thu, 30 Sep 2004 13:25:46 -0400 (EDT) From: John Heffner To: "David S. Miller" cc: Andi Kleen , , , , , Subject: Re: bad TSO performance in 2.6.9-rc2-BK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on mailer2.psc.edu X-Virus-Status: Clean X-archive-position: 9740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 686 Lines: 19 On Wed, 29 Sep 2004, John Heffner wrote: > On Wed, 29 Sep 2004, John Heffner wrote: > > > Using iperf, I'm getting ~ the same speed to a slow p3 receiver (680 > > Mbits) with TSO on or off right now. Haven't tried netperf. > > Netperf does not work well for me (350 Mbits). Something to investigate. I tried again, and it does not even work this well. The connection hangs at the end in state FIN_WAIT1 with 101361 bytes in the Send-Q. It seems that the whole interface dies. (Maybe it's sending something invalid to the TSO engine?) When I bring the interface down then back up again, the connection terminates normally. Don't have this problem with iperf, strange. -John From roland@topspin.com Thu Sep 30 11:41:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 11:41:25 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UIfKXQ027432 for ; Thu, 30 Sep 2004 11:41:21 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Thu, 30 Sep 2004 11:41:08 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 30 Sep 2004 11:41:08 -0700 Received: from roland by eddore with local (Exim 4.34) id 1CD5rX-0001z4-Oj; Thu, 30 Sep 2004 11:41:08 -0700 To: "David S. Miller" Cc: netdev@oss.sgi.com, openib-general@openib.org X-Message-Flag: Warning: May contain useful information References: <52fz5esxx6.fsf@topspin.com> <20040919140133.60ea3fb3.davem@davemloft.net> <52r7onc8ev.fsf@topspin.com> <20040927215244.697aaa02.davem@davemloft.net> From: Roland Dreier Date: Thu, 30 Sep 2004 11:41:07 -0700 In-Reply-To: <20040927215244.697aaa02.davem@davemloft.net> (David S. Miller's message of "Mon, 27 Sep 2004 21:52:44 -0700") Message-ID: <521xgj1tx8.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 30 Sep 2004 18:41:08.0345 (UTC) FILETIME=[0CC69E90:01C4A71D] X-archive-position: 9741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 970 Lines: 21 David> I think you might learn something by having a look at what David> net/atm/clip.c is doing, it creates it's own neighbour David> layer for CLIP ATM neighbours. It is in a similar boat to David> your IPoIB stuff. Thanks, this suggestion was very helpful. I think I'm making progress. Now I know my next question :) CLIP ATM is a little different from IPoIB in that it completely replaces the ARP layer with its own ARP daemon. For IPoIB I don't want to reinvent the ARP and ND code -- I just want to add a secondary lookup after the response comes back. I think I have an idea of how to do that and then stash the information in the struct neighbour, so that my hard_start_xmit method can get it from skb->dst (ala clip.c). However, it seems that broadcast ARP packets have skb->dst == NULL. Is it safe for me to assume that packets with skb->dst == NULL are broadcast packets? Will multicast packets have a non-NULL dst? Thanks, Roland From davem@davemloft.net Thu Sep 30 13:22:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 13:22:21 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UKM8kA000445 for ; Thu, 30 Sep 2004 13:22:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CD7Pj-0004No-00; Thu, 30 Sep 2004 13:20:31 -0700 Date: Thu, 30 Sep 2004 13:20:31 -0700 From: "David S. Miller" To: Andi Kleen Cc: herbert@gondor.apana.org.au, ak@suse.de, niv@us.ibm.com, jheffner@psc.edu, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040930132031.3264000b.davem@davemloft.net> In-Reply-To: <20040930092926.GA18353@wotan.suse.de> References: <415B24C0.2020208@us.ibm.com> <20040929145050.71afa1ac.davem@davemloft.net> <20040929215613.GC26714@wotan.suse.de> <20040929162923.796d142e.davem@davemloft.net> <20040930000515.GA10496@gondor.apana.org.au> <20040929213310.40f5f33a.davem@davemloft.net> <20040930092926.GA18353@wotan.suse.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 618 Lines: 17 On Thu, 30 Sep 2004 11:29:26 +0200 Andi Kleen wrote: > Talking to another rc3 kernel with tg3 tso on is as fast as tso off now. > Unfortunately the ACKs still look funny. Can you help us debug this instead of just running tests over and over Andi? It's frustrating because I cannot reproduce the problem here, else I would be adding checks to the receiver on my systems here. :-/ Please put some checks into the ACK tests on your 2.6.5 receiver to determine why it does not want to ACK every other frame like it is supposed to. We need to figure out where the stretch ACKs are coming from. Thanks. From davem@davemloft.net Thu Sep 30 13:25:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 13:25:48 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UKPh5c000856 for ; Thu, 30 Sep 2004 13:25:43 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CD7ST-0004OS-00; Thu, 30 Sep 2004 13:23:21 -0700 Date: Thu, 30 Sep 2004 13:23:21 -0700 From: "David S. Miller" To: John Heffner Cc: ak@suse.de, niv@us.ibm.com, herbert@gondor.apana.org.au, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040930132321.523c9490.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1146 Lines: 28 On Thu, 30 Sep 2004 13:25:46 -0400 (EDT) John Heffner wrote: > On Wed, 29 Sep 2004, John Heffner wrote: > > > On Wed, 29 Sep 2004, John Heffner wrote: > > > > > Using iperf, I'm getting ~ the same speed to a slow p3 receiver (680 > > > Mbits) with TSO on or off right now. Haven't tried netperf. > > > > Netperf does not work well for me (350 Mbits). Something to investigate. > > I tried again, and it does not even work this well. The connection hangs > at the end in state FIN_WAIT1 with 101361 bytes in the Send-Q. It seems > that the whole interface dies. (Maybe it's sending something invalid to > the TSO engine?) When I bring the interface down then back up again, the > connection terminates normally. > > Don't have this problem with iperf, strange. Even stranger is that with current netperf tg3-->tg3 works perfectly fine for me with TSO enabled. I'm getting clean 700Mbit transfers through my D-Link DGS-1008T switch as long as netperf doesn't do something silly like use tiny send/receiver buffers. I've never had a transfer stall either. Please help debug this John since I'm not seeing this here. From dlstevens@us.ibm.com Thu Sep 30 14:22:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 14:22:24 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ULMDZf002231 for ; Thu, 30 Sep 2004 14:22:20 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i8ULLNqY810906; Thu, 30 Sep 2004 17:21:23 -0400 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8ULLM2o379756; Thu, 30 Sep 2004 15:21:23 -0600 In-Reply-To: <521xgj1tx8.fsf@topspin.com> To: Roland Dreier Cc: "David S. Miller" , netdev@oss.sgi.com, openib-general@openib.org MIME-Version: 1.0 Subject: Re: Advice needed on IP-over-InfiniBand driver X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 30 Sep 2004 14:21:20 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/30/2004 15:21:22, Serialize complete at 09/30/2004 15:21:22 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 9744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 502 Lines: 11 > However, it seems that broadcast ARP packets have skb->dst == NULL. > Is it safe for me to assume that packets with skb->dst == NULL are > broadcast packets? Will multicast packets have a non-NULL dst? I think it would be a mistake to use skb->dst as a flag for unicast or not. Even if it is correct in all cases you care about now (I don't know either way), it would be a hidden dependency with high potential to break something eventually. +-DLS From romieu@fr.zoreil.com Thu Sep 30 14:40:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 14:40:51 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ULebrU002839 for ; Thu, 30 Sep 2004 14:40:40 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.10/8.12.1) with ESMTP id i8ULacvr016870; Thu, 30 Sep 2004 23:36:38 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.10/8.12.10/Submit) id i8ULabOD016869; Thu, 30 Sep 2004 23:36:37 +0200 Date: Thu, 30 Sep 2004 23:36:37 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: Jon Mason , jgarzik@pobox.com Subject: [PATCH] r8169 tx_timeout recovery and automatic DAC step-down Message-ID: <20040930213637.GA12646@electric-eye.fr.zoreil.com> References: <20040919224102.GA32577@electric-eye.fr.zoreil.com> <200409231558.29821.jdmason@us.ltcfwd.linux.ibm.com> <20040923220519.GD8018@electric-eye.fr.zoreil.com> <200409231840.12539.jdmason@us.ltcfwd.linux.ibm.com> <20040926230928.GA28817@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040926230928.GA28817@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 9745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 656 Lines: 19 Francois Romieu : [...] Errr... Oops. :o* Ok, try #2. Now I can recover from the infamous PCI DAC error on my 32 bit box. Any taker on amd64 ? http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc2-bk15/r8169-200.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc2-bk15/r8169-210.patch These patches apply against 2.6.9-rc2-mm2 or -netdev. If people want to use a vanilla post 2.6.9-rc2-bk15, the patches below must be applied first: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc2-bk15/r8169-2.6.9-rc2-bk15-dac-revert.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.9-rc2-bk15/r8169-rc2-mm2.patch -- Ueimor From roland@topspin.com Thu Sep 30 14:49:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 14:49:12 -0700 (PDT) Received: from umhlanga.STRATNET.NET (umhlanga.stratnet.net [12.162.17.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8ULn5WS003278 for ; Thu, 30 Sep 2004 14:49:06 -0700 Received: from exch-1.topspincom.com ([12.162.17.3]) by umhlanga.STRATNET.NET with Microsoft SMTPSVC(5.0.2195.5329); Thu, 30 Sep 2004 14:48:53 -0700 Received: from eddore ([10.10.253.169]) by exch-1.topspincom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 30 Sep 2004 14:48:53 -0700 Received: from roland by eddore with local (Exim 4.34) id 1CD8nF-0002HK-Cs; Thu, 30 Sep 2004 14:48:53 -0700 To: David Stevens Cc: "David S. Miller" , netdev@oss.sgi.com, openib-general@openib.org X-Message-Flag: Warning: May contain useful information References: From: Roland Dreier Date: Thu, 30 Sep 2004 14:48:53 -0700 In-Reply-To: (David Stevens's message of "Thu, 30 Sep 2004 14:21:20 -0700") Message-ID: <52sm8zxwai.fsf@topspin.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: roland@topspin.com Subject: Re: Advice needed on IP-over-InfiniBand driver Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on eddore) X-OriginalArrivalTime: 30 Sep 2004 21:48:53.0751 (UTC) FILETIME=[477B2870:01C4A737] X-archive-position: 9746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: roland@topspin.com Precedence: bulk X-list: netdev Content-Length: 627 Lines: 16 David> I think it would be a mistake to use skb->dst as a flag for David> unicast or not. Even if it is correct in all cases you care David> about now (I don't know either way), it would be a hidden David> dependency with high potential to break something David> eventually. That's kind of what I thought. But since my packets have no L2 header in them, I don't know what hard_start_xmit can look at other than skb->dst. I guess hard_header could put some info in skb->cb -- is cb available for net device use between hard_header and hard_start_xmit, or does someone else still own it? Thanks, Roland From xschmi00@stud.feec.vutbr.cz Thu Sep 30 15:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 15:06:05 -0700 (PDT) Received: from tron.kn.vutbr.cz (tron.kn.vutbr.cz [147.229.191.152]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8UM60nn003887 for ; Thu, 30 Sep 2004 15:06:00 -0700 Received: from [147.229.222.29] (a05-0930b.kn.vutbr.cz [147.229.222.29]) by tron.kn.vutbr.cz (8.12.9p2/8.12.9) with ESMTP id i8UM5VZm055687; Fri, 1 Oct 2004 00:05:41 +0200 (CEST) (envelope-from xschmi00@stud.feec.vutbr.cz) Message-ID: <415C8322.7030005@stud.feec.vutbr.cz> Date: Fri, 01 Oct 2004 00:05:22 +0200 From: Michal Schmidt User-Agent: Mozilla Thunderbird 0.8 (X11/20040927) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mlindner@syskonnect.de CC: netdev@oss.sgi.com Subject: [PATCH 2.6.9-rc3] sk98lin - register the driver with hotplug Content-Type: multipart/mixed; boundary="------------010404000700000007090003" X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-Scanned-By: milter-spamc/0.19.268 (tron [147.229.191.152]); Fri, 01 Oct 2004 00:05:42 +0200 X-archive-position: 9747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xschmi00@stud.feec.vutbr.cz Precedence: bulk X-list: netdev Content-Length: 899 Lines: 32 This is a multi-part message in MIME format. --------------010404000700000007090003 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Hello, The attached patch allows the sk98lin module to be loaded automatically by hotplug. Michal Schmidt --------------010404000700000007090003 Content-Type: text/plain; name="sk98lin-hotplug.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sk98lin-hotplug.diff" --- linux-2.6.9-rc3.orig/drivers/net/sk98lin/skge.c 2004-09-30 23:38:44.181252712 +0200 +++ linux-2.6.9-rc3/drivers/net/sk98lin/skge.c 2004-09-30 21:02:04.000000000 +0200 @@ -5169,6 +5169,8 @@ static struct pci_device_id skge_pci_tbl { 0, } }; +MODULE_DEVICE_TABLE(pci, skge_pci_tbl); + static struct pci_driver skge_driver = { .name = "skge", .id_table = skge_pci_tbl, --------------010404000700000007090003-- From yasuyuki.kozakai@toshiba.co.jp Thu Sep 30 17:20:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 17:20:21 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i910KFGp011992 for ; Thu, 30 Sep 2004 17:20:15 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i910Jnbv024575; Fri, 1 Oct 2004 09:19:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i910JnET008395; Fri, 1 Oct 2004 09:19:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA08392 ; Fri, 1 Oct 2004 09:19:49 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA14697; Fri, 1 Oct 2004 09:19:48 +0900 (JST) Received: by toshiba.co.jp id i910JlZY002193; Fri, 1 Oct 2004 09:19:48 +0900 (JST) Date: Fri, 01 Oct 2004 09:19:46 +0900 (JST) Message-Id: <200410010019.i910JlZY002193@toshiba.co.jp> To: kaber@trash.net Cc: yasuyuki.kozakai@toshiba.co.jp, okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type From: Yasuyuki Kozakai In-Reply-To: <415C1CC9.2090604@trash.net> References: <200409301239.i8UCdACm005816@toshiba.co.jp> <200409301244.i8UCid17009482@toshiba.co.jp> <415C1CC9.2090604@trash.net> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev Content-Length: 509 Lines: 21 Hi, From: Patrick McHardy Date: Thu, 30 Sep 2004 16:48:41 +0200 > >Sorry, I sent it to only netfilter-devel ml because I wanted someone to test > >it more before sending it to netdev ml. > > > > > > I've reviewed the patch, I think we can push it soon. > Did you do any changes besides the u_int8_t fix since > the last patch you sent ? No. Regards, ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project From davem@davemloft.net Thu Sep 30 17:36:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 17:36:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i910adiP012473 for ; Thu, 30 Sep 2004 17:36:40 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDBNf-0004kE-00; Thu, 30 Sep 2004 17:34:39 -0700 Date: Thu, 30 Sep 2004 17:34:39 -0700 From: "David S. Miller" To: Herbert Xu Cc: jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040930173439.3e0d2799.davem@davemloft.net> In-Reply-To: <20040930001007.GB10496@gondor.apana.org.au> References: <20040929162923.796d142e.davem@davemloft.net> <20040929170310.46c58095.davem@davemloft.net> <20040930001007.GB10496@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 439 Lines: 11 So I was wondering what in 2.6.5 vs. current 2.6.x TCP could be tripping up Andi's setup and I think I just found it. If I disable /proc/sys/net/tcp_moderate_rcvbuf performance goes down from ~634Mbit/sec to ~495Mbit/sec. Andi, I know you said that with TSO disabled things go more smoothly. But could you try upping the TCP socket receive buffer sizes on the 2.6.5 box to see if that gives you the performance back with TSO enabled? From davem@davemloft.net Thu Sep 30 18:15:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 18:15:35 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i911FMk0013367 for ; Thu, 30 Sep 2004 18:15:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDBya-0004nm-00; Thu, 30 Sep 2004 18:12:48 -0700 Date: Thu, 30 Sep 2004 18:12:48 -0700 From: "David S. Miller" To: "David S. Miller" Cc: herbert@gondor.apana.org.au, jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040930181248.48185e41.davem@davemloft.net> In-Reply-To: <20040930173439.3e0d2799.davem@davemloft.net> References: <20040929162923.796d142e.davem@davemloft.net> <20040929170310.46c58095.davem@davemloft.net> <20040930001007.GB10496@gondor.apana.org.au> <20040930173439.3e0d2799.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 3877 Lines: 116 On Thu, 30 Sep 2004 17:34:39 -0700 "David S. Miller" wrote: > If I disable /proc/sys/net/tcp_moderate_rcvbuf performance > goes down from ~634Mbit/sec to ~495Mbit/sec. > > Andi, I know you said that with TSO disabled things go > more smoothly. But could you try upping the TCP socket > receive buffer sizes on the 2.6.5 box to see if that gives > you the performance back with TSO enabled? Ok, here is something to play with. This adds a sysctl to moderate the percentage of the congestion window we'll limit TSO segmenting to. It defaults to 2, but setting of 3 or 4 seem to make Andi's case behave much better. With such small receive buffers, netperf simply can't clear the receive queue fast enough when a burst of TSO created frames come in. This is also where the stretch ACKs come from. We defer the ACK to recvmsg making progress, because we cannot advertise a larger window and thus the connection is application limited. I'm also thinking about whether this sysctl should be a divisor instead of a shift, and also whether it should be in terms of the snd_cwnd or the advertised receiver window whichever is smaller. Basically, receivers with too small socket receive buffers crap out if TSO bursts are too large. This effect is minimized the further the receiver is (rtt wise) from the sender since the path tends to smooth out the bursts. But on local gigabit lans, the effect is quite pronounced. Ironically, this case is a great example of how powerful and incredibly effective John's receive buffer moderation code is. 2.6.5 performance is severely hampered due to lack of this code. ===== include/linux/sysctl.h 1.88 vs edited ===== --- 1.88/include/linux/sysctl.h 2004-09-23 14:34:12 -07:00 +++ edited/include/linux/sysctl.h 2004-09-30 17:17:49 -07:00 @@ -341,6 +341,7 @@ NET_TCP_BIC_LOW_WINDOW=104, NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, + NET_TCP_TSO_CWND_SHIFT=107, }; enum { ===== include/net/tcp.h 1.92 vs edited ===== --- 1.92/include/net/tcp.h 2004-09-29 21:11:52 -07:00 +++ edited/include/net/tcp.h 2004-09-30 17:18:02 -07:00 @@ -609,6 +609,7 @@ extern int sysctl_tcp_bic_fast_convergence; extern int sysctl_tcp_bic_low_window; extern int sysctl_tcp_moderate_rcvbuf; +extern int sysctl_tcp_tso_cwnd_shift; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; ===== net/ipv4/sysctl_net_ipv4.c 1.25 vs edited ===== --- 1.25/net/ipv4/sysctl_net_ipv4.c 2004-08-26 13:55:36 -07:00 +++ edited/net/ipv4/sysctl_net_ipv4.c 2004-09-30 17:19:32 -07:00 @@ -674,6 +674,14 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_TSO_CWND_SHIFT, + .procname = "tcp_tso_cwnd_shift", + .data = &sysctl_tcp_tso_cwnd_shift, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; ===== net/ipv4/tcp_output.c 1.65 vs edited ===== --- 1.65/net/ipv4/tcp_output.c 2004-09-29 21:11:53 -07:00 +++ edited/net/ipv4/tcp_output.c 2004-09-30 17:27:32 -07:00 @@ -44,6 +44,7 @@ /* People can turn this off for buggy TCP's found in printers etc. */ int sysctl_tcp_retrans_collapse = 1; +int sysctl_tcp_tso_cwnd_shift = 2; static __inline__ void update_send_head(struct sock *sk, struct tcp_opt *tp, struct sk_buff *skb) @@ -673,7 +674,7 @@ !tp->urg_mode); if (do_large) { - int large_mss, factor; + int large_mss, factor, limit; large_mss = 65535 - tp->af_specific->net_header_len - tp->ext_header_len - tp->ext2_header_len - @@ -688,8 +689,10 @@ * can keep the ACK clock ticking. */ factor = large_mss / mss_now; - if (factor > (tp->snd_cwnd >> 2)) - factor = max(1, tp->snd_cwnd >> 2); + limit = tp->snd_cwnd >> sysctl_tcp_tso_cwnd_shift; + limit = max(1, limit); + if (factor > limit) + factor = limit; tp->mss_cache = mss_now * factor; From cranium2003@yahoo.com Thu Sep 30 19:37:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 19:37:40 -0700 (PDT) Received: from web41415.mail.yahoo.com (web41415.mail.yahoo.com [66.218.93.81]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i912bX2x015105 for ; Thu, 30 Sep 2004 19:37:33 -0700 Message-ID: <20041001023716.46520.qmail@web41415.mail.yahoo.com> Received: from [66.218.69.220] by web41415.mail.yahoo.com via HTTP; Thu, 30 Sep 2004 19:37:16 PDT Date: Thu, 30 Sep 2004 19:37:16 -0700 (PDT) From: cranium2003 Subject: Plzzz help me To: netdev@oss.sgi.com Cc: linux-net@veger.linux.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 383 Lines: 16 Hello, I want to know is there any way in linux kernel by which i can come to know that the outgoing packet is having destination address is of host not of router? I want to send different data to host/router depending on dest. address. regards, cranium. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From cranium2003@yahoo.com Thu Sep 30 19:40:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 19:40:13 -0700 (PDT) Received: from web41408.mail.yahoo.com (web41408.mail.yahoo.com [66.218.93.74]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i912e8UR015546 for ; Thu, 30 Sep 2004 19:40:08 -0700 Message-ID: <20041001023951.98119.qmail@web41408.mail.yahoo.com> Received: from [66.218.69.220] by web41408.mail.yahoo.com via HTTP; Thu, 30 Sep 2004 19:39:51 PDT Date: Thu, 30 Sep 2004 19:39:51 -0700 (PDT) From: cranium2003 Subject: Plzzz help me To: netdev@oss.sgi.com Cc: linux-net@veger.linux.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 399 Lines: 16 Hello, I want to know is there any way in linux kernel by which i can come to know that the outgoing packet is having destination address is of host not of router? I want to send different data to host/router depending on dest. address. regards, cranium. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From jgarzik@pobox.com Thu Sep 30 20:13:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 20:13:21 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i913DEh0016674 for ; Thu, 30 Sep 2004 20:13:15 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CDDqw-0001xH-8F; Fri, 01 Oct 2004 04:13:02 +0100 Message-ID: <415CCB32.9020708@pobox.com> Date: Thu, 30 Sep 2004 23:12:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jt@hpl.hp.com CC: netdev@oss.sgi.com Subject: Re: WE-17 typo fix References: <20040928184625.GA8299@bougret.hpl.hp.com> In-Reply-To: <20040928184625.GA8299@bougret.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 433 Lines: 17 Jean Tourrilhes wrote: > Hi Jeff, > > Felix R. found a typo in the WE-17 patch I sent you and is > pending in your tree (more correctly, an overzealous > search&replace). The patch below fix this mistake. > I would appreciate you adding this patch to your tree ;-) Applied, but, please try to stick more closely to the standard patch format, including the signed-off-by header. http://linux.yyz.us/patch-format.html Jeff From davem@davemloft.net Thu Sep 30 20:41:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 20:42:10 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i913fw0i021156 for ; Thu, 30 Sep 2004 20:41:59 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDEH7-0004yU-00; Thu, 30 Sep 2004 20:40:05 -0700 Date: Thu, 30 Sep 2004 20:40:05 -0700 From: "David S. Miller" To: "David S. Miller" Cc: herbert@gondor.apana.org.au, jheffner@psc.edu, ak@suse.de, niv@us.ibm.com, andy.grover@gmail.com, anton@samba.org, netdev@oss.sgi.com Subject: Re: bad TSO performance in 2.6.9-rc2-BK Message-Id: <20040930204005.69115c0e.davem@davemloft.net> In-Reply-To: <20040930181248.48185e41.davem@davemloft.net> References: <20040929162923.796d142e.davem@davemloft.net> <20040929170310.46c58095.davem@davemloft.net> <20040930001007.GB10496@gondor.apana.org.au> <20040930173439.3e0d2799.davem@davemloft.net> <20040930181248.48185e41.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 5603 Lines: 183 On Thu, 30 Sep 2004 18:12:48 -0700 "David S. Miller" wrote: > Ok, here is something to play with. This adds a sysctl > to moderate the percentage of the congestion window we'll > limit TSO segmenting to. I've done some tweaking and this is the patch I actually checked into my tree. I made it a divisor and the default is 8. I tried to play around with taking the send window and the congestion window both into account, but that did not help at all. My current setup is Ultra-III 750Mhz w/tg3 sending to Ultra-II 360Mhz w/tg3 through a D-Link DGS 1008-T gigabit switch. I'm using 32-bit binaries of netperf 2.3pl1 built with -DUSE_PROC_STAT and -DHAVE_SENDFILE. The MTU being used is 1500. Each run is made via "netperf -fM -H ${IP_OF_ULTRA-II}". I did 3 runs each for 4 different configurations. The parameters are "TSO on/off" (sender side) and "TCP rcvbuf moderation on/off" (receiver side). With this patch I'm seeing these results: TSO off + rbuf off: 63.15 MBytes/sec 64.78 MBytes/sec 64.53 MBytes/sec TSO on + rbuf off: 62.76 MBytes/sec 63.36 MBytes/sec 63.79 MBytes/sec TSO off + rbuf on: 71.98 MBytes/sec 73.52 MBytes/sec 73.57 MBytes/sec TSO on + rbuf on: 75.70 MBytes/sec 76.05 MBytes/sec 75.42 MBytes/sec The "rbuf off" cases are meant to emulate Andi's 2.6.5 case, and "rbuf on" is current 2.6.x. How do things look for you with this change Andi? If things are still out of whack, play around with different values of /proc/sys/net/ipv4/tcp_tso_win_divisor # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/30 20:09:28-07:00 davem@nuts.davemloft.net # [TCP]: Add tcp_tso_win_divisor sysctl. # # This allows control over what percentage of # the congestion window can be consumed by a # single TSO frame. # # The setting of this parameter is a choice # between burstiness and building larger TSO # frames. # # Signed-off-by: David S. Miller # # net/ipv4/tcp_output.c # 2004/09/30 20:07:20-07:00 davem@nuts.davemloft.net +19 -7 # [TCP]: Add tcp_tso_win_divisor sysctl. # # net/ipv4/sysctl_net_ipv4.c # 2004/09/30 20:07:20-07:00 davem@nuts.davemloft.net +8 -0 # [TCP]: Add tcp_tso_win_divisor sysctl. # # include/net/tcp.h # 2004/09/30 20:07:20-07:00 davem@nuts.davemloft.net +1 -0 # [TCP]: Add tcp_tso_win_divisor sysctl. # # include/linux/sysctl.h # 2004/09/30 20:07:20-07:00 davem@nuts.davemloft.net +1 -0 # [TCP]: Add tcp_tso_win_divisor sysctl. # diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h 2004-09-30 20:19:49 -07:00 +++ b/include/linux/sysctl.h 2004-09-30 20:19:49 -07:00 @@ -341,6 +341,7 @@ NET_TCP_BIC_LOW_WINDOW=104, NET_TCP_DEFAULT_WIN_SCALE=105, NET_TCP_MODERATE_RCVBUF=106, + NET_TCP_TSO_WIN_DIVISOR=107, }; enum { diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-09-30 20:19:49 -07:00 +++ b/include/net/tcp.h 2004-09-30 20:19:49 -07:00 @@ -609,6 +609,7 @@ extern int sysctl_tcp_bic_fast_convergence; extern int sysctl_tcp_bic_low_window; extern int sysctl_tcp_moderate_rcvbuf; +extern int sysctl_tcp_tso_win_divisor; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c 2004-09-30 20:19:49 -07:00 +++ b/net/ipv4/sysctl_net_ipv4.c 2004-09-30 20:19:49 -07:00 @@ -674,6 +674,14 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_TSO_WIN_DIVISOR, + .procname = "tcp_tso_win_divisor", + .data = &sysctl_tcp_tso_win_divisor, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-30 20:19:49 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-30 20:19:49 -07:00 @@ -45,6 +45,12 @@ /* People can turn this off for buggy TCP's found in printers etc. */ int sysctl_tcp_retrans_collapse = 1; +/* This limits the percentage of the congestion window which we + * will allow a single TSO frame to consume. Building TSO frames + * which are too large can cause TCP streams to be bursty. + */ +int sysctl_tcp_tso_win_divisor = 8; + static __inline__ void update_send_head(struct sock *sk, struct tcp_opt *tp, struct sk_buff *skb) { @@ -658,7 +664,7 @@ { struct tcp_opt *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); - int do_large, mss_now; + unsigned int do_large, mss_now; mss_now = tp->mss_cache_std; if (dst) { @@ -673,7 +679,7 @@ !tp->urg_mode); if (do_large) { - int large_mss, factor; + unsigned int large_mss, factor, limit; large_mss = 65535 - tp->af_specific->net_header_len - tp->ext_header_len - tp->ext2_header_len - @@ -683,13 +689,19 @@ large_mss = max((tp->max_window>>1), 68U - tp->tcp_header_len); + factor = large_mss / mss_now; + /* Always keep large mss multiple of real mss, but - * do not exceed 1/4 of the congestion window so we - * can keep the ACK clock ticking. + * do not exceed 1/tso_win_divisor of the congestion window + * so we can keep the ACK clock ticking and minimize + * bursting. */ - factor = large_mss / mss_now; - if (factor > (tp->snd_cwnd >> 2)) - factor = max(1, tp->snd_cwnd >> 2); + limit = tp->snd_cwnd; + if (sysctl_tcp_tso_win_divisor) + limit /= sysctl_tcp_tso_win_divisor; + limit = max(1U, limit); + if (factor > limit) + factor = limit; tp->mss_cache = mss_now * factor; From jgarzik@pobox.com Thu Sep 30 21:15:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 21:16:05 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i914FqLc022164 for ; Thu, 30 Sep 2004 21:15:52 -0700 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CDEpU-00034h-4N; Fri, 01 Oct 2004 05:15:36 +0100 Message-ID: <415CD9D9.2000607@pobox.com> Date: Fri, 01 Oct 2004 00:15:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margit Schubert-While CC: Nishanth Aravamudan , hvr@gnu.org, mcgrof@studorgs.rutgers.edu, kernel-janitors@lists.osdl.org, prism54-devel@prism54.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.9-rc2 17/38] net/islpci_dev: replace schedule_timeout() with msleep() References: <20040923221303.GB13244@us.ibm.com> <20040923221303.GB13244@us.ibm.com> <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> In-Reply-To: <5.1.0.14.2.20040924074745.00b1cd40@pop.t-online.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 57 Lines: 2 I would rather see an msleep implementation in 2.4.x... From davem@davemloft.net Thu Sep 30 21:20:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 21:20:28 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i914KMxa022842 for ; Thu, 30 Sep 2004 21:20:22 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDEsc-00050u-00; Thu, 30 Sep 2004 21:18:50 -0700 Date: Thu, 30 Sep 2004 21:18:50 -0700 From: "David S. Miller" To: John Heffner Cc: netdev@oss.sgi.com Subject: Re: TSO and MSS Message-Id: <20040930211850.53da1542.davem@davemloft.net> In-Reply-To: References: <20040929154645.4e8987d2.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 9756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 13523 Lines: 422 On Wed, 29 Sep 2004 18:51:36 -0400 (EDT) John Heffner wrote: > On Wed, 29 Sep 2004, David S. Miller wrote: > > > If you are on ethernet using different MTU's, shouldn't you be > > getting ICMP messages back when trying to communicate with that > > host which will decrease the PMTU of the path? TCP's MSS is > > determined in terms of this, so I can't see what the issue is. > > Unfortunately no. If there's no router in between, the frame gets smashed > and no ICMP is generated. Proper communication relies on honoring the MSS > value for directly connected machines. > > Regardless, it is probably a good idea to honor the MSS value anyway, > because I think you're violating the TCP spec otherwise. Ok, I hacked up the fix for this. There are some nice results to these changes: 1) All the 'hack zone' crap disappeared from ip_output.c 2) tcp_skb_cb got smaller again 3) ipv6 support could be added very easily, once we have cards that support this (none currently) It also fixes the MSS problem John Heffner noticed which caused this thread. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/09/30 20:58:53-07:00 davem@nuts.davemloft.net # [TCP]: Kill tso_{factor,mss}. # # We can just use skb_shinfo(skb)->tso_{segs,size} # directly. This also allows us to kill the # hack zone code in ip_output.c # # The original impetus for thus change was a problem # noted by John Heffner. We do not abide by the MSS # of the connection for TCP segmentation, we were using # the path MTU instead. This broke various local # network setups with TSO enabled and is fixed as a side # effect of these changes. # # Signed-off-by: David S. Miller # # net/ipv4/tcp_output.c # 2004/09/30 20:56:45-07:00 davem@nuts.davemloft.net +30 -28 # [TCP]: Kill tso_{factor,mss}. # # net/ipv4/tcp_input.c # 2004/09/30 20:56:45-07:00 davem@nuts.davemloft.net +7 -7 # [TCP]: Kill tso_{factor,mss}. # # net/ipv4/tcp.c # 2004/09/30 20:56:45-07:00 davem@nuts.davemloft.net +2 -2 # [TCP]: Kill tso_{factor,mss}. # # net/ipv4/ip_output.c # 2004/09/30 20:56:45-07:00 davem@nuts.davemloft.net +1 -14 # [TCP]: Kill tso_{factor,mss}. # # include/net/tcp.h # 2004/09/30 20:56:45-07:00 davem@nuts.davemloft.net +11 -7 # [TCP]: Kill tso_{factor,mss}. # diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h 2004-09-30 20:59:22 -07:00 +++ b/include/net/tcp.h 2004-09-30 20:59:22 -07:00 @@ -1152,8 +1152,6 @@ __u16 urg_ptr; /* Valid w/URG flags is set. */ __u32 ack_seq; /* Sequence number ACK'd */ - __u16 tso_factor; /* If > 1, TSO frame */ - __u16 tso_mss; /* MSS that FACTOR's in terms of*/ }; #define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0])) @@ -1165,7 +1163,13 @@ */ static inline int tcp_skb_pcount(struct sk_buff *skb) { - return TCP_SKB_CB(skb)->tso_factor; + return skb_shinfo(skb)->tso_segs; +} + +/* This is valid iff tcp_skb_pcount() > 1. */ +static inline int tcp_skb_psize(struct sk_buff *skb) +{ + return skb_shinfo(skb)->tso_size; } static inline void tcp_inc_pcount(tcp_pcount_t *count, struct sk_buff *skb) @@ -1440,7 +1444,7 @@ tcp_minshall_check(tp)))); } -extern void tcp_set_skb_tso_factor(struct sk_buff *, unsigned int); +extern void tcp_set_skb_tso_segs(struct sk_buff *, unsigned int); /* This checks if the data bearing packet SKB (usually sk->sk_send_head) * should be put on the wire right now. @@ -1448,11 +1452,11 @@ static __inline__ int tcp_snd_test(struct tcp_opt *tp, struct sk_buff *skb, unsigned cur_mss, int nonagle) { - int pkts = TCP_SKB_CB(skb)->tso_factor; + int pkts = tcp_skb_pcount(skb); if (!pkts) { - tcp_set_skb_tso_factor(skb, tp->mss_cache_std); - pkts = TCP_SKB_CB(skb)->tso_factor; + tcp_set_skb_tso_segs(skb, tp->mss_cache_std); + pkts = tcp_skb_pcount(skb); } /* RFC 1122 - section 4.2.3.4 diff -Nru a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c --- a/net/ipv4/ip_output.c 2004-09-30 20:59:22 -07:00 +++ b/net/ipv4/ip_output.c 2004-09-30 20:59:22 -07:00 @@ -305,7 +305,6 @@ struct ip_options *opt = inet->opt; struct rtable *rt; struct iphdr *iph; - u32 mtu; /* Skip all of this if the packet is already routed, * f.e. by something like SCTP. @@ -366,21 +365,9 @@ skb->nh.iph = iph; /* Transport layer set skb->h.foo itself. */ - if(opt && opt->optlen) { + if (opt && opt->optlen) { iph->ihl += opt->optlen >> 2; ip_options_build(skb, opt, inet->daddr, rt, 0); - } - - mtu = dst_pmtu(&rt->u.dst); - if (skb->len > mtu && (sk->sk_route_caps & NETIF_F_TSO)) { - unsigned int hlen; - - /* Hack zone: all this must be done by TCP. */ - hlen = ((skb->h.raw - skb->data) + (skb->h.th->doff << 2)); - skb_shinfo(skb)->tso_size = mtu - hlen; - skb_shinfo(skb)->tso_segs = - (skb->len - hlen + skb_shinfo(skb)->tso_size - 1)/ - skb_shinfo(skb)->tso_size - 1; } ip_select_ident_more(iph, &rt->u.dst, sk, skb_shinfo(skb)->tso_segs); diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c 2004-09-30 20:59:22 -07:00 +++ b/net/ipv4/tcp.c 2004-09-30 20:59:22 -07:00 @@ -691,7 +691,7 @@ skb->ip_summed = CHECKSUM_HW; tp->write_seq += copy; TCP_SKB_CB(skb)->end_seq += copy; - TCP_SKB_CB(skb)->tso_factor = 0; + skb_shinfo(skb)->tso_segs = 0; if (!copied) TCP_SKB_CB(skb)->flags &= ~TCPCB_FLAG_PSH; @@ -938,7 +938,7 @@ tp->write_seq += copy; TCP_SKB_CB(skb)->end_seq += copy; - TCP_SKB_CB(skb)->tso_factor = 0; + skb_shinfo(skb)->tso_segs = 0; from += copy; copied += copy; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c 2004-09-30 20:59:22 -07:00 +++ b/net/ipv4/tcp_input.c 2004-09-30 20:59:22 -07:00 @@ -1035,7 +1035,7 @@ if(!before(TCP_SKB_CB(skb)->seq, end_seq)) break; - fack_count += TCP_SKB_CB(skb)->tso_factor; + fack_count += tcp_skb_pcount(skb); in_sack = !after(start_seq, TCP_SKB_CB(skb)->seq) && !before(end_seq, TCP_SKB_CB(skb)->end_seq); @@ -1224,7 +1224,7 @@ tcp_set_pcount(&tp->fackets_out, 0); sk_stream_for_retrans_queue(skb, sk) { - cnt += TCP_SKB_CB(skb)->tso_factor;; + cnt += tcp_skb_pcount(skb); TCP_SKB_CB(skb)->sacked &= ~TCPCB_LOST; if (!(TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_ACKED)) { @@ -1299,7 +1299,7 @@ tp->undo_marker = tp->snd_una; sk_stream_for_retrans_queue(skb, sk) { - cnt += TCP_SKB_CB(skb)->tso_factor; + cnt += tcp_skb_pcount(skb); if (TCP_SKB_CB(skb)->sacked&TCPCB_RETRANS) tp->undo_marker = 0; TCP_SKB_CB(skb)->sacked &= (~TCPCB_TAGBITS)|TCPCB_SACKED_ACKED; @@ -1550,7 +1550,7 @@ BUG_TRAP(cnt <= tcp_get_pcount(&tp->packets_out)); sk_stream_for_retrans_queue(skb, sk) { - cnt -= TCP_SKB_CB(skb)->tso_factor; + cnt -= tcp_skb_pcount(skb); if (cnt < 0 || after(TCP_SKB_CB(skb)->end_seq, high_seq)) break; if (!(TCP_SKB_CB(skb)->sacked&TCPCB_TAGBITS)) { @@ -2369,7 +2369,7 @@ { struct tcp_opt *tp = tcp_sk(sk); struct tcp_skb_cb *scb = TCP_SKB_CB(skb); - __u32 mss = scb->tso_mss; + __u32 mss = tcp_skb_psize(skb); __u32 snd_una = tp->snd_una; __u32 orig_seq, seq; __u32 packets_acked = 0; @@ -2423,7 +2423,7 @@ } tcp_dec_pcount_explicit(&tp->packets_out, packets_acked); - BUG_ON(scb->tso_factor == 0); + BUG_ON(tcp_skb_pcount(skb) == 0); BUG_ON(!before(scb->seq, scb->end_seq)); } @@ -2450,7 +2450,7 @@ * the other end. */ if (after(scb->end_seq, tp->snd_una)) { - if (scb->tso_factor > 1) + if (tcp_skb_pcount(skb) > 1) acked |= tcp_tso_acked(sk, skb, now, &seq_rtt); break; diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c 2004-09-30 20:59:22 -07:00 +++ b/net/ipv4/tcp_output.c 2004-09-30 20:59:22 -07:00 @@ -274,7 +274,7 @@ int sysctl_flags; int err; - BUG_ON(!TCP_SKB_CB(skb)->tso_factor); + BUG_ON(!tcp_skb_pcount(skb)); #define SYSCTL_FLAG_TSTAMPS 0x1 #define SYSCTL_FLAG_WSCALE 0x2 @@ -428,21 +428,22 @@ } } -void tcp_set_skb_tso_factor(struct sk_buff *skb, unsigned int mss_std) +void tcp_set_skb_tso_segs(struct sk_buff *skb, unsigned int mss_std) { if (skb->len <= mss_std) { /* Avoid the costly divide in the normal * non-TSO case. */ - TCP_SKB_CB(skb)->tso_factor = 1; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; } else { unsigned int factor; factor = skb->len + (mss_std - 1); factor /= mss_std; - TCP_SKB_CB(skb)->tso_factor = factor; + skb_shinfo(skb)->tso_segs = factor; + skb_shinfo(skb)->tso_size = mss_std; } - TCP_SKB_CB(skb)->tso_mss = mss_std; } /* Function to create two new TCP segments. Shrinks the given segment @@ -508,8 +509,8 @@ } /* Fix up tso_factor for both original and new SKB. */ - tcp_set_skb_tso_factor(skb, tp->mss_cache_std); - tcp_set_skb_tso_factor(buff, tp->mss_cache_std); + tcp_set_skb_tso_segs(skb, tp->mss_cache_std); + tcp_set_skb_tso_segs(buff, tp->mss_cache_std); if (TCP_SKB_CB(skb)->sacked & TCPCB_LOST) { tcp_inc_pcount(&tp->lost_out, skb); @@ -585,7 +586,7 @@ /* Any change of skb->len requires recalculation of tso * factor and mss. */ - tcp_set_skb_tso_factor(skb, tp->mss_cache_std); + tcp_set_skb_tso_segs(skb, tp->mss_cache_std); return 0; } @@ -914,8 +915,8 @@ ((skb_size + next_skb_size) > mss_now)) return; - BUG_ON(TCP_SKB_CB(skb)->tso_factor != 1 || - TCP_SKB_CB(next_skb)->tso_factor != 1); + BUG_ON(tcp_skb_pcount(skb) != 1 || + tcp_skb_pcount(next_skb) != 1); /* Ok. We will be able to collapse the packet. */ __skb_unlink(next_skb, next_skb->list); @@ -1047,14 +1048,14 @@ return -EAGAIN; if (skb->len > cur_mss) { - int old_factor = TCP_SKB_CB(skb)->tso_factor; + int old_factor = tcp_skb_pcount(skb); int new_factor; if (tcp_fragment(sk, skb, cur_mss)) return -ENOMEM; /* We'll try again later. */ /* New SKB created, account for it. */ - new_factor = TCP_SKB_CB(skb)->tso_factor; + new_factor = tcp_skb_pcount(skb); tcp_dec_pcount_explicit(&tp->packets_out, old_factor - new_factor); tcp_inc_pcount(&tp->packets_out, skb->next); @@ -1081,7 +1082,8 @@ tp->snd_una == (TCP_SKB_CB(skb)->end_seq - 1)) { if (!pskb_trim(skb, 0)) { TCP_SKB_CB(skb)->seq = TCP_SKB_CB(skb)->end_seq - 1; - TCP_SKB_CB(skb)->tso_factor = 1; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; skb->ip_summed = CHECKSUM_NONE; skb->csum = 0; } @@ -1166,7 +1168,7 @@ tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, tp->rto); } - packet_cnt -= TCP_SKB_CB(skb)->tso_factor; + packet_cnt -= tcp_skb_pcount(skb); if (packet_cnt <= 0) break; } @@ -1256,8 +1258,8 @@ skb->csum = 0; TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_FIN); TCP_SKB_CB(skb)->sacked = 0; - TCP_SKB_CB(skb)->tso_factor = 1; - TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; /* FIN eats a sequence byte, write_seq advanced by tcp_queue_skb(). */ TCP_SKB_CB(skb)->seq = tp->write_seq; @@ -1289,8 +1291,8 @@ skb->csum = 0; TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_RST); TCP_SKB_CB(skb)->sacked = 0; - TCP_SKB_CB(skb)->tso_factor = 1; - TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; /* Send it off. */ TCP_SKB_CB(skb)->seq = tcp_acceptable_seq(sk, tp); @@ -1371,8 +1373,8 @@ TCP_SKB_CB(skb)->seq = req->snt_isn; TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(skb)->seq + 1; TCP_SKB_CB(skb)->sacked = 0; - TCP_SKB_CB(skb)->tso_factor = 1; - TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; th->seq = htonl(TCP_SKB_CB(skb)->seq); th->ack_seq = htonl(req->rcv_isn + 1); if (req->rcv_wnd == 0) { /* ignored for retransmitted syns */ @@ -1474,8 +1476,8 @@ TCP_SKB_CB(buff)->flags = TCPCB_FLAG_SYN; TCP_ECN_send_syn(sk, tp, buff); TCP_SKB_CB(buff)->sacked = 0; - TCP_SKB_CB(buff)->tso_factor = 1; - TCP_SKB_CB(buff)->tso_mss = tp->mss_cache_std; + skb_shinfo(buff)->tso_segs = 1; + skb_shinfo(buff)->tso_size = 0; buff->csum = 0; TCP_SKB_CB(buff)->seq = tp->write_seq++; TCP_SKB_CB(buff)->end_seq = tp->write_seq; @@ -1575,8 +1577,8 @@ buff->csum = 0; TCP_SKB_CB(buff)->flags = TCPCB_FLAG_ACK; TCP_SKB_CB(buff)->sacked = 0; - TCP_SKB_CB(buff)->tso_factor = 1; - TCP_SKB_CB(buff)->tso_mss = tp->mss_cache_std; + skb_shinfo(buff)->tso_segs = 1; + skb_shinfo(buff)->tso_size = 0; /* Send it off, this clears delayed acks for us. */ TCP_SKB_CB(buff)->seq = TCP_SKB_CB(buff)->end_seq = tcp_acceptable_seq(sk, tp); @@ -1611,8 +1613,8 @@ skb->csum = 0; TCP_SKB_CB(skb)->flags = TCPCB_FLAG_ACK; TCP_SKB_CB(skb)->sacked = urgent; - TCP_SKB_CB(skb)->tso_factor = 1; - TCP_SKB_CB(skb)->tso_mss = tp->mss_cache_std; + skb_shinfo(skb)->tso_segs = 1; + skb_shinfo(skb)->tso_size = 0; /* Use a previous sequence. This should cause the other * end to send an ack. Don't queue or clone SKB, just @@ -1656,8 +1658,8 @@ sk->sk_route_caps &= ~NETIF_F_TSO; tp->mss_cache = tp->mss_cache_std; } - } else if (!TCP_SKB_CB(skb)->tso_factor) - tcp_set_skb_tso_factor(skb, tp->mss_cache_std); + } else if (!tcp_skb_pcount(skb)) + tcp_set_skb_tso_segs(skb, tp->mss_cache_std); TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_PSH; TCP_SKB_CB(skb)->when = tcp_time_stamp; From davem@davemloft.net Thu Sep 30 21:33:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 21:33:50 -0700 (PDT) Received: from cheetah.davemloft.net (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i914XiiQ023359 for ; Thu, 30 Sep 2004 21:33:45 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1CDF5h-00051Y-00; Thu, 30 Sep 2004 21:32:21 -0700 Date: Thu, 30 Sep 2004 21:32:21 -0700 From: "David S. Miller" To: netdev@oss.sgi.com Cc: ak@suse.de, jheffner@psc.edu, herbert@gondor.apana.org.au Subject: Current 2.6.x TSO state Message-Id: <20040930213221.06a3f5b3.davem@davemloft.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h" X-archive-position: 9757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 37064 Lines: 548 This is a multi-part message in MIME format. --Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Attached are the 4 TCP TSO patches I have in my tree. They are relative to Linus's current tree and also available at: bk://kernel.bkbits.net/davem/net-2.6 The quick summary is: diff1) Smooth out TSO ack clocking by calling tcp_trim_head() at tcp_tso_ack() time and making tcp_trim_head() liberate socket send buffer space. diff2) URG fix in tcp_tso_ack() diff3) Add tcp_tso_win_divisor sysctl knob. diff4) Obey MSS in tso handling, shrink tcp_skb_cb Existing known problems requiring a fix in time for 2.6.9-final are: 1) Andi sees performance anomaly to 2.6.5 kernels. Hopefully fixed by diff3 above, merely awaiting retesting by him. 2) John Heffner sees some kind of weird transfer hang, down/up'ing the interface makes transfer finish successfully. He has told me he will spend some time this weekend trying to debug it. Future enhancements which are not as critical as the above: 1) Handle SACK tagging of TSO frames... somehow. I don't have any brilliant ideas currently. We could use bits, to represent sub-TSO SACK regions. This would impose a hard limit of something like 32 for the maximum TSO factor. Another idea is to resegment a TSO frame when SACKs cover portions. This approach is my least favorite because SACKs can be common in the presence of even minor packet reordering. So we'd be splitting up + copying a lot. 2) Leave TSO enabled even during loss events. #1 is pretty much a prerequisite for #2 If we don't do #1 first, most SACKs get entirely ignored. 3) Fix up the packet counting once we have sub-TSO SACK tagging in place. Ok that's enough TSO hacking for me today. --Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h Content-Type: application/octet-stream; name="diff1" Content-Disposition: attachment; filename="diff1" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMjkgMjE6MTI6MTgtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IFNtb290aCBvdXQgVFNPIGFjayBjbG9ja2luZy4KIyAgIAoj ICAgLSBFeHBvcnQgdGNwX3RyaW1faGVhZCgpIGFuZCBjYWxsIGl0IGRpcmVjdGx5IGZyb20KIyAg ICAgdGNwX3Rzb19hY2tlZCgpLiAgVGhpcyBhbHNvIGZpeGVzIFVSRyBoYW5kbGluZy4KIyAgIAoj ICAgLSBNYWtlIHRjcF90cmltX2hlYWQoKSBhZGp1c3QgdGhlIHNrYi0+dHJ1ZXNpemUgb2YKIyAg ICAgdGhlIHBhY2tldCBhbmQgbGliZXJhdGUgdGhhdCBzcGFjZSBmcm9tIHRoZSBzb2NrZXQKIyAg ICAgc2VuZCBidWZmZXIuCiMgICAKIyAgIC0gSW4gdGNwX2N1cnJlbnRfbXNzKCksIGxpbWl0IFRT TyBmYWN0b3IgdG8gMS80IG9mCiMgICAgIHNuZF9jd25kLiAgVGhlIGlkZWEgaXMgZnJvbSBKb2hu IEhlZmZuZXIuCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1A ZGF2ZW1sb2Z0Lm5ldD4KIyAKIyBuZXQvaXB2NC90Y3Bfb3V0cHV0LmMKIyAgIDIwMDQvMDkvMjkg MjE6MTE6NTMtMDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsxNSAtMzUKIyAgIFtUQ1Bd OiBTbW9vdGggb3V0IFRTTyBhY2sgY2xvY2tpbmcuCiMgICAKIyAgIC0gRXhwb3J0IHRjcF90cmlt X2hlYWQoKSBhbmQgY2FsbCBpdCBkaXJlY3RseSBmcm9tCiMgICAgIHRjcF90c29fYWNrZWQoKS4g IFRoaXMgYWxzbyBmaXhlcyBVUkcgaGFuZGxpbmcuCiMgICAKIyAgIC0gTWFrZSB0Y3BfdHJpbV9o ZWFkKCkgYWRqdXN0IHRoZSBza2ItPnRydWVzaXplIG9mCiMgICAgIHRoZSBwYWNrZXQgYW5kIGxp YmVyYXRlIHRoYXQgc3BhY2UgZnJvbSB0aGUgc29ja2V0CiMgICAgIHNlbmQgYnVmZmVyLgojICAg CiMgICAtIEluIHRjcF9jdXJyZW50X21zcygpLCBsaW1pdCBUU08gZmFjdG9yIHRvIDEvNCBvZgoj ICAgICBzbmRfY3duZC4gIFRoZSBpZGVhIGlzIGZyb20gSm9obiBIZWZmbmVyLgojICAgCiMgICBT aWduZWQtb2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+CiMgCiMg bmV0L2lwdjQvdGNwX2lucHV0LmMKIyAgIDIwMDQvMDkvMjkgMjE6MTE6NTMtMDc6MDAgZGF2ZW1A bnV0cy5kYXZlbWxvZnQubmV0ICs5IC0xMwojICAgW1RDUF06IFNtb290aCBvdXQgVFNPIGFjayBj bG9ja2luZy4KIyAgIAojICAgLSBFeHBvcnQgdGNwX3RyaW1faGVhZCgpIGFuZCBjYWxsIGl0IGRp cmVjdGx5IGZyb20KIyAgICAgdGNwX3Rzb19hY2tlZCgpLiAgVGhpcyBhbHNvIGZpeGVzIFVSRyBo YW5kbGluZy4KIyAgIAojICAgLSBNYWtlIHRjcF90cmltX2hlYWQoKSBhZGp1c3QgdGhlIHNrYi0+ dHJ1ZXNpemUgb2YKIyAgICAgdGhlIHBhY2tldCBhbmQgbGliZXJhdGUgdGhhdCBzcGFjZSBmcm9t IHRoZSBzb2NrZXQKIyAgICAgc2VuZCBidWZmZXIuCiMgICAKIyAgIC0gSW4gdGNwX2N1cnJlbnRf bXNzKCksIGxpbWl0IFRTTyBmYWN0b3IgdG8gMS80IG9mCiMgICAgIHNuZF9jd25kLiAgVGhlIGlk ZWEgaXMgZnJvbSBKb2huIEhlZmZuZXIuCiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMu IE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4KIyAKIyBpbmNsdWRlL25ldC90Y3AuaAojICAg MjAwNC8wOS8yOSAyMToxMTo1Mi0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzEgLTAK IyAgIFtUQ1BdOiBTbW9vdGggb3V0IFRTTyBhY2sgY2xvY2tpbmcuCiMgICAKIyAgIC0gRXhwb3J0 IHRjcF90cmltX2hlYWQoKSBhbmQgY2FsbCBpdCBkaXJlY3RseSBmcm9tCiMgICAgIHRjcF90c29f YWNrZWQoKS4gIFRoaXMgYWxzbyBmaXhlcyBVUkcgaGFuZGxpbmcuCiMgICAKIyAgIC0gTWFrZSB0 Y3BfdHJpbV9oZWFkKCkgYWRqdXN0IHRoZSBza2ItPnRydWVzaXplIG9mCiMgICAgIHRoZSBwYWNr ZXQgYW5kIGxpYmVyYXRlIHRoYXQgc3BhY2UgZnJvbSB0aGUgc29ja2V0CiMgICAgIHNlbmQgYnVm ZmVyLgojICAgCiMgICAtIEluIHRjcF9jdXJyZW50X21zcygpLCBsaW1pdCBUU08gZmFjdG9yIHRv IDEvNCBvZgojICAgICBzbmRfY3duZC4gIFRoZSBpZGVhIGlzIGZyb20gSm9obiBIZWZmbmVyLgoj ICAgCiMgICBTaWduZWQtb2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5u ZXQ+CiMgCmRpZmYgLU5ydSBhL2luY2x1ZGUvbmV0L3RjcC5oIGIvaW5jbHVkZS9uZXQvdGNwLmgK LS0tIGEvaW5jbHVkZS9uZXQvdGNwLmgJMjAwNC0wOS0zMCAyMTowMjozNCAtMDc6MDAKKysrIGIv aW5jbHVkZS9uZXQvdGNwLmgJMjAwNC0wOS0zMCAyMTowMjozNCAtMDc6MDAKQEAgLTk0NCw2ICs5 NDQsNyBAQAogZXh0ZXJuIGludCB0Y3BfcmV0cmFuc21pdF9za2Ioc3RydWN0IHNvY2sgKiwgc3Ry dWN0IHNrX2J1ZmYgKik7CiBleHRlcm4gdm9pZCB0Y3BfeG1pdF9yZXRyYW5zbWl0X3F1ZXVlKHN0 cnVjdCBzb2NrICopOwogZXh0ZXJuIHZvaWQgdGNwX3NpbXBsZV9yZXRyYW5zbWl0KHN0cnVjdCBz b2NrICopOworZXh0ZXJuIGludCB0Y3BfdHJpbV9oZWFkKHN0cnVjdCBzb2NrICosIHN0cnVjdCBz a19idWZmICosIHUzMik7CiAKIGV4dGVybiB2b2lkIHRjcF9zZW5kX3Byb2JlMChzdHJ1Y3Qgc29j ayAqKTsKIGV4dGVybiB2b2lkIHRjcF9zZW5kX3BhcnRpYWwoc3RydWN0IHNvY2sgKik7CmRpZmYg LU5ydSBhL25ldC9pcHY0L3RjcF9pbnB1dC5jIGIvbmV0L2lwdjQvdGNwX2lucHV0LmMKLS0tIGEv bmV0L2lwdjQvdGNwX2lucHV0LmMJMjAwNC0wOS0zMCAyMTowMjozNCAtMDc6MDAKKysrIGIvbmV0 L2lwdjQvdGNwX2lucHV0LmMJMjAwNC0wOS0zMCAyMTowMjozNCAtMDc6MDAKQEAgLTIzNjQsMTMg KzIzNjQsMTQgQEAKICAqIHRoZW4gbWFraW5nIGEgd3JpdGUgc3BhY2Ugd2FrZXVwIGNhbGxiYWNr IGlzIGEgcG9zc2libGUKICAqIGZ1dHVyZSBlbmhhbmNlbWVudC4gIFdBUk5JTkc6IGl0IGlzIG5v dCB0cml2aWFsIHRvIG1ha2UuCiAgKi8KLXN0YXRpYyBpbnQgdGNwX3Rzb19hY2tlZChzdHJ1Y3Qg dGNwX29wdCAqdHAsIHN0cnVjdCBza19idWZmICpza2IsCitzdGF0aWMgaW50IHRjcF90c29fYWNr ZWQoc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiLAogCQkJIF9fdTMyIG5vdywg X19zMzIgKnNlcV9ydHQpCiB7CisJc3RydWN0IHRjcF9vcHQgKnRwID0gdGNwX3NrKHNrKTsKIAlz dHJ1Y3QgdGNwX3NrYl9jYiAqc2NiID0gVENQX1NLQl9DQihza2IpOyAKIAlfX3UzMiBtc3MgPSBz Y2ItPnRzb19tc3M7CiAJX191MzIgc25kX3VuYSA9IHRwLT5zbmRfdW5hOwotCV9fdTMyIHNlcSA9 IHNjYi0+c2VxOworCV9fdTMyIG9yaWdfc2VxLCBzZXE7CiAJX191MzIgcGFja2V0c19hY2tlZCA9 IDA7CiAJaW50IGFja2VkID0gMDsKIApAQCAtMjM3OSwyMiArMjM4MCwxOCBAQAogCSAqLwogCUJV R19PTighYWZ0ZXIoc2NiLT5lbmRfc2VxLCBzbmRfdW5hKSk7CiAKKwlzZXEgPSBvcmlnX3NlcSA9 IHNjYi0+c2VxOwogCXdoaWxlICghYWZ0ZXIoc2VxICsgbXNzLCBzbmRfdW5hKSkgewogCQlwYWNr ZXRzX2Fja2VkKys7CiAJCXNlcSArPSBtc3M7CiAJfQogCisJaWYgKHRjcF90cmltX2hlYWQoc2ss IHNrYiwgKHNlcSAtIG9yaWdfc2VxKSkpCisJCXJldHVybiAwOworCiAJaWYgKHBhY2tldHNfYWNr ZWQpIHsKIAkJX191OCBzYWNrZWQgPSBzY2ItPnNhY2tlZDsKIAotCQkvKiBXZSBhZGp1c3Qgc2Ni LT5zZXEgYnV0IHdlIGRvIG5vdCBwc2tiX3B1bGwoKSB0aGUKLQkJICogU0tCLiAgV2UgbGV0IHRj cF9yZXRyYW5zbWl0X3NrYigpIGhhbmRsZSB0aGlzIGNhc2UKLQkJICogYnkgY2hlY2tpbmcgc2ti LT5sZW4gYWdhaW5zdCB0aGUgZGF0YSBzZXF1ZW5jZSBzcGFuLgotCQkgKiBUaGlzIHdheSwgd2Ug YXZvaWQgdGhlIHBza2JfcHVsbCgpIHdvcmsgdW5sZXNzIHdlCi0JCSAqIGFjdHVhbGx5IG5lZWQg dG8gcmV0cmFuc21pdCB0aGUgU0tCLgotCQkgKi8KLQkJc2NiLT5zZXEgPSBzZXE7Ci0KIAkJYWNr ZWQgfD0gRkxBR19EQVRBX0FDS0VEOwogCQlpZiAoc2Fja2VkKSB7CiAJCQlpZiAoc2Fja2VkICYg VENQQ0JfUkVUUkFOUykgewpAQCAtMjQxMyw3ICsyNDEwLDcgQEAKIAkJCQkJCQlwYWNrZXRzX2Fj a2VkKTsKIAkJCWlmIChzYWNrZWQgJiBUQ1BDQl9VUkcpIHsKIAkJCQlpZiAodHAtPnVyZ19tb2Rl ICYmCi0JCQkJICAgICFiZWZvcmUoc2NiLT5zZXEsIHRwLT5zbmRfdXApKQorCQkJCSAgICAhYmVm b3JlKG9yaWdfc2VxLCB0cC0+c25kX3VwKSkKIAkJCQkJdHAtPnVyZ19tb2RlID0gMDsKIAkJCX0K IAkJfSBlbHNlIGlmICgqc2VxX3J0dCA8IDApCkBAIC0yNDI1LDcgKzI0MjIsNiBAQAogCQkJdGNw X2RlY19wY291bnRfZXhwbGljaXQoJnRwLT5mYWNrZXRzX291dCwgZHZhbCk7CiAJCX0KIAkJdGNw X2RlY19wY291bnRfZXhwbGljaXQoJnRwLT5wYWNrZXRzX291dCwgcGFja2V0c19hY2tlZCk7Ci0J CXNjYi0+dHNvX2ZhY3RvciAtPSBwYWNrZXRzX2Fja2VkOwogCiAJCUJVR19PTihzY2ItPnRzb19m YWN0b3IgPT0gMCk7CiAJCUJVR19PTighYmVmb3JlKHNjYi0+c2VxLCBzY2ItPmVuZF9zZXEpKTsK QEAgLTI0NTUsNyArMjQ1MSw3IEBACiAJCSAqLwogCQlpZiAoYWZ0ZXIoc2NiLT5lbmRfc2VxLCB0 cC0+c25kX3VuYSkpIHsKIAkJCWlmIChzY2ItPnRzb19mYWN0b3IgPiAxKQotCQkJCWFja2VkIHw9 IHRjcF90c29fYWNrZWQodHAsIHNrYiwKKwkJCQlhY2tlZCB8PSB0Y3BfdHNvX2Fja2VkKHNrLCBz a2IsCiAJCQkJCQkgICAgICAgbm93LCAmc2VxX3J0dCk7CiAJCQlicmVhazsKIAkJfQpkaWZmIC1O cnUgYS9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMgYi9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMKLS0tIGEv bmV0L2lwdjQvdGNwX291dHB1dC5jCTIwMDQtMDktMzAgMjE6MDI6MzQgLTA3OjAwCisrKyBiL25l dC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA0LTA5LTMwIDIxOjAyOjM0IC0wNzowMApAQCAtNTI1LDcg KzUyNSw3IEBACiAgKiBldmVudHVhbGx5KS4gVGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBwdWxsZWQg ZGF0YSBub3QgY29waWVkLCBidXQKICAqIGltbWVkaWF0ZWx5IGRpc2NhcmRlZC4KICAqLwotdW5z aWduZWQgY2hhciAqIF9fcHNrYl90cmltX2hlYWQoc3RydWN0IHNrX2J1ZmYgKnNrYiwgaW50IGxl bikKK3N0YXRpYyB1bnNpZ25lZCBjaGFyICpfX3Bza2JfdHJpbV9oZWFkKHN0cnVjdCBza19idWZm ICpza2IsIGludCBsZW4pCiB7CiAJaW50IGksIGssIGVhdDsKIApAQCAtNTUzLDggKzU1MywxMCBA QAogCXJldHVybiBza2ItPnRhaWw7CiB9CiAKLXN0YXRpYyBpbnQgX190Y3BfdHJpbV9oZWFkKHN0 cnVjdCB0Y3Bfb3B0ICp0cCwgc3RydWN0IHNrX2J1ZmYgKnNrYiwgdTMyIGxlbikKK2ludCB0Y3Bf dHJpbV9oZWFkKHN0cnVjdCBzb2NrICpzaywgc3RydWN0IHNrX2J1ZmYgKnNrYiwgdTMyIGxlbikK IHsKKwlzdHJ1Y3QgdGNwX29wdCAqdHAgPSB0Y3Bfc2soc2spOworCiAJaWYgKHNrYl9jbG9uZWQo c2tiKSAmJgogCSAgICBwc2tiX2V4cGFuZF9oZWFkKHNrYiwgMCwgMCwgR0ZQX0FUT01JQykpCiAJ CXJldHVybiAtRU5PTUVNOwpAQCAtNTY2LDggKzU2OCwxNCBAQAogCQkJcmV0dXJuIC1FTk9NRU07 CiAJfQogCisJVENQX1NLQl9DQihza2IpLT5zZXEgKz0gbGVuOwogCXNrYi0+aXBfc3VtbWVkID0g Q0hFQ0tTVU1fSFc7CiAKKwlza2ItPnRydWVzaXplCSAgICAgLT0gbGVuOworCXNrLT5za19xdWV1 ZV9zaHJ1bmsgICA9IDE7CisJc2stPnNrX3dtZW1fcXVldWVkICAgLT0gbGVuOworCXNrLT5za19m b3J3YXJkX2FsbG9jICs9IGxlbjsKKwogCS8qIEFueSBjaGFuZ2Ugb2Ygc2tiLT5sZW4gcmVxdWly ZXMgcmVjYWxjdWxhdGlvbiBvZiB0c28KIAkgKiBmYWN0b3IgYW5kIG1zcy4KIAkgKi8KQEAgLTU3 NiwxNiArNTg0LDYgQEAKIAlyZXR1cm4gMDsKIH0KIAotc3RhdGljIGlubGluZSBpbnQgdGNwX3Ry aW1faGVhZChzdHJ1Y3QgdGNwX29wdCAqdHAsIHN0cnVjdCBza19idWZmICpza2IsIHUzMiBsZW4p Ci17Ci0JaW50IGVyciA9IF9fdGNwX3RyaW1faGVhZCh0cCwgc2tiLCBsZW4pOwotCi0JaWYgKCFl cnIpCi0JCVRDUF9TS0JfQ0Ioc2tiKS0+c2VxICs9IGxlbjsKLQotCXJldHVybiBlcnI7Ci19Ci0K IC8qIFRoaXMgZnVuY3Rpb24gc3luY2hyb25pemUgc25kIG1zcyB0byBjdXJyZW50IHBtdHUvZXh0 aGRyIHNldC4KIAogICAgdHAtPnVzZXJfbXNzIGlzIG1zcyBzZXQgYnkgdXNlciBieSBUQ1BfTUFY U0VHLiBJdCBkb2VzIE5PVCBjb3VudHMKQEAgLTY4NiwxMSArNjg0LDEyIEBACiAJCQkJCTY4VSAt IHRwLT50Y3BfaGVhZGVyX2xlbik7CiAKIAkJLyogQWx3YXlzIGtlZXAgbGFyZ2UgbXNzIG11bHRp cGxlIG9mIHJlYWwgbXNzLCBidXQKLQkJICogZG8gbm90IGV4Y2VlZCBjb25nZXN0aW9uIHdpbmRv dy4KKwkJICogZG8gbm90IGV4Y2VlZCAxLzQgb2YgdGhlIGNvbmdlc3Rpb24gd2luZG93IHNvIHdl CisJCSAqIGNhbiBrZWVwIHRoZSBBQ0sgY2xvY2sgdGlja2luZy4KIAkJICovCiAJCWZhY3RvciA9 IGxhcmdlX21zcyAvIG1zc19ub3c7Ci0JCWlmIChmYWN0b3IgPiB0cC0+c25kX2N3bmQpCi0JCQlm YWN0b3IgPSB0cC0+c25kX2N3bmQ7CisJCWlmIChmYWN0b3IgPiAodHAtPnNuZF9jd25kID4+IDIp KQorCQkJZmFjdG9yID0gbWF4KDEsIHRwLT5zbmRfY3duZCA+PiAyKTsKIAogCQl0cC0+bXNzX2Nh Y2hlID0gbXNzX25vdyAqIGZhY3RvcjsKIApAQCAtMTAwMyw3ICsxMDAyLDYgQEAKIHsKIAlzdHJ1 Y3QgdGNwX29wdCAqdHAgPSB0Y3Bfc2soc2spOwogIAl1bnNpZ25lZCBpbnQgY3VyX21zcyA9IHRj cF9jdXJyZW50X21zcyhzaywgMCk7Ci0JX191MzIgZGF0YV9zZXEsIGRhdGFfZW5kX3NlcTsKIAlp bnQgZXJyOwogCiAJLyogRG8gbm90IHNlbnQgbW9yZSB0aGFuIHdlIHF1ZXVlZC4gMS80IGlzIHJl c2VydmVkIGZvciBwb3NzaWJsZQpAQCAtMTAxMywyNCArMTAxMSw2IEBACiAJICAgIG1pbihzay0+ c2tfd21lbV9xdWV1ZWQgKyAoc2stPnNrX3dtZW1fcXVldWVkID4+IDIpLCBzay0+c2tfc25kYnVm KSkKIAkJcmV0dXJuIC1FQUdBSU47CiAKLQkvKiBXaGF0IGlzIGdvaW5nIG9uIGhlcmU/ICBXaGVu IFRTTyBwYWNrZXRzIGFyZSBwYXJ0aWFsbHkgQUNLJ2QsCi0JICogd2UgYWRqdXN0IHRoZSBUQ1Bf U0tCX0NCKHNrYiktPnNlcSB2YWx1ZSBmb3J3YXJkIGJ1dCB3ZSBkbwotCSAqIG5vdCBhZGp1c3Qg dGhlIGRhdGEgYXJlYSBvZiB0aGUgU0tCLiAgV2UgZGVmZXIgdGhhdCB0byBoZXJlCi0JICogc28g dGhhdCB3ZSBjYW4gYXZvaWQgdGhlIHdvcmsgdW5sZXNzIHdlIHJlYWxseSByZXRyYW5zbWl0Ci0J ICogdGhlIHBhY2tldC4KLQkgKi8KLQlkYXRhX3NlcSA9IFRDUF9TS0JfQ0Ioc2tiKS0+c2VxOwot CWRhdGFfZW5kX3NlcSA9IFRDUF9TS0JfQ0Ioc2tiKS0+ZW5kX3NlcTsKLQlpZiAoVENQX1NLQl9D Qihza2IpLT5mbGFncyAmIFRDUENCX0ZMQUdfRklOKQotCQlkYXRhX2VuZF9zZXEtLTsKLQotCWlm IChza2ItPmxlbiA+IChkYXRhX2VuZF9zZXEgLSBkYXRhX3NlcSkpIHsKLQkJdTMyIHRvX3RyaW0g PSBza2ItPmxlbiAtIChkYXRhX2VuZF9zZXEgLSBkYXRhX3NlcSk7Ci0KLQkJaWYgKF9fdGNwX3Ry aW1faGVhZCh0cCwgc2tiLCB0b190cmltKSkKLQkJCXJldHVybiAtRU5PTUVNOwotCX0JCQotCiAJ aWYgKGJlZm9yZShUQ1BfU0tCX0NCKHNrYiktPnNlcSwgdHAtPnNuZF91bmEpKSB7CiAJCWlmIChi ZWZvcmUoVENQX1NLQl9DQihza2IpLT5lbmRfc2VxLCB0cC0+c25kX3VuYSkpCiAJCQlCVUcoKTsK QEAgLTEwNDEsNyArMTAyMSw3IEBACiAJCQl0cC0+bXNzX2NhY2hlID0gdHAtPm1zc19jYWNoZV9z dGQ7CiAJCX0KIAotCQlpZiAodGNwX3RyaW1faGVhZCh0cCwgc2tiLCB0cC0+c25kX3VuYSAtIFRD UF9TS0JfQ0Ioc2tiKS0+c2VxKSkKKwkJaWYgKHRjcF90cmltX2hlYWQoc2ssIHNrYiwgdHAtPnNu ZF91bmEgLSBUQ1BfU0tCX0NCKHNrYiktPnNlcSkpCiAJCQlyZXR1cm4gLUVOT01FTTsKIAl9CiAK --Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h Content-Type: application/octet-stream; name="diff2" Content-Disposition: attachment; filename="diff2" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMzAgMTI6NDI6MjktMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IENoZWNrIGNvcnJlY3Qgc2VxdWVuY2UgbnVtYmVyIGZvciBV UkcgaW4gdGNwX3Rzb19hY2tlZCgpLgojICAgCiMgICBOb3RpY2VkIGJ5IEhlcmJlcnQgWHUuCiMg ICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5l dD4KIyAKIyBuZXQvaXB2NC90Y3BfaW5wdXQuYwojICAgMjAwNC8wOS8zMCAxMjo0MTo1Ny0wNzow MCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzEgLTEKIyAgIFtUQ1BdOiBDaGVjayBjb3JyZWN0 IHNlcXVlbmNlIG51bWJlciBmb3IgVVJHIGluIHRjcF90c29fYWNrZWQoKS4KIyAKZGlmZiAtTnJ1 IGEvbmV0L2lwdjQvdGNwX2lucHV0LmMgYi9uZXQvaXB2NC90Y3BfaW5wdXQuYwotLS0gYS9uZXQv aXB2NC90Y3BfaW5wdXQuYwkyMDA0LTA5LTMwIDIxOjAyOjQ3IC0wNzowMAorKysgYi9uZXQvaXB2 NC90Y3BfaW5wdXQuYwkyMDA0LTA5LTMwIDIxOjAyOjQ3IC0wNzowMApAQCAtMjQxMCw3ICsyNDEw LDcgQEAKIAkJCQkJCQlwYWNrZXRzX2Fja2VkKTsKIAkJCWlmIChzYWNrZWQgJiBUQ1BDQl9VUkcp IHsKIAkJCQlpZiAodHAtPnVyZ19tb2RlICYmCi0JCQkJICAgICFiZWZvcmUob3JpZ19zZXEsIHRw LT5zbmRfdXApKQorCQkJCSAgICAhYmVmb3JlKHNlcSwgdHAtPnNuZF91cCkpCiAJCQkJCXRwLT51 cmdfbW9kZSA9IDA7CiAJCQl9CiAJCX0gZWxzZSBpZiAoKnNlcV9ydHQgPCAwKQo= --Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h Content-Type: application/octet-stream; name="diff3" Content-Disposition: attachment; filename="diff3" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMzAgMjA6MDk6MjgtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IEFkZCB0Y3BfdHNvX3dpbl9kaXZpc29yIHN5c2N0bC4KIyAg IAojICAgVGhpcyBhbGxvd3MgY29udHJvbCBvdmVyIHdoYXQgcGVyY2VudGFnZSBvZgojICAgdGhl IGNvbmdlc3Rpb24gd2luZG93IGNhbiBiZSBjb25zdW1lZCBieSBhCiMgICBzaW5nbGUgVFNPIGZy YW1lLgojICAgCiMgICBUaGUgc2V0dGluZyBvZiB0aGlzIHBhcmFtZXRlciBpcyBhIGNob2ljZQoj ICAgYmV0d2VlbiBidXJzdGluZXNzIGFuZCBidWlsZGluZyBsYXJnZXIgVFNPCiMgICBmcmFtZXMu CiMgICAKIyAgIFNpZ25lZC1vZmYtYnk6IERhdmlkIFMuIE1pbGxlciA8ZGF2ZW1AZGF2ZW1sb2Z0 Lm5ldD4KIyAKIyBuZXQvaXB2NC90Y3Bfb3V0cHV0LmMKIyAgIDIwMDQvMDkvMzAgMjA6MDc6MjAt MDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsxOSAtNwojICAgW1RDUF06IEFkZCB0Y3Bf dHNvX3dpbl9kaXZpc29yIHN5c2N0bC4KIyAKIyBuZXQvaXB2NC9zeXNjdGxfbmV0X2lwdjQuYwoj ICAgMjAwNC8wOS8zMCAyMDowNzoyMC0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzgg LTAKIyAgIFtUQ1BdOiBBZGQgdGNwX3Rzb193aW5fZGl2aXNvciBzeXNjdGwuCiMgCiMgaW5jbHVk ZS9uZXQvdGNwLmgKIyAgIDIwMDQvMDkvMzAgMjA6MDc6MjAtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0ICsxIC0wCiMgICBbVENQXTogQWRkIHRjcF90c29fd2luX2Rpdmlzb3Igc3lzY3Rs LgojIAojIGluY2x1ZGUvbGludXgvc3lzY3RsLmgKIyAgIDIwMDQvMDkvMzAgMjA6MDc6MjAtMDc6 MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsxIC0wCiMgICBbVENQXTogQWRkIHRjcF90c29f d2luX2Rpdmlzb3Igc3lzY3RsLgojIApkaWZmIC1OcnUgYS9pbmNsdWRlL2xpbnV4L3N5c2N0bC5o IGIvaW5jbHVkZS9saW51eC9zeXNjdGwuaAotLS0gYS9pbmNsdWRlL2xpbnV4L3N5c2N0bC5oCTIw MDQtMDktMzAgMjE6MDM6MDAgLTA3OjAwCisrKyBiL2luY2x1ZGUvbGludXgvc3lzY3RsLmgJMjAw NC0wOS0zMCAyMTowMzowMCAtMDc6MDAKQEAgLTM0MSw2ICszNDEsNyBAQAogCU5FVF9UQ1BfQklD X0xPV19XSU5ET1c9MTA0LAogCU5FVF9UQ1BfREVGQVVMVF9XSU5fU0NBTEU9MTA1LAogCU5FVF9U Q1BfTU9ERVJBVEVfUkNWQlVGPTEwNiwKKwlORVRfVENQX1RTT19XSU5fRElWSVNPUj0xMDcsCiB9 OwogCiBlbnVtIHsKZGlmZiAtTnJ1IGEvaW5jbHVkZS9uZXQvdGNwLmggYi9pbmNsdWRlL25ldC90 Y3AuaAotLS0gYS9pbmNsdWRlL25ldC90Y3AuaAkyMDA0LTA5LTMwIDIxOjAzOjAwIC0wNzowMAor KysgYi9pbmNsdWRlL25ldC90Y3AuaAkyMDA0LTA5LTMwIDIxOjAzOjAwIC0wNzowMApAQCAtNjA5 LDYgKzYwOSw3IEBACiBleHRlcm4gaW50IHN5c2N0bF90Y3BfYmljX2Zhc3RfY29udmVyZ2VuY2U7 CiBleHRlcm4gaW50IHN5c2N0bF90Y3BfYmljX2xvd193aW5kb3c7CiBleHRlcm4gaW50IHN5c2N0 bF90Y3BfbW9kZXJhdGVfcmN2YnVmOworZXh0ZXJuIGludCBzeXNjdGxfdGNwX3Rzb193aW5fZGl2 aXNvcjsKIAogZXh0ZXJuIGF0b21pY190IHRjcF9tZW1vcnlfYWxsb2NhdGVkOwogZXh0ZXJuIGF0 b21pY190IHRjcF9zb2NrZXRzX2FsbG9jYXRlZDsKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvc3lzY3Rs X25ldF9pcHY0LmMgYi9uZXQvaXB2NC9zeXNjdGxfbmV0X2lwdjQuYwotLS0gYS9uZXQvaXB2NC9z eXNjdGxfbmV0X2lwdjQuYwkyMDA0LTA5LTMwIDIxOjAzOjAxIC0wNzowMAorKysgYi9uZXQvaXB2 NC9zeXNjdGxfbmV0X2lwdjQuYwkyMDA0LTA5LTMwIDIxOjAzOjAxIC0wNzowMApAQCAtNjc0LDYg KzY3NCwxNCBAQAogCQkubW9kZQkJPSAwNjQ0LAogCQkucHJvY19oYW5kbGVyCT0gJnByb2NfZG9p bnR2ZWMsCiAJfSwKKwl7CisJCS5jdGxfbmFtZQk9IE5FVF9UQ1BfVFNPX1dJTl9ESVZJU09SLAor CQkucHJvY25hbWUJPSAidGNwX3Rzb193aW5fZGl2aXNvciIsCisJCS5kYXRhCQk9ICZzeXNjdGxf dGNwX3Rzb193aW5fZGl2aXNvciwKKwkJLm1heGxlbgkJPSBzaXplb2YoaW50KSwKKwkJLm1vZGUJ CT0gMDY0NCwKKwkJLnByb2NfaGFuZGxlcgk9ICZwcm9jX2RvaW50dmVjLAorCX0sCiAJeyAuY3Rs X25hbWUgPSAwIH0KIH07CiAKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvdGNwX291dHB1dC5jIGIvbmV0 L2lwdjQvdGNwX291dHB1dC5jCi0tLSBhL25ldC9pcHY0L3RjcF9vdXRwdXQuYwkyMDA0LTA5LTMw IDIxOjAzOjAwIC0wNzowMAorKysgYi9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0zMCAy MTowMzowMSAtMDc6MDAKQEAgLTQ1LDYgKzQ1LDEyIEBACiAvKiBQZW9wbGUgY2FuIHR1cm4gdGhp cyBvZmYgZm9yIGJ1Z2d5IFRDUCdzIGZvdW5kIGluIHByaW50ZXJzIGV0Yy4gKi8KIGludCBzeXNj dGxfdGNwX3JldHJhbnNfY29sbGFwc2UgPSAxOwogCisvKiBUaGlzIGxpbWl0cyB0aGUgcGVyY2Vu dGFnZSBvZiB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgd2hpY2ggd2UKKyAqIHdpbGwgYWxsb3cgYSBz aW5nbGUgVFNPIGZyYW1lIHRvIGNvbnN1bWUuICBCdWlsZGluZyBUU08gZnJhbWVzCisgKiB3aGlj aCBhcmUgdG9vIGxhcmdlIGNhbiBjYXVzZSBUQ1Agc3RyZWFtcyB0byBiZSBidXJzdHkuCisgKi8K K2ludCBzeXNjdGxfdGNwX3Rzb193aW5fZGl2aXNvciA9IDg7CisKIHN0YXRpYyBfX2lubGluZV9f CiB2b2lkIHVwZGF0ZV9zZW5kX2hlYWQoc3RydWN0IHNvY2sgKnNrLCBzdHJ1Y3QgdGNwX29wdCAq dHAsIHN0cnVjdCBza19idWZmICpza2IpCiB7CkBAIC02NTgsNyArNjY0LDcgQEAKIHsKIAlzdHJ1 Y3QgdGNwX29wdCAqdHAgPSB0Y3Bfc2soc2spOwogCXN0cnVjdCBkc3RfZW50cnkgKmRzdCA9IF9f c2tfZHN0X2dldChzayk7Ci0JaW50IGRvX2xhcmdlLCBtc3Nfbm93OworCXVuc2lnbmVkIGludCBk b19sYXJnZSwgbXNzX25vdzsKIAogCW1zc19ub3cgPSB0cC0+bXNzX2NhY2hlX3N0ZDsKIAlpZiAo ZHN0KSB7CkBAIC02NzMsNyArNjc5LDcgQEAKIAkJICAgICF0cC0+dXJnX21vZGUpOwogCiAJaWYg KGRvX2xhcmdlKSB7Ci0JCWludCBsYXJnZV9tc3MsIGZhY3RvcjsKKwkJdW5zaWduZWQgaW50IGxh cmdlX21zcywgZmFjdG9yLCBsaW1pdDsKIAogCQlsYXJnZV9tc3MgPSA2NTUzNSAtIHRwLT5hZl9z cGVjaWZpYy0+bmV0X2hlYWRlcl9sZW4gLQogCQkJdHAtPmV4dF9oZWFkZXJfbGVuIC0gdHAtPmV4 dDJfaGVhZGVyX2xlbiAtCkBAIC02ODMsMTMgKzY4OSwxOSBAQAogCQkJbGFyZ2VfbXNzID0gbWF4 KCh0cC0+bWF4X3dpbmRvdz4+MSksCiAJCQkJCTY4VSAtIHRwLT50Y3BfaGVhZGVyX2xlbik7CiAK KwkJZmFjdG9yID0gbGFyZ2VfbXNzIC8gbXNzX25vdzsKKwogCQkvKiBBbHdheXMga2VlcCBsYXJn ZSBtc3MgbXVsdGlwbGUgb2YgcmVhbCBtc3MsIGJ1dAotCQkgKiBkbyBub3QgZXhjZWVkIDEvNCBv ZiB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgc28gd2UKLQkJICogY2FuIGtlZXAgdGhlIEFDSyBjbG9j ayB0aWNraW5nLgorCQkgKiBkbyBub3QgZXhjZWVkIDEvdHNvX3dpbl9kaXZpc29yIG9mIHRoZSBj b25nZXN0aW9uIHdpbmRvdworCQkgKiBzbyB3ZSBjYW4ga2VlcCB0aGUgQUNLIGNsb2NrIHRpY2tp bmcgYW5kIG1pbmltaXplCisJCSAqIGJ1cnN0aW5nLgogCQkgKi8KLQkJZmFjdG9yID0gbGFyZ2Vf bXNzIC8gbXNzX25vdzsKLQkJaWYgKGZhY3RvciA+ICh0cC0+c25kX2N3bmQgPj4gMikpCi0JCQlm YWN0b3IgPSBtYXgoMSwgdHAtPnNuZF9jd25kID4+IDIpOworCQlsaW1pdCA9IHRwLT5zbmRfY3du ZDsKKwkJaWYgKHN5c2N0bF90Y3BfdHNvX3dpbl9kaXZpc29yKQorCQkJbGltaXQgLz0gc3lzY3Rs X3RjcF90c29fd2luX2Rpdmlzb3I7CisJCWxpbWl0ID0gbWF4KDFVLCBsaW1pdCk7CisJCWlmIChm YWN0b3IgPiBsaW1pdCkKKwkJCWZhY3RvciA9IGxpbWl0OwogCiAJCXRwLT5tc3NfY2FjaGUgPSBt c3Nfbm93ICogZmFjdG9yOwogCg== --Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h Content-Type: application/octet-stream; name="diff4" Content-Disposition: attachment; filename="diff4" Content-Transfer-Encoding: base64 IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5bGUgcGF0Y2guCiMK IyBDaGFuZ2VTZXQKIyAgIDIwMDQvMDkvMzAgMjA6NTg6NTMtMDc6MDAgZGF2ZW1AbnV0cy5kYXZl bWxvZnQubmV0IAojICAgW1RDUF06IEtpbGwgdHNvX3tmYWN0b3IsbXNzfS4KIyAgIAojICAgV2Ug Y2FuIGp1c3QgdXNlIHNrYl9zaGluZm8oc2tiKS0+dHNvX3tzZWdzLHNpemV9CiMgICBkaXJlY3Rs eS4gIFRoaXMgYWxzbyBhbGxvd3MgdXMgdG8ga2lsbCB0aGUKIyAgIGhhY2sgem9uZSBjb2RlIGlu IGlwX291dHB1dC5jCiMgICAKIyAgIFRoZSBvcmlnaW5hbCBpbXBldHVzIGZvciB0aHVzIGNoYW5n ZSB3YXMgYSBwcm9ibGVtCiMgICBub3RlZCBieSBKb2huIEhlZmZuZXIuICBXZSBkbyBub3QgYWJp ZGUgYnkgdGhlIE1TUwojICAgb2YgdGhlIGNvbm5lY3Rpb24gZm9yIFRDUCBzZWdtZW50YXRpb24s IHdlIHdlcmUgdXNpbmcKIyAgIHRoZSBwYXRoIE1UVSBpbnN0ZWFkLiAgVGhpcyBicm9rZSB2YXJp b3VzIGxvY2FsCiMgICBuZXR3b3JrIHNldHVwcyB3aXRoIFRTTyBlbmFibGVkIGFuZCBpcyBmaXhl ZCBhcyBhIHNpZGUKIyAgIGVmZmVjdCBvZiB0aGVzZSBjaGFuZ2VzLgojICAgCiMgICBTaWduZWQt b2ZmLWJ5OiBEYXZpZCBTLiBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5uZXQ+CiMgCiMgbmV0L2lw djQvdGNwX291dHB1dC5jCiMgICAyMDA0LzA5LzMwIDIwOjU2OjQ1LTA3OjAwIGRhdmVtQG51dHMu ZGF2ZW1sb2Z0Lm5ldCArMzAgLTI4CiMgICBbVENQXTogS2lsbCB0c29fe2ZhY3Rvcixtc3N9Lgoj IAojIG5ldC9pcHY0L3RjcF9pbnB1dC5jCiMgICAyMDA0LzA5LzMwIDIwOjU2OjQ1LTA3OjAwIGRh dmVtQG51dHMuZGF2ZW1sb2Z0Lm5ldCArNyAtNwojICAgW1RDUF06IEtpbGwgdHNvX3tmYWN0b3Is bXNzfS4KIyAKIyBuZXQvaXB2NC90Y3AuYwojICAgMjAwNC8wOS8zMCAyMDo1Njo0NS0wNzowMCBk YXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzIgLTIKIyAgIFtUQ1BdOiBLaWxsIHRzb197ZmFjdG9y LG1zc30uCiMgCiMgbmV0L2lwdjQvaXBfb3V0cHV0LmMKIyAgIDIwMDQvMDkvMzAgMjA6NTY6NDUt MDc6MDAgZGF2ZW1AbnV0cy5kYXZlbWxvZnQubmV0ICsxIC0xNAojICAgW1RDUF06IEtpbGwgdHNv X3tmYWN0b3IsbXNzfS4KIyAKIyBpbmNsdWRlL25ldC90Y3AuaAojICAgMjAwNC8wOS8zMCAyMDo1 Njo0NS0wNzowMCBkYXZlbUBudXRzLmRhdmVtbG9mdC5uZXQgKzExIC03CiMgICBbVENQXTogS2ls bCB0c29fe2ZhY3Rvcixtc3N9LgojIApkaWZmIC1OcnUgYS9pbmNsdWRlL25ldC90Y3AuaCBiL2lu Y2x1ZGUvbmV0L3RjcC5oCi0tLSBhL2luY2x1ZGUvbmV0L3RjcC5oCTIwMDQtMDktMzAgMjE6MDM6 MTQgLTA3OjAwCisrKyBiL2luY2x1ZGUvbmV0L3RjcC5oCTIwMDQtMDktMzAgMjE6MDM6MTQgLTA3 OjAwCkBAIC0xMTUyLDggKzExNTIsNiBAQAogCiAJX191MTYJCXVyZ19wdHI7CS8qIFZhbGlkIHcv VVJHIGZsYWdzIGlzIHNldC4JKi8KIAlfX3UzMgkJYWNrX3NlcTsJLyogU2VxdWVuY2UgbnVtYmVy IEFDSydkCSovCi0JX191MTYJCXRzb19mYWN0b3I7CS8qIElmID4gMSwgVFNPIGZyYW1lCQkqLwot CV9fdTE2CQl0c29fbXNzOwkvKiBNU1MgdGhhdCBGQUNUT1IncyBpbiB0ZXJtcyBvZiovCiB9Owog CiAjZGVmaW5lIFRDUF9TS0JfQ0IoX19za2IpCSgoc3RydWN0IHRjcF9za2JfY2IgKikmKChfX3Nr YiktPmNiWzBdKSkKQEAgLTExNjUsNyArMTE2MywxMyBAQAogICovCiBzdGF0aWMgaW5saW5lIGlu dCB0Y3Bfc2tiX3Bjb3VudChzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogewotCXJldHVybiBUQ1BfU0tC X0NCKHNrYiktPnRzb19mYWN0b3I7CisJcmV0dXJuIHNrYl9zaGluZm8oc2tiKS0+dHNvX3NlZ3M7 Cit9CisKKy8qIFRoaXMgaXMgdmFsaWQgaWZmIHRjcF9za2JfcGNvdW50KCkgPiAxLiAqLworc3Rh dGljIGlubGluZSBpbnQgdGNwX3NrYl9wc2l6ZShzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQoreworCXJl dHVybiBza2Jfc2hpbmZvKHNrYiktPnRzb19zaXplOwogfQogCiBzdGF0aWMgaW5saW5lIHZvaWQg dGNwX2luY19wY291bnQodGNwX3Bjb3VudF90ICpjb3VudCwgc3RydWN0IHNrX2J1ZmYgKnNrYikK QEAgLTE0NDAsNyArMTQ0NCw3IEBACiAJCSAgdGNwX21pbnNoYWxsX2NoZWNrKHRwKSkpKTsKIH0K IAotZXh0ZXJuIHZvaWQgdGNwX3NldF9za2JfdHNvX2ZhY3RvcihzdHJ1Y3Qgc2tfYnVmZiAqLCB1 bnNpZ25lZCBpbnQpOworZXh0ZXJuIHZvaWQgdGNwX3NldF9za2JfdHNvX3NlZ3Moc3RydWN0IHNr X2J1ZmYgKiwgdW5zaWduZWQgaW50KTsKIAogLyogVGhpcyBjaGVja3MgaWYgdGhlIGRhdGEgYmVh cmluZyBwYWNrZXQgU0tCICh1c3VhbGx5IHNrLT5za19zZW5kX2hlYWQpCiAgKiBzaG91bGQgYmUg cHV0IG9uIHRoZSB3aXJlIHJpZ2h0IG5vdy4KQEAgLTE0NDgsMTEgKzE0NTIsMTEgQEAKIHN0YXRp YyBfX2lubGluZV9fIGludCB0Y3Bfc25kX3Rlc3Qoc3RydWN0IHRjcF9vcHQgKnRwLCBzdHJ1Y3Qg c2tfYnVmZiAqc2tiLAogCQkJCSAgIHVuc2lnbmVkIGN1cl9tc3MsIGludCBub25hZ2xlKQogewot CWludCBwa3RzID0gVENQX1NLQl9DQihza2IpLT50c29fZmFjdG9yOworCWludCBwa3RzID0gdGNw X3NrYl9wY291bnQoc2tiKTsKIAogCWlmICghcGt0cykgewotCQl0Y3Bfc2V0X3NrYl90c29fZmFj dG9yKHNrYiwgdHAtPm1zc19jYWNoZV9zdGQpOwotCQlwa3RzID0gVENQX1NLQl9DQihza2IpLT50 c29fZmFjdG9yOworCQl0Y3Bfc2V0X3NrYl90c29fc2Vncyhza2IsIHRwLT5tc3NfY2FjaGVfc3Rk KTsKKwkJcGt0cyA9IHRjcF9za2JfcGNvdW50KHNrYik7CiAJfQogCiAJLyoJUkZDIDExMjIgLSBz ZWN0aW9uIDQuMi4zLjQKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvaXBfb3V0cHV0LmMgYi9uZXQvaXB2 NC9pcF9vdXRwdXQuYwotLS0gYS9uZXQvaXB2NC9pcF9vdXRwdXQuYwkyMDA0LTA5LTMwIDIxOjAz OjE0IC0wNzowMAorKysgYi9uZXQvaXB2NC9pcF9vdXRwdXQuYwkyMDA0LTA5LTMwIDIxOjAzOjE0 IC0wNzowMApAQCAtMzA1LDcgKzMwNSw2IEBACiAJc3RydWN0IGlwX29wdGlvbnMgKm9wdCA9IGlu ZXQtPm9wdDsKIAlzdHJ1Y3QgcnRhYmxlICpydDsKIAlzdHJ1Y3QgaXBoZHIgKmlwaDsKLQl1MzIg bXR1OwogCiAJLyogU2tpcCBhbGwgb2YgdGhpcyBpZiB0aGUgcGFja2V0IGlzIGFscmVhZHkgcm91 dGVkLAogCSAqIGYuZS4gYnkgc29tZXRoaW5nIGxpa2UgU0NUUC4KQEAgLTM2NiwyMSArMzY1LDkg QEAKIAlza2ItPm5oLmlwaCAgID0gaXBoOwogCS8qIFRyYW5zcG9ydCBsYXllciBzZXQgc2tiLT5o LmZvbyBpdHNlbGYuICovCiAKLQlpZihvcHQgJiYgb3B0LT5vcHRsZW4pIHsKKwlpZiAob3B0ICYm IG9wdC0+b3B0bGVuKSB7CiAJCWlwaC0+aWhsICs9IG9wdC0+b3B0bGVuID4+IDI7CiAJCWlwX29w dGlvbnNfYnVpbGQoc2tiLCBvcHQsIGluZXQtPmRhZGRyLCBydCwgMCk7Ci0JfQotCi0JbXR1ID0g ZHN0X3BtdHUoJnJ0LT51LmRzdCk7Ci0JaWYgKHNrYi0+bGVuID4gbXR1ICYmIChzay0+c2tfcm91 dGVfY2FwcyAmIE5FVElGX0ZfVFNPKSkgewotCQl1bnNpZ25lZCBpbnQgaGxlbjsKLQotCQkvKiBI YWNrIHpvbmU6IGFsbCB0aGlzIG11c3QgYmUgZG9uZSBieSBUQ1AuICovCi0JCWhsZW4gPSAoKHNr Yi0+aC5yYXcgLSBza2ItPmRhdGEpICsgKHNrYi0+aC50aC0+ZG9mZiA8PCAyKSk7Ci0JCXNrYl9z aGluZm8oc2tiKS0+dHNvX3NpemUgPSBtdHUgLSBobGVuOwotCQlza2Jfc2hpbmZvKHNrYiktPnRz b19zZWdzID0KLQkJCShza2ItPmxlbiAtIGhsZW4gKyBza2Jfc2hpbmZvKHNrYiktPnRzb19zaXpl IC0gMSkvCi0JCQkJc2tiX3NoaW5mbyhza2IpLT50c29fc2l6ZSAtIDE7CiAJfQogCiAJaXBfc2Vs ZWN0X2lkZW50X21vcmUoaXBoLCAmcnQtPnUuZHN0LCBzaywgc2tiX3NoaW5mbyhza2IpLT50c29f c2Vncyk7CmRpZmYgLU5ydSBhL25ldC9pcHY0L3RjcC5jIGIvbmV0L2lwdjQvdGNwLmMKLS0tIGEv bmV0L2lwdjQvdGNwLmMJMjAwNC0wOS0zMCAyMTowMzoxNCAtMDc6MDAKKysrIGIvbmV0L2lwdjQv dGNwLmMJMjAwNC0wOS0zMCAyMTowMzoxNCAtMDc6MDAKQEAgLTY5MSw3ICs2OTEsNyBAQAogCQlz a2ItPmlwX3N1bW1lZCA9IENIRUNLU1VNX0hXOwogCQl0cC0+d3JpdGVfc2VxICs9IGNvcHk7CiAJ CVRDUF9TS0JfQ0Ioc2tiKS0+ZW5kX3NlcSArPSBjb3B5OwotCQlUQ1BfU0tCX0NCKHNrYiktPnRz b19mYWN0b3IgPSAwOworCQlza2Jfc2hpbmZvKHNrYiktPnRzb19zZWdzID0gMDsKIAogCQlpZiAo IWNvcGllZCkKIAkJCVRDUF9TS0JfQ0Ioc2tiKS0+ZmxhZ3MgJj0gflRDUENCX0ZMQUdfUFNIOwpA QCAtOTM4LDcgKzkzOCw3IEBACiAKIAkJCXRwLT53cml0ZV9zZXEgKz0gY29weTsKIAkJCVRDUF9T S0JfQ0Ioc2tiKS0+ZW5kX3NlcSArPSBjb3B5OwotCQkJVENQX1NLQl9DQihza2IpLT50c29fZmFj dG9yID0gMDsKKwkJCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NlZ3MgPSAwOwogCiAJCQlmcm9tICs9 IGNvcHk7CiAJCQljb3BpZWQgKz0gY29weTsKZGlmZiAtTnJ1IGEvbmV0L2lwdjQvdGNwX2lucHV0 LmMgYi9uZXQvaXB2NC90Y3BfaW5wdXQuYwotLS0gYS9uZXQvaXB2NC90Y3BfaW5wdXQuYwkyMDA0 LTA5LTMwIDIxOjAzOjE0IC0wNzowMAorKysgYi9uZXQvaXB2NC90Y3BfaW5wdXQuYwkyMDA0LTA5 LTMwIDIxOjAzOjE0IC0wNzowMApAQCAtMTAzNSw3ICsxMDM1LDcgQEAKIAkJCWlmKCFiZWZvcmUo VENQX1NLQl9DQihza2IpLT5zZXEsIGVuZF9zZXEpKQogCQkJCWJyZWFrOwogCi0JCQlmYWNrX2Nv dW50ICs9IFRDUF9TS0JfQ0Ioc2tiKS0+dHNvX2ZhY3RvcjsKKwkJCWZhY2tfY291bnQgKz0gdGNw X3NrYl9wY291bnQoc2tiKTsKIAogCQkJaW5fc2FjayA9ICFhZnRlcihzdGFydF9zZXEsIFRDUF9T S0JfQ0Ioc2tiKS0+c2VxKSAmJgogCQkJCSFiZWZvcmUoZW5kX3NlcSwgVENQX1NLQl9DQihza2Ip LT5lbmRfc2VxKTsKQEAgLTEyMjQsNyArMTIyNCw3IEBACiAJdGNwX3NldF9wY291bnQoJnRwLT5m YWNrZXRzX291dCwgMCk7CiAKIAlza19zdHJlYW1fZm9yX3JldHJhbnNfcXVldWUoc2tiLCBzaykg ewotCQljbnQgKz0gVENQX1NLQl9DQihza2IpLT50c29fZmFjdG9yOzsKKwkJY250ICs9IHRjcF9z a2JfcGNvdW50KHNrYik7CiAJCVRDUF9TS0JfQ0Ioc2tiKS0+c2Fja2VkICY9IH5UQ1BDQl9MT1NU OwogCQlpZiAoIShUQ1BfU0tCX0NCKHNrYiktPnNhY2tlZCZUQ1BDQl9TQUNLRURfQUNLRUQpKSB7 CiAKQEAgLTEyOTksNyArMTI5OSw3IEBACiAJCXRwLT51bmRvX21hcmtlciA9IHRwLT5zbmRfdW5h OwogCiAJc2tfc3RyZWFtX2Zvcl9yZXRyYW5zX3F1ZXVlKHNrYiwgc2spIHsKLQkJY250ICs9IFRD UF9TS0JfQ0Ioc2tiKS0+dHNvX2ZhY3RvcjsKKwkJY250ICs9IHRjcF9za2JfcGNvdW50KHNrYik7 CiAJCWlmIChUQ1BfU0tCX0NCKHNrYiktPnNhY2tlZCZUQ1BDQl9SRVRSQU5TKQogCQkJdHAtPnVu ZG9fbWFya2VyID0gMDsKIAkJVENQX1NLQl9DQihza2IpLT5zYWNrZWQgJj0gKH5UQ1BDQl9UQUdC SVRTKXxUQ1BDQl9TQUNLRURfQUNLRUQ7CkBAIC0xNTUwLDcgKzE1NTAsNyBAQAogCUJVR19UUkFQ KGNudCA8PSB0Y3BfZ2V0X3Bjb3VudCgmdHAtPnBhY2tldHNfb3V0KSk7CiAKIAlza19zdHJlYW1f Zm9yX3JldHJhbnNfcXVldWUoc2tiLCBzaykgewotCQljbnQgLT0gVENQX1NLQl9DQihza2IpLT50 c29fZmFjdG9yOworCQljbnQgLT0gdGNwX3NrYl9wY291bnQoc2tiKTsKIAkJaWYgKGNudCA8IDAg fHwgYWZ0ZXIoVENQX1NLQl9DQihza2IpLT5lbmRfc2VxLCBoaWdoX3NlcSkpCiAJCQlicmVhazsK IAkJaWYgKCEoVENQX1NLQl9DQihza2IpLT5zYWNrZWQmVENQQ0JfVEFHQklUUykpIHsKQEAgLTIz NjksNyArMjM2OSw3IEBACiB7CiAJc3RydWN0IHRjcF9vcHQgKnRwID0gdGNwX3NrKHNrKTsKIAlz dHJ1Y3QgdGNwX3NrYl9jYiAqc2NiID0gVENQX1NLQl9DQihza2IpOyAKLQlfX3UzMiBtc3MgPSBz Y2ItPnRzb19tc3M7CisJX191MzIgbXNzID0gdGNwX3NrYl9wc2l6ZShza2IpOwogCV9fdTMyIHNu ZF91bmEgPSB0cC0+c25kX3VuYTsKIAlfX3UzMiBvcmlnX3NlcSwgc2VxOwogCV9fdTMyIHBhY2tl dHNfYWNrZWQgPSAwOwpAQCAtMjQyMyw3ICsyNDIzLDcgQEAKIAkJfQogCQl0Y3BfZGVjX3Bjb3Vu dF9leHBsaWNpdCgmdHAtPnBhY2tldHNfb3V0LCBwYWNrZXRzX2Fja2VkKTsKIAotCQlCVUdfT04o c2NiLT50c29fZmFjdG9yID09IDApOworCQlCVUdfT04odGNwX3NrYl9wY291bnQoc2tiKSA9PSAw KTsKIAkJQlVHX09OKCFiZWZvcmUoc2NiLT5zZXEsIHNjYi0+ZW5kX3NlcSkpOwogCX0KIApAQCAt MjQ1MCw3ICsyNDUwLDcgQEAKIAkJICogdGhlIG90aGVyIGVuZC4KIAkJICovCiAJCWlmIChhZnRl cihzY2ItPmVuZF9zZXEsIHRwLT5zbmRfdW5hKSkgewotCQkJaWYgKHNjYi0+dHNvX2ZhY3RvciA+ IDEpCisJCQlpZiAodGNwX3NrYl9wY291bnQoc2tiKSA+IDEpCiAJCQkJYWNrZWQgfD0gdGNwX3Rz b19hY2tlZChzaywgc2tiLAogCQkJCQkJICAgICAgIG5vdywgJnNlcV9ydHQpOwogCQkJYnJlYWs7 CmRpZmYgLU5ydSBhL25ldC9pcHY0L3RjcF9vdXRwdXQuYyBiL25ldC9pcHY0L3RjcF9vdXRwdXQu YwotLS0gYS9uZXQvaXB2NC90Y3Bfb3V0cHV0LmMJMjAwNC0wOS0zMCAyMTowMzoxNCAtMDc6MDAK KysrIGIvbmV0L2lwdjQvdGNwX291dHB1dC5jCTIwMDQtMDktMzAgMjE6MDM6MTQgLTA3OjAwCkBA IC0yNzQsNyArMjc0LDcgQEAKIAkJaW50IHN5c2N0bF9mbGFnczsKIAkJaW50IGVycjsKIAotCQlC VUdfT04oIVRDUF9TS0JfQ0Ioc2tiKS0+dHNvX2ZhY3Rvcik7CisJCUJVR19PTighdGNwX3NrYl9w Y291bnQoc2tiKSk7CiAKICNkZWZpbmUgU1lTQ1RMX0ZMQUdfVFNUQU1QUwkweDEKICNkZWZpbmUg U1lTQ1RMX0ZMQUdfV1NDQUxFCTB4MgpAQCAtNDI4LDIxICs0MjgsMjIgQEAKIAl9CiB9CiAKLXZv aWQgdGNwX3NldF9za2JfdHNvX2ZhY3RvcihzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCB1bnNpZ25lZCBp bnQgbXNzX3N0ZCkKK3ZvaWQgdGNwX3NldF9za2JfdHNvX3NlZ3Moc3RydWN0IHNrX2J1ZmYgKnNr YiwgdW5zaWduZWQgaW50IG1zc19zdGQpCiB7CiAJaWYgKHNrYi0+bGVuIDw9IG1zc19zdGQpIHsK IAkJLyogQXZvaWQgdGhlIGNvc3RseSBkaXZpZGUgaW4gdGhlIG5vcm1hbAogCQkgKiBub24tVFNP IGNhc2UuCiAJCSAqLwotCQlUQ1BfU0tCX0NCKHNrYiktPnRzb19mYWN0b3IgPSAxOworCQlza2Jf c2hpbmZvKHNrYiktPnRzb19zZWdzID0gMTsKKwkJc2tiX3NoaW5mbyhza2IpLT50c29fc2l6ZSA9 IDA7CiAJfSBlbHNlIHsKIAkJdW5zaWduZWQgaW50IGZhY3RvcjsKIAogCQlmYWN0b3IgPSBza2It PmxlbiArIChtc3Nfc3RkIC0gMSk7CiAJCWZhY3RvciAvPSBtc3Nfc3RkOwotCQlUQ1BfU0tCX0NC KHNrYiktPnRzb19mYWN0b3IgPSBmYWN0b3I7CisJCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NlZ3Mg PSBmYWN0b3I7CisJCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NpemUgPSBtc3Nfc3RkOwogCX0KLQlU Q1BfU0tCX0NCKHNrYiktPnRzb19tc3MgPSBtc3Nfc3RkOwogfQogCiAvKiBGdW5jdGlvbiB0byBj cmVhdGUgdHdvIG5ldyBUQ1Agc2VnbWVudHMuICBTaHJpbmtzIHRoZSBnaXZlbiBzZWdtZW50CkBA IC01MDgsOCArNTA5LDggQEAKIAl9CiAKIAkvKiBGaXggdXAgdHNvX2ZhY3RvciBmb3IgYm90aCBv cmlnaW5hbCBhbmQgbmV3IFNLQi4gICovCi0JdGNwX3NldF9za2JfdHNvX2ZhY3Rvcihza2IsIHRw LT5tc3NfY2FjaGVfc3RkKTsKLQl0Y3Bfc2V0X3NrYl90c29fZmFjdG9yKGJ1ZmYsIHRwLT5tc3Nf Y2FjaGVfc3RkKTsKKwl0Y3Bfc2V0X3NrYl90c29fc2Vncyhza2IsIHRwLT5tc3NfY2FjaGVfc3Rk KTsKKwl0Y3Bfc2V0X3NrYl90c29fc2VncyhidWZmLCB0cC0+bXNzX2NhY2hlX3N0ZCk7CiAKIAlp ZiAoVENQX1NLQl9DQihza2IpLT5zYWNrZWQgJiBUQ1BDQl9MT1NUKSB7CiAJCXRjcF9pbmNfcGNv dW50KCZ0cC0+bG9zdF9vdXQsIHNrYik7CkBAIC01ODUsNyArNTg2LDcgQEAKIAkvKiBBbnkgY2hh bmdlIG9mIHNrYi0+bGVuIHJlcXVpcmVzIHJlY2FsY3VsYXRpb24gb2YgdHNvCiAJICogZmFjdG9y IGFuZCBtc3MuCiAJICovCi0JdGNwX3NldF9za2JfdHNvX2ZhY3Rvcihza2IsIHRwLT5tc3NfY2Fj aGVfc3RkKTsKKwl0Y3Bfc2V0X3NrYl90c29fc2Vncyhza2IsIHRwLT5tc3NfY2FjaGVfc3RkKTsK IAogCXJldHVybiAwOwogfQpAQCAtOTE0LDggKzkxNSw4IEBACiAJCSAgICAoKHNrYl9zaXplICsg bmV4dF9za2Jfc2l6ZSkgPiBtc3Nfbm93KSkKIAkJCXJldHVybjsKIAotCQlCVUdfT04oVENQX1NL Ql9DQihza2IpLT50c29fZmFjdG9yICE9IDEgfHwKLQkJICAgICAgIFRDUF9TS0JfQ0IobmV4dF9z a2IpLT50c29fZmFjdG9yICE9IDEpOworCQlCVUdfT04odGNwX3NrYl9wY291bnQoc2tiKSAhPSAx IHx8CisJCSAgICAgICB0Y3Bfc2tiX3Bjb3VudChuZXh0X3NrYikgIT0gMSk7CiAKIAkJLyogT2su ICBXZSB3aWxsIGJlIGFibGUgdG8gY29sbGFwc2UgdGhlIHBhY2tldC4gKi8KIAkJX19za2JfdW5s aW5rKG5leHRfc2tiLCBuZXh0X3NrYi0+bGlzdCk7CkBAIC0xMDQ3LDE0ICsxMDQ4LDE0IEBACiAJ CXJldHVybiAtRUFHQUlOOwogCiAJaWYgKHNrYi0+bGVuID4gY3VyX21zcykgewotCQlpbnQgb2xk X2ZhY3RvciA9IFRDUF9TS0JfQ0Ioc2tiKS0+dHNvX2ZhY3RvcjsKKwkJaW50IG9sZF9mYWN0b3Ig PSB0Y3Bfc2tiX3Bjb3VudChza2IpOwogCQlpbnQgbmV3X2ZhY3RvcjsKIAogCQlpZiAodGNwX2Zy YWdtZW50KHNrLCBza2IsIGN1cl9tc3MpKQogCQkJcmV0dXJuIC1FTk9NRU07IC8qIFdlJ2xsIHRy eSBhZ2FpbiBsYXRlci4gKi8KIAogCQkvKiBOZXcgU0tCIGNyZWF0ZWQsIGFjY291bnQgZm9yIGl0 LiAqLwotCQluZXdfZmFjdG9yID0gVENQX1NLQl9DQihza2IpLT50c29fZmFjdG9yOworCQluZXdf ZmFjdG9yID0gdGNwX3NrYl9wY291bnQoc2tiKTsKIAkJdGNwX2RlY19wY291bnRfZXhwbGljaXQo JnRwLT5wYWNrZXRzX291dCwKIAkJCQkJb2xkX2ZhY3RvciAtIG5ld19mYWN0b3IpOwogCQl0Y3Bf aW5jX3Bjb3VudCgmdHAtPnBhY2tldHNfb3V0LCBza2ItPm5leHQpOwpAQCAtMTA4MSw3ICsxMDgy LDggQEAKIAkgICB0cC0+c25kX3VuYSA9PSAoVENQX1NLQl9DQihza2IpLT5lbmRfc2VxIC0gMSkp IHsKIAkJaWYgKCFwc2tiX3RyaW0oc2tiLCAwKSkgewogCQkJVENQX1NLQl9DQihza2IpLT5zZXEg PSBUQ1BfU0tCX0NCKHNrYiktPmVuZF9zZXEgLSAxOwotCQkJVENQX1NLQl9DQihza2IpLT50c29f ZmFjdG9yID0gMTsKKwkJCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NlZ3MgPSAxOworCQkJc2tiX3No aW5mbyhza2IpLT50c29fc2l6ZSA9IDA7CiAJCQlza2ItPmlwX3N1bW1lZCA9IENIRUNLU1VNX05P TkU7CiAJCQlza2ItPmNzdW0gPSAwOwogCQl9CkBAIC0xMTY2LDcgKzExNjgsNyBAQAogCQkJCQkJ dGNwX3Jlc2V0X3htaXRfdGltZXIoc2ssIFRDUF9USU1FX1JFVFJBTlMsIHRwLT5ydG8pOwogCQkJ CX0KIAotCQkJCXBhY2tldF9jbnQgLT0gVENQX1NLQl9DQihza2IpLT50c29fZmFjdG9yOworCQkJ CXBhY2tldF9jbnQgLT0gdGNwX3NrYl9wY291bnQoc2tiKTsKIAkJCQlpZiAocGFja2V0X2NudCA8 PSAwKQogCQkJCQlicmVhazsKIAkJCX0KQEAgLTEyNTYsOCArMTI1OCw4IEBACiAJCXNrYi0+Y3N1 bSA9IDA7CiAJCVRDUF9TS0JfQ0Ioc2tiKS0+ZmxhZ3MgPSAoVENQQ0JfRkxBR19BQ0sgfCBUQ1BD Ql9GTEFHX0ZJTik7CiAJCVRDUF9TS0JfQ0Ioc2tiKS0+c2Fja2VkID0gMDsKLQkJVENQX1NLQl9D Qihza2IpLT50c29fZmFjdG9yID0gMTsKLQkJVENQX1NLQl9DQihza2IpLT50c29fbXNzID0gdHAt Pm1zc19jYWNoZV9zdGQ7CisJCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NlZ3MgPSAxOworCQlza2Jf c2hpbmZvKHNrYiktPnRzb19zaXplID0gMDsKIAogCQkvKiBGSU4gZWF0cyBhIHNlcXVlbmNlIGJ5 dGUsIHdyaXRlX3NlcSBhZHZhbmNlZCBieSB0Y3BfcXVldWVfc2tiKCkuICovCiAJCVRDUF9TS0Jf Q0Ioc2tiKS0+c2VxID0gdHAtPndyaXRlX3NlcTsKQEAgLTEyODksOCArMTI5MSw4IEBACiAJc2ti LT5jc3VtID0gMDsKIAlUQ1BfU0tCX0NCKHNrYiktPmZsYWdzID0gKFRDUENCX0ZMQUdfQUNLIHwg VENQQ0JfRkxBR19SU1QpOwogCVRDUF9TS0JfQ0Ioc2tiKS0+c2Fja2VkID0gMDsKLQlUQ1BfU0tC X0NCKHNrYiktPnRzb19mYWN0b3IgPSAxOwotCVRDUF9TS0JfQ0Ioc2tiKS0+dHNvX21zcyA9IHRw LT5tc3NfY2FjaGVfc3RkOworCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NlZ3MgPSAxOworCXNrYl9z aGluZm8oc2tiKS0+dHNvX3NpemUgPSAwOwogCiAJLyogU2VuZCBpdCBvZmYuICovCiAJVENQX1NL Ql9DQihza2IpLT5zZXEgPSB0Y3BfYWNjZXB0YWJsZV9zZXEoc2ssIHRwKTsKQEAgLTEzNzEsOCAr MTM3Myw4IEBACiAJVENQX1NLQl9DQihza2IpLT5zZXEgPSByZXEtPnNudF9pc247CiAJVENQX1NL Ql9DQihza2IpLT5lbmRfc2VxID0gVENQX1NLQl9DQihza2IpLT5zZXEgKyAxOwogCVRDUF9TS0Jf Q0Ioc2tiKS0+c2Fja2VkID0gMDsKLQlUQ1BfU0tCX0NCKHNrYiktPnRzb19mYWN0b3IgPSAxOwot CVRDUF9TS0JfQ0Ioc2tiKS0+dHNvX21zcyA9IHRwLT5tc3NfY2FjaGVfc3RkOworCXNrYl9zaGlu Zm8oc2tiKS0+dHNvX3NlZ3MgPSAxOworCXNrYl9zaGluZm8oc2tiKS0+dHNvX3NpemUgPSAwOwog CXRoLT5zZXEgPSBodG9ubChUQ1BfU0tCX0NCKHNrYiktPnNlcSk7CiAJdGgtPmFja19zZXEgPSBo dG9ubChyZXEtPnJjdl9pc24gKyAxKTsKIAlpZiAocmVxLT5yY3Zfd25kID09IDApIHsgLyogaWdu b3JlZCBmb3IgcmV0cmFuc21pdHRlZCBzeW5zICovCkBAIC0xNDc0LDggKzE0NzYsOCBAQAogCVRD UF9TS0JfQ0IoYnVmZiktPmZsYWdzID0gVENQQ0JfRkxBR19TWU47CiAJVENQX0VDTl9zZW5kX3N5 bihzaywgdHAsIGJ1ZmYpOwogCVRDUF9TS0JfQ0IoYnVmZiktPnNhY2tlZCA9IDA7Ci0JVENQX1NL Ql9DQihidWZmKS0+dHNvX2ZhY3RvciA9IDE7Ci0JVENQX1NLQl9DQihidWZmKS0+dHNvX21zcyA9 IHRwLT5tc3NfY2FjaGVfc3RkOworCXNrYl9zaGluZm8oYnVmZiktPnRzb19zZWdzID0gMTsKKwlz a2Jfc2hpbmZvKGJ1ZmYpLT50c29fc2l6ZSA9IDA7CiAJYnVmZi0+Y3N1bSA9IDA7CiAJVENQX1NL Ql9DQihidWZmKS0+c2VxID0gdHAtPndyaXRlX3NlcSsrOwogCVRDUF9TS0JfQ0IoYnVmZiktPmVu ZF9zZXEgPSB0cC0+d3JpdGVfc2VxOwpAQCAtMTU3NSw4ICsxNTc3LDggQEAKIAkJYnVmZi0+Y3N1 bSA9IDA7CiAJCVRDUF9TS0JfQ0IoYnVmZiktPmZsYWdzID0gVENQQ0JfRkxBR19BQ0s7CiAJCVRD UF9TS0JfQ0IoYnVmZiktPnNhY2tlZCA9IDA7Ci0JCVRDUF9TS0JfQ0IoYnVmZiktPnRzb19mYWN0 b3IgPSAxOwotCQlUQ1BfU0tCX0NCKGJ1ZmYpLT50c29fbXNzID0gdHAtPm1zc19jYWNoZV9zdGQ7 CisJCXNrYl9zaGluZm8oYnVmZiktPnRzb19zZWdzID0gMTsKKwkJc2tiX3NoaW5mbyhidWZmKS0+ dHNvX3NpemUgPSAwOwogCiAJCS8qIFNlbmQgaXQgb2ZmLCB0aGlzIGNsZWFycyBkZWxheWVkIGFj a3MgZm9yIHVzLiAqLwogCQlUQ1BfU0tCX0NCKGJ1ZmYpLT5zZXEgPSBUQ1BfU0tCX0NCKGJ1ZmYp LT5lbmRfc2VxID0gdGNwX2FjY2VwdGFibGVfc2VxKHNrLCB0cCk7CkBAIC0xNjExLDggKzE2MTMs OCBAQAogCXNrYi0+Y3N1bSA9IDA7CiAJVENQX1NLQl9DQihza2IpLT5mbGFncyA9IFRDUENCX0ZM QUdfQUNLOwogCVRDUF9TS0JfQ0Ioc2tiKS0+c2Fja2VkID0gdXJnZW50OwotCVRDUF9TS0JfQ0Io c2tiKS0+dHNvX2ZhY3RvciA9IDE7Ci0JVENQX1NLQl9DQihza2IpLT50c29fbXNzID0gdHAtPm1z c19jYWNoZV9zdGQ7CisJc2tiX3NoaW5mbyhza2IpLT50c29fc2VncyA9IDE7CisJc2tiX3NoaW5m byhza2IpLT50c29fc2l6ZSA9IDA7CiAKIAkvKiBVc2UgYSBwcmV2aW91cyBzZXF1ZW5jZS4gIFRo aXMgc2hvdWxkIGNhdXNlIHRoZSBvdGhlcgogCSAqIGVuZCB0byBzZW5kIGFuIGFjay4gIERvbid0 IHF1ZXVlIG9yIGNsb25lIFNLQiwganVzdApAQCAtMTY1Niw4ICsxNjU4LDggQEAKIAkJCQkJc2st PnNrX3JvdXRlX2NhcHMgJj0gfk5FVElGX0ZfVFNPOwogCQkJCQl0cC0+bXNzX2NhY2hlID0gdHAt Pm1zc19jYWNoZV9zdGQ7CiAJCQkJfQotCQkJfSBlbHNlIGlmICghVENQX1NLQl9DQihza2IpLT50 c29fZmFjdG9yKQotCQkJCXRjcF9zZXRfc2tiX3Rzb19mYWN0b3Ioc2tiLCB0cC0+bXNzX2NhY2hl X3N0ZCk7CisJCQl9IGVsc2UgaWYgKCF0Y3Bfc2tiX3Bjb3VudChza2IpKQorCQkJCXRjcF9zZXRf c2tiX3Rzb19zZWdzKHNrYiwgdHAtPm1zc19jYWNoZV9zdGQpOwogCiAJCQlUQ1BfU0tCX0NCKHNr YiktPmZsYWdzIHw9IFRDUENCX0ZMQUdfUFNIOwogCQkJVENQX1NLQl9DQihza2IpLT53aGVuID0g dGNwX3RpbWVfc3RhbXA7Cg== --Multipart=_Thu__30_Sep_2004_21_32_21_-0700_9lFrv8zfPlAUX31h-- From garzik@havoc.gtf.org Thu Sep 30 22:00:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 22:00:43 -0700 (PDT) Received: from havoc.gtf.org (havoc.gtf.org [69.28.190.101]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9150Y26024240 for ; Thu, 30 Sep 2004 22:00:34 -0700 Received: from havoc.gtf.org (havoc.gtf.org [127.0.0.1]) by havoc.gtf.org (Postfix) with ESMTP id C3FE2754E; Fri, 1 Oct 2004 00:59:18 -0400 (EDT) Received: (from garzik@localhost) by havoc.gtf.org (8.12.10/8.12.10/Submit) id i914xIdC025936; Fri, 1 Oct 2004 00:59:18 -0400 Date: Fri, 1 Oct 2004 00:59:18 -0400 From: Jeff Garzik To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: netdev-2.6 queue updated Message-ID: <20041001045918.GA25891@havoc.gtf.org> Reply-To: netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.1i X-archive-position: 9758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9669 Lines: 254 BK users: bk pull bk://gkernel.bkbits.net/netdev-2.6 Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.9-rc3-netdev1.patch.bz2 This will update the following files: arch/cris/arch-v10/drivers/ethernet.c | 140 ++---- drivers/ieee1394/eth1394.c | 95 +--- drivers/media/dvb/dvb-core/dvb_net.c | 9 drivers/net/3c509.c | 151 ++----- drivers/net/8139cp.c | 100 +++- drivers/net/8139too.c | 14 drivers/net/Kconfig | 45 +- drivers/net/acenic.c | 163 +++---- drivers/net/acenic.h | 23 - drivers/net/amd8111e.c | 248 +++++------ drivers/net/atp.c | 2 drivers/net/b44.c | 102 ++-- drivers/net/b44.h | 113 ----- drivers/net/defxx.c | 144 +++--- drivers/net/defxx.h | 2 drivers/net/dl2k.c | 267 +++++------- drivers/net/e100.c | 38 + drivers/net/e1000/e1000.h | 2 drivers/net/e1000/e1000_ethtool.c | 6 drivers/net/e1000/e1000_hw.c | 115 +++++ drivers/net/e1000/e1000_main.c | 41 - drivers/net/e1000/e1000_osdep.h | 6 drivers/net/e1000/e1000_param.c | 167 ++++--- drivers/net/eepro100.c | 425 +++++++++----------- drivers/net/ewrk3.c | 326 +++++++-------- drivers/net/forcedeth.c | 142 +++--- drivers/net/hamachi.c | 157 +++---- drivers/net/hamradio/hdlcdrv.c | 2 drivers/net/ibmlana.c | 9 drivers/net/iseries_veth.c | 81 +-- drivers/net/ixgb/ixgb_ethtool.c | 494 +++++++---------------- drivers/net/ixgb/ixgb_main.c | 34 - drivers/net/mac8390.c | 4 drivers/net/meth.c | 26 - drivers/net/natsemi.c | 273 +++++-------- drivers/net/ne2k-pci.c | 31 + drivers/net/ns83820.c | 61 -- drivers/net/pcmcia/smc91c92_cs.c | 181 ++++---- drivers/net/r8169.c | 592 +++++++++++++++++++++------- drivers/net/sis900.c | 258 ++++++------ drivers/net/sk_mca.c | 9 drivers/net/smc91x.h | 43 ++ drivers/net/starfire.c | 191 ++++----- drivers/net/sundance.c | 187 ++++---- drivers/net/tulip/de2104x.c | 3 drivers/net/tulip/de4x5.c | 2 drivers/net/tulip/tulip_core.c | 34 - drivers/net/tulip/winbond-840.c | 2 drivers/net/tulip/xircom_tulip_cb.c | 194 ++++----- drivers/net/typhoon.c | 232 ++++------- drivers/net/wan/lmc/lmc_main.c | 9 drivers/net/wireless/airo.c | 45 +- drivers/net/wireless/netwave_cs.c | 12 drivers/net/wireless/prism54/isl_38xx.c | 15 drivers/net/wireless/prism54/isl_38xx.h | 4 drivers/net/wireless/prism54/isl_ioctl.c | 629 ++++++++++++++++++++++++++---- drivers/net/wireless/prism54/isl_ioctl.h | 2 drivers/net/wireless/prism54/isl_oid.h | 9 drivers/net/wireless/prism54/islpci_dev.c | 35 - drivers/net/wireless/prism54/islpci_dev.h | 4 drivers/net/wireless/prism54/islpci_eth.c | 5 drivers/net/wireless/prism54/oid_mgt.c | 121 +++++ drivers/net/wireless/prism54/oid_mgt.h | 3 drivers/net/wireless/wavelan.c | 19 drivers/net/wireless/wavelan.p.h | 3 drivers/net/wireless/wavelan_cs.c | 181 +++----- drivers/net/wireless/wavelan_cs.p.h | 3 drivers/net/wireless/wl3501_cs.c | 53 -- drivers/net/yellowfin.c | 62 +- drivers/usb/gadget/ether.c | 73 +-- drivers/usb/net/catc.c | 122 +---- drivers/usb/net/kaweth.c | 34 - drivers/usb/net/pegasus.c | 297 +++++--------- drivers/usb/net/rtl8150.c | 186 +++----- include/linux/netdevice.h | 4 include/linux/wireless.h | 64 ++- include/net/iw_handler.h | 60 ++ net/core/dev.c | 2 net/core/wireless.c | 210 ++++++---- net/irda/irlan/irlan_client.c | 2 80 files changed, 4237 insertions(+), 4017 deletions(-) through these ChangeSets: : o eepro100.c iomap conversion : o [netdrvr b44] clean up SiliconBackplane definitions/functions o [netdrvr b44] ignore carrier lost errors Alexander Viro: o (27/27) catc ethtool conversion o (26/27) kaweth ethtool conversion o (25/27) pegasus ethtool conversion o (24/27) rtl8150 ethtool conversion o (23/27) gadget ethtool conversion o (22/27) amd8111e ethtool conversion o (21/27) dl2k ethtool conversion o (20/27) eepro100 ethtool conversion o (19/27) ewrk3 ethtool conversion o (18/27) forcedeth ethtool conversion o (17/27) hamachi ethtool conversion o (16/27) veth ethtool conversion o (15/27) natsemi ethtool conversion o (14/27) ns83820 ethtool conversion o (13/27) starfire ethtool conversion o (12/27) sundance ethtool conversion o (11/27) typhoon ethtool conversion o (10/27) yellowfin ethtool conversion o (9/27) wl3501_cs ethtool conversion o (8/27) wavelan ethtool conversion o (7/27) xircom ethtool conversion o (6/27) tulip ethtool conversion o (5/27) smc91c92_cs ethtool conversion o (4/27) 3c509 ethtool conversion o (3/27) ixgb ethtool conversion o (2/27) cris ethtool conversion o (1/27) eth1394 ethtool conversion o [netdrvr starfire] use netdev_priv o [netdrvr starfire] fix unregister_netdev call site o [netdrvr] use netdev_priv in dl2k, hamachi o [netdrvr] netdev_priv for sundance, typhoon, yellowfin o [netdrvr] netdev_priv for ewrk3, xircom_tulip_cb, wavelan_cs o [netdrvr usb] use netdev_priv o [netdrvr eth1394] use netdev_priv Andrew Morton: o e1000 sparc64 dma_mapping build fix o igxb speedup o pegasus.c fixes o de4x5 warning fix Daniele Venzano: o [netdrvr sis900] whitespace and codingstyle updates David Dillow: o PCI cleanups and convert to ethtool_ops Felipe Damasio: o 8139cp net driver: add MODULE_VERSION François Romieu: o via-velocity: wrong module name in Kconfig documentation o r8169: default on disabling PCIDAC o r8169: Mac identifier extracted from Realtek's driver v2.2 o r8169: TSO support o r8169: hint for Tx flow control o r8169: miscalculation of available Tx descriptors o 8139cp: SG support fixes o r8169: vlan support o r8169: Rx checksum support o r8169: advertise DMA to high memory o r8169: Tx checksum offload o r8169: comment a gcc 2.95.x bug o r8169: sync the names of a few bits with the 8139cp driver o r8169: bump version number o r8169: enable MWI o r8169: code cleanup o r8169: per device receive buffer size o r8169: add ethtool_ops.{get_regs_len/get_regs} Ganesh Venkatesan: o e1000 update -- fix MODULE_PARM, module_param, module_param_array o e1000 - Ethtool -- 82545 do not support WoL o e1000 - Polarity reversal workaround for 10F/10H links o e1000 - Fix VLAN filter setup errors (while running on PPC) o e1000 Check value returned by from pci_enable_device o e1000 - Removed support for advanced TCO features o e1000 - use pci_device_name for syslog messages till registering netdevice. o e100 driver version number update o e100 - use NET_IP_ALIGN to set rx data buffer alignment o e100 - Use pci_device_name for syslog messages till registering netdevice Jean Tourrilhes: o WE-17 typo fix o wireless-drivers-update-for-we-17.patch o wireless-extension-v17-for-linus.patch Jeff Garzik: o Hand-merge typhoon conflicts o [netdrvr eepro100] fix pci_iomap() args and info msg that follows o [netdrvr b44] update MODULE_AUTHORS o [netdrvr 8139cp] TSO support o [netdev] Remove no-op in-driver implementations of ->set_config() Jesse Brandeburg: o e100: whitespace and DPRINTKS o e100: fix NAPI race with watchdog o ixgb: fix endianness issue for tx cleanup Kenji Kaneshige: o add missing pci_disable_device for e1000 Maciej W. Rozycki: o defxx device name fixes o defxx trivial updates Manfred Spraul: o rx checksum support for gige nForce ethernet Marc Singer: o adding smc91x ethernet to lpd7a40x Margit Schubert-While: o prism54 fix wpa_supplicant frequency parsing o prism54 initial WPA support o prism54 add WE17 support o prism54 remove module params o prism54 Code cleanup Mika Kukkonen: o sparse: fix warnings in net/irda/* Nishanth Aravamudan: o net/de2104x: replace schedule_timeout() with msleep() Olaf Hering: o remove old version check from mac8390 Pavel Machek: o swsuspend for ne2k-pci cards Pekka Pietikäinen: o b44: use bounce buffers to workaround chip DMA bug/limitations Ralf Bächle: o Stop queue on close in hdlcdrv Rene Herman: o 8139too Interframe Gap Time Roger Luethi: o mc_filter on big-endian arch Steffen Klassert: o 8139cp - add netpoll support Stephen Hemminger: o 8139cp - module_param o (4/4) acenic - don't spin forever in hard_start_xmit o (3/4) acenic - __iomem warnings cleanup o (2/4) acenic - eliminate MAX_SKB_FRAGS #if o (1/4) acenic - use netdev_priv From yasuyuki.kozakai@toshiba.co.jp Thu Sep 30 22:09:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 30 Sep 2004 22:09:54 -0700 (PDT) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9159iL5024700 for ; Thu, 30 Sep 2004 22:09:45 -0700 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9159Dbv011808; Fri, 1 Oct 2004 14:09:14 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9159DQx027196; Fri, 1 Oct 2004 14:09:13 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id QAA27193 ; Fri, 1 Oct 2004 14:09:13 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id OAA09943; Fri, 1 Oct 2004 14:09:12 +0900 (JST) Received: by toshiba.co.jp id i9159Cg2021037; Fri, 1 Oct 2004 14:09:12 +0900 (JST) Date: Fri, 01 Oct 2004 14:09:10 +0900 (JST) Message-Id: <200410010509.i9159Cg2021037@toshiba.co.jp> To: yasuyuki.kozakai@toshiba.co.jp Cc: kaber@trash.net, okir@suse.de, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, usagi-core@linux-ipv6.org Subject: Re: [PATCH] netfilter6: Skip extension headers when matching icmp6-type From: Yasuyuki Kozakai In-Reply-To: <200410010019.i910JlZY002193@toshiba.co.jp> References: <200409301244.i8UCid17009482@toshiba.co.jp> <415C1CC9.2090604@trash.net> <200410010019.i910JlZY002193@toshiba.co.jp> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Oct__1_14:09:10_2004_359)--" Content-Transfer-Encoding: 7bit X-archive-position: 9759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yasuyuki.kozakai@toshiba.co.jp Precedence: bulk X-list: netdev Content-Length: 25935 Lines: 764 ----Next_Part(Fri_Oct__1_14:09:10_2004_359)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, From: Yasuyuki Kozakai Date: Fri, 01 Oct 2004 09:19:46 +0900 (JST) > From: Patrick McHardy > Date: Thu, 30 Sep 2004 16:48:41 +0200 > > > >Sorry, I sent it to only netfilter-devel ml because I wanted someone to test > > >it more before sending it to netdev ml. > > > > > > > > > > I've reviewed the patch, I think we can push it soon. > > Did you do any changes besides the u_int8_t fix since > > the last patch you sent ? You mean that "I" should send the fixed patch to netdev ? OK, David, here you are. # Sometimes I confuse I should send patches to netdev, or send them to # netfilter-devel and core team of netfilter review/send it to netdev.

This patch is the preparation before removing skb_linearize() from ip6_tables.c. The codes parsing headers are changed to use skb_header_pointer(). To do this, I also changed the arguments of match functions. The match functions get the offset to layer 4 protocol header instead of the pointer to it. The offset is calculated at ip6_packet_match(). In the result, this patch fixes the bug which assumes layer 4 protocol header is next to IPv6 header. Moreover, the arguments order of target functions are changed likely IPv4 to occur compiling error when a user try this patch and old target modules. This patch doesn't remove skb_linearize() yet. It will be done after all match/target functions are changed to use skb_header_pointer(). Signed-off-by: Yasuyuki KOZAKAI Regards, ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project ----Next_Part(Fri_Oct__1_14:09:10_2004_359)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nolinearize.patch" diff -Nur linux-2.6.9-rc3/include/linux/netfilter_ipv6/ip6_tables.h linux-2.6.9-rc3-nolinearize/include/linux/netfilter_ipv6/ip6_tables.h --- linux-2.6.9-rc3/include/linux/netfilter_ipv6/ip6_tables.h 2004-09-30 18:45:23.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/include/linux/netfilter_ipv6/ip6_tables.h 2004-10-01 12:42:35.225648336 +0900 @@ -355,13 +355,15 @@ /* Return true or false: return FALSE and set *hotdrop = 1 to force immediate packet drop. */ + /* Arguments changed since 2.6.9, as this must now handle + non-linear skb, using skb_header_pointer and + skb_ip_make_writable. */ int (*match)(const struct sk_buff *skb, const struct net_device *in, const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop); /* Called when user tries to insert an entry of this type. */ @@ -386,11 +388,13 @@ const char name[IP6T_FUNCTION_MAXNAMELEN]; - /* Returns verdict. */ + /* Returns verdict. Argument order changed since 2.6.9, as this + must now handle non-linear skbs, using skb_copy_bits and + skb_ip_make_writable. */ unsigned int (*target)(struct sk_buff **pskb, - unsigned int hooknum, const struct net_device *in, const struct net_device *out, + unsigned int hooknum, const void *targinfo, void *userdata); diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6_tables.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6_tables.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6_tables.c 2004-09-30 18:45:24.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6_tables.c 2004-10-01 12:43:02.644480040 +0900 @@ -158,14 +158,15 @@ /* Returns whether matches rule or not. */ static inline int ip6_packet_match(const struct sk_buff *skb, - const struct ipv6hdr *ipv6, const char *indev, const char *outdev, const struct ip6t_ip6 *ip6info, - int isfrag) + unsigned int *protoff, + int *fragoff) { size_t i; unsigned long ret; + const struct ipv6hdr *ipv6 = skb->nh.ipv6h; #define FWINV(bool,invflg) ((bool) ^ !!(ip6info->invflags & invflg)) @@ -216,9 +217,10 @@ /* look for the desired protocol header */ if((ip6info->flags & IP6T_F_PROTO)) { u_int8_t currenthdr = ipv6->nexthdr; - struct ipv6_opt_hdr *hdrptr; + struct ipv6_opt_hdr _hdr, *hp; u_int16_t ptr; /* Header offset in skb */ u_int16_t hdrlen; /* Header */ + u_int16_t _fragoff = 0, *fp = NULL; ptr = IPV6_HDR_LEN; @@ -234,23 +236,41 @@ (currenthdr == IPPROTO_ESP)) return 0; - hdrptr = (struct ipv6_opt_hdr *)(skb->data + ptr); + hp = skb_header_pointer(skb, ptr, sizeof(_hdr), &_hdr); + BUG_ON(hp == NULL); /* Size calculation */ if (currenthdr == IPPROTO_FRAGMENT) { + fp = skb_header_pointer(skb, + ptr+offsetof(struct frag_hdr, + frag_off), + sizeof(_fragoff), + &_fragoff); + if (fp == NULL) + return 0; + + _fragoff = ntohs(*fp) & ~0x7; hdrlen = 8; } else if (currenthdr == IPPROTO_AH) - hdrlen = (hdrptr->hdrlen+2)<<2; + hdrlen = (hp->hdrlen+2)<<2; else - hdrlen = ipv6_optlen(hdrptr); + hdrlen = ipv6_optlen(hp); - currenthdr = hdrptr->nexthdr; + currenthdr = hp->nexthdr; ptr += hdrlen; /* ptr is too large */ if ( ptr > skb->len ) return 0; + if (_fragoff) { + if (ip6t_ext_hdr(currenthdr)) + return 0; + break; + } } + *protoff = ptr; + *fragoff = _fragoff; + /* currenthdr contains the protocol header */ dprintf("Packet protocol %hi ?= %s%hi.\n", @@ -292,9 +312,9 @@ static unsigned int ip6t_error(struct sk_buff **pskb, - unsigned int hooknum, const struct net_device *in, const struct net_device *out, + unsigned int hooknum, const void *targinfo, void *userinfo) { @@ -310,13 +330,12 @@ const struct net_device *in, const struct net_device *out, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { /* Stop iteration if it doesn't match */ if (!m->u.kernel.match->match(skb, in, out, m->data, - offset, hdr, datalen, hotdrop)) + offset, protoff, hotdrop)) return 1; else return 0; @@ -338,10 +357,8 @@ void *userdata) { static const char nulldevname[IFNAMSIZ]; - u_int16_t offset = 0; - struct ipv6hdr *ipv6; - void *protohdr; - u_int16_t datalen; + int offset = 0; + unsigned int protoff = 0; int hotdrop = 0; /* Initializing verdict to NF_DROP keeps gcc happy. */ unsigned int verdict = NF_DROP; @@ -354,9 +371,6 @@ return NF_DROP; /* Initialization */ - ipv6 = (*pskb)->nh.ipv6h; - protohdr = (u_int32_t *)((char *)ipv6 + IPV6_HDR_LEN); - datalen = (*pskb)->len - IPV6_HDR_LEN; indev = in ? in->name : nulldevname; outdev = out ? out->name : nulldevname; @@ -393,17 +407,19 @@ IP_NF_ASSERT(e); IP_NF_ASSERT(back); (*pskb)->nfcache |= e->nfcache; - if (ip6_packet_match(*pskb, ipv6, indev, outdev, - &e->ipv6, offset)) { + if (ip6_packet_match(*pskb, indev, outdev, &e->ipv6, + &protoff, &offset)) { struct ip6t_entry_target *t; if (IP6T_MATCH_ITERATE(e, do_match, *pskb, in, out, - offset, protohdr, - datalen, &hotdrop) != 0) + offset, protoff, &hotdrop) != 0) goto no_match; - ADD_COUNTER(e->counters, ntohs(ipv6->payload_len) + IPV6_HDR_LEN, 1); + ADD_COUNTER(e->counters, + ntohs((*pskb)->nh.ipv6h->payload_len) + + IPV6_HDR_LEN, + 1); t = ip6t_get_target(e); IP_NF_ASSERT(t->u.kernel.target); @@ -443,8 +459,8 @@ = 0xeeeeeeec; #endif verdict = t->u.kernel.target->target(pskb, - hook, in, out, + hook, t->data, userdata); @@ -459,11 +475,6 @@ ((struct ip6t_entry *)table_base)->comefrom = 0x57acc001; #endif - /* Target might have changed stuff. */ - ipv6 = (*pskb)->nh.ipv6h; - protohdr = (u_int32_t *)((void *)ipv6 + IPV6_HDR_LEN); - datalen = (*pskb)->len - IPV6_HDR_LEN; - if (verdict == IP6T_CONTINUE) e = (void *)e + e->next_offset; else @@ -1535,26 +1546,31 @@ static int tcp_find_option(u_int8_t option, - const struct tcphdr *tcp, - u_int16_t datalen, + const struct sk_buff *skb, + unsigned int tcpoff, + unsigned int optlen, int invert, int *hotdrop) { - unsigned int i = sizeof(struct tcphdr); - const u_int8_t *opt = (u_int8_t *)tcp; + /* tcp.doff is only 4 bits, ie. max 15 * 4 bytes */ + u_int8_t _opt[60 - sizeof(struct tcphdr)], *op; + unsigned int i; duprintf("tcp_match: finding option\n"); + if (!optlen) + return invert; /* If we don't have the whole header, drop packet. */ - if (tcp->doff * 4 < sizeof(struct tcphdr) || - tcp->doff * 4 > datalen) { + op = skb_header_pointer(skb, tcpoff + sizeof(struct tcphdr), optlen, + _opt); + if (op == NULL) { *hotdrop = 1; return 0; } - while (i < tcp->doff * 4) { - if (opt[i] == option) return !invert; - if (opt[i] < 2) i++; - else i += opt[i+1]?:1; + for (i = 0; i < optlen; ) { + if (op[i] == option) return !invert; + if (op[i] < 2) i++; + else i += op[i+1]?:1; } return invert; @@ -1566,27 +1582,31 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { - const struct tcphdr *tcp; + struct tcphdr _tcph, *th; const struct ip6t_tcp *tcpinfo = matchinfo; - int tcpoff; - u8 nexthdr = skb->nh.ipv6h->nexthdr; - /* To quote Alan: + if (offset) { + /* To quote Alan: - Don't allow a fragment of TCP 8 bytes in. Nobody normal - causes this. Its a cracker trying to break in by doing a - flag overwrite to pass the direction checks. - */ - - if (offset == 1) { - duprintf("Dropping evil TCP offset=1 frag.\n"); - *hotdrop = 1; + Don't allow a fragment of TCP 8 bytes in. Nobody normal + causes this. Its a cracker trying to break in by doing a + flag overwrite to pass the direction checks. + */ + if (offset == 1) { + duprintf("Dropping evil TCP offset=1 frag.\n"); + *hotdrop = 1; + } + /* Must not be a fragment. */ return 0; - } else if (offset == 0 && datalen < sizeof(struct tcphdr)) { + } + +#define FWINVTCP(bool,invflg) ((bool) ^ !!(tcpinfo->invflags & invflg)) + + th = skb_header_pointer(skb, protoff, sizeof(_tcph), &_tcph); + if (th == NULL) { /* We've been asked to examine this packet, and we can't. Hence, no choice but to drop. */ duprintf("Dropping evil TCP offset=0 tinygram.\n"); @@ -1594,45 +1614,30 @@ return 0; } - tcpoff = (u8*)(skb->nh.ipv6h + 1) - skb->data; - tcpoff = ipv6_skip_exthdr(skb, tcpoff, &nexthdr, skb->len - tcpoff); - if (tcpoff < 0 || tcpoff > skb->len) { - duprintf("tcp_match: cannot skip exthdr. Dropping.\n"); - *hotdrop = 1; - return 0; - } else if (nexthdr == IPPROTO_FRAGMENT) - return 0; - else if (nexthdr != IPPROTO_TCP || - skb->len - tcpoff < sizeof(struct tcphdr)) { - /* cannot be occured */ - duprintf("tcp_match: cannot get TCP header. Dropping.\n"); - *hotdrop = 1; - return 0; + if (!port_match(tcpinfo->spts[0], tcpinfo->spts[1], + ntohs(th->source), + !!(tcpinfo->invflags & IP6T_TCP_INV_SRCPT))) + return 0; + if (!port_match(tcpinfo->dpts[0], tcpinfo->dpts[1], + ntohs(th->dest), + !!(tcpinfo->invflags & IP6T_TCP_INV_DSTPT))) + return 0; + if (!FWINVTCP((((unsigned char *)th)[13] & tcpinfo->flg_mask) + == tcpinfo->flg_cmp, + IP6T_TCP_INV_FLAGS)) + return 0; + if (tcpinfo->option) { + if (th->doff * 4 < sizeof(_tcph)) { + *hotdrop = 1; + return 0; + } + if (!tcp_find_option(tcpinfo->option, skb, protoff, + th->doff*4 - sizeof(*th), + tcpinfo->invflags & IP6T_TCP_INV_OPTION, + hotdrop)) + return 0; } - - tcp = (struct tcphdr *)(skb->data + tcpoff); - - /* FIXME: Try tcp doff >> packet len against various stacks --RR */ - -#define FWINVTCP(bool,invflg) ((bool) ^ !!(tcpinfo->invflags & invflg)) - - /* Must not be a fragment. */ - return !offset - && port_match(tcpinfo->spts[0], tcpinfo->spts[1], - ntohs(tcp->source), - !!(tcpinfo->invflags & IP6T_TCP_INV_SRCPT)) - && port_match(tcpinfo->dpts[0], tcpinfo->dpts[1], - ntohs(tcp->dest), - !!(tcpinfo->invflags & IP6T_TCP_INV_DSTPT)) - && FWINVTCP((((unsigned char *)tcp)[13] - & tcpinfo->flg_mask) - == tcpinfo->flg_cmp, - IP6T_TCP_INV_FLAGS) - && (!tcpinfo->option - || tcp_find_option(tcpinfo->option, tcp, datalen, - tcpinfo->invflags - & IP6T_TCP_INV_OPTION, - hotdrop)); + return 1; } /* Called when user tries to insert an entry of this type. */ @@ -1658,16 +1663,18 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { - const struct udphdr *udp; + struct udphdr _udph, *uh; const struct ip6t_udp *udpinfo = matchinfo; - int udpoff; - u8 nexthdr = skb->nh.ipv6h->nexthdr; - if (offset == 0 && datalen < sizeof(struct udphdr)) { + /* Must not be a fragment. */ + if (offset) + return 0; + + uh = skb_header_pointer(skb, protoff, sizeof(_udph), &_udph); + if (uh == NULL) { /* We've been asked to examine this packet, and we can't. Hence, no choice but to drop. */ duprintf("Dropping evil UDP tinygram.\n"); @@ -1675,30 +1682,11 @@ return 0; } - udpoff = (u8*)(skb->nh.ipv6h + 1) - skb->data; - udpoff = ipv6_skip_exthdr(skb, udpoff, &nexthdr, skb->len - udpoff); - if (udpoff < 0 || udpoff > skb->len) { - duprintf("udp_match: cannot skip exthdr. Dropping.\n"); - *hotdrop = 1; - return 0; - } else if (nexthdr == IPPROTO_FRAGMENT) - return 0; - else if (nexthdr != IPPROTO_UDP || - skb->len - udpoff < sizeof(struct udphdr)) { - duprintf("udp_match: cannot get UDP header. Dropping.\n"); - *hotdrop = 1; - return 0; - } - - udp = (struct udphdr *)(skb->data + udpoff); - - /* Must not be a fragment. */ - return !offset - && port_match(udpinfo->spts[0], udpinfo->spts[1], - ntohs(udp->source), - !!(udpinfo->invflags & IP6T_UDP_INV_SRCPT)) + return port_match(udpinfo->spts[0], udpinfo->spts[1], + ntohs(uh->source), + !!(udpinfo->invflags & IP6T_UDP_INV_SRCPT)) && port_match(udpinfo->dpts[0], udpinfo->dpts[1], - ntohs(udp->dest), + ntohs(uh->dest), !!(udpinfo->invflags & IP6T_UDP_INV_DSTPT)); } @@ -1748,14 +1736,18 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { - const struct icmp6hdr *icmp = hdr; + struct icmp6hdr _icmp, *ic; const struct ip6t_icmp *icmpinfo = matchinfo; - if (offset == 0 && datalen < 2) { + /* Must not be a fragment. */ + if (offset) + return 0; + + ic = skb_header_pointer(skb, protoff, sizeof(_icmp), &_icmp); + if (ic == NULL) { /* We've been asked to examine this packet, and we can't. Hence, no choice but to drop. */ duprintf("Dropping evil ICMP tinygram.\n"); @@ -1763,13 +1755,11 @@ return 0; } - /* Must not be a fragment. */ - return !offset - && icmp6_type_code_match(icmpinfo->type, - icmpinfo->code[0], - icmpinfo->code[1], - icmp->icmp6_type, icmp->icmp6_code, - !!(icmpinfo->invflags&IP6T_ICMP_INV)); + return icmp6_type_code_match(icmpinfo->type, + icmpinfo->code[0], + icmpinfo->code[1], + ic->icmp6_type, ic->icmp6_code, + !!(icmpinfo->invflags&IP6T_ICMP_INV)); } /* Called when user tries to insert an entry of this type. */ diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_LOG.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_LOG.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_LOG.c 2004-09-30 18:45:24.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_LOG.c 2004-10-01 12:42:35.228647880 +0900 @@ -335,9 +335,9 @@ static unsigned int ip6t_log_target(struct sk_buff **pskb, - unsigned int hooknum, const struct net_device *in, const struct net_device *out, + unsigned int hooknum, const void *targinfo, void *userinfo) { diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_MARK.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_MARK.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_MARK.c 2004-08-14 14:37:41.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_MARK.c 2004-10-01 12:42:35.228647880 +0900 @@ -20,9 +20,9 @@ static unsigned int target(struct sk_buff **pskb, - unsigned int hooknum, const struct net_device *in, const struct net_device *out, + unsigned int hooknum, const void *targinfo, void *userinfo) { diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_ah.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_ah.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_ah.c 2004-08-14 14:36:17.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_ah.c 2004-10-01 12:42:35.229647728 +0900 @@ -45,8 +45,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct ip_auth_hdr *ah = NULL; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_dst.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_dst.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_dst.c 2004-08-14 14:36:13.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_dst.c 2004-10-01 12:42:35.229647728 +0900 @@ -60,8 +60,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct ipv6_opt_hdr *optsh = NULL; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_esp.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_esp.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_esp.c 2004-08-14 14:37:15.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_esp.c 2004-10-01 12:42:35.230647576 +0900 @@ -45,8 +45,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct ip_esp_hdr *esp = NULL; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_eui64.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_eui64.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_eui64.c 2004-08-14 14:36:11.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_eui64.c 2004-10-01 12:42:35.230647576 +0900 @@ -24,8 +24,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_frag.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_frag.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_frag.c 2004-08-14 14:36:32.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_frag.c 2004-10-01 12:42:35.230647576 +0900 @@ -70,8 +70,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct fraghdr *frag = NULL; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_hbh.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_hbh.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_hbh.c 2004-08-14 14:37:38.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_hbh.c 2004-10-01 12:42:35.231647424 +0900 @@ -59,8 +59,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct ipv6_opt_hdr *optsh = NULL; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_hl.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_hl.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_hl.c 2004-08-14 14:37:26.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_hl.c 2004-10-01 12:42:35.231647424 +0900 @@ -20,7 +20,7 @@ static int match(const struct sk_buff *skb, const struct net_device *in, const struct net_device *out, const void *matchinfo, - int offset, const void *hdr, u_int16_t datalen, + int offset, unsigned int protoff, int *hotdrop) { const struct ip6t_hl_info *info = matchinfo; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_ipv6header.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_ipv6header.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_ipv6header.c 2004-08-14 14:38:10.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_ipv6header.c 2004-10-01 12:42:35.231647424 +0900 @@ -31,8 +31,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { const struct ip6t_ipv6header_info *info = matchinfo; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_length.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_length.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_length.c 2004-08-14 14:38:08.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_length.c 2004-10-01 12:42:35.257643472 +0900 @@ -23,8 +23,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { const struct ip6t_length_info *info = matchinfo; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_limit.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_limit.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_limit.c 2004-08-14 14:36:32.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_limit.c 2004-10-01 12:42:35.258643320 +0900 @@ -57,8 +57,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct ip6t_rateinfo *r = ((struct ip6t_rateinfo *)matchinfo)->master; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_mac.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_mac.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_mac.c 2004-08-14 14:37:41.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_mac.c 2004-10-01 12:42:35.258643320 +0900 @@ -25,8 +25,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { const struct ip6t_mac_info *info = matchinfo; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_mark.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_mark.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_mark.c 2004-08-14 14:38:11.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_mark.c 2004-10-01 12:42:35.258643320 +0900 @@ -24,8 +24,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { const struct ip6t_mark_info *info = matchinfo; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_multiport.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_multiport.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_multiport.c 2004-08-14 14:38:09.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_multiport.c 2004-10-01 12:42:35.259643168 +0900 @@ -53,15 +53,14 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { - const struct udphdr *udp = hdr; + const struct udphdr *udp = (const struct udphdr *)(skb->data + protoff); const struct ip6t_multiport *multiinfo = matchinfo; /* Must be big enough to read ports. */ - if (offset == 0 && datalen < sizeof(struct udphdr)) { + if (offset == 0 && skb->len - protoff < sizeof(struct udphdr)) { /* We've been asked to examine this packet, and we can't. Hence, no choice but to drop. */ duprintf("ip6t_multiport:" diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_owner.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_owner.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_owner.c 2004-08-14 14:37:38.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_owner.c 2004-10-01 12:42:35.259643168 +0900 @@ -92,8 +92,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *hdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { const struct ip6t_owner_info *info = matchinfo; diff -Nur linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_rt.c linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_rt.c --- linux-2.6.9-rc3/net/ipv6/netfilter/ip6t_rt.c 2004-08-14 14:36:33.000000000 +0900 +++ linux-2.6.9-rc3-nolinearize/net/ipv6/netfilter/ip6t_rt.c 2004-10-01 12:42:35.259643168 +0900 @@ -47,8 +47,7 @@ const struct net_device *out, const void *matchinfo, int offset, - const void *protohdr, - u_int16_t datalen, + unsigned int protoff, int *hotdrop) { struct ipv6_rt_hdr *route = NULL; ----Next_Part(Fri_Oct__1_14:09:10_2004_359)----